Jimmy Song – GPU 软件栈与容器化

NVIDIA 软件栈：一个应用，多份契约

Jimmy Song — Mon, 31 Aug 2026 02:47:53 +0000

GPU 容器不会直接和硅片对话。任何一条边界上的失配，都可能表现为“莫名其妙的应用错误”。

图 1: NVIDIA 软件栈的分层契约

应用或框架调用库；库调用 CUDA；CUDA 运行时与驱动交互；容器运行时注入设备访问；内核驱动与硬件对话。排查 GPU 问题的第一课，是先判断故障发生在哪一层，自底向上检查往往最快。

逐层拆解

层	职责	故障信号
固件 / GPU	供电、内存、引擎、链路、RAS	硬件错误、复位、链路故障
内核驱动	特权设备访问与内存管理	模块失配、Xid、设备消失
Container Toolkit	向容器注入设备与库	容器里没有 GPU
CUDA 运行时	kernel 启动、流、内存、事件、驱动 API	符号缺失或运行时不匹配
cuBLAS / cuDNN	优化的线性代数与神经网络原语	不支持的路径或糟糕的 kernel 选择
NCCL	集合与对等通信	挂起、超时、扩展缓慢
TensorRT / TRT-LLM	优化的推理图与引擎执行	构建失配或不支持的算子
DCGM	遥测、诊断、健康、exporter 集成	指标或健康状态缺失

表 1: NVIDIA 软件栈逐层职责与故障信号

每一层的故障签名都不同：Xid 错误指向驱动与硬件层（见指标语义），“容器里没有 GPU”指向工具链层（见下一章），符号缺失指向运行时版本失配，扩展缓慢则多半是 NCCL 与互连问题（见互连与集合通信）。

驱动与运行时：兼容性的方向

主机驱动是特权的，与内核和 GPU 绑定。容器通常携带用户态运行时部件和应用库。驱动必须支持运行时与 GPU 架构；基于较新 CUDA 版本构建的镜像，可能在驱动较旧的节点上失败。更新的驱动并不保证所有应用都兼容，但过旧的驱动是常见的头号嫌疑。

工程纪律

锁定节点驱动、基础镜像、框架和 GPU Operator 版本，建立兼容性矩阵。在改动整个机群之前，用诊断镜像加一个代表性工作负载测试升级。

CUDA 库与优化路径

cuBLAS 加速稠密线性代数；cuDNN 提供优化的深度学习原语；NCCL 处理分布式通信；TensorRT 构建优化的推理引擎；TensorRT-LLM 把这些思想专门化用于语言模型服务；DCGM 及其 exporter 暴露健康与遥测；CUDA Toolkit 提供把各层粘合在一起的编译器、运行时、工具和编程接口。

应用很少直接使用所有这些库，但性能与可靠性正是从它们的组合中涌现，这也是为什么版本矩阵管理（详见安全、可靠性与生命周期）是平台团队的核心职责。

总结

把 GPU 栈看成一张契约图，“哪层 owns 这个故障”就有了判定依据。本章的分层表也是全书排障章节的索引：固件与驱动问题走 Xid 路径，工具链问题走 Toolkit 路径，性能问题走互连与调度路径。下一章深入其中的 Container Toolkit 层。

Kubernetes 的出身：从 Borg 到 GPU 事实编排器

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

Kubernetes 原本为无状态微服务而生；它成为 GPU 编排器，不是因为设计初衷，而是因为它无处不在、可扩展，而推理时代的所有需求它都已经具备。

Kubernetes 之前的世界

在 Kubernetes 出现之前，部署分布式应用意味着两个痛苦选择之一：用手工部署脚本管理裸机服务器，或用 Chef、Puppet、Ansible 之类的工具管理虚拟机。扩容意味着手工开通新虚机；故障转移依赖自定义脚本；环境一致性是神话，生产环境“在我机器上是好的”问题就是日常。

2013 年，Solomon Hykes 在 PyCon 上做了五分钟的闪电演讲，改变了一切：他演示了一个即将发布的工具 Docker。Docker 用干净的 API 包装了底层命名空间与 cgroups 的复杂性，把 Linux 容器带入主流。突然之间，你可以把应用及其全部依赖打包成一个可移植、可复现的镜像。容器革命开始了。

但容器带来了新问题：现在你有几百个容器分布在几十台主机上，全都需要被启动、停止、扩缩、更新和健康检查。编排（orchestration）成了必需品。

诞生于 Google 的 Borg

