从CUDA到昇腾：拆解DeepSeek新开源组件与TileLang、Ascend C的关系
2026年9月30日，DeepSeek公布了一组面向华为昇腾平台的开源组件。对开发者来说，新闻里的“全套基础设施”太宽泛，还是要落到三个问题：仓库里有什么、与CUDA侧项目怎样对应、TileLang和Ascend C各管哪一层。
一张表看懂组件对应关系
| 昇腾侧实现 | NVIDIA/CUDA侧对应项 | 作用 |
|---|---|---|
| TileLang Ascend后端 | TileLang CUDA后端 | DSL、代码生成、调度与同步 |
| DeepGEMM-Ascend | DeepGEMM CUDA版本 | BF16、FP8、FP4 GEMM及相关模型计算 |
| DeepEP-Ascend | DeepEP CUDA版本 | MoE dispatch/combine等专家并行通信 |
| TileKernels Ascend后端 | TileKernels NVIDIA后端 | MoE路由、量化、Engram、mHC、RoPE等算子 |
| FlashMLA Ascend内核 | FlashMLA CUDA内核 | MLA/DSA注意力内核 |
| DeepSelect Ascend内核 | DeepSelect CUDA内核 | DSA与采样场景的TopK |
这张表最容易被误读的地方，是有人会把右侧直接换成cuBLAS、CUTLASS、NCCL等NVIDIA官方组件。
更准确的说法是：这些昇腾实现直接对应DeepSeek自己已经开放的CUDA侧项目。DeepGEMM的功能领域与cuBLAS/CUTLASS有交集，但它更聚焦大模型所需的特定计算形态；DeepEP会使用平台通信能力解决专家并行问题，但它也不是通用集合通信库的同义词。
TileLang、Ascend C和CANN如何分层？
可以把开发路径简化为：
Python / 模型框架
|
TileLang DSL与算子库
|
原生代码生成 / Ascend C / PTO / AscendNPU IR等路径
|
CANN编译与运行时能力
|
Ascend NPU
Ascend C更贴近硬件。开发者能够显式组织Global Memory与片上存储之间的数据搬运，安排计算流水，并处理同步关系。这给性能调优留下了空间，也带来了更高的学习和工程成本。
TileLang把抽象提高到Tile。开发者主要描述分块后的计算与数据关系，由编译器及硬件后端承担更多代码生成和调度工作。TileLang的昇腾生态包含不同实现路径，Ascend C后端是其中之一；面向不同硬件和版本，也可以采用原生代码生成、PTO或AscendNPU IR等路径。
这种分层给开发者提供了两种入口：常见算子和快速迭代可以优先使用高层DSL；遇到需要深度优化或补齐底层能力的场景，仍然可以下沉到Ascend C。
工程上，这两种入口缺一不可。Ascend C把底层能力开放出来，开发者才能手工安排数据搬运、流水和同步，把具体Shape的性能调到位；TileLang走高级编译路线，适合沉淀通用调度并提高迭代速度。手工精调与自动编译并行，远比强迫所有人使用同一种抽象更实际。开放的底层能力越多，上层编译器、算子库和第三方工具才越容易生长，这也是生态繁荣最朴素的前提。
这组开源项目解决了哪些工程问题？
1. 计算内核不再是单点适配
DeepGEMM-Ascend面向矩阵计算，FlashMLA面向注意力，DeepSelect面向TopK，TileKernels则收纳量化、MoE路由、RoPE等多类操作。多个模型热点同时获得昇腾实现，可以减少“一个算子完成迁移，下一个算子又成为瓶颈”的情况。
2. 通信进入同一套优化视野
MoE不只是矩阵乘问题。Token需要在设备间完成dispatch和combine，计算与通信还需要尽可能重叠。DeepEP-Ascend将专家并行通信纳入这套开放基础设施，使单卡算子优化与多卡数据流能够一起讨论。
3. 上层接口尽量保持稳定
DeepGEMM-Ascend官方说明强调与DeepGEMM的API兼容；TileKernels则在同一Python API下根据运行环境选择NVIDIA或昇腾后端。接口稳定不能消除所有迁移成本，但能把平台差异更多收敛到实现层，为框架集成和应用维护提供清晰边界。
4. 优化方法成为可研究对象
过去谈昇腾性能优化，开发者经常只能面对零散样例。真实模型组件公开后，数据布局、流水、同步、通信与计算重叠等策略都有了更复杂也更接近生产负载的参考实现。这对Ascend C开发者、编译器开发者和模型框架维护者都有实际价值。
“API对齐”不等于“零成本迁移”
接口相似，只能解决一部分迁移问题。
NVIDIA GPU和昇腾NPU的执行模型、存储结构、编译链和通信栈并不相同。即使函数签名一致，也必须分别验证精度、性能、数据类型、Shape和硬件支持范围。
公开文档里已经能看到差异。例如DeepSelect的CUDA与昇腾实现，目前支持的数据类型和部分参数能力并不完全一致。上层迁移路径确实更清楚了，底层优化工作并没有消失。
这次开源的长期价值
CUDA的生态优势来自长期积累，而不是单个组件。要形成可持续的另一条路径，同样需要语言、编译器、算子库、通信库、调试工具、框架适配和社区协作共同演进。
DeepSeek此次开放的组件，价值在于开始呈现这种“组合”：TileLang改善开发表达，Ascend C和CANN承接底层实现，DeepGEMM-Ascend、FlashMLA、DeepSelect与TileKernels覆盖计算热点，DeepEP-Ascend补上多设备通信。
这套工具还在演进，但代码、接口和测试对象已经摆在公开仓库里。接下来社区可以讨论具体的Shape、数据类型和性能回退，也可以直接提交测试与补丁。工程推进往往就是从这些小问题开始的。
“一花独放不是春，百花齐放春满园”，唯有汇聚更多开发者、编译工具、算子库和应用实践，才能把一个个技术突破连接成繁荣、可持续的昇腾生态。
