1、AI程序员系列文章

2、AI面试系列文章

3、AI编程系列文章

目录

一、那个GPU，它到底去哪了？

二、一张图看懂GPU调度全景

三、第一步：把Pod"绑"到GPU节点 — Node Selector & Affinity

3.1 最简单的方式：Node Selector

3.2 更智能的方式：Node Affinity

四、第二步：保护你的GPU — Taints & Tolerations

4.1 给GPU节点打上"专属污点"

4.2 让GPU Pod"容忍"污点

4.3 进阶：多级污点策略

五、GPU资源管理：nvidia.com/gpu 的前世今生

5.1 资源声明

5.2 GPU数量的坑

六、NVIDIA Device Plugin：GPU"翻译官"

6.1 安装Device Plugin（最简方式）

6.2 Device Plugin配置详解

七、GPU共享方案：从"一张卡一个人"到"全民共享"

7.1 方案一：NVIDIA MIG（多实例GPU）—— 物理隔离

7.2 方案二：Time Slicing（时间分片）—— 最易上手

7.3 方案三：NVIDIA MPS（多进程服务）—— 推理场景首选

八、多GPU拓扑分布：不要让PCIe成为瓶颈

8.1 GPU拓扑感知调度

8.2 Volcano GPU调度（进阶）

九、生产环境最佳实践：一张清单打天下

9.1 节点准备

9.2 Pod配置模板（开箱即用）

9.3 排障速查

一、那个GPU，它到底去哪了？

凌晨两点，我盯着kubectl describe pod的输出，看到了一个让我血压飙升的结果：

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4m28s default-scheduler 0/3 nodes are available: 3 Insufficient nvidia.com/gpu

三台带GPU的节点，一张卡都分不到。Pod就是这么硬生生Pending了4分钟。

不是没卡，是调度器不觉得他能用。

这是一个典型的K8s GPU调度翻车现场。更惨的是，隔壁老王直接裸机跑模型，比我早两小时下班，而我的Pod还在那儿挂着。

如果你也正在经历——或者是预防性地想避免——Pod调度到GPU节点失败、GPU利用率低、多个人抢一张卡这些问题，那这篇文章就是为你准备的。

💡核心问题就一个：K8s原生调度器对GPU的感知，和AI工程师对GPU的需求，中间隔着一道认知鸿沟。调度器只会数数（几块卡），但AI工作负载关心的是：什么型号、什么拓扑、能不能共享、显存够不够。填平这个鸿沟，就是本文要做的事。

二、一张图看懂GPU调度全景

先别急着写YAML，我们得把整个调度链路搞清楚。下面这张图覆盖了从Pod创建到GPU分配的全流程：

graph TB subgraph "用户层" A[AI工程师<br/>提交Pod/Deployment] end subgraph "K8s调度器" B[调度器接收Pod] C{节点过滤<br/>Filtering} D{节点打分<br/>Scoring} E[绑定Pod到Node] end subgraph "节点层面" F[Node Selector<br/>节点选择器] G[Node Affinity<br/>节点亲和性] H[Taints & Tolerations<br/>污点与容忍] end subgraph "GPU资源层" I[NVIDIA Device Plugin<br/>GPU发现与上报] J[nvidia.com/gpu<br/>资源计数] K[kubelet<br/>设备分配] end subgraph "GPU共享方案" L[NVIDIA MIG<br/>物理分片] M[Time Slicing<br/>时间分片] N[MPS<br/>多进程服务] end A --> B B --> C C --> F C --> G C --> H C --> I C --> J C --> D D --> E I --> K K --> J L --> K M --> K N --> K style A fill:#ff6b6b,color:#fff style E fill:#51cf66,color:#fff style I fill:#339af0,color:#fff style J fill:#339af0,color:#fff style L fill:#fcc419,color:#333 style M fill:#fcc419,color:#333 style N fill:#fcc419,color:#333

