---

🌌你好！这里是 晓雨的笔记本

在所有感兴趣的领域扩展知识，感谢你的陪伴与支持~

👋 欢迎添加好友 is_yu_ei，不定期掉落福利资讯

---

写在最前面

版权声明：本文为原创，遵循 CC 4.0 BY-SA 协议。转载请注明出处。

openPangu-2.0-Pro 模型地址 ：
openPangu-2.0-Pro:昇腾原生的openPangu-2.0-Pro语言模型 - AtomGit AI社区

505B 混合专家模型如何在昇腾上完成预训练、后训练和推理部署

资源够，只是大型工程的起点

假如你之前写的一段代码意外超有效，用户从几百涨到几百万，公司一路上市。公司买下了一栋自己的总部大楼，几百号员工、电脑、服务器、实验设备、会议室、档案，全都要在一个周末搬过去。

好消息是，现在你不差钱。所以第一反应很自然，多找点人。30 个搬家师傅不够，那就 100 个；100 个还不够，那就 500 个。

可真到了几百个人一起搬，瓶颈很快就从“人够不够”变成了“怎么协调”。有人堵在电梯口，有人在楼上等设备；服务器已经到新楼，机柜还在旧楼；两拨人抢着搬同一张会议桌，另一层却有人空着手等下一步指令。

所有人都很忙，但整栋楼就是搬不快。

这时候你发现，资源够，只是大型工程的起点。 真正难的是怎么分工、怎么传递、谁和谁应该离得近一点、哪些事情能同时做，又怎么尽量少互相等。

训练一个 505B 的大模型也有点像这样。

只不过这里的“搬家师傅”换成了昇腾 NPU。NPU 是专门加速神经网络计算的处理器；箱子则变成模型参数、训练数据和一层层产生的中间结果。

昇腾原生的 openPangu-2.0-Pro，把一个 505B 的 MoE（Mixture of Experts，混合专家）从预训练、后训练一路做到推理部署，会碰上哪些问题？MoE 可以先理解成一支很大的专家团队，每次只让其中一小部分参数参与计算。

图 1｜从“上市公司搬总部”理解 505B 大模型训练

openPangu-2.0-Pro 的看点由此变得具体：公开的不只是一个能在昇腾上运行的模型，还包括从训练到推理的完整链路——系统怎么组织、哪些环节容易出问题，以及团队怎样处理这些问题。

一、先让它干点活，试试水准

拿到一个新模型，与其先出一道算法题，不如直接扔进真实开发任务。开发者平时面对的需求很少是“写一个函数就结束”，更多是一整个项目：页面、状态、数据、工程配置和测试都缠在一起。

第一项测试，是让 openPangu-2.0-Pro 做一个研发项目管理后台 ProjectOps。它既要有 Dashboard 总览页，也要能在 Kanban 看板里拖任务、在 List 列表页里搜索和多条件筛选，还要支持任务详情、编辑和新建。所有改动都得写进浏览器的 localStorage 本地存储，刷新以后不能丢，最后还要适配手机。

图 2｜ProjectOps Dashboard 实测截图

实际结果不仅有一个简洁大方的首屏。组件怎么拆、几处页面怎么共享同一份状态、拖拽以后数据怎么保存，这些都继续往下做了。

最后打开页面时，关键指标（KPI）、趋势图、状态分布、筛选和任务看板已经能互相联动，有了一个产品后台该有的样子。

1. 第一次严格跑 TypeScript 编译时，还是冒出了几处工程尾巴。比如有 import 导入了却没用，个别类型引用没收干净，还有 React Provider 的连接关系没有完全接好。继续修下去以后，业务功能能全部跑通；随后做了 14 项浏览器验收，最后 14/14 通过，浏览器控制台和页面都没有报错。

这两类问题需要分开看：一种是功能本身做不出来，另一种是主体已经完成，但交付前的编译和清理没有收干净。openPangu 这次更接近后者。第一次交付前的工程自检，还可以更稳。

1. 第二项测试换了个方向： 不给它从零写项目，而是丢一个已经能编译、能启动的 React 代码仓库（Repo），只埋三个真实 Bug——组合筛选错误、共享状态不同步、拖拽后刷新会回滚。它不能改工程配置，不能加依赖，也不能针对某个任务 ID 写硬编码。

