DeepSeek 的昇腾移植把 AI 基础设施兼容性变成了一笔可以拆解的预算。应用侧能够复用包名、API 和部分开发流程，性能关键路径则继续依赖数据布局、编译器、内核、通信拓扑和验证环境。真正有用的问题因此变成：哪些层已经省下成本，哪些层仍要重做，以及每一条性能结论需要什么证据才能进入采购和生产决策。
阅读时间：约 8 分钟 · 证据核验日期：2026 年 10 月 6 日
TL;DR
- DeepGEMM-Ascend 保留
deep_gemm包名和公开 API，同时引入昇腾专用的 scale 布局、对齐规则、编译器和 kernel。 - FlashMLA、DeepSelect 在同一 Python 接口下提供 CUDA 与 Ascend 路径，但两边支持的 dtype、索引类型、算子和模型版本存在差异。
- DeepEP-Ascend 延续
EPBuffer抽象，部分集合通信、负载均衡、Engram、graph capture 仍处于开发、实验或未支持状态。 - 官方微基准证明代码能够在指定环境中有效利用硬件。生产替代还要通过整模负载、可靠性、升级和成本门禁。
- 兼容性预算至少包含六层：接口、数据、编译运行时、kernel、通信、生产验证。
把兼容性从布尔值改成预算表
硬件迁移经常被压缩为一个问题：兼不兼容。这个口径会把大量成本藏在同一个绿色勾里。
更实用的表达是：
兼容性预算 =
接口适配
+ 数据与数值适配
+ 编译器和运行时集成
+ kernel 与通信调优
+ 生产验证和运维
+ 后续升级回归
DeepSeek 在 9 月 30 日公开或更新的一组代码，已经明显压低了前几项成本。调用方式更熟悉，参考实现与测试入口公开，Ascend 950 的优化路径也已经存在。仓库同时公开了工具链要求、布局差异、能力缺口和性能条件。预算并未消失，它从应用代码层下沉到了基础设施层。
这正是 T01 基础设施优于组件在硬件迁移中的具体表现。一个 API 能否调用，只决定迁移的起点。数据怎样摆放、代码怎样编译、通信怎样跨卡、结果怎样复现，决定迁移能否完成。
六层兼容边界
| 层级 | 已复用部分 | 仍具平台差异的部分 | 验收证据 |
|---|---|---|---|
| 包名与 API | 包名、公开函数、buffer 抽象 | 参数组合与支持模式 | 导入测试、API 合同测试 |
| 数据与数值 | tensor 角色和上层 dtype 语义 | scale 打包、stride、索引类型、KV layout、累加精度 | 跨后端正确性与误差测试 |
| 编译与运行时 | JIT 流程、部分构建习惯 | CANN、Bisheng、torch_npu、HCCL/HCOMM、设备探测 |
冻结环境矩阵、干净构建 |
| Kernel | 算子名称和参考行为 | CUDA 与 Ascend 的独立实现、调度、流水线和对齐 | 分 shape 正确性与性能曲线 |
| 通信 | EPBuffer 生命周期、dispatch/combine 概念 |
NCCL/NVLink/RDMA 与 UBMEM/URMA/HCCL 拓扑 | 目标拓扑上的多 rank 测试 |
| 生产验证 | 负载定义和服务目标 | 故障、监控、升级、尾延迟和 TCO | 端到端回放、故障演练、合格负载成本 |
上层复用减少代码改动，下层差异决定性能和稳定性。兼容性预算的目标，就是让这两部分分账。
API 复用确实省钱
DeepGEMM-Ascend沿用 deep_gemm 包名，并把 kernel API 指向原版 DeepGEMM。公开范围包含 BF16、FP8、FP4 GEMM、MQA logits 和 MegaMoE 等操作。
DeepEP-Ascend保留 deep_ep 包与 EPBuffer 模型，训练、prefill 和 decode 继续围绕同一套 buffer 生命周期组织。FlashMLA 和 DeepSelect 则把 CUDA 与 Ascend 支持放在同一仓库和 Python 接口下。
这些工作将完整应用重写收敛为后端资格验证。调度逻辑、调用结构和相当一部分测试词汇可以继续使用。对于已经围绕 DeepSeek 基础设施开发的团队，这是直接可计量的迁移收益。
下一层开始支付硬件差异成本。
数据布局是第一笔隐性支出
DeepGEMM-Ascend 明确记录了一项差异：沿 K 维的每两个 UE8M0 scaling factor 会打包进一个 int16，再按 MN-major 保存。仓库专门提供转换函数，因为高效布局已经发生变化。
DeepSelect提供了更直观的能力边界。Ascend 路径当前支持 BF16 输入和 int32 索引；FP32 sampling 与 int64 索引属于 CUDA 路径。输入行还要满足 stride 和连续性要求，TopK 上限为 4096。
FlashMLA在 9 月版本中修改了 FP8、FP4 KV cache 格式，当前分支面向 DeepSeek V4.1，同时移除了 Hopper 和更早 DeepSeek 模型的支持。部分 fused sparse kernel 与 dense MHA 仍为 CUDA-only，Ascend 主要覆盖 sparse prefill 与 decode。
这些差异反映了合理的系统设计。硬件特性不同，高性能实现自然会采用本地布局与调度。工程验收需要把 dtype、shape、stride、模型 revision、KV 格式和误差容限写进合同。共享函数名负责入口一致，能力矩阵负责实际边界。
开发流程可以迁移，工具链和 kernel 需要重建
DeepGEMM-Ascend 的公开要求包括 Ascend 950、CANN 9.20、Bisheng、torch_npu、Python 3.10+ 和支持 C++20 的工具链。FlashMLA 在构建时识别 CUDA 或 Ascend，然后选择各自的源文件。DeepSelect 也分别维护 csrc/cuda_kernels 与 csrc/ascend_kernels。
真正复用的是架构：JIT 编译、Python binding、参考实现、测试入口。真正重写的是机器执行路径。
因此，以下工作都属于兼容预算：
- 冻结经过验证的 driver、firmware、CANN、PyTorch、
torch_npu、编译器和仓库 revision。 - 为每条硬件路径生成不可变镜像。
- 覆盖生产会遇到的 shape、dtype、alignment 和运行模式。
- 分别维护性能基线，因为一个后端的优化可能把另一个后端的瓶颈推到不同位置。
- firmware、编译器、模型布局或 kernel revision 变化后重新验收。
vLLM Ascend 的安装矩阵在更高一层印证了这个逻辑：HDK、CANN、NNAL、PyTorch、TorchNPU、Triton Ascend、vLLM 与 vLLM Ascend 被当作一组兼容版本验证。可用性属于一套冻结栈，而非单独一颗芯片。
通信让拓扑进入兼容合同
大模型系统的限制经常从 GEMM 转移到 dispatch、combine、collective 和跨卡内存访问。
NVIDIA 侧 DeepEP依赖 CUDA、NCCL、NVLink 和 RDMA。DeepEP-Ascend 延续上层 buffer 抽象，底层改为 HCCL/HCOMM、UBMEM 与 URMA。
仓库也列出了当前边界：
- batched all-gather 已提供，Ascend reduce-scatter 与 all-reduce kernel 仍在开发；
- 负载均衡 API 已对齐，对应 Ascend 通信 kernel 尚未完成；
- PP 与 Engram 仍属实验能力；
- hybrid communication、CPU-backed Engram storage 与 graph capture 当前未支持。
于是，同一套 EPBuffer 能否完成迁移，取决于具体工作负载。只使用 expanded dispatch 与 BF16 combine 的系统可能已经具备验证条件。依赖 graph capture、CPU 后备存储或缺失 collective 的系统，还要增加绕行方案和维护成本。
性能数字必须带着测试单元一起走
几个仓库给出了很强的性能信号。
FlashMLA 报告 Ascend 950 sparse prefill 最高 410 TFLOPS，sparse decode 最高 360 TFLOPS，官方分别标注为理论峰值的 95% 和 83%。DeepSelect 报告相对 torch.topk 的 2 至 20 倍加速。DeepEP-Ascend 则公布了多个 EP size 下的 dispatch 与 combine 带宽。
这些数字能够支持三层结论：实现真实存在，公开测试路径存在，代码在指定微基准单元中可以高效利用硬件。
更强的生产结论需要继续升级证据。DeepEP-Ascend 明确说明，其性能结果来自 Ascend 950DT、CANN 9.2.0、DeepSeek 获得的 PoC HDK 和额外手工配置。该配置并非公开发行版。FlashMLA、DeepSelect 的数字同样属于仓库作者运行结果。本次核验没有 Ascend 950 环境，无法执行独立复测。
可以用六级证据阶梯约束结论：
| 级别 | 证据 | 可以支持的结论 |
|---|---|---|
| 1 | 仓库与源码 | 已有公开实现 |
| 2 | 测试与基准方法 | 存在复现路径 |
| 3 | 冻结条件下的厂商结果 | 指定栈达到报告结果 |
| 4 | 目标硬件独立复跑 | 结果可迁移到采购方环境 |
| 5 | 整模负载与故障验证 | 满足生产服务合同 |
| 6 | 持续生产观测与 TCO | 迁移具备长期经济价值 |
接近硬件峰值回答了软件能否驱动本卡。整模 tokens/s、任务质量、集群可靠性、升级成本和运维人力属于后续门禁。
一套可执行的昇腾迁移门禁
第一步：冻结真实负载
记录模型 revision、精度、上下文分布、batch、并发、训练或推理模式、EP size、拓扑、质量目标、延迟目标和故障预算。
第二步：建立能力矩阵
把每项必要操作分成四类：已支持且验证、支持但有约束、实验能力、缺失。数据布局和生命周期行为也要进入矩阵。
第三步：固定完整环境
保留容器 digest、HDK、firmware、CANN、PyTorch、torch_npu、编译器、仓库 commit、运行参数和拓扑。环境本身就是交付物。
第四步：先验正确性
用可信参考实现交叉检查结果，覆盖边界 shape、NaN、padding、alignment、determinism、数值误差和多 rank 行为。量化与 layout 转换完成后，再跑任务级质量评测。
第五步：寻找当前瓶颈
先测 kernel 曲线，再测完整 layer 与端到端回放。共同记录尾延迟、吞吐、显存、通信、编译时间、失败、恢复和合格任务率。每次有效优化后重新定位瓶颈。
第六步：验证运维与升级
演练冷启动、缓存失效、节点丢失、rank 失败、链路降级、回滚、监控和版本升级。第二套硬件后端会增加 CI 单元、镜像、仪表盘、值班知识和发布协调。
第七步：计算合格负载成本
把硬件、能耗、工程时间、支持费用、利用率、重试、故障恢复和升级回归放进同一个分母。比较完成且通过验收的工作负载，而非峰值算力。
这个门禁能够得出三种合理结果：迁移 Ascend、继续 CUDA、保留混合机群。统一证据合同可以让三种决策在同一张表上比较。
DeepSeek 真正改变了什么
DeepSeek 把昇腾支持的起点向前推进了一大步。采用方现在可以从公开、优化过的实现和对齐接口出发，应用结构更容易保留，kernel 团队也有可审计的参考工程。
剩余预算集中在硬件差异真正产生性能的地方：数据表达、编译行为、kernel 调度、通信拓扑和生产验证。DeepSeek 与华为通过模型、kernel、硬件团队的深度协同支付了其中一部分成本。普通采用方继承这些基础设施，再为自己的工作负载完成资格验证。
这比兼容口号更有价值。它给出了一张清楚的分工图：哪些能力可以复用，哪些能力还需要工程时间。
常见问题
原有 DeepGEMM 调用能直接迁到 DeepGEMM-Ascend 吗？
支持范围内可以保留包名和公开 kernel API。高效输入仍需遵守 Ascend 专用 scale 布局、对齐、工具链和硬件条件。源码兼容与运行边界兼容应分别验收。
API 一致能否保证性能一致？
API 一致减少应用改动。性能由 shape、dtype、layout、编译器、kernel、firmware、拓扑和负载共同决定，目标栈仍要重跑正确性与性能。
这些仓库能否覆盖更早的昇腾芯片？
固定版本的 DeepGEMM-Ascend 与 FlashMLA 文档面向 Ascend 950。DeepEP-Ascend 也明确限定了已测环境。其他代际和 CANN 版本需要独立能力矩阵。
官方基准是否足以证明 CUDA 可被替代？
官方基准证明指定测试单元中的实现效率。生产替代还要加入功能覆盖、整模负载、质量、可靠性、运维、升级与 TCO。
最小 PoC 应该做到什么程度？
选一个代表性负载，冻结完整栈，通过跨后端正确性，验证端到端服务目标，再完成一次故障和升级演练。这个小合同比大而全的功能清单更能暴露真实成本。
参考资料
- DeepSeek：DeepGEMM
- DeepSeek：DeepGEMM-Ascend
- DeepSeek：FlashMLA
- DeepSeek：DeepSelect
- DeepSeek：DeepEP
- DeepSeek：DeepEP-Ascend
- vLLM Ascend：版本说明
- vLLM Ascend：验证过的安装矩阵
- Agent Skills 跨工具兼容：四层移植边界
- OpenAI Jalapeño 基准审计：全栈推理闭环
- Qwen3.8-27B 实战评测：先冻结变量
下一步：为目标负载建立一页兼容性台账，把所有必需 API、dtype、shape、collective、编译器版本和故障模式标上证据等级，再进入采购或迁移排期。