从这张图可以看出，K8s的GPU调度是一个“漏斗”模型：

1. 用户提交Pod，声明需要多少GPU
2. 调度器挨个节点做过滤（有没有足够GPU、有没有污点、亲和性匹不匹配）
3. 过滤通过的节点再打分（谁的资源更充裕、拓扑更优化）
4. 最终把Pod绑定到分数最高的节点

⚠️关键认知：大部分GPU调度问题，卡在第2步——过滤阶段。节点有卡但Pod就是调度不上去，八成是你的Node Selector写错了，或者Taint没配Toleration。

三、第一步：把Pod"绑"到GPU节点 — Node Selector & Affinity

有些人觉得：我有GPU节点，K8s不就该自动把GPU Pod调度过去吗？

错。K8s调度器不认识"GPU Pod"这个概念。除非你告诉它，否则它可能把GPU Pod调度到只有CPU的节点上，然后Pod自己发现没有CUDA设备，原地失败。

3.1 最简单的方式：Node Selector

apiVersion: v1 kind: Pod metadata: name: gpu-training-pod spec: nodeSelector: accelerator: nvidia-tesla-v100 # 标签匹配 containers: - name: training-container image: nvidia/cuda:12.1.0-runtime-ubuntu22.04 resources: limits: nvidia.com/gpu: 1 command: ["nvidia-smi"]

前提是你的GPU节点打上了对应标签：

kubectl label node gpu-node-01 accelerator=nvidia-tesla-v100 kubectl label node gpu-node-02 accelerator=nvidia-tesla-v100 kubectl label node gpu-node-03 accelerator=nvidia-a100

Node Selector 简单粗暴，但有个致命缺陷：只能做"等于"匹配。你说"我要V100"，但三台V100节点都在跑任务，只剩A100有闲卡——对不起，调不上去。

3.2 更智能的方式：Node Affinity

Node Affinity 支持更丰富的匹配规则：

apiVersion: apps/v1 kind: Deployment metadata: name: inference-service spec: replicas: 3 selector: matchLabels: app: inference template: metadata: labels: app: inference spec: affinity: nodeAffinity: # 硬性要求：必须有GPU，且型号至少是V100级别 requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu.present operator: In values: ["true"] - key: nvidia.com/gpu.product operator: In values: - NVIDIA-Tesla-V100 - NVIDIA-A100 - NVIDIA-A100-SXM4-40GB - NVIDIA-H100 # 软性偏好：优先选A100/H100 preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: nvidia.com/gpu.product operator: In values: - NVIDIA-A100 - NVIDIA-H100 containers: - name: inference image: mymodel/inference:v2 resources: limits: nvidia.com/gpu: 1

这里的两个关键字段：

💡实战建议：GPU标签最好用NVIDIA Device Plugin自动打的标签（如nvidia.com/gpu.product），而非自己手动打。手动标签容易过期，三周后你自己都不知道哪个节点是什么卡。

四、第二步：保护你的GPU — Taints & Tolerations

Node Selector 解决了"GPU Pod去哪"的问题，但没解决另一个问题：

CPU Pod别上GPU节点！

试想：你花几万块买的A100节点，部署了一个Prometheus、一个Nginx、一个日志采集器。这些纯CPU Pod随手就调度上去了，占端口、吃内存，GPU Pod反而Pending。这就像买了辆法拉利，天天开去买菜。

4.1 给GPU节点打上"专属污点"

# 给GPU节点打污点：只有带对应toleration的Pod才能调度上来 kubectl taint nodes gpu-node-01 nvidia.com/gpu=true:NoSchedule kubectl taint nodes gpu-node-02 nvidia.com/gpu=true:NoSchedule kubectl taint nodes gpu-node-03 nvidia.com/gpu=true:NoSchedule

三种Taint效果：

4.2 让GPU Pod"容忍"污点

