DeepSeek 与华为 Ascend 工具开源后的算力协作模式

这次开源最值得关注的地方，不是“又多了几个 Ascend 仓库”，而是算力软件开始出现更清晰的协作分层：模型团队把真正影响训练与推理效率的计算内核、通信原语和注意力实现公开出来，硬件生态提供编译器、运行时与设备支持，编译抽象层再把这些能力接到更大的开发者社区里。它有机会降低适配成本，但不能被解读成所有芯片型号、框架和生产环境已经完成统一替代。

官方仓库：https://github.com/deepseek-ai/DeepGEMM-Ascend

通信库地址：https://github.com/deepseek-ai/DeepEP-Ascend

先把公开发布的组件分成四层

从公开仓库的职责看，这次协作至少可以拆成四层。第一层是模型工作负载，包含矩阵乘加、稀疏注意力和 MoE 路由；第二层是 TileLang 这类面向多后端的编程抽象，帮助开发者描述高性能 kernel；第三层是针对关键热点的实现，包括 DeepGEMM-Ascend、DeepEP-Ascend、DeepSelect 和 FlashMLA 的 Ascend 相关代码；第四层是 Ascend NPU、CANN 与 torch_npu 组成的设备和运行时基础。

这样看，所谓“工具开源”并不是把一个大而全的系统交给用户，而是把最容易形成瓶颈、又最适合复用的层公开出来。DeepGEMM-Ascend 的 README 将自己定义为 DeepGEMM 在华为 Ascend 平台上的实现，并强调与 DeepGEMM API 兼容；DeepEP-Ascend 则围绕 MoE 的 expert-parallel dispatch/combine 提供 all-to-all 通信，同时使用 Ascend C、HCCL/HCOMM、UBMEM 和 URMA 等能力。两者解决的是不同方向的瓶颈。

从 API 对齐看协作边界

我认为这次发布的工程价值，首先体现在“保留上层习惯”。如果计算库和通信库能尽量沿用既有公开接口，模型框架、测试用例和调度逻辑就不必为了换硬件完全重写。DeepGEMM-Ascend 公开说明支持 BF16、FP8、FP4 GEMM、MQA logits 和 MegaMoE；DeepEP-Ascend 则说明其公开 buffer API 与 NVIDIA 版本的 DeepEP 对齐。

但 API 对齐只代表接入面的稳定性，不代表性能、数据布局和硬件约束完全相同。DeepGEMM-Ascend 的文档特别提醒，Ascend 上的缩放因子布局与 NVIDIA 路径不同；这类细节会直接影响 kernel 的输入准备、对齐和调度。换句话说，上层可以“看起来一样”，底层仍然需要针对 NPU 的内存布局和同步机制做专门优化。

TileLang 的位置也值得单独看。其官方仓库列出 Ascend 950 的原生代码生成、自动调度和同步能力，同时把其他 Ascend 适配器放在生态仓库中独立演进。它更像一层共享的表达方式和编译入口，价值在于减少每个模型团队从零理解底层指令、布局和同步的成本，而不是替代 CANN 或设备运行时。

把硬件与工具链条件单独列出来

公开仓库给出的依赖条件说明了为什么这不是“安装 Python 包就完成迁移”。DeepGEMM-Ascend 的初始发布说明面向 Ascend 950，快速开始部分列出 CANN 9.20、torch_npu、Python 3.10 及以上、支持 C++20 的编译器和若干构建依赖。项目还需要递归拉取子模块，并通过脚本链接必要的头文件后编译 C++ 扩展。

# 下面只展示仓库 README 给出的准备顺序，不代表当前机器已经完成构建
git clone --recursive https://github.com/deepseek-ai/DeepGEMM-Ascend.git
cd DeepGEMM-Ascend
# 先确认 CANN、torch_npu 和编译器版本，再构建扩展
./develop.sh
# 构建完成后再安装，避免跳过本地工具链检查
python -m pip install . --no-build-isolation

这个顺序里最容易被忽略的是“设备条件”和“软件条件”必须成套出现。只有仓库代码，没有匹配的 CANN、驱动、torch_npu 和 NPU 型号，不能推导出可用的生产环境；反过来，工具链齐全，也不代表某个具体模型的 kernel 已经覆盖了所有 shape、精度和并行方式。