最后它只改了一个 App.tsx，5 项隐藏回归测试全部通过。 从这个结果看，它已经不只是“从零生成代码”，也能接住现有工程，顺着状态变化往回追，直到找到几个 Bug 背后的共同根因。

图 3｜ProjectOps 的真实 List 页面：搜索、筛选和任务状态来自同一份共享状态

二、再看官方评测：这一代 openPangu 把力气花在哪？

模型效果基本能应对日常开发需求，那么对应的模型整体能力怎么样呢？我们来看官方模型卡公开评测，Thinking 与 Non-Thinking 两种模式在不同任务上的差异，能补上一张更完整的能力侧写。

• 复杂指令：IFEval 94.5；IFBench 79.9。长指令和显式约束得分较高，可以理解为复杂需求能否被完整执行。
• 深度推理：AIME 2026 95.4；GPQA-Diamond 87.9；IMO-AnswerBench 84.3。数学、科学和多步推理是主要强项之一。
• Agent / 工具：TAU2-Bench 81.1；MCP-Atlas 61.3；Claw-Eval 61.7；BrowseComp 65.7。重点考察连续调用工具、读取结果并决定下一步。
• Coding：LiveCodeBench V6 85.7；DeepCodeBench 74.2；SWE-bench Verified 68.5。既覆盖代码生成，也进入真实软件工程任务。

图 4｜官方模型卡公开评测：这一代 openPangu 的能力侧重点

Thinking 并不是所有任务都更高。复杂推理、Agent 和不少代码任务里，Thinking 通常占优，例如 AIME 2026 从 87.3 提高到 95.4，GDPVal 从 51.2 提高到 74.9；Chinese-SimpleQA、PinchBench、FeatBench 里，Non-Thinking 反而持平或更高。

对实际使用来说，这更像两档工作状态：复杂任务值得多花一点推理预算，简单任务直接做，反而可能更合适。

资料来源｜openPangu-2.0-Pro 官方模型卡；技术报告 §5.1。官方表格同时报告 Thinking / Non-Thinking；评测使用 top_p=0.8、temperature=1.0。注：这些成绩来自官方模型卡，不等同于第三方统一条件下的横向评测。

三、从结果往回追：505B 到底怎么在昇腾上“长出来”？

实测回答“能不能做”，官方评测说明“重点练了什么”。再往下，就是这套能力怎样在昇腾上被训练出来，再部署出去。先看四个数字。

参数	怎么理解
505B 总参数	模型总规模是 505B；MoE 结构让它不必每一步都把全部参数激活。
约 18B 激活参数	每处理一个 token，参与计算的参数约 18B。
512K 上下文	原生支持 512K 上下文，面向长文档和长流程 Agent 任务。
约 34T tokens	预训练数据规模约 34T tokens，并按不同阶段使用。

前面提到的 MoE，在这里开始真正影响计算方式。openPangu-2.0-Pro 配置里有 384 个可被动态选择的专家（routed experts）；每处理一个 token，路由器选 8 个参与计算，再加 1 个始终工作的共享专家（shared expert）。所以 505B 是模型的总规模，每一步真正参与计算的参数约 18B。

下面把报告中展现的解决方案拆到每个小节里，一张图对应一个现实难点。

3.1 芯片越多，为什么反而越容易“堵车”？

回到开头那个“上市公司搬总部”的故事。只有 20 个搬家师傅时，大家喊一嗓子还能协调；到了几百人，真正让效率崩掉的往往是电梯、通道和互相等待。

505B 的 MoE 也一样。模型太大，只能拆到很多 NPU 上一起训练。MoE 又天然需要频繁搬数据，不同 token 会被分给不同专家，而专家分散在不同设备上。计算本身再快，如果大量时间耗在网络传输和等别的卡，集群利用率照样上不去。

先从设备怎么连开始。openPangu 模型使用 CloudMatrix 384 这样的昇腾超节点环境，可以把“超节点”理解成一组通过高带宽连接在一起的 NPU。

