1. 这件事到底在说什么：从“拆墙”和“架空地基”两个词说起
“拆英伟达的墙，从架空地基开始”——这个标题我第一次看到的时候，脑子里蹦出来的画面是装修队进场，先把承重墙以外的隔断全砸了，然后发现地基也不是自己的。DeepSeek 这次联合昇腾搞的“六件套”开源，本质上就是这么一件事：它不是在英伟达的地基上盖房子，而是试图在另一块地上重新打桩。
先把话说清楚，这里说的“六件套”不是某个单一模型，而是一整套围绕昇腾硬件做适配的工具链组合。从社区里流传的信息来看，它大概率覆盖了推理框架适配、算子库、通信库、模型转换工具、量化工具以及配套的部署脚本这几个层面。为什么是这六块？因为任何想在非英伟达平台上跑大模型的人，都会依次撞上这六堵墙：框架不支持、算子缺失、多卡通信跑不通、模型格式转不过去、量化精度掉得厉害、部署脚本全是坑。
英伟达真正的护城河从来不是某一张显卡的算力，而是 CUDA 这十几年攒下来的软件生态。你可以买到算力接近的卡，但你买不到一个能让 PyTorch、vLLM、TensorRT-LLM、FlashAttention 这些库开箱即用的软件栈。这就是那堵“墙”。DeepSeek 和昇腾这次做的事，说白了就是绕开这堵墙，在昇腾的 CANN 软件栈上重新搭一套能跑通的东西。
适合谁看这篇内容？三类人。第一类是在做国产化替代选型的技术负责人，需要判断昇腾这套东西现在到底能不能上生产；第二类是想在昇腾上跑 DeepSeek 系列模型的算法工程师，需要知道具体怎么落地；第三类是纯粹关心大模型基础设施格局的人，想搞明白“去 CUDA 化”这件事现在走到了哪一步。我会尽量把成色和裂缝都讲透，不吹也不黑。
2. 为什么非要“架空地基”：CUDA 生态的锁定效应到底有多深
2.1 从一行代码看迁移成本的真实量级
很多人低估了 CUDA 的锁定效应，觉得“不就是换个后端吗”。我举个具体的例子。你在 PyTorch 里写一行x = torch.nn.functional.scaled_dot_product_attention(q, k, v)，在英伟达卡上它会自动走 FlashAttention 的融合算子，性能拉满。但换到昇腾上，这行代码背后需要有人把对应的融合算子用 Ascend C 重新实现一遍，而且要实现得足够快，否则性能直接腰斩。
这还只是一个算子。一个大模型推理链路里，从 Embedding 到 RMSNorm、RoPE、Attention、MoE 路由、各种激活函数，涉及的算子少说几十个，多则上百个。每一个都要重新适配、重新调优。这就是为什么“架空地基”这四个字分量这么重——它不是改个配置的事，是把整条软件栈重写一遍。
2.2 昇腾 CANN 与 CUDA 的架构差异
昇腾的软件栈叫 CANN，对标的是 CUDA。但两者的设计哲学不太一样。CUDA 是“GPU 通用计算”的思路，什么都能算；昇腾的达芬奇架构更偏向“矩阵计算专用”，Cube 单元做矩阵乘非常强，但做非矩阵类的操作就没那么灵活。
这个差异直接导致一个问题：英伟达上很多“顺手就写了”的算子，在昇腾上需要仔细考虑怎么映射到 Cube 和 Vector 单元上。比如 MoE 里的 token 路由和 gather/scatter 操作，在 GPU 上是内存操作，在昇腾上如果处理不好，会频繁打断 Cube 的计算流水，性能掉得很难看。
提示：判断一个模型能不能顺利迁到昇腾，先看它的算子构成里矩阵乘占比有多高。占比越高，迁移越顺；如果大量是 element-wise 操作和动态 shape 操作，坑会明显更多。
2.3 “六件套”各自要解决什么问题
我把这六块对应的“墙”列个表，这样更清楚：
| 组件类别 | 对标的 CUDA 生态组件 | 解决的核心问题 | 迁移难度 |
|---|---|---|---|
| 推理框架适配 | vLLM / TensorRT-LLM | 让模型能在昇腾上跑起来 | 高 |
| 算子库 | cuBLAS / cuDNN / FlashAttention | 补齐缺失的融合算子 | 极高 |
| 通信库 | NCCL | 多卡多机通信 | 中高 |
| 模型转换工具 | 无直接对标 | 权重格式转换与图优化 | 中 |
| 量化工具 | TensorRT 量化 / GPTQ | 低比特量化精度保持 | 高 |
| 部署脚本 | 各类 Docker 镜像 | 开箱即用的环境 | 低 |
这张表里，算子库和量化工具是难度最高的两块，也是决定“成色”的关键。框架适配和部署脚本相对好搞，属于工程活；通信库有华为自己的 HCCL 在推，成熟度在提升；模型转换工具是纯工程问题。
3. 成色几何：这套东西现在能干什么，干得怎么样
3.1 推理链路的完整性验证
从社区反馈和我自己了解到的情况看，这套东西目前能做到的是：在昇腾 A2 单机（8卡）上，把 DeepSeek 系列模型跑起来，包括 MoE 结构的模型。注意我的措辞——“跑起来”。跑起来和跑得好是两回事。
具体来说，单机 8 卡部署 DeepSeek 的 MoE 模型，通过这套工具链是可以走通的。模型加载、权重转换、多卡切分、推理输出，整条链路是通的。这说明最基础的“能用”已经达到了。对于很多只是想做 POC 验证或者内部 demo 的团队来说，这个程度已经够用了。
但如果你要问吞吐量和延迟，那就得看具体场景。我了解到的情况是，在 batch size 较小、序列长度中等的情况下，性能大概能达到同规格英伟达方案的六七成。这个数字不算好看，但考虑到这是第一版开源，而且是在完全不同的硬件架构上，我觉得可以接受。
3.2 量化支持的实际情况
量化这块是我最关心的，因为它直接决定部署成本。目前这套工具链支持的量化方案，主要是 W8A8 和 W4A16 这两种。W8A8 是权重和激活都量化到 8bit，W4A16 是权重 4bit、激活保持 16bit。
W8A8 在昇腾上的成熟度相对高一些，因为 8bit 的矩阵乘可以直接映射到 Cube 单元上。W4A16 就麻烦一些，4bit 权重的解量化操作需要额外的计算开销，如果实现得不好，省下来的显存会被计算开销吃掉。
注意：量化不是免费的午餐。W4A16 在昇腾上的实际加速比，取决于你的 batch size 和序列长度。小 batch 场景下，解量化的开销占比高，加速可能不明显甚至负优化。建议先用 W8A8 跑通，再根据显存压力决定要不要上 W4。
3.3 多卡通信的成熟度
多卡通信用的是华为的 HCCL，对标 NCCL。在单机 8 卡场景下，HCCL 的成熟度已经比较高了，AllReduce、AllGather 这些基础通信原语都能正常工作。但跨机场景下，情况就没那么乐观。多机通信涉及到 RDMA 配置、网络拓扑感知、通信与计算的 overlap 等问题，这些在 CUDA 生态里有 NCCL 多年打磨的积累，HCCL 还在追赶。
我个人的判断是：单机 8 卡是目前这套方案最稳妥的部署形态。如果你的模型能塞进单机 8 卡的显存里，那体验会好很多。一旦要跨机，需要做好踩坑的心理准备。
4. 裂缝在哪：几个绕不过去的现实问题
4.1 算子覆盖率的长尾问题
这是最核心的裂缝。大模型的算子看起来就那么几类，但实际部署时会遇到各种长尾算子。比如某些模型用了特殊的激活函数、自定义的归一化方式、非标准的注意力变体，这些在 CUDA 上可能一个torch.nn.functional调用就解决了，但在昇腾上如果没有对应的算子实现，就得自己写。
自己写算子这件事，门槛不低。你需要懂 Ascend C 编程，需要理解达芬奇架构的流水线设计，需要会做性能调优。这不是普通算法工程师能搞定的，需要专门的算子开发人员。而算子开发人才的稀缺程度，比 CUDA 工程师还要高一个数量级。
4.2 动态 Shape 的支持程度
大模型推理里，序列长度是动态的。用户输入可能很短，也可能很长。CUDA 生态对动态 shape 的支持已经比较成熟了，PyTorch 的 dynamo 和 TensorRT 的 dynamic shape 都能处理得不错。但昇腾的图编译模式对动态 shape 的支持，目前还有提升空间。
具体表现是：当输入序列长度变化时，可能需要重新编译图，导致首 token 延迟抖动。或者在某些动态 shape 场景下，性能会明显下降。这个问题在固定 shape 的 benchmark 里看不出来，但一到真实业务场景就会暴露。
4.3 调试工具链的差距
CUDA 有 nsight systems、nsight compute 这一套 profiling 工具，能精确到 kernel 级别的性能分析。昇腾这边有 msprof 等工具，功能在逐步完善，但和 nsight 的成熟度还有差距。当你遇到性能问题时，能不能快速定位到瓶颈，很大程度上取决于工具链好不好用。
我踩过的一个坑是：某个算子在昇腾上跑得特别慢，但用 profiling 工具看，发现时间都花在了一个看起来无关紧要的内存拷贝上。这种问题在 CUDA 上可能几分钟就能定位，在昇腾上花了我大半天。
4.4 社区生态的冷启动
CUDA 生态的强大，很大程度上是因为有海量的社区贡献。你在 GitHub 上搜任何一个模型，大概率能找到 CUDA 上的部署方案。但昇腾上的部署方案，数量少得多。这意味着你遇到问题时，能搜到的参考资料有限，很多时候需要自己摸索或者去提 issue。
这个问题的解决需要时间。开源六件套本身就是在往这个方向努力，但生态的积累不是一朝一夕的事。
5. 实操层面：如果你想上手，该怎么走
5.1 环境准备与依赖安装
假设你手头有一台昇腾 A2 的机器，8 卡，想跑 DeepSeek 的模型。第一步是装驱动和 CANN 工具包。这部分华为的官方文档写得还算清楚，但版本匹配是个大坑。CANN 的版本、驱动的版本、PyTorch 的版本、这套工具链的版本，四者之间必须严格匹配，错一个就可能跑不起来。
我的建议是：直接用官方提供的 Docker 镜像。虽然镜像体积大，但省去了版本匹配的麻烦。如果你非要自己装，一定要先把版本对应关系表找出来，逐项核对。
# 以官方镜像为例，大致流程是这样 docker pull ascend/deepseek-toolkit:latest docker run -it --device=/dev/davinci0 --device=/dev/davinci1 \ --device=/dev/davinci2 --device=/dev/davinci3 \ --device=/dev/davinci4 --device=/dev/davinci5 \ --device=/dev/davinci6 --device=/dev/davinci7 \ -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \ ascend/deepseek-toolkit:latest /bin/bash注意--device参数要把 8 张卡都映射进去，少映射一张，多卡通信就会出问题。
5.2 模型权重转换
DeepSeek 的模型权重是 HuggingFace 格式的，需要转换成昇腾能识别的格式。这一步用工具链里的转换脚本就能做。转换过程中要注意的是：MoE 模型的专家权重需要特殊处理，因为昇腾上的 MoE 实现和 GPU 上的切分方式可能不一样。
转换完成后，建议先用小规模数据做一次前向验证，确认输出和 GPU 上的结果对齐。对齐的标准一般是 cosine similarity 大于 0.99。如果低于这个值，说明转换过程中有精度损失，需要排查。
5.3 推理服务启动与压测
启动推理服务的时候，有几个参数需要特别注意：
- max_batch_size：昇腾的显存管理策略和 GPU 不同，batch size 设太大容易 OOM，设太小吞吐上不去。建议从 8 开始试，逐步往上加。
- max_seq_len：这个参数直接影响 KV Cache 的显存占用。昇腾上 KV Cache 的管理方式有差异，建议留出足够的余量。
- tp_size：张量并行的切分数量。单机 8 卡的话，一般设 8 或者 4。设 8 的话，每张卡上的模型参数量少，但通信开销大；设 4 的话反过来。需要根据实际瓶颈来调。
压测的时候，不要只看平均延迟，要看 P99 延迟。昇腾上因为图编译的原因，首 token 延迟的抖动可能比 GPU 上大。如果 P99 延迟不可接受，可能需要考虑预热策略。
5.4 性能调优的几个切入点
如果你跑通了，但性能不满意，可以从这几个方向入手：
第一，检查算子是否都走了融合路径。用 profiling 工具看，如果有大量的 element-wise 算子单独执行，说明融合没做好，需要检查图优化配置。
第二，检查通信和计算是否 overlap。多卡场景下，如果通信时间没有被计算掩盖，性能会明显下降。HCCL 支持通信计算 overlap，但需要正确配置。
第三，检查 KV Cache 的管理策略。昇腾上的显存管理有自己的特点，如果 KV Cache 频繁申请释放，会产生碎片，影响性能。可以考虑预分配策略。
6. 常见问题速查与避坑指南
6.1 典型报错与排查思路
| 报错信息 | 可能原因 | 排查方向 |
|---|---|---|
ACL_ERROR_INVALID_DEVICE | 设备映射错误 | 检查--device参数是否完整 |
HCCL communication timeout | 多卡通信配置问题 | 检查 HCCL 配置文件、网络连通性 |
Operator not found | 算子缺失 | 确认 CANN 版本是否包含所需算子 |
Out of memory | 显存不足 | 降低 batch size 或 seq len，检查 KV Cache 配置 |
Precision mismatch | 精度对齐失败 | 检查权重转换脚本，确认量化配置 |
6.2 几个我踩过的坑
第一个坑：CANN 版本和驱动版本不匹配。我一开始用的是 CANN 7.0，但驱动是 6.0 的，结果各种奇怪的报错。后来统一到 CANN 8.0 + 对应驱动才正常。这个教训是：版本管理一定要严格，不要混用。
第二个坑：MoE 模型的专家并行配置。DeepSeek 的 MoE 模型有多个专家，在昇腾上如果专家并行的切分方式和权重转换时的切分方式不一致，会导致推理结果错误。这个问题的表现是输出乱码或者重复，排查起来很费劲。建议在转换权重时就确定好并行策略，后面保持一致。
第三个坑：动态 shape 导致的性能抖动。我一开始用固定 shape 压测，性能很好。但接入真实流量后，发现延迟波动很大。后来发现是动态 shape 触发了重新编译。解决办法是设置几个常见的 shape 档位，让图编译提前完成。
6.3 什么场景适合现在上车
如果你满足以下条件，可以考虑现在就用这套方案：
- 模型结构相对标准，没有太多自定义算子
- 部署形态是单机 8 卡，不需要跨机
- 对性能的要求不是极致，能接受比 GPU 方案低一些的吞吐
- 团队里有懂昇腾开发的人，或者愿意投入时间学习
如果你满足以下条件，建议再等等：
- 模型有大量自定义算子，且没有现成的昇腾实现
- 需要跨机部署，且对通信性能要求高
- 对 P99 延迟有严格要求
- 团队完全没有昇腾相关的经验
7. 这件事的后续影响与个人判断
7.1 对国产算力生态的意义
这套东西开源的意义，不在于它现在有多好用，而在于它证明了一件事：在非 CUDA 平台上跑大模型，这条路是走得通的。虽然走得磕磕绊绊，但至少有人把路开出来了。
对于国产算力生态来说，最缺的不是硬件，而是软件栈和开发者社区。硬件可以堆料，但软件栈需要时间打磨，社区需要时间积累。DeepSeek 和昇腾这次的开源，相当于往这个生态里扔了一块石头，能不能激起浪花，要看后续有多少人愿意跟着一起填坑。
7.2 对开发者的实际影响
如果你是一个算法工程师，短期内这套东西不会改变你的工作方式。CUDA 仍然是主流，PyTorch + 英伟达仍然是默认选择。但如果你所在的公司有国产化替代的需求，或者你个人想提前布局，那现在花时间了解一下昇腾的开发流程，是有价值的。
我的建议是：不要一上来就啃硬骨头。先找一个标准的、结构简单的模型，在昇腾上跑通全流程，熟悉工具链和调试方法。然后再逐步尝试更复杂的模型。这个过程可能需要几周时间，但一旦跑通，后面就顺了。
7.3 后续可以关注的方向
第一，关注算子库的更新频率。如果昇腾能保持较高的算子更新频率，说明他们在认真投入，生态会逐步好起来。
第二，关注社区里有没有人分享实际的部署案例。案例越多，说明用的人越多，生态越活跃。
第三，关注量化工具的进展。量化是降低部署成本的关键，如果昇腾能在低比特量化上做出优势，会是一个重要的差异化点。
我个人在实际操作中的体会是：这套东西现在的状态，像是一个刚学会走路的孩子。能走，但走不稳，需要有人扶着。但你不能因为它走不稳就否定它，因为学会走路是跑起来的前提。如果你愿意当那个扶着的人，现在上车是个不错的时机；如果你只想坐现成的车，那再等等也无妨。
