昇腾生态培训笔记：软件栈、大 EP 推理、超节点互联与跨代兼容

昇腾生态的竞争力，需要沿着“模型适配—算子与编译器—HBM—互联—调度与可靠性—客户交付”整条链路理解。超节点与大规模专家并行可以改善部分 MoE 推理瓶颈，但收益取决于工作负载和系统实现。

整理日期：2026-09-11。来源为本次培训笔记与公开项目、厂商文档。正文解释通用原理并注明已核查来源；未获公开证据支持的现场交流内容保留在附录，不作为产品规格、市场统计或性能结论。本文未进行硬件实测。

1. 核心结论

生态决定性能能否被开发者获得。 芯片峰值算力之外，模型覆盖、版本兼容、算子质量、问题定位和维护响应同样重要。
大 EP 的本质是用更多设备分担专家权重和计算，并付出跨设备通信代价。 超节点提供更强通信条件，但不能保证 EP 规模越大越快。
模型跑通、性能优化、生产可用是三个不同阶段。 Day 0 支持不能自动推导出完整量化、长上下文、吞吐和稳定性支持。
跨代兼容必须分层讨论。 源码、算子 API、编译后二进制和性能可移植性不是一回事。
产品规格、路线图、客户实测和课堂交流需要分开。 特别是超节点规模、客户采购数量、BF16 实现和竞品时延倍数。

2. 软件生态：各组件分别解决什么问题

组件	定位	应如何理解
CANN	昇腾异构计算软件平台	涵盖算子、编译、运行时与通信等底层能力；不是单一推理框架。
PyTorch + TorchNPU	通用框架与昇腾适配	让 PyTorch 模型调用昇腾后端；适配之后仍需核查算子、版本和性能。
MindSpore	AI 框架	与 PyTorch 属于同一大层级；不能凭行业标签推断所有客户的选型。
MindSpeed / MindSpeed-LLM	训练加速与大语言模型训练套件	区分底层分布式加速能力和面向模型的预训练、微调、工具链。
Megatron-LM / Megatron Core	大模型训练与并行组件	与张量、流水线、数据等并行策略相关；Megatron 的中文常译为“威震天”。
MindSpeed-MM	多模态训练套件	面向多模态模型训练；不能只凭名称推断所有模型均已适配。
verl	LLM 强化学习后训练库	组织 rollout、奖励计算和策略更新，可集成训练与推理后端。
VeOmni	面向多模态的分布式训练框架	字节 Seed 开源项目；原笔记“全模型狂欢”应改为准确的框架定位。
Diffusers	Hugging Face 扩散模型工具库	提供扩散模型、调度器和生成管线，不是通用 LLM 服务引擎。
MindIE	昇腾推理软件套件	讨论开源状态必须细化到组件、版本和许可证；不能只以实现语言判断接受度。
vLLM Ascend / SGLang	LLM 推理与服务生态	提供昇腾运行路径；支持某硬件不代表全部模型和优化特性均可直接使用。
Ascend C / Triton-Ascend / TileLang / PyPTO	不同层级的算子开发入口	开发抽象、编译链路和目标硬件覆盖不同；DSL 接口接近不等于性能自动可移植。

公开项目说明：verl 由 ByteDance Seed 发起、社区维护，其原 volcengine 仓库已重定向至 verl-project；MindSpeed-LLM 明确定位为昇腾大语言模型分布式训练套件。verl、MindSpeed-LLM、MindSpeed-MM、VeOmni、Diffusers

2.1 vLLM“打补丁”与 SGLang“原生支持”

vLLM Ascend 是正式的硬件插件路径，不能简单概括为“只能修改 vLLM 源码打补丁”。特定版本和模型仍可能要求额外修补，但那是具体兼容问题。vLLM Ascend 文档

SGLang 的官方文档列出了 Ascend NPU 支持及安装要求。“原生支持”说明项目存在对应后端，不代表不需要 CANN、TorchNPU、专用算子或匹配版本。SGLang、Ascend 安装文档

因此选型时，更有用的问题是：目标模型在哪个版本支持、依赖什么软件组合、哪些功能受限、遇到问题能否找到维护者。

2.2 开源真正改善什么

“以前不敢开源”是对内部动机的判断，不能由开源范围反推。更适合长期保留的工程结论是：开放源码、构建过程、测试与问题跟踪，有助于开发者自行定位问题，降低对原厂现场支持的依赖。