然后才决定模型怎么切：张量并行（Tensor Parallelism，TP）把一次大矩阵计算拆给多张卡；上下文并行（Context Parallelism，CP）把一条超长序列分给多张卡；专家并行（Expert Parallelism，EP）把 MoE 的不同专家分散到不同设备上。openPangu 尽量让这些频繁交换数据的计算留在超节点内部，减少跨超节点通信。

光把设备放对位置还不够，计算和通信还得尽量同时进行。这种做法叫 compute-communication overlap：当前这部分还在算，下一部分需要的数据已经开始传。连负责更新参数的 Muon 优化器也按这个思路做分布式重叠；MTP（Multi-Token Prediction，多 token 预测）相关的跨阶段传输，则尽量使用更轻的点对点通信。

这正是“昇腾原生”的第一层含义：硬件的连接方式不是部署末端才考虑的细节，而是训练方案的一部分。

图 5｜多卡训练真正的瓶颈：并行规模变大后，通信与调度开始拖慢计算

资料来源｜openPangu-2.0 Tech Report §3.3 Training System Optimization。报告将主要挑战概括为复杂通信、激活内存压力，以及新结构缺少高效 Ascend-native 算子实现。

3.2 512K 上下文，不能每生成一个字都重读整本书

512K 上下文作用很大，意味着可以解决更复杂的问题，但要把它真正跑顺却麻烦得多。

假设你在查一套几十万字的公司档案。每问一个问题都从第一页重新读到最后一页，当然最完整，代价也会非常夸张。更实际的做法是，多数时候先看当前页附近；真的要追半年前的一次决策，再从整套档案里把相关记录找出来。

openPangu-2.0 的注意力设计沿着这个思路做。SWA（Sliding-Window Attention，滑动窗口注意力）负责近处，每层主要看附近 512 个 token；每隔两层再用一层 DSA（DeepSeek Sparse Attention，稀疏注意力）往更长的历史里找关键位置。模型因此按 DSA-SWA-SWA 的顺序重复堆叠：多数时候看近处，需要时再往远处找。

DSA 里还有一个轻量索引器 Lightning Indexer，先替全局层筛一遍。它会从历史 KV 里挑和当前 token 最相关的位置。这里的 KV 是模型为过去 token 保存的注意力信息。这里的典型选择量是 2,048 个 token，因此全局层不用每次都让 50 多万个 token 两两互相“看”。

512K 的难点不只是“内存里塞不塞得下”。每一层到底看多远、哪些历史值得看、这些信息怎么缓存，都会直接影响训练和推理成本。

这个结构也不是从训练最开始就直接换上去。到了 512K 预训练后期，原有 FULL 注意力层才逐步替换为 DSA，SWA 层保持不变。团队先用 8B replay tokens 做 dense warm-up，让 DSA 接住原有 FULL 层的能力；再用 100B tokens 做 sparse adaptation，适应稀疏检索。

图 6｜长上下文注意力：SWA 负责近处，DSA 负责远处

资料来源｜openPangu-2.0 Tech Report §2.1 Attention Architecture、§3.2 Training Details。SWA 窗口为 512，DSA 的 index top-K 为 2,048。

3.3 模型结构一变，芯片下面的软件也得跟着改

这一节最能看出“原生”和“兼容”的差别：结构图画出来只是第一步，更难的是它能不能在 505B、512K 这样的规模上高效运行。

openPangu 里有一个 mHC（Manifold-Constrained Hyper-Connection）结构。传统 Transformer 里的核心信息大体沿一条主路径层层往下传，mHC 把它扩成四路，希望深层网络能同时保留更多不同表示。公式可以先放一边，记住“从一路变成多路”就够了。

路一多，系统马上开始付代价。中间激活值占的内存更多，分阶段并行训练时前后阶段要传更多数据，昇腾里主要负责向量计算的 Vector 单元，工作量也会增加。

openPangu 没把这些代价留给硬件自己扛。有专门的 mHC 去做选择性重计算（selective recomputation）：有些中间结果不一直占着内存，等真正需要时再算一遍；其中一部分重算还会塞进通信空闲时间，尽量不把总训练时间拉长。

