H20之后，昇腾910C迁移账本

H20不好拿之后，很多团队才开始认真算国产卡迁移这笔账。

外部供给的信号已经很清楚。RFI援引彭博社报道称，华为计划在2026年生产约60万枚昇腾910C，约为今年产量的两倍；昇腾产品线整体产量计划提高至160万片裸芯片。另一边，IDC在AIGC算力趋势报告中预测，到2026年，AIGC算力中62.2%会用在模型推理上。

这两个数字放在一起看，结论并不复杂：国产AI卡会更多进入生产环境，最先被考验的不是训练大集群，而是每天跑在线业务的推理链路。

开发者真正关心的是另一件事：原来跑在H20上的PyTorch模型，搬到昇腾910C或者寒武纪卡上，要改多少代码，吞吐会掉多少，排障要多花几天。

第一个坑通常在Attention

迁移时最容易碰到的，不是模型完全跑不起来，而是关键路径上的算子行为不一致。

在当前稿件给出的迁移记录里，torch.nn.functional.scaled_dot_product_attention 是高频问题。它在Nvidia路径上通常很自然地接入Flash Attention相关优化，但到了昇腾910C，需要替换成 torch_npu.npu_fusion_attention；寒武纪路径则要走CNNL或厂商自定义接口。

常见问题可以压缩成这张表：

覆盖率数字本身意义有限。一个业务模型里，冷门算子缺几个未必影响上线；rms_norm、Attention、mask处理这类高频路径出问题，延迟和显存就会一起变差。

API替换只是开始

原来的H20/Nvidia路径可能只有几行：

attn_output = torch.nn.functional.scaled_dot_product_attention(
    query, key, value, attn_mask=causal_mask, dropout_p=0.0
)

迁到昇腾910C后，代码会变成更显式的写法：

import torch_npu

causal_mask_bool = causal_mask.to(torch.bool)

attn_output = torch_npu.npu_fusion_attention(
    query, key, value,
    head_num=32,
    input_layout="BNSD",
    pse=None,
    keep_prob=1.0,
    sync=False,
    atten_mode=torch_npu.npu_attn_mode.SELF_ATTN,
    scale=1.0 / (head_dim ** 0.5),
    pre_tokens=65535,
    next_tokens=0,
    sparse_mode=0
)

这段改动看起来像“把一个函数换成另一个函数”。实际工程里，麻烦在三个地方。

第一是内存布局。BNSD、BSND这类布局差异，会决定融合算子能不能吃满硬件。如果为了适配算子在前后插入 permute，吞吐可能恢复一部分，但显存占用和额外拷贝又会冒出来。

第二是mask。Nvidia路径上一个相对宽松的mask写法，到了NPU接口里可能要显式转成bool，并且维度严格对齐。生成式推理每一步decode都要处理mask，长上下文下会被放大。

第三是排障。Nvidia侧常用Nsight Systems、nccl-tests定位kernel和通信问题；昇腾侧有msprof和HCCL日志，但团队要重新熟悉指标含义。当前稿件提到，一个8卡通信问题在昇腾侧花了3天对HCCL日志，类似问题在Nvidia侧用nccl-tests半小时可定位。这个差异不一定来自硬件，更多来自工具链熟练度和生态积累。

HCCL要按模型调

单卡能跑，只能说明迁移完成了第一步。到了8卡、几十卡甚至更大规模，HCCL通信会变成第二个压力点。

当前稿件中，一组8×昇腾910C服务器跑Qwen-2.5-72B推理的环境变量如下：

export HCCL_WHITELIST_DISABLE=1
export HCCL_IF_IP=$(hostname -I | awk '{print $1}')
export HCCL_CONNECT_TIMEOUT=1800
export HCCL_EXEC_TIMEOUT=1800
export HCCL_RDMA_TC=160
export HCCL_RDMA_SL=5
export HCCL_RDMA_TIMEOUT=20
export HCCL_BUFFSIZE=8192

export HCCL_NET_INTERFACE=bond0
export HCCL_SOCKET_IFNAME=bond0

export HCCL_ALLREDUCE_ALGO=ring
export HCCL_ALLGATHER_ALGO=pipeline

里面最值得看的是 HCCL_RDMA_TC 和 HCCL_RDMA_SL。它们控制RoCEv2网络流量优先级。稿件记录显示，在混合负载下，把TC从默认值调到160后，8卡间通信延迟从120μs降到68μs。

但这个参数不能直接复制到所有集群。网络拓扑、交换机配置、训练和推理是否混跑，都会影响结果。到了256卡规模，ring allreduce的延迟会线性累积，hierarchical allreduce才更值得试；可在CANN 8.0里，这类能力仍需要谨慎验证后再上生产。

吞吐损失要按模型看

纸面算力容易让人误判。当前稿件里提到，昇腾910C的BF16算力约为320 TFLOPS，H20约为296 TFLOPS。单看这个数字，910C并不弱。

问题在软件栈效率。用标准vLLM框架及适配版本跑推理，稿件给出的对比如下，单位为tokens/s，条件为batch_size=32、input_len=512、output_len=128：

这张表比“能不能替代H20”更有价值。

7B、8B模型上，昇腾910C的损失在稿件样本里是16%到18%。如果业务是批量推理、RAG里的固定embedding/reranker，或者对首token延迟不太敏感，这个结果可以进入成本核算。

72B模型就没那么轻松。Qwen-2.5-72B在8卡张量并行下损失28%，主要问题集中在集合通信和大head_num下的Attention实现。寒武纪MLU590在这个配置下还出现了OOM和精度异常，稿件记录为截至2026年7月未稳定跑通。

所以，国产卡迁移不能只按模型参数量粗分。固定shape、小模型、离线任务，是更容易先落地的部分；长上下文、多卡大模型、强依赖Flash Attention 3和动态shape的任务，需要留出更多验证时间。

什么场景可以先迁

如果团队已经有昇腾硬件，也有人熟悉CANN，以下几类任务可以先做灰度：

• 7B/8B级文本生成模型推理；
• 固定shape的embedding、reranker服务；
• 对延迟不敏感的批量离线推理；
• 模型结构相对稳定、不会频繁切换新算子的业务。

需要更谨慎的场景包括：

• 70B以上模型的多卡推理；
• 依赖 torch.compile 动态优化的训练任务；
• 强依赖Flash Attention 3的长上下文推理；
• 团队没有国产卡调试经验，却要求短期替换线上H20集群。

寒武纪MLU590并非没有机会，但从当前稿件记录看，更适合先从小模型、固定shape任务验证。大模型推理要先跑完整链路，不要只看单个算子benchmark。

真正贵的是人力

中国移动广东公司在深圳光明大装置算力服务支撑平台项目中，以1.55亿元中标建设，方案全栈采用华为昇腾910C芯片及OceanStor存储设备，并构建1600 EFLOPS国产算力平台。这样的项目有一个前提：它能组织足够的工程团队处理底层适配、集群调优和运维监控。

20人的AI创业公司面对的账本不一样。硬件买回来只是第一笔成本，后面还有算子替换、HCCL参数、profile工具、监控告警、精度回归、压测脚本。稿件中一位已跑通910C推理的团队负责人说，前两周以为改完算子就结束，第三周发现HCCL参数要按模型单独调，第四周发现监控和告警体系也要重做。

这句话比很多参数表更接近现实。

国产算力正在进入更多生产环境，供给侧也在改善。但从H20迁到昇腾910C或寒武纪，不是把CUDA代码一键翻译成NPU代码。真正的工作量藏在每一次 npu_fusion_attention 参数调整、每一轮HCCL日志分析，以及每个模型上线前的吞吐和精度回归里。