把模型从英伟达搬到昇腾，难的从来不是峰值算力，而是从编程语言一路铺到通信库的那张软件栈。
9 月 30 日，DeepSeek 在 GitHub 上一次性放出了六个仓库，全部面向华为昇腾平台。念一遍名字：TileLang、DeepGEMM-Ascend、DeepEP-Ascend、TileKernels、FlashMLA、DeepSelect。官方公告里有一句关键的话——这些组件与此前面向英伟达平台开源的组件一一对应，覆盖矩阵运算、跨设备通信、常规向量计算与访存、稀疏注意力和数据筛选。
同一天还披露了另一件事：DeepSeek 与华为共同推进了基于昇腾 950 的 128 卡超节点方案，并对计算和通信做了联合优化。
这两件事放在一起，指向一个被严重低估的问题——把模型从一套芯片搬到另一套芯片，难在哪？
答案不在芯片手册里。这篇文章用六个问题把它拆开：难在哪一层、CUDA 的护城河到底是什么、"API 兼容"为什么值钱、TileLang 站在哪、128 卡是在为谁买单、以及你该拿哪几句话去问供应商。
先排掉最容易误判的那个答案：不是算力。
昇腾 950 的公开规格并不难看。按华为昇腾官网的口径，Ascend 950PR 的 FP8 算力 919 TFLOPS、MXFP4 算力 1784 TFLOPS，片上内存最大 128GB、带宽 1.6TB/s，支持灵衢 2.0 互联协议。
纸面数字够看。可工程师真正要搬的，不是这些数字，而是一张软件栈。
这张栈至少四层。从上面数：
越往上，越贴近人的习惯；越往下，越贴近硅。
搬家时的痛是自下而上叠起来的：底层要重写算子，中层要重搭通信，上层要重学一套表达方式。算力是这张栈跑起来之后的结果，不是搬家的代价。
换个说法更清楚：算力决定天花板有多高，软件栈决定你能不能走到天花板下面。
问：昇腾的单卡规格并不难看，为什么换过去还是这么痛？
答：因为你要换的不是一块芯片，是一整套工程实践。
NVIDIA 在 2006 年推出 CUDA。这句话不是转述，是该公司 2026 财年年报（10-K）的原文："With our introduction of CUDA in 2006, we opened the parallel processing capabilities of our GPU." 按同一家公司 2025 财年年报的口径，使用 CUDA 及 NVIDIA 软件工具的开发者约 590 万。
二十年长出来的不只是驱动。是 cuBLAS、cuDNN、NCCL 这些库，是 Nsight 这些工具，是搜索框里那些别人已经踩过的坑，是每一个新入职工程师简历里那一行"熟悉 CUDA"。
这些加起来，构成了那句最省事的判断：换芯片，等于换一整套工程实践。
有个场景能说明问题。一个团队开始评估昇腾方案，第一周通常不是跑 benchmark，而是回头数自己代码里有多少处直接调了 CUDA 的原生接口。数完之后，评估会的气氛一般会变。
所以护城河不写在芯片手册上，它写在过去二十年所有跑在 CUDA 上的代码里。这也解释了为什么这次开源要强调"一一对应"——它是在对着这条护城河，修一条平行的路。
问：为什么官方通告反复强调"API 兼容"？
答：因为它是迁移成本的分水岭——一边是重写，一边是改配置。
看证据。DeepGEMM-Ascend 的 README 写得很直白："It is fully API-compatible with DeepGEMM and supports BF16, FP8, FP4 GEMM, MQA logits, and MegaMoE." 完全兼容，精度一路支持到 FP4。
DeepEP-Ascend 的说法是：公开的 buffer API 与英伟达版 DeepEP 对齐，并提供 MoE 分发与汇总所需的 all-to-all 操作，包括 FP8 分发。
TileKernels 说得更彻底：同一组 Python API，运行时自动选择后端，英伟达 GPU 和华为 NPU 上跑同一套调用。
把六个仓库的兼容口径和迁移注意点并排放在一起，看得更清楚：
| 仓库 | 负责什么 | 兼容口径 | 迁移要注意什么 |
|---|---|---|---|
| TileLang | 语言与编译 | 共享前端，昇腾 950 原生代码生成 | 昇腾后端含专用语言接口与存储操作 |
| DeepGEMM-Ascend | 矩阵乘法 | 与 DeepGEMM 完全 API 兼容，支持 BF16 / FP8 / FP4 | 缩放因子格式不同：每两个 UE8M0 打包为 int16，MN-major 存储 |
| DeepEP-Ascend | 跨设备通信 | buffer API 与英伟达版对齐，支持 FP8 分发 | 流水线、上下文、数据并行的部分通信能力仍在开发中 |
| TileKernels | 常用算子库 | 同一组 Python API，运行时自动选后端 | 昇腾后端要求 CANN 9.2.0 及以上 |
| FlashMLA | 稀疏注意力 | 覆盖预填充与解码 | 部分融合内核与稠密注意力内核仍仅支持 CUDA |
| DeepSelect | TopK 数据筛选 | 提供昇腾实现 | 昇腾版目前仅支持 BF16 输入，CUDA 版还支持 FP32 |
只看前面那三行，故事很美。但完整的故事不能只看那三行。
DeepGEMM-Ascend 同一份 README 里还有一句：昇腾上的缩放因子格式与英伟达不同——沿 K 维度每两个 UE8M0 缩放因子打包成一个 int16，并按 MN-major 顺序存储。翻译一下：接口一样，数据布局不一样，迁移时该改的地方还得改。
DeepSelect 的昇腾实现目前只支持 BF16 输入，CUDA 版本还支持 FP32。FlashMLA 的昇腾支持覆盖了预填充和解码两个阶段，但仓库里仍有部分融合内核和稠密注意力内核只跑 CUDA。
问：四层栈里，最贵的是哪一层？
答：最上面那层，语言和 DSL。因为它决定算法怎么写。
这次开源的六个项目里，只有 TileLang 不是 DeepSeek 自己的项目。它由北大团队发起，核心人物包括王磊、董宇骐，以及北京大学计算机学院副研究员杨智，项目由 TileLang 社区主导开发。它的编译基础设施建立在 TVM 之上，语法接近 Python。
DeepSeek 和它的关系是深度使用。官方口径是：TileLang 已承载 DeepSeek V4 系列模型训练中大部分算子的实现，是开发高性能算子的核心工具。更关键的一句是——目前 DeepSeek 训练中用到的每一个 TileLang 算子，在昇腾上都有对应的高性能实现。
9 月 30 日，TileLang 主仓库公布了对昇腾 950 NPU 的支持：原生代码生成、自动调度和同步。实现路径是复用共享前端，再针对 Cube 矩阵计算单元和 Vector 向量计算单元做专用的编译转换、调度、同步与代码生成。
为什么这件事的分量比看起来重？看一个对照。董宇骐介绍过用 TileLang 实现 FlashAttention：代码量从 500 多行压到 80 行，性能与官方版本持平。
省下来的不是打字的时间。是那几百行里藏着的硬件细节——数据搬运、流水线安排、单元间同步。这些原本要工程师一行行手写，现在交给编译器。
这也正是语言这一层排在栈顶的原因：算子库可以用兼容接口对齐，通信库可以用同样的 API 包装，只有语言，要重新说服一批人换一种写法。而 TileLang 的选择是——不换写法，只换后端。
问：单卡更强不就行了吗，为什么要把 128 张卡绑成一个域？
答：因为在大模型训练与推理里，单卡往往不是瓶颈，互联带宽和拓扑才是。
先看数字。昇腾 950 单卡支持灵衢 2.0 互联协议，双向互联带宽最高 2TB/s；Unified Bus 规格为 18 Port、112Gbps，双向 2016GB/s。
再往上一层，Atlas 950 SuperPoD 的总互联带宽是 1.72PB/s，256TB 全局统一内存编址，支持 64 卡、1024 卡等多种配置。
这些数字不是给单卡看的，是给通信看的。
原因在 MoE。现在的旗舰模型基本都是混合专家架构，一张卡的显存装不下所有专家。于是每一层都要把 token 分发到不同设备上的专家，算完再汇总回来，这就是 all-to-all。它的开销直接跟互联带宽与拓扑挂钩——卡间带宽不够，专家的算力就有一半时间在等数据。
顺带澄清一个容易混淆的地方：把这次说的"128 卡超节点"和上一代的 CloudMatrix384 直接画等号并不准确。CloudMatrix384 是 384 卡、跑 910 系列芯片的方案；DeepSeek 这次讲的是昇腾 950 上的 128 卡超节点。两者来自不同代际，公开资料里没有明确说前者是后者的前身。
DeepEP Ascend 的位置就在这里：它提供 MoE 专家并行需要的 all-to-all 操作，包括 FP8 分发。通信这层不通，上面再漂亮的算子也会被拖住。把 128 卡绑成一个域，本质上是在为通信买单。
问：一个要选型的人，应该问供应商哪几句话？
答：三句，恰好对应前面那张四层栈。
三句问完，一个方案能走到哪一步，大致就有数了。
"兼容"这个词最近被用得很轻。它经常被讲成一个是或否的状态，好像接口对齐了，搬家就算完成。
但从这次开源的六个仓库看，兼容更像一份承诺：承诺主干道已经通，同时承认支路还得一起填。DeepGEMM-Ascend 一边强调完全兼容，一边白纸黑字写下缩放因子格式的差异——这种写法反而更值得信任。
所以回到最初那个问题：模型兼容国产芯片，到底有多难？
难的部分在变少。真正的新问题是另一个——当迁移成本从"重写"降到"改配置"，你手上那笔技术债，还剩多少是必须自己还的？