GPU容器化与AI训练平台实践：从Kubernetes调度到资源治理

1. 从裸机乱局到容器化：我们为什么非要重建一套训练平台

我所在的团队负责为整个公司的算法部门提供 GPU 算力支撑。两年前的状态，说实话，和很多公司一样：几台 8 卡的 GPU 服务器散落在不同机柜，算法同学申请到一台机器后，从装驱动、装 CUDA、配 Python 虚拟环境开始，再一个个 pip install 依赖，少则半天、多则一周才能把训练作业跑起来。硬件资源是有的，但利用率和交付效率都很低。

真正让我下定决心做 GPU 容器化与 AI 训练平台的，是三件事同时发生。

第一件事是环境冲突。一个算法工程师在自己机器上调试好的 PyTorch 版本，放到另一台机器上跑不起来，因为隔壁项目组的同学把那台机器的 CUDA 软链换成了另一个版本。这种事情在多人共用 GPU 服务器的场景下几乎每周都在发生。第二件事是资源碎片化。每张卡上零零散散跑着几个任务，A 同学占了两张卡跑一个小实验，B 同学占了三张卡但实际只用了一半显存，剩下的大块显存就这么空着。第三件事是故障恢复太慢。有一次某张卡上的驱动崩了，整个服务器上所有项目的训练进程全部挂掉，由于没有隔离手段，连排查是谁的进程导致的内核模块异常都要花半天。

当时我们评估过几条路：继续用裸机静态分配，买新的物理服务器，或者上虚拟机。裸机和物理机显然解决不了环境隔离和动态调度的问题。虚拟机方案在 CPU 场景成熟，但 GPU 透传的虚拟机在 vGPU 切分、迁移和驱动兼容上都有不少历史包袱，而且虚拟化层本身有性能损耗。对训练这种动辄几百上千个 epoch 迭代的场景来说，性能损耗不能接受。

所以方向其实很明确：容器化 + Kubernetes 调度。容器天然解决了环境一致性问题——算法同学只需要交付一份打包好的镜像，里面是什么版本、什么依赖，到哪都能原样复现。调度层则把 GPU 资源从"物理服务器"维度拆成"可调度的资源池"维度，任何一台机器上的空闲算力都能被动态分配给新的训练任务。这就是我们自研 AI 训练平台的起点，也是"探索与实践"这个标题的来源。

这里我不展开讲平台架构图了，很多图网上都能搜到。我重点讲的是落地过程中真正花过时间、踩过坑的部分：底层 GPU 容器化的原理、共享调度方案选型、镜像与存储治理、故障排查和可观测性建设。这些内容不是从文档里抄来的，是实实在在熬过几个通宵换来的经验。

提示：如果你所在团队还没到规模化训练的阶段，可以先不用上完整平台，Kubernetes + NVIDIA 官方 Device Plugin 已经能覆盖大部分需求。平台化建设的核心驱动力是"多团队、多项目、资源需要统一治理"，而不是单纯的"把任务跑起来"。

2. GPU 容器化的技术底座：Device Plugin 与 container runtime 的协作机制

很多人第一次接触 GPU 容器化时，最大的困惑是：这不就是在 Docker 里装个 nvidia-smi 吗？我在早期做概念验证时也走过弯路——直接在基础镜像里 COPY 了一份宿主机上的 nvidia-smi 二进制和 CUDA 库，结果在另一台驱动版本不同的机器上根本起不来。这个误区值得先说清楚。

2.1 为什么容器里不需要装驱动，但必须装 CUDA 用户态库

GPU 驱动分为两部分：内核态模块（nvidia.ko 等）和用户态库（libcuda.so、libnvidia-ml.so 等）。Docker 容器共享宿主机内核，容器里没有权限加载内核模块，所以内核态驱动永远只能装在宿主机上。容器里跑的 PyTorch、TensorFlow 通过用户态库的 API 去调用驱动，最终由内核态模块操作 GPU 硬件。

