## 一、一个让人心疼的现场：GPU 99% 的时间在等 CPU

先讲个真实的烦恼。你组里一个训练任务，跑了三天，`nvidia-smi` 一查：GPU 利用率 60%，还一跳一跳的，像打摆子。算法同学说"代码没问题"，网络同学说"带宽没跑满"，存储同学说"I/O 也没瓶颈"。

那 GPU 的时间去哪了？

答案是：**CPU 没把活喂到 GPU 嘴边**。训练循环里，CPU 要干的事一大堆——从磁盘读数据、分词、做数据增强、把 batch 搬进显存、调度 kernel 启动、协调多线程。这一长串主机侧工作里任何一环慢半拍，昂贵的 GPU 就得空转等下一批数据

书里那句原话很扎心：GPU 饿肚子最常见的原因，就是 CPU 没给它提供有用的工作。

这一篇就把"喂 GPU"这件事拆开，从 CPU 内存拓扑、内存管理、GPU 运行时、容器四个层面，把单机性能的每一分钱都抠出来。

![fig11-numa-topology.png](https://developer.qcloudimg.com/http-save/yehe-11479707/7c145b8edaee7575693ef6a3648ef2c0.png)

## 二、NUMA：GPU 跟错了 CPU，数据要"跨城快递"

现代服务器是双路（甚至更多路）CPU，每路 CPU 连着自己的内存和一部分 GPU/NIC，这个物理分组叫 **NUMA 节点**。同一个节点内的访问是"同城快递"，跨节点就是"跨城快递"——延迟直接翻倍。

书里给了一组实测：本地 NUMA 内存访问延迟约 **80ns**，跨节点约 **139ns**，暴涨 75%。别小看这几十纳秒，训练循环里 CPU 要做的内存访问是亿次级的，每次多等 60ns，累积起来就是肉眼可见的吞吐差（来源：*AI Systems Performance Engineering* 第 3 章 3.3.1 节）。

**白话解释**：NUMA 就是"谁的东西离谁近"。GPU 0 插在 CPU 0 的 PCIe 槽上，它俩是一伙的；如果进程跑在 CPU 1 上却要伺候 GPU 0，那 CPU 1 得先"跨城"去读 CPU 0 侧的内存，再把数据搬到 GPU 0——两头都是冤枉路。

Linux 默认有 NUMA balancing，但对 AI 这种性能敏感负载通常不够，进程还会被调度器到处迁移。正确做法是**显式绑定**，三个工具任选：

```bash
# 方式一：numactl 同时绑定 CPU 节点和内存节点
numactl --cpunodebind=1 --membind=1 python train.py --gpu 5

# 方式二：taskset 绑定具体核心
taskset -c 24-31 python train.py --gpu 5

# 方式三（推荐动态写法）：先查 GPU 属于哪个 NUMA 节点
for GPU in 0 1 2 3; do
  NODE=$(nvidia-smi topo -m -i $GPU | awk '/NUMA Affinity/ {print $NF}')
  numactl --cpunodebind=$NODE --membind=$NODE \
    bash -c "CUDA_VISIBLE_DEVICES=$GPU python train.py --gpu $GPU"
done
```

注意 `--membind` 要和 `--cpunodebind` 一起用：只绑 CPU 不绑内存，进程可能跑在节点 0 却用着节点 1 的内存，绑定白做（来源：*AI Systems Performance Engineering* 第 3 章 3.3.2 节）。

还有个细节：numactl 的策略会被 fork 出来的子进程继承，但 **spawn 启动的子进程不继承**。PyTorch DataLoader 的 worker 如果走 spawn，内存绑定就丢了——所以要么保持 fork 模型，要么在 worker 里手动设置亲和性（`worker_init_fn`）。

在 GH200/GB200 这类 Grace 超级芯片上，CPU 和 GPU 用 NVLink-C2C 直连（约 900GB/s 一致性带宽），但 Linux 仍把 CPU 内存和 GPU HBM 分开管理，照样要尊重数据局部性。

**我的判断**：NUMA 绑定是单机调优里投入产出比最高的一步，纯配置、零代码改动、风险几乎为零。K8s 环境别忘了配合拓扑管理器（后面集群篇细说），物理机直接上 numactl。

## 三、内存：固定、大页、别交换，三件套

CPU 侧的第二个大头是内存管理。三个旋钮，按收益排序：

**① 内存固定（pinned memory）：+10%~20% 吞吐**

普通内存是"可分页"的，OS 随时可能把它挪走；固定内存（页锁定）OS 不能动它，GPU/NIC 就能直接 DMA 读走，不需要 CPU 临时钉页。从固定内存拷数据到 GPU，比从可分页内存**快 2-3 倍**。

落地极其简单——PyTorch DataLoader 加一个参数：

```python
DataLoader(dataset, batch_size=256, pin_memory=True)
```

就这一行，很多团队实测主机到设备传输吞吐提升 10%~20%（来源：同上）。

两个坑：

- OS 对锁定内存有上限（`ulimit -l`），默认可能只有 64KB，大 buffer 直接分配失败。AI 集群惯例是设成 unlimited，容器里对应 `--ulimit memlock=-1`。
- GPUDirect RDMA / GDS 都是建立在"内存固定"之上的，固定内存是它们的地基。

**② 透明大页（THP）：+3%~5% 吞吐，但推理慎用**

Linux 默认用 4KB 小页管理内存，大模型动辄几十上百 GB 内存，管理几百万个小页，页表（TLB）压力很大。打个**比**——大页就像把散装小信封换成整箱发货，量大快递费便宜，可**整箱打包时会卡一下**——这就是 THP 的后台压缩。THP 用 2MB 大页兜底，减少页错误和 TLB miss，一般能拿 3%~5% 吞吐。

**但**：THP 的整箱压缩会引入不可预测的停顿，对延迟敏感的推理负载是灾难。业界共识是——**训练开 THP，推理关 THP**（或改 madvise 模式）。分布式训练里多个 rank 同时申请大内存的场景同样建议关闭，避免压缩风暴。

**③ 交换（swap）：必须杜绝**

GPU 程序会在主机内存里缓存大量数据，一旦 OS 把一部分换到磁盘，GPU 要数据时就是灾难性的、数量级的延迟。书里的建议很直接：`vm.swappiness=0`，除非极端内存压力否则不交换；容器里再用 cgroup 内存限制把作业隔离起来。

![fig11-cpu-binding.png](https://developer.qcloudimg.com/http-save/yehe-11479707/18962fef1549cc811ed38252c68bf234.png)

## 四、GPU 运行时：持久化模式，别让 GPU 反复"开机"

GPU 驱动默认在没人用的时候会把卡降到低功耗状态、卸载驱动上下文。下一个任务要用时，驱动重新初始化要花一两秒。训练集群里作业频繁启停，推理集群里请求稀疏——每来一个请求都要等 GPU"睡醒"，积少成多就是白白流失的吞吐。

解法是**持久化模式**：跑一个 `nvidia-persistenced` 守护进程，让驱动常驻、GPU 保持就绪，下一个作业零启动延迟。AI 集群的惯例是开机就在所有卡上启用：

```bash
systemctl enable nvidia-persistenced
```

K8s 环境用 NVIDIA GPU Operator 也能自动在所有 GPU 上开启。唯一代价是空闲功耗略高，对数据中心 GPU 来说，用这点电换性能一致性，值。

**白话解释**：持久化模式就是不让 GPU 睡懒觉。它不会让数学算得更快，但能砍掉冷启动延迟——作业一来就能开跑。

## 五、一张卡多人用：MPS、MIG、时间片怎么选

这是多租户/多任务场景的经典选择题。一张 80GB 的卡，四个推理服务各用 5-10GB、各占 30% 算力，怎么分？

**默认行为（时间分片）**：GPU 调度器在进程间频繁切换，同一时刻只有一个进程的 kernel 在跑，其他三个等着。结果就是卡 70% 时间闲着。

**MPS（进程级并发）**：把多个进程的上下文合并进一个调度上下文，kernel 可以真正并发跑——A 在等内存时 B 的 kernel 填上来。书里给的数据：两个各占 40% 的进程，开 MPS 后整卡利用率能到 80%~90%；两个原本各要 1 小时的训练进程，并发跑总共只要 1 小时多一点而不是 2 小时（来源：同上）。

**MIG（硬件级隔离）**：把 GPU 在硬件层面切成最多 7 个实例，每个有独立的内存和 SM。隔离最强、互不干扰，适合"不同租户、安全隔离、SLA 严格"的场景；代价是灵活性差——空闲实例的资源不能借给邻居，切 MIG 模式要重启 GPU，是静态配置不是动态调度。

三者的取舍一句话：**MPS 要并发、MIG 要隔离、时间片只图省事**。推理服务密集小任务用 MPS；多租户强隔离用 MIG；交互式/开发环境图省事才用时间片。MPS 有个安全坑要注意：所有客户端共享完整显存空间，一个进程 OOM 会带走整卡上所有进程，且默认要求同一 Unix 用户（现代驱动支持多用户 MPS，但无内存隔离）。

![fig11-gpu-share.png](https://developer.qcloudimg.com/http-save/yehe-11479707/68a624ad091ee8cf4b8e322e4c31e64b.png)

## 六、容器：别让 OverlayFS 拖后腿

容器本身对 GPU 性能几乎无损耗——配好 NVIDIA Container Toolkit 后，容器内 GPU 性能和裸机差异 <2%（MLPerf Inference v5.0 就是用容器编排环境跑的）。真正的坑在别处：

**① 数据别放镜像里，用 bind mount。** 容器的可写层是 OverlayFS + 写时复制，大文件读写（数据集、checkpoint）走可写层会有额外开销。正确姿势是把数据集目录从宿主机挂进来，只读挂载，读写直接走宿主机文件系统，拿到 NVMe 的全部性能：

```bash
docker run -v /data/dataset:/mnt/dataset:ro -v /data/ckpt:/mnt/ckpt ...
```

**② 镜像瘦身，启动提速。** 镜像越大，拉取越慢。训练任务一次跑几小时几周，启动慢几分钟可忽略；但如果是短作业多的调度环境，镜像大小直接决定排队成本。别把构建工具和临时文件打进镜像。

**③ 多节点训练用 hostNetwork。** K8s 默认的 overlay 网络 + NAT 会给 MPI/集合通信引入额外开销和端口映射麻烦。性能敏感的 GPU 作业设 `hostNetwork: true`，让容器直接用宿主机网络栈访问 InfiniBand，零转换零防火墙层（来源：*AI Systems Performance Engineering* 第 3 章 3.6.4 节）。

**④ CUDA 与驱动版本匹配。** 容器里装的是 CUDA 运行时，驱动在宿主机。CUDA 13.x 需要宿主驱动 R580+，CUDA 12.x 需要 R525+。驱动比 CUDA 要求的版本旧，CUDA 初始化直接失败。用 NGC 官方基础镜像（nvcr.io/nvidia/pytorch 之类）最省心，镜像标注了所需的最低驱动。

## 七、调优顺序：先算账，再动手

单机调优旋钮很多，但别全上，先算账：

1. **先做基线**：跑同一 benchmark，记下 GPU 利用率、吞吐、kernel 间隙（Nsight Systems 看 timeline，gap 一目了然）。
2. **零成本项先上**：NUMA 绑定 + pin_memory + swappiness=0 + 持久化模式——全是配置，没代码风险，通常能回收 10%+ 的利用率。
3. **再看数据路径**：数据集是不是走 bind mount？是不是还在镜像里？这一步经常被忽略。
4. **最后才考虑分卡**：多租户场景才需要 MPS/MIG 决策，单机单任务别折腾。
5. **验证再验收**：改完一项重跑一次基线，别一口气全改——出了问题都不知道是哪个旋钮引入的。

下次再遇到 GPU 利用率掉，先别急着抄别人的算法 trick，把主机侧这四个旋钮拧完再说。算法是"锅"的概率，远低于 CPU/内存/存储是"锅"的概率。


## 参考资料

- Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media（第 3 章：GPU 环境的 OS/Docker/K8s 调优）
- NVIDIA：《Automating GPU Kernel Generation with DeepSeek-R1 and Inference Time Scaling》
- NVIDIA MLPerf Inference v5.0 提交说明（容器编排环境性能）


先讲个真实的烦恼。你组里一个训练任务，跑了三天，nvidia-smi 一查：GPU 利用率 60%，还一跳一跳的，像打摆子。算法同学说"代码没问题"，网络同学说"带宽没跑满"，存储同学说"I/O 也没瓶颈"。

AI Infra 系列 · 第四章 训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账

这一篇把镜头拉回一台机器内部：为什么 8 张卡里总有一张利用率上不去？为什么同样的代码，换个机器慢 20%？答案往往不在算法，而在 CPU 怎么给 GPU 喂数据。NUMA、CPU 绑定、内存固定、THP、GPU 持久化、MPS/MIG、容器挂载——七个旋钮，每个都能榨出几个点的吞吐。

运维开发工程师

人工智能

后端

开发工具

NUMA绑定、内存固定、持久化模式是提升GPU利用率的三板斧，纯配置即可回收10%+吞吐。训练开THP、推理关THP，杜绝swap。MPS保并发、MIG保隔离、时间片仅图省事。容器数据走bind mount并启用hostNetwork，注意CUDA驱动匹配。调优按基线、零成本项、数据路径、分卡顺序推进。

文件系统

代码解释

容器编排

内存管理

数据中心

服务器

防火墙

DeepSeek

Docker

Python

Kernel

容器

Linux

Unix

4核4G3M云服务器 新用户低至38元/年！

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Infra 系列 · 第四章 训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第四章训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账

AI Infra 系列 · 第四章训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第四章 训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账

AI Infra 系列 · 第四章 训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第四章训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账

AI Infra 系列 · 第四章训练与调度（上）： 8 张卡 7 张闲？单机调优才是你欠下的第一笔账