1、课程导学与项目全景：vLLM推理框架简介、K8s部署的价值、项目整体架构图、学习路径规划

大家好，我是你们这门课的主讲。在AI运维这个坑里摸爬滚打了六七年，从最早的TensorFlow Serving裸机部署，到后来用Docker Compose编排，再到今天用Kubernetes管理千卡集群，我踩过的坑，说实话，比你们吃过的盐还多（笑）。

这门课，咱们不聊虚的。直接上生产环境。目标就一个：让你能独立把一个高并发、高可用的vLLM推理服务，稳稳当当跑在K8s上。

vLLM推理框架：它到底牛在哪？

先说说vLLM。你可能听过，也可能没用过。简单讲，它是一个专门为LLM推理优化的框架。为什么选它？

我去年帮一家公司做模型上线，他们用Hugging Face的Transformers直接推理，一个70B的模型，单卡A100，QPS（每秒查询数）死活上不去，只有个位数。后来换成vLLM，同样的硬件，QPS直接翻了5倍。为什么？

核心在于它的PagedAttention技术。你想想看，传统推理时，显存里存的是完整的KV Cache，就像一个大仓库，不管用不用，先占着地方。vLLM不一样，它把KV Cache切成小块（Page），按需分配。这就像内存分页，利用率极高。

另外，它还支持Continuous Batching。传统做法是等一个请求处理完，再处理下一个。vLLM可以动态地把多个请求拼成一个Batch，一起算。GPU利用率自然就上去了。

为什么非要用K8s部署？

有人可能会问：我单机部署vLLM不香吗？香，但仅限于实验环境。

生产环境里，你面对的是：

• 流量洪峰：白天用户多，晚上用户少。单机没法弹性伸缩。
• 硬件故障：GPU卡偶尔会挂，机器会宕。单点故障直接导致服务中断。
• 模型更新：今天要上线v2版本，明天要回滚v1版本。手动操作太容易出错了。

K8s的价值，说白了就是帮你解决这三个问题：弹性、高可用、声明式管理。

我记得有一次，线上流量突然暴涨，K8s的HPA（水平自动伸缩）自动拉起5个Pod，扛住了压力。如果当时是裸机部署，我估计得半夜爬起来手动加机器。嗯，那种感觉，经历过的人都懂。

项目整体架构图

下面这张图，是我根据多个生产项目经验总结出来的。它展示了我们这门课要搭建的完整架构。

这张图里，从上到下分了几层：

1. 入口层：Ingress负责域名和TLS终止，LoadBalancer负责流量分发。
2. 服务层：vLLM Service作为内部负载均衡，把请求分发给后端的Pod。
3. Pod层：每个Pod里跑一个vLLM实例，绑定一块GPU。HPA根据CPU/GPU利用率或QPS自动扩缩。
4. 存储层：模型文件放在PVC里，可以是NFS或者S3。Pod启动时自动挂载。
5. 监控层：Prometheus采集指标，Grafana展示仪表盘。出了问题能第一时间发现。

学习路径规划

这门课一共30章，我把它分成了四个阶段。每个阶段都有明确的目标。

阶段	章节范围	核心目标
基础准备	第1-5章	搭建K8s集群、熟悉vLLM基本用法、理解GPU调度原理
核心部署	第6-15章	编写Deployment/Service/HPA YAML、配置Ingress、实现滚动更新
进阶优化	第16-25章	性能调优、监控告警、日志收集、成本控制
生产实战	第26-30章	多模型管理、A/B测试、故障演练、CI/CD集成

我个人建议，如果你对K8s还不太熟，前5章一定要跟着动手敲一遍。别光看。我见过太多人，看视频觉得都会了，一上手就报错。嗯，动手才是硬道理。

好了，这一章就到这里。咱们下一章见。

---