所以正确的做法是：宿主机装好驱动，容器镜像里装与宿主机驱动兼容的 CUDA 用户态库（包括 CUDA runtime、cuDNN、TensorRT 等）。nvidia-container-toolkit 会在容器启动时通过 prestart hook 自动把宿主机的 driver 库目录（如 /usr/lib/x86_64-linux-gnu/libcuda.so.1）挂载进容器，同时挂载 /dev/nvidia0 等设备文件。

NVIDIA_VISIBLE_DEVICES 这个环境变量是整个流程的开关，它可以取值：all（所有 GPU 可见）、GPU- （指定设备）、0,1,2（设备索引）。nvidia-container-toolkit 根据这个变量的值决定将哪些设备告诉容器里的 CUDA 库。

2.2 Device Plugin 到底做了什么：从"机器上有卡"到"K8s 里有资源"

Kubernetes 原生不认识 GPU 这类扩展资源。要让 Pod 能申请 nvidia.com/gpu，必须通过 Device Plugin 机制打通。这个流程分三步：

1. Device Plugin 以 DaemonSet 形式跑在每个 GPU 节点上，启动后向 kubelet 注册自己的 Unix Socket（默认路径 /var/lib/kubelet/device-plugins/nvidia.sock），并上报本机 GPU 数量和健康状态。
2. 用户创建 Pod 时声明 nvidia.com/gpu: 1，调度器根据每个节点的可分配资源数决定把 Pod 放到哪个节点上。
3. 节点上的 kubelet 收到 Pod 绑定信息后，向 Device Plugin 发起 Allocate 请求，Device Plugin 返回环境变量、设备文件、挂载列表，kubelet 组装成最终容器配置交给容器运行时执行。

这里有个关键细节：Device Plugin 上报的资源数量默认是整数（几个 GPU），它并不知道 GPU 还能被切分成更小的单位。后面讲共享调度时你会看到，我们最终放弃了这个默认机制，自己实现了一套能在"物理 GPU 之下"继续划分资源的方案。

2.3 镜像里 CUDA 版本与宿主机驱动版本的兼容规则

这是整个 GPU 容器化里最容易踩、也最影响体验的坑。

CUDA 用户态库可以向后兼容：容器里的 CUDA 11.8 程序，在宿主机驱动版本支持的 CUDA 12.x 上通常能跑，因为运行时只会用到 libcuda.so 中稳定的 API 接口。反过来则不允许，比如镜像里是 CUDA 12.1，宿主机驱动只支持到 CUDA 11.4，那么容器启动时大概率报 libcuda.so.1: cannot open shared object file 或干脆 nvidia-smi 里看不到卡。

所以我们做平台时发布了一套严格的兼容矩阵：每个 CANN/PyTorch/TensorFlow 基础镜像都会标注与宿主机驱动的最低版本要求。驱动版本低于要求的节点，不允许调度该系统镜像的任务。这一步看起来简单，但有效避免了大量"我的代码在镜像里跑不起来"的排查浪费。

2.4 容器内 GPU 隔离为什么不能像 CPU 内存那样做"限流"

日常部署微服务时，给 CPU 容器设个 CPU limits、内存限制是常态。但 GPU 是加速器，它的算力和显存不通过 Linux cgroup 直接控制。容器启动后，如果代码里 torch.cuda.set_device(0)，而容器里只挂了 /dev/nvidia1，它访问的还是那一整张物理卡的显存。

这也是一开始我们只能整卡分配的根本原因——平台层面没有能力限制某个容器最多只能用 4GB 显存、最多用 50% 算力。NVIDIA 官方虽然提供了 MIG（Multi-Instance GPU）能力，但 MIG 需要 A100/A800 以上型号且是静态切分。对存量的大批 2080Ti、3090 机器来说，需要一套更灵活的方案。

3. 共享调度选型：从整卡独占走向显存与算力的细粒度分配

GPU 容器化跑通之后，平台的第一个版本只能做"整卡分配"：一张物理卡只能属于一个 Pod。很快我们就发现这个模式不可能持久——算法同学跑个小 batch 的调试任务，也要独占一张 3090，平台的 GPU 总数再多也经不住这么消耗。

3.1 原生 K8s 调度 GPU 的局限：为什么 requests 和 limits 必须相等

