杂记

菜单

Administrator
发布于 2026-04-02 / 1 阅读
0

Mig基本使用

一、背景

在使用 NVIDIA GPU Operator 管理 MIG 时，常见做法是通过自定义 yaml 来声明多套 MIG 配置模板，然后再让不同节点选择不同模板。

这一过程里最容易混淆的点主要有三个：

  1. mig-configs 下面定义的名字是否固定
  2. 节点上的 nvidia.com/mig.config 是否自动生成
  3. 正确的执行顺序到底是什么

本文围绕这些问题进行梳理，并结合如下示例配置进行说明。

二、示例配置文件

mig:
  strategy: mixed  # Mixed 策略

migManager:
  enabled: true
  config:
    name: custom-mig-config   # ConfigMap 名称
    default: all-disabled     # 默认模板
    create: true              # 自动创建 ConfigMap
    data:
      config.yaml: |
        version: v1
        mig-configs:
          all-disabled:
            - devices: all
              mig-enabled: false

          H20-mixed:
            - devices: [0]
              mig-enabled: true
              mig-devices:
                1g.24gb: 4
            - devices: [1]
              mig-enabled: true
              mig-devices:
                1g.24gb: 4
            - devices: [2]
              mig-enabled: true
              mig-devices:
                1g.24gb: 4
            - devices: [3]
              mig-enabled: true
              mig-devices:
                1g.24gb: 4
            - devices: [4,5,6,7]
              mig-enabled: false

          H20-mixed-2:
            - devices: [0,1,2,3,4,5,6,7]
              mig-enabled: false

三、这份 YAML 的整体作用

这份文件的核心作用不是直接指定某台机器怎么切，而是：

  1. 启用 GPU Operator 的 MIG 管理能力
  2. 定义若干个可选的 MIG 配置模板
  3. 指定默认模板
  4. 将模板内容保存为 MIG Manager 可读取的配置

换句话说，这份 YAML 负责的是“提供模板”，而不是“把模板绑定到具体节点”。

四、配置结构解释

1. mig.strategy: mixed

mig:
  strategy: mixed

mixed 表示混合策略。

含义如下：

  • 同一台节点内，不同 GPU 可以采用不同配置
  • 某些 GPU 可以开启 MIG
  • 某些 GPU 可以保持整卡
  • 开启 MIG 的 GPU 之间，也可以存在不同切分方式

这种模式适合部分 GPU 切卡、部分 GPU 不切卡的场景。

2. migManager.enabled: true

migManager:
  enabled: true

表示启用 MIG Manager。

MIG Manager 负责：

  • 监听节点上的 MIG 相关标签
  • 根据指定模板执行 MIG 开关与切分
  • 更新节点上的状态标签

真正执行切卡动作的组件就是 MIG Manager。

3. config.name

name: custom-mig-config

表示创建或使用的 ConfigMap 名称为 custom-mig-config。

MIG Manager 会从这个 ConfigMap 中读取模板配置。

4. default: all-disabled

default: all-disabled

表示默认模板为 all-disabled。

也就是说，在未明确指定节点使用哪个模板时，节点会默认使用 all-disabled。

5. create: true

create: true

表示由 Helm 自动创建对应 ConfigMap，而不是手工提前创建。

6. data.config.yaml

这一段是真正的模板定义内容，其中 mig-configs 下面声明了多个模板名称。

五、mig-configs 的含义

1. all-disabled

all-disabled:
  - devices: all
    mig-enabled: false

含义：

  • 所有 GPU 都关闭 MIG
  • 所有 GPU 以整卡模式运行

这是一个默认模板，也可以作为恢复整卡的模板。

2. H20-mixed

H20-mixed:
  - devices: [0]
    mig-enabled: true
    mig-devices:
      1g.24gb: 4
  - devices: [1]
    mig-enabled: true
    mig-devices:
      1g.24gb: 4
  - devices: [2]
    mig-enabled: true
    mig-devices:
      1g.24gb: 4
  - devices: [3]
    mig-enabled: true
    mig-devices:
      1g.24gb: 4
  - devices: [4,5,6,7]
    mig-enabled: false

