一、混合部署不是选择题，而是必答题

某省政务云平台的技术负责人最近算了一笔账：2025 年采购的 16 台昇腾 910B 服务器已到位，但现有的 OCR 证件识别、视频分析等 12 个推理服务全部跑在 NVIDIA T4 上，模型权重为 CUDA TensorRT 格式，直接迁移到昇腾需要模型重编译 + 精度验证，预计工期 3 个月。更棘手的是，2027 年的信创合规检查要求国产芯片算力占比不低于 60%——但业务不能停。

这不是技术选型问题，这是并行运行问题。

IDC 2026 Q1 报告显示，中国企业 AI 算力市场中，国产 AI 芯片（昇腾/海光/寒武纪）出货量同比增长 217%，但同期 NVIDIA 存量 GPU 利用率仅 41%。核心矛盾在于：新卡在入库，旧卡在空转，两套生态之间缺乏一个统一的调度平面。

ANI 的一云多芯方案要解决的问题很明确：让昇腾 910B 和 NVIDIA A100 在同一调度面板下被统一管理，让开发者不用关心底层芯片型号。

二、混合部署架构：一平面、两通道、三芯片

架构核心设计原则：

• 单调度平面：GPUInventory Port 是唯一的资源入口。无论底层是昇腾还是 NVIDIA，调度器看到的都是统一语义的设备对象（`{vendor, memory, compute_units, health}`），不区分厂商。
• 双通道并行：昇腾走 CANN 生态链（Ascend Docker Runtime → torch_npu），NVIDIA 走 CUDA 生态链（nvidia-container-runtime → CUDA/cuDNN）。两个通道在 HAMi 层完成统一虚拟化切分后，各自进入独立的 Adapter 执行，互不干扰。
• 零侵入迁移：已有 CUDA 模型无需重编译即可继续在 NVIDIA 节点运行，新增模型可以选择昇腾或 NVIDIA 部署，调度器根据集群资源状态和策略自动化分配。

三、昇腾 910B 接入实操：从硬件上架到任务提交

以下步骤基于 ANI v2.0 + 昇腾 910B（CANN 8.0.RC1）环境，已在多个客户现场验证。

3.1 节点初始化

# 1. 安装昇腾驱动和固件（BMC 远程挂载 ISO）
./Ascend-hdk-910b-npu-driver_8.0.RC1_linux-aarch64.run --full --install-for-all

# 2. 验证 NPU 可见
npu-smi info
# 预期输出：4 NPUs visible, driver 8.0.RC1

# 3. 安装 Ascend Docker Runtime
yum install -y Ascend-docker-runtime_8.0.RC1_linux-aarch64
systemctl restart docker

# 4. 部署 Ascend Device Plugin（通过 ANI deploy profile）
kubectl label node node-910b-01 kubercloud.io/npu=ascend-910b
ani-cli deploy-profile apply ascend-device-plugin --node-selector kubercloud.io/npu=ascend-910b

3.2 GPUInventory 注册

节点初始化完成后，GPUInventory Port 的 Discover 机制会自动扫描新节点。HAMi 的昇腾 Adapter 通过 `npu-smi` 采集每张卡的显存、频率、温度、健康状态，注册到统一设备池：

# GPUInventory 自动生成的设备视图（截取）
devices:
- id: “asc-910b-node01-0”
vendor: “Huawei”
model: “Ascend 910B”
memory_mb: 65536
compute_units: 100
health: “healthy”
topology:
numa_node: 0
pcie_bdf: “0000:3b:00.0”
- id: “nvidia-a100-node05-0”
vendor: “NVIDIA”
model: “A100-SXM4-40GB”
memory_mb: 40960
compute_units: 100
health: “healthy”
topology:
numa_node: 0
pcie_bdf: “0000:47:00.0”

关键在于：这两张卡在设备池中是对等的——上层调度器只看到两个"拥有不同显存容量的 GPU"，不知道也不需要知道一个是 CUDA 一个是 CANN。

