华为盘古大模型的演进历程，不仅是一部大模型技术迭代史，而且是一部围绕其 自研昇腾（Ascend）硬件平台，从追赶到探索，逐步构建“软硬一体”战略的产 业发展路径。其发展路径清晰地展示了从最初的参数竞赛，到万亿模型的稀疏化 探索，再到面向行业深度优化的结构化转型，最终全面拥抱为硬件效率而生的混 合专家（Mixture of Experts,MoE）架构。这一过程揭示了华为的 AI 战略核心：模 型的每一次进化，都是为了更紧密地与昇腾硬件协同，旨在构筑其全栈软硬融合 技术体系。
1.1. 盘古大模型系列的起点是 PanGu-α确立基于昇腾与自研框架的技 术路线
华为盘古大模型的征程始于2021年4月，其标志性起点是PanGu-α模型的发布。 这是一个参数规模高达 2000 亿的自回归中文预训练语言模型，其训练语料库是从 近 80TB 原始数据中经过复杂清洗和过滤后提炼出的 1.1TB 高质量中文文本，在 当时引起了业界的广泛关注。PanGu-α的论文明确指出，当时 GPT-3 等模型主要 基于英文且仅提供有限访问，而其目标正是为了推动中文预训练语言模型的公共 研究。它首次完整地向外界展示了华为 AI 的全栈自主技术路线，模型是在一个由 2048 个自研的昇腾 910 AI 处理器组成的集群上，使用自研的 MindSpore 深度学习 框架完成训练的。为了攻克大模型训练的内存和算力挑战，团队基于 MindSpore 框架采用了包括数据并行、算子级模型并行、流水线模型并行在内的五维并行策 略，从而高效地将训练任务扩展至整个集群，为其后续走上“为硬件效率而进行 软件创新”的道路奠定了方向。这种优化不仅体现在系统工程层面，也体现在模 型架构的微创新上，例如论文中提到的在 Transformer 主干网络之上增加一个独特 的“查询层”（Query Layer）以增强模型性能。PanGu-α解决了华为 AI 大模型 “从 0 到 1”的问题，它验证了这条全栈自主路线的技术可行性，成为了后续所 有演进的重要基础。
1.2. PanGu-Σ对稀疏化进行早期尝试，2023 年就向万亿参数发起探索
在 PanGu-α证明了千亿级稠密模型的可行性之后，华为将目光投向了更具挑战性 的万亿参数领域。2023 年 3 月，华为发布了拥有 1.085 万亿参数的 PanGu-Σ模 型，标志着其向更大模型规模和更高效模型架构的探索上又迈进一步。PanGu-Σ 团队认为，单纯增加稠密模型的参数会带来高昂的计算成本，而稀疏化是通往万 亿参数更经济高效的路径。 PanGu-Σ的核心创新在于引入了稀疏化架构。它并非沿用传统的稠密模型设计，而是通过继承式学习（Inheritance Learning）策略，继承了 PanGu-α 13B 版本的 参数，并将其扩展为一个覆盖 40 个不同领域（包括自然语言和编程语言）的稀疏 模型。这一架构的核心是随机路由专家（Random Routed Experts，RRE），它在模 型的上层用多个条件激活的前馈网络（即专家）替代了原有的稠密前馈网络。与 当时主流 MoE 模型采用可学习的门控网络来路由 token 不同，RRE 采用了一种非 学习式的、基于 token ID 和预设映射表的两级随机路由机制。这种设计的背后， 反映了华为在模型设计的早期阶段就注意到了稀疏模型在分布式系统上的核心问 题：负载均衡。随机路由虽然在模型表达能力上可能不如可学习路由，但它通过 随机化和预设映射，天然地避免了部分专家过载而另一部分专家空闲的问题，保 证了训练的稳定性和硬件资源利用率。此外，这种非学习式的路由设计还带来了 一个关键的工程优势：模型可以被灵活地拆解，允许开发者无损地提取出特定领 域的子模型（如代码模型、双语模型）进行独立部署，极大地提升了模型的实用 性和落地效率。
为了支撑这个万亿参数的稀疏模型在一个适度规模的硬件资源上高效训练，华为 同步推出了一套名为专家计算与存储分离（Expert Computation and Storage Separation，ECSS）的系统设计。ECSS 是一种创新的异构计算方案，它将计算密 集型的任务保留在 NPU 上，而将内存消耗巨大的优化器状态等卸载到拥有 750GB 主机内存容量（Host Memory）的主机 CPU（鲲鹏 920 CPU）上进行处理。通过这 种方式，ECSS 有效缓解了单颗昇腾 910 处理器 32GB 高带宽内存（High-Bandwidth Memory，HBM）的瓶颈，使得在仅 512 卡的集群上训练万亿模型成为可能，并实 现了高达 6.3 倍的训练吞吐量提升。 PanGu-Σ的实践，是华为从稠密模型向稀疏模型演进的一次重要尝试。RRE 和 ECSS 的组合，清晰地展示了华为解决大规模的模型挑战的思路：当遇到硬件瓶颈 时，不仅从软件算法层面（RRE）进行创新，也从系统架构层面（ECSS）进行软 硬件协同设计。这标志着其“软硬一体”的战略思想开始从理论走向实践。
1.3. 盘古 3.0 提出“5+N+X”架构，面向多行业进行大模型落地
2023 年 7 月，在华为开发者大会上，盘古大模型 3.0 正式发布，同时提出了一个 战略性口号，“不作诗，只做事”。这一口号的背后，是盘古大模型从通用技术展 示向深度赋能千行百业的战略转型。这一战略以其在一系列行业应用为基础：例 如，盘古气象大模型成为全球首个在精度上超越传统数值预报方法的 AI 模型，其 成果发表于顶级科学期刊《自然》（Nature）；盘古药物分子大模型则成功研发出一 款有望成为全球 40 年来首个新靶点、新类别抗生素的超级抗菌药 Drug X，并将 研发周期从数年缩短至几个月。
盘古 3.0 推出了标志性的“5+N+X”三层架构： L0 层：基础大模型。包含自然语言处理（NLP）、计算机视觉（CV）、多模态、预 测、科学计算五个基础大模型。同时，盘古 3.0 也为用户提供从 100 亿参数到 1， 000 亿参数等五种不同规模的大模型以适应不同行业的多样化需求。L0 层是盘古 能力的基础，为上层应用提供通用的、可组合的 AI 技能。 L1 层：行业大模型。包含 N 个面向特定行业的模型，如政务、金融、制造、矿 山、气象等。这些模型利用行业公开数据和华为在这些领域的相关经验进行训练， 实现了对行业知识的深度理解。 L2 层：场景化模型。包含更多细化场景的模型，更加专注于政务热线、网点助手、 先导药物筛选、传送带异物检测、台风路径预测等具体行业应用或特定业务场景， 为客户提供开箱即用的模型服务。 “5+N+X”架构的核心设计理念是分层解耦。它允许客户与合作伙伴根据自身需 求，灵活地调用任意一层或多层模型的能力，既可以直接使用 L0 和 L1 的通用技 能，也可以在其基础上结合自有数据，快速构建并迭代自己的 L2 场景化模型。这 种架构是华为对大模型商业化路径的判断，华为更聚焦其拥有传统优势的 B 端行 业市场。 这一战略选择，反过来又进一步凸显了其“软硬一体”模式的必要性。行业客户 对 AI 解决方案的要求远比普通消费者苛刻，他们更关心模型及硬件的可靠性、数 据的安全性、部署的成本效益以及长期的技术支持。华为云提供了工业级的解决 方案：在可靠性上，其昇腾 AI 云服务承诺千卡训练 30 天长稳率达到 90%；在数 据安全与合规上，则提供公用云、大模型云专区、混合云等多样化的部署形态， 以满足不同行业客户的严苛标准。通过从芯片、框架到模型的全栈垂直整合和深 度优化，华为为行业客户提供一个性能可预期、安全可控、成本可负担的端到端 解决方案。因此，盘古 3.0 的发布，进一步明确了华为 AI 的商业模式和市场定 位。
1.4. 盘古 5.0 发布、盘古 5.5 全面拥抱 MoE，体现从应用深化到架构升 维的演进
从 2024 到 2025 年，华为盘古大模型的发展呈现出一条从应用场景深化到核心架 构升维的清晰路径。在 2024 年 6 月的开发者大会上，盘古大模型 5.0 的发布标志 着其向千行万业的深度渗透。其核心是“全系列、多模态、强思维”的全面升级， 推出了从十亿级（E 系列）到万亿级（S 系列）的完整模型矩阵，并着重强化了模 型在工业设计、自动驾驶、具身智能等领域的复杂任务规划与工具调用能力。 在此基础上，华为于 2025 年 6 月发布的盘古大模型 5.5，则正式标志着其技术路 线的又一次重要演进，即全面拥抱并深度优化混合专家（MoE）架构。这背后， 是 Pangu Ultra MoE（718B 总参数）和 Pangu Pro MoE（72B 总参数，16B 激活参 数）等一系列技术探索的落地。 这一系列新模型的发布，其核心驱动力是将系统效率和硬件亲和性提升到了新的 高度。与早期的 PanGu-Σ采用的非学习式 RRE 路由不同，新的 MoE 模型采用了 更主流的可学习门控网络，但在路由机制上进行了重要的创新。Pangu Pro MoE 模 型中引入了“分组专家混合”（Mixture of Grouped Experts, MoGE）架构，通过将 专家分组并强制从每个组中激活固定数量的专家，以结构性的方式缓解了传统 MoE 在分布式系统中的负载均衡难题。
Pangu Ultra MoE、Pangu Pro MoE 的关键超参数，如隐层维度、网络深度、专家数 量等，都有通过复杂的系统仿真流程，针对昇腾硬件平台（如 Ascend 910B/C 平 台、新一代昇腾 AI 云服务所基于的 CloudMatrix 超节点 Supernode 架构等）的特 性进行反复迭代和寻优的结果。这表明华为的模型设计理念：在设计之初就将硬 件的性能边界作为核心约束，去寻找一个能在该硬件上运行效率最高的模型架构。 这一演进过程，本质上是华为 AI 战略从“点”的突破，到“面”的拓展，再到“体” 的立体化构建过程。PanGu-α是一个技术单点的突破，解决了“有没有”的问题。 PanGu-Σ和盘古 3.0/5.0 将技术能力拓展到万亿参数和行业应用的广阔平面，解决 了“能不能用”和“用在哪”的问题。而盘古 5.5 所代表的 MoE 系列模型，与新 一代昇腾 AI 云服务的深度结合，则标志着华为正在构建一个软硬件深度融合、自 成体系、闭环优化的 AI 生态。这个生态的效率可以用具体的指标来衡量：例如， Pangu Ultra MoE 论文中披露其在 6000 卡昇腾集群上实现了高达 30.0%的模型算 力利用率（Model Flops Utilization，MFU），并取得了媲美 DeepSeek R1 的性能。 这并非单个模型或单款硬件的贡献，它代表了一种基于全栈整合的系统级能力， 这构成了华为在 AI 领域的一项关键竞争力。
Pangu Pro MoE 与 Pangu Ultra MoE 两大模型背后的创新路径虽然不同但目标一 致，体现其模型设计是为提升昇腾硬件效率而服务的思路。
2.1. Pangu Pro MoE 以架构创新缓解负载不均衡
Pangu Pro MoE 的创新，主要针对一个业界关注的系统性难题。它通过引入全新的 分组专家混合（Mixture of Grouped Experts，MoGE）架构，旨在解决传统 MoE 模型在分布式部署中的效率问题，体现了华为通过重构软件来解决系统问题的思 路。
2.1.1. 专家负载不均衡是分布式系统的一个关键挑战
随着大模型发展进入深水区，通过混合专家（MoE）架构实现模型的稀疏化，已 成为在控制计算成本的同时，继续扩大模型有效参数规模的业界核心趋势。然而， 这一架构在带来巨大收益的同时，也引入了一个系统性问题，即专家负载不均衡 （Expert Load Imbalance）。问题的根源在于传统 MoE 模型广泛采用的 Top-K 路 由机制。 该机制会为每个 token 计算其与所有专家的亲和度分数，然后选择分数最高的 K 个专家进行激活。然而，这个选择过程是自由的，它不关心这些被选中的专家物 理上部署在哪些计算设备上。在实际的大规模部署中，为了容纳海量的专家参数， 通常需要将专家分布在成百上千个 NPU 上。此时，Top-K 路由的自由选择就可能 导致严重的后果：对于一个 batch 的 tokens，被激活的专家可能偶然地集中在少数 几个 NPU 上，导致这些 NPU 计算负载急剧飙升，而其他 NPU 则因其上的专家未 被选中而处于空闲或低利用率状态。
2.1.2. MoGE 以分组专家混合架构实现确定的负载均衡
面对传统 MoE 架构的固有缺陷，业界通常采用引入辅助损失函数（Auxiliary Load Balancing Loss）等软约束方法来尝试缓解负载不均衡。这种方法通过在总损失中 增加一个惩罚项，来鼓励路由器将 token 更均匀地分配给所有专家。然而，这种方 法通常作为一种缓解手段，但较难完全消除该问题。 华为的 Pangu Pro MoE 则提出了一种结构性的解决方案，分组专家混合（MoGE） 架构。MoGE 的核心思想是，不再试图通过惩罚来引导路由器的行为，而是通过 结构性设计来消除设备间负载不均衡的可能性。MoGE 架构的实现主要包含两个 关键机制： 1) 专家分组（Expert Partitioning）：将模型中全部的 N 个专家，在设计阶段就 确定性地、不重叠地划分为 M 个组。每个组包含?? = ?/? 个专家。最关键 的一步是，这 M 个组与 M 个计算设备（如 NPU）进行一对一的绑定，即每 个设备承载一个完整的专家组。 2) 组内均衡路由（Group-Balanced Routing）：路由机制被重新设计。对于每个 输入的 token，路由过程分为两步。首先，像传统 MoE 一样，计算该 token 与 所有 N 个专家的初始亲和度分数，并进行全局???????归一化。然后，路由 机制不再是全局选择 Top-K，而是在每个专家组内部，根据组内的亲和度分数， 选择分数最高的? ′个专家。如果总共需要激活 K 个专家，那么? ′ = ?/?。
Pangu Pro MoE 的架构设计本身就为解决这个问题提供了一种针对性的方案。模 型拥有 64 个路由专家，并且设计为每个 token 激活 8 个专家（K=8）。当模型被部 署在一个由 8 个 NPU 组成的、与激活专家数（K=8）相匹配的系统上时，MoGE 的组内均衡路由机制便能发挥出有效地运行。届时，64 个专家会被均匀地划分为 8 个组，每个组 8 个专家，而路由机制将从每个组（每个设备）中精确地选择 1 个 （? ′ = ?/? = 8/8 = 1）亲和度最高的专家。如此一来，对于任何一个 token， 每个设备上都有且仅有 1 个专家被激活，从而在硬件层面实现了理论上的计算负 载均衡，其理论上的不均衡分数恒为 0。 MoGE 架构为了硬件效率而对软件架构进行结构性调整的思路，其背后需要相应 的系统仿真与协同设计能力作为支撑。Pangu Pro MoE 的最终架构（如 5120 的隐 层维度、48 层网络深度）是面向昇腾 NPU 硬件特性深度优化的结果。技术报告 指出，团队采用了一种分层策略，并利用算子级模拟器，在一个广泛的架构设计 空间中对大量候选模型进行了性能仿真。该模拟器综合考量了 TFLOPS、内存访 问带宽、互联拓扑等硬件参数，最终迭代寻优出在昇腾 300I Duo 和 800I A2 平台 上性能最优的配置。MoGE 牺牲了一定的路由灵活性（token 无法从全局 64 个专 家中自由选择最优的 8 个），但换来了在分布式系统上高度可预测的运行效率。这 种设计思路体现了拥有全栈技术能力的公司在软硬件协同方面的一种可行选择。
2.1.3. Pangu Pro MoE 通过贯穿训练和推理的定制，旨在充分发挥昇腾硬件的性能
为了将 MoGE 架构的理论优势无损地转化为真实的运行效率，Pangu Pro MoE 的 开发者们进一步围绕昇腾平台的硬件特性，进行了多方面的深度定制。这种定制 贯穿了从训练到推理的全生命周期，针对训练阶段的吞吐量与稳定性和推理阶段 的低延迟与高效率这两大核心目标，分别进行了针对性的协同优化与深度重构。 在训练侧，这种协同优化体现为对吞吐量和稳定性的高度关注。通用的普适性并 行方案，往往难以完美适配特定硬件的拓扑结构。Pangu Pro MoE 的训练系统则处 处体现了对昇腾硬件平台的精细权衡。 1) 为流水线均衡而进行的架构微调。为了在训练中采用 PP=5（流水线并行度为 5）与 VPP=5（虚拟流水线为 5）的并行策略，团队进行了一项架构调整。由 于模型原有的 48 个 Transformer 层无法被 5 整除，这会导致流水线阶段存在 负载不均和硬件空闲。为此，开发者为模型额外增加了 2 个无操作（no-op） 的空层，使总层数达到 50 层。这样，每个虚拟流水线阶段便能均匀地划分这 50 层，从而实现了更为均衡的流水线负载，避免了不必要的硬件等待，提升 了整体吞吐量。 2) 为通信开销定制的并行策略。在专家并行（Expert Parallelism，EP）策略上， 训练阶段采用了 EP=2 的配置。根据技术报告，这一选择是经过系统性分析后， 为了在昇腾集群内存容量允许的前提下，最小化分层式 EP All-to-All 通信的开 销而做出的特定优化。这与其在推理时为追求高并行度而采用 EP=4 的策略不 同，体现了针对训练和推理不同阶段负载特性的精细化定制。 3) 系统级的有针对性的协同优化，带来了一种加速作用。由于模型尺寸和并行 配置已为昇腾平台高度优化，训练过程中累积的激活值内存占用显著降低。这 使得训练过程不再需要依赖此前为更大模型设计的、更复杂的内存优化技术 （如细粒度重计算和张量交换），从而消除了这些技术本身带来的额外开销， 进一步加速了训练。
这一系列针对昇腾平台特性进行的深度定制，最终使得 Pangu Pro MoE 的模型 FLOPs 利用率（MFU）相对基线提升了 35%，显著提高了训练效率。 在推理侧，这种定制化则表现得更为深入，覆盖了从宏观并行策略到微观算子内 核的多个层面。 层级与混合并行（Hierarchical & Hybrid Parallelism，H² P）策略的设计，体现 了对昇腾硬件物理形态的精确适配。它并非一套单一的并行方案，而是为模型中 不同模块量身定制的混合策略集： 1) 针对注意力（Attention）模块，团队采用了 DP2+TP4（数据并行度 2，张量 并行度 4）的混合并行策略。这一决策的背后，是对昇腾 300I Duo 推理芯片 一个 CPU 控制四张 NPU 这一物理架构的直接响应，其核心目标是最小化跨 CPU 的通信开销。 2) 针对专家（Expert）模块，则采用了 TP2+EP4（张量并行度 2，专家并行度 4）的组合。这是一种权衡，单纯的专家并行（Expert Parallelism，EP）会导致 负载不均，而单纯的张量并行（Tensor Parallelism，TP）又可能因切分过细而 导致计算效率下降。TP2+EP4 的混合模式，正是在计算效率与负载均衡之间 寻找到的平衡点。 这种策略，将通信算子 AllReduce 重构为 Reduce-Scatter 与 AllGather 的组合，最 终直接将该环节的通信数据量减少了 50%。
为解决 MoE 模型独特的量化挑战，团队提出了专家感知量化方法（Expert-Aware Quantization）。该方法通过其平滑聚合策略来抑制激活异常值，并以双目标校准 过程来保证路由的稳定性。这一系列创新使得模型在 W8A8 量化下，在 MATH500 等多个关键基准上实现了精度损失低于 1%的近乎无损效果。 为了优化底层性能，团队为昇腾平台专门重构了两个关键的融合算子： 1) MulAttention：该算子针对注意力计算中 KV 缓存的访存瓶颈，通过大包 KV 传输、双循环流水线等一系列为昇腾硬件深度设计的优化，最终实现了端到端 注意力计算 4.5 倍的性能提升。 2) SwiftGMM：该技术针对 GMM（GroupMatmu，分组矩阵乘法）算子在高并发 场景下的高延迟问题。通过引入动态切片缓存和执行模式选择，使算子性能逼 近了由硬件带宽决定的理论上限。 这种贯穿训练与推理的定制方案，最终转化为 Pangu Pro MoE 在真实推理场景中 可量化的性能数据。在 Prefill 阶段，由于其等效于 16B 稠密模型的稀疏激活模式， 使其在昇腾 800I A2 硬件上的输入吞吐量比同系列的 72B 和 32B 稠密模型分别高 出 203%和 42%。在 Decode 阶段，模型实现了平均每卡 1148 tokens/s 的输出吞 吐量，在使用多令牌预测（Multi-Token Prediction，MTP）优化后，更可进一步提 升至 1528 tokens/s。
MoGE 架构带来的高运行效率，与贯穿训练和推理的全流程深度定制，共同构成 了 Pangu Pro MoE 的技术基础。这使得华为有能力在其上执行一个规模较大、设 计有针对性的训练流程，最终让 Pangu Pro MoE 具备了在多个基准测试中取得较 好表现的能力。这清晰地证明，其架构与系统层面的创新，最终都统一服务于“在 昇腾平台上高效地打造并运行一个有一定竞争力的模型”这一核心目标。
2.2. Pangu Ultra MoE 以系统级寻优策略探索软硬协同路径
Pangu Ultra MoE 的设计过程，体现了一种为充分发挥硬件潜能而设计软件的协同 理念。其模型架构、训练策略及系统优化，在设计中均考虑了昇腾硬件的特性， 是软硬一体理念在实践中的一个典型案例。
2.2.1. Pangu Ultra MoE 采用仿真先行的设计方法进行架构寻优
Pangu Ultra MoE 的关键超参数，如隐层维度、网络层数、专家数量等，并非基 于业界经验或对标竞品而设定，而是通过一个以硬件仿真为核心的、复杂的架构 搜索流程，为昇腾硬件平台针对性设计的结果。 这一流程的核心是华为自研的、能够高度模拟昇腾硬件集群行为的系统仿真平台。 该平台采用自底向上的工作流，能够精确预测不同模型架构在特定并行策略和硬件配置下的端到端性能，其仿真过程涵盖了从单个算子在昇腾 NPU 上的性能，到 整个模型的并行依赖、计算与通信重叠，并考虑了昇腾芯片的峰值算力、内存带 宽、互联拓扑等物理参数。 Pangu Ultra MoE 的架构确定，严格遵循了仿真先行的方法论，分为四个阶段： 1) 确定 MoE 模块设计：首先通过在小规模模型上的真实训练实验，确定了 MoE 模块的基本设计，如采用 256 个专家和共享专家架构能获得较好的性能与效 率平衡。 2) 定义架构搜索空间：在约 7000 亿总参数的约束下，结合业界关于模型深度与 宽度的经验公式，定义了一个包含约 10,000 个候选模型配置的巨大搜索空间。 3) 仿真驱动的架构搜索：利用仿真平台对这上万个候选配置进行评估，分析它们 在昇腾 910B 集群上的训练和推理吞吐量。根据仿真结果，模型 7（61 层， 7680 隐层大小，256 个路由专家）在训练和推理性能上得分均高于其他所有 候选者，因此被选为 Pangu Ultra MoE 的最终架构。 4) 验证仿真准确性：为了确保仿真结果的可靠性，团队通过真实训练进行了双重 验证。首先，在一个 4.2B 参数的预备实验中，仿真与真实的吻合度已达到 88.9%。在 718B 参数的 Pangu Ultra MoE 正式训练完成后，团队再以仿真模 型进行复盘，其预测时长与真实训练时长的吻合度高达 90.1%。这种贯穿预 备阶段到正式阶段的多方面的验证，表明该仿真方法具有一定的可信度。 这种设计方法论的转变，标志着华为现阶段的模型设计理念是在设计之初就将硬 件性能作为核心约束，去寻找一个能在该硬件上运行效率较好的模型架构。
2.2.2. Pangu Ultra MoE 采用定制训练策略以提升模型性能
软硬一体的理念不仅体现在架构的初始设计，而且贯穿于训练策略的决策中。 Pangu Ultra MoE 团队并没有照搬业界对 MoE 模型的通用训练方法，而是通过细 致的实验分析，做出了两项以优先保障最终模型性能为目标的决策。 1) 坚持 Dropless 路由，拒绝为训练效率牺牲模型精度。业界为解决专家负载不均衡，普遍采用 Drop-and-Pad 策略，即为每个专家设定容量上限，丢弃超出 容量的 token。这种方法虽能提升训练吞吐量，但代价是信息损失。Pangu Ultra MoE 团队的分析发现，这种信息损失会随模型规模扩大而恶化。在相同设置 下，一个 20B 模型的 token 丢弃率约为 6%，而 718B 的 Pangu Ultra MoE 则会 上升至 8%。基于性能优先的原则，Pangu Ultra MoE 选择了 Dropless，即不丢 弃 token 的训练方式，将负载均衡的挑战交由后续的系统优化来解决，以避免 对模型能力产生影响。 2) 采用 EP-Group 辅助损失，寻求性能与效率的最佳平衡。在 Dropless 的前提 下，模型仍需通过辅助损失函数来引导负载均衡。团队对比了在不同粒度上计 算该损失的效果。实验证明，在拥有数千个 NPU 的大规模集群中，计算范围 过小（如微批次）会施加过强的正则化约束，损害模型性能；而计算范围过大 （如数据并行组）虽对模型最友好，但通信开销巨大。最终，Pangu Ultra MoE 采用了在专家并行（Expert Parallelism，EP）组内进行计算的 EP-Group 辅助 损失方案，在通信开销和正则化强度之间寻求平衡。
2.2.3. Pangu Ultra MoE 通过并行、通信与内存的深度协同实现系统级训练优化
选择了 Dropless 这条对模型更优但对系统挑战更大的道路后，Pangu Ultra MoE 的 成功便高度依赖于系统层面的优化。华为工程师们为此开发了一系列与昇腾硬件 深度协同的系统级解决方案。
1) 并行策略设计与负载均衡：系统优化的基础在于并行策略的选择。根据仿真平 台的评估结果，Pangu Ultra 采用了一套多维并行组合：TP=8（张量并行），EP=4 （专家并行），PP=16（流水线并行）与 VPP=2（虚拟流水线并行）。在此并行 策略下，团队还对特定层的负载进行了精细化调整。例如，MTP（多令牌预测） 层的计算量约为普通 MoE 层的 2.5 倍，会造成流水线负载不均。为解决此问 题，其不同组件（Body 和 Output Head）被拆分并放置到两个不同的流水线阶 段（Stage 14 和 15）上，从而实现了更优的流水线负载均衡。
2) 分层专家并行通信（Hierarchical EP All-to-All Communication）：该策略是针 对昇腾集群网络拓扑的特定优化。传统 MoE 训练采用的 All-to-All 通信原语， 并未区分带宽极高的节点内通信与带宽相对较低的节点间通信。华为提出的 分层通信策略，将一次 All-to-All 分解为两步：首先进行一次通信量较小的节 点间 AllGather，然后在各个节点内部进行高效的节点内 All-to-All。这种设计 将绝大部分通信量约束在了节点内部的高速网络上，有助于降低对跨节点带 宽的压力。
3) 自适应流水线重叠（Adaptive Pipe Overlap）：仅仅优化通信路径是不够的， 为进一步隐藏通信的等待时间，团队进一步开发了核心的自适应流水线重叠技术。该机制打破了传统训练中前向、后向计算的固定壁垒， 将所有操作（如计算、通信、重计算）视为可灵活调度的独立任务流。通过编 排一个微批次（micro-batch）的后向计算（绿色）与下一个微批次的前向计算 （黄色），并穿插必要的重计算（蓝色）与通信任务，Pangu Ultra MoE 显著减 少了硬件空闲情况。这种调度优化，最终实现了高达 95%的通信重叠率 （Communication Overlap Rate），硬件利用率也得到了大幅提升。
4) 为昇腾 NPU 定制的精细化内存管理：为在昇腾 NPU 有限的 HBM 内存中容 纳庞大的模型参数与激活值，训练框架没有采用对整个 Transformer 层进行重 计 算 的 粗 放 式 策 略 。 取 而 代 之 的 是 细粒度重计算（ Fine-Grained Recomputation）和张量交换（Tensor Swapping）技术。这些技术能够精确识 别出模型中激活值占用内存最大、但重计算开销相对较小的部分（如 Permute 算子），只对这些部分进行选择性重计算或临时交换到主机内存，在内存节省 和计算开销之间取得了更优的平衡。Pangu Ultra 软硬协同的理念同时深入到 最底层的硬件内核，为适配昇腾 DaVinci 架构核心计算单元 16x16 的矩阵运 算模式，模型所有关键张量尺寸均被设计为 256 的倍数，有助于实现高效的 硬件计算效率。
2.2.4. Pangu Ultra MoE 多方面的协同优化提升训练效率与模型性能
在训练效率上，Pangu Ultra MoE 在 6000 张昇腾 910B NPU 的集群上，最终实现 了 30.0%的模型算力利用率（MFU）。这一成果并非单一技术所致，而是多项系 统优化累加的结果。相较于基线（Baseline），Pangu Ultra 整体 MFU 实现了 58.7% 的相对提升，这正是由细粒度重计算与张量交换、自适应流水线重叠、主机优化 和融合算子等一系列为昇腾平台深度定制的策略共同贡献的。
在模型能力上，高效的训练过程为模型最终的性能表现奠定了基础。如图 13 所 示，在多个公认的基准测试中，Pangu Ultra MoE 展现了具有竞争力的性能，尤其 在需要深度推理的专业领域取得了一定的表现。
盘古大模型系列在软件层面的创新，有赖于底层 AI 基础设施的坚实支撑。为此， 华为构建了新一代 AI 基础设施 CloudMatrix。其定位不仅是支撑盘古等自研模型 高性能运行的核心物理底座，同时也是面向产业的开放推理平台，旨在通过软硬 件协同设计，高效承载包括业界主流模型在内的各类大模型任务。
3.1. 大语言模型对 AI 基础设施提出四大全新挑战
随着 MoE 模型参数规模和上下文长度的快速增长，传统数据中心在支撑大模型推 理时，正面临四大系统级挑战。CloudMatrix 及其推理系统 CloudMatrix-Infer 的每 一项核心设计，旨在应对上述一个或多个挑战。 1) 通信密集型并行的扩展难题（Scaling Communication-Intensive Parallelism）： MoE 模型的专家并行（EP）等策略，需要在数百乃至数千个计算节点间进行 频繁、细粒度的 All-to-All 通信。传统集群的网络拓扑和带宽难以高效支撑这 种通信模式的规模化扩展，导致跨节点通信成为核心瓶颈。 2) 异构 AI 工作负载下的高利用率维持难题（Maintaining High Utilization under Heterogeneous AI Workloads）：大模型推理包含计算密集型的 Prefill 和访存 密集型的 Decode 等多个阶段，对硬件资源的需求动态且异构。传统服务器的 固定硬件配比无法灵活适应这些变化，常常导致部分资源（如 CPU 或 NPU） 的闲置与浪费。 3) AI 与数据密集型工作负载的融合执行难题（Enabling Converged Execution of AI and Data-Intensive Workloads）：现代 AI 应用（如 Retrieval-Augmented Generation，RAG）要求推理任务与数据检索、预处理等数据密集型任务进行 融合。传统架构中分离的计算与存储系统，难以满足这种融合场景下的高吞吐 与低延迟需求。 4) 提供内存级存储性能的难题（Delivering Memory-class Storage Performance）： 巨大的 KV 缓存是当前大模型推理的核心瓶颈之一。传统架构受限于节点间的带宽和延迟，难以构建一个能提供类似本地内存访问性能的、大规模、分布 式的缓存池，极大地限制了推理效率和并发能力。
3.2. CloudMatrix-Infer 通过软硬件协同设计为承载 SOTA 级模型而生
为了验证 CloudMatrix 平台的真实能力与开放性，华为并非仅用自家的盘古系列 模型进行测试，也选择了有代表性的、被广泛应用且完全开源的第三方模型，拥 有 671B 参数的 DeepSeek-R1，作为其推理系统 CloudMatrix-Infer 的优化与评测对 象。这不仅致力于优化自身模型的使用体验，更意图将 CloudMatrix 打造为一个 能够高效承载业界主流 SOTA 模型的开放基础设施平台。为此，CloudMatrixInfer 在架构、并行策略和算子层面进行了深入的软硬件协同设计，旨在为各类 SOTA 级模型提供一个高效率的运行环境。
3.2.1. CloudMatrix-Infer 采用 PDC 解耦的 Peer-to-Peer 对等服务架构
CloudMatrix-Infer 的核心架构创新在于其 Peer-to-Peer 对等服务架构 (Peer-toPeer Serving Architecture)。该架构旨在将 LLM 推理所需的所有硬件资源（NPU、 CPU、内存）视为一个统一、可自由调度的资源池，系统中的任何计算任务都可 以对等地（Peer-to-Peer）访问所需资源，不受物理位置的限制。这与传统的以 KV 缓存为中心（KV Cache-centric）的架构形成对比，后者的调度逻辑与 KV 缓存的 物理位置紧密绑定，导致了复杂的调度和资源孤岛问题，并非真正意义上的对等 架构。 为了实现这一理念，CloudMatrix-Infer 采用了 Prefill-Decode-Caching（PDC）解耦 的设计。该设计将 LLM 推理的三个核心阶段解耦，并将其部署在三个独立的、可 弹性伸缩的“对等”硬件资源池中： 1) Prefill 集群（Prefill Cluster）：一个专用于处理输入提示词的 NPU 资源池。其 核心任务是完整处理用户查询或上下文中的全部 token，以生成第一个输出 token，并构建初始的 KV 缓存。这是推理流程中计算量最密集的部分。 2) Decode 集群（Decode Cluster）：一个独立的 NPU 资源池，其职责是自回归地 生成后续 Token。在此过程中，它会持续消费和更新 KV 缓存，直到生成序列 结束符（End-of-Sequence Token）或达到预设的输出长度上限为止。这个阶段 通常是内存带宽敏感的。 3) Caching 集群（Caching Cluster）：一个基于统一总线（UB）网络连接的缓存 层，构建于一个解耦的共享内存池之上。它为整个推理流程提供两种关键的缓存服务：上下文缓存（Context Caching）：通过复用历史 KV 缓存，来加速 Prefill 阶段的处理过程，避免对相同前缀内容的重复计算。模型缓存（Model Caching)：用于缓存模型权重分块，从而加快模型的加载和动态切换速度，显 著降低服务的冷启动（cold-start）延迟。
这种分层分离的设计之所以能在 CloudMatrix384 上高效运行，其关键的硬件基础 在于统一总线（Unified Bus，UB）网络。UB 网络构建了一个覆盖整个超节点的、 统一寻址的高速互联平面，极大地缩小了跨节点与节点内内存访问的性能差异。 在此硬件之上，名为弹性内存服务（Elastic Memory Service，EMS）的分布式软件 系统将所有节点的 CPU-DRAM 聚合成一个逻辑统一的内存池，为上层提供高性 能的缓存服务。 PDC 分离架构是 Peer-to-Peer 理念在大语言模型推理场景下的具体实现，它将功 能解耦（软件设计）与底层硬件能力（UB 网络与 EMS）深度结合，从而解决了 传统架构的固有瓶颈，体现了其软硬一体的设计思路。
3.2.2. 大规模专家并行（LEP）将通信成本转化为性能收益
为了在 MoE 模型的解码阶段实现低延迟，一种有效的方法是采用高程度的专家并 行（Expert Parallelism）。理想情况下，每个专家独占一个计算核心，以避免任何 串行等待。CloudMatrix-Infer 正是采用了这种大规模专家并行（Large-scale Expert Parallelism，LEP）策略，在解码拥有 256 个专家的 DeepSeek-R1 模型时，部署了 高达 EP320 的并行度，即每个 NPU Die 只承载一个专家。 这种高并行策略在传统集群上通常难以实施，因为它会产生巨大的通信开销（即 “通信风暴”现象），可能导致系统性能不升反降。然而，在 CloudMatrix384 上， 这一策略却变得可行且高效。其核心思路在于，华为依托自身硬件能力，主动调 整了系统优化中的成本函数。UB 网络具备超高带宽与全互联架构，能够有效吸收 LEP 带来的高通信负载，将通信延迟稳定控制在可接受范围内，从而避免其成为 系统瓶颈。在此基础上，CloudMatrix-Infer 得以在硬件可承受的通信成本范围内， 进一步提升软件层的并行度并压缩解码延迟，形成一种以硬件特性为前提的非对 称优化策略。
3.2.3. AIV-Direct 通信机制的应用实现算子级深度融合
CloudMatrix-Infer 与昇腾的协同设计，也体现在芯片的微观架构层面。这集中体 现在其为 MoE 解码设计的 FusedDispatch 和 FusedCombine 等融合通信算子上，其 核心在于利用了一项名为 AIV-Direct 的底层通信机制。 传统的 NPU 间通信，通常依赖专门的系统直接内存访问（SDMA）引擎。如图 16 所示，红线代表的 SDMA 路径，需要将数据从 NPU 内存搬运至 SDMA 引擎，再 通过 UB 网络传输至远程 NPU，整个过程虽然能处理大宗数据，但其启动和调度 会带来固定的开销，在解码这种需要频繁进行小数据量通信的场景中，容易成为 延迟瓶颈。 AIV-Direct 则提供了一条更高效的路径。如图 16 中的蓝线所示，它允许昇腾 NPU 内部的 AI Vector（AIV）核心（一个原本负责计算的单元）直接绕过 SDMA 引擎， 通过 UB 网络将数据直接写入到远程 NPU 的内存中。这种设计，将通信延迟的固 定开销从“启动一个专用硬件引擎”的宏观级别，降低到了接近“执行一条计算 指令”的微观级别，提升了小包通信的效率。 FusedDispatch和FusedCombine算子正是基于AIV-Direct机制构建的。它们将token 的量化、打包、远程地址计算、直接写入以及状态同步等一系列复杂的计算和通 信操作，无缝地融合在同一个算子内部，并通过流水线设计，来隐藏延迟。软件 （算子）的设计已经深入到硬件（NPU）的特定计算单元（AIV 核心）的指令集 层面，两者之间实现了深度协同，体现了华为软硬一体的设计理念。
3.2.4. CloudMatrix-Infer 针对 DeepSeek-R1 架构特性做出多方面优化
CloudMatrix-Infer 还针对 DeepSeek-R1 模型独特的架构特性，从多个维度进行了 深度优化，以求最大化发挥硬件潜能。 1) 多头隐式注意力（MLA）优化：DeepSeek 模型采用 MLA 来降低 KV 缓存的 显存占用。CloudMatrix-Infer 针对其计算模式进行了算子级优化，将其中大量 零散的计算操作（如 RMSNorm、线性投射、RoPE 等）聚合成 MLAProlog 和 FusedAttention 等大的融合算子，大幅减少了内核启动开销。同时，通过将 KV 缓存直接以昇腾 NPU 核心计算所需的 NZ 格式进行存储，避免了耗时的格式 转换操作，提升了内存访问效率。 2) 多 Token 预测（MTP）支持与流水线优化：MTP 作为一种投机解码（Speculative Decoding）技术，能有效提升吞吐量，但其原生实现会频繁打断 CPU-NPU 间 的执行流水线。为解决此问题，CloudMatrix-Infer 实现了免 CPU 干扰（CPUFree）的 NPU 侧采样，并将 MTP 所需的元数据在计算开始前聚合初始化，从 而消除了不必要的同步等待，保证了计算图在 NPU 上连续、不间断地执行。 3) Prefill 阶段的混合并行策略：LLM 推理的 Prefill（预填充）阶段，不同请求的 输入序列长度差异巨大，若采用单纯的数据并行会导致严重的负载不均衡。为 此，CloudMatrix-Infer 创新性地采用了序列并行(SP)-张量并行(TP)-序列并行 (SP)的混合并行策略。该策略通过先将不同请求的序列拼接再切分的方式，保 证了无论原始输入长度如何，每个 NPU 所处理的 Token 数量都基本一致，从 而极大地提升了 Prefill 阶段的硬件利用率和整体吞吐量。 4) INT8 量化方案：为了在不牺牲模型精度的前提下获得极致的推理性能， CloudMatrix-Infer为DeepSeek模型设计并实现了一套完整的INT8量化方案。 该方案采用混合精度策略，对计算密集型算子（如矩阵乘）进行 8 比特量化， 而对精度敏感的算子保留更高精度，从而在保证准确率的同时，实现了数倍的 性能提升。
3.2.5. CloudMatrix-infer 交出高吞吐量和高效率的推理表现
上述从宏观架构到微观算子的深度协同设计，最终转化为 CloudMatrix-Infer 在运 行 DeepSeek-R1 模型时可量化的、具有竞争力的推理性能。 在 Prefill 阶段，CloudMatrix-Infer 在理想负载均衡下可实现每 NPU 6,688 tokens/s 的吞吐量，其硬件效率（4.45 tokens/s/TFLOPS）高于业界主流框架 SGLang 在 NVIDIA H100 上的表现（3.75 tokens/s/TFLOPS）。这一单位算力推理效率指标， 类似于训练中的模型算力利用率（MFU），旨在剥离不同硬件峰值算力的差异，更 纯粹地衡量软件栈与系统架构对硬件潜力的挖掘深度。在这一效率指标下， CloudMatrix-Infer 展现了其在软硬件协同优化上的优势。 在 Decode 阶段，系统在维持低于 50ms 时延目标的同时，达到了每 NPU 1,943 tokens/s 的吞吐量，硬件效率（1.29 tokens/s/TFLOPS）也高于 SGLang on H100（1.10 tokens/s/TFLOPS）和 DeepSeek 官方在 H800 上的表现（1.17 tokens/s/TFLOPS）。 在严苛延迟约束下，CloudMatrix-Infer 展现了动态调整能力，在低于 15ms 的延迟 要求下，依然能维持每 NPU 538 tokens/s 的有效吞吐量。 这些数据表明，华为 CloudMatrix 平台所构建的软硬件协同体系，不仅能为自家模 型提供优化，也具备了高效承载和运行业界其他 SOTA 级模型的能力，为其“开 放的 AI 基础设施”的定位提供了技术基础。
3.3. CloudMatrix 硬件设计为上层创新提供物理基础
CloudMatrix-Infer 在软件层面的架构创新，建立在华为在硬件层面的底层重构智商。其物理底座 CloudMatrix 硬件集群，通过超节点理念整合大规模计算资源，借 助统一总线（UB）网络显著降低了跨节点的通信延迟，并依靠昇腾 910C NPU 的 异构计算核心，为 CANN 软件栈实现底层深度优化提供了物理抓手。
3.3.1. 超节点的物理构成与设计理念
CloudMatrix384 并非一个简单的服务器集合，而是在设计上被视为单一计算实体 的 AI 集群。它在物理上集成了 384 个昇腾 910C NPU 和 192 个鲲鹏 CPU，其设 计目标是实现这些物理组件间的“资源池化、平等对待、自由组合”。 这个超节点并非松散堆叠的结构，其基本构件是 48 个高度集成的“昇腾 910C 节 点”（Ascend 910C Node）。每个节点内部集成了 8 个昇腾 910C NPU、4 个鲲鹏 CPU 和 7 个板载 UB 交换芯片。这种模块化设计在提供大规模计算能力的同时， 也具备良好的扩展性和可维护性，使得整体架构在工程上实现落地，并具备实际 部署与运维的可行性。 超节点理念的本质，是将一个物理上分布式的集群，在逻辑上抽象成一个拥有超 大规模、统一寻址空间的计算平台。这种架构简化了上层分布式软件的设计复杂 性，开发者无需过多关注跨节点的数据局部性、通信拓扑和资源分配问题，因为 硬件层面提供了一个相对平坦的资源池。这个超节点的设计，为 CloudMatrix-Infer 的 PDC 分离架构和 EMS 统一缓存池的实现奠定了基础。它通过全互联网络应对 了通信密集型并行的扩展难题；通过资源池化应对了异构负载下的高利用率维持 难题；并通过统一的内存访问，为解决融合执行与内存级存储性能的难题奠定了 物理基础。
3.3.2. 统一总线（UB）网络实现节点间通信的高性能
实现超节点理念的关键技术之一，是华为在互联技术上的创新，统一总线（Unified Bus, UB）网络。它是一个为 CloudMatrix 设计的超高带宽、低延迟的互联系统。 UB 网络以全互联（all-to-all）、非阻塞（non-blocking）的方式，将超节点内的所 有 NPU 和 CPU 连接在一起，构成一个统一的通信域。其最关键的特性，是在工 程上显著缩小了节点内（intra-node）和跨节点（inter-node）通信的性能差异。 这一性能表现，源于其物理拓扑设计。UB 网络通过一个两级交换（Two-tier Switching）架构来实现其“非阻塞”特性：第一级（L1）交换由每个计算节点板载的 UB 交换机组成，负责节点内部的高效数据交换；第二级（L2）交换则由 4 个专门的通信机柜中的 L2 交换机组成，负责所有 48 个计算节点间的互联。 根据实测数据，UB 网络的性能表现如下： 1) 带宽方面：NPU 之间跨节点读写带宽，与节点内的带宽相比，衰减率低于 3% （比率高达 0.97-0.99）。例如，NPU 间读取操作的节点内带宽为 167GB/s，而 跨节点带宽依然高达 164GB/s。 2) 延迟方面：跨节点通信的延迟增加被控制在 1 微秒以内。例如，NPU 间读取 操作的节点内延迟为 1.2µs，跨节点延迟仅为 1.9µs。 这些数据表明，在 CloudMatrix384 中，访问一个物理上位于其他服务器上的 NPU 或 CPU 内存，其代价与访问本地节点的资源相近。传统 AI 集群主要的性能瓶颈， 缓慢且昂贵的跨节点通信，在 UB 网络上得到了一定程度的缓解。UB 网络提供的 这种高性能远程内存访问能力，是 PDC 分离架构和 LEP 大规模专家并行策略得 以高效运行的关键。
3.3.3. CloudMatrix 通过三平面网络架构，兼顾内部性能与外部兼容
支撑超节点理念的，是一套“三平面”网络架构。该架构确保了系统内部性能的 同时，具备了在现实世界中部署和兼容的能力。 1) UB 平面（Unified Bus Plane）：作为性能核心，负责超节点内部的 Scale-up 通 信。它构成了前述的高速通信域，是 PDC、LEP 等创新架构得以实现的性能 基础。 2) RDMA 平面（RDMA Plane）：作为扩展核心，负责超节点之间的 Scale-out 通 信。该平面采用标准的 RoCE（RDMA over Converged Ethernet）协议，提供高 达 400Gbps 的 NPU 间带宽，用于连接多个 CloudMatrix384 超节点以构建更大 规模的集群，或与外部兼容 RDMA 的系统进行高速互联。 3) VPC 平面（Virtual Private Cloud Plane）：作为管理与兼容核心，负责将超节 点融入传统数据中心。该平面通过专用的擎天卡（Qingtian Card）DPU 实现， 处理管理、监控、部署等控制流任务，并负责与外部存储（如 OBS/SFS）等服 务进行交互。 这套三平面设计，体现了 CloudMatrix 在追求创新的同时，对工程现实的充分考 量。它使得超节点既是一个内部高速互联的计算单元，又能够与外部系统顺畅交 互、易于管理。该架构为应对 AI 与数据密集型工作负载的融合执行挑战，提供了 坚实的硬件基础。
3.3.4. 昇腾 910C NPU 为 AI 计算负载定制异构设计
在超节点的最底层，是其核心处理单元，昇腾 910C NPU。它并非一个同构的计算 单元，而是一个高度集成的异构系统。 1) 双 Die 封装（Dual-Die Package）：昇腾 910C 将两个相同的计算裸片（Die） 封装在一起，通过高带宽的片内互联技术连接。这种设计在提升单颗芯片集成 度和总算力的同时，也为软件层面实现更细粒度的并行计算（如 H² P 策略） 提供了可能。 2) 异构计算核心：每个 Die 内部都包含两种不同类型的 AI 核心。一种是 AI Cube 核心，专门用于处理大规模的矩阵和卷积运算，这是深度学习中最核心和计算 密集的部分。另一种是 AI Vector 核心，负责处理更灵活的元素级（elementwise）运算、标量运算以及控制流任务。所有计算引擎均支持 FP16/BF16 和 INT8 数据类型，整颗芯片可提供高达 752 TFLOPS 的 BF16/FP16 稠密算力。 其 8 位量化通过 INT8 精度实现，可以在无需专用 FP8 硬件支持的情况下，提 供与原生 FP8 硬件相当的计算效率。 3) 高带宽片上内存：每个Die都配备了高达 64GB 的片上高带宽内存（On-package Memory），整颗芯片总内存达到 128GB，该内存采用堆栈式设计（Memory Stacks），提供高达 1.6TB/s 的单 Die 内存带宽。 4) 原生网络接口（Native Network Interfaces）：昇腾 910C 的一个关键特征是其 计算+网络的融合设计。每个 Die 都原生集成了针对不同网络平面的专用硬件 接口：一组由 7 个高速收发器构成的 UB 平面接口，以及一个独立的 RDMA 平面接口。这意味着通信能力并非外部附加功能，而是芯片固有的核心能力之 一。这为上层软件实现高效的通信优化提供了直接的硬件支持，是软硬件协同 设计理念的一种体现。
昇腾 NPU 的这种异构计算架构，是其能够与上层软件进行深度协同优化的硬件基 础。AI Cube 和 AI Vector 的明确分工，使得软件（如 CANN 算子库）可以将不同 的计算任务调度到最适合的硬件单元上执行。这正是 AIV-Direct 通信机制得以实 现的物理前提：软件可以直接调度更灵活的 AI Vector 核心来执行通信任务，完全 绕过 SDMA 引擎，从而将通信延迟降低到“执行一条计算指令”的微观级别，实 现了软硬件协同。
3.3.5. CANN 软件栈是连接上层框架与底层硬件的关键中间层
为确保上层 AI 应用能够充分利用昇腾 NPU 的异构计算能力，华为构建了名为 CANN（Compute Architecture for Neural Networks）的底层软件栈。CANN 在整个 技术体系中扮演着关键的中间层角色，类似于 NVIDIA 的 CUDA 生态，负责将高 层 AI 框架（如 PyTorch）中的计算意图，高效地转译为底层硬件可执行的指令序 列。 CANN 的架构主要由三个核心层次构成： 1) 驱动层（Driver Layer）：作为最底层，负责操作系统与 NPU 硬件间的交互， 管理设备初始化、资源分配和基本通信。 2) 运行时层（Runtime Layer）：提供核心的执行引擎，管理应用生命周期、内存、 以及模型和算子的执行调度。上层应用主要通过其提供的 ACL（Ascend Computing Language）API 与之交互。 3) 库层（Library Layer）：提供一系列高度优化的软件组件，包括用于分布式任 务的集合通信库（HCCL）、预优化的算子库（OPP）以及用于加速神经网络的 引擎。
在这些核心层之上，CANN 还包含一个关键组件，图引擎（Graph Engine，GE）。 GE 负责接收来自 AI 框架的计算图，并执行全局级的优化，例如算子融合（operator fusion）、内存规划以及对动态输入尺寸的处理（Dynamic Shape Handling）。 CloudMatrix-Infer 中的融合通信算子（FusedDispatch/FusedCombine），其实现便深 度依赖 GE 的图编译和优化能力。 CANN 为上层软件提供了一个稳定且高效的编程接口，屏蔽了底层硬件的复杂性。 通过 CANN，CloudMatrix-Infer 得以精细化地调度和利用昇腾 910C 的 AI Cube 与 AI Vector 核心，并将 AIV-Direct 这类硬件特性封装为高性能算子，从而实现了从 应用层到底层芯片的、贯穿整个技术栈的协同设计。
华为在 AI 领域着力构建的竞争力，并非源于模型或硬件的单点突破，而是来自 于一种贯穿全栈、深度耦合、双向定义的“软硬一体”系统工程能力。
4.1. 开源策略以模型开放构筑昇腾硬件生态建设
在全球大模型技术浪潮中，开源已成为推动技术普及和生态建设的重要手段。华 为近期逐步开放其盘古系列模型，这一举措是在特定的产业环境和地缘背景下做 出的主动战略选择。其背后，是旨在构筑昇腾硬件生态的深层考量。 2025 年 6 月 30 日，华为正式宣布开源盘古 70 亿参数的稠密模型、盘古 Pro MoE 720 亿参数的混合专家模型和基于昇腾的模型推理技术。此举是华为践行昇腾生 态战略的又一关键举措，推动大模型技术的研究与创新发展，加速推进人工智能 在千行百业的应用与价值创造。1）盘古 Pro MoE 72B 模型权重、基础推理代码， 已正式上线开源平台。2）基于昇腾的超大规模 MoE 模型推理代码，已正式上线 开源平台。3）盘古 7B 相关模型权重与推理代码将于近期上线开源平台。
2025 年 8 月 5 日,华为宣布 CANN 全面开源开放，共建昇腾生态:华为昇腾硬件使 能 CANN 全面开源开放，Mind 系列应用使能套件及工具链全面开源，支持用户自 主的深度挖潜和自定义开发，加速广大开发者的创新步伐，让昇腾更好用、更易 用。 华为的盘古模型系列，并非硬件无关的通用模型。恰恰相反，从 Pangu Pro MoE 的 MoGE 架构，到 Pangu Ultra MoE 的系统级优化，再到 CloudMatrix-Infer 的 AIVDirect 算子，模型的每一处设计都与昇腾硬件的特性深度耦合。这意味着，尽管开 发者可以获取模型，但要复现其技术报告中所述的高性能，一种直接路径便是使 用华为的昇腾硬件平台与 CANN 软件栈。 因此，华为的开源策略，其本质是以开放的软件为入口，吸引开发者和用户进入 其深度优化的硬件生态。在美国对先进 AI 芯片实施出口管制的背景下，这一策 略，旨在通过软件生态来促进硬件应用，从而推动其昇腾生态的建设。这一策略 的战略逻辑十分清晰： 1) 降低 AI 应用门槛：通过开放高性能的盘古大模型，降低企业使用和开发大模型技术的门槛。 2) 加速硬件市场渗透：当大量应用基于盘古模型构建后，对底层昇腾硬件的需求 随之增加，从而加速昇腾芯片的市场渗透。 3) 培育全栈开发者生态：大量开发者的涌入和使用，会反过来促进 CANN 软件 栈的成熟与完善，形成正向的生态循环。 4) 建立技术标准：随着基于“盘古+昇腾”的应用生态日益进步，该技术体系或 将在国内市场形成一定的影响力。 华为的开源策略是以开放的软件为牵引，最终服务于其在外部技术限制下，构建 自主可控 AI 产业体系的核心目标。
4.2. 架构、系统和算子构成全栈协同的三个方面
华为盘古大模型与昇腾硬件平台的协同进化之路，为观察 AI 时代的产业竞争提 供了一个值得关注的案例。其竞争力主要构建于一个深度耦合的“软硬一体”体 系之上。这一体系的核心，是一种硬件、软件的双向协同进化。 1) 软件协同硬件：盘古大模型的设计，是在为最大化利用昇腾硬件潜力而进行。 Pangu Pro MoE 的 MoGE 架构，是对软件的结构性调整，以解决硬件层面的负 载均衡难题；Pangu Ultra MoE 的“仿真先行”设计方法论，则是软件在设计 之初就以硬件性能边界为核心约束的直接体现。 2) 硬件协同软件：昇腾平台的底层硬件创新，为上层软件的范式创新提供了物理 基础。CloudMatrix 的统一总线（UB）网络，是 CloudMatrix-Infer 的 PDC 分 离架构得以存在的关键技术；昇腾 NPU 的异构计算核心（AI Cube & AI Vector）， 则是 AIV-Direct 原子级通信得以实现的物理前提。
这种全栈协同能力，具体体现在从宏观到微观的三个层面： 1) 架构协同：PDC 架构与 UB 网络的相互使能；MoGE 架构与分布式硬件的负 载均衡。这是顶层设计层面的协同。 2) 系统协同：LEP 并行策略与集群通信能力的匹配；精细化流水线负载均衡与 硬件特性的耦合。这是系统策略层面的协同。 3) 算子协同：AIV-Direct 通信机制与 CANN 融合算子的融合；为 DaVinci 内核 定制的张量尺寸。这是深入到硬件指令集层面的微观协同。 展望未来，华为的“软硬一体”战略将继续深化。其聚焦行业的差异化定位，旨 在为政务、金融、制造等更看重稳定性、数据安全和长期技术支持的 B 端客户， 提供性能有保障的端到端解决方案。对于整个 AI 产业而言，华为的实践提供了一 个视角，除了算法层面的创新，基于全栈技术整合的系统工程能力，也可能成为 影响未来市场竞争中的一个重要因素。
（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）