Google 从 2003 年起就在内部以一套叫 Borg 的集群管理系统大规模运行容器化工作负载。Docker 时代到来时，Google 工程师 Joe Beda、Brendan Burns 和 Craig McLuckie 看到了把 Borg 的经验带进开源世界的机会。这个内部项目的代号是 Project 7，致敬《星际迷航》中脱离了 Borg 集合的角色“九之七”（Seven of Nine），Kubernetes 标志上的七根辐条正源于此。

时间	里程碑	发生了什么
2014 年 6 月	首次 GitHub 提交	Google 在 DockerCon 上发布 Kubernetes，Eric Brewer 的主题演讲把 K8s 带给世界
2015 年 7 月	K8s v1.0：生产就绪	Kubernetes 1.0 发布。Google 联合 Linux 基金会成立 CNCF，K8s 作为首个种子项目捐出
2015–16	CNCF 与生态成长	Microsoft、Red Hat、IBM 加入；面向有状态应用的 StatefulSets；包管理器 Helm 诞生
2017	K8s 1.8：RBAC + 设备插件	基于角色的访问控制 GA；关键：设备插件框架以 1.8 alpha 引入，GPU 从此可以暴露给 K8s
2018	K8s 1.10：设备插件稳定	设备插件框架进入 beta；CRI-O 运行时；CoreDNS 成为默认；GKE/EKS/AKS 上线
2019–20	K8s 成为中坚	91% 的组织在运行容器；K8s 用于微服务、数据库、ML 工作负载、网络功能
2020–22	AI 工作负载规模化	GPT-3、BERT、Stable Diffusion 全部在 GPU 集群上训练；GPU Operator v1.0 发布
2022	ChatGPT 改变一切	GPU 需求爆炸，每个组织都需要 GPU 基础设施，而 Kubernetes 正是它们的运行方式
2024–26	DRA 时代开启	K8s 1.32（DRA beta）、1.34（DRA GA）；NVIDIA 向 CNCF 捐赠 DRA Driver 并成为白金会员

表 1: Kubernetes 与 GPU 编排的关键时间线

注意 2017 年这一行：设备插件框架（详见设备资源抽象）与 GPU 的结缘从 K8s 1.8 就开始了，此后近十年 GPU 接入 Kubernetes 的方式都围绕它展开，直到 DRA 登场。

为什么 Kubernetes 成了 GPU 编排器

下面这个关键洞察解释了为什么原本为无状态微服务构建的 Kubernetes，成了 GPU 工作负载的事实编排器：

无处不在： 到 2020 年，Kubernetes 已经运行在每个主要数据中心里。团队熟悉它、工具链存在、云厂商提供托管版本。另建一套 GPU 调度系统，意味着重建 Kubernetes 已有的一切：网络、RBAC、服务发现、存储集成。
可扩展性： K8s 生来为扩展而设计：自定义资源定义（CRD）、准入 Webhook、设备插件、Operator 模式。NVIDIA 无需 fork Kubernetes 就能接入 GPU 支持。
AI 接理爆炸： 训练一个模型与大规模服务它有不同的需求。推理需要弹性伸缩、多租户、负载均衡、滚动更新，这些 Kubernetes 都已具备。在 Kubernetes 之外做推理，意味着把这一切重建一遍。

历史的必然路径

ChatGPT 上线的那一刻，每一家大公司都想要 GPU 基础设施。它们已经有了 Kubernetes。阻力最小的路径是：扩展 Kubernetes 以支持 GPU。NVIDIA 构建的正是这个。

总结

Kubernetes 的胜利不是功能清单的胜利，而是生态位的选择：它在正确的时间（容器标准化）、以正确的架构（可扩展控制面）占据了编排层，使 GPU 支持可以被“插入”而非“重造”。理解这段历史，就能理解为什么后续章节中的设备插件、GPU Operator 与 DRA 都以“扩展 Kubernetes”而非“绕开 Kubernetes”的方式演化。

容器与 GPU 的问题：为什么不能开箱即用

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

GPU 无法在容器里“开箱即用”不是缺陷，而是架构使然：容器是内核特性的组合，而 GPU 恰恰不是内核原生资源。

容器究竟如何工作

容器不是轻量级虚拟机。它是一组 Linux 内核特性的集合（主要是命名空间 namespace 与 cgroups，前者负责进程、网络、文件系统、用户隔离，后者负责资源记账与限制），让一个进程相信自己独占整台机器。