含义：

  • 0 号 GPU：开启 MIG，切成 4 个 1g.24gb
  • 1 号 GPU：开启 MIG，切成 4 个 1g.24gb
  • 2 号 GPU：开启 MIG，切成 4 个 1g.24gb
  • 3 号 GPU：开启 MIG，切成 4 个 1g.24gb
  • 4、5、6、7 号 GPU：关闭 MIG，保持整卡

这里的 devices: [0] 到 devices: [7] 表示的是单台节点内部的 GPU 编号。

3. H20-mixed-2

H20-mixed-2:
  - devices: [0,1,2,3,4,5,6,7]
    mig-enabled: false

含义：

  • 节点上的 0 到 7 号 GPU 全部关闭 MIG
  • 所有 GPU 保持整卡

从效果上看，这个模板和 all-disabled 类似，只是写法不同。

六、模板名是否固定

mig-configs 下面的模板名，例如：

  • all-disabled
  • H20-mixed
  • H20-mixed-2

本质上都是自定义名称。

这些名字没有特殊系统语义，主要作用是：

  1. 方便识别模板用途
  2. 供节点标签引用

例如，H20-mixed 这个名字通常只是表达：

  • H20：适用于 H20 GPU 的配置
  • mixed：混合模式模板

名字本身不会自动触发任何特殊行为，真正决定行为的是模板内部内容。

七、哪些内容可以自定义，哪些不能乱改

1. 可以自定义的内容

以下内容本质上是模板名称或配置命名，可以自行定义：

  • H20-mixed
  • H20-mixed-2
  • all-disabled
  • custom-mig-config

前提是引用关系保持一致。

2. 不能乱改的结构字段

以下字段属于配置格式的一部分，不能随意改名：

  • mig
  • strategy
  • migManager
  • enabled
  • config
  • name
  • default
  • create
  • data
  • config.yaml
  • version
  • mig-configs
  • devices
  • mig-enabled
  • mig-devices

3. 不能随便编造的 profile 名称

例如：

mig-devices:
  1g.24gb: 4

这里的 1g.24gb 不是随便起的名字，而必须是 GPU 实际支持的合法 MIG profile。

因此：

  • H20-mixed 可以自定义
  • 1g.24gb 不能随便编写

八、节点是如何知道该使用哪个模板的

节点通过标签 nvidia.com/mig.config 来选择模板。

例如，节点标签：

nvidia.com/mig.config=H20-mixed

表示这个节点要使用 mig-configs 下面名为 H20-mixed 的模板。

同理：

nvidia.com/mig.config=H20-mixed-2

表示这个节点要使用 H20-mixed-2 模板。

因此，关系可以理解为：

  • mig-configs 下面是在定义模板名
  • nvidia.com/mig.config=... 是在选择模板名

这两者必须完全一致。

九、节点标签是不是自动打的

1. 默认标签通常会自动出现

由于配置中写了：

default: all-disabled

节点通常会先以默认模板运行，也就是 all-disabled。

2. 目标模板标签通常需要手工设置

例如，想让某个节点应用 H20-mixed，通常需要手工执行：

kubectl label node <node-name> nvidia.com/mig.config=H20-mixed --overwrite

想让另一个节点应用 H20-mixed-2，则执行：

kubectl label node <node-name> nvidia.com/mig.config=H20-mixed-2 --overwrite

也就是说：

  • 默认值可能自动存在
  • 目标模板通常需要手工通过 kubectl label node 指定

十、nvidia.com/mig.config.state 的含义

除了 nvidia.com/mig.config 之外，节点上还会看到：

nvidia.com/mig.config.state=success

或

nvidia.com/mig.config.state=failed

这个标签表示模板应用状态。

1. success

表示当前节点指定的模板已经成功应用。

例如：

nvidia.com/mig.config=H20-mixed
nvidia.com/mig.config.state=success

表示该节点已经成功按照 H20-mixed 模板完成切卡。

2. failed

表示节点已经被要求使用某个模板，但执行失败。

例如：

nvidia.com/mig.config=H20-mixed-2
nvidia.com/mig.config.state=failed

表示该节点本来要按 H20-mixed-2 执行，但没有成功。

这并不代表模板名无法识别，而是表示模板已经选中，但应用过程出错。

