★ FEATURED ARTICLE 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 是权重和激活都量化到 8bitW4A16 是权重 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 后续可以关注的方向第一关注算子库的更新频率。如果昇腾能保持较高的算子更新频率说明他们在认真投入生态会逐步好起来。第二关注社区里有没有人分享实际的部署案例。案例越多说明用的人越多生态越活跃。第三关注量化工具的进展。量化是降低部署成本的关键如果昇腾能在低比特量化上做出优势会是一个重要的差异化点。我个人在实际操作中的体会是这套东西现在的状态像是一个刚学会走路的孩子。能走但走不稳需要有人扶着。但你不能因为它走不稳就否定它因为学会走路是跑起来的前提。如果你愿意当那个扶着的人现在上车是个不错的时机如果你只想坐现成的车那再等等也无妨。
阅读完成 · 觉得有帮助？