当你运行 docker run nginx 时，容器运行时（Docker → containerd → runc）为进程创建隔离的命名空间、挂载容器镜像文件系统、配置网络，并对 CPU 和内存施加 cgroup 限制。这一切都是纯 Linux 内核，除了内核本来就管理的东西，没有任何硬件驱动的参与。

这正是容器启动快、重量轻的原因：它们共享主机内核，没有虚拟机管理器开销。但这个设计在加入 GPU 时制造了一个棘手问题。

根本问题：GPU 不是内核原生资源

与 CPU 核和系统内存不同（Linux 内核通过进程调度和虚拟内存系统原生管理它们），GPU 由 GPU 厂商加载的专有内核模块管理。对 NVIDIA 来说，就是 nvidia.ko 内核模块及其上的用户态驱动栈。

GPU 通过一组设备文件向用户态暴露自己。在只有一块 NVIDIA GPU 的节点上，你会发现：

# Device files created by the NVIDIA kernel module
/dev/nvidia0 # GPU 本体
/dev/nvidiactl # GPU 控制设备（所有 GPU 共享）
/dev/nvidia-uvm # 统一虚拟内存（UVM）驱动
/dev/nvidia-uvm-tools # UVM 调试工具
/dev/nvidia-modeset # 显示模式设置（可选）

# 同时：必须存在于容器中的 NVIDIA 库
/usr/lib/x86_64-linux-gnu/libcuda.so.1 # CUDA 运行时
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 # NVML（管理接口）
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so # GL 加速

问题就在这里：一个标准容器得不到其中任何一项。容器文件系统与主机隔离，设备文件在容器里不存在，NVIDIA 驱动库也没有被挂载。即使你在容器镜像里装了 CUDA，运行时它也无处可谈。

天真的失败

不做 GPU 配置直接运行 docker run my-cuda-app，结果是：CUDA error: no kernel image is available for execution on the device，或者干脆 nvidia-smi: command not found，更糟的是：进程正常启动但悄悄回落到 CPU。没有报错，只是推理慢了 100 倍。

早期尝试：nvidia-docker v1（2016）

2016 年 NVIDIA 发布 DGX-1（世界上第一台“盒子里的 AI 超算”），随机器附带了 NVIDIA Docker，一个改造过的 Docker CLI 包装器。nvidia-docker v1 的做法是维护一个单独的 Docker 卷插件，把 GPU 库和设备文件打包进去，启动时再挂载到容器里。

这能用，但问题很深：

它要求一条单独的 nvidia-docker 命令，破坏了标准 Docker 工作流和 CI/CD 流水线
卷里和主机上的驱动版本必须完全一致，维护起来是噩梦
它无法与 Kubernetes、Docker Swarm 或任何绕过 Docker CLI 的编排器配合
每次 nvidia-docker 升级都要重建卷插件，每逢内核或驱动更新都极其脆弱

AI 社区在快速膨胀，这个 hack 走不远。

nvidia-docker v2：OCI 钩子方案（2017）

2017 年，NVIDIA 推倒重来。nvidia-docker v2 不再包装 Docker CLI，而是引入了自定义 OCI 运行时的概念，在最底层钩进容器创建过程本身。

关键洞察是：开放容器倡议（Open Container Initiative，OCI）运行时规范定义了容器如何被创建。参考实现 runc 遵循该规范。规范允许预启动钩子（pre-start hook）：在容器创建之后、启动之前运行的可执行文件。NVIDIA 正是利用这个钩子点把 GPU 访问注入容器。

架构转变

NVIDIA 没有修改 Docker，而是在 runc 外面包了一层薄壳，把 GPU 资源作为预启动钩子注入。Docker 调用这个包装器（nvidia-container-runtime）的方式与调用 runc 完全一样。Docker 无需任何改动；containerd、CRI-O 及任何兼容 OCI 的运行时同理。

这一钩子机制后来被标准化为 CDI（容器设备接口），并成为 DRA 路径的注入基础，从 v2 到 CDI 再到 DRA 一脉相承。

总结

容器与 GPU 的缝隙本质上是两套世界的接口失配：容器世界只认识内核原生资源，GPU 世界由厂商内核模块和用户态库构成。nvidia-docker v2 用 OCI 预启动钩子在进程创建的最底层缝合了这道缝，其思想延续至今。下一章将拆解完成这件事的完整工具链。

NVIDIA Container Toolkit：四个组件与 CDI 深度解析

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

NVIDIA Container Toolkit（NCT）是其他一切的地基：设备插件宣告的资源、GPU Operator 部署的组件，最终都靠它把 GPU 真正放进容器。

什么是 NVIDIA Container Toolkit