评估生态时，应关注是否能够独立复现、定位和提交修复，以及修复能否进入主线。源码可见只是起点。

3. 新模型适配：从 Day 0 到生产可用

培训中的“Day 0 发布、Day 7 达到 0.8 最优化性能”可记录为团队目标或口头描述。原文的“0.8”缺少参照系：可能是某项性能比例，也可能是转录遗漏，不能直接写成“7 天达到最优性能的 80%”。

更完整的适配过程如下：

功能跑通：模型结构、权重加载、算子与基本生成链路可执行。
精度对齐：验证输出、任务指标、低精度误差和关键算子数值行为。
性能优化：定位热点，以融合算子、高性能 GEMM/Attention、通信重叠、图执行等替换初始实现。
服务化验证：覆盖动态请求、长上下文、并发、缓存、故障恢复与持续运行。

“小算子先跑通，再用高性能算子替换”对应先建立正确性基线、再优化热点的合理路径。不过应根据 profiling 选择热点，不是所有小算子都值得融合。

3.1 DeepSeek-V4 与 1M 序列应该怎样记录

本次查看的 MindSpeed-LLM 仓库存在 DeepSeek4 相关训练与推理入口，但这只能说明存在代码适配，不能据此证实所有平台的 Day 0 完整支持。MindSpeed-LLM 仓库

培训中的“DSv4 首发、A3 到 950PR/DT、1M 序列”保留为待核查的具体支持承诺。核验时需补齐：模型版本、框架版本、硬件 SKU、精度、输入与输出长度、并行方式、并发和测量结果。

模型标称上下文长度、服务允许设置的最大长度，以及该长度下可接受的时延与吞吐，分别是三项能力。

4. 大规模专家并行：为什么与超节点紧密相关

4.1 专家处理的是 hidden states

MoE 层的 Router 根据 token 的隐藏向量选择 Top-k 专家。Dispatch 将向量分发到专家所在设备；专家执行 MLP/FFN；Combine 把结果按路由权重聚合，返回后续网络层。

传输的不是完整文本或全模型参数，而是这一层需要处理的 token 隐藏向量及必要的路由信息。

标准自回归解码启用 KV Cache 后，旧 token 通常无需重新执行 MLP；当前步的新输入位置仍需逐层执行 Attention 与 MLP/MoE。KV Cache 保存的是注意力所需的 K/V，不是“把整个网络的所有中间计算都缓存”。

4.2 “一卡一专家”不是整张卡永远只有一个专家

这个说法通常指某个 MoE 层、某个 EP 组内的放置粒度。一张卡可能承载多个层各自的专家，以及 Attention、共享专家或其他模块；还可能存在专家副本或专家内部的张量并行。

例如，一个有 64 个路由专家的 MoE 层，在不复制专家、不做专家内部切分的示例中，EP=8 可平均每卡放 8 个专家，EP=64 可每卡放 1 个专家。这只是便于理解的配置示例，不代表具体产品方案。

4.3 大 EP 的收益与代价

方面	可能收益	约束
专家权重	单卡驻留的专家权重减少	Attention、共享专家、其他层和运行缓冲仍占空间。
HBM	分散权重读取，利用多卡总带宽	单卡物理 HBM 带宽不会因 EP 扩大而提高。
专家计算	更多设备并行处理路由后的 token	路由倾斜会造成热点；每专家 token 太少会降低 GEMM 效率。
KV Cache	若释放显存且布局允许，可容纳更多缓存	KV Cache 如何分布由 Attention 并行、复制方式与调度共同决定。
通信	强互联有利于 Dispatch / Combine	每层通信、同步与重排可能抵消计算收益。
可靠性	可结合专家冗余和恢复机制	通信域扩大后，故障影响范围、排障与恢复更复杂。

可用一个工程近似理解端到端 Decode 步时：

Decode 步时 ≈ Attention + Dispatch + Expert 计算 + Combine + 调度/同步。

计算和通信可以重叠，因此这里是分解瓶颈的示意，不是严格相加的预测公式。EP 扩大主要影响专家计算、权重布局与通信项，不能自动缩短所有部分。

“EP 越多，单卡并发越强、Decode 越快”应改为：在权重/访存成为瓶颈、负载足够均衡且通信成本可控时，扩大 EP 可能改善时延或容量；最佳 EP 规模需要实测。

