正在加载，请稍候
DeepSeek 把昇腾 950 的底层组件摊开了，但「能跑通」和「敢上生产」之间，隔着四个必须自己在目标硬件上跑一遍的核对项。
9 月 30 日，昇腾 950 的底层组件被摊开了。但「能跑通」和「敢上生产」之间，隔着四个必须自己在目标硬件上跑一遍的核对项。
2026 年 9 月 30 日，DeepSeek 开源了一组面向华为昇腾算力平台的基础设施组件，涵盖 TileLang 高级语言编译工具，以及 DeepGEMM、DeepEP、TileKernels、FlashMLA、DeepSelect 的昇腾平台实现。这批组件与此前开源的英伟达平台版本一一对应，覆盖矩阵运算、跨设备通信、常规向量计算与访存、稀疏注意力和数据筛选（来源见文末「参考」）。
其中 TileLang 负责算子开发所用的语言和编译能力，其余五类组件提供可调用的计算与通信实现。它的语法接近 Python，编译基础设施建立在 TVM 之上；9 月 30 日主仓库公布了针对 NPU 的原生后端支持，包括代码生成、自动调度和同步等能力。官方称，昇腾后端通过封装 Ascend C 底层指令，既提供高级语言编程方式，又保留针对硬件做优化的空间。
落到编译路径上：昇腾后端复用了共享前端，并针对 Cube 矩阵计算单元和 Vector 向量计算单元实现专用的编译转换、调度、同步和代码生成。开发者仍需描述数据类型、分块大小和计算操作，编译器承担部分数据搬运、流水线安排以及单元间同步。官方披露，TileLang 已承载 V4 系列模型训练中大部分算子的实现，且训练中用到的每一个算子，在昇腾上都有对应的高性能实现。
这部分是决策者最该逐字读的地方。官方明确：部分组件沿用原平台的上层接口，便于已有调用代码迁移；但具体硬件要求、数据格式与功能支持范围，需要按组件分别确认。跨平台适配仍需结合目标硬件的执行方式调整，而不是改个开关就能切换。
| 组件 | 解决什么问题 | 本次开源后的状态 | 迁移时要单独确认的点 |
|---|---|---|---|
| TileLang | 算子开发语言与编译 | 新增 NPU 后端，支持代码生成、自动调度、同步 | 后端含专用语言接口与存储操作，需按目标硬件执行方式调整 |
| DeepGEMM-Ascend | 矩阵乘法加速 | 支持 BF16、FP8、FP4，API 与原平台兼容 | 量化缩放因子存储格式存在差异，需适配数据布局 |
| DeepEP Ascend | 跨设备通信，MoE 专家并行 all-to-all | buffer API 与原平台对齐，支持 FP8 数据分发 | 流水线并行、上下文并行、数据并行的部分通信能力仍在开发中 |
| FlashMLA | 稀疏注意力计算 | 覆盖预填充与解码两个阶段 | 仓库中仍有部分融合内核及稠密注意力内核仅支持 CUDA |
| TileKernels | 算子库（MoE 路由、量化、位置编码） | 新增昇腾后端，支持运行时自动选择 | 后端要求 CANN 9.2.0 及以上版本 |
| DeepSelect | TopK 数据筛选 | 面向稀疏注意力与采样器场景 | 昇腾实现目前仅支持 BF16 输入，CUDA 实现还支持 FP32 |
把这张表横向读一遍会发现：六类组件没有一个是「完全等价替换」。算子库的卖点是同一组 Python API 可调用英伟达 GPU 和华为 NPU 上的相应实现；矩阵库的接口也保持兼容，可以沿用既有开发流程——但这些兼容都停在接口层。落到数据布局、精度范围、内核覆盖度上，每一项都需要在当前负载上重新验证。这份成本账的另一面——瓶颈如何从算力本身转移到迁移工程量——可以对照站内《DeepSeek 把全套算子搬到昇腾 950：国产算力的瓶颈换成了迁移成本》一起读。
官方同时披露，团队与华为共同推进了基于昇腾 950 的 128 卡超节点方案，并对计算和通信进行了联合优化。对做大规模训练或高并发推理的团队，这比单个算子库更有意义——超节点方案的价值不在单卡算力，而在于把计算单元之间的通信开销压到可接受范围。
对照公开信息可以看清这条脉络：2025 年 1 月，硅基流动与华为云上线基于昇腾的 V3、R1 推理服务；同年 6 月，华为与硅基流动通过 CloudMatrix384 论文披露运行 R1 的超节点推理方案；2025 年 9 月，伴随 V3.2-Exp 发布，昇腾完成 TileLang 适配并开源稀疏注意力及索引算子；2026 年 4 月，华为云在 V4 预览版发布当天宣布完成适配，通过注意力、缓存管理和融合算子等优化，支持百万 token 上下文推理。此次则进一步把编译工具和计算、通信基础库开放出来供开发者调用、修改。
更关键的是精度路线的变化。CloudMatrix384 论文重点讨论 INT8 量化在矩阵运算和数据传输中的应用；此次矩阵库提供 BF16、FP8、FP4 等实现，通信库支持 FP8 数据分发。两者都在用低精度减少开销，但支持的数据格式并不相同——这恰好也是迁移时要逐项核对的典型细节。
把上面的技术事实翻译成项目动作，建议在动手迁移前完成四项核对。这套口径同样适用于国产算力迁移成本的估算和 AI 应用私有化部署的验收——后者可先看两份站内实测：《开源大模型私有化部署实测》与《自托管还是走 API》。
这次发布最容易踩的坑，是把「API 兼容」直接读成「换硬件就完事」。接口兼容解决的是调用方式的问题，行为等价要解决的是数值、性能、边界条件的问题。二者之间隔着数据布局、精度支持范围、内核覆盖度三层差异——上面那张表里每一行的「迁移时要单独确认的点」就是证据。
更现实的提醒来自官方文档自己：通信库的昇腾版说明，现有测试尚未验证其内核对其他昇腾代际或 CANN 版本的支持情况；算子库的昇腾后端则要求 CANN 9.2.0 及以上。也就是说，这套组件的验证环境主要围绕这代 NPU 展开，如果你的集群里混着不同代际的卡或不同版本的 CANN，先把版本矩阵理清楚再排期。不做回归就切换的团队，通常会在上线后第一次遇到低精度溢出或通信超时时付出代价。
训练侧覆盖度已较高：官方称训练中用到的每一个算子，在这套 NPU 上都有对应的高性能实现。但后端本身包含专用语言接口和存储操作，跨平台适配仍需结合目标硬件的执行方式调整，不能当成无缝移植。
取决于用了哪些组件。调用层基本可复用，但硬件版本要求、数据布局、精度边界需要逐个核对，其中矩阵库的缩放因子存储格式差异最容易被忽略。
矩阵计算支持 BF16、FP8、FP4，通信库支持 FP8 数据分发，TopK 筛选组件目前仅支持 BF16 输入。整体比 CUDA 版本的覆盖范围略窄。
算子库的昇腾后端要求 CANN 9.2.0 及以上。这些工具仍需与底层软件配合使用，接入前应确认目标环境满足版本要求。
它主要面向大规模训练或高并发推理场景，价值在于计算与通信的联合优化。中小规模部署不必以此为前置条件，但可以作为评估国产算力能否支撑规模化负载的参考。