课程导入：容器化GPU资源分配与隔离
学习目标
完成本章学习后，你将能够：
- 准确描述容器场景下GPU资源管理的核心矛盾——共享与隔离的平衡；
- 区分GPU显存隔离与计算能力隔离两个不同维度，并解释为何仅做显存隔离不足以保障服务质量；
- 梳理从设备暴露到细粒度调度的完整技术层次，建立后续章节的知识地图；
- 识别生产环境中常见的GPU资源滥用风险，理解资源失控的典型后果。
核心概念：从“看见GPU”到“用好GPU”
在传统虚拟机环境中，GPU通常以直通（Passthrough）方式绑定给单个虚拟机，隔离简单但利用率低下。容器化改变了这一格局——多个容器可以共享同一块物理GPU，但由此引入了三个关键问题：
- 可见性：容器如何发现宿主机上的GPU设备？
- 可分配性：如何将GPU的显存与算力切分给不同容器？
- 可隔离性：当一个容器满载显存或持续高算力运行时，如何避免影响邻居容器？
这三个问题构成了容器化GPU资源管理的完整链条。下图展示了从物理GPU到容器实例的核心层次关系：
上图揭示了容器化GPU管理的分层逻辑：底层是物理GPU硬件，中间经过设备插件与运行时暴露给上层，再由隔离机制切分显存与算力，最终呈现为多个容器各自独立的GPU视图。本章后续所有内容都将围绕这一架构展开。
整体框架：五层技术栈
本课程共30章，按技术深度递进组织为五个层次：
| 层次 | 章节范围 | 核心主题 | 关键工具/技术 |
|---|---|---|---|
| 基础层 | 第1-5章 | GPU虚拟化原理、容器运行时集成 | NVIDIA Container Toolkit, runc |
| 隔离层 | 第6-12章 | 显存隔离、算力隔离、MPS与时间切片 | CUDA MPS, Time-Slicing, 显存控制组 |
| 调度层 | 第13-20章 | Kubernetes设备插件、资源调度策略 | Device Plugin, 调度器扩展 |
| 观测层 | 第21-26章 | 监控、日志、性能剖析与告警 | DCGM, Prometheus, Grafana |
| 实践层 | 第27-30章 | 生产环境最佳实践、故障排查与性能调优 | 真实案例与排障方法论 |
典型场景：为什么需要细粒度隔离？
考虑一个真实的AI推理平台：
场景描述：一台8卡A100服务器上运行着多个模型推理容器。某团队部署了一个显存占用达30GB的大模型，同时另一个团队启动了20个小型OCR容器。若不加以隔离，可能出现：
- 大模型容器申请显存失败，触发OOM Killer；
- 小型容器因算力争抢导致P99延迟从20ms飙升至800ms；
- 单个容器异常死循环，占满GPU算力，导致同卡其他容器全部超时。
这正是本课程要解决的核心问题——通过合理的资源分配与隔离策略，让每个容器获得可预测、可保障的GPU资源。
常见误区与复盘
误区一：认为“设置了显存上限就等于隔离完成”
显存隔离只解决“不会撑爆”的问题，不解决“算力被抢”的问题。两个容器即使各自显存占用正常，也可能因SM（流处理器）争抢导致性能剧烈波动。必须同时考虑计算隔离。
误区二：盲目使用GPU共享而忽略MPS的上下文切换开销
MPS（Multi-Process Service）虽然能提升利用率，但频繁的上下文切换会引入额外延迟。对于延迟敏感型推理任务，需要评估共享粒度是否合适。
误区三：忽略CPU与GPU之间的协同调度
GPU资源分配不仅是显存和算力，还包括CPU侧的DMA通道、PCIe带宽和GPU拷贝引擎。CPU资源不足时，GPU利用率同样会大幅下降。