apiVersion: v1 kind: Pod metadata: name: gpu-job spec: tolerations: - key: nvidia.com/gpu operator: Equal value: "true" effect: NoSchedule nodeSelector: accelerator: nvidia containers: - name: training image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime resources: limits: nvidia.com/gpu: 2

⚠️一个常见翻车点：Toleration 和 Node Selector都要配。Toleration 只是说"我能上GPU节点"，不代表"我只上GPU节点"。不加Node Selector的话，Pod还是可能被调度到CPU节点。两者是AND关系，不是OR关系。

4.3 进阶：多级污点策略

如果你的GPU节点还有"等级"之分，可以用多级污点：

# 专属GPU池（推理服务专用） kubectl taint nodes gpu-node-01 gpu-pool=inference:NoSchedule # 通用GPU池（训练/调试） kubectl taint nodes gpu-node-02 gpu-pool=training:NoSchedule kubectl taint nodes gpu-node-03 gpu-pool=training:NoSchedule

对应的Pod配置：

# 推理服务 - 只上推理池 tolerations: - key: gpu-pool operator: Equal value: "inference" effect: NoSchedule nodeSelector: gpu-pool: inference # 训练任务 - 只上训练池 tolerations: - key: gpu-pool operator: Equal value: "training" effect: NoSchedule nodeSelector: gpu-pool: training

这套组合拳下来，你的GPU节点就"刀枪不入"了——只有你明确允许的Pod才能调度上去。

五、GPU资源管理：nvidia.com/gpu 的前世今生

5.1 资源声明

K8s中GPU资源的声明方式非常直观：

resources: limits: nvidia.com/gpu: 2 # 声明需要2张GPU

但这里有个很多人忽略的细节：GPU资源的 requests 和 limits 必须相等。你写：

resources: requests: nvidia.com/gpu: 1 # ❌ 这行是无效的 limits: nvidia.com/gpu: 2

K8s处理GPU资源的方式和CPU/内存不同。对于扩展资源（Extended Resources）：

• requests会被K8s自动设置为等于limits（即使你显式写了requests也没用）
• GPU属于不可压缩资源，不支持超卖
• 每个Pod分配的GPU是独占的

5.2 GPU数量的坑

一张A100 80GB，跑一个7B的模型只需要20GB显存。按说一张卡能跑4个实例——但在K8s默认配置下，你只能跑一个。

因为nvidia.com/gpu: 1的语义是"一整张物理GPU卡"，不是"1GB显存"。这就是GPU利用率低的根源。

pie title GPU真实利用率（某AI团队实测数据） "真正用于计算" : 35 "显存占用但GPU空闲" : 25 "完全空闲" : 40

40%的时间GPU完全空闲，25%的时间显存占着但GPU计算核心闲着。只有35%的时间真正在跑计算。

💡这就是为什么GPU共享方案如此重要——放着一万块一张的卡闲着，比程序出Bug还让人心疼。

六、NVIDIA Device Plugin：GPU"翻译官"

K8s本身不认识GPU。它只知道CPU、内存、磁盘这些基础资源。那GPU从哪来的？

答案是NVIDIA Device Plugin。它是Kubelet的一个插件，专门负责：

1. 发现：扫描节点上有几张GPU、什么型号
2. 上报：把GPU资源上报给K8s（变成nvidia.com/gpu）
3. 分配：当Pod被调度到节点时，把GPU设备挂载到容器里

6.1 安装Device Plugin（最简方式）

# 使用NVIDIA官方的Helm Chart（推荐） helm repo add nvdp https://nvidia.github.io/k8s-device-plugin helm repo update helm install nvidia-device-plugin nvdp/nvidia-device-plugin \ --namespace nvidia-device-plugin \ --create-namespace \ --version 0.15.0 # 查看状态 kubectl get pods -n nvidia-device-plugin

安装成功后，检查节点资源：

kubectl describe node gpu-node-01 | grep nvidia

输出示例：