再往下就是算子层。AscendC 是给昇腾写高性能算子的开发方式，团队用它给 mHC 等新模块写专门实现，并把原来分散的小操作尽量融合成一次执行，少启动、少搬数据。具体放在哪类计算单元也不一刀切：主要卡在数据搬运的操作更适合 Vector，主要是矩阵计算的则更适合 CUBE。

这有个很直观的例子。ModAttn 模块里有一段 1D 因果卷积，只使用当前位置和之前的信息。按传统方式放到 CUBE 单元上，会产生大量数据转置；改到 Vector 单元，再把反复使用的滚动状态留在片上以后，这个模块的计算时间下降了 79%。

“昇腾原生”在这里已经有了具体含义： 模型结构设计时，就要同时考虑它在昇腾上的高效实现。芯片连接、算子和训练系统从一开始就进入设计，而不是部署末端再补。

图 7｜新结构带来的系统压力：激活、内存、通信与算子必须一起优化

资料来源｜openPangu-2.0 Tech Report §3.3.1（mHC）与 §3.3.5（ModAttn）。

3.4 34T tokens，为什么还要分阶段训练？

如果把大模型训练比成上学，openPangu 不会在第一天就把几十万字的技术文档全塞进去。

整个约 34T tokens 的预训练被拆成三个阶段。

第一阶段用 25T tokens 和 4K 上下文打通通用知识与语言基础；

第二阶段再用 8T tokens，提高 STEM、逻辑和高级代码的比例，上下文拉到 8K。

最后约 1.4T tokens 进入 Annealing，也就是训练后期的精修阶段，这时才进一步加入长文档和复杂 Agent 任务，并把上下文逐步推到 32K、128K 和 512K。

图 8｜34T tokens 的三阶段预训练，以及 512K 后期的 DSA 适配

所以“支持 512K”远不只是把配置里的最大长度改大。模型得真的在训练后期见过越来越长、越来越复杂的任务，数据怎么配、注意力怎么算、训练系统怎么撑住，都要跟着改。

Agent、Reasoning、Code 三类重点数据合称 ARC。除了网页、书籍、PDF、多语言文本、代码仓库、STEM 和工业数据，openPangu 还专门生成并筛选高质量 Agent 轨迹，也就是模型在一个长任务里连续观察、调用工具、读取结果，再决定下一步的完整记录。

资料来源｜openPangu-2.0 Tech Report §3.1 Data Construction、§3.2 Training Details：25T General、8T Reasoning、1.4T Annealing；后者分配 800B/400B/200B token 到 32K/128K/512K。

四、从会回答问题，到会把事情做完

4.1 后训练：先练专项能力，再合回一个模型

预训练让模型见过很多东西，但会答题和会连续做事仍然隔着一段距离。真实 Agent 要先理解目标，再调用工具、读取结果、调整计划，接着往下执行；代码任务也一样，最后要落到程序能不能跑、测试能不能过、错误能不能沿着执行链找回来。

openPangu 的后训练先做 SFT（Supervised Fine-Tuning，监督微调），用高质量示例把基本行为教稳；接着进入 RL（Reinforcement Learning，强化学习），根据任务结果继续更新。其中，Reasoning、General、Agent、Coding 分别训练成四个专项 RL Expert，最后再用 OPD（Multi-Expert On-Policy Distillation，多专家在线策略蒸馏）把这些专项能力合回一个统一模型。

图 9｜后训练路线：统一 SFT → 四类专项 RL → OPD 合回统一模型

拆开的原因在奖励信号本身。普通聊天里很多质量标准偏主观；代码和工具调用却能直接检查，例如工具 JSON 格式合不合法、程序能不能执行、测试能不能通过。把这些差异很大的奖励信号全搅在一起，训练时反而容易互相干扰。

在 Agent 强化学习里，工具调用少参数或格式错会直接扣分，也就是 syntax penalty（语法惩罚）。能真正执行验证的结果，就尽量交给训练循环外部去跑，减少模型钻奖励规则空子的机会，也就是 reward hacking。已经稳定会做的样本，则通过 Online Dynamic Filtering（在线动态过滤）暂时移出训练，让算力继续花在“刚好还不会”的任务上。