NVIDIA Container Toolkit（NCT）是一组软件组件的集合，让 NVIDIA GPU 在所有主流容器运行时（Docker、containerd、CRI-O 和 Podman）中都可用。它由四个各司其职的组件组成。理解每一个都至关重要，因为 GPU 容器出问题的时候（它们一定会出问题），你需要确切知道故障发生在哪一层。

组件一：libnvidia-container

libnvidia-container 是最底层的组件：一个 C 库和 CLI 工具，执行向容器注入 GPU 的实际动作。被调用时，它做以下事情：

读取容器的 cgroup 和进程命名空间
通过 NVML（NVIDIA 管理库）发现主机上的全部 NVIDIA GPU 设备
把所需的 GPU 设备文件（/dev/nvidia*）绑定挂载进容器的 /dev 命名空间
把主机上的 NVIDIA 驱动用户态库（libcuda.so、libnvidia-ml.so 等）绑定挂载进容器的库路径
注入必要的环境变量（如 NVIDIA_VISIBLE_DEVICES）
可选地配置统一虚拟内存（UVM）与管理文件

为什么挂载主机库而不是打包进镜像

CUDA 用户态库必须与内核驱动版本精确匹配。如果把库烧进镜像，主机上每次驱动更新都会弄坏所有容器。运行时从主机挂载，库就永远与正在运行的驱动匹配，无需重建镜像。

# nvidia-container-cli（libnvidia-container 的 CLI 包装，很少直接调用）
nvidia-container-cli --load-kmods configure \
 --ldconfig=@/sbin/ldconfig \
 --require=cuda>=12.0 \
 --pid=<PID> \
 --device=all

# 查看工具包可见的 GPU
nvidia-container-cli info
nvidia-container-cli list

组件二：NVIDIA Container Runtime Hook

nvidia-container-runtime-hook（同样以 nvidia-container-toolkit 包发布）是 OCI 预启动钩子可执行文件，是 OCI 规范与 libnvidia-container 之间的粘合剂。执行流程：

runc 创建容器（命名空间、cgroups、文件系统），但尚未启动进程
runc 读取 OCI 规范的 hooks.prestart 数组，找到 NVIDIA 钩子
runc 携带容器的 config.json 和进程 ID 执行钩子
钩子从容器环境读取 NVIDIA_VISIBLE_DEVICES 和 NVIDIA_DRIVER_CAPABILITIES
钩子调用 nvidia-container-cli configure，后者执行 libnvidia-container 注入 GPU 设备与库
钩子退出，runc 启动容器进程，容器现在拥有 GPU 访问

# 控制 GPU 可见性与能力的环境变量
NVIDIA_VISIBLE_DEVICES=all # 所有 GPU
NVIDIA_VISIBLE_DEVICES=0,1 # 仅 GPU 0 和 1
NVIDIA_VISIBLE_DEVICES=none # 无 GPU（纯 CPU 容器）

NVIDIA_DRIVER_CAPABILITIES=compute,utility # 最常用
NVIDIA_DRIVER_CAPABILITIES=all # 全部（含显示）
NVIDIA_DRIVER_CAPABILITIES=compute,compat32 # 32 位 CUDA 兼容

NVIDIA_REQUIRE_CUDA=cuda>=12.0 # 驱动 CUDA < 12.0 则失败

设备插件（见设备资源抽象）在 Allocate 阶段设置的正是 NVIDIA_VISIBLE_DEVICES，两条链路在这里汇合。

组件三：NVIDIA Container Runtime

nvidia-container-runtime 是一个兼容 OCI 的运行时包装器，位于 Docker/containerd 与真正的 runc 之间，唯一职责是在把 OCI 规范传给 runc 之前注入 NVIDIA 钩子。自 2019 年起它实现为一层薄垫片：

# 配置 nvidia-container-runtime 后 Docker 的执行流：

Docker（守护进程）
→ 调用 nvidia-container-runtime（而非 runc）
→ nvidia-container-runtime 读取 OCI config.json
→ 注入预启动钩子：nvidia-container-runtime-hook
→ 把修改后的 config.json 交给 runc
→ runc 创建容器
→ runc 执行预启动钩子（nvidia-container-runtime-hook）
→ 钩子调用 libnvidia-container → GPU 设备注入完成
→ runc 启动容器进程
→ GPU 可用！

对 CRI-O（用于 OpenShift 和许多生产 K8s 集群）来说，这个包装器并非必需，CRI-O 原生支持 OCI 钩子，可直接调用钩子。

组件四：nvidia-ctk CLI