Kubernetes 调度 GPU 时，一个 Pod 声明 nvidia.com/gpu: 1，调度器就认为它占用了节点上 1 个单位的 GPU 资源。但显存和算力都是硬约束，没法像 CPU 那样做压缩式共享（CPU 的 requests 和 limits 可以不同，超卖时靠 cgroup 限流）。GPU 如果打了多个容器，任何一个容器占满显存，其他容器直接 OOM 或者触发驱动重置。

所以原生 K8s 里 nvidia.com/gpu 的 requests 必须等于 limits，且只能是整数。这决定了原生方案的上限就是"物理卡数"，利用率天花板就是所有卡都被分配出去。如果一张卡上平均跑 1.5 个任务可以满载，但只能喂给 1 个任务，剩下 0.5 的算力和显存就浪费了。

3.2 我们最后选的路：将 GPU 抽象为"算力配额 + 显存上限"

经过一轮调研，我们排除了自研 cuda-sim、改驱动这种高风险路子。可行的方案有三类：MIG 静态切分、显存虚拟化（通过拦截 CUDA 调用限制显存）、时间片抢占。最终我们采用了折中方案：保留"一个容器对应一个物理 GPU 内的逻辑切分"，支持将一张物理卡切成多个逻辑设备，每个逻辑设备有独立的显存上限和算力比例。

具体协议层是这样抽象的：每个训练任务声明要多少毫卡（比如 500m 代表 50% 算力）和多少显存（比如 2000Mi）。调度器负责把任务绑定到某个空闲逻辑设备上，逻辑设备由一套 GPU 池管理服务统一分配。容器运行时侧仍使用 nvidia-container-toolkit 挂载整张物理卡，但通过注入 CUDA 可见显存上限和环境变量，让任务在用户态只能看到被分配的那部分资源。

这里必须说清楚一个容易误解的点：这种"显存上限"是软限制而非硬隔离。代码如果尝试申请超过上限的显存，会被运行时拦截并返回 CUDA OOM 错误，但同一个物理卡上多个逻辑设备共享显存控制器和计算单元，极端情况下存在相互影响。所以我们在平台策略上做了妥协：调试类任务允许共享，大规模训练任务仍然独占整卡。

3.3 Volcano 批式调度在训练场景中的价值

训练任务是典型的批处理负载，不是常驻服务。它有三个特征：一次性跑很久、结束后释放全部资源、对排队时间有一定容忍度。

用原生 K8s Deployment/StatefulSet 管理训练任务会很别扭，因为任务终态不是"运行中"，而是"成功/失败"。我们调研后引入了 Volcano 作为批式调度器，它的队列、优先级、Gang Scheduling（顺便提一下，虽然单卡任务不需要 gang，但多卡并行训练任务需要）正好匹配训练场景。

实际配置中我们建立了三个队列：

队列配额是硬约束：TrainQueue 的算力配额耗尽后，新任务进入 Pending 状态，而不是抢占其他队列的资源。这让不同团队之间互不干扰，也让平台团队能给出明确的排队时长预期。

3.4 共享带来最直接的一个问题：性能蚕食

共享 GPU 的最大代价是性能不稳定。两个容器同时跑 matrix multiplication，哪怕显存上限控制住了，计算单元争抢也会让训练速度比独占时慢 20%~40%。这对"实验对照"型任务影响很大——昨天在同一张卡上跑 baseline 用时 10 小时，今天共享后变成 13 小时，算法同学会抱怨实验结果不可比。

我们的对策是提供三层资源规格，让用户自己在灵活性、成本和稳定性之间选：

1. GuaranteedSpec：整卡独占，可预期性能，适合正式训练和模型上线前校验。
2. PerformanceSpec：高配逻辑切分（如 3/4 算力 + 6/8 显存），适合日常迭代。
3. SharedSpec：低配额逻辑切分（如 1/4 算力 + 2/8 显存），适合调试、快速报错。

这套规格上线后，算法同学很少再来投诉"我的任务怎么变慢了"，因为他们在提交任务前就明确了性能预期。

4. 镜像治理与存储策略：训练任务跑起来之前最容易被忽略的隐形地基

