2025年，国产AI芯片出货约165万张，占市场41%。这个数据来自广州市科技局转载的《科技日报》信息。采购端的变化已经很明显：企业不再只面对一种芯片、一套工具链、一种运维习惯。
问题也跟着来了。昇腾、寒武纪、海光放进同一个机房后，算力池看上去更灵活，实际运维会变得更碎。驱动版本、固件依赖、算子覆盖、显存分配、集群通信，每一层都可能卡住上线节奏。
如果你的机房里同时有 Ascend 910B、Cambricon MLU370、Hygon DCU Z100，就别再按单一 GPU 集群的办法做规划了。混部的第一原则很简单：先隔离，再调度；先验证，再扩容。
驱动不要混装，宿主机越干净越好
昇腾依赖 CANN，寒武纪使用 BANG Compiler，海光 DCU 通常围绕 ROCm 或 DTK 体系做适配。这几套基础软件栈对设备枚举、中断处理、电源管理、运行时库的要求都不一样。
很多故障不是模型代码写错，而是从安装阶段埋下的。比如同一台服务器上叠加多套驱动，modprobe 时出现冲突；或者某个厂商的驱动升级后，固件版本没跟上，设备在压力测试中掉线。最麻烦的是，这类问题不一定在安装当天暴露，往往到模型上线、任务跑满后才出现。
更稳妥的做法是：宿主机只保留必要驱动和设备插件，应用环境放进容器。昇腾准备包含 CANN 工具链的基础镜像，寒武纪准备对应 MLU 运行环境，海光准备 DCU 所需镜像。Kubernetes 层通过 Device Plugin 暴露资源，不要让业务容器直接猜底层设备。
版本也要锁。钛媒体提到，寒武纪、摩尔线程、沐曦在2026年一季度财报中营收分别同比增长160%、155%和75%，厂商迭代速度很快。对运维来说，这意味着“自动升级”未必是好事。驱动、固件、编译器、框架插件最好进入同一张版本矩阵，升级前先在灰度节点跑模型回归。
显存和算子，别只看峰值算力
异构混部最容易被低估的是算子和显存管理。
同一个模型，在不同芯片上不一定有同样的执行路径。昇腾侧可能要处理 CANN、MindSpore 或 torch_npu 的适配；寒武纪侧要看 BANG 工具链和 MLU 算子支持；海光 DCU 则要关注 ROCm/DTK 版本与 PyTorch 定制编译的关系。
显存也是同样的问题。不同芯片的显存分配器互不相通，监控口径也不同。推荐系统、搜索排序、Agent 推理这类业务经常会同时出现大 batch、短请求、高并发和多模型共存。如果调度系统只看“还有几张卡”，不看显存余量、模型加载状态和算子支持，最后就会出现一边资源闲置、一边任务排队。
这里不要急着做一个“大一统调度器”。第一步可以更朴素：
- 给每类芯片单独建资源池，先避免任务误调度；
- 把模型、框架版本、芯片类型写进发布配置；
- 每次模型更新后，在昇腾、寒武纪、海光节点上分别跑回归；
- 对不稳定算子建立清单，明确哪些模型不能跨芯片迁移。
这件事看起来麻烦，但比上线后排查“为什么同一个模型在另一类卡上慢了一截”要便宜得多。
监控指标先统一名字，再谈大屏
单一 NVIDIA 集群里，很多团队习惯用 nvidia-smi 和 DCGM。换成国产芯片混部后，这套习惯要改。
昇腾有 npu-smi info，寒武纪有 cnmon，海光有 dcu-smi。工具名称不同，输出格式不同，指标字段也不完全一致。直接把这些信息堆到 Grafana 上，最后得到的往往不是监控系统，而是一面“看起来很忙”的墙。
建议先做一层指标清洗。无论底层叫什么，运维侧至少要统一这些字段：
- 设备编号；
- 芯片类型；
- 驱动与固件版本；
- 显存使用量；
- 温度；
- 功耗；
- 错误计数；
- 任务占用关系。
Prometheus Exporter 可以按芯片分别写，但进入监控系统后的标签要统一，比如 chip_type、memory_used、temperature、power。这样值班人员看到告警时，才能第一时间判断是业务负载问题、设备问题，还是某个版本批次的问题。
集群通信要按物理拓扑规划
混部不是把几类卡接进同一张网络就结束了。训练任务、推理服务、参数同步、模型热更新都会吃通信能力。
广州市科技局转载的《科技日报》信息里提到，算力竞争正在从单点峰值性能转向系统级全栈效率，集群工程能力与软件配套正在变成核心壁垒。这个判断放到运维现场非常直接：单卡跑分漂亮，不代表千卡集群就好用。
昇腾常见 HCCS 或 RoCE v2 方案，寒武纪有 CNLink，海光也支持 RoCE。不同架构的节点混进同一个任务后，通信库和协议适配会变复杂。训练任务尤其要谨慎，AllReduce 一旦拖慢，算力利用率会明显下去。
更现实的方案是分区：物理上按芯片类型和网络拓扑划 Zone，逻辑上再通过 Kubernetes 调度策略做约束。需要强通信的任务，尽量落在同一类芯片、同一交换机范围内。跨芯片任务适合放在推理编排、离线处理、低耦合流水线里，不要一上来就把它当成统一训练集群使用。
通信库也要选清楚。昇腾使用 HCCL，寒武纪使用 CNCL，海光使用 HYCL。通用抽象可以降低开发负担，但性能和排障成本都要提前评估。运维文档里应写明：哪些任务允许跨 Zone，哪些任务只能在固定资源池运行。
自动化不是写脚本凑齐命令
混部环境里，自动化最容易做成“把三套命令包一层壳”。这能解决一部分重复劳动，但解决不了故障定位。
更有用的是把日常运维拆成几类固定动作。
第一类是健康检查。定时采集 npu-smi info、cnmon、dcu-smi 输出，转成统一 JSON，记录设备状态、驱动版本、温度、功耗和错误信息。不要只看设备是否在线，还要看它是否处在可调度状态。
第二类是发布前验证。模型更新、镜像更新、驱动更新，都要走同一套检查：容器能否启动，框架能否识别设备，关键算子能否执行，推理输出是否符合预期。芯片越多，这一步越不能省。
第三类是故障隔离。某张卡掉线后，平台要能先把它从可调度资源里摘掉，再迁移任务，并留下日志。不要让调度器反复把新任务派到一张已经不稳定的卡上。
第四类是容量管理。白天高并发推理、夜间离线批处理、模型训练任务，对芯片的需求不同。调度策略可以按业务时段调整，但不要只凭经验切换，至少要结合排队时长、显存占用、失败率这些指标。
真正的成本在适配和回归里
国产AI芯片混合部署值得做，但它不是采购完成后的附加题，而是从架构设计开始就要考虑的工程问题。
2025年国产AI芯片出货约165万张、占市场41%，说明更多企业会遇到多厂商共存的环境。钛媒体提到，华为在3月发布昇腾950PR，面向推理场景做优化，单卡FP4精度算力达到1.56PFlops，搭载112GB自研HBM显存，带宽1.4TB/s。硬件在往前走，运维体系也要跟上。
对团队来说，最先要建立的不是漂亮的大屏，而是几张清单：版本矩阵、模型适配矩阵、芯片资源池、故障处理流程。清单跑顺了，再谈统一平台；清单都没有，平台只会把问题藏得更深。
混部可以提高资源弹性，也可能放大排障难度。关键不在于把昇腾、寒武纪、海光都接进来，而在于能不能稳定地分配任务、识别故障、控制升级节奏，并让每一次模型变更都有可追溯的验证结果。
