一个中型规模的LLM项目，从 NVIDIA H100 集群完整迁移到昇腾 910C 集群，最终的账单是：3名资深算子工程师，2名集群运维，总计耗时 11 周，累计投入约 140 人日。其中，让模型“跑通”只用了 2 周，而让模型“跑快”且“稳定”则耗掉了剩下的 9 周。
很多技术负责人在评估国产算力时，容易被“兼容 CUDA”或“一键迁移”的口号误导。但在 2026 年的实际工程环境下，迁移成本并不在于简单的 API 替换，而在于底层通信拓扑的重构和长尾算子的性能补齐。
第一阶段：从 0 到 1 的“跑通”成本
对于大多数团队，第一周的任务是环境搭建。在昇腾 910C 上，这意味着处理 CANN（异构计算架构）版本与 PyTorch 适配版本的匹配问题。由于 910C 已经成为国家级算力平台的“必选”底座（参考 2026 年 2 月中国移动深圳光明大装置的 1.55 亿中标案例），其软件栈的成熟度比 910B 时代有了显著提升，但依赖冲突依然是首个坑点。
在我们的案例中，基础环境适配耗时 5 个工作日。模型加载、前向传播、简单的梯度更新在第 10 天实现。这个阶段的成本极低，因为绝大多数标准算子在 CANN 8.x 之后已经实现了高度覆盖。如果你的项目只涉及标准 Transformer 架构，这个阶段的体感会非常流畅。
然而，真正的成本在第二周开始激增：一旦进入大规模分布式训练，你会发现单卡性能（TFLOPS）虽然达标，但多机多卡下的 MFU（模型算力利用率）远低于预期。
第二阶段：算子重写的“深水区”
当团队尝试在 910C 上复现 H100 的训练效率时，发现了 3 个关键的自定义算子在迁移后性能下降了 40% 以上。这些算子通常涉及复杂的访存模式或非标准激活函数。
在 2026 年之前，开发者习惯于手写 TBE 或 Triton 来强行优化。但在 910C 时代，盲目手调往往是效率最低的选择。我们曾尝试手动优化一个 FlashAttention 的变体，结果在不同的集群规模下性能波动剧烈。后来我们意识到，应当先让编译器跑一轮。正如我们在《昇腾910D算子别急着手调，先让编译器跑一轮》中所讨论的，利用 Auto-Kernel 自动化适配能显著降低人力成本。通过 CANN 8 的 profiling 工具，我们发现性能瓶颈不在于计算，而在于内存搬运的冗余。
算子优化成本拆解：
- 定位瓶颈：使用 Profiling 工具分析 $\rightarrow$ 3 人日
- Auto-Kernel 自动搜索：尝试不同分块策略 $\rightarrow$ 5 人日
- 边缘 case 手写补齐：针对极少数无法自动优化的算子进行 TBE 编写 $\rightarrow$ 12 人日
这一阶段，团队最真实的体感是：国产算力不再缺“能跑的算子”，而是缺“高效的算子”。
第三阶段：HCCL 调优与“延迟墙”
迁移到 910C 后，最令开发者头疼的不是计算，而是通信。在 128 卡规模的集群上，我们遇到了严重的通信同步延迟，导致 GPU 频繁处于等待状态，整体训练速度比预期慢了 25%。
这是典型的“延迟墙”问题。昇腾的 HCCL（Huawei Collective Communication Library）在处理大规模 All-Reduce 时，对拓扑结构的敏感度极高。如果调度算法没有感知物理链路的跳数，数据包会在交换机之间产生严重的拥塞。
我们参考了北京通用人工智能研究院（BIGAI）的路径，通过引入拓扑感知的调度架构，将集群同步延迟降低了约 30%（具体技术细节可参考《BIGAI新架构落地实测：国产算力集群延迟降低40%的路径》）。在实际操作中，这意味着我们需要重新定义算子并行策略，将通信密集型操作尽可能地在单机内部消化，减少跨机通信频次。
通信调优的人力投入：
- 拓扑分析与链路压测：2 周
- 并行策略（TP/PP/DP）重新配比：3 周
- 稳定性压力测试（防止随机掉卡导致训练中断）：2 周
真实的 ROI 账单：迁移还是坚守？
将这 11 周的成本量化后，我们可以得出一个关于 910C 迁移的决策模型。如果你处于以下三种场景，迁移的 ROI 是正向的：
- 合规性驱动：类似于中国移动这类国家级项目，国产化是 0 或 1 的选择，成本是必要支出。
- 规模化成本压力：当你的算力需求达到千卡规模时，昇腾 910C 的单卡租赁/采购成本优势足以抵消这 140 人日的迁移人力成本。在 2026 年 Q2 的融资环境下，资本已不再支持单纯的参数军备赛，转向追求效率（参考《AI算力市场变局：2026第二季度融资盘点》）。
- 深度定制需求：如果你需要对底层算子进行深度定制，且能熟练使用 Auto-Kernel 降低开发量，国产栈提供的底层开放度在某些场景下比封闭的 CUDA 生态更灵活。
反之，如果你的项目规模在 32 卡以下，且模型架构极其冷门，迁移成本可能会在短期内吞噬掉所有的硬件成本节省。
给技术负责人的避坑建议
最后，基于这次迁移实录，给准备切换算力栈的团队三条建议：
首先，不要试图在迁移第一天就追求性能。先用最简单的原生适配跑通全流程，确保 Loss 下降曲线正常，再进入优化阶段。很多团队在第一周就陷入算子调优，导致整体进度卡死。
其次，重视通信拓扑而非单卡算力。在 910C 集群中，一个糟糕的并行策略会浪费掉 50% 的硬件性能。尽早引入拓扑感知调度，不要把希望全部寄托在 HCCL 的默认参数上。
最后，利用好 2026 年的自动化工具链。现在的国产算力栈已经过了“纯靠手写”的蛮荒时代，尽量将精力放在模型架构优化上，而非在 TBE 算子代码里死磕。如果发现自定义算子变慢，先查 Profiling，再试 Auto-Kernel，最后才考虑人工重写。