容器化带来的一个副作用是：算法同学不再关心"我的代码跑在哪台机器上"，转而关心"我的镜像能不能找到、数据挂在哪个路径"。镜像和存储被忽视的话，平台体验会非常差。

4.1 从"每人一个完整镜像"到"基础镜像 + 项目镜像"分层体系

平台刚开放时，每个算法同学习惯自己做一个完整的镜像，里面从 CUDA 到 Python 依赖全部打进去，有些镜像甚至 40GB。我们统计过，当时平台上有 300 多个不同的镜像，很多只是某个库的小版本差异。镜像仓库被塞得满满当当，拉取时间经常超过 20 分钟，磁盘碎片严重。

我们做了一次系统性的镜像治理。规则其实朴素：

• 基础镜像按 CUDA 版本 + 深度学习框架版本组合，收敛到 8 个左右，由平台团队维护，每周自动重建并扫描安全漏洞。
• 项目镜像基于基础镜像做增量，业务侧只负责装自己项目的 Python 包。
• 禁止在镜像内保存训练数据和模型权重，那些必须走外部存储挂载。

分层之后，镜像大小平均降到 8GB 以下，拉取时间大幅缩短。这里有个小技巧：镜像仓库搭建一套容器镜像加速缓存，把每个节点上已经存在的镜像层缓存起来，相同的基础镜像只要被拉过一次，后续任务秒级启动。

4.2 训练数据与 Checkpoint 的存储设计取舍

训练数据分两类：一类是小体量的配置文件、词典，适合打进镜像或者存对象存储；另一类是动辄几百 GB 的图像、音频、文本语料，必须放在分布式存储中。

我们最初直接用了 NFS 挂载到所有 GPU 节点，但很快发现两个问题：NFS 文件的元数据操作（列出目录、查找文件）在数据量大了之后极其缓慢；多节点同时读同一个文件时，NFS 吞吐会撞到瓶颈。后来我们将高频读取的数据迁移到分布式文件系统，低频备份数据仍保留在 NFS 上，同时鼓励算法同学在做 DataLoader 时优先使用缓存机制减少跨文件系统的重复读取。

Checkpoint 的存储则完全是另一套策略：训练中每步的 ckpt 文件不宜直接写到分布式存储，因为 IO 延迟会影响训练节奏。我们的做法是任务本地目录落盘一份，同时在任务结束时把重要版本回传对象存储。对超长训练任务，支持周期性 checkpoint 直接回传，用于断点续跑。

4.3 任务生命周期管理：超时、重试、日志与清理

训练作业跑起来后，平台侧还需要一套完整的生命周期机制：

• 任务超时后自动终止，防止算法同学忘记关掉训练，白占资源。
• 任务失败后，根据退出码区分"可重试"（如基础设施抖动）和"不可重试"（如代码报错）。前者自动重启，后者直接把 stderr 日志推给用户。
• 每个任务分配独立日志目录，上报到日志平台，支持关键字检索和关注告警。

这些机制看着基础，但缺少任何一环，平台团队都会变成"人工运维"，每天被拉去手动清理僵尸任务、翻日志。

注意：GPU 任务的日志量通常非常大，尤其是调试阶段，每秒可能刷出几万行 tensorboard 信息。建议日志平台侧必须做采样或截断策略，避免磁盘被日志撑爆。我们最终给每个任务设置了单日日志上限，超出部分只保留最近 5000 行。

5. 线上踩坑实录：三起典型故障背后的完整排查链路

平台稳定运行到现在，中间出过不少故障。有些问题只在生产环境遇到，文档上根本不会写。我挑三个有代表性的，把排查思路完整记录下来，比直接给结论更有参考价值。

5.1 故障一：某任务占用了超出配额的内存，整卡训练任务被"打挂"

现象：A 项目的调试任务在 SharedSpec 上运行正常，B 项目某天开始跑一个正式的 DistributedQueue 训练任务，跑了不到两分钟，训练进程报 CUDA OOM 退出。

初步排查：B 任务申请的是整张 40GB 显存的卡，按理物理卡独占比 container 级别分配多，不会出现显存不足。