nvidia.com/gpu: 4 nvidia.com/gpu.memory: 327680 nvidia.com/gpu.product: NVIDIA-A100-SXM4-40GB nvidia.com/gpu.replicas: 4 nvidia.com/gpu.sharing-strategy: none

6.2 Device Plugin配置详解

NVIDIA Device Plugin支持通过ConfigMap定制行为：

apiVersion: v1 kind: ConfigMap metadata: name: nvidia-device-plugin-config namespace: nvidia-device-plugin data: config.yaml: | version: v1 flags: migStrategy: "none" # MIG策略：none / single / mixed failOnInitError: true # 初始化失败时是否让插件失败 nvidiaDriverRoot: "/" plugin: passDeviceSpecs: false deviceListStrategy: "envvar" deviceIDStrategy: "uuid" sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 # 每张物理GPU虚拟成4份

⚠️关于replicas参数：它让一张物理GPU在K8s眼中变成N份。比如A100设replicas: 4，K8s就认为这个节点有16个nvidia.com/gpu（4张×4=16），可以调度16个Pod上去。

但这是虚假繁荣！每个Pod分到的是时间片，不是独立的物理GPU。所有Pod共享同一张卡的CUDA核心和显存。如果你4个Pod每个都要用80GB显存——会直接OOM。

七、GPU共享方案：从"一张卡一个人"到"全民共享"

终于到了最核心的部分。上一节说到，默认的GPU资源模型是"1 Pod = 1~N张物理卡"，这在推理场景下极其浪费。下面我们看看三种主流共享方案。

graph LR subgraph "方案一: MIG" A[物理GPU] --> A1[GPU实例1<br/>20GB] A --> A2[GPU实例2<br/>20GB] A --> A3[GPU实例3<br/>20GB] A --> A4[GPU实例4<br/>20GB] end subgraph "方案二: Time Slicing" B[物理GPU] --> B1[时间片1] B --> B2[时间片2] B --> B3[时间片3] B --> B4[时间片4] end subgraph "方案三: MPS" C[物理GPU] --> C1[进程1] C --> C2[进程2] C --> C3[进程3] C --> C4[进程4] end style A fill:#51cf66,color:#fff style B fill:#339af0,color:#fff style C fill:#fcc419,color:#333

7.1 方案一：NVIDIA MIG（多实例GPU）—— 物理隔离

MIG是A100/A30/H100支持的硬件级分区技术，把一张物理GPU切成多个独立的GPU实例，每一份都有独立的显存、缓存和计算单元。

优点：

• ✅ 硬件级隔离，实例间互不影响
• ✅ 显存和计算资源都是固定的，不会互相抢占
• ✅ 适合多租户场景（推理服务A不会把推理服务B的显存撑爆）

缺点：

• ❌ 只有A100/A30/H100支持
• ❌ 切分后单实例性能下降（但隔离性换来的稳定更值钱）
• ❌ 配置后需要重启节点或重新配置GPU

MIG配置示例（A100 80GB切成 3g.20gb × 4）：

# 在GPU节点上启用MIG模式 nvidia-smi -i 0 -mig 1 # 查看可用MIG配置 nvidia-smi mig -lgip # 创建MIG实例 nvidia-smi mig -cgi 19,19,19,19 -C # 查看MIG实例 nvidia-smi mig -lgi

对应的K8s Device Plugin配置：

apiVersion: v1 kind: ConfigMap metadata: name: nvidia-device-plugin-config namespace: nvidia-device-plugin data: config.yaml: | version: v1 flags: migStrategy: "mixed" # 启用MIG模式 sharing: timeSlicing: resources: []

启用MIG后，K8s会看到类似nvidia.com/mig-3g.20gb的资源类型，每个Pod可以请求一个MIG实例。

7.2 方案二：Time Slicing（时间分片）—— 最易上手

Time Slicing是NVIDIA Device Plugin内置的能力，把GPU的计算时间切片分配给不同Pod。