十一、两台 8 卡主机场景说明

假设集群中有两台 8 卡节点。

节点 A 标签

nvidia.com/mig.config=H20-mixed
nvidia.com/mig.config.state=success

说明节点 A 已成功应用 H20-mixed，实际效果是：

  • GPU 0 到 3：各切成 4 个 1g.24gb
  • GPU 4 到 7：保持整卡

节点 B 标签

nvidia.com/mig.config=H20-mixed-2
nvidia.com/mig.config.state=failed

说明节点 B 被指定为使用 H20-mixed-2，也就是：

  • GPU 0 到 7 全部关闭 MIG
  • 所有 GPU 保持整卡

但实际执行失败了。

这说明“节点应该怎么切”是已经明确的，只是应用没有成功。

十二、正确的执行流程

一个容易混淆的问题是执行顺序。

错误理解

常见误解是：

  1. 写好 YAML
  2. 先给节点打标签
  3. 再执行 Helm

这个顺序不够稳妥，因为节点标签引用的模板可能在集群中还不存在，或者仍然是旧版本。

推荐流程

推荐顺序如下：

1. 编写好自定义 YAML

例如 custom-mig-profile.yaml，先把模板定义清楚。

2. 通过 Helm 安装或更新配置

如果 GPU Operator 已经安装过，通常使用 helm upgrade 反之使用helm install：

helm upgrade --wait gpu-operator -n gpu-operator nvidia/gpu-operator \
  --wait \
  --set driver.enabled=false \
  --set mig.strategy=mixed \
  --set toolkit.enabled=false \
  -f /data/gpu-mixed/custom-mig-profile.yaml

这一步的作用是先把新的模板写入集群中，让 MIG Manager 能够读取到。

# 1) 先更新 Helm 配置
helm upgrade --wait gpu-operator -n gpu-operator nvidia/gpu-operator \
  --wait \
  --set driver.enabled=false \
  --set mig.strategy=mixed \
  --set toolkit.enabled=false \
  -f /data/gpu-mixed/custom-mig-profile.yaml

# 2) 再重新触发节点配置
kubectl label node <node-name> nvidia.com/mig.config=all-disabled --overwrite
kubectl label node <node-name> nvidia.com/mig.config=H20-mixed --overwrite

之所以“先切到 all-disabled，再切回目标 profile`”这种方式，是因为如果标签值没变，可能就没有一个明确的“变更事件”去触发重新应用；而官方明确支持的是更新节点标签值来应用目标 profile。

还要注意一点：MIG Manager 在应用配置时，会停掉相关 GPU Pod，并在需要时处理重配流程；有些场景下还可能出现 rebooting 之类状态。因此在重配前，最好确保节点上没有占用 GPU 的工作负载，再观察 nvidia.com/mig.config.state 是否变成 success。

3. 给节点打标签，选择模板

例如：

kubectl label node node-a nvidia.com/mig.config=H20-mixed --overwrite
kubectl label node node-b nvidia.com/mig.config=H20-mixed-2 --overwrite

这样不同节点就会选择不同模板。

4. 检查状态

kubectl get node node-a --show-labels
kubectl get node node-b --show-labels

或者直接查看指定标签：

kubectl get node node-a -o jsonpath='{.metadata.labels.nvidia\.com/mig\.config}{"\n"}{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}'

十三、关键

1. mig-configs 下面的名字是模板名

例如：

  • H20-mixed
  • H20-mixed-2

本质上都是自定义名称。

2. 节点标签必须引用已存在的模板名

例如 YAML 里定义了：

mig-configs:
  H20-mixed:

则节点标签可以写：

nvidia.com/mig.config=H20-mixed

两者必须一致。

3. YAML 本身不区分哪台节点使用哪个模板

YAML 只负责定义模板，不负责绑定节点。

4. 节点到底使用哪个模板，由 nvidia.com/mig.config 决定

这是节点选择模板的入口。

5. 默认模板可能自动生效，自定义模板需要手工打标签

通常默认是 all-disabled，而切换到自定义模板需要手工指定。

6. 推荐流程是先 Helm 更新，再给节点打标签

这样可以保证节点引用到的模板已经存在于集群中。

UV常用命令整理