1. 课程导入：学习目标、课程结构、容器化AI应用性能问题概述
1.1 为什么需要关注容器化AI应用的性能
容器化技术已经成为AI应用部署的主流方式。通过Docker和Kubernetes，团队可以快速打包模型服务、弹性扩缩容、隔离依赖环境。然而，容器化带来的隔离层、调度机制和资源配额，也为性能问题引入了新的复杂性。一个在裸机上运行良好的PyTorch推理服务，放入容器后可能因为CPU绑核不当、共享内存限制或GPU显存分配策略而出现明显的延迟抖动。
更关键的是，AI应用与传统Web服务在性能特征上有本质差异：
- 计算密集：模型推理依赖GPU/NPU算力，瓶颈往往在显存带宽、算子执行效率，而非简单的CPU使用率。
- 数据流水线复杂：数据加载、预处理、增强、批处理组装等环节都可能成为隐藏瓶颈。
- 资源需求动态波动：推理请求的batch size、输入尺寸变化会导致资源消耗剧烈波动，容器调度难以精准预判。
- 多组件协同：一个完整的推理服务通常包含API网关、预处理服务、模型推理引擎、后处理服务、缓存等多个容器，链路性能分析难度大。
1.2 课程学习目标
完成本课程后，你将能够：
- 定位容器层瓶颈：熟练使用
docker stats、kubectl top、crictl stats等命令快速判断CPU、内存、网络、磁盘的容器级资源瓶颈。 - 分析AI计算链路：掌握
nvidia-smi、nsys、py-spy、CUPTI等工具，定位GPU利用率低、显存不足、算子执行慢等模型侧问题。 - 识别调度与隔离问题：理解CPU绑核、NUMA拓扑、内存限制、GPU显存隔离对性能的影响，能够通过调整Kubernetes资源配额和调度策略优化性能。
- 建立系统化排查方法：掌握从“现象收集 → 假设验证 → 定位根因 → 优化验证”的闭环排查流程，避免盲目调参。
- 实战演练：通过多个真实案例（如GPU利用率低、推理延迟抖动、OOM重启、网络瓶颈等），积累可复用的排查经验。
1.3 课程结构总览
本课程共30个章节，按“基础 → 方法 → 实战 → 进阶”四个阶段组织：
| 阶段 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第1-6章 | 容器化AI架构、性能指标体系、常用工具链、资源隔离原理 |
| 方法篇 | 第7-14章 | CPU/内存/GPU/网络/存储瓶颈的定位方法、性能剖析技术 |
| 实战篇 | 第15-24章 | 10个真实生产案例：推理延迟高、GPU空闲、OOM、数据加载慢等 |
| 进阶篇 | 第25-30章 | Kubernetes调度优化、弹性伸缩、性能基准测试、持续性能监控 |
每个章节都包含：核心原理讲解、工具实操演示、典型故障案例复盘、常见误区提醒。建议按顺序学习，基础篇为后续实战提供必要的知识铺垫。
1.4 容器化AI应用性能问题全景图
为了帮助你在头脑中建立整体框架，下图展示了容器化AI应用中常见的性能瓶颈分布位置和相互关联：
上图展示了三个核心资源域及其典型瓶颈。在实际排查中，这些域之间还会相互影响：例如CPU预处理过慢会导致GPU空闲等待；内存限制过紧可能触发频繁GC或OOM重启；网络延迟高则会让整个推理链路响应变慢。因此，排查时不能孤立地看单一指标，而要从端到端的请求链路出发。
1.5 典型故障场景示例
为了让你对后续内容有直观感受，这里列举三个本课程将深入剖析的典型场景：
场景一：GPU利用率只有15%
现象：模型推理服务部署在Kubernetes中，nvidia-smi显示GPU利用率持续低于20%，但请求延迟却很高。
初步排查方向：数据加载是否成为瓶颈？batch size是否过小？CPU预处理是否拖慢整体流水线？是否存在GPU同步等待？
场景二：容器频繁OOM重启
现象：推理服务运行数小时后被Kubernetes判定为OOMKilled并重启，kubectl describe pod显示内存超过limit。
初步排查方向：模型显存与内存的映射关系？PyTorch缓存分配器是否占用过多内存？是否存在内存泄漏？limit设置是否合理？
场景三：推理延迟剧烈抖动
现象：P99延迟是P50的10倍以上，且抖动呈周期性。
初步排查方向：是否与其他容器共享物理机导致CPU争抢？NUMA跨节点访问？GPU显存碎片化？网络带宽周期性饱和？
1.6 常见误区与复盘
在开始正式学习之前，先澄清几个常见误区，避免你在后续排查中走弯路：
| 误区 | 正确认知 |
|---|---|
| 只看CPU利用率判断瓶颈 | AI应用中CPU低可能意味着GPU等待或IO阻塞，需要结合GPU指标、等待状态综合判断 |
| 盲目调大batch size提升吞吐 | batch size增大会增加显存占用和延迟，需在吞吐与延迟间权衡，并考虑显存上限 |
| 认为容器内看到的就是全部 | 容器内/proc和free看到的是隔离后的视图，宿主机层面的NUMA、CPU共享情况需要额外检查 |
| 忽略Kubernetes调度策略 | Pod调度位置、CPU manager策略、设备插件分配方式直接影响性能，需纳入排查范围 |