3.3 提交任务

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
name: mixed-inference-test
spec:
schedulerName: volcano
queue: inference-queue
tasks:
- replicas: 1
name: ascend-task
policies:
- event: TaskCompleted
action: CompleteJob
template:
spec:
containers:
- name: main
image: harbor.ani.local/models/bert-inference:torch-npu
resources:
limits:
kubercloud.io/gpu-memory: 16GB # 统一语义
kubercloud.io/gpu-count: 1
- replicas: 1
name: nvidia-task
template:
spec:
containers:
- name: main
image: harbor.ani.local/models/resnet-inference:cuda-12
resources:
limits:
kubercloud.io/gpu-memory: 8GB
kubercloud.io/gpu-count: 1

调度器自动将 `ascend-task` 路由到昇腾节点、`nvidia-task` 路由到 NVIDIA 节点——用户在 YAML 中没有写任何厂商特定的 `nodeSelector` 或 `nodeAffinity`。

四、智能调度策略：不只是"就近分配"

ANI 调度器采用多策略级联评分模型，按优先级依次评估：

策略	权重	说明
信创合规	+10	当集群配置中 `prefer-domestic: true` 时，国产芯片获得优先加权，确保信创算力占比达标
模型兼容性	硬约束	如果容器镜像为 `torch-npu`，自动排除 NVIDIA 节点；反之亦然（镜像标签自动识别芯片类型）
负载均衡	动态	基于 Prometheus 实时数据，优先选择 GPU 利用率最低节点，避免热点
亲和性溢出	弹性	当首选芯片资源不足时，自动溢出到备选芯片（昇腾 → NVIDIA 或反向），保证任务成功率
成本感知	可选	结合财务标签，优先使用已折旧完毕或 TCO 更低的芯片（适用于非生产环境）

一个典型的调参建议：信创优先 + 亲和性溢出 的组合策略在实际生产中最实用。它既满足合规检查（昇腾优先），又保证业务连续性（NVIDIA 兜底）。某政务云平台使用此策略后，昇腾 910B 分配率从 34% 提升至 89%，同时任务总失败率从 2.1% 降至 0.3%。

五、性能对比：昇腾 910B vs NVIDIA A100（实测数据）

以下数据来自 ANI 基准测试套件 2026Q1，测试环境：昇腾 910B（CANN 8.0.RC1）vs NVIDIA A100-40GB（CUDA 12.4），均通过 ANI 统一调度平面运行。镜像分别为 `torch-npu:2.1.0` 和 `pytorch:2.3.0-cuda12.4`。

指标	昇腾 910B	NVIDIA A100-40GB	差异
FP16 算力 (TFLOPS)	320	312	+2.6%（昇腾略优）
显存带宽 (GB/s)	1228	1555	-21%（A100 优）
BERT-Large 推理 (QPS)	852	914	-6.8%
ResNet-50 训练 (img/s)	4780	5210	-8.3%
LLM 推理 (Llama-2-7B, tokens/s)	48.3	52.1	-7.3%
模型迁移成本 (人天)	0 (CANN 原生)	0 (CUDA 原生)	—
首次适配成本 (CUDA→CANN)	5-15 人天	—	仅首次
功耗 (W, 满载推理)	310	400	-22.5%（昇腾优）
虚拟化切分粒度	vNPU (1/64)	MIG (1/7) + vGPU	昇腾更细粒度
单卡切分上限	64 实例	7 MIG + 16 vGPU	昇腾多租户能力更强

性能解读

昇腾的优势在推理密度。 虽然单卡原始性能落后 A100 约 7-8%，但 vNPU 的 1/64 切分粒度使其在多租户共享场景中优势明显。某电信运营商的在线客服系统部署了 4 张昇腾 910B，以 vNPU 模式切分为 256 个推理实例（每实例 1GB 显存），单卡同时服务 64 路 BERT 请求。相同预算下，NVIDIA A100 的 MIG 模式最多切分为 28 个实例（4×7），推理密度低 9 倍。