4.4 超节点为什么有帮助

MoE 的跨设备通信往往每层都要发生。更大的高速 Scale-Up 域可以减少专家跨越较慢网络的机会，配合通信与计算重叠改善时延。

这是一条通用系统优化思路，不能把“大 EP”理解为仅一家厂商能够实现。SGLang 的 Ascend 路线图也列有融合 Dispatch、GEMM、Activation 与 Combine 的工作。SGLang Ascend 路线图

“相比友商领先”应绑定模型、精度、卡数、功耗、请求长度、吞吐、用户时延和软件版本；本笔记不将现场比较写成普遍结论。

5. Prefix Cache、TTFT 与 Decode 的边界

Prefill：处理尚未缓存的输入位置，建立相应 KV Cache。
TTFT（Time To First Token）：从请求发出或服务接收开始，到首个输出 token 的时间；测试需注明起止点。
Prefix Cache：复用兼容请求的相同前缀所对应的 KV Cache，减少重复 Prefill。

例如，多次请求使用同一系统提示词和长文档，后续请求可复用命中的前缀，只计算尚未缓存的后缀。命中范围取决于模型、token 序列和缓存实现。

TTFT 还可能包含排队、输入处理、缓存查找/加载和输出传输。Prefix Cache 主要减少重复 Prefill，不能消除排队，也不直接省去新 token 的逐步 Decode 计算。vLLM Automatic Prefix Caching

6. 硬件与互联：把产品层级分清

Ascend 是处理器系列，Atlas 是硬件产品体系，SuperPoD 是超节点形态。 芯片型号、服务器、超节点规模和集群规模不能混用。

6.1 HCCS、HCCL、灵衢与拓扑不是同一层

HCCS：昇腾硬件高速互联相关技术；具体覆盖范围取决于产品。
HCCL：软件通信库层，面向集合通信等操作。
灵衢 / UnifiedBus：系统互联体系；内存语义是其需要理解的重要能力。
Full Mesh / Clos：拓扑结构，描述如何连接。
OD 正交架构：偏向系统物理布局和连接组织，不能与网络拓扑直接画等号。

Full Mesh 表示所讨论端点之间直接全连接；Clos 使用多级交换扩大连接规模。同一系统的不同层级可以采用不同结构。因此“A3 都是 Full Mesh，A5 才变成 Clos”缺少观察层级，不适合当作完整架构结论。

统一编址或支持内存语义，也不代表远端内存与本地 HBM 等延迟，更不代表默认具有全系统缓存一致性。

6.2 950：产品规格与路线图

当前 Atlas 950 SuperPoD 官网列出最高 1024 颗 950DT、64/1024 卡配置、液冷和全局统一内存编址能力。当前产品页

华为 2025 年发布的路线图则描述最多 8192 颗 950DT 的更大系统，并给出未来计划。华为 2025 年路线图

因此“支持 1K 和 8K，8K 比较少”不够准确：现有证据可以证明两种公开口径存在，不能证明 8K 已交付或其数量。

官网目录明确区分 Atlas 950 液冷超节点与 Atlas 850E 风冷超节点。风冷/液冷是部署条件，不直接等于计算能力高低。Atlas 产品目录

6.3 950PR 的 SIMT 与存储配置

Atlas 350 产品页明确说明其采用 950PR，支持 SIMT/SIMD，配置 112 GB HBM、1.4 TB/s 内存带宽，并列出 BF16 及多种低精度格式。Atlas 350

这支持“新架构改善编程与部分算子适配条件”的方向，但不能推导所有 Triton/TileLang 代码零修改迁移，更不能仅凭带宽较低推断 PR 型号划分完全由 HBM 供应限制导致。

6.4 NVL72 与“无收敛”

GB200 NVL72 含 72 个 Blackwell GPU 和 36 个 Grace CPU，GPU 通过 NVLink Switch 系统构成一个高速域。NVIDIA GB200 NVL72

网络语境中的“无收敛”一般指没有带宽超卖，即相关网络切面的供给能力足以承载设计的端口流量；它与模型训练是否收敛无关。它也不意味着任意流量模式都不会竞争，或每对 GPU 都有独占满带宽直连。

72 是该产品域的 GPU 数量，不是 NVIDIA 集群只能使用 72 张卡。多个域仍可通过集群网络连接。

