5 月的一个深夜，屏幕上报第 37 次编译错误，指向一个在 PyTorch 里习以为常的 torch.nn.functional.scaled_dot_product_attention。在昇腾 910C 上，CANN 直接告诉你“不支持”。
这不是个例。根据华为官方刊物《华为技术》2025 年 3 月刊的数据，CANN 8.0 已覆盖 PyTorch 约 85% 的常用算子，但剩下 15% 恰恰是 LLM 训练和推理中最吃性能的部分——Flash Attention 变体、融合算子、自定义 CUDA 扩展。据 Tom's Hardware 等媒体 2026 年 5 月报道，DeepSeek 团队在适配 DeepSeek-V4-Pro 时，通过手写 CANN 算子优化，使昇腾 910C 达到 NVIDIA H100 约 60% 的等效性能。这个“手写”二字，对普通团队意味着至少 2-3 个月的工程投入。
我们之前写的《国产芯片跑通万亿模型后，运维成本比训练更高》算的是千卡集群的宏观账。今天把镜头拉到一台 8 卡 910C 服务器前，记录从 git clone 到第一次成功跑通训练的完整过程。
算子缺失不是“没有”，是“有但不对”
迁移前我们以为最大问题是某些算子在 CANN 里干脆不存在。第一周下来发现，真正麻烦的是 CANN 报“支持”，但行为与 PyTorch 原生不一致。
典型案例：torch.where 在 PyTorch CUDA 后端对某些边界条件返回浮点 0.0，而昇腾 910C 上返回的是极小的负值（如 -1e-12）。正常推理中完全感知不到，但在 RLHF 训练的 reward 模型打分环节，这个微小差异会被 torch.clamp 截断放大，最终导致 loss 曲线在 2000 步后开始系统性偏移。
华为在 2026 年 5 月宣布昇腾超节点与 DeepSeek-V4 同日发布，标志着 CANN 在超大模型场景下的成熟度已被验证。但对于中小团队，问题出在“长尾算子”上。据清华大学计图团队 2025 年 1 月官方公告，他们完成昇腾 910 系列适配时“精心且深入地将框架与 CANN 8.0 接口进行深度融合与优化”——翻译成工程语言就是：你得自己读 CANN 算子文档，逐个对齐数值行为。
我们的做法是建一个“算子对齐测试集”——把模型前向传播拆成 200 多个原子操作，每个操作在 NVIDIA A100 和昇腾 910C 上各跑 100 组随机输入，对比输出的最大相对误差。超过 1e-5 的标红，集中攻关。这项工作花了三周，标红 17 个算子，最终手写 CANN 扩展替换了其中 9 个。
通信不是带宽问题，是初始化问题
单机八卡 910C 用 HCCL 通信，理论上卡间带宽不输 NVLink。但我们在跑张量并行（TP=8）时，前 100 个 step 的吞吐量只有理论值的 40%。
根因出在 HCCL 的初始化策略。与 NCCL 不同，HCCL 在首次集合通信时会做一次全拓扑探测，这个过程在 8 卡环境下耗时约 12 秒。如果你的训练脚本在 model.to(device) 之后立即开始数据加载，HCCL 探测和数据预处理会撞在一起，导致 PCIe 带宽被争抢，通信初始化反而更慢。
解决方案很简单但反直觉：先跑一个空的 all_reduce 做预热，等 HCCL 拓扑稳定后再加载数据。这个改动让我们的稳态吞吐从 40% 提到了 78%。
我们在《昇腾 910C 追 B200，先过兼容关》里详细拆解过 CloudMatrix 384 的集群通信效率，但单机场景下的坑往往更隐蔽也更致命。
内存碎片比 OOM 更可怕
昇腾 910C 单卡显存约 64GB HBM2e，跑一个 7B 模型绰绰有余。但在跑 70B 模型的 8 比特量化版本时，遇到一个诡异现象：显存占用显示只用了 48GB，但 CANN 频繁报“out of memory”。
根因是 CANN 的内存分配器在处理动态 shape 时容易产生碎片。PyTorch 的 CUDA 分配器有成熟的碎片整理机制，而 CANN 的对应实现还在迭代中。当模型中有大量 view、reshape 和动态 sequence length 操作时，碎片率会迅速飙升。
我们的临时方案是把所有 reshape 替换为 contiguous().view()，强制做内存拷贝来减少碎片。代价是多了约 8% 的显存带宽消耗，但 OOM 消失了。据经济观察网 2026 年 5 月报道，华为正通过“开链”战略加速软件栈迭代，4 月发布的 CANN 8.1 RC 版本中改进了内存分配器，我们测试后发现碎片率下降了约 30%，但尚未完全解决。
社区支持：从“找不到人”到“有人但贵”
2025 年上半年，昇腾开发者社区的问题响应周期大约是 3-5 个工作日。到 2026 年 7 月，这个周期缩短到了 1-2 天。但高难度算子适配问题仍需要走华为 TAC（技术协助中心）工单，响应级别取决于你的算力采购规模。
我们接触的三家 ISV 都提供 CANN 适配服务，报价从 15 万到 40 万不等，视模型复杂度而定。这跟《一家模型公司的 8000P 租用账》里提到的算力租赁市场类似——生态正在成熟，但成本结构还在剧烈波动。
一个值得注意的变化是：华为在 2026 年 5 月宣布算力“开链”战略后，CANN 的部分组件开始在 GitHub 上接受社区 PR。我们在适配过程中提交的一个 torch.roll 算子修复，三周内被合入主线。这是国产 AI 软件栈走向真正开源化的一个微小信号。
到底值不值得切？
做完这次适配后，我们内部的结论是分场景的：
- 如果你们团队已经在 NVIDIA 生态上有大量自定义 CUDA 扩展，等 CANN 的兼容层更成熟。目前迁移成本仍然偏高。
- 如果你们跑的是标准 Transformer 架构，且模型规模在 13B 以下，CANN 8.1 + PyTorch 2.5 的原生支持已经够用，迁移周期可控制在两周内。
- 如果你们在做 RLHF 或复杂 Agent 训练，要做好心理准备：算子对齐测试是绕不开的硬仗。
我们最终花了 45 天完成适配，比预期多了 15 天。多出来的时间全耗在算子精度对齐上。但一旦跑通，昇腾 910C 的性价比优势开始显现——在我们的 8 卡服务器上，同等吞吐下，单次训练任务的算力成本比 A100 云实例低了约 35%。
这个数字会随着 CANN 迭代继续变化。正如我们在《国产芯片跑通万亿模型后》里写的：训练只是一次性投入，长期运维才是真正的账本。对昇腾 910C 来说，软件栈的成熟速度，将决定这个 35% 的成本优势能否持续。
适配结束那天，同事在群里发了一张截图：loss: 2.347, step: 5000, device: npu:3。一切正常。没有庆祝，大家默默切回 IDE 开始改下一个模型。这就是 2026 年国产算力的真实日常——门槛还在，但路已经通了。
