分子模拟异构算力适配开发教程15批调度集成——Volcano gang scheduling 与昇腾 vNPU 切分版本声明块工具/软件Volcano v1.14.2CNCF 孵化MindClusterAscend/mind-cluster 仓库原 MindX DL 6.0.RC1 起的开源体系语言/环境Kubernetes、昇腾 Atlas A2 系列硬件本文目标读完你能为一个多副本 MD 任务如增强采样写出 gang 调度的 Volcano 作业并理解 vNPU 的 vir 模板如何切分昇腾卡一句话结论Volcano 的核心对象PodGroupCRD用spec.minMember实现 gang 语义——源码注释原文 “if there’s not enough resources to start all tasks, the scheduler will not start anyone”资源不够就一个都不启动昇腾 vNPU 用vir 模板切分物理 NPU如vir12_3c_32g 12 AICore 3 AICPU 32GB即 Atlas A2 训练卡 1 切 2静态用npu-smi set -t create-vnpu创建、动态由容器按ASCEND_VNPU_SPECS自动切。〇、本篇要解决的认知问题为什么 MD 的多副本任务增强采样、多 walker需要 gang schedulingPodGroup 的 minMember 语义是什么Volcano 的 Queue配额/借用/抢占与原生 K8s 的 ResourceQuota 有什么不同Volcano 怎么跑 MPI 作业GROMACS 多 rank 的载体昇腾 vNPU 的静态/动态切分怎么操作vir 模板命名怎么读一、机制解析1.1 为什么 MD 需要 gang从“任务组”说起为什么这一节对你重要第 20 篇的平台要调度的一大类任务就是“必须整组起、否则全废”的——增强采样的 N 个 walker每个 walker 是独立 mdrun但共享统计权重、多副本交换REMD 的 N 个温度副本间要定期交换构象、多尺度耦合的组件。这类任务用原生 K8s 调度的风险部分 Pod 起来了、部分因资源不足 Pending——起来的那些空烧算力等同步永远等不到。Volcanov1.14.2CNCF 首个官方容器批调度项目扩展增强标准 kube-scheduler的答案PodGroupCRDscheduling API 组shortNamepg。源码 types.go 的注释就是权威语义“PodGroup is a collection of Pod; used for batch workload”spec.minMember“defines the minimal number of members/tasks to run the pod group;if there’s not enough resources to start all tasks, the scheduler will not start anyone”这就是 gang scheduling组调度要么整组起、要么整组等——消灭“半启动”的资源浪费。PodGroup 相位流转Pending → Inqueue → Running → Unknown/Completed。Volcano 官网对 gang 的表述“Ensure all tasks of a job start simultaneously, suitable for distributed training and big data scenarios”——分布式训练与 MD 多副本是同构场景MPI 全体 rank 到齐才能 mdrun。组件三件套Quick Start 输出可见volcano-admission、vc-controller-manager、volcano-scheduler部署kubectl apply -f .../installer/volcano-development.yaml。1.2 Queue批调度的资源经济学PodGroup 通过spec.queue归属队列默认值default。Volcano Queue 的能力集官网特性 types.go多维资源配额CPU/Memory/GPU、多级队列与资源继承、队列间借用/回收/抢占capability 之上借闲、配额紧张回收状态 Open/Closed/Closing/Unknown。与原生 ResourceQuota 的本质差异ResourceQuota 是“限额静态切片”Volcano Queue 是“配额弹性回收的动态分配”——批负载的潮汐特性白天交互作业、夜间批量 MD需要后者。其他调度策略官网原文Binpack、Proportion/Capacity、NodeGroup、DRF、SLA、Task-topology、NUMA Aware。对 MD 平台的意义不同课题组/项目分队列配额保证空闲时段互相借用利用率紧急项目抢占优先级——第 20 篇平台的“资源治理层”就是 Queue 体系。1.3 MPI 作业GROMACS 多 rank 的正确姿势Volcano 仓库自带 MPI 集成示例example/integrations/mpi实测含 mpi-example.yaml 与 Dockerfile。结构要点MPI 作业的通用形态Launcher Pod跑 mpirun/mpirun 的入口 Worker Pods各持一块卡PodGroup 把它们绑成 gang设备经 device plugin 下发NVIDIA 的 nvidia.com/gpu 或昇腾的 huawei.com/ascend-910以 MindCluster 上报名为准任务内通信rank 文件/主机名发现昇腾侧由 MindCluster HCCL Controller 生成 rank table见 1.4。GROMACS 的对应物mpirun -np N gmx mdrunN rank 域分解正是 MPI 作业原型第 13 篇的直连 GPU 通信与-gputasks在这个载体上才有意义单机 thread-MPI 不需要 gang。1.4 昇腾 MindCluster 与 vNPU 切分MindClustergithub.com/Ascend/mind-cluster昇腾官方集群调度组件族MindX DL 6.0.RC1 起的开源化体系。component/ 目录实测子组件2026-09ascend-device-pluginNPU 的 K8s 上报第 14 篇协议的昇腾实现、ascend-for-volcanoVolcano 的昇腾调度插件——Volcano 与昇腾的官方接合点、ascend-docker-runtime容器设备运行时、ascend-dynamic-resource-allocation、ascend-operator、infer-operator、npu-exporter 等。一个仓库考古注意调研底账master 分支 component/ 里没有 ascend-hccl-controller 目录GitHub 独立仓库 Ascend/ascend-hccl-controller 已 404——该组件现名 “MindCluster HCCL Controller”源码在 Gitee华为文档确认作用配合 MindCluster Volcano 与 Ascend Device Plugin 为训练任务生成 rank table 通信配置。vNPU 切分官方文档物理 NPU 按 AICore/AICPU/内存/DVPP 切成 vNPU 挂给容器一个 vNPU 只能被一个任务容器用。两种模式静态先npu-smi set -t create-vnpu -i id -c chip_id -f vnpu_config创建再挂载动态容器拉起时按ASCEND_VISIBLE_DEVICES、ASCEND_VNPU_SPECS环境变量自动切分。vir 模板官方表Atlas A2 训练系列 24 AICore模板切分规格vir12_3c_32g1 卡 2 份12 AICore 3 AICPU 32GB约半卡算力vir06_1c_16g1 卡 4 份6 AICore 1 AICPU 16GB命名规则vir AICore 数_c AICPU 数 _g 内存 GB。查询可用模板npu-smi info -t template-info。其他系列训练 30/32 核vir02/04/08/16A2 推理 20 核vir05_1c_8g 等A3 训练 48 核见官方模板表。vNPU 的定位与铁律 9昇腾上跑的是 AI 负载DeePMD 等第 11 篇切分收益判断同理——但 AI 推理负载小 batch、算力敏感与 MD带宽敏感的切分曲线完全不同不要把 MD 的切分结论搬到 AI 负载上反之亦然。二、完整代码与逐行剖析一个完整的“增强采样 gang 作业”——Volcano VolcanoJob PodGroup 多 walker mdrun把第 1.1 节的语义落成 YAML# md-replica-gang.yaml —— 多副本 MD 的 gang 调度VolcanoJob# 场景8 个 walker 的增强采样——8 个 mdrun 必须同时起定期交换构象/权重# 起一半 全部白烧gang 语义的教科书场景apiVersion:batch.volcano.sh/v1alpha1kind:VolcanoJob# Volcano 的 Job 对象含 PodGroup 语义metadata:name:md-enhanced-sampling-8wspec:schedulerName:volcano# 关键用 Volcano 调度器而非 defaultminAvailable:8# gang 语义8 个任务不齐就一个都不起对应 PodGroup minMemberqueue:md-batch# 归属队列见下方 Queue 定义tasks:-replicas:8# 8 个 walker各自一个 Pod、各持一块卡name:walkertemplate:spec:restartPolicy:NeverschedulerName:volcanocontainers:-name:gmximage:your-registry/gromacs-musa:2026.1# 每个 walker 用自己的副本编号算 tpr/输出WALKER_ID 由 Volcano 注入 task 序号可用# $(VOLCANO_TASK_INDEX) 类索引——生产实现见第 20 篇的适配层封装command:-/bin/bash--c-gmx mdrun -s /data/walker.tpr -deffnm /out/walker-$HOSTNAME -nb gpu -pme gpu -pmefft gpu -bonded gpu -update gpu -gpu_id 0 -pin on -noconfoutresources:limits:nvidia.com/gpu:1# 每 walker 一整卡MD 带宽敏感——铁律 9不切分cpu:8memory:16GivolumeMounts:-{name:data,mountPath:/data}-{name:out,mountPath:/out}volumes:-{name:data,hostPath:{path:/srv/md-data}}-{name:out,emptyDir:{}}---# 队列定义资源治理1.2 节语义的落地apiVersion:scheduling.volcano.sh/v1beta1kind:Queuemetadata:name:md-batchspec:weight:3# 相对权重Proportion 策略下的配额比例reclaimable:true# 空闲资源可被其他队列借用本队列紧张时可回收capability:# 上限借用也不能超cpu:64memory:256Ginvidia.com/gpu:16# ── vNPU 静态切分实操昇腾侧官方命令──────────────────────────# 1. 查询本系列硬件支持的模板官方命令npu-smi info-ttemplate-info# 2. 把物理 NPUid 0 的 chip 0按 vir12_3c_32g 切成 1/2 卡npu-smiset-tcreate-vnpu-i0-c0-fvir12_3c_32g# 3. 容器侧挂载K8s MindCluster 场景走 ASCEND_VISIBLE_DEVICES/ASCEND_VNPU_SPECS# 环境变量由 ascend-device-plugin 按调度结果注入——第 14 篇 Allocate 语义逐段剖析YAMLminAvailable: 8是 gang 语义的落点——删掉这一行作业退化回“各自调度”半启动风险回归。注释里写明“为什么”定期交换构象——YAML 里保留“为什么”是基础设施代码的可维护性纪律。schedulerName: volcano出现在两处Job 级与 Pod template 级——Volcano 文档的稳妥写法防调度器穿透。queue: md-batch Queue 对象的组合是 1.2 节“资源经济学”的最小实现weight 定配额、reclaimable 开借用/回收、capability 封顶——三行配置就是一套多课题组共享治理的雏形。walker 命令里的-gpu_id 0每 Pod 只见自己分到的卡device plugin 注入的可见性第 14 篇所以永远 0 号——可见性隔离让“选卡”问题在调度层就消失第 18 篇适配层会把它固化成约定。三、常见报错与排查问题 1现象——VolcanoJob 一直 Pendingkubectl describe podgroup显示 Inqueue 但不 Running。根因gang 在等资源——minAvailable 要求的任务数与当前可用资源不匹配比如要 8 卡、集群闲时只有 6 卡。这是 gang 的正常行为不是故障真正的故障是这种状态持续很久资源碎片化或队列配额不足。解法kubectl describe queue md-batch看队列配额与占用核对 minAvailable 与实际需求walker 数是硬需求吗能否 6 个起跑——业务问题资源碎片用 Binpack 策略缓解官网调度策略。问题 2现象——MPI 作业LauncherWorker起来后 mpirun 报 rank 连不上通信超时。根因容器网络未打通 MPI 的通信模式rank 间直连常见于默认 CNI 限制或主机名发现失败昇腾侧则可能是 rank table 没生成HCCL Controller 组件未部署。解法对照 Volcano 官方 MPI 示例example/integrations/mpi核对网络/hostfile 配置昇腾场景确认 MindCluster 组件齐备ascend-for-volcano HCCL ControllerGROMACS 侧优先考虑单节点多卡thread-MPI-gputasks绕开跨节点 MPI 复杂度第 13 篇的直连通信在单节点收益已很可观。问题 3现象——vNPU 容器报“设备不存在”或算力明显低于模板规格。根因静态切分的 vNPU 没创建成功npu-smi set 参数错-i 是 NPU id、-c 是 chip id两者别混或模板名拼写错vir12_3c_32g 的下划线与数字段有严格格式或容器用的是动态切分但 ASCEND_VNPU_SPECS 值不合法。解法npu-smi info先确认 vNPU 已存在npu-smi info -t template-info对照模板名逐字符核对K8s 场景改走 MindCluster 的动态切分路径环境变量由 plugin 注入减少手滑面。问题 4现象——安装 Volcano 后部分原生 Deployment 调度行为异常。根因Volcano 是批调度增强不是替代——装了它不会自动接管没写schedulerName: volcano的工作负载但如果误把 volcano-scheduler 配成默认调度器原生负载会按批调度语义走行为差异。解法保持 kube-scheduler 为默认Volcano 按作业显式指定本篇 YAML 的写法只在“整个集群都是批负载”的场景才考虑反转默认。四、动手练习练习 1基础在测试集群或 kind/minikube部署 Volcano官方 installer YAML创建本篇的 Queue 与一个 minAvailable: 2 的两副本作业观察 PodGroup 相位流转。判定成功标准kubectl get podgroup显示相位从 Pending 到 Inqueue 到 Running故意把副本资源请求调到超过集群容量观察到“一个都不起”gang 生效的直接证据。练习 2进阶把作业改成minAvailable: 1再跑对比行为差异然后在队列上设 capability 低于需求观察借用/回收行为。判定成功标准能口头复述两种配置下调度器的决策差异gang on/offcapability 触发时作业停留在 Inqueue 的现象与 describe 输出证据。练习 3思考题无标准答案你的 MD 平台有三种负载交互式短作业用户等结果、夜间批量采样8 小时窗口、月度大项目独占期。Queue 体系怎么设计思考方向验证要点① 三队列的 weight/reclaimable/capability 各怎么定② 交互作业的 SLA 靠什么保证抢占优先级预留配额③ 与第 17 篇“批调度器”应用层的分工边界——哪些逻辑放 Volcano、哪些放应用层。五、小结与下一篇预告本篇把调度从“设备级”升到“作业组级”PodGroup 的 minMember 语义资源不够就一个都不起是 gang 的本质多副本 MD增强采样/REMD是它的天然客户Queue 的配额/借用/回收构成资源治理层MPI 集成示例是 GROMACS 多 rank 的 K8s 载体昇腾侧 MindClusterascend-device-plugin/ascend-for-volcano接入 Volcano 生态vNPU 用 vir 模板切分vir12_3c_32g 12 核 3CPU 32GB 半卡静态 npu-smi/动态环境变量两条路。MD 大带宽负载的切分决策延续铁律 9。下一篇补齐调度版图的最后一块传统 HPC 路线——Slurm 的 GRES 机制gres.conf/--gresgpu:N/CUDA_VISIBLE_DEVICES 注入与 Apptainer 容器化–nv/SIF——很多算力中心同时有 Slurm 与 K8s第 18 篇的适配层要同时伺候两边的调度语义。本篇认知问题回显FAQQ1Volcano 的 gang scheduling 是什么MD 什么时候需要它AVolcano 用 PodGroup CRD 的 spec.minMember 实现 gang 语义源码注释资源不足以启动全部任务时一个都不启动保证任务组要么整组起要么整组等MD 的多副本任务需要它——增强采样的多 walker、REMD 的温度副本间要定期交换起一半等于全废。Q2Volcano 的 Queue 和 K8s 原生 ResourceQuota 有什么区别AResourceQuota 是静态限额切片Volcano Queue 是动态资源治理——多维配额CPU/Memory/GPU、多级队列、队列间借用reclaimable与回收、按权重weight分配另有 Binpack/DRF/SLA/NUMA Aware 等调度策略适合批负载的潮汐特性。Q3昇腾的 vNPU 怎么切分vir12_3c_32g 是什么意思AvNPU 把物理 NPU 按 AICore/AICPU/内存切分挂给容器一个 vNPU 只能被一个任务容器使用vir 模板命名规则是 virAICore 数_cAICPU 数_g内存GBvir12_3c_32g 即 12 AICore 3 AICPU 32GBAtlas A2 训练卡 24 核的半卡1 卡切 2 份静态用 npu-smi set -t create-vnpu -i -c chip_id -f 模板动态由容器按 ASCEND_VISIBLE_DEVICES/ASCEND_VNPU_SPECS 自动切。Q4昇腾的 K8s 调度组件有哪些和 Volcano 什么关系AMindClustergithub.com/Ascend/mind-cluster组件族含 ascend-device-pluginNPU 上报 K8s、ascend-for-volcanoVolcano 的昇腾调度插件——官方接合点、ascend-docker-runtime、npu-exporter 等MindCluster HCCL Controller现由华为文档命名、源码在 Gitee负责为训练任务生成 rank table——昇腾调度官方路径就是“MindCluster 组件 Volcano 批调度”的组合。