华为大模型训练栈中，最值得关注的新文件有一个毫不起眼的名字：train_fsdp2.py。

MindSpeed-LLM 是昇腾的分布式训练套件，位于模型权重与更底层的 NPU 软件栈之间。它原有的主路线是 Mcore，也就是项目为其推荐的 Megatron Core 后端所用的名称。2026 年 2 月 10 日，代码仓库宣布为 Qwen3-Next 推出原型 FSDP2 后端。当前代码树已经包含 FSDP2 启动程序、配置目录、详尽的 Qwen3 教程，以及面向更大模型的条目。[1][2]

截至 2026-08-02T16:38:15Z UTC，现有材料尚不足以说明昇腾训练已经做到硬件中立。它支持的是一个范围更窄、却具有战略价值的判断：部分移植职责正在转向上游 PyTorch API。MindSpeed-LLM 如今可以提供两条不同的 PyTorch 训练路线，一条使用 Megatron 明确的模型并行体系，另一条遵循 FSDP2 的逐参数分片契约，同时清楚保留两者在成熟度上的差距。

项目自己的支持表把这项差距标得格外清楚。多项 Mcore 条目都标有 Pass 认证，较新的 FSDP2 条目仍标为 Test。第二条路线已有实际运行基础，覆盖范围尚不足以和原有路线等同互换。

第二个后端改变了交接方式

FSDP2 带来的变化，远超替换同一个分布式作业的启动命令。PyTorch 的 fully_shard API 会把参数转换为 DTensor 对象，在前向与反向计算需要完整参数时执行聚合，计算结束后再恢复为分片状态。它采用逐参数分片和 eager 模式钩子，让各项分布式转换脱离应用程序的直接管理。[5]

这套契约对昇腾很重要，因为使用者由此面对熟悉的配置入口。MindSpeed-LLM 的 Qwen3-8B 教程从 Hugging Face 或 ModelScope 权重起步，使用 torchrun 启动作业；分片模块、专家并行、重计算、优化器设置和数据选项则写入 YAML 文件。示例把 fsdp_size 设为与 8 个 NPU 的 world size 相等，并将 Transformer 层、嵌入层和语言模型头列为分片目标。[3]

硬件约束依然清楚。教程把受支持路线限定在昇腾 950 产品，以及每个 NPU 至少拥有 64 GB 片上内存的 Atlas A3 或 A2 训练系统。示例使用 8 个 NPU，文档同时警告，数量更少时会面临内存不足风险。展示的日志记录了若干预训练和微调迭代的完成过程；这些结果可以充当可运行的冒烟测试，尚未覆盖吞吐量对比或多节点可靠性研究。[3]

Megatron 提供另一类控制。它的核心设计组合了数据并行、张量并行、流水线并行、上下文并行和专家并行，操作者可以沿不同轴拆分批次、网络层、长序列和混合专家模型。这样的设计为大集群提供了强大底座，本身也更为专门，带有自己的配置与 checkpoint 假设。[6] MindSpeed-LLM 的 Mcore 路线在这套体系上加入昇腾专用适配和工具。FSDP2 路线关注的则是训练工作流有多大部分可以继续用标准 PyTorch 概念来表达。

两条路线各自针对不同需求。Megatron 的吸引力来自细粒度扩展控制；对于已经使用 PyTorch 的团队，FSDP2 所需跨越的概念门槛更低。供应链问题在于，昇腾能否同时支持两者，并让模型、checkpoint、kernel 与升级脱离逐项移植的循环。

模型表比发布口号更有用

判断成熟度时，仓库中的模型名称数量作用有限，MindSpeed-LLM 在可比配方下如何标记两个后端才是更清楚的信号。

对于序列长度为 4,000 个 token 的 Qwen3-32B，表中 Mcore 配方使用 2 个节点、每个节点 8 个 NPU，状态为 Pass；FSDP2 配方使用 1 个 16-NPU 节点，仍为 Test。对于混合专家模型 Qwen3-235B-A22B，两个后端都列出 16×16-NPU 配置，Mcore 为 Pass，FSDP2 为 Test。Qwen3-Next 80B-A3B 的两组条目同样都使用 4 个 16-NPU 节点，状态依旧分别为 Pass 与 Test。[2]

这些条目的作用在于标明配置与状态，基准测试仍需另行提供。卡数相同无法证明速度、内存占用、数值行为、故障恢复或成本也相同。它们能够确认的范围更窄：FSDP2 工作已经从 8 卡教程推进到针对稠密与稀疏架构的模型专用脚本，并扩展到多节点规模。支持表也让证据的适用范围保持清晰，新路线仍未得到同等认证标签。

