课程导入：课程目标、目标学员、学习路径与vLLM结合Kubernetes的价值
欢迎进入《vLLM结合Kubernetes容器化部署实战》课程。在正式开始技术细节之前，我们需要先建立全局认知框架。大语言模型（LLM）的推理服务化部署，已经从“单机跑通”演进为“分布式、高并发、弹性伸缩”的工程体系。vLLM作为当前业界领先的高吞吐推理引擎，解决了显存管理与调度效率的核心痛点；而Kubernetes（K8s）作为容器编排的事实标准，提供了资源调度、服务发现、自动扩缩容与故障恢复的完整能力。将两者结合，并非简单的“把vLLM装进容器”，而是需要从架构设计、资源模型、性能调优、运维治理等多个维度进行系统性整合。本章作为全课程的起点，将明确学习目标、界定目标学员、规划学习路径，并深入剖析vLLM与Kubernetes结合的价值模型与典型应用场景，为后续章节的实战操作奠定认知基础。
1.1 课程目标与目标学员
本课程的核心目标，是培养学员构建生产级LLM推理服务平台的综合能力。我们不止于“跑通Demo”，而是聚焦于如何将vLLM引擎稳定、高效、弹性地运行在Kubernetes集群之上。课程结束后，学员应能够独立完成从模型打包、镜像构建、集群部署、性能调优到监控告警的全链路工作。
具体而言，课程目标可拆解为以下四个层级：
| 目标层级 | 能力描述 | 对应章节 |
|---|---|---|
| 理解层 | 掌握vLLM的PagedAttention、Continuous Batching等核心机制，理解其与K8s资源模型的映射关系 | 第2-4章 |
| 操作层 | 熟练编写Dockerfile、K8s YAML清单，完成vLLM服务的容器化部署与暴露 | 第5-10章 |
| 优化层 | 基于Prometheus监控指标，配置HPA弹性伸缩规则，实现GPU资源利用率最大化 | 第11-18章 |
| 架构层 | 设计多租户隔离、GPU共享、模型热加载等高级架构方案，满足企业级SLA要求 | 第19-30章 |
目标学员画像方面，本课程主要面向三类人群：AI平台工程师（负责搭建和维护LLM推理基础设施）、ML Ops工程师（关注模型部署的自动化与标准化）、以及后端开发/架构师（需要将LLM能力集成到业务系统中）。学员需要具备的基础包括：熟悉Python编程、了解Docker基本命令（如build、run）、掌握Linux常用操作，以及具备基本的YAML语法阅读能力。如果你对Kubernetes仅有概念性了解，不必担心，课程第6章会专门安排K8s核心对象的快速入门。
--gpu-memory-utilization参数。建议在学习过程中，始终带着“为什么这样设计”的思考。
1.2 学习路径规划与章节地图
本课程共30章，按照“基础→进阶→高级→生产”的螺旋式结构设计。每一章都包含理论讲解、动手实验和常见问题复盘三个环节。建议学员按照顺序学习，因为后续章节会频繁引用前面章节的概念和配置。
学习路径分为五个阶段，每个阶段都有明确的产出物：
- 阶段一（第1-4章）：基础认知与单机部署。产出：本地运行一个vLLM服务，理解其核心参数。
- 阶段二（第5-8章）：容器化改造。产出：构建vLLM的Docker镜像，在单机Docker中运行并验证GPU透传。
- 阶段三（第9-14章）：Kubernetes编排。产出：在K8s集群中部署vLLM服务，配置Service和Ingress，实现外部访问。
- 阶段四（第15-22章）：弹性与调度进阶。产出：配置基于自定义指标的HPA，实现GPU共享与节点池管理。
- 阶段五（第23-30章）：生产级治理。产出：完整的监控告警体系、多租户隔离方案、以及故障演练报告。
为了帮助学员快速定位知识盲区，我们设计了如下自测清单。在开始学习前，请对照检查自己的掌握程度：
- 是否清楚Transformer模型推理时的显存占用分布？（KV Cache、模型权重、激活值）
- 是否了解vLLM与HuggingFace Transformers在推理性能上的数量级差异？
- 是否知道Kubernetes中
requests和limits对GPU调度的影响？ - 是否理解HPA弹性伸缩的冷却周期和指标采集延迟？
如果以上问题有超过两个无法回答，建议在对应章节学习时投入更多精力。
1.3 vLLM与Kubernetes结合的价值模型
vLLM与Kubernetes的结合，本质上是“计算效率”与“资源效率”的乘法效应。单独使用vLLM，你获得的是一个高性能的推理引擎，但缺乏弹性伸缩和故障恢复能力；单独使用Kubernetes，你获得的是一个成熟的编排平台，但Pod内的推理服务可能成为性能瓶颈。两者的结合，产生了三个层面的价值：
第一层：弹性伸缩与成本控制。LLM推理服务的流量波动往往非常剧烈——例如一个面向内部员工的代码辅助工具，工作日上午10点和下午3点的请求量可能相差5倍。通过Kubernetes的HPA（Horizontal Pod Autoscaler），我们可以基于vLLM暴露的自定义指标（如vllm:num_requests_running、GPU利用率）自动调整Pod副本数。在低峰期缩容至最小副本，高峰期提前扩容，从而显著降低GPU云资源成本。
第二层：资源利用率与GPU共享。vLLM的PagedAttention技术已经大幅提升了单卡利用率，但在多模型、多租户场景下，单张GPU卡上运行多个小型模型的需求依然存在。Kubernetes提供了设备插件（Device Plugin）机制，配合NVIDIA MPS（Multi-Process Service）或vGPU方案，可以实现GPU的细粒度切分。例如，一张A100 80GB显卡，可以切分为4个20GB的虚拟GPU，分别运行不同版本的模型，通过K8s的ResourceQuota进行隔离。
第三层：运维标准化与可靠性。生产环境中的LLM服务必须满足SLA要求。Kubernetes提供的滚动更新（Rolling Update）策略，可以在不中断服务的情况下升级vLLM版本或替换模型权重。配合就绪探针（Readiness Probe），K8s可以自动摘除尚未加载完成的Pod流量。此外，通过PodDisruptionBudget，我们可以保证在进行节点维护时，至少有N个副本保持可用。
1.4 典型应用场景与案例拆解
为了更具体地说明vLLM与Kubernetes结合的实际价值，我们来看一个典型的多租户SaaS平台案例。假设我们是一家提供AI写作助手的SaaS公司，需要为不同规模的企业客户提供模型推理服务。
场景背景与约束：平台拥有三个不同规模的模型：7B参数（轻量级，用于实时补全）、13B参数（标准级，用于文章生成）、70B参数（重量级，用于深度分析）。客户分为免费版、专业版和企业版，不同版本对应不同的并发上限和优先级。基础设施为混合云环境：自建机房有20张A100 GPU，公有云可按需弹性扩容。
初始现象与目标：最初采用“一个模型一个裸机集群”的方式，导致资源碎片化严重——7B模型的GPU利用率不足20%，而70B模型的集群经常排队。目标是将所有模型统一调度到Kubernetes平台，实现资源池化，并保证企业版客户的SLA（P99延迟<500ms）。
关键输入数据与指标：我们采集了连续两周的请求日志，发现免费版客户的请求量波动极大（峰值/谷值比达到8:1），而企业版客户相对平稳。7B模型平均请求处理时间为80ms，13B模型为220ms，70B模型为1.2s。GPU显存占用方面，7B模型约需16GB，13B约需32GB，70B约需70GB（使用INT8量化后）。
分析判断过程：基于以上数据，我们决定采用节点池隔离 + HPA弹性伸缩的混合架构。具体来说：
- 将自建机房的20张A100划分为两个节点池：
pool-standard（16张卡）和pool-large（4张卡）。 - 7B和13B模型部署在
pool-standard，通过K8s的nodeSelector绑定；70B模型部署在pool-large。 - 为7B模型配置HPA，指标为
vllm:num_requests_running，目标值为50，冷却周期为300秒。当请求量激增时，自动扩容Pod副本数，并借助Cluster Autoscaler在公有云上创建新的GPU节点。 - 企业版客户通过专用的Ingress路径路由到固定副本数的Deployment，避免被免费版流量冲击。
实际操作步骤与结果对比：实施后，免费版客户的请求在高峰期可以快速扩容至20个副本，P95延迟维持在300ms以内；企业版客户由于独享资源池，P99延迟稳定在450ms。整体GPU利用率从35%提升至58%。代价是需要额外维护Cluster Autoscaler的节点组配置，以及编写自定义指标适配器（Prometheus Adapter）。
风险与复盘经验：初期我们曾遇到HPA频繁抖动的问题——由于vLLM的请求处理速度极快，num_requests_running指标在毫秒级波动，导致Pod频繁扩缩容。解决方案是调整HPA的behavior配置，设置scaleDown的 stabilizationWindowSeconds 为600秒，并增加指标聚合窗口。另一个教训是，GPU节点在公有云上的创建时间较长（约5分钟），因此对于可预见的流量高峰（如营销活动），需要提前手动扩容节点池。
resources.limits.nvidia.com/gpu与requests的一致性。如果只设置limits而不设置requests，K8s调度器可能将多个Pod调度到同一张GPU卡上，导致显存溢出（OOM）。建议始终同时设置两者，并确保数值一致。
1.5 常见误区与学习建议
在长期的教学和工程实践中，我们发现学员在入门阶段常犯以下错误，在此提前指出，帮助大家少走弯路：
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 将vLLM当作黑盒，只关注API调用 | 无法针对业务场景调整max-model-len、gpu-memory-utilization等关键参数 |
阅读vLLM官方文档中关于PagedAttention和Continuous Batching的说明，理解每个参数对吞吐和延迟的影响 |
在K8s中直接使用hostPort暴露服务 |
端口冲突、无法利用Service负载均衡 | 使用ClusterIP + Ingress或LoadBalancer类型Service |
忽略preStop钩子 |
Pod终止时正在处理的请求被强制断开，导致客户端报错 | 配置preStop执行sleep，并配合Readiness Probe实现优雅下线 |
| 所有模型共用一个Deployment | 不同模型的资源需求差异大，互相干扰 | 按模型规格拆分Deployment，使用nodeSelector或affinity进行节点绑定 |
最后，关于学习节奏的建议：本课程包含大量动手实验，建议每完成一章学习后，在真实的K8s集群（可以是云厂商的托管集群，也可以是本地Kind集群）中复现实验。不要只停留在“看懂YAML”的层面，一定要亲手执行kubectl apply并观察Pod的调度过程。遇到问题时，优先查看vLLM的容器日志（kubectl logs）和K8s事件（kubectl describe pod），这是排障的第一入口。