Coding RL 还在负责组织任务和工具调用的 agent harness 与推理引擎之间加了一层记录网关，把每次输入、模型输出、生成概率和完整执行轨迹统一留档；旁边再用监控 Agent 盯奖励分布和异常轨迹。

这套训练思路和前面的 ProjectOps / Repo Debug 实测能对应起来。模型处理的并不只是“React 语法会不会”，而是一条执行链：状态改没改，刷新后还在不在，修一个 Bug 会不会顺手把别的功能弄坏。

资料来源｜openPangu-2.0 Tech Report §4.1–§4.3。SFT 数据覆盖 Reasoning、General Chat、Coding、Long-Trajectory Agent；后训练采用多专项 RL + Multi-Expert On-Policy Distillation。

4.2 训推一致：训练时和上线时，不能变成“两个人”

训推一致是模型里技术密度最高的一部分，也直接关系到 Agent RL 的稳定性。

同一个模型，训练时算一次答案，上线时再算一次，理论上应该一样吧？

现实里未必一样。大规模 RL 常常同时用训练引擎和推理引擎，两边各有一套模型实现。为了追求吞吐和延迟，它们还可能采用不同的并行方式、融合算子和计算顺序。到了 MoE，又多了一层专家路由。几百块 NPU 一起算，谁先加、谁后加，一个 token 最后被送到哪个专家，都可能带来很小的数值差异。

普通聊天里，这点差异可能看不出来。RL 却会把刚刚 rollout 出来的结果重新拿回去训练自己。rollout 就是让当前模型真正生成一段答案或完整执行轨迹。细小偏差一次次回到训练里，可能变成噪声，严重时甚至会把训练推向梯度爆炸或发散。

openPangu 用了一组办法去压这个问题，其中一个叫 Rollout Routing Replay（R3）。做法很直观，推理生成 token 时，把当时选中了哪些 MoE 专家记下来；到了训练侧，再尽量按同样的路由重放。

多轮 Agent 任务还多一个麻烦。第一轮新生成的 token，下一轮会重新作为已有上下文做 prefill。prefill 就是在正式逐 token 生成之前，先把眼前这整段上下文一次性算一遍。重新算时，模型可能又把这些 token 分给了不同专家。Cached R3 会把第一次生成时的专家选择缓存起来，训练时继续复用。

图 10｜R3 / Cached R3：让训练尽量复用 rollout 时发生过的专家选择

训练时算出来的东西和推理时不完全一样，也就是 train-inference mismatch——训推不一致。它被拆成三层：模型定义有没有差异、计算图重排带来的浮点误差，以及硬件调度本身的非确定性。最底层甚至会追到 NPU 怎样切分一个大算子、怎样把矩阵计算分片，再按什么顺序把各个核心的结果加回来。对应的关键词是 tiling、SplitK 和 AtomicAdd，但关键只有一个：累加顺序一变，浮点结果也可能跟着发生细小变化。

为了方便理解，我们预览一条更严格的白盒对齐路线。先固定随机采样和通信，把训练与推理每一层的中间张量都导出来，从第一个出现数值分叉的位置往回查。Prefill 侧统一 FlashAttention 这类高效注意力实现；进入逐 token 生成的 Decode 阶段后，则继续下沉到 CANN。CANN 是昇腾计算软件栈的一部分，这里甚至要手工对齐 SplitK 和最终累加顺序。

训推一致的问题会继续下沉到昇腾底层： kernel 怎么切、怎么并行、按什么顺序累加，都可能影响最终数值。排查因此不能只停在 Python 模型代码。

资料来源｜openPangu-2.0 Tech Report §4.4 Resolving Training-Inference Mismatch，尤其 §4.4.1 R3 / Cached R3 与 §4.4.2–4.4.3 的根因分析和全对齐方案预览。

五、训出来之后，怎么让它真的用得起？

训练结束只是第一关。一个 505B 模型如果上线时权重就占一千多 GB，能力再强，服务成本也会非常高。