用算力协作模型解释各方角色

把角色拆开后，协作关系会比“谁替代谁”更清楚。模型团队熟悉稀疏注意力、专家路由和实际 workload，适合把热点算子与通信需求抽象成可复用接口；硬件生态团队掌握 NPU 指令、内存层次、编译器和集群互联，负责把这些接口落到设备能力上；编译器项目把底层实现变成更容易迁移和维护的开发模型；社区则通过 issue、适配器、测试和框架接入，暴露不同设备和负载下的兼容性问题。

这也是我对这次开源最谨慎、但也最乐观的判断：它的价值不只在某个 benchmark 数字，而在于把“模型算法需要什么”和“硬件平台能提供什么”之间的接口公开出来。接口一旦稳定，后续无论是接入 SGLang、服务框架还是内部推理平台，讨论就可以从重新造轮子转向具体的兼容、测试和性能问题。

按工作负载做接入判断

如果团队准备评估这批工具，我会先问五个问题，而不是先看仓库 star 数。第一，目标设备是否落在项目明确支持或验证过的型号上；第二，CANN、torch_npu、Python 与编译器是否能组成匹配环境；第三，瓶颈到底是 GEMM、MoE 的 all-to-all，还是稀疏注意力；第四，现有框架能否复用对齐后的 API；第五，手头的性能数据是否来自与目标环境一致的硬件和配置。

以公开资料为例，DeepGEMM-Ascend 的 README 把 Ascend 950 和 CANN 9.20 写成明确条件；DeepEP-Ascend 的 README 又提醒部分性能结果使用了 DeepSeek 获得的 PoC HDK 和手工配置，早期 PoC 版本可能观察到更低带宽。这两条信息放在一起，结论就很明确：可以把它们作为技术路线和适配入口，却不能拿仓库中的一组数据直接承诺自己的商用集群一定得到同样结果。

性能数据与治理边界不能省略

开源项目进入生产前，除了 kernel 是否能编译，还要看版本节奏、许可证、子模块、CI 覆盖、问题响应和回滚路径。硬件相关项目尤其容易出现“代码公开了，但可复现环境还没有完全公开”的情况。DeepEP-Ascend 自己对 PoC 配置做出的限定，正好提醒我们把“能看到代码”“能在实验设备上跑”“能在商用环境稳定运行”分成三件事。

因此，这次发布更适合被看成一条可被社区共同加固的路线：模型团队继续开放热点实现，硬件生态把编译器和运行时能力做得更可用，编译抽象层减少迁移重复劳动，使用者通过真实 workload 反馈接口和性能问题。谁能把这四个环节持续接起来，谁才可能把一次发布变成长期生态，而不是停留在新闻标题上的“支持某种芯片”。

常见问题

这次开源是否意味着 DeepSeek 与 Ascend 已经完全兼容？

不能这样概括。公开仓库说明了部分 API 对齐和具体硬件、工具链条件，兼容范围仍取决于模型、shape、精度、框架版本与设备环境。

为什么要同时关注 DeepGEMM-Ascend 和 DeepEP-Ascend？

前者主要处理矩阵计算等单卡热点，后者处理 MoE 专家并行的数据交换。大模型系统往往同时受计算和通信影响，只优化一边不一定得到完整收益。

TileLang 能不能替代 CANN？

不能。TileLang 提供更高层的 kernel 表达和编译入口，实际运行仍需要匹配的 Ascend 编译器、运行时、驱动和设备支持。

看到仓库里的性能数字就可以直接用于选型吗？

不可以。应先核对测试硬件、HDK、驱动、工具链、输入 shape、精度和配置；如果仓库明确标注 PoC 或手工配置，更要把它当作方向性参考。

参考地址

DeepGEMM-Ascend：https://github.com/deepseek-ai/DeepGEMM-Ascend

DeepEP-Ascend：https://github.com/deepseek-ai/DeepEP-Ascend

DeepSelect：https://github.com/deepseek-ai/DeepSelect

FlashMLA Ascend 说明：https://github.com/deepseek-ai/FlashMLA/blob/main/docs/20260930-ascend-prefill-deep-dive.md

TileLang：https://github.com/tile-ai/tilelang

DeepSeek-V3 官方仓库：https://github.com/deepseek-ai/DeepSeek-V3