铜与光的选择涉及距离、信号完整性、功耗、成本和可靠性。“光模块故障率高”需要现场统计；不能脱离器件数量、时间范围和冗余设计下结论。

7. 芯片架构、算子兼容与数值精度

7.1 四种兼容性必须分别判断

兼容层级	问题
框架/API 兼容	同一模型与 API 能否调用？
源码兼容	同一算子源码能否重新编译，是否需要修改布局、同步与分块？
二进制兼容	旧目标设备代码能否直接加载到新设备？
性能可移植性	跑通后是否仍有较好的利用率与端到端性能？

原笔记一处说“910B 到 910C 不能复用”，另一处说“B/C 相对能复用”，应保留这一矛盾并回到具体算子核查，不能选择其一当作整代结论。

低层算子与硬件执行单元、本地存储、同步和数据搬运方式相关，跨代优化可能需要调整。上层模型或算子接口可复用，不代表旧二进制和调优参数可直接复用。

对 NVIDIA 也应使用同样尺度：CUDA 生态提供兼容机制，但旧二进制是否可用取决于目标架构、所携带代码与驱动支持，性能不会自动达到新硬件最优。

7.2 Cube/Vector 分离不等于融合算子必然低效

培训以“耦合/分离”解释不同代际的矩阵与向量执行方式。该思路有助于关注数据流，但“910A 融合高效、B/C 融合低效”过于笼统。

融合能否获益取决于减少了多少 HBM 往返与启动开销，以及新增的数据交换、同步、缓冲占用和流水线等待。分离执行单元可以创造并行机会，也要求更细致的流水线安排。

910A、310 家族、910B/C 和 950 的具体映射与配比，在缺少对应架构手册时不在本文补写为定论。

7.3 BF16 输入、FP32 累加与软件模拟是三件事

“BF16 通过 FP32 软件强转支持”不能笼统套用到整颗 910C：

BF16 可以是输入和权重的存储格式。
矩阵乘可能采用低精度输入、较高精度累加。
某个具体算子可能为了精度或指令限制而显式转换数据类型。
只有确认指令路径与实现，才能判断是否属于软件模拟以及性能代价。

BF16 输入配合 FP32 累加并不等于“没有硬件 BF16”。MindSpore 官方文档已列出 Ascend 后端的 BF16 算子支持，但该表本身也不足以证明某个 910C 算子的硬件执行细节。MindSpore BF16 支持说明

因此本次不保留“昇腾 BF16 天然比 GPU 精度更高”的结论。应比较具体运算、累加精度、舍入方式、算法和误差测试。

FP8 同样应区分存储、量化、算子接收的数据类型与原生矩阵指令。关于“910C 以前都不支持 FP8”，需按 SKU 和上述层次核验。

7.4 双 Die 不自动变成无代价的单设备

即使硬件采用多 Die 封装，上层看到几个设备、内存如何寻址、通信和调度如何组织，仍由软硬件共同决定。“没有解决当一个设备看的性能问题”应落到具体运行模式与测试案例，不能作为完整产品定性。

8. 训练、交付与运维

8.1 为什么训练经常更难迁移

训练除了前向，还需要反向、梯度、优化器状态、分布式同步、检查点，以及长期数值稳定性验证。一个模型能推理，不等于同一平台能稳定完成训练。

但大规模在线推理也需要管理动态请求、KV Cache、长尾延迟、跨设备专家通信和故障恢复。因此“只做推理很好做”只适用于限定范围的功能跑通。

8.2 客户买什么，取决于自己承担多少集成工作

采购形态	客户主要承担的工作
芯片或定制板卡	板级设计、主机平台、供电散热、互联和软硬件验证。
标准加速卡	服务器适配、驱动框架、组网与运维。
整机服务器	集群网络、软件部署与业务优化。
集群/超节点解决方案	机房条件、业务接入、容量规划及与供应商共同运维。

头部客户可能更愿意自集成，但“头部买卡、腰部买集群、行业买服务器”只能作为培训观察。具体采购随团队能力、项目需求与时间变化。

采购适配 x86 的卡与“把既有鲲鹏整机直接换成 x86”不同，仍需主板、固件、驱动与互联验证。

8.3 现场支持是一种交付能力

原笔记“用昇腾可以让华为的人干活”可改为：原厂驻场、联合调优和故障升级通道能降低客户初期迁移门槛，但服务范围取决于合同与项目资源。