推理侧第一件很直观的事是量化。openPangu 用 W8A8，意思是权重和激活值都大量改用 8-bit 表示。权重按输出通道做静态量化，激活值则按 token 动态量化。Pro 例子里，权重占用从约 1,009GB 降到 517GB，约 1.95 倍压缩。

但它没有把全模型一刀切成 8-bit。路由器、前面提到的 Indexer、容易积累误差的残差路径，以及量化收益很小的层，会继续保留 BF16（bfloat16，16 位浮点）。这个取舍很实用：省资源不是压得越狠越好，关键是知道哪些地方不能乱动。

低延迟推理里，有些时间甚至不是花在矩阵计算本身，而是花在反复启动小算子、同步和调度上。于是给 SWA 做了 micro-tile mask-skip，让不需要计算的小块直接跳过，单算子性能提升 30% 到 40%。MoE Dispatch，也就是把 token 送给不同专家的过程，则改成一个 token 只读取、只量化一次，再发给多个专家，分发延迟下降 25% 到 30%，端到端最多改善约 5%。

再往系统层，CANN 用静态 kernel 编译和 Superkernel 减少启动次数。Superkernel 可以理解成把多个原本分开的操作尽量合成一次更大的执行。在超低延迟场景里，这部分一共带来 3.2ms 的 TPOT 改善。TPOT（Time Per Output Token）表示平均生成一个新 token 需要多少时间。

最后还有并行和缓存。不同注意力层用不同并行方式，CUBE 和 Vector 两类计算单元尽量多流并发；KV Cache 会复用历史 token 已经算过的注意力信息，前缀缓存则继续复用重复出现的长上下文。前面提到的 3-head MTP 还会多预测后面几个 token，先当作草稿，再由模型自己验证，用来做自投机解码。

openPangu-2.0-Pro 报告了两组不同推理配置下的结果：在 Ascend 910C、128K 长上下文的 ultra-low-latency 配置下，最低 TPOT 为 9.55 ms；另一组以约 20 ms TPOT 为目标的吞吐配置下，生成吞吐为 1,326 tokens/s/NPU。两组数字不是同一 workload，不应绑在一起理解；这里也只把它们作为官方给定条件下的内部结果，不和不同集群、不同服务条件横向硬比。

图 11｜推理侧怎么把 505B 模型的显存、重复计算和等待时间压下来

资料来源｜openPangu-2.0 Tech Report §6 Inference。量化见 §6.1.1；算子、通信与 Graph 优化见 §6.2；并行与 Multi-Stream 见 §6.3。

六、最后回到用户：这些底层细节，和实际使用有什么关系？

把这些底层机制放回我们最初实测的 ProjectOps 项目，就能看出 Agent、Coding、长上下文和 Generative UI 为什么会被放在同一条能力线上。Generative UI 指的是模型不只给文字答案，还能直接生成可以操作的界面。

ProjectOps 并不是一个只看“前端好不好看”的 Demo。它考验的是整条状态链：搜索和筛选是不是同一份数据，任务从 In Progress 拖到 Done 以后 Dashboard 会不会更新，刷新以后状态还在不在，编辑、新建和 Reset 会不会互相打架。

这类任务和长轨迹 Agent 很接近。执行过程一长，模型就得在很多轮工具调用和页面变化之后，仍然记得目标、状态和格式。

第二个 Repo Debug 实验又是另一种工作方式：不给模型重新发明项目的机会，只让它接住已有逻辑，找三个 Bug 的共同根因。最后只改一个文件、隐藏回归全过。这种克制的修改，比从零生成更能说明它有没有理解现有工程。

openPangu-2.0 的评测也在往类似方向走。它的 Deep Research 不只要求最后写出研究文字，Agent 还会调用搜索、代码和前端工具，最终生成带统计图、SVG 矢量图、动画和交互组件的研究网站。报告还展示了从需求直接生成可交互小应用的能力（Full-Stack Mini-App Generation），代表案例包括带路线地图和交互行程的旅行规划器，以及带实时数据管线和动态图表的股票跟踪助手。

这些案例与前面我们的两个实测在任务形态上是一致的：目标都不是只生成一段文字，而是把自然语言需求继续推进到可操作的软件结果。

