设备注册只是第一步。相应的 Device Plugin 把加速卡暴露为 Kubernetes 扩展资源后，昇腾、海光、寒武纪可以进入同一资源池。一旦要求它们同步训练同一个模型，通信后端、算子实现、精度设置和故障恢复的差异就会同时出现。
2024年7月5日，新华网报道了“前进·AI异构计算平台”的发布，并称其为首个大规模国产多芯混元集群。百度百舸的公开材料也讨论过把 GPU、昆仑芯、昇腾等不同芯片纳入单一集群。这些案例说明，多芯统一纳管已有现实路径。至于一个训练作业能否横跨不同芯片，还要看任务怎么拆、数据怎么传。
先把“混合集群”拆成两件事
资源池级混合，是让不同芯片进入同一套集群，各类作业按后端分配到合适的节点。昇腾跑一批任务，海光 DCU 跑另一批任务，寒武纪 MLU370 承接适配完成的模型，彼此不必在每个训练步交换数据。
任务级混合更难。一个作业的多个 Rank 分布在不同芯片上，每一步都要同步梯度或传递激活。此时，速度较慢、算子不全或网络条件较差的一组节点，都可能让整个作业停下来等待。
如果目标只是利用闲置设备，资源池级混合通常已经能解决大部分问题。只有在单一芯片数量不足，或模型本身适合分段执行时，才值得继续做跨芯任务。
通信层别急着写“大一统 All-Reduce”
NCCL 是 NVIDIA 的集合通信库，不能充当昇腾、海光 DCU 和寒武纪之间的共同后端。昇腾侧有 HCCL 等通信组件，其他芯片也有各自的软件栈。即使把这些接口封装成同一个 All-Reduce 调用，底层的拓扑、数据格式、错误处理和传输能力仍然不同。
自定义通信层可以做，但边界要收紧：
- 同一类芯片组成一个计算组，组内使用该后端已经优化的集合通信能力；
- 跨芯片组只传递模型分段所需的激活，或经过明确设计的参数分片；
- 统一张量形状、数据类型、序列化顺序和校验方式；
- 为超时、节点退出和断点恢复留下明确处理路径。
原型阶段可以用 gRPC 传递控制消息、状态和少量数据。大张量通信仍应优先走各后端支持的高性能路径。如果使用 RoCE v2，网卡、交换网络、驱动和机架拓扑都要一起检查，不能只在训练代码里换一个通信接口。
全局梯度同步尤其要谨慎。把所有梯度集中到一个所谓的“主节点”，很容易形成新的瓶颈。只有明确采用参数服务器架构时，才需要这样的中心角色；其他场景应尽量让通信留在同构组内。
Kubernetes能分配设备，不会判断模型是否适配
部署时可以分别接入 Ascend Device Plugin、Hygon DCU Plugin 和 Cambricon Neuware Plugin。具体的资源名称、驱动要求和支持范围，需要按现场版本核对。Device Plugin 解决的是设备发现与分配，模型能不能运行，还要交给调度策略和训练框架判断。
节点标签至少应覆盖芯片厂商、型号、运行时版本和网络域，例如 accelerator.vendor、accelerator.model、runtime.version、fabric.zone。这些字段属于集群自己的运维约定，不是厂商统一标准。
OceanClub技术社区在2024年8月发布的材料中提到，昇腾910面向训练和推理，昇腾310主要面向推理。即使来自同一厂商，不同型号的任务角色也可能不同。只打一个笼统的“昇腾节点”标签，调度信息远远不够。
自定义 Scheduler Extender 或其他调度扩展，应在 Pod 落点前检查几件事：同一 Worker 组的软件栈是否一致，节点是否处于合适的通信域，当前模型阶段所需算子是否完整，以及全部 Rank 能否同时获得资源。显存还有空位，并不代表这张卡适合加入当前训练组。
PyTorch适配的账，最终落在算子上
CANN、DTK 和 Neuware 的接口与算子覆盖并不相同。torch.compile 配合自定义 Backend，可以作为计算图适配的入口；torch.library 也能注册统一的算子名称。但每个后端仍然需要对应的 Kernel，并保证前向、反向、形状和数据类型语义一致。
ZeRO-3 可以分片参数、梯度和优化器状态，主要解决显存压力。它不会自动解决异构问题。如果分片落在性能差异较大的设备上，较慢的 Rank 仍会拖住同步节奏。
动态调整 Local Batch Size 也不能只看显存。不同 Rank 处理的样本数不一致时，梯度聚合需要按样本量加权，否则会改变实际的梯度尺度。优化器状态、数值设置和断点文件也要保持可恢复，不能只保证一次前向能够跑通。
70B级模型不适合直接拿全集群试错。更稳妥的顺序是：
- 先在每种后端完成单卡前向和反向，列出缺失算子；
- 再验证同厂商多卡通信和断点恢复；
- 随后只增加一个跨芯片的流水线边界，核对输出和关键梯度；
- 最后再扩大模型和节点规模。
前面任一步还不稳定，增加卡数只会让定位问题更困难。
更稳妥的形态是“同构计算岛”
现有设备如果包括昇腾910D、海光DCU和寒武纪MLU370，可以先分别组成三个同构计算岛。每个岛固定驱动、运行时和通信后端，由 Kubernetes 统一纳管。
确实需要三类芯片共同承担一个模型时，可以按算子支持情况划分流水线阶段。每个数据并行组仍留在同一种芯片内，跨组只传递阶段之间的激活，避免让所有设备参加同一次跨厂商 All-Reduce。
如果模型图无法清楚分段，或者某类芯片缺少关键算子，可以让这部分设备承担数据处理、评测或独立微调任务。这样仍然属于混合集群，只是没有强行把不同后端塞进同一个同步作业。两种部署方式应在方案中写清楚，否则很容易把“统一资源池”误写成“统一训练后端”。
性能账先把基线写明白
异构训练高度依赖卡型与数量、驱动版本、框架版本、网络拓扑、模型结构和并行策略。缺少这些前提，单独给出“吞吐提升”或“成本下降”的百分比没有可比性。
一份可复现的部署记录，至少要比较三种状态：现有同构组单独运行、不同芯片分别承接任务、不同芯片加入同一作业。记录内容应包括单步耗时、通信等待、算子回退、故障次数、恢复时间和资源占用。成本也不能只算硬件采购，还要把多套软件栈的适配与维护算进去。
模型参数量本身无法决定异构训练是否合适。70B微调遇到关键算子缺失或频繁跨组同步，同样可能得不偿失；结构容易切分的较小模型，落地反而更顺利。
太初元碁洪源在2026年5月的分析中，把国产AI算力的突破点放在大规模集群服务能力、计算效率和生态易用性上。对应到工程现场，就是承认不同芯片的差异，并把差异关在清晰边界内：设备由 Kubernetes 分组，算子由各后端实现，跨芯通信只走必要路径。做到这些，混合集群才有机会稳定承担训练任务。
资料来源
- 太初元碁洪源：异构计算能力将成为未来AI算力基础设施的……，2026-05-20
- 国产AI算力：万卡集群，多芯混合，OceanClub技术社区，2024-08-06
- 助推国产算力水平突破 “前进·AI异构计算平台”发布，新华网，2024-07-05
- 百度百舸如何搞定一个可以支持多芯混合训练的AI集群