优点：

• ✅ 配置简单，改个ConfigMap即可
• ✅ 支持所有GPU型号
• ✅ 不需要修改应用代码

缺点：

• ❌ 显存不隔离（一个进程OOM，全部受影响）
• ❌ 上下文切换有开销
• ❌ 没有QoS保证

完整配置示例：

apiVersion: v1 kind: ConfigMap metadata: name: nvidia-device-plugin-config namespace: nvidia-device-plugin data: config.yaml: | version: v1 sharing: timeSlicing: renameByDefault: false failRequestsGreaterThanOne: false resources: - name: nvidia.com/gpu replicas: 8 # 1张物理卡 = 8个虚拟GPU

安装时指定ConfigMap：

helm install nvidia-device-plugin nvdp/nvidia-device-plugin \ --namespace nvidia-device-plugin \ --create-namespace \ --set config.name=nvidia-device-plugin-config \ --set config.default=config

配置后，nvidia.com/gpu数量变成原来的8倍。每个Pod可以nvidia.com/gpu: 1，但实际只分到1/8的时间片。

⚠️Time Slicing的陷阱：replicas: 8不意味着你能跑8个模型。假设一张A100 80GB，你跑一个需要30GB显存的7B模型——最多只能跑2个（60GB < 80GB），第3个Pod会因为显存不足OOM。Time Slicing只管时间，不管显存。

7.3 方案三：NVIDIA MPS（多进程服务）—— 推理场景首选

MPS（Multi-Process Service）是CUDA提供的一个服务，允许多个CUDA进程共享GPU上下文，减少上下文切换开销。

优点：

• ✅ 真正的并行（不是时间片轮转）
• ✅ 对推理场景提升显著（吞吐量提升30-50%）
• ✅ 应用无感知

缺点：

• ❌ 一个进程崩溃可能影响同一MPS组的所有进程
• ❌ 需要额外配置
• ❌ 错误隔离不如MIG

MPS开启方式（在Device Plugin配置中）：

sharing: mps: resources: - name: nvidia.com/gpu replicas: 8

💡方案选择速查表：

八、多GPU拓扑分布：不要让PCIe成为瓶颈

当你需要多张GPU时（比如多卡训练），GPU之间的通信带宽就成了关键。两张卡如果不在同一个PCIe Switch下，你的训练速度可能直接腰斩。

8.1 GPU拓扑感知调度

K8s 1.27+ 引入了拓扑管理器（Topology Manager）配合Device Plugin实现NUMA感知的GPU分配。

apiVersion: v1 kind: Pod metadata: name: distributed-training spec: containers: - name: training image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel resources: limits: nvidia.com/gpu: 4 env: - name: NCCL_DEBUG value: "INFO" - name: NCCL_SOCKET_IFNAME value: "eth0"

但要真正做到拓扑感知调度，需要GPU拓扑感知调度插件，比如volcano的Gang Scheduling + Topology Policy。

8.2 Volcano GPU调度（进阶）

Volcano是K8s的批调度引擎，原生支持GPU拓扑感知：

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: multi-gpu-training spec: minAvailable: 4 schedulerName: volcano tasks: - replicas: 4 name: worker template: spec: containers: - name: training image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel resources: limits: nvidia.com/gpu: 2 command: - torchrun - --nproc_per_node=2 - --nnodes=4 - train.py

Volcano的优势：

• Gang Scheduling：要么所有Worker一次性调度成功，要么都不调度（避免部分节点卡着等）
• Binpack：尽量把Pod紧凑调度到同一节点，减少跨节点通信
• 拓扑感知：配合nvidia-topology插件，优先选择NVLink互连的GPU

⚠️多GPU训练避坑指南：