“找不到负责开发的人”反映的是问题归属与升级机制不清。成熟生态应让开发者能获取最小复现、日志、profiling 数据、版本矩阵及明确维护入口。

CCAE 在官网被归类为集群自智引擎；培训所述业务视图、监控分析和资源管理，可作为后续按版本核对的功能条目。昇腾产品目录

“工具完善是因为别人不需要”属于课堂调侃。任何大规模 AI 系统都需要监控、故障定位和恢复；工具数量也不能直接衡量平台好坏。

9. 培训现场信息备忘：保留，但不提升为事实结论

以下均来自用户原始记录，未独立确认。保留用于回看课件或向讲师追问，不与已核查技术原理混用。

主题	原始信息与待核查点
社区协作	verl 与昇腾团队双周例会、社区交流；需要公开会议记录或讲师说明。
适配承诺	Day 0、Day 7、0.8 性能，DSv4 首发、1M 序列、A3/950PR/DT；需版本和测试矩阵。
内部资源	华为内部缺卡、盘古缺卡、研发驻客户现场、DeepSeek-V4 适配重点在蚂蚁；均属现场交流，不能据此推断公司总体资源。
客户规模	蚂蚁 51、京东 59、小红书 20 个 A3 超节点；缺采购/部署时间、配置、统计口径和出处。
机房与托管	腾讯没有液冷机房、蚂蚁节点托管华为云；需限定具体项目和时间，不能泛化为公司整体。
采购方式	字节买标卡或芯片、自建 x86 平台，头部客户自行组网；需具体项目证据。
产品与组织标签	A3 面向 OTT/小巧灵、A5 计算产品线、海思 A6；可能混合内部组织与产品代号，不作为公开产品分类。
不完整转录	“6计算×2”、950prdt、0.8最优化性能；上下文不足，不擅自补全。
架构判断	910A/310 耦合、B/C 分离、950 又不通用、910C 双 Die；细节需架构手册和具体算子案例。
310P 定位	使用 DDR、属于过渡产品；需确认具体板卡和存储规格，“过渡”属于评价。
性能倍数	Decode 比 NVIDIA 慢 2～3 倍、超节点+大 EP 领先；缺硬件、模型、精度和负载条件。
供应链与路线	一年一代算力翻倍、HBM 已自主可控、950PR 因 HBM 受限；分别需要路线图、供应链与 SKU 设计依据。
生态评价	MindIE 不开源且接受度低、国产 CUDA 兼容单卡尚可但多卡差；缺组件/厂商范围与数据。
商业观点	模型赢家通吃、工艺落后依靠存算网协同；可讨论规模效应和系统设计，不宜写成无条件规律。
出口政策解释	A800/H800/H20/H200 被描述为依次限制与放开；不能简单视作同一产品连续裁剪，更不能把政策动机推测当事实。本篇不将此作为已核实政策现状。

10. 建议形成的实测与学习方法

先问工作负载在等什么，再选择优化技术。

等权重/KV 数据：看 HBM 带宽、容量、缓存布局、量化和 batch。
等专家通信：看 Dispatch/Combine、拓扑、EP、路由均衡和通信重叠。
等小算子/启动：看图执行、融合、编译和主机调度。
容量不够：看权重分布、KV Cache、复制策略与并行组合。
时快时慢或任务中断：看尾延迟、故障域、恢复机制与运维数据。

后续对比 CUDA 与昇腾时，建议固定一个模型，记录：硬件 SKU、设备数、CANN/CUDA 与框架版本、精度、输入/输出长度、并发、TP/EP/DP/PP、TTFT、TPOT/ITL、吞吐、P95/P99、显存峰值和功耗口径。一次只改变一个主要变量，避免把增卡收益误认为单卡或算法收益。

值得继续学习的四个问题：

固定总请求量与增加总请求量时，扩大 EP 的结果为什么不同？
专家权重减少后，KV Cache 可用容量是否一定增加？
相同算子源码跨代能编译，为什么性能仍可能明显下降？
超节点规模扩大后，何时应该增加 EP，何时应该增加独立推理副本？

11. 关联阅读

编辑说明：统一了 verl、vLLM、SGLang、Prefill、Decode、Dispatch/Combine 等拼写，合并重复内容，增加条件与证据边界，并保留现场信息附录。既有笔记是关联阅读，不作为未经复核的外部证据。