nvidia-ctk 是工具包的管理接口，负责容器运行时配置、CDI 规范生成和诊断：

# 配置 containerd 使用 nvidia-container-runtime
nvidia-ctk runtime configure --runtime=containerd

# 配置 Docker / CRI-O
nvidia-ctk runtime configure --runtime=docker
nvidia-ctk runtime configure --runtime=crio

# 生成 CDI 规范（现代方式）
nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

# 列出 CDI 设备 / 验证安装
nvidia-ctk cdi list
nvidia-ctk --version

CDI：容器设备接口（现代路径）

OCI 钩子方案能用，但有个根本缺陷：每个容器运行时都必须知道 NVIDIA 的钩子，在厂商中立的规范里塞进了一个厂商专属的钩子。2021 年，NVIDIA、Red Hat 等共同创建了容器设备接口（Container Device Interface，CDI）标准，现由 CNCF 托管。

CDI 是一份声明式 YAML 规范，描述让一个设备在容器中可用所需的一切：设备节点、库挂载、环境变量和钩子。规范生成一次、存放在 /etc/cdi/，任何支持 CDI 的运行时读取即可注入设备，无需任何 NVIDIA 专属代码：

# CDI 设备命名
nvidia.com/gpu=all # 所有 GPU
nvidia.com/gpu=0 # 仅 GPU 0
nvidia.com/mig-1g.10gb=0:0 # MIG 实例

# 在 Docker 中使用 CDI（需要 Docker 25+）
docker run --device=nvidia.com/gpu=0 nvidia/cuda:12.6.0-base nvidia-smi

CDI 与 DRA 的关系

DRA 路径（见数据平面·DRA）的设备注入同样依赖 CDI 兼容的运行时。CDI 把“注入”标准化，DRA 把“声明与调度”标准化，两者是上下游关系，不是竞争关系。

完整安装实践

在 GPU 节点上的四步（Kubernetes 场景通常由 GPU Operator 代劳，但手工走一遍能建立完整心智模型）：

# 第 1 步：在主机上安装 NVIDIA 驱动（Ubuntu 22.04/24.04）
sudo apt-get install -y linux-headers-$(uname -r)
sudo apt-get install -y nvidia-driver-570
sudo reboot
# 验证：nvidia-smi 应显示 Driver Version: 570.x.x, CUDA Version: 13.x

# 第 2 步：安装 NVIDIA Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
 | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
 | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
 | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit

# 第 3 步：配置容器运行时（containerd 为 Kubernetes 默认）
sudo nvidia-ctk runtime configure --runtime=containerd
sudo systemctl restart containerd

# 第 4 步：验证
docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi
# 应打印容器内的 nvidia-smi 输出

关键 NVIDIA 基础镜像选型

镜像标签模式	包含内容	适用场景
`nvcr.io/nvidia/cuda:<ver>-base-<os>`	仅 CUDA 运行时（libcudart），无开发工具	最小推理容器
`nvcr.io/nvidia/cuda:<ver>-runtime-<os>`	基础版 + cuBLAS、cuDNN 运行时库	运行预编译的 CUDA 应用
`nvcr.io/nvidia/cuda:<ver>-devel-<os>`	完整工具链：nvcc、cuDNN、全部头文件	从源码构建 CUDA 应用
`nvcr.io/nvidia/pytorch:<ver>-py3`	完整 PyTorch + CUDA + cuDNN + NCCL	开箱即用的深度学习训练/推理
`nvcr.io/nvidia/tensorflow:<ver>-tf2-py3`	TF2 + CUDA + cuDNN 栈	TensorFlow 工作负载
`nvcr.io/nvidia/tritonserver:<ver>`	Triton 推理服务器二进制	生产模型服务

表 1: NVIDIA 官方基础镜像速查

选型原则与显存管理的教训一致：devel 镜像体积数倍于 base，运行时镜像只装运行时库；除非你要编译，否则不要用 devel。

总结

NVIDIA Container Toolkit 的四个组件构成一条注入链：nvidia-container-runtime 把钩子写进 OCI 规范，runc 在容器启动前执行钩子，钩子调用 libnvidia-container 完成设备与库的绑定挂载，nvidia-ctk 负责配置与诊断。CDI 把这套厂商机制标准化，成为现代运行时与 DRA 的共同底座。排障时按“容器里有没有 /dev/nvidia* → 有没有 NVIDIA_VISIBLE_DEVICES → 运行时配置对不对”的顺序自底向上检查，绝大多数“容器里看不见 GPU”的问题都能定位。