4月24日，DeepSeek V4正式发布。这个包含V4-Pro（1.6万亿参数）和V4-Flash（2840亿参数）的模型家族，将上下文窗口拉升至100万字。紧接着，华为云团队宣布，通过协同作战，昇腾910C的推理能力已满足客户需求。
这听起来像是国产算力的高光时刻。但如果你最近接触过深圳光明大装置的交付现场，或者刚把一套基于PyTorch的训练脚本迁移到Ascend环境，你会发现“跑通Demo”和“稳定生产”之间隔着一条巨大的鸿沟。昇腾910C千卡集群完成DeepSeek-V4-Pro的后训练，确实把国产AI算力推到了工程现场，但对于开发者而言，接下来的异构调度、框架迁移和混合硬件兼容，才是真正的深水区。
算子补齐不是“翻译”，是“重写”
很多人误以为从CUDA迁移到昇腾，只是换个编译器。事实是，这需要重写大量底层逻辑。
据《经济观察报》5月1日的报道，华为算力团队在春节期间就进入了高强度工作状态，只为接住DeepSeek带来的流量冲击。这种“日夜奋战”的背后，是算子缺失的真实痛点。昇腾的CANN架构虽然支持PTU（Performance Training Unit）计费模式，但在实际落地中，许多非标准算子仍需开发者手动编写或寻找社区补丁。
相比之下，海光DCU在兼容CUDA方面走了一条不同的路。海光的生态更接近于“翻译层”，这使得许多现有的PyTorch模型能够直接运行。然而，这种兼容性是有代价的。在《1.55亿大单全拒进口：昇腾910C替代H20背后的迁移阵痛》一文中曾指出，海光DCU在处理大规模分布式训练时，通信效率往往成为瓶颈。当模型参数量达到万亿级别，通信开销不再是线性增长，而是指数级爆炸。
昇腾910C的优势在于其自研的HCCL（Huawei Collective Communication Library）。在千卡集群中，HCCL的优化使得带宽利用率远高于通用网卡。但问题在于，HCCL只服务于昇腾硬件。一旦你的集群中混入了海光DCU，或者需要调用不同厂商的推理引擎，HCCL就无法发挥作用。这就导致了“异构孤岛”。
异构调度的噩梦：当PyTorch遇见MindSpore
更复杂的情况发生在混合硬件调度上。随着海光DCU、寒武纪MLU等国产芯片的市场份额提升，企业级AI基础设施正变得越来越“杂”。
想象这样一个场景：你的训练集群主要由昇腾910C组成，负责DeepSeek-V4-Pro这种超大模型的预训练和微调；但在推理阶段，为了降低成本，你希望利用闲置的海光DCU节点进行部署。此时，调度器面临的第一个问题是：框架不统一。
昇腾原生推荐MindSpore，而海光DCU更适配PyTorch。虽然目前已有项目尝试在PyTorch上通过torch_npu或第三方适配层来支持昇腾，但这种“套壳”方案在复杂模型（如DeepSeek的MoE架构）中极易出现显存泄漏或算子执行错误。MindSpore虽然在昇腾硬件上有深度优化，但其生态封闭性使得跨平台迁移几乎不可能。开发者不得不维护两套代码库，一套用于训练，一套用于推理，且两者之间的权重转换往往伴随着精度的损失。
此外，通信协议的断裂是另一个隐形杀手。HCCL与海光的DCCL（类似NVIDIA的NCCL）互不相通。在异构集群中，要实现节点间的高效数据交换，必须依赖通用的RDMA网络或TCP/IP协议，这会大幅降低通信效率。对于DeepSeek-V4-Pro这样动辄百万token上下文的模型，通信延迟的增加直接导致训练时间延长，算力成本飙升。
稳定性：千卡集群的“木桶效应”
单卡性能再强，也抵不过千卡集群中一颗故障芯片引发的雪崩。
在《H20断供一年：昇腾910C接管国产算力，开发者面临HCCL迁移阵痛》的记录中，开发者们反映，昇腾910C在大规模集群下的稳定性仍有待验证。与NVIDIA成熟的容错机制相比，国产芯片的故障检测、自动隔离和任务迁移功能尚处于初级阶段。在千卡规模的训练中，任何一颗芯片的异常都可能导致整个训练任务中断，重新从头开始。
这种不确定性在异构环境中被放大。如果集群中同时存在昇腾和海光节点，调度器需要实时监测不同硬件的健康状态，并根据算力类型动态分配任务。目前的开源调度框架（如Kubernetes + Volcano）在这方面缺乏针对国产异构硬件的深度适配。开发者往往需要自行开发监控探针和故障恢复逻辑，这不仅增加了工程复杂度，也引入了新的Bug风险。
结论：别被“算力翻倍”忽悠
华为昇腾910C的迭代逻辑确实是“一年一代、算力翻倍”，参数上看着诱人。但从工程角度看，算力只是基础，可用性才是关键。
在《京东数字人开播激增6倍：首个“AI原生”618背后的入口战》中提到的技术门槛重塑，同样适用于算力领域。电商巨头们不再只看显卡的FLOPS，更看重整条链路的稳定性和成本可控性。对于广大开发者而言，昇腾910C千卡之后的挑战，不在于硬件本身有多强，而在于如何在异构环境中，让PyTorch、MindSpore、HCCL、DCCL等不同组件和谐共处。
这不是一个简单的“插拔替换”问题，而是一场关于兼容性、通信效率和工程能力的持久战。在异构算力调度标准尚未统一的今天，盲目乐观只会让你在深夜面对报错日志时，感到深深的无力。
如果你正在规划下一代的AI基础设施，建议先从小规模异构集群的PoC（概念验证）开始，重点测试跨框架的算子兼容性和通信效率。毕竟，在DeepSeek-V4-Pro这种巨型模型面前，任何微小的工程瑕疵都可能被放大成巨大的成本黑洞。
