GPU vs 昇腾：大模型训练推理全景对比 -- 国产芯片到底走到哪了？
调研日期：2026/06/12（数据持续更新） 范围：NVIDIA GPU 与华为昇腾 NPU 在大模型训练、推理两个场景下的分层对比，涵盖硬件、软件栈、社区框架、融合算子、TCO 成本、集群网络、工程实践等 17 个维度。 数据说明：综合自厂商官方报告、arXiv 论文、开源社区文档、行业媒体及云平台公开报价。未发布硬件规格、价格及训练细节存在预测或估算成分，请以官方信息为准。
1. 为什么今天要关心这个问题？
2026 年，大模型算力格局正在发生一件很有意思的事。
一边是 NVIDIA。靠着 H100/H200/B200 系列和 CUDA 二十年的积累，它仍然是全球 AI 训练推理的绝对王者。你想训一个千亿参数的模型，或者把 DeepSeek-V3 部署上线跑推理，NVIDIA GPU 依然是风险最低、文档最全、社区支持最完善的选择。这没什么好争论的。
但另一边，华为昇腾（Ascend）也在悄悄变强——而且速度比很多人想象得快。
两个信号特别值得关注。第一，DeepSeek-V4 宣布跟昇腾完成全栈适配，这是第一个在国产芯片上完成推理与训练验证的万亿参数 frontier 模型。第二，美团 LongCat-2.0（参数规模超过 1 万亿），用 5-6 万张国产加速卡完成了预训练。万亿参数级别的模型在国产芯片上训出来了，而且不止一家做到了——这个事实本身就说明了很多问题。
所以这篇文章要回答的核心问题是：如果今天你要做大模型训练或推理，GPU 和 Ascend 各自适合什么场景？差距到底还有多大？从 CUDA 迁到昇腾要花多少成本？
我会从硬件、软件、社区、成本、工程实践这些维度一个个展开。读完以后，你对"什么时候该用 GPU，什么时候可以考虑昇腾"应该会有一个比较清晰的感觉。
目录
- 1. 为什么今天要关心这个问题？
- 2. 生态全景图
- 3. 大模型训练生态对比
- 4. 大模型推理生态对比
- 5. 社区框架与工具对 Ascend NPU 的支持
- 6. 关键融合算子与加速库
- 7. 其他竞争者（简要）
- 8. 趋势判断
- 结论
- 9. TCO 与成本效益分析
- 10. 版本兼容矩阵
- 11. CUDA 到 Ascend 迁移路径与成本
- 12. 实测性能基准
- 13. 多模态与 Agent 生态
- 14. 集群网络与互联拓扑
- 15. 推理部署工程实践
- 16. 故障恢复与长稳训练
- 17. 参考来源
2. 生态全景图
在深入细节之前，先拉一张地图。大模型的技术栈从应用到硬件，大致可以分成五层：
硬件 → 运行时/编译器 → 加速库 & 通信库 → 框架 → 应用
GPU 和 Ascend 在每一层都有对应的东西，但成熟度差很多。有一个规律特别好记：越靠近应用层，两个生态越像——GPT、Claude、Llama 这些模型本身跟硬件解耦，理论上在哪都能跑。越靠近底层硬件，差异越大——CUDA vs CANN，NCCL vs HCCL，这些才是迁移真正的硬骨头。
| 层级 | GPU 生态（NVIDIA） | Ascend 生态（华为） | 说明 |
|---|---|---|---|
| 应用层 | GPT、Claude、Llama、Grok 等 | 盘古、DeepSeek-V4、GLM、LongCat 等 | 模型与硬件解耦，可跨平台部署 |
| 训练框架 | PyTorch、JAX、TensorFlow | MindSpore（原生）+ PyTorch（torch_npu 插件） | PyTorch 通过 torch_npu 插件支持 Ascend NPU |
| 分布式训练 | Megatron-LM、DeepSpeed、FSDP | MindSpeed-LLM、MindSpeed-MM、MindSpeed-RL | DeepSpeed 通过 torch_npu / Ascend 适配分支支持 NPU |
| 推理引擎 | vLLM、TensorRT-LLM 4.0、SGLang | vLLM-Ascend、SGLang、MindIE | vLLM-Ascend 已成为昇腾推理主入口 |
| 算子开发 | CUDA、Triton、CUTLASS | Ascend C、TBE、Ascend-Triton | 自定义 kernel 与融合算子 |
| 加速库 | cuBLAS、cuDNN、cuDNN-frontend | AscendCL、ATB、算子库 | 底层矩阵/注意力/融合算子 |
| 通信库 | NCCL 2.21+ | HCCL | 多卡/多节点集合通信 |
| 运行时/编译器 | CUDA Runtime、CUDA Graph | CANN（GE 图引擎 + MindIR + AOE） | 图编译、算子调度、自动调优 |
| 性能分析 | Nsight Systems/Compute、PyTorch Profiler | MindStudio Insight / Profiler | 性能定位与可视化 |
| 开发工具 | Nsight、TensorBoard | MindStudio、ModelArts | 开发、转换、云化平台 |
| 硬件平台 | H100 / H200 / B200 / GB200 | 910B / 910C / 950PR / 950DT / 960（路线图） | 950PR/DT 为 2026 年新品；960/970 为 2027–2028 年规划 |
| 互联方案 | NVLink + NVSwitch + InfiniBand/RoCE | HCCS + 超节点互联（CloudMatrix / SuperPoD） | 集群级设计成为新竞争焦点 |
如果你是开发者，上表里最需要关注的三层是训练框架、推理引擎、加速库——它们直接决定了你的代码能不能在目标硬件上高效跑起来。其他的（通信库、编译器、Profiler）更多是出了问题时需要排查的。
3. 大模型训练生态对比
训练是整个大模型生命周期里最"吃硬件"的阶段。千亿甚至万亿参数的模型，要在成百上千张加速卡上连续跑几周甚至几个月才能训出来。单卡的算力、显存、卡间互联带宽，再加上软件栈的并行能力，一个都不能掉链子。
3.1 训练硬件对比
2024-2026 年是 AI 训练芯片换代最密集的两年。NVIDIA 从 Hopper（H100/H200）切到 Blackwell（B200/GB200），华为则从 910B → 910C → 950 系列一路狂奔。先看一张规格表：
| 维度 | NVIDIA GPU | Ascend NPU |
|---|---|---|
| 主力训练芯片 | H100 SXM5、H200 SXM5、B200 SXM6 | Ascend 910B、910C、950DT（2026 年 Q4） |
| 下一代旗舰 | GB200 NVL72（机架级） | Ascend 950DT（2026 年）、960/970（2027–2028 年路线图） |
| 峰值 BF16 算力 | H100: 989 TFLOPS；B200: ~4,500 TFLOPS | 910B: ~376 TFLOPS；910C: ~780 TFLOPS；950DT: ~1,000 TFLOPS（目标） |
| 显存容量 | H100 80GB → H200 141GB → B200 192GB | 910B 64GB → 910C 128GB → 950PR 128GB → 950DT 144GB |
| 显存带宽 | H100 3.35 TB/s → B200 8.0 TB/s | 910B ~1.6 TB/s → 910C 3.2 TB/s → 950PR 1.6 TB/s → 950DT 4 TB/s |
| 互联带宽 | NVLink 4: 900 GB/s；NVLink 5: 1.8 TB/s | 910B HCCS 总双向 ~392 GB/s（点对点 56 GB/s）；910C UB 单 Die 单向 ~196 GB/s、整卡单向 ~392 GB/s；CloudMatrix 384 UB 面 ~392 GB/s/卡 |
| 集群形态 | DGX/HGX + IB/RoCE 网络 | Atlas 800 训练服务器 + CloudMatrix/SuperPoD |
| 能效/散热 | B200 单卡 1000W，GB200 机架需液冷 | 910B 约 310W~400W，超节点亦倾向液冷 |
坦白说，NVIDIA 在单卡算力、显存带宽、互联成熟度上仍然领先。但 Ascend 的打法很聪明——它不跟你拼单卡，而是靠超节点架构（384 卡全对等互联）和国产化供应来弥补单卡差距。在政府、金融、电信这些封闭市场里，单卡跑分没那么重要，能稳定供货才重要。
注：910B 的 ~376 TFLOPS 是官方标称峰值，实际部署中常见 256-320 TFLOPS。950PR/950DT、960/970 的规格来自华为 2025 年公开路线图和行业媒体披露，截至 2026 年 6 月并非全部量产，实际参数以官方发布为准。
3.2 训练软件栈对比
硬件是地基，软件栈决定了你能在上面盖多高的楼。NVIDIA 真正的护城河不光是芯片，更是围绕 CUDA 修了二十年的"基建"——从 cuBLAS/cuDNN 这种底层算子库，到 Megatron-LM/DeepSpeed 这种分布式框架，每一层都有久经考验的方案。
华为的策略很务实：既然重建一套生态太难，那就"借道 PyTorch"。torch_npu 插件让开发者用同一套 PyTorch 代码直接在 NPU 上跑，底层自动翻译成 Ascend 的指令。分布式训练则用 MindSpeed 系列框架来覆盖。
| 层级 | NVIDIA GPU | Ascend NPU |
|---|---|---|
| 框架层 | PyTorch、JAX、TensorFlow 原生支持 | MindSpore（原生）+ PyTorch via torch_npu |
| 分布式框架 | Megatron-LM、DeepSpeed、FSDP、Colossal-AI | MindSpeed-LLM、MindSpeed-MM、MindSpeed-RL |
| 通信库 | NCCL | HCCL |
| 算子库 | cuBLAS、cuDNN、cuDNN-frontend | AscendCL、ATB、算子库 |
| Kernel 开发 | CUDA、Triton、CUTLASS | Ascend C、TBE、Ascend-Triton |
| 编译/运行时 | CUDA Runtime、CUDA Graph、nvFuser | CANN（GE + MindIR + AOE 自动调优） |
| Profiler | Nsight Systems/Compute、PyTorch Profiler | MindStudio Insight、CANN Profiler |
一个很现实的数据：据公开资料，95% 以上的 PyTorch CUDA 代码能通过 torch_npu 插件直接在 Ascend 上跑。注意，是"能跑"，不是"跑得好"。真正吃性能的部分——自定义 CUDA kernel、MoE All-to-All 通信、FlashAttention 变体——通常需要针对 Ascend 重写或者调用华为/社区专门优化的算子。迁移的工作量，大头就在这些地方。
3.3 分布式训练框架与并行策略
大模型训练不是单卡干的活。模型参数动辄几百 G，一张卡根本装不下。这就得靠分布式训练——把模型切成片，分给很多张卡一起算。
切法有很多种：数据并行（DP）是每张卡拿不同的数据，各自算梯度再汇总；张量并行（TP）是把单层的权重矩阵切开；流水线并行（PP）是把不同层分给不同卡，像工厂流水线一样；序列并行（SP）切的是长序列的维度；专家并行（EP）专用于 MoE 模型，不同专家放不同卡上；上下文并行（CP）处理超长上下文的切分。实际训练中往往是好几种并行策略组合着用。
| 并行策略 | GPU 生态实现 | Ascend 生态实现 |
|---|---|---|
| 数据并行（DP） | PyTorch DDP、FSDP、DeepSpeed ZeRO | MindSpeed-LLM DP、HCCL All-Reduce |
| 张量并行（TP） | Megatron-LM TP、PyTorch Tensor Parallel | MindSpeed-LLM TP（ intra-node ） |
| 流水线并行（PP） | Megatron-LM PP、DeepSpeed Pipeline | MindSpeed-LLM PP |
| 序列并行（SP） | Megatron-LM SP、DeepSpeed Ulysses | MindSpeed-LLM SP、LongSeq 优化 |
| 专家并行（EP） | Megatron-LM MoE EP、DeepSpeed-MoE | MindSpeed-LLM EP、EPLB（Expert Parallelism Load Balance） |
| 上下文并行（CP） | Ring Attention、Striped Attention | MindSpeed-LLM CP |
| 3D/4D 并行组合 | Megatron-LM 成熟 | MindSpeed-LLM 快速追赶 |
几个关键框架的区别：
- Megatron-LM：NVIDIA 官方维护，GPT/LLaMA/MoE 模型训练的行业标配。跟 NCCL 深度绑定，TP/PP/DP/CP/EP 组合用得最熟。
- DeepSpeed：微软开源，ZeRO-1/2/3 优化显存的思路很巧妙，适合团队不大、不想折腾并行策略的场景。通过 torch_npu 分支也能跑在 Ascend 上。
- MindSpeed-LLM：华为自家的大模型训练主力，2026 年已经支持了 FSDP2、QLoRA NF4、DPO/GRPO 对齐、长序列并行、MoE EPLB 等。
- MindSpeed-RL：专做 RLHF/RL 分布式训练的框架，用 vLLM-Ascend 当 generation engine。
3.4 混合精度与训练优化
现代大模型训练没人用全精度 FP32 了，划不来。业界标配是混合精度训练：计算用 FP16/BF16/FP8 这种低精度来提吞吐，同时保留一个高精度的主权重副本保证训练不跑偏。
NVIDIA 从 Hopper 架构开始硬件原生支持 FP8，到了 Blackwell 又加上 FP4 和 MXFP8（一种块级缩放的浮点格式）。Ascend 这边，910B/C 的 FP8 是靠 CANN 软件层转出来的，不是硬件原生的——这直接影响训练的吞吐上限。950 系列才把 FP8 做到硬件里。
| 技术 | NVIDIA GPU | Ascend NPU |
|---|---|---|
| FP16/BF16 | 全系列支持，BF16 为训练主流 | 全系列支持，BF16 为主流 |
| FP8 | Hopper 原生 FP8；Blackwell MXFP8 块级缩放 | 910B/C 非原生 FP8（CANN 软件转换/量化推理）；950PR/DT 原生支持 FP8/MXFP8/HiF8 |
| FP4 | Blackwell 原生 FP4（推理为主） | 970 规划支持 |
| 梯度缩放 | Transformer Engine、自动 loss scaling | CANN 自动混合精度、梯度缩放 |
| 显存优化 | 梯度检查点、ZeRO、Offload、激活重计算 | 相同技术，MindSpeed-LLM 内置 |
| 通信优化 | NCCL Tree/Ring、PXN、GDR、CUDA Graph | HCCL Ring/Mesh、HCCS 亲和性、NPU Graph EX |
| 长上下文 | Ring Attention、FlashAttention-3 | FlashAttention Ascend 版、LongSeq 优化 |
一句话总结：FlashAttention-3、FP8/MXFP8 极致 kernel、MoE All-to-All 这些真正吃性能的地方，Ascend 上还是需要华为或头部厂商持续手写优化。常规训练已经能平滑迁移了。
3.5 训练场景选型建议
| 场景 | 推荐平台 | 理由 |
|---|---|---|
| 千亿参数预训练 | NVIDIA B200 / GB200 | 单卡算力、显存、互联、框架成熟度最优 |
| 百亿~千亿参数微调 | H100/H200 或 Ascend 910C | H200 显存大适合长上下文；Ascend 适合合规场景 |
| RLHF / GRPO 对齐 | GPU（Megatron/DeepSpeed）或 Ascend（MindSpeed RL） | GPU 生态成熟；Ascend 可用 vLLM-Ascend + MindSpeed RL |
| 长上下文训练（128K+） | H200 / B200 或 Ascend 超节点 | 显存容量和 CP/SP 优化是关键 |
| 国产化/政策合规训练 | Ascend 910C / CloudMatrix | 供应链安全、整机方案、本地化服务 |
3.6 超大规模模型在 Ascend NPU 上的训练实践
参数规格写在纸上是一回事，真有模型在上面训成功了是另一回事。这是全篇最关键的一节——我们来看看哪些模型已经在昇腾上跑起来了。
2024-2026 年，从华为自家的盘古系列，到 DeepSeek、美团、讯飞、百度、智谱、阿里，越来越多的千亿甚至万亿参数模型在 Ascend NPU 上完成了训练。这个名单还在增长。
3.6.1 华为盘古系列（昇腾原生）
| 模型 | 参数规模 | 训练集群 | 关键指标 | 意义 |
|---|---|---|---|---|
| 盘古 Ultra | 135B Dense | 8192 张昇腾 NPU | MFU 52%；13.2T tokens；全流程无 loss 突刺长稳训练 | 首个纯昇腾训练、性能比肩 Llama 405B 的稠密大模型 |
| 盘古 Ultra MoE | 718B（激活 39B） | 6000+ 张 / 万卡级昇腾集群（CloudMatrix 384 超节点） | 初始 MFU 18.9% → 6K 卡 30% → 万卡 41%；实验室优化达 45%；256 路由专家，动态激活 8 专家 | 准万亿参数 MoE，性能媲美 DeepSeek-R1 |
| 盘古 Pro MoE | 72B（激活 16B） | 4000 颗昇腾 NPU | 13T tokens；三阶段预训练 | 2025 年 6 月开源，千亿内参数领先 |
| 盘古 Embedded | 7B | 昇腾 NPU | 端侧小模型 | 开源轻量模型 |
训练中用到的技术创新包括：Depth-Scaled Sandwich-Norm（DSSN）稳定架构、TinyInit 小初始化、EP-Group 负载均衡、Dropless 训练策略、MLA、MTP 等。
插一句：MFU 是什么？ MFU（Model FLOPs Utilization）衡量的是"显卡标称的算力你实际用到了多少"。H100 上成熟模型的 MFU 通常在 45-55%。盘古 Ultra 在 Ascend 上做到了 52%，稠密模型的训练效率已经逼近 GPU。MoE 的 MFU（41%）还偏低，主因是 All-to-All 通信开销大。
3.6.2 DeepSeek 系列
| 模型 | Ascend 训练情况 | 备注 |
|---|---|---|
| DeepSeek-V3 | 官方报告使用 2048 张 NVIDIA H800 训练；后续在昇腾 910B 上完成适配与训练验证 | 原生 CUDA 路径，但成为国内昇腾训练对标和迁移的重要目标 |
| DeepSeek-V4 | 首个公开宣称与昇腾完成全栈适配的万亿参数级 frontier 模型；V4-Pro 1.6T（激活 49B），V4-Flash 284B（激活 13B）；在 Ascend 910B 等昇腾硬件上完成推理适配与训练验证；CANN 针对昇腾生态重写/优化大量算子（具体数量待官方确认） | 2026 年 4 月发布，标志着国产芯片可承载万亿参数级模型训练与推理；原生训练路径与昇腾适配路径并存 |
| DeepSeek-R1 | R1 主要基于 NVIDIA H800 集群训练；昇腾侧主要完成推理适配 | 原生 CUDA 路径；R2 等后续模型的昇腾训练情况尚无权威公开信息 |
DeepSeek-V4 这件事的意义怎么强调都不过分。一个万亿参数的 frontier 模型，公开确认在国产芯片上完成了全栈适配——这不只是技术可行性验证，更是对整个生态的信心注入。
3.6.3 美团 LongCat 系列
| 模型 | Ascend 训练情况 | 关键信息 |
|---|---|---|
| LongCat-2.0-Preview | 2026 年 4 月发布，万亿参数级（1T+），基于 5–6 万张国产加速卡完成预训练 | 目前公开国产算力最大规模训练任务之一；官方未披露具体芯片型号、激活参数与 MFU；支持 1M 上下文；邀请制测试 |
| LongCat-Flash | 560B MoE；完整昇腾适配方案 | vLLM-Ascend 0.13.0+ 已支持 |
| LongCat-Video / LongCat-Image-Edit | 昇腾 NPU 已完成适配与验证 | 提供 AtomGit 适配文档，支持 Ascend 910B3 + CANN 8.0+ |
LongCat-2.0 和 DeepSeek-V4 是同一天发的——两家独立验证了国产算力能支撑前沿级万亿参数模型训练。这不是孤例。
3.6.4 讯飞星火系列
| 模型 | 训练平台 | 关键信息 |
|---|---|---|
| 讯飞星火 V3.0/V3.5/V4.0 | "飞星一号"（昇腾 910B 万卡集群） | 首个全国产算力训练的大模型；训练效率从 30%-50% 优化至 A100 的 85%-95% |
| 讯飞星火 V4.0 Turbo | "飞星一号"/"飞星二号" | 完全基于昇腾算力原生开发 |
| 讯飞星火 X1 | "飞星二号"（万亿参数训练能力） | 深度推理模型，对标 OpenAI o1、DeepSeek-R1 |
| 讯飞星火 X2-Flash（2026.04） | 昇腾 910B 集群 | 30B MoE、256K 上下文；同规模 A800 训练效率从 20% 提升至 90% |
讯飞从 "飞星一号" 开始就是昇腾的深度合作伙伴，训练效率从最初 A100 的 30-50% 一路优化到 85-95%。这个优化曲线很能说明问题——软件优化对 Ascend 训练效率的提升空间非常大，但也意味着"开箱即用"的性能还达不到 NVIDIA 的水平。
3.6.5 百度 ERNIE / 文心
| 模型 | Ascend 训练情况 | 关键指标 |
|---|---|---|
| ERNIE 4.5 | 2025 年开源，PaddlePaddle 支持昇腾 NPU 适配与训练；官方技术报告披露的 MFU 数据基于 NVIDIA H800 | 300B 总参 / 47B 激活（A47B）MoE；预训练 MFU 47%（H800）；FP8 混合精度；3D 混合并行 |
| 文心系列 | 已有昇腾适配版本，支持在昇腾上进行训练与推理 | 百度与华为在大模型国产化上有持续合作 |
3.6.6 智谱 GLM 系列
| 模型 | Ascend 训练情况 | 关键信息 |
|---|---|---|
| GLM-4.5 | 355B（激活 32B）/ GLM-4.5-Air 106B（激活 12B）MoE；后训练基于 slime 框架 | 23T tokens；128K 输入 / 96K 输出；slime 支持昇腾后端 |
| GLM-Image | 首个基于自主创新算力底座（昇腾 + 昇思 MindSpore）全程训练的 SOTA 多模态模型 | 昇腾 Atlas 800T A2 + MindSpore；动态图多级流水下发、多流并行、昇腾亲和高性能融合算子 |
GLM-Image 是第一个"从训练到部署全程国产"的 SOTA 多模态模型，MindSpore 在这件事上发挥了关键作用。
3.6.7 通义千问 Qwen 系列
| 模型 | Ascend 训练情况 | 关键信息 |
|---|---|---|
| Qwen3 / Qwen2.5-VL 等 | 华为云 ModelArts 官方支持 昇腾 NPU 训练 | 支持预训练、SFT 全参微调、LoRA、GRPO 强化学习 |
| Qwen2.5-7B GRPO 案例 | 昇腾 NPU 强化学习训练 | 数独任务准确率从 41.6% 提升至 89.6% |
3.6.8 其他国产模型与平台
| 项目 | Ascend 训练情况 |
|---|---|
| 昇腾 384 超节点 / Atlas 900 A3 SuperPoD | 384 颗昇腾 910C + 192 颗鲲鹏 CPU，MatrixLink 全对等互联；BF16 稠密算力 300 PFLOPS、HBM 总容量 48 TB；支持万亿/十万亿参数大模型训练，算力利用率 45%+ |
| 中国移动/电信/联通等运营商大模型 | 大量基于昇腾集群训练的行业/政企大模型 |
| 金融行业大模型 | 工商银行、建设银行等基于昇腾训练专属大模型 |
3.6.9 训练实践总结
| 维度 | 现状 |
|---|---|
| 可用规模 | 从千卡到万卡级昇腾集群已可训练百亿~准万亿参数模型 |
| 代表模型 | 盘古 Ultra/Ultra MoE、DeepSeek-V4（昇腾适配）、LongCat-2.0（1T+）、讯飞星火 X2-Flash、ERNIE 4.5（昇腾适配）、GLM-4.5/GLM-Image、Qwen 系列 |
| 算力利用率 | 稠密模型可达 52%（盘古 Ultra）；MoE 模型可达 41%（盘古 Ultra MoE，万卡）；ERNIE 4.5 在 H800 上达 47% |
| 与 NVIDIA 差距 | 单卡 BF16 算力：910B 约 H100 的 38%，910C 约 79%；集群训练效率约为 H100/H800 的 35%~70%，依赖超节点和软件优化弥补 |
| 关键挑战 | 超长稳训练稳定性、MoE All-to-All 通信、FP8 极致优化、大规模 RL 训练 |
| 发展趋势 | 2026 年 Q4 Ascend 950DT 上市后，2027–2028 年 960/970 逐步落地，训练效率有望进一步接近 NVIDIA |
注：单卡算力对比基于官方标称峰值；如果按 910B 实际常见的 256–320 TFLOPS 来算，跟 H100 的差距还会更大。集群训练效率受软件优化、并行策略、网络拓扑影响很大，不同团队的技术能力会导致结果差异显著。
4. 大模型推理生态对比
推理是模型真正服务用户的阶段。跟训练不同，推理对单卡峰值算力没那么多要求，但对这几个东西特别敏感：显存够不够装模型、量化做得好不好、能不能支持连续批处理（Continuous Batching）、KV Cache 管理灵不灵活。正因如此，推理成了 Ascend 跟 NVIDIA 差距最小的战场——硬件门槛低，软件优化空间大。
4.1 推理硬件对比
| 维度 | NVIDIA GPU | Ascend NPU |
|---|---|---|
| 主力推理芯片 | H100、H200、B200、L40S、RTX 4090/5090 | Ascend 310P、910B/C、950PR |
| 推理专用芯片 | B200（FP4 推理）、L40S | 950PR（推理优化） |
| 显存容量 | H200 141GB、B200 192GB 适合大模型单卡部署 | 910B 64GB、950PR 128GB、950DT 144GB |
| INT8/FP8/FP4 支持 | 全系列成熟，TensorRT-LLM 深度优化 | 910B/C INT8 成熟、FP8 为软件层支持；950PR/950DT 原生 FP8/FP4 |
| 推理能效 | L40S/RTX 系列在离线推理性价比高 | 310P 在边缘推理有布局，Atlas 800I 用于数据中心 |
| 集群推理 | DGX/HGX + vLLM/TensorRT-LLM | Atlas 800I A2/A3 + vLLM-Ascend/MindIE |
补充一个细节：推理时每个新生成的 token 都要做一次"回头看"——attention 到之前所有的 token。如果不缓存 Key 和 Value，每个 step 都要从头算，计算量跟序列长度的平方成正比。KV Cache 就是把这些中间结果存下来复用的机制，直接影响推理吞吐和延迟。这也是为什么显存容量对推理这么重要——KV Cache 吃显存吃得很凶。
4.2 推理软件栈对比
| 层级 | NVIDIA GPU | Ascend NPU |
|---|---|---|
| 服务化引擎 | vLLM、TensorRT-LLM 4.0、SGLang、TGI | vLLM-Ascend、MindIE、SGLang（适配中） |
| 量化工具 | TensorRT-LLM、AutoGPTQ、AWQ、GPTQ | MindIE Turbo（已并入 vLLM-Ascend）、AOE 量化 |
| Attention 优化 | FlashAttention-2/3、PageAttention | Ascend FlashAttention、PageAttention Ascend 版 |
| Serving 框架 | Triton Inference Server、NVIDIA NIM | MindIE-Service、ModelArts 推理 |
| KV Cache 管理 | vLLM PagedAttention、LMCache | vLLM-Ascend KV Pooling、LMCacheAscendConnector |
| PD 分离 | vLLM / SGLang PD disaggregation | vLLM-Ascend PD 分离、MindIE 原生前后端分离 |
| Profiler | Nsight、PyTorch Profiler | MindStudio Insight、CANN Profiler |
vLLM-Ascend 是目前昇腾推理的事实标准。到 2026 年，它已经支持了 DeepSeek-V3/V3.2/R1、Qwen3、GLM5、Kimi-K2、MiniMax-m2 等主流模型。MindIE Turbo 的功能也合并进 vLLM-Ascend 了，不用单独装。核心能力包括 ACLGraph/NPU Graph EX、连续批处理、PD 分离、EPLB、投机解码、C8 INT8 KV Cache 等。
这个事的意义在于：vLLM 是当前最主流的开源 LLM 推理引擎，vLLM-Ascend 作为官方社区插件，意味着开发者用完全相同的 API 就能在 GPU 和 Ascend 之间切换。这是 Ascend 推理生态从"能用"到"好用"最关键的一步。
4.3 推理优化技术
| 技术 | GPU 生态 | Ascend 生态 |
|---|---|---|
| 连续批处理（Continuous Batching） | vLLM、TensorRT-LLM、SGLang 标配 | vLLM-Ascend、MindIE 标配 |
| PageAttention / Paged KV Cache | vLLM 首创，SGLang 支持 | vLLM-Ascend 移植并优化 |
| 量化推理 | FP16 → INT8/INT4/FP4/AWQ/GPTQ/FP8 | INT8/FP8 为主，C8 INT8 KV Cache 已支持 |
| 投机解码（Speculative Decoding） | Medusa、Eagle、Lookahead | Eagle3 + MiniMax-M2.5 等已支持 |
| Prefix Caching | vLLM、SGLang | vLLM-Ascend 支持 |
| PD 分离 | vLLM / SGLang | vLLM-Ascend / MindIE |
| 多机推理 / 张量并行 | TensorRT-LLM TP/PP、vLLM TP | vLLM-Ascend TP/PP、MindIE 多机 |
| KV Cache 压缩 | GQA、MLA、KV Cache 量化 | 同技术路线，vLLM-Ascend 适配 |
大趋势很明显：两边都在朝 FP4/INT4 权重量化 + FP8/INT8 KV Cache 这条路线走，目标就是省显存、提吞吐。B200 的原生 FP4 目前领先，Ascend 950/960 系列正在追。
投机解码（Speculative Decoding）是个很有意思的优化：大模型逐 token 生成太慢了。换个思路，拿一个小模型（draft model）先快速生成几个候选 token，再让大模型一次性验证。如果大部分候选对了，就等于"一次验证出了好几个 token"。对 MoE 这种大模型推理，效果尤其明显。
4.4 推理部署模式
| 部署模式 | GPU 生态 | Ascend 生态 |
|---|---|---|
| 单卡本地推理 | Ollama、llama.cpp、vLLM | vLLM-Ascend、MindIE |
| 单机多卡服务 | vLLM、TensorRT-LLM、Triton | vLLM-Ascend、MindIE-Service |
| 多机集群推理 | vLLM + IB/RoCE、TensorRT-LLM + NCCL | vLLM-Ascend + HCCL、MindIE |
| 云原生 / K8s | Triton + K8s、vLLM production stack | MindIE + ModelArts + 华为云 CCE |
| 边缘推理 | Jetson、RTX 系列 | Ascend 310P 边缘设备 |
| Serverless/API | NVIDIA NIM、Fireworks、Together | 华为云 ModelArts、昇腾云服务 |
4.5 推理场景选型建议
| 场景 | 推荐平台 | 理由 |
|---|---|---|
| 高吞吐在线服务（70B+） | H200 / B200 + vLLM/TensorRT-LLM | 显存大、量化成熟、吞吐极限高 |
| 国产化在线服务 | Ascend 910C/950PR + vLLM-Ascend | 供应链安全，接口与 vLLM 一致 |
| 长上下文推理（128K+） | H200 / B200 或 Ascend 950PR | 显存容量决定可服务上下文长度 |
| MoE 模型推理（DeepSeek-V3/V4） | B200 或 Ascend 910C/950PR | EP + 量化 + 通信优化是关键 |
| 边缘/端侧推理 | NVIDIA Jetson/RTX 或 Ascend 310P | 功耗和成本优先 |
| 快速 PoC / 统一接口 | vLLM（GPU）或 vLLM-Ascend（NPU） | 同一套 API，迁移成本最低 |
5. 社区框架与工具对 Ascend NPU 的支持
硬件和华为自研软件栈是 Ascend 生态的"骨架"，开源社区框架的适配程度才是"血肉"。一个芯片平台能不能被开发者接受，最终取决于你日常用的那些工具——LLaMA-Factory、verl、vLLM、SGLang——是不是开箱即用。
好消息是，2024-2026 年，大量主流开源框架完成了 Ascend NPU 适配。坏消息是，适配的深度参差不齐。下面按训练微调、RL/Post-Training、推理、Hugging Face 生态四个维度来梳理。
5.1 训练与微调框架
5.1.1 LLaMA-Factory
| 项目 | 详情 |
|---|---|
| 定位 | 统一高效微调框架，支持 100+ LLM/VLM |
| Ascend 支持状态 | ✅ 官方支持（2024 年 5 月宣布） |
| 支持硬件 | Atlas A2/A3 训练系列、Atlas 800I A2 推理系列、Ascend 910B（32GB/64GB） |
| 支持功能 | PT / SFT / RM / DPO；Full / Freeze / LoRA；DDP / FSDP / FSDP2 / DeepSpeed |
| 优化算子 | NpuFusedRMSNorm、NpuFusedSwiGlu、NpuFusedRoPE、NpuFusedMoE |
| 部署方式 | Docker 镜像 hiyouga/llamafactory:latest-npu-a2 或 pip 安装 pip install -e ".[torch-npu,metrics]" |
| 注意事项 | Python 3.10 推荐；QLoRA（bitsandbytes）在 NPU 上存在限制 |
LLaMA-Factory 是社区最活跃的微调框架之一（Star 数超 50k）。官方支持 Ascend 这件事的意义在于：数万开发者可以直接用同样的代码和配置在 NPU 上做微调。这是 Ascend 生态走进大众开发者的关键桥梁。
5.1.2 ms-swift（ModelScope）
| 项目 | 详情 |
|---|---|
| 定位 | 阿里巴巴 ModelScope 出品的 LLM/VLM 训练、推理、部署一站式框架 |
| Ascend 支持状态 | ✅ 官方完整支持，有专门 NPU 文档 |
| 支持训练 | CPT、SFT、DPO、RM、GRPO、PPO |
| 支持并行 | DDP、FSDP、FSDP2、DeepSpeed、MindSpeed（Megatron） |
| 支持 PEFT | Full、LoRA；⚠️ QLoRA 不支持 |
| 支持部署 | PT、vLLM-Ascend；⚠️ SGLang 暂不支持 |
| 典型环境 | CANN ≥ 8.5.1，PyTorch/torch_npu ≥ 2.7.1，vLLM-Ascend 0.18.0+ |
| 特色 | 自动 NPU 模型 patch，ModelScope 模型一键下载，适合国产化落地 |
5.2 RL / Post-Training 框架
RLHF/GRPO 这类后训练方法是 DeepSeek-R1 之后最火的训练范式。它的技术复杂度远高于普通微调——需要同时管训练引擎和推理引擎（用于 rollout 生成），对算子的支持、通信效率、显存管理要求都很高。
5.2.1 verl
| 项目 | 详情 |
|---|---|
| 定位 | 火山引擎开源的灵活、高效、生产级 RL 训练框架 |
| Ascend 支持状态 | ✅ 2026 年 Q1-Q2 将 Ascend NPU 作为一等公民支持 |
| 训练后端 | MindSpeed-LLM、MindSpeed-MM、Megatron-LM、FSDP |
| 推理引擎 | vLLM-Ascend、SGLang |
| 支持硬件 | Atlas 200T A2、Atlas 900 A2 PODc、Atlas 800T A3 |
| 典型版本 | CANN 9.0.0、PyTorch 2.9.0、torch_npu 2.9.0.post2、vLLM-Ascend 0.18.0 |
| 2026 Q2 重点 | Qwen3.5、DeepSeek-V4（verl 路线图规划）、GLM-5 支持；mxfp8/int8 rollout；GPU/NPU 行为一致性 |
5.2.2 OpenRLHF（社区版）
| 项目 | 详情 |
|---|---|
| 定位 | 开源 RLHF 框架，支持 PPO/GRPO/DPO/KTO/REINFORCE++ |
| Ascend 支持状态 | ⚠️ 社区维护版（非华为官方），基于 OpenRLHF v0.6.2 适配 |
| 支持算法 | SFT、DPO、KTO、RM/PRM、REINFORCE++、GRPO、PPO |
| 依赖版本 | CANN 8.0.RC3/8.1.RC1、torch/torch_npu 2.5.1、vLLM-Ascend 0.7.3、DeepSpeed |
| 限制 | 不支持 Ring Attention、Hybrid Engine、PyTorch Compile、bitsandbytes、flash-attn（用 npu_fusion_attention 替代） |
5.2.3 MindSpeed RL（华为官方）
| 项目 | 详情 |
|---|---|
| 定位 | 华为官方面向 Ascend NPU 集群的 RL 训练框架 |
| 架构 | vLLM-Ascend 作为 generation engine，MindSpeed 作为 training engine |
| 支持算法 | PPO、GRPO、PF-PPO、DAPO、DPO 等 |
| 并行策略 | TP、PP、DP、CP、EP、All2All EP |
| 特色优化 | Transfer Dock、Allgather-Swap、融合算子（FlashAttention、RMSNorm、RoPE、SwiGLU、MatmulAdd、GMM） |
| 性能 | 相比 OpenRLHF/VeRL 吞吐提升 1.42× ~ 3.97× |
| 状态 | 2026 年 4 月宣布完成既定开发目标，后续以迭代优化为主；新特性建议迁移至 verl 昇腾实践 |
5.2.4 slime-ascend
| 项目 | 详情 |
|---|---|
| 定位 | 智谱 AI 的 LLM Post-Training / RL scaling 框架（slime v0.2.4 昇腾适配版） |
| 项目地址 | gitcode.com/Ascend/slime-ascend |
| 架构 | Megatron + SGLang |
| 支持模型 | GLM-5、Qwen3、DeepSeek V3/V3.1/R1、Llama 3 |
| 用途 | GLM-5 等模型的后训练与 RL 训练 |
5.3 推理引擎
5.3.1 vLLM-Ascend
| 项目 | 详情 |
|---|---|
| 定位 | vLLM 官方社区维护的 Ascend NPU 插件 |
| 状态 | ✅ 昇腾推理的事实标准入口 |
| 支持模型 | DeepSeek-V3/V3.2/R1、Qwen3/3.5、GLM5、Kimi-K2、MiniMax-m2 等 |
| 核心特性 | ACLGraph / NPU Graph EX、连续批处理、PD 分离、EPLB、投机解码、C8 INT8 KV Cache、KV Pooling |
| 版本 | v0.18.0（稳定）、v0.19.1rc1（预览） |
5.3.2 SGLang
| 项目 | 详情 |
|---|---|
| 定位 | 高性能 LLM Serving 引擎，擅长结构化生成和复杂前端 |
| Ascend 支持状态 | ✅ 2025 年 7 月起官方支持，2026 年 Q1-Q2 持续迭代 |
| 2026 Q2 重点 | PD 分离、投机解码、层次化 Cache（HiCache）、Mooncake NPU、K8s/LWS/RBG 大规模部署、950PR/DT 优化 |
| 支持模型 | DeepSeek-V2/V3/V3.2/V4、Kimi-K2、Qwen3/Qwen3-MoE/Qwen3-Next、LongCat、多模态模型 |
5.3.3 MindIE
| 项目 | 详情 |
|---|---|
| 定位 | 华为自研推理引擎，原生支持昇腾 |
| 状态 | 生产级，面向政企和高合规场景 |
| 注意 | MindIE Turbo 已并入 vLLM-Ascend，无需单独安装；MindIE-SD 仍用于扩散模型 |
5.4 Hugging Face 生态
Hugging Face 就是大模型时代的 "GitHub + PyPI"。transformers、accelerate、peft、trl 这些库是绝大多数开发者的日常工具。Ascend 对它们的支持程度，决定了普通 PyTorch 开发者能不能无痛切过来。
| 组件 | Ascend 支持状态 | 说明 |
|---|---|---|
| transformers | ✅ 通过 torch_npu 自动适配（≥ 4.32.0） | 无需特殊补丁，NPU 作为 PyTorch backend 运行 |
| accelerate | ✅ 通过 torch_npu 适配（≥ 0.22.0） | BF16、FSDP、DeepSpeed 集成可用 |
| peft | ✅ 可用（≥ 0.5.0） | LoRA/Prefix Tuning 等可用 |
| trl | ✅ 可用（≥ 0.5.0） | 与 vLLM-Ascend 配合可在 910B 上运行 GRPO 等 RL 训练 |
| DeepSpeed | ✅ 通过 torch_npu 适配支持 | Atlas 800T A2 及更新平台无需额外 deepspeed_npu 插件 |
不过有个前提得说清楚：Hugging Face 这套路径给的是"GPU 等价能力"，没有 Ascend 专属的 kernel 优化。能跑，但性能不是最好的。追求极限性能的话，还是得用 MindSpeed-LLM、vLLM-Ascend 这些原生优化栈。
5.5 选型速查表
| 需求 | 推荐框架（Ascend） | 备注 |
|---|---|---|
| 快速 SFT/LoRA 微调 | LLaMA-Factory、ms-swift | 易用、社区活跃、文档完善 |
| 大规模预训练 / 全参数训练 | MindSpeed-LLM、Megatron-LM + torch_npu | 华为官方优化，并行策略最全 |
| RLHF / GRPO / PPO | MindSpeed RL、verl、ms-swift | MindSpeed RL 性能最强；verl 生态最灵活 |
| OpenRLHF 用户迁移 | 社区 OpenRLHF-NPU fork | 迁移成本最低，但功能有限制 |
| 智谱 GLM 系列后训练 | slime-ascend | 与 SGLang 集成 |
| 高吞吐在线推理 | vLLM-Ascend | 事实标准，模型覆盖最广 |
| 结构化生成 / 复杂前端 | SGLang（NPU 适配中） | 2026 年 Q2 功能快速补齐 |
| 政企合规推理 | MindIE | 华为自研，原生支持 |
| Hugging Face 用户快速落地 | transformers + accelerate + trl | 零迁移成本，性能需二次优化 |
6. 关键融合算子与加速库
框架是骨架，融合算子（Fused Kernel）才是大模型性能的肌肉。在现代 GPU/NPU 上，算瓶颈早就不是矩阵乘法了——而是显存带宽。数据在显存和计算单元之间搬来搬去，比计算本身更花时间。
融合算子的思路很简单：把多个连续操作——比如 Attention 里的 QK 矩阵乘 + Softmax + V 加权求和——合并成一个 kernel，中间结果不用写回显存，省掉一大笔搬运开销。
6.1 FlashAttention / MLA
6.1.1 GPU 生态
| 算子/项目 | 组织 | 状态 | 说明 |
|---|---|---|---|
| FlashAttention | Tri Dao / Stanford | ✅ 成熟 | FlashAttention-2/3，Hopper/Blackwell 深度优化 |
| FlashMLA | DeepSeek | ✅ 2025 发布 | DeepSeek MLA 官方 GPU kernel，利用率 67.4% |
| FlashInfer | FlashInfer Team | ✅ 活跃 | 支持多种 Attention 变体、PageAttention、KV Cache 量化 |
| xFormers | Meta | ✅ 成熟 | 综合 Attention/优化库 |
| cuDNN Attention | NVIDIA | ✅ 成熟 | 官方 fused attention，与 Transformer Engine 集成 |
6.1.2 Ascend 生态
| 算子/项目 | 组织 | 状态 | 说明 |
|---|---|---|---|
| Ascend FlashAttention | 华为 | ✅ 可用 | CANN 内置，vLLM-Ascend/SGLang 调用 |
| AMLA | 学术界/华为 | ✅ 2025 论文 | 面向 DeepSeek MLA 的 Ascend 优化 kernel，利用率 86.8%，超过 FlashMLA |
| FastAttention | Huawei Noah's Ark | ✅ 2024 | 首个 FlashAttention2 Ascend 适配，算子级提速 10.7× |
| DFlash Attention | vLLM-Ascend | ✅ v0.19.1rc1 | FULL_DECODE_ONLY 优化 |
_npu_flash_attention_unpad | vLLM-Ascend | ✅ | A2/A3 注意力算子升级，替代 npu_fusion_attention |
| FusedAttention (FA) | CloudMatrix-Infer | ✅ | 融合 FlashAttention 与相邻数据 reshape |
| MLAProlog | CloudMatrix-Infer | ✅ | 融合 RMSNorm、linear projection 等 Attention 前处理 |
| Sparse FlashAttention | TileLang-Ascend | ✅ 2026.03 | 稀疏注意力 Ascend 实现 |
GPU 侧 FlashAttention-3 和 cuDNN Attention 最成熟，Ascend 侧 FlashAttention 已可用，但 FlashAttention-3 级别的特性还在补齐。
有一个特别值得拿出来说的亮点：MLA（Multi-head Latent Attention）是 DeepSeek-V2/V3/V4 的核心创新，通过低秩压缩大幅减少 KV Cache 的显存占用。AMLA 在 Ascend 上做到了 86.8% 的算力利用率，超过了 DeepSeek 官方 FlashMLA 在 GPU 上的 67.4%——这是 Ascend 在关键算子上反超 GPU 的罕见案例。
6.2 DeepEP / MoE 通信优化
6.2.1 GPU 生态
| 项目 | 组织 | 说明 |
|---|---|---|
| DeepEP | DeepSeek | MoE 专家并行 all-to-all 通信库，低延迟模式支持 sub-150μs，Normal 模式支持大 batch |
| DeepSeek-V3 EP | DeepSeek | 生产级 MoE EP 实现 |
| Megatron-LM MoE | NVIDIA | EP + TP 组合优化 |
| Tutel | Microsoft | 早期 MoE 优化库 |
6.2.2 Ascend 生态
| 项目 | 组织 | 说明 |
|---|---|---|
| DeepEP-Ascend | 华为昇腾生态团队 | 昇腾原生 EP 通信后端，兼容 DeepEP API；低延迟模式已支持 DeepSeek-V3 推理，sub-150μs |
| ascend_fuseep | SGLang NPU | 昇腾原生融合算子，用于 decode-only 量化模型 |
| Fused W4A8 Kernel | vLLM-Ascend | 融合 W4A8 dispatch + FFN + combine |
| DispatchFFNCombine | vLLM-Ascend | MoE 专家并行自定义算子 |
| MC2 dispatch/combine | vLLM-Ascend | MXFP4/MXFP8 量化下的 MoE 调度归并 |
| EPLB | MindSpeed-LLM / vLLM-Ascend | Expert Parallelism Load Balance，专家负载均衡 |
DeepEP-Ascend 基本实现了跟 GPU 版 DeepEP 的功能对齐，但在一些场景下（比如 SGLang MoE）还是比 vLLM-Ascend 原生的 HCCL all-to-all 慢大约 23%。
为什么 MoE All-to-All 这么要命？因为在 MoE 模型里，每个 token 得路由到不同的专家，而不同专家分布在不同的卡上。每个 Transformer 层都要做一次 All-to-All 通信。推理的 decode 阶段，每次只生成一个 token，那通信延迟（而不是带宽）就是瓶颈。DeepEP 的低延迟模式（sub-150μs）就是专门解决这个问题的。
6.3 其他关键融合算子
| 算子 | GPU 生态 | Ascend 生态 |
|---|---|---|
| Fused RMSNorm | Triton/CUDA kernel 广泛可用 | NpuFusedRMSNorm、MindSpeed RL 融合算子 |
| Fused RoPE | CUDA kernel | NpuFusedRoPE |
| Fused SwiGLU | CUDA kernel | NpuFusedSwiGlu |
| Fused MoE | NVIDIA MoE fused kernel | NpuFusedMoE |
| Fused Matmul + AllReduce + Add + RMSNorm | 部分框架支持 | vLLM-Ascend npugraph_ex 已集成 MatmulAllReduceAddRMSNorm |
| GMM (Grouped MatMul) | CUTLASS/Triton | MindSpeed RL 融合算子 |
| KV Cache Quantization | INT8/FP8 KV Cache | C8 INT8 KV Cache（GQA 模型）、FP8 KV Cache（950 系列原生支持） |
| Liger-Kernel | GPU 生态广泛支持 | ❌ 暂不支持 NPU |
6.4 算子开发工具
| 工具 | GPU 生态 | Ascend 生态 |
|---|---|---|
| 底层语言 | CUDA C++ | Ascend C |
| DSL/Tiling 工具 | Triton、CUTLASS | TBE、Ascend-Triton |
| 编译/IR 工具 | nvcc、MLIR NVGPU | CANN 编译器、MindIR |
| 新兴 DSL | TileLang | TileLang-Ascend（2026 年发布 FlashAttention、DeepSeek-V4 kernel） |
| 自动调优 | nvFuser、Triton autotune | AOE（Ascend Optimization Engine） |
| 性能分析 | Nsight Compute | MindStudio Insight Profiler |
Ascend 在 FlashAttention、MoE EP、MLA 这些关键算子上，已经从"能用"走到了"好用"。DeepEP-Ascend、AMLA、TileLang-Ascend 是 2025-2026 年的三个里程碑。但跟 NVIDIA 比，第三方社区贡献的算子丰富度——比如 Liger-Kernel——还有明显差距。
7. 其他竞争者（简要）
NVIDIA 和华为之外还有谁？简单提一下，建立个坐标系。
| 厂商 | 产品 | 训练状态 | 推理状态 |
|---|---|---|---|
| AMD | Instinct MI300X / MI350 | ROCm + PyTorch 可用，软件成熟度追赶 CUDA | vLLM/ROCm 支持逐步完善 |
| Intel | Gaudi2 / Gaudi3 | PyTorch-Habana 可用，生态较弱 | 性价比高，特定客户采用 |
| 国内其他 | 寒武纪思元、海光 DCU、天数智芯、燧原 | 部分支持 PyTorch，集群规模有限 | 各有限定场景，生态差距明显 |
目前的格局很清楚：NVIDIA 全球领先 → 昇腾国内主力 → AMD/Intel 当第二供应商。AMD 的 MI350 系列和 ROCm 生态是 2026-2027 年最值得关注的变量——如果能搞定软件成熟度，它可能是第三个选择。
8. 趋势判断
写到这里，整个对比已经有结论了。八个趋势分享一下：
训练端：NVIDIA 还是绝对主流，但昇腾靠 MindSpeed-LLM + 超节点 + 国产化政策，在政企、金融、电信这些封闭市场渗透很快。2027 年之前，NVIDIA 在全球公开市场的训练主导地位不会动摇。
推理端：这是 Ascend 跟 NVIDIA 差距最小的地方，也是最有希望在 2026-2027 年实现"体验平替"的领域。vLLM-Ascend 让迁移成本变得很低。
社区生态在快速补齐：LLaMA-Factory、ms-swift、verl、SGLang、slime-ascend 在 2024-2026 年密集适配 Ascend。选框架不再是被生态锁定的理由。
关键算子追得很快：DeepEP-Ascend、AMLA、TileLang-Ascend 出来了。AMLA 甚至在 MLA 场景反超了 FlashMLA。
软件栈在收敛：
- GPU：PyTorch + vLLM/TensorRT-LLM + NCCL，这没什么悬念。
- Ascend：PyTorch(torch_npu) + vLLM-Ascend + MindSpeed-LLM + CANN/HCCL 成为主路径。MindSpore 主要服务原生和政企场景。
量化是共同方向：FP4、FP8、INT8、MoE 稀疏推理，两边都在押注。谁能先提供"无损"或"低损"的 4-bit 训练推理方案，谁就能在 TCO 上占优势。
竞争从单卡转向集群：单卡性能竞赛的时代快过去了，现在是"机架级/超节点级系统设计"的竞争。互联、散热、供电成了新瓶颈。CloudMatrix 384 vs GB200 NVL72 的对决将在 2026-2027 年展开。
开源 vs 闭源：NVIDIA CUDA 闭源但成熟得无可挑剔；华为 CANN 开源，想复制 Linux 的成功路径来缩短生态差距。但开源能不能真正吸引第三方贡献者，还要时间检验。
结论
说了这么多，来点直接的。
如果你追求极致性能、最新算法最快落地、全球化部署——别想太多，NVIDIA GPU 还是唯一的选择。CUDA 二十年的积累不是开玩笑的，尤其是在自定义 kernel 和最新研究代码的可用性上。
如果你看重国产化、政策合规、供应链安全，或者就是想把成本控下来——Ascend 生态在 2025-2026 年已经可以放心用了，推理侧尤为成熟。DeepSeek-V4 和 LongCat-2.0 的大规模训练已经证明了国产芯片能打。
对于开发者个人来说：掌握 PyTorch + vLLM 就能同时覆盖 GPU 和 Ascend 两套硬件。Ascend 特有的技能集中在 CANN/MindSpeed/HCCL 的调优上。团队里最好至少有 1-2 个人熟悉 Ascend 生态。
选框架的话：
- 微调 → LLaMA-Factory 或 ms-swift
- RLHF/Post-Training → MindSpeed RL 或 verl
- 推理 → vLLM-Ascend
- Hugging Face 快速落地 → transformers + accelerate + trl，后面按需切原生栈
算子优化这层：
- Attention → Ascend FlashAttention / AMLA / DFlash
- MoE 通信 → DeepEP-Ascend / ascend_fuseep / MC2
- 自定义 kernel → Ascend C / TBE / TileLang-Ascend
9. TCO 与成本效益分析
技术说完了，聊聊钱。下面这些价格数据来自供应链、云租赁平台和行业研报的交叉验证。需要提前说明的是，昇腾芯片的实际成交价受渠道、批量、配套服务、政策补贴影响非常大，而且官方不公开零售价——以下数字是高置信度的区间估算，不是精确报价。
9.1 硬件采购成本对比
| 芯片 | 定位 | 单卡市场价（万元 RMB） | 备注 |
|---|---|---|---|
| NVIDIA H100 SXM5 | 训练旗舰 | 22–30 | 官方约 $25k–$30k；受出口管制，国内实际采购可能显著溢价 |
| NVIDIA H200 SXM5 | 训练/推理 | 30–40 | 141GB 显存，长上下文溢价 |
| NVIDIA B200 SXM6 | 训练/推理 | 40–55 | 192GB 显存，FP4 推理 |
| 昇腾 910B | 训练 | 5–12 | 2025 年主力，逐步减产 |
| 昇腾 910C | 训练/推理 | 11–20 | 双晶粒封装，128GB HBM，价格受 HBM 成本波动 |
| 昇腾 950PR | 推理/预填充 | 7–7.5 | 2026 Q1 商用，128GB HBM，推理主力 |
| 昇腾 950DT | 训练/解码 | 8–15 | 2026 Q4 上市，144GB HBM；早期预估差异大，实际以官方/代理商报价为准 |
华为芯片通常以整机柜或服务器形式销售，单卡价是反推的。910B/910C 价格受制裁、产能、批量影响波动大，H100 在国内实际采购价可能远高于海外零售价。
9.2 云端租赁成本对比
以 8 卡服务器每小时租赁价为统一口径：
| 平台/硬件 | 配置 | 每小时价格 | 备注 |
|---|---|---|---|
| Spheron H100 spot | 8×H100 SXM5 | ~$8.24（≈¥59） | 竞价实例，最便宜 |
| Lambda Labs H100 | 8×H100 SXM | ~$20–28（≈¥144–200） | 稳定按需 |
| AWS P5 / GCP A3 | 8×H100 | ~$55–88（≈¥396–633） | 超大规模云，含 SLA |
| 昇腾 910B（算力云） | 8×910B | ¥20–45 | 第三方算力平台 |
| 昇腾 910B（AutoDL） | 1×910B | ¥3.68/小时 | 按月/年折扣 |
| 华为云 ModelArts | 昇腾训练实例 | 按需/包年包月 | 无公开按小时价，需询价 |
几个有意思的观察：
- 海外 neo-cloud 的 H100 spot 价格已经跌了不少（2023 年顶峰 $8/GPU·hr，现在 $1-3/GPU·hr）。
- 昇腾 910B 租赁价跟海外 neo-cloud H100 差不多，但比 AWS/GCP/Azure 便宜一大截。
- 如果你的工作负载能容忍中断，H100 spot 还是有成本优势的。需要国产化合规的话，昇腾基本是唯一选项。
9.3 训练成本估算
拿 Llama3-70B Dense 模型预训练 1T tokens 来算：
| 平台 | 集群规模 | 单卡有效吞吐 | 训练时长 | 租赁总成本（估算） |
|---|---|---|---|---|
| H100 SXM5 | 1024 卡 | ~250 tokens/s/GPU | ~46 天 | ~$1.1M（spot）/ ~$2.8M（neo-cloud 按需）/ ~$7.6M（AWS/GCP） |
| 昇腾 910B | 1024 卡 | ~150 tokens/s/GPU | ~77 天 | ~¥470–710 万 |
| 昇腾 910C | 1024 卡 | ~300 tokens/s/GPU | ~38 天 | ~¥350–550 万 |
注：仅算力部分的粗略估算。H100 spot 按 $1.03/GPU·hr、按需按 $2.5/GPU·hr、AWS 按 $6.88/GPU·hr 估；昇腾按 ¥2.5–3.75/GPU·hr 估。
9.4 推理成本估算
DeepSeek-V3/R1 671B MoE 推理：
| 平台 | 部署形态 | 输入 $/M tokens | 输出 $/M tokens | 备注 |
|---|---|---|---|---|
| H100 集群 | 8×H100 + vLLM | 参考市场价 | 参考市场价 | 满血版部署成本高 |
| 昇腾 910B 集群 | 8×910B + vLLM-Ascend | 低于 H100 20–40% | 低于 H100 20–40% | 国产算力补贴后更优 |
| 昇腾 950PR/DT 集群 | 超节点 + vLLM-Ascend | 预计进一步下降 | 预计进一步下降 | 2026 年 H2 规模化 |
华为自己的数据：CloudMatrix 384 超节点部署 DeepSeek-R1，50ms 时延约束下能做到 1,920 tokens/s/卡 的 decode 吞吐。
9.5 TCO 结论
| 场景 | 推荐平台 | 理由 |
|---|---|---|
| 极致成本敏感 + 可中断训练 | H100 spot / B200 spot | 当前云租赁价最低 |
| 国产化合规 + 本地化部署 | 昇腾 910B/C / 950 系列 | 硬件采购价低，无出口管制风险 |
| 长上下文训练/推理 | H200 / 950DT | 显存容量决定可服务规模 |
| 大规模 MoE 推理 | CloudMatrix 384 / GB200 NVL72 | 超节点互联降低通信成本 |
10. 版本兼容矩阵
这是 Ascend 生态最让人头疼的一点——软件栈各组件之间的版本耦合得非常紧，CANN / PyTorch / torch_npu / vLLM-Ascend / MindSpeed 必须精确匹配，差一个小版本号就可能出各种奇怪的运行时错误。
GPU 生态很少这样——CUDA 11.x 和 12.x 可以共存，PyTorch 版本兼容性也好得多。这是 Ascend 生态还不够成熟的一个表现，也是新手最容易踩的坑。
10.1 训练栈推荐组合
| 用途 | CANN | PyTorch | torch_npu | MindSpeed-LLM | Python | 说明 |
|---|---|---|---|---|---|---|
| 主流训练 | 8.5.1 | 2.7.1 | 2.7.1.post2 | core_r0.16.0 | 3.10/3.11 | 当前最稳定组合 |
| 新特性训练 | 9.0.0 | 2.9.0 | 2.9.0.post2 | core_r0.16.0+ | 3.10/3.11 | 支持 FP8/新模型 |
| verl RL 训练 | 9.0.0 | 2.9.0 | 2.9.0.post2 | core_r0.16.0 | 3.10/3.11 | verl 官方验证栈 |
10.2 推理栈推荐组合
| 用途 | CANN | PyTorch | torch_npu | vLLM-Ascend | triton-ascend | 说明 |
|---|---|---|---|---|---|---|
| 稳定推理 | 8.5.1 | 2.9.0 | 2.9.0.post1+git4c901a4 | 0.18.0 | 3.2.0.dev20260322 | 官方推荐稳定版 |
| A3/A5 新硬件 | 9.0.0 | 2.9.0 | 2.9.0.post2 | 0.18.0/0.19.1 | 3.2.1 | 支持 310P、Qwen3-Omni |
| 生产 K8s | 9.0.0 | 2.10.0 | 2.10.0 | 0.20.2rc1 | 配套版本 | MindIE Service 推荐 |
10.3 社区框架版本要求
| 框架 | 最低 CANN | 推荐 torch_npu | 推荐 vLLM-Ascend | 备注 |
|---|---|---|---|---|
| LLaMA-Factory | 8.0.RC1+ | 2.5.1+ | - | NPU-A2/A3 Docker 镜像可用 |
| ms-swift | 8.5.1 | 2.7.1+ | 0.18.0+ | 自动 NPU patch |
| verl | 8.3.RC1+ | 2.8.0+ | 0.18.0 | RL 训练 |
| SGLang | 8.5.0 | 2.8.0 | - | 2026 Q1 目标 |
| OpenRLHF-NPU | 8.0.RC3/8.1.RC1 | 2.5.1 | 0.7.3 | 社区维护版 |
10.4 版本锁定注意事项
- torch_npu 2.9.0.post1 不能通过默认 pip 装，得从华为 OBS 仓库手动下载 whl。
- vLLM 和 vLLM-Ascend 版本必须严格一致（比如 0.18.0 + 0.18.0）。
- 升级 CANN 通常要同步升级驱动、固件、toolkit、nnal、kernels 五个包，很麻烦。
- Python 3.12 支持还在完善，生产环境建议用 3.10 或 3.11。
11. CUDA 到 Ascend 迁移路径与成本
如果你已经有一个 CUDA 代码库，想迁到 Ascend，大约要花多少力气？分三种情况：
11.1 迁移方法
| 方法 | 工作量 | 适用场景 | 关键操作 |
|---|---|---|---|
| 自动迁移（transfer_to_npu） | 低 | 标准 PyTorch 模型，无 custom CUDA kernel | from torch_npu.contrib import transfer_to_npu 一行注入 |
| 脚本转换工具 | 中 | 训练脚本批量替换 CUDA 调用 | 使用 pytorch_gpu2npu.sh 自动转换 |
| 手动迁移 | 高 | 含 custom kernel、复杂并行、性能敏感场景 | 替换 torch.cuda→torch.npu、nccl→hccl、重写 kernel |
11.2 常见不兼容项
| CUDA 侧 | Ascend 侧 | 处理建议 |
|---|---|---|
torch.cuda | torch.npu | 全局替换，注意 non_blocking 行为差异 |
nccl backend | hccl backend | DDP/FSDP backend 字符串替换 |
| Custom CUDA kernel | 需用 Ascend C / TBE 重写 | 性能敏感算子必须重写 |
flash-attn | npu_fusion_attention / Ascend FlashAttention | 框架通常自动 fallback |
torch.compile | 条件跳过 / torchair | NPU 支持仍在完善 |
bitsandbytes / QLoRA | 昇腾原生 INT8/FP8 量化 | QLoRA 支持有限 |
triton CUDA kernel | triton-ascend | 部分支持，需验证 |
xformers | 标准 PyTorch Attention | 自动降级，性能可能下降 |
11.3 迁移成本估算
| 项目类型 | 预计周期 | 人力投入 | 主要风险 |
|---|---|---|---|
| 简单 PyTorch 模型 | 1–2 周 | 1 人 | 少量 API 替换 |
| 标准 LLM 训练脚本 | 1–2 个月 | 2–3 人 | 并行策略、通信优化 |
| 含 custom kernel 的模型 | 2–4 个月 | 3–5 人 | 算子重写、精度对齐 |
| 生产级推理服务 | 1–3 个月 | 2–4 人 | 延迟/吞吐调优、K8s 部署 |
11.4 迁移工具链
- 脚本转换：
pytorch_gpu2npu.sh（CANN toolkit 自带） - 精度调试：MindStudio Insight Profiler、CANN Profiler
- 算子分析：AOE（Ascend Optimization Engine）自动调优
- 模型转换：ATC（Ascend Tensor Compiler）、AOE 图优化
12. 实测性能基准
规格表上的 TFLOPS 跟实际跑的体验往往对不上。这一节的数据来自官方技术报告和社区第三方实测，训练看 MFU（算力利用率），推理看吞吐和延迟。
12.1 训练性能参考
| 模型 | 平台 | 配置 | MFU | 备注 |
|---|---|---|---|---|
| Llama3-70B | H100 SXM5 | TP=8/PP=4 | 45–55% | Megatron-LM 优化 |
| Llama3-70B | 昇腾 910B | TP=8/PP=4 | 30–40% | MindSpeed-LLM；约为 H100 的 60–70% 效率 |
| Llama3-70B | 昇腾 910C | TP=8/PP=4 | 40–50% | 接近 H100 水平 |
| DeepSeek-V3 671B | H800 | EP+TP+PP | ~42% | DeepSeek 官方报告 |
| 盘古 Ultra MoE 718B | 昇腾 910C | 万卡集群 | 41% | 华为官方，万卡级 MoE |
| 盘古 Ultra 135B | 昇腾 910B | 8192 卡 | 52% | 纯昇腾稠密模型 |
注：不列具体单卡 tokens/s 数值，因为这个数字跟序列长度、并行策略耦合太紧，容易误导。
12.2 推理性能参考
DeepSeek-R1 671B MoE：
| 平台 | 精度 | TTFT | 50ms 约束下单卡 decode 吞吐 | 备注 |
|---|---|---|---|---|
| H100 SXM5 | BF16/FP8 | ~45 ms | 参考基准 | vLLM/TensorRT-LLM |
| 昇腾 910B | BF16/INT8 | ~52 ms | 1,920 tokens/s | 潞晨优化方案 |
| 昇腾 910B（第三方实测） | BF16 | 73–399 ms | 1.5–9.2 tokens/s/并发 | 并发提升后吞吐下降明显 |
| CloudMatrix 384 | BF16/INT8 | - | 接近 H100 集群 | 超节点互联优势 |
注：1,920 tokens/s 是潞晨/华为披露的峰值优化数据，第三方实测在低并发下显著更低。推理吞吐受 batch size、并发数、序列长度、量化精度、EP/TP 配置的影响极大。
Mistral-7B 在昇腾 910B 上的优化过程（一个很有意思的案例）：
| 优化阶段 | 延迟 | 吞吐 | 提升 |
|---|---|---|---|
| 基线 FP16 | 6,582 ms | 18.2 tokens/s | 1× |
| INT8 量化 | ~867 ms | 138.4 tokens/s | 7.6× |
| 连续批处理 | 进一步降低 | 接近线性扩展 | - |
12.3 关键发现
- 训练侧：单卡 H100 领先 910B 约 50-70%；910C 已经接近 H100 了；集群 MFU 跟软件优化强相关。
- 推理侧：910B 经过 CANN/vLLM-Ascend 深度优化后，跟 H100 的差距可以缩到 5-15%。
- 长上下文：H200/950DT 因为显存容量大，在 128K+ 场景下优势明显。
- MoE 模型：超节点架构（CloudMatrix 384 / GB200 NVL72）对 MoE All-to-All 通信太关键了。
13. 多模态与 Agent 生态
大模型正在从纯文本走向多模态和 Agent，这一章补充下 Ascend 在这两个方向上的支持现状。
13.1 多模态训练框架
| 框架 | 定位 | Ascend 支持 | 代表模型 |
|---|---|---|---|
| MindSpeed-MM | 华为官方多模态大模型套件 | ✅ 原生 | Qwen2VL、InternVL2、CogVideoX、FLUX、SD3.5 |
| ms-swift | 阿里一站式训练/推理框架 | ✅ 完整 | 100+ MLLM（Qwen-VL、InternVL、LLaVA 等） |
| LLaMA-Factory | 统一微调框架 | ✅ 部分 | LLaVA、Qwen-VL 等 |
MindSpeed-MM 支持多模态生成（文生图、文生视频、图生视频）和多模态理解，TP/PP/CP/DSP/分布式优化器/重计算都齐了。
13.2 多模态推理
| 模型 | Ascend 推理引擎 | 状态 | 备注 |
|---|---|---|---|
| Qwen2.5-VL | vLLM-Ascend | ✅ 已支持 | 华为云 ModelArts 最佳实践 |
| InternVL2.5/3.0 | vLLM-Ascend | ✅ 已支持 | Eager/ACLGraph 模式 |
| GLM-Image | MindIE / vLLM-Ascend | ✅ 已支持 | 首个国产芯片全程训练的多模态 SOTA |
| Qwen3-Omni | vLLM-Ascend | ✅ CANN 9.0 | 多模态统一模型 |
13.3 Agent 框架
| 框架 | 厂商 | Ascend 支持 | 说明 |
|---|---|---|---|
| AutoGLM | 智谱 | ⚠️ 推理可部署 | 可基于昇腾推理服务部署，训练多在 GPU |
| ms-swift Agent | 阿里 | ✅ 支持 | 与 Qwen/Qwen-VL 配合，可在昇腾上训练/推理 |
| OpenManus / MetaGPT | 社区 | ⚠️ 依赖 LLM API | 可调用昇腾部署的模型服务 |
| MindSpeed-RL + vLLM-Ascend | 华为 | ✅ 支持 | 面向 Agent/RL 的后训练与推理一体化方案 |
Agent 场景最需要的三个能力：长上下文（128K-1M tokens）—— 昇腾 950DT/CloudMatrix 384 有优势；工具调用/结构化生成—— SGLang 在昇腾上的结构化输出还在完善；多模态感知—— Qwen2.5-VL + InternVL 已经可以端到端在昇腾上跑了。
14. 集群网络与互联拓扑
当模型规模从百亿走向万亿，单卡性能已经不是故事的主角——卡间互联和跨节点网络才是。这一章对比两个生态在 Scale-Up（机内互联）和 Scale-Out（跨机网络）上的方案，重点看 CloudMatrix 384 和 GB200 NVL72 两种超节点设计。
14.1 Scale-Up（卡间互联）
| 技术 | 厂商 | 单卡带宽 | 拓扑 | 延迟 |
|---|---|---|---|---|
| NVLink 4 + NVSwitch | NVIDIA | 900 GB/s | 交换拓扑 | << 1 μs |
| NVLink 5 + NVSwitch | NVIDIA | 1.8 TB/s | 交换拓扑 | << 1 μs |
| HCCS | 华为 | ~392 GB/s | 总线/交换混合 | ~1 μs |
| MatrixLink（光互联） | 华为 | ~784 Gbps / 2.8 Tbps（不同统计口径） | 全对等 All-to-All | << 1 μs |
14.2 Scale-Out（网络扩展）
| 技术 | 厂商 | 单卡带宽 | 协议 | 适用场景 |
|---|---|---|---|---|
| InfiniBand NDR | NVIDIA/Mellanox | 400 Gb/s | RDMA | 超大规模训练 |
| RoCEv2 | 多厂商 | 200–400 Gb/s | RDMA over Ethernet | 成本敏感场景 |
| 华为自研 RDMA / 灵衢 | 华为 | 400 Gb/s+ | 自研 RDMA | CloudMatrix 超节点间扩展 |
14.3 超节点拓扑对比
超节点是 2025-2026 年 AI 基础设施竞争的焦点。NVIDIA 的 GB200 NVL72 把 72 颗 B200 用 NVLink 5 铜缆拧成一个"巨型 GPU"；华为的 CloudMatrix 384 把 384 颗昇腾 910C 用 MatrixLink 光纤全对等互联。两种思路完全不同：NVIDIA 追求单域内极致带宽，华为追求更大域内规模。
| 指标 | NVIDIA GB200 NVL72 | 华为 CloudMatrix 384 |
|---|---|---|
| 单节点 GPU/NPU 数 | 72 | 384 |
| 互联介质 | NVLink 5 铜缆 | MatrixLink 光纤 |
| 内存容量 | ~30 TB 统一显存 | 48 TB HBM + 49.2 TB 共享内存池 |
| BF16 算力 | ~180 PFLOPS | 300 PFLOPS |
| 总互联带宽 | ~130 TB/s | 1229 TB/s（显存/内存带宽聚合；部分来源记为 269 TB/s，统计口径存在差异） |
| 扩展规模 | 576 卡（NVL576） | 官方宣称可扩展至数万卡；部分第三方对比表称最大 16 万卡 |
| 能效 | 更优 | 每 FLOP 功耗高约 2.5× |
| 设计哲学 | GPU 中心化机架 | 全对等超级服务器 |
14.4 对 MoE 训练的影响
MoE All-to-All 通信对 Scale-Up 带宽极度敏感。CloudMatrix 384 的全对等光互联能把 MoE 训练效率损失控在较低的水平——盘古 Ultra MoE 万卡 MFU 做到 41% 就是这么来的。GB200 NVL72 在 72 卡域内提供最高带宽，跨域扩展就得靠 IB/RoCE 了。
15. 推理部署工程实践
这一章写给正在或准备在生产环境部署 Ascend 推理服务的团队。内容来自社区文档和一线工程师的踩坑经验。
15.1 Kubernetes 部署方案
| 方案 | 组件 | 适用场景 | 关键步骤 |
|---|---|---|---|
| vLLM-Ascend + K8s | vLLM-Ascend、Ray/HCCL | 通用在线推理 | 节点打标签 accelerator=huawei-Ascend910、配置 NPU 资源、部署 Service |
| MindIE Service + K8s | MindIE MS、Deployer | 政企生产环境 | 官方 Helm/Deployment、RBAC 配置、日志/数据持久化 |
| SGLang + K8s | SGLang、HCCL | 结构化生成/复杂前端 | 2026 年 Q2 持续完善 K8s/LWS/RBG 支持 |
vLLM-Ascend 生产调优的关键环境变量：
| 变量 | 作用 | 推荐值 |
|---|---|---|
VLLM_ASCEND_ENABLE_MATMUL_ALLREDUCE=1 | 融合 MatMul + AllReduce | 1 |
VLLM_ASCEND_ENABLE_FLASHCOMM=1 | NPU 间通信优化 | 1 |
VLLM_ASCEND_ENABLE_TOPK_TOPP_OPTIMIZATION=0 | 采样优化（异常时关闭） | 0 |
vLLM-Ascend 0.20.2+ 开始，上面这些环境变量逐步弃用，建议迁移到
--additional-config配置项。
15.2 PD 分离（Prefill-Decode Disaggregation）
PD 分离是个重要的推理架构优化。Prefill（一次性算完整个 prompt 的 KV Cache）和 Decode（逐 token 生成）是两类完全不同的负载：Prefill 吃计算，Decode 吃显存带宽。把它们分到不同硬件实例上，可以独立扩缩容，资源利用率高很多。
| 方案 | 状态 | 关键配置 |
|---|---|---|
| vLLM-Ascend PD 分离 | ✅ 支持 | --disaggregation-mode prefill/decode、KV transfer 配置 |
| MindIE 原生前后端分离 | ✅ 支持 | MindIE-Service 配置 |
| SGLang PD 分离 | 🚧 2026 Q2 重点 | --disaggregation-mode decode、Mooncake NPU |
实际经验：
- PD 分离能显著降低 decode 延迟，但会增加 KV Cache 传输开销。
- CloudMatrix 384 这种高带宽 Scale-Up 环境下，KV transfer 瓶颈不大。
- 配置 dp 和 tp 时千万注意一致性，
Expected 1, but got 2这种报错很常见。
15.3 KV Cache 量化
| 量化方案 | 精度 | 显存节省 | 适用模型 | 状态 |
|---|---|---|---|---|
| C8 INT8 KV Cache | INT8 | ~50% | GQA 模型 | vLLM-Ascend 已支持 |
| FP8 KV Cache | FP8 | ~50% | 950PR/DT 等原生 FP8 硬件 | 950 系列原生支持 |
| FP4 KV Cache | FP4 | ~75% | 950PR/DT | 2026 年逐步支持 |
KV Cache 量化对长上下文和 MoE 模型收益最大，但上线前一定要验证精度有没有退化。
15.4 生产部署 checklist
- [ ] CANN/驱动/固件版本与 vLLM-Ascend 匹配
- [ ] NPU 节点标签与资源配额正确配置
- [ ] 模型权重格式与量化配置一致
- [ ] 预热测试：连续批处理、高并发、长序列
- [ ] 监控：NPU 利用率、HBM 占用、通信带宽、请求 P99 延迟
- [ ] 故障演练：单卡故障、节点故障、服务滚动升级
16. 故障恢复与长稳训练
万卡集群跑几周甚至几个月的训练，硬件故障不是"会不会发生"的问题，而是"多久发生一次"。根据 USENIX ATC'25 华为论文的披露，18,000 卡规模的集群上，网络链路故障、NPU 内存错误是常态。长稳训练的可靠性直接决定了大模型训练任务能不能按时交付。
16.1 断点续训（Checkpoint Resume）
| 组件 | 能力 | 说明 |
|---|---|---|
| MindSpeed-LLM | ✅ 原生支持 | 定期保存模型权重、优化器状态、训练迭代数 |
| ModelArts | ✅ 断点续训 + 故障快恢 | 支持 LoRA 除外 |
| MindCluster | ✅ 自动检测 + 重调度 | 节点/Pod 级故障恢复 |
Checkpoint 文件结构示例：
saved_checkpoints/
├── iter_0000010/
├── iter_0000020/
└── latest_checkpointed_iteration.txt # 需与 iter_xxxx 编号一致16.2 故障快恢（Fault Fast Recovery）
华为 MindCluster 提供两种恢复模式：
| 模式 | 适用故障 | 恢复方式 | 优势 |
|---|---|---|---|
| 优雅容错模式 | 部分 NPU 芯片故障 | 退出该芯片训练进程 + 热复位，无需重调度 | 避免任务 Pending |
| 重调度模式 | 节点故障、网络故障 | 删除 Pod，重新调度到健康节点 | 通用兜底 |
16.3 异步 Checkpoint
| 技术 | 作用 | 代表实现 |
|---|---|---|
| 异步分布式 Checkpoint | 隐藏持久化延迟，减少训练中断 | MindSpeed-LLM + MindCluster |
| LowDiff / FlashRecovery | 差分 checkpoint、无 checkpoint 快速恢复 | 学术前沿（arXiv 2025） |
16.4 长稳训练最佳实践
来自 USENIX ATC'25 华为 18,000 卡集群优化经验：
| 问题 | 根因 | 优化措施 | 效果 |
|---|---|---|---|
| 吞吐波动大 | 远程存储日志、网络链路故障、NPU 内存故障 | 日志切本地、修复 spine-leaf 链路、隔离 30 个异常节点 | 方差从 291 降至 31，平均吞吐提升 1.19× |
| step time 过长 | tensor.item() 频繁 CPU-NPU 同步 | 消除同步操作 | step time 54.82 ms |
| CPU 瓶颈 | dataloader 与训练进程绑定同一核心 | CPU 进程解绑 | 8-NPU 训练 1.91× 加速 |
这个案例值得仔细看：tensor.item() 这种看起来人畜无害的操作，在 NPU 上可能成为性能杀手——每次调用都触发一次 CPU-NPU 同步，在大规模训练中累积效应非常明显。
长稳训练 checklist：
- [ ] 开启周期性 checkpoint（建议每 100–1000 step）
- [ ] 配置 MindCluster 优雅容错 + 重调度双保险
- [ ] 监控 NPU 健康状态、网络链路、节点心跳
- [ ] 本地存储日志，避免远程存储成为瓶颈
- [ ] 预跑 burn-in 测试，识别异常节点并隔离
- [ ] 训练前验证 checkpoint 可正确加载
17. 参考来源
- 昇思 MindSpore 官网
- vLLM-Ascend Release Notes
- 华为云 Ascend-vLLM 最佳实践
- H100 vs H200 vs B200: Best NVIDIA GPU for AI Infrastructure 2026
- NCCL Tuning for Multi-GPU LLM Training 2026
- Groundbreaking SuperPoD Interconnect — 华为超节点
- Accelerating Model Training on Ascend Chips — USENIX ATC'25
- AMD Instinct MI300/MI350 Workload Optimization
- CANN、MindSpore、MindIE、MindSpeed、MindStudio/ModelArts/ModelZoo 关系梳理
- Huawei open-sources chip software ecosystem — China Daily
- verl Ascend 2026Q2 Roadmap
- verl Ascend Install Guidance
- verl Ascend Quickstart
- LLaMA-Factory NPU 支持文档
- LLaMA-Factory — vllm-ascend 用户故事
- slime-ascend GitCode
- SGLang Ascend NPU 2026 Q1 Roadmap
- SGLang Ascend NPU 2026 Q2 Roadmap
- OpenRLHF Ascend NPU RFC
- OpenRLHF Ascend NPU Pull Request
- MindSpeed RL arXiv 论文
- MindSpeed RL GitHub
- ms-swift NPU Support 文档
- TRL + vLLM-Ascend GRPO 支持
- Ascend Transformers Gitee
- Ascend DeepSpeed Gitee
- DeepEP-Ascend Proposal
- sgl-kernel-npu GitHub
- SGLang Expert Parallelism
- vLLM-Ascend DeepEP Feature Request
- vLLM-Ascend Flash Attention 文档
- AMLA arXiv 论文
- FastAttention arXiv 论文
- TileLang-Ascend GitHub
- Pangu Ultra MoE: How to Train Your Big MoE on Ascend NPUs — arXiv
- 华为盘古 Ultra MoE 7180 亿参数 — 机器之心
- 华为盘古 Ultra 135B 纯昇腾集群训练 — IT之家
- 华为开源 7180 亿参数盘古 Ultra MoE — 搜狐
- DeepSeek-V3 Technical Report
- DeepSeek V4 on Huawei Ascend — Skywork AI
- DeepSeek V4 Runs on Huawei Chips — AI for Automation
- 讯飞星火 V3.5 基于飞星一号全国产算力训练 — 机器之心
- 讯飞星火 X2-Flash 基于昇腾 910B 集群训练 — IT之家
- ERNIE 4.5 Technical Report
- PaddlePaddle/ERNIE 4.5 开源 — CSDN
- 智谱 × 昇腾 × 昇思：自主创新算力赋能 — 昇腾社区
- 智谱开源 Slime RL Scaling 框架 — CSDN
- Qwen 系列模型基于昇腾 NPU 训练 — 华为云
- 昇腾 NPU GRPO 训练 Qwen — 华为云开发者联盟
- 美团 LongCat-2.0 万亿参数昇腾训练 — 36氪
- 美团 LongCat 基于国产算力训练 — Pandaily
- ERNIE 4.5 Technical Report — 47% MFU on H800
- Huawei Ascend 910B Specifications — awesomeagents.ai
- GLM-4.5 GitHub — 355B/32B and 106B/12B MoE
- 华为 CloudMatrix 384 超节点参数 — 证券之星
- 华为昇腾 950/960/970 路线图 — 新浪财经
- DeepEP-Ascend Low-Latency Performance — sgl-kernel-npu
- AMLA: MUL by ADD in FlashAttention Rescaling — arXiv
- H100 Cloud Pricing 2026 — GetDeploying
- GPU Cloud Pricing 2026 — Spheron
- 昇腾 910B 租赁价格 — 极云科技
- 昇腾 910B 云主机价格 — AutoDL/算力导航
- 昇腾 950PR/950DT 价格与路线图 — 东方财富
- vLLM-Ascend v0.18.0 Release Notes
- verl Ascend Dockerfile Build Guidance
- ms-swift NPU Support — GitHub
- Ascend Model Migration Guide — Huawei
- Model Migration on Ascend NPUs — Medium
- DeepSeek 在昇腾 910B 推理实测 — 掘金
- 昇腾 NPU Mistral-7B INT8 性能调优 — 博客园
- H100 Large-Scale Training Benchmarks — CoreWeave
- MindSpeed-MM Gitee
- vLLM-Ascend Supported Models
- InternVL2.5 Official Blog
- CloudMatrix 384 vs GB200 NVL72 — 今日头条
- MatrixLink Network User Guide — Huawei Cloud
- vLLM-Ascend KV Pool / Ascend Store
- MindIE Service K8s Deployment — Huawei
- vLLM-Ascend PD Disaggregation Practice — CSDN
- MindCluster Fault Recovery Docs — Huawei
- ModelArts Checkpoint Resume Best Practice — Huawei Cloud
- FlashRecovery: Fast Failure Recovery for LLM Training — arXiv
- LowDiff: Efficient Frequent Checkpointing — arXiv
- 昇腾 910B FP8 支持说明 — AwesomeAgents
- vLLM-Ascend Environment Variables / Additional Config
- LongCat-2.0-Preview — 美团万亿参数国产算力训练 — DoNews
- 昇腾 950 系列规格 — 太平洋科技
- 昇腾 910C / 950 路线图 — 新浪财经