NVIDIA 的优势在大模型训练。 A100 的显存带宽领先 21%，在需要大 batch size 的训练场景中优势明显。此外，NVIDIA 的 NCCL 集合通信库在跨节点扩展时仍比 HCCL 成熟一个数量级——8 卡 A100 的线性扩展效率可达 92%，而昇腾 8 卡约为 85%。

能耗是昇腾的隐藏优势。 满载推理功耗仅 310W，比 A100 低 22.5%。在电费敏感的 IDC 场景，这直接转化为 TCO 优势。按单卡 3 年周期计算，昇腾 910B 的总拥有成本（含硬件 + 电费）比 A100 低约 18%。

六、混合部署最佳实践

6.1 芯片选择决策矩阵

场景	推荐芯片	原因
在线推理（高并发、小模型）	昇腾 910B	vNPU 细粒度切分，单卡并发 64 路
大模型训练（>7B）	NVIDIA A100/H800	NCCL 多卡扩展效率更高
信创合规（涉密网）	昇腾 910B	国产唯一选择
图像/视频预处理	昇腾 910B 或 DCU	低精度推理，NPU 性价比更高
开发/测试环境	按空闲资源弹性分配	溢价芯片不用于调试

6.2 避免的陷阱

陷阱 1：混部在同一节点。 不要在同一个 Kubernetes 节点上同时安装 Ascend Runtime 和 NVIDIA Runtime。两者都会修改 Docker 默认 Runtime，冲突概率极高。正确做法是按整机维度划分芯片池——某一批节点是纯昇腾，另一批是纯 NVIDIA。

陷阱 2：忽略 HCCL/NCCL 网络拓扑。 昇腾 HCCL 要求 NPU 之间通过 HCCS（Huawei Cache Coherence System）全互联，NVIDIA NCCL 要求 GPU 之间通过 NVLink/NVSwitch 互联。如果节点内部拓扑不满配（如两块 NPU 不在同一个 HCCS 域），跨卡通信性能会骤降 60% 以上。

陷阱 3：显存等价误区。 昇腾 910B 的 64GB 显存 ≠ A100 的 40GB 显存，因为 CANN 框架在运行时需要额外预留 8-12GB 显存用于图编译和算子缓存。实际可用显存约为标称值的 80%。

6.3 推荐的集群配比

基于多个客户现场的实际运行数据，推荐初始配比为：

• 推理型集群：昇腾 60% + NVIDIA 40%（信创达标 + 存量消化）
• 训练型集群：NVIDIA 70% + 昇腾 30%（训练性能优先 + 推理分流）
• 开发测试集群：按成本弹性，5:5 均可

该配比建议每季度根据信创政策进度和模型迁移进度重新评估调整。

七、总结：一云多芯的三个支柱

回顾整个混合部署方案，ANI 的一云多芯能力建立在三个技术支柱上：

1. GPUInventory Port 的统一抽象——这是根基。如果调度器看到的是两套不同的 API（`nvidia-smi` 和 `npu-smi`），混合部署就永远停留在运维手册层面，无法成为平台能力。
2. HAMi 的跨芯片虚拟化——昇腾 vNPU 切分和 NVIDIA MIG/vGPU 切分在 HAMi 层完成统一建模，对上层暴露完全一致的资源申请语义（`gpu-memory: 16GB, gpu-count: 1`）。
3. Volcano 的多策略级联调度——从信创合规到负载均衡到弹性溢出，策略可配置、可组合、可插拔。不是"选最优芯片"，而是"让每张芯片在最优时间做最优任务"。
4. 对正在规划一云多芯落地的团队，一个可操作的起点是：先部署 ANI 的 GPUInventory Port + HAMi，让昇腾和 NVIDIA 在同一个设备池中被发现。 这一步不需要修改任何模型代码或 CI 流水线，但它是后续所有自动化调度策略的基石。拿到设备池的统一视图之后，再逐步引入 Volcano 的优先级策略和亲和性溢出——每一步的收益都可量化、可验证。