进一步看监控指标，发现 B 任务实际"吃到"的显存只有 20GB 就报错了。怀疑是共享模式残留的限制策略阿拉伯。我们逐个排查配置后发现问题出在逻辑设备分配上：调试任务占用的那个逻辑设备，其显存上限是从整卡显存中划分出来的，但设备池服务在回收调试任务时，没有把这块逻辑设备释放掉，导致 B 任务申请整卡时，设备池服务给它的实际可用显存被"存量逻辑设备"挤压，只能拿到 20GB。

修复方案：设备池服务在分配整卡独占任务时，必须先调用回收接口强制清理该物理卡上的所有逻辑设备，再进行分配。同时补充一致性检查，每 10 分钟巡检一次实际已分配显存与总显存是否对得上。

经验：共享调度系统里，凡是有"逻辑视图"和"物理视图"两层概念的地方，都必须有同步机制。分配、回收、状态变更，任何一个环节失败都要能回滚。

5.2 故障二：GPU 状态被 nvidia-smi 判定为 unhealthy 后仍被继续调度

现象：平台某段时间偶发任务失败率上升，失败任务集中在同一个节点。查看节点日志发现该节点某张卡曾经报错 NV_ERR_GPU_LOST，之后 nvidia-smi 把这张卡标记为 unhealthy，但 Device Plugin 的健康检查没有及时剔除它，这张卡仍然被继续调度新任务，导致新任务一亮相就失败。

排查链路：先看 Device Plugin 的 health check 机制。官方实现是周期性运行 nvidia-smi，检查每张卡的 UUID 状态，unhealthy 的卡从上报列表中移除。但我们的实际日志显示，健康检查周期 60 秒，而任务调度在健康检查判定之前就发生了，存在时间窗。

修复方案：在平台侧增加"预分配前探活"机制，调度器把任务分配给某个逻辑设备后，先进行一次轻量级 CUDA 上下文初始化，失败则立刻回退到下一个可用设备。同时在 Device Plugin 侧降低健康检查周期到 10 秒，并加入驱动重置事件的日志聚合告警。

经验：GPU 的硬件故障不像 CPU 内核 panic 那么明显，更像"慢性病"。unhealthy 状态不代表立刻完全不工作，而是随时可能出问题。平台必须有前置探活机制才能在出问题之前拦截。

5.3 故障三：多节点分布式训练任务网络通信慢，NCCL 报 Ring 超时

现象：一个 4 节点 32 卡的分布式训练任务，前十分钟运行正常，之后逐步出现 NCCL 超时，最终任务卡死。

排查思路：NCCL 超时最常见的原因是拓扑不匹配——GPU 之间的实际通信走的是 PCIe 还是 NVLink，容器是否做了 CPU 绑核，节点间通信走的是哪个网卡。我们一层层看监控：带宽曲线显示跨机通信只有 2Gbps，明显没跑满。

原因定位：容器网络使用默认的 bridge 模式，NCCL 走的是虚拟网桥和宿主机 NAT 转发，而不是直连物理网卡。对单机训练影响不大，但对跨机分布式训练，虚拟网络转发路径太长，吞吐急剧下降。

修复方案：在训练任务的 Pod 配置中显式选择支持 SR-IOV 的直通网络插件，让跨机通信直接走物理网卡；同时要求多卡任务在调度时尽量将同一批任务分配到同机架，最大化 NVLink 和机架内带宽利用率。

经验：分布式训练的性能瓶颈，很多时候不在 GPU 算力，而在数据通路。平台层面应该把网络拓扑信息（下挂的可用 NVLink、可用物理网卡）暴露给调度器，调度器才能做出合理的跨节点放置决策。

6. 可观测性建设：GPU 指标怎么采集，才算真正"看得见"

容器化之后，"看着 nvidia-smi 判断机器卡不卡"这种经验基本失效了。单机 nvidia-smi 看的是整卡状态，而容器任务看到的是逻辑设备状态，两者差距很大。可观测性建设是平台从"能用"到"好用"的分水岭。

6.1 DCGM 指标的采集维度与告警规则