1. 检查GPU拓扑：nvidia-smi topo -m看GPU间的连接方式（NVLink > PCIe Switch > PCIe Host Bridge）
2. 设置NCCL环境变量：NCCL_P2P_LEVEL、NCCL_IB_DISABLE=1（没有RDMA时）
3. 优先同节点部署：跨节点的网络通信是百倍量级的延迟差距
4. 限制GPU可见性：用NVIDIA_VISIBLE_DEVICES或CUDA_VISIBLE_DEVICES精确控制

九、生产环境最佳实践：一张清单打天下

把前面所有知识点浓缩成一个实战Checklist：

9.1 节点准备

# 1. 安装NVIDIA驱动 + nvidia-container-toolkit # 2. 安装NVIDIA Device Plugin helm install nvidia-device-plugin nvdp/nvidia-device-plugin \ --namespace nvidia-device-plugin --create-namespace # 3. 打标签 kubectl label node gpu-node-0{1..4} node-role.kubernetes.io/gpu=true kubectl label node gpu-node-01 nvidia.com/gpu.product=NVIDIA-A100-SXM4-80GB # 4. 打污点 kubectl taint nodes gpu-node-0{1..4} gpu=true:NoSchedule

9.2 Pod配置模板（开箱即用）

apiVersion: apps/v1 kind: Deployment metadata: name: production-inference namespace: ai-workloads spec: replicas: 2 selector: matchLabels: app: inference template: metadata: labels: app: inference spec: # 【1】污点容忍：允许上GPU节点 tolerations: - key: gpu operator: Equal value: "true" effect: NoSchedule # 【2】节点亲和：只选A100节点 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu.product operator: In values: - NVIDIA-A100-SXM4-80GB - NVIDIA-H100-SXM # 【3】容器配置 containers: - name: inference-server image: myorg/llm-inference:v3.2 resources: limits: nvidia.com/gpu: 1 # 1张GPU memory: "64Gi" # 显存+主存需求 cpu: "8" requests: memory: "32Gi" cpu: "4" # 【4】GPU环境变量 env: - name: CUDA_VISIBLE_DEVICES value: "0" - name: NVIDIA_DRIVER_CAPABILITIES value: "compute,utility" # 【5】健康检查（模型加载慢，给足时间） readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 120 periodSeconds: 10 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 180 periodSeconds: 30

9.3 排障速查

十、写在最后

K8s的GPU调度，本质上是一套"资源翻译+策略路由"系统。NVIDIA Device Plugin负责把物理GPU翻译成K8s能理解的资源，而Node Selector、Affinity、Taints/Tolerations这些机制负责把资源路由到正确的Pod。

记住三个原则：

1. 隔离先行：Taint + Toleration 是所有配置的第一步，让GPU节点只服务GPU负载
2. 表达精确：Affinity 写清楚你需要的GPU型号，别让调度器猜
3. 共享是刚需：单一Pod独占一张GPU是巨大的浪费，根据自己的场景选MIG/Time Slicing/MPS

💡最后留一个思考题：你现在用MIG把A100切成了4份，每份20GB显存。来了一个Pod需要24GB显存跑模型——你怎么办？

（提示：答案是下篇文章要讲的内容——动态GPU资源调度。）

📢 下篇预告

《GPU资源调度深度实战：NVIDIA MIG + Time Slicing + HAMi》

MIG到底该怎么切？Time Slicing的坑有多少？Hami（阿里巴巴开源的GPU共享方案）为什么能做得更好？ 下篇文章带你从配置到监控，完整落地一套生产级GPU共享体系。 关注我，不错过后续更新 🔥

如果这篇文章帮你少踩了几个坑，不妨：

👍点赞— 让更多搞AI基建的同学看到 ⭐收藏— 下次配GPU调度回来翻，比查文档快 💬评论— 把你的GPU调度血泪史说出来，我们一起吐槽 🔔关注— 下一期《GPU资源调度深度实战》已经在写了

标签：#Kubernetes #GPU调度 #AI工作负载 #NVIDIA #DevicePlugin #K8s #GPU共享

原创文章，转载请注明出处