1. 课程导入:学习目标、课程结构、GPU容器化概述与优势

1.1 为什么需要GPU容器化

在深度学习、科学计算与大规模推理场景中,GPU算力已成为稀缺资源。传统裸机部署方式面临三个核心痛点:环境一致性差(CUDA、cuDNN、驱动版本互相牵制)、资源利用率低(单卡多任务难以隔离)、迁移成本高(换一台机器就要重新配置环境)。容器化技术将GPU资源与运行环境解耦,使团队能够像管理普通微服务一样管理GPU工作负载。

本课程面向已掌握Docker基础操作、熟悉Linux命令行、具备基本GPU使用经验的工程师,系统讲解从单机到集群的GPU容器化部署全链路。课程不要求读者具备Kubernetes或CUDA编程经验,但建议了解虚拟化基本概念。

1.2 课程学习目标

完成本课程后,你将能够:

  • 理解GPU容器化的核心原理:掌握Linux设备映射(/dev/nvidia*)、驱动兼容层、用户态与内核态CUDA的协作机制。
  • 独立完成NVIDIA Container Toolkit部署:在Ubuntu/CentOS等主流发行版上配置GPU运行时,并验证容器内GPU可用性。
  • 编写生产级GPU Dockerfile:正确处理CUDA基础镜像选择、Python环境隔离、多阶段构建等关键细节。
  • 掌握GPU资源编排方法:使用Docker --gpus参数、Kubernetes设备插件及共享GPU方案,实现算力按需分配。
  • 建立监控与排障体系:通过nvidia-smi、DCGM等工具定位显存泄漏、驱动异常、性能下降等问题。

1.3 课程结构总览

课程共30章,按“原理→单机→集群→进阶→实战”五阶段递进。下表展示了各模块的核心内容与对应章节范围:

阶段 章节范围 核心主题 关键产出
原理基础 1-5 GPU虚拟化原理、驱动模型、容器运行时 理解设备映射与CUDA分层
单机部署 6-12 NVIDIA Container Toolkit、Dockerfile优化 可复用的GPU镜像模板
集群编排 13-20 Kubernetes GPU调度、共享GPU、MIG 生产级YAML编排清单
进阶调优 21-26 性能监控、故障排查、安全加固 排障决策树与监控面板
实战案例 27-30 LLM推理、模型训练、CI/CD集成 端到端部署方案

课程强调“每个结论都有验证命令”,所有示例均在NVIDIA A100/A30及RTX 3090上验证通过。建议按顺序学习,前五章是后续操作的理论基石。

学习建议:第1-5章即使跳过操作,也务必理解原理图。后续章节中90%的排障思路都源于对“用户态CUDA→驱动→硬件”这条调用链的清晰认知。

1.4 GPU容器化核心原理

GPU容器化并非“在容器里装驱动”,而是通过宿主机驱动透传与用户态库挂载的组合实现。其本质是:容器共享宿主机的GPU驱动(内核模块),但拥有独立的CUDA用户态运行库。下图展示了这一分层架构:

GPU容器化分层架构原理 宿主机 (Host OS) 物理GPU硬件 (NVIDIA A100 / V100 / RTX 3090 ...) PCIe总线 · NVLink · 显存控制器 NVIDIA 内核驱动 (nvidia.ko) + 设备文件 /dev/nvidia* 由宿主机加载 · 容器共享 · 通过Linux设备映射暴露 容器A (训练任务) CUDA用户态库 (libcudart.so) CUDA 11.8 · cuDNN 8.6 · TensorRT Python / PyTorch / TensorFlow 应用层代码 容器B (推理服务) CUDA用户态库 (libcudart.so) CUDA 12.0 · TensorRT 8.5 Triton / FastAPI / 模型服务 gRPC接口 关键点: 容器内不包含内核驱动,仅包含用户态CUDA库。驱动由宿主机统一管理, 通过NVIDIA Container Toolkit将设备文件与库自动注入容器。

图中展示了两个关键分层:内核态驱动(灰色区域)由宿主机独占,而用户态CUDA库(橙色区域)随镜像分发。容器运行时通过nvidia-container-cli在容器启动时执行以下操作:

  1. 将宿主机的/dev/nvidia0、/dev/nvidiactl等设备文件映射到容器内;
  2. 挂载与容器内CUDA版本匹配的libcuda.so、libnvidia-ml.so等用户态库;
  3. 注入必要的环境变量(如NVIDIA_VISIBLE_DEVICES、NVIDIA_DRIVER_CAPABILITIES)。

1.5 GPU容器化的核心优势

相比传统裸机部署,GPU容器化带来四个维度的显著提升:

  • 环境隔离与可复现性:同一物理GPU上可运行不同CUDA版本(如11.8与12.0)的容器,互不干扰。镜像即环境,彻底解决“在我机器上能跑”的问题。
  • 资源利用率倍增:通过MPS(多进程服务)或时间切片,可将单张GPU切分为多个虚拟设备,利用率从平均30%提升至70%以上。
  • 秒级弹性伸缩:容器启动时间仅需2-5秒(相比裸机环境配置的30分钟+),配合Kubernetes可实现GPU工作负载的自动扩缩容。
  • 运维标准化:驱动升级只需在宿主机操作,容器镜像无需重建。监控、日志、健康检查均可复用云原生生态工具。
典型收益数据:某互联网公司AI平台团队在采用GPU容器化后,GPU集群整体利用率从28%提升至65%,新模型上线时间从2天缩短至2小时,硬件采购成本降低约40%(通过共享GPU减少闲置)。

1.6 常见误区与澄清

在课程开始前,先澄清几个高频误解,避免后续踩坑:

误区1:容器内需要安装NVIDIA驱动。
正确做法:容器内只装CUDA用户态库,驱动必须由宿主机提供。若在Dockerfile中执行apt install nvidia-driver,会导致容器启动失败或与宿主机驱动冲突。
误区2:--gpus all 等于完全隔离。
实际上--gpus all默认共享显存与计算单元。若需严格隔离,必须配置MIG(多实例GPU)或使用时间切片策略,否则一个容器可能占满显存导致其他容器OOM。
误区3:CUDA版本越新越好。
容器内CUDA版本必须与宿主机驱动支持的CUDA版本兼容。例如驱动版本535.104支持CUDA 12.2,但容器内使用CUDA 11.8仍可运行(通过向前兼容),反之则不行。建议使用nvidia-smi查看驱动支持的CUDA版本上限。