NVIDIA 官方提供 DCGM（Data Center GPU Manager）用于采集 GPU 的细粒度指标，包括利用率、显存使用、温度、功耗、PCIe 吞吐、NVML 错误计数等。我们用 DCGM-Exporter 采集，存储到时序数据库中，再按逻辑设备维度聚合。这样既能看"整张卡负载"，也能看"某个逻辑设备负载"。

告警规则我们分了三级：

• 警告：显存使用率超 90% 持续 5 分钟。
• 严重：任务失败率超过 5%，或者 GPU 温度超过 85 度。
• 致命：驱动重置事件、NV_ERR_GPU_LOST、设备进入 unhealthy 状态。

告警不只是通知值班同学，还要自动触发动作。比如"任务失败率超过阈值"可以直接触发任务重启，不用等人工介入。

6.2 为什么不能用宿主机级别监控替代容器级别监控

宿主机级别的 GPU 监控只能告诉你这张卡被分配出去了多少，看不出来具体是哪个任务在消耗、消耗了多少逻辑配额。有一次一个任务偷偷在 SharedSpec 上反复分配显存，宿主机显存使用率飙升，但所有任务的配额看起来都正常。我们排查了半天才发现是某个任务的代码存在显存泄漏，garbage collector 跟不上，导致显存占用持续增长，宿主机的显存统计暴露了问题，而容器级别的统计因为配额限制没有记录到。

现在我们的监控体系是三层：宿主层（机器健康、GPU 硬件状态）、调度层（任务队列状态、资源分配情况）、业务层（训练进度、loss 曲线、吞吐、显存峰值）。每层指标独立采集，但通过任务 ID 串联起来，出问题时可以直接一条链路查到根因。

6.3 任务进度可视化的实践经验

训练任务的进度、loss 曲线这类业务指标，我们没有自己做可视化界面，而是直接接入算法同学已经熟悉的 TensorBoard 体系。平台侧只做两件事：一是为每个任务分配端口和访问凭证，前端页面内嵌 TensorBoard 交互；二是把日志汇总到统一入口，支持按任务 ID 查询。

这里有个容易被忽略的点：TensorBoard 的端口必须动态分配，否则多个任务同时跑就会冲突。我们通过服务发现机制，在任务启动时注册一个虚拟域名，结束后自动回收。

7. 平台建设的经验沉淀与下一步规划

从第一版裸机环境到现在的 GPU 容器 + 训练平台，前后大约经过了一年多迭代。如果让我总结能拿出来分享的经验，大概就三条。

第一条，平台建设初期不要太纠结"完美架构"，先把容器化跑通、任务能调起来，再逐步加入共享调度、镜像治理、可观测性这些进阶能力。我们的调度器最初版本就是基于原生 K8s 改的，连 Webhook 都没接，很多功能是后期一点点补的。

第二条，所有资源抽象都要考虑"逻辑对象"和"物理对象"的映射一致性。GPU 切分、逻辑设备回收、配额统计，很多故障都出在这个映射关系不同步上。一定要有定期巡检和状态校验机制，平台系统的可靠程度取决于这些兜底逻辑，而不是主流程有多么顺畅。

第三条，也是我认为最重要的一条，训练平台的服务对象是算法工程师，不是运维工程师。平台团队必须站在"降低算法同学的等待时间、提升他们的实验效率"这个视角去设计功能。我们上线队列制度时，算法同学的第一反应是"怎么又要排队了"，但当我们把排队时长从半小时降到分钟级、把共享池的算力扩大后，整体等待时间反而大幅下降了。

下一步规划里，我最想推进的方向有两个。一是将训练和推理的 GPU 池彻底分层，避免两个场景互相干扰；二是强化训练任务自动调优能力，通过历史资源使用数据，自动推荐最优的卡数、显存和批量大小，减少算法同学反复试错的时间。这些方向看起来离"能用"越来越远，但离"好用"越来越近。

最后分享一个小技巧：给平台加一个"一键复现"能力。每次算法同学反馈"上次跑得好好的，这次怎么不行"，大概率是环境变了。通过记录每个任务的镜像 ID、依赖版本、CUDA 版本、驱动版本、资源规格，一键重建出完全相同的环境，这个功能虽然不起眼，但在排障时能节省大量沟通成本。