资料来源｜openPangu-2.0 Tech Report §5.2 Deep Research and Interactive Visualization / Full-Stack Mini-App Generation。

6.1 开源的工程价值：让后来者少走一遍弯路

MoE、长上下文、强化学习、Agent、量化，这些方向今天大家都听过。

成本最高的往往是第一次把这些环节在同一套硬件上全部跑通。

505B 怎么切到昇腾集群，哪种通信最容易堵，512K 怎么撑住，新结构没有高效算子怎么办，RL rollout 为什么会和训练侧算得不一样，8-bit 哪些地方能压、哪些地方最好别动。开源的技术报告最有价值的地方，恰好都落在这些具体问题上。

任何团队如果都从零踩一遍，成本都不会低。

又一个开源模型，更完整的开源答卷。7 月 31 日，openPangu-2.0-Pro 的模型权重、基础推理代码和技术报告正式开源；openPangu 模型，同时希望用昇腾原生训练与推理技术给业界提供实践参考。

除了已经上线的模型权重、基础推理代码和技术报告，Ascend Tribe 当前还能看到 ascend-training-system、openPangu-2.0-Infer、openPangu-2.0-Op、ascend-inference-system、ascend-cluster-infra 等相关项目。它们分别覆盖训练系统、推理源码、自定义算子、推理系统和集群基础设施等环节。

这份开源技术报告留下的，不只是模型结构和指标，还有一条 505B 大模型从训练走到推理的工程路径。 后来者至少能少猜一遍已经被验证过的系统问题。

以后另一支团队也想在昇腾上训练大 MoE，至少不用从零尝试所有问题。重通信怎么围绕超节点组织，长上下文怎么分阶段训练，新结构什么时候需要下沉到 AscendC，训推不一致从哪一层开始查，量化又该在哪些位置保守一点，这些都已经有了可参考的工程答案。

资料来源｜华为官方公告《openPangu-2.0-Pro模型及技术报告正式开源上线》；Ascend Tribe 项目列表。

6.2 回到开头：这份 505B 开源答卷意味着什么？

当然，基础 Coding 和 feature implementation 表现不错，复杂真实的软件工程 workflow 仍有提升空间。在最开始的实测里：主体能力已经够用，第一次交付前的工程自检还可以继续变稳。

但 505B 模型本身并不是这次发布里唯一值得关注的部分。

更值得关注的是系统协同：模型、昇腾芯片、训练系统和推理系统被放在同一条链路里一起设计和优化。

以前聊国产大模型，人们更常问“能力能不能追上”。到了 505B、512K 长上下文、Agent RL 和低延迟推理这个规模，瓶颈会同时出现在芯片、通信、编译器、算子、训练框架和推理框架。任何一层跟不上，模型能力都很难完整落地。

openPangu-2.0-Pro 的开源价值因此不只落在模型权重本身。

一边是 ProjectOps 和 Repo Debug 的实际表现，一边是 505B MoE 从预训练、后训练到推理部署的工程记录。两者合在一起，构成这份完整的“开源答卷”：它把“模型能不能用”和“系统能不能把 505B 能力稳定地训出来、跑起来”放到了同一张答卷上。

过去常问“国产模型能不能追上”；到了 505B、512K 长上下文和 Agent RL 这个规模，更具体的问题是：围绕昇腾算力构建的训推体系，能不能同时把模型能力和工程链路做完整。

从两个实际开发任务，以及官方模型卡公开评测、技术报告里的完整训推链路看，openPangu-2.0-Pro 已经展示出相当完整的模型能力和工程能力。

参考资料

资料	点击访问
模型下载地址	打开链接
模型页 / 在线体验	打开链接
openPangu-2.0 Tech Report（45页）	打开链接
华为官方开源公告	打开链接
Ascend Tribe 开源社区	打开链接
其他模型实践案例	打开链接
AtomGit 文本生成 API 文档	打开链接

---

hello，这里是 晓雨的笔记本 。如果你喜欢我的文章，欢迎三连给我鼓励和支持：👍点赞 📁 关注 💬评论，我会给大家带来更多有用有趣的文章。
原文链接 👉 ，⚡️更新更及时。

欢迎大家点开下面名片，添加好友交流。