HAMi 动态 MIG 切片插件深度解析NVIDIA GPU 按需切片、调度与生命周期管理【免费下载链接】HAMiHeterogeneous GPU Sharing on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ha/HAMi本文以 HAMi 仓库 docs/develop/dynamic-mig.md 为核心骨架讲解 HAMi 如何在 Kubernetes 中基于 NVIDIA MIGMulti-Instance GPU实现用户按需申请、系统自动切片的动态 GPU 切片能力。文章完整继承原文档的knownMigGeometries配置体系、任务示例与调度流程并进一步结合当前仓库中 topology-aware 的新实现migProfileAllowlist、hami.io/vgpu-mig-allocations预约注解以及 mig-dynamic-deallocate.md、dynamic-mig-migration.md 两篇配套文档从架构、配置、调度到回收给出端到端的技术指南。读完本文你将掌握如何在 HAMi 中配置 MIG 动态切片、如何通过注解让任务选择mig或hami-core模式、动态 MIG 的调度与实例创建流程以及从旧版模板模型迁移到新版 profile allowlist 模型的关键步骤与验证方法。背景为什么 HAMi 需要动态 MIGNVIDIA GPU 内置的共享方式主要有三种时间片time-slicing、MPSMulti-Process Service和 MIGMulti-Instance GPU。时间片共享存在频繁的上下文切换开销因此 HAMi 选择了 MPS 与 MIG 两条路线。MIG 可以将一块物理 GPU 划分为多个硬件隔离的计算实例GI/CI每个实例拥有独立的显存与算力边界。但 MIG 的 profile切片规格是可变的用户理论上可以按 profile 定义去获取 MIG 设备而旧实现只允许在用户请求之前预先定义好一套固定 profile这大大限制了 MIG 的使用弹性。dynamic-mig.md提出的目标正是开发一个自动切片插件用户提出需求时系统再动态创建对应的切片slice而不是让管理员提前把 GPU 静态切好。HAMi 本身基于 hami-core一个 CUDA 劫持库实现 vGPU 共享但 MIG 在全球范围同样被广泛使用。因此 HAMi 需要一个统一的 API同时覆盖 dynamic-mig 与 hami-core 两种虚拟化技术让上层任务以一致的方式申请 GPU。设计目标Targets原文档给出了该特性的核心目标CPU、内存与 GPU 的联合调度调度时同时考虑 CPU、Mem 与 GPU 显存而不是只盯显卡GPU 动态切片同时支持 hami-core 与 MIG 两种切片路径节点级 binpack 与 spread依据 GPU 显存、CPU 与 Mem 支持节点维度的装箱/打散调度策略统一 vGPU 资源池屏蔽不同虚拟化技术的差异形成一个统一的 vGPU Pool任务自由选择任务可以选择只用 MIG、只用 HAMi-core或者两者混用。总体结构动态 MIG 的整体结构如下hami-scheduler位于控制面核心负责配置管理与 NVIDIA 设备 API 对接每个计算节点运行hami-device-plugin按节点配置的 operating modeMIG / hami-core / MPS提供差异化服务。hami-scheduler通过 Config Manager 管理集群配置资源策略、MIG/MPS 参数通过 Device API 对接 NVIDIA 底层能力Node AMIG 模式device-plugin 以 MIG 模式将 GPU 切分为多个 MIG 实例供容器使用Node BHAMi-core 模式device-plugin 以 hami-core 模式提供 vGPUNode CMPS 模式device-plugin 通过 MPS 服务允许多个进程共享单块 GPU。调度器与所有节点双向通信调度器负责全局资源调度与节点状态监控节点插件负责本地资源的实时管理与上报。配置体系从 knownMigGeometries 到 migProfileAllowlist配置载体hami-scheduler-device-configMap原文档中插件配置包括 resourceName、MIG geometries 与节点级配置集中定义在名为hami-scheduler-device-configMap的 ConfigMap 中。在 Helm Chart 中该 ConfigMap 由 charts/hami/templates/scheduler/device-configmap.yaml 生成name 模板为{{ include hami-vgpu.scheduler . }}-device即默认的hami-scheduler-device其数据键为device-config.yaml。旧版knownMigGeometriesmaster 分支的模板模型dynamic-mig.md描述的是master分支上基于knownMigGeometries的实现管理员为每种 GPU 型号预先声明一组完整几何布局每行是一个合法的 profile 组合模板调度时从中挑选第一个能容纳当前请求的模板。原文档给出的完整示例配置如下apiVersion: v1 data: device-config.yaml: | nvidia: resourceCountName: nvidia.com/gpu resourceMemoryName: nvidia.com/gpumem resourceCoreName: nvidia.com/gpucores knownMigGeometries: - models: [ A30 ] allowedGeometries: - - name: 1g.6gb memory: 6144 count: 4 - - name: 2g.12gb memory: 12288 count: 2 - - name: 4g.24gb memory: 24576 count: 1 - models: [ A100-SXM4-40GB, A100-40GB-PCIe, A100-PCIE-40GB, A100-SXM4-40GB ] allowedGeometries: - - name: 1g.5gb memory: 5120 count: 7 - - name: 2g.10gb memory: 10240 count: 3 - name: 1g.5gb memory: 5120 count: 1 - - name: 3g.20gb memory: 20480 count: 2 - - name: 7g.40gb memory: 40960 count: 1 - models: [ A100-SXM4-80GB, A100-80GB-PCIe, A100-PCIE-80GB] allowedGeometries: - - name: 1g.10gb memory: 10240 count: 7 - - name: 2g.20gb memory: 20480 count: 3 - name: 1g.10gb memory: 10240 count: 1 - - name: 3g.40gb memory: 40960 count: 2 - - name: 7g.79gb memory: 80896 count: 1 - models: [ RTX PRO 6000 Blackwell Server Edition ] allowedGeometries: - - name: 1g.24gb memory: 24576 count: 4 - - name: 2g.48gb memory: 49152 count: 2 - - name: 4g.96gb memory: 98304 count: 1 nodeconfig: - name: nodeA operatingmode: hami-core - name: nodeB operatingmode: mig要点解读resourceCountName / resourceMemoryName / resourceCoreName定义了调度与上报所用的扩展资源名nvidia.com/gpu、nvidia.com/gpumem、nvidia.com/gpucoresknownMigGeometries按models分组每个模型可对应多组allowedGeometries即多种可切换的整卡布局模板每组由若干- name / memory / count三元组组成——name是 MIG profile 名memory是该 slice 的显存MBcount是数量nodeconfig为节点指定operatingmodehami-core或mig决定该节点上的 device-plugin 走哪条虚拟化路径。这个模型的痛点在于管理员必须为每种 GPU 型号手工维护显存、算力、实例数量与几何组合当新请求无法匹配当前几何时需要把整块 GPU切换到另一套模板运行中的实例会阻碍重配置固定布局中未被使用的实例也持续占用切片。新版migProfileAllowlist NVML 能力发现当前仓库已演进为 topology-aware 实现profile 能力显存、算力、数量、合法放置位置全部由拥有 GPU 的节点通过 NVML 发现配置中只声明集群允许使用的 profile 白名单。dynamic-mig.md开头也明确说明本仓库当前实现通过 NVML 发现 MIG 能力并使用migProfileAllowlist迁移与运维指引见 Migrating to HAMi Dynamic MIG最新架构见 Dynamic MIG Architecture。Chart 默认生成的migProfileAllowlist配置见 charts/hami/templates/scheduler/device-configmap.yamlnvidia: migProfileAllowlist: - models: [ A30 ] profiles: [ 1g.6gb, 2g.12gb, 4g.24gb ] - models: [ A100-SXM4-40GB, A100-40GB-PCIe, A100-PCIE-40GB] profiles: [ 1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb ] - models: [ A100-SXM4-80GB, A100-80GB-PCIe, A100-PCIE-80GB] profiles: [ 1g.10gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.79gb ] - models: [ H100-PCIE-80GB, H100-SXM5-80GB] profiles: [ 1g.10gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb ] - models: [ H100-PCIE-94GB, H100-SXM5-94GB] profiles: [ 1g.12gb, 2g.24gb, 3g.47gb, 4g.47gb, 7g.94gb ] - models: [ H20, H100 on GH200] profiles: [ 1g.12gb, 2g.24gb, 3g.48gb, 4g.48gb, 7g.96gb ] - models: [ H200 NVL, H200-SXM5] profiles: [ 1g.18gb, 2g.35gb, 3g.71gb, 4g.71gb, 7g.141gb ] - models: [ B200 ] profiles: [ 1g.23gb, 2g.45gb, 3g.90gb, 4g.90gb, 7g.180gb ] - models: [ RTX PRO 6000 Blackwell Server Edition ] profiles: [ 1g.24gb, 2g.48gb, 4g.96gb ]相比旧版操作者不再需要重复维护core、memory、count或合法放置数据——这些值由所属节点通过 NVML 发现。allowlist 的意义在于定义调度器允许使用哪些 profile这一集群策略避免把驱动上报的每一种能力都无条件暴露给调度器。配置校验逻辑位于 pkg/device/nvidia/mig_profiles.goValidateMigProfileAllowlist只做策略校验每个条目必须同时定义models与profiles且 profile 名必须形如Ng.xxx而 profile 的容量与拓扑信息一律来自节点上的 NVML。如果使用 Helm 部署Chart 默认值charts/hami/values.yaml中已包含migProfileAllowlist若通过device-config.content或外部 ConfigMap 覆盖了默认配置需要同步更新自定义内容旧字段不会被自动转换为新 allowlist。工作负载示例一个 YAML 同时兼容两种虚拟化动态 MIG 与 hami-core 任务完全兼容。任务只需设置nvidia.com/gpu与nvidia.com/gpumem系统会自动决定切片方式apiVersion: v1 kind: Pod metadata: name: gpu-pod1 spec: containers: - name: ubuntu-container1 image: ubuntu:20.04 command: [bash, -c, sleep 86400] resources: limits: nvidia.com/gpu: 2 # requesting 2 vGPUs nvidia.com/gpumem: 8000 # Each vGPU contains 8000m device memory Optional,Integer)如果任务希望明确只走mig或只走hami-core可以通过annotations.nvidia.com/vgpu-mode注解指定例如强制使用 MIGapiVersion: v1 kind: Pod metadata: name: gpu-pod1 annotations: nvidia.com/vgpu-mode: mig spec: containers: - name: ubuntu-container1 image: ubuntu:20.04 command: [bash, -c, sleep 86400] resources: limits: nvidia.com/gpu: 2 # requesting 2 vGPUs nvidia.com/gpumem: 8000 # Each vGPU contains 8000m device memory Optional,Integer)注解的取值常量在源码 pkg/device/nvidia/device.go 中定义为AllocateMode nvidia.com/vgpu-mode。仓库示例 examples/nvidia/dynamic_mig_example.yaml 展示了更完整的写法还可以叠加调度策略注解## This example will allocate 2g.10gb * 2 for A100-40GB-PCIE device ## or 1g.10gb * 2 for A100-80GB-XSM device. apiVersion: v1 kind: Pod metadata: name: gpu-pod annotations: nvidia.com/vgpu-mode: mig hami.io/gpu-scheduler-policy: binpack #(Optional) spec: containers: - name: ubuntu-container image: ubuntu:18.04 command: [bash, -c, sleep 86400] resources: limits: nvidia.com/gpu: 2 nvidia.com/gpumem: 8000需要说明的是nvidia.com/gpumem为可选整数参数表示每个 vGPU 包含的显存大小单位 MB。用户侧工作负载 YAML 通常无需因迁移而改动继续请求nvidia.com/gpu和nvidia.com/gpumem并选择nvidia.com/vgpu-mode: mig即可hami.io/vgpu-mig-allocations这类预约注解由调度器与 device-plugin 管理不是面向用户的 API。调度与分配流程Procedures一个使用动态 MIG 的 vGPU 任务的完整流程如下图所示流程分为**调度Filter与分配Allocate**两个阶段Filter 阶段hami-scheduler用户提交 Pod 后调度器遍历各节点并按其类型筛选——MIG 模式节点先检查是否有可用的 MIG Entry已存在的虚拟实例若没有再检查是否有可用的 MIG Template模板选择最优模板并匹配HAMi-core 模式节点检查节点整体资源是否满足直接筛选MPS 模式节点逻辑类似将所有符合条件的节点资源汇总为调度决策。Allocate 阶段hami-device-plugin按节点类型落地——HAMi-core 模式挂载 hami-core 资源 → 设置环境变量 → 挂载 GPU UUIDMIG 模式检查是否需要切换 MIG Template必要时通过 MIG-Parted 工具切换→ 查找可用 MIG 实例 → 挂载 MIG UUID完成资源挂载后启动容器。关于模板迭代有一个重要说明原文档原意提交任务后deviceshare 插件会遍历hami-scheduler-deviceConfigMap 中定义的模板找到第一个可容纳请求的模板。你随时可以修改该 ConfigMap 的内容并重启 scheduler 以定制模板策略。具体实例如果在一个空的 A100-PCIE-40GB 节点上提交上面的示例nvidia.com/gpu: 2nvidia.com/gpumem: 8000系统会选定一块 GPU 并选择如下 MIG 模板2g.10gb : 3 1g.5gb : 1随后容器将以2g.10gb实例 × 2 的方式启动——2 个 vGPU 各对应一个 2g.10gb 的 MIG 实例每实例 10240MB 显存满足 8000MB 请求剩余的 1g.5gb 实例可继续承接其他任务。当前架构reservation-first预约先行的拓扑感知动态 MIG原文档的knownMigGeometries模型已被当前仓库的**预约先行reservation-first**架构取代详见 Dynamic MIG Architecture。理解这一架构有助于把握动态 MIG 的正确打开方式device plugin publishes profiles and legal placements discovered through NVML ↓ scheduler selects GPU profile placement for a Pod ↓ Pod annotation persists the logical reservation ↓ device plugin creates the GI/CI at that placement ↓ device plugin records MIG UUID, GI ID, and CI ID ↓ the exact CI/GI is destroyed when the Pod terminates能力契约Capability Contractdevice-plugin 在 NVIDIA 节点注册注解中发布每个 allowlisted profile 的紧凑能力契约包括name、memoryMB、core、sliceCount与placementsNVML 上报的合法拓扑位置如{start: 0, size: 2}。设备本地的发现细节留在 device-plugin 进程内从而控制节点注解的膨胀。预约契约Reservation Contract调度器把精确预约写入hami.io/vgpu-mig-allocations注解。该注解常量的定义位于 pkg/device/nvidia/mig_allocations.goMigAllocation结构体同文件 L37-L46包含{ containerIndex: 0, deviceIndex: 0, gpuUUID: GPU-xxxxxxxx, profile: 2g.10gb, placement: {start: 2, size: 2}, migUUID: MIG-xxxxxxxx, gpuInstanceID: 4, computeInstanceID: 0 }调度器负责写容器索引、父 GPU UUID、profile、placement区间[start, startsize)device-plugin 负责补全MIG UUID、GPU Instance ID、Compute Instance ID在创建实例后回填。该注解是跨控制面与节点生命周期的一致化身份载体调度器据此重建占用拓扑、device-plugin 重启后据此恢复状态、Pod 终止后据此精确回收实例。解码侧mig_allocations.go会校验字段完整性runtime 身份必须三件套MigUUID / GPUInstanceID / ComputeInstanceID同时存在或同时缺失且(containerIndex, deviceIndex)不允许重复避免因半残注解造成误判。父 GPU UUID 与 GPU Instance ID 还能直接作为 DCGM 指标UUID、GPU_I_ID标签的关联键。核心工作流能力发布device-plugin 通过 NVML 发现 allowlisted profile 集合并发布契约调度器状态刷新将其转为每 GPU 的拓扑容量调度与预约调度器从活跃 Pod 预约重建占用profile 选择遵循最小可覆盖显存足够的最小 profile 优先除非任务用偏好注解改变顺序放置选择遵循确定性打包容量不足时任务停留在 Pending运行时实现kubelet Allocate 时 device-plugin 解析预约并与当前 NVML 能力核对MIG 实例管理器按物理 GPU 串行化变更在选定 placement 创建 GI 与 CI、解析运行时 ID 并回填记录预约键由 GPU profile placement 构成重复 Allocate 收敛到同一实例生命周期对账reconciler 从分配到节点的活跃 Pod 推导期望分配与受管实例比对释放已结束工作负载的分配周期性运行以支撑稳态清理与容量快速复用重启恢复启动时将活跃 Pod 预约与 NVML 进程活动结合识别承载活跃工作的 GPU空闲 GPU 进入干净的 MIG-ready 状态含 profile、placement、MIG UUID 的完整记录经 NVML 验证后被新进程收养。主动 shutdown 本身不会销毁运行中的实例。指定 MIG profile 偏好MIG 将显存与算力耦合因此可能出现两个 profile 都能覆盖同一显存请求、但算力不同的情况。例如在 A100-40GB 上一个 20GB 的请求默认总会被解析为3g.20gb最小可覆盖即使4g.20gb也在 allowlist 中。如果任务需要更多算力可设置nvidia.com/mig-profile-preference注解值为有序、逗号分隔的 profile 列表apiVersion: v1 kind: Pod metadata: name: mig-prefer-4g annotations: nvidia.com/vgpu-mode: mig nvidia.com/mig-profile-preference: 4g spec: containers: - name: workload image: ubuntu:22.04 command: [bash, -c, sleep 3600] resources: limits: nvidia.com/gpu: 1 nvidia.com/gpumem: 20000仓库示例见 examples/nvidia/dynamic_mig_profile_preference.yaml。语义要点注解解析实现在 pkg/device/nvidia/mig_preference.go每个条目可以是精确 profile 名如4g.20gb也可以是slice 类别如4g后者可跨 GPU 型号匹配一条4g同时覆盖 A100 与 H100 节点偏好只是倾向而非强制绝不会选择小于显存请求的 profile只作用于该 GPU allowlist 内的 profile未命中的条目在该 GPU 上被忽略若偏好 profile 无空闲 placement 或布局装不下容器切片调度器回退到默认顺序而不是拒绝该 GPU准入 webhook 会拒绝在所有 allowlist 条目中都匹配不到任何 profile 的值拼写错误在 Pod 创建时即被报出。迁移路径从旧模型迁移到动态 MIG由于本文所述文档是master分支的 legacy 设计对于正在运行旧版knownMigGeometries或 NVIDIA GPU Operator MIG Manager 的用户dynamic-mig-migration.md 提供了完整迁移指南核心要点如下。配置迁移geometries → profile allowlist旧版配置含core、memory、count与几何组合应转换为仅声明允许的 profilenvidia: migProfileAllowlist: - models: [A100-SXM4-40GB] profiles: [1g.5gb, 2g.10gb, 3g.20gb, 7g.40gb]当旧配置含多组几何时通常取各 profile 名的并集。例如7 × 1g 3 × 2g 1 × 1g 2 × 3g 1 × 7g转换为profiles: [1g.5gb, 2g.10gb, 3g.20gb, 7g.40gb]注意务必针对实际 GPU 型号核对 profile 名不要仅凭名义显存推断以 Chart 默认映射与 device-plugin 发现日志为起点再用目标驱动与硬件验证。分配身份迁移UUID 后缀 → Pod 注解旧实现把模板与槽位编码进设备标识如GPU-xxxxxxxx[1-2]新实现把完整分配身份存入hami.io/vgpu-mig-allocations。旧 Pod 不包含该完整身份且模板/槽位索引无法可靠推导每种 GPU 型号与既有硬件布局下的物理位置因此旧版 MIG Pod 在初次升级时必须 drain新实现宁可安全失败也不去猜测并冒险产生重叠切片。推荐迁移流程概览备份当前状态scheduler device ConfigMap、MIG 节点注册注解、活跃 MIG Pod 列表、nvidia-smi -L输出停止新调度cordon 待迁移的 MIG 节点Drain 旧版 MIG Pod等待工作负载结束或迁移迁移配置knownMigGeometries→migProfileAllowlist先升级 scheduler及配置再升级 device-plugin——避免旧 scheduler 向新节点下发不兼容分配逐节点升级 device-plugin先拿少量节点做 canary启动时空闲 GPU 会进入干净的 MIG-ready 状态可能销毁其上的既有 GI/CI验证节点能力device-plugin 日志应显示 profile/placement 发现节点注册注解中migProfiles非空验证完整生命周期创建 MIG Pod → 检查预约注解、NVML 可见实例、容器内 MIG UUID删除 Pod → 确认实例被释放canary 成功后逐步 uncordon 并恢复生产负载。如果从 NVIDIA MIG Manager 迁移核心原则是先确立单一所有权MIG Manager 与 HAMi 动态 MIG 都在变更 GI/CI 状态二者绝不能同时管理同一块物理 GPU。GPU Operator 可以继续提供驱动、Container Toolkit、DCGM 等组件但必须停止 MIG Manager 对目标节点的 geometry 对账仅删除一次 MIG Manager Pod 不够若其控制器配置会立即重建。支持边界迁移后通常不再需要 drain创建不同 allowlisted profile 的新 Pod删除 Pod 并回收 MIG 实例复用合法空闲 placementdevice-plugin 重启后收养可通过 NVML 验证的活跃实例。仍可能需要 drain/重启从旧模型的初次迁移从 MIG Manager 接管硬件变更所有权启停物理 GPU 的 MIG 模式驱动升级/GPU reset/平台要求的节点重启回滚到只懂旧几何与 UUID 编码的版本需要挪动运行中 GI/CI 的新布局HAMi 注解无法与 NVML 硬件状态关联的故障修复。验证清单摘要节点能力注册 GPUmode为mig每块目标 GPU 的migProfiles非空profile 显存、切片数量与 placement 和 NVML 能力一致未意外暴露不支持/未允许的型号。调度与实现Pod 使用nvidia.com/vgpu-mode: migscheduler 写入hami.io/vgpu-mig-allocations所选 profile 满足显存请求且 placement 不与活跃预约重叠Allocate 成功后注解包含 MIG UUID、GI ID、CI ID容器内可见的 MIG UUID 与注解、NVML 一致。回收与恢复删除 Pod 只释放其 CI/GI 而不影响其他 Pod 的实例后续 Pod 可复用同一 slicedevice-plugin 重启的启动清理不 reset 活跃 GPUKubernetes API/注解读取失败时跳过破坏性对账而不是猜测删除实例。推荐的场景覆盖单个1gPod 的创建/删除、单 GPU 上多个不重叠1g实例、1g/2g/3g混合放置、容量耗尽时 Pod 保持 Pending、删除小实例后复用其 placement、CUDA 负载运行中重启 device-plugin、注解缺失/仅含部分 runtime 身份时的安全失败、Kubernetes API 短暂不可用时不发生破坏性回收。结论动态 MIG 的价值在于把 MIG 从预先静态划分变成按 Pod 生命周期动态供给设备插件通过 NVML 发布真实能力调度器为每个 Pod 预约精确的 GPU profile placement设备插件按预约创建 GI/CIPod 终止时精确回收。它大幅降低了日常 profile 切换的频率与整卡重布局的影响范围但并不绕过 NVIDIA MIG 的硬件与驱动约束——启停 MIG 模式、驱动维护与回滚仍可能需要 drain 或重启节点。如果你的集群 MIG 需求长期稳定预分区的静态节点池依然是简单可靠的选择当 profile 需求随 Pod 生命周期动态变化、静态实例池利用率偏低、或 geometry 切换已成为日常运维负担时HAMi 的动态 MIG 正是为这类场景设计的方案。更多资料可进一步阅读Dynamic MIG Architecture、Migrating to HAMi Dynamic MIG相关源码与示例包括 pkg/device/nvidia/mig_profiles.go、pkg/device/nvidia/mig_allocations.go、pkg/device/nvidia/mig_preference.go、examples/nvidia/dynamic_mig_example.yaml 与 examples/nvidia/dynamic_mig_profile_preference.yaml。【免费下载链接】HAMiHeterogeneous GPU Sharing on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ha/HAMi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考