叙述这个项目时，这一区分需要保留。“Supported”一词覆盖的状态很多：脚本已经存在、第一步已经完成、内部测试已经运行，或维护中的 release 通过了既定认证套件。MindSpeed-LLM 的表格至少分开了其中两种状态。下一版若要增强可信度，需要解释 Test 与 Pass 背后的确切标准，再发布可复现日志，让外部操作者看到状态转变的过程。

标准 API 仍落在严格配套的版本栈上

FSDP2 可以减少特定训练框架的适配工作，平台栈依然保持紧密耦合。MindSpeed-LLM 26.0.0 release notes 给出的参考组合是 MindSpeed Core core_v0.12.1、PyTorch 2.7.1、Ascend Extension for PyTorch 26.0.0、CANN 9.0.0、Triton-Ascend 3.2.1 和 Python 3.10。另有兼容性表格将这个 MindSpeed-LLM release 标为兼容较旧版本的 Ascend Extension 和 CANN。即便如此，文档仍称 Triton-Ascend 与 CANN 强绑定，应当一一配对，并警告软件升级会中断正在运行的工作负载。[4]

这里显露出 AI 供应链里较少露面的一层。它落在机箱里的加速器之外，由驱动、固件、CANN 库、torch_npu、编译器组件、分布式训练系统、模型适配器和 checkpoint 依次相连，各部分必须彼此匹配。标准分片 API 的价值，恰在于它能稳定这条链上的一处接缝。单靠这项 API，仍然无法让未支持的算子凭空出现，无法让 checkpoint 跨越不兼容布局，也无法证明作业从一台机器扩大到数百台后，集合通信依旧表现良好。

面对当前版本矩阵，可以用一组具体问题检验“PyTorch 兼容性”。同一个模型定义能否直接沿 FSDP2 路线运行，并继续共用原有代码，省去昇腾专用分支？运行时小版本升级后，checkpoint 能否恢复训练？优化器状态与专家分区能否在不同配方之间迁移？公开的多节点运行能否承受 worker 丢失，并继续收敛到同样的结果？所列兼容范围是否代表完整且经过测试的组合？实际运行是否仍要求参考栈的大部分组件同步锁定版本？

MindSpeed-LLM 尚未回答全部问题。至少，这些问题如今更容易定位。

分层解耦有了具体形态

2025 年 9 月的 HUAWEI CONNECT 上，华为把昇腾软件的发展方向描述为“分层解耦”，并提到希望与 PyTorch、Triton、vLLM 和 verl 等上游社区深入协作。[7] 这项表述范围很广。FSDP2 路线给出了一项规模更小、便于检查的具体做法：硬件专用工作留在底层，上方采用更多训练代码原本就能识别的接口。

决定性证据要从实际运行中产生，口头表述居于其次。首先，FSDP2 条目需要按照公开标准从 Test 升至 Pass。其次，项目除了展示全新启动，还需要展示 checkpoint 的保存、重新加载与续训。第三，多节点参考运行需要在锁定版本矩阵后，报告利用率、内存占用、收敛情况与故障恢复。最后，兼容性还要经受日常升级；可移植 API 若在每次小版本升级时都要求重建完整软件栈，这种可移植性依然代价高昂。

眼下，Mcore 是成熟主路，FSDP2 则是旁边一座正接受负载测试的新桥。这仍是有意义的进展。中国加速器所面对的挑战，已经从造出硬件、跑通一个知名模型，延伸到让工程师选择熟悉的训练抽象，同时由平台在底层兑现性能。

train_fsdp2.py 没有让昇腾软件栈消失。它移动了其中一条边界，而且支持表清楚标出了新路线目前止步之处。

来源

1. 昇腾，“MindSpeed-LLM”（官方代码仓库；项目范围、仓库结构、2026 年 2 月 FSDP2 公告与后端导航）。
2. 昇腾，“PyTorch 框架模型支持列表”（MindSpeed-LLM 官方表格，区分 Legacy、Mcore 与 FSDP2 配方、集群规模和 Pass/Test 状态）。
3. 昇腾，“快速入门：使用 FSDP2 后端训练 Qwen3-8B”（官方硬件范围、8-NPU 配置、YAML 控制项与运行日志示例）。
4. 昇腾，“MindSpeed-LLM release notes”（官方 26.0.0 组件矩阵、兼容性说明与升级影响）。
5. PyTorch，“PyTorch FSDP2（fully_shard）”（逐参数分片、DTensor 与聚合/重新分片钩子的官方 API 契约）。
6. NVIDIA，“Megatron Core 并行策略指南”（数据并行、张量并行、流水线并行、上下文并行、专家并行与完全分片并行的官方概览）。
7. 华为，“Ascend: Open for All to Build a Vibrant Ecosystem”（2025 年 9 月 20 日；关于分层解耦与上游协作的官方报道及会议照片）。