第一章：vLLM与K8s基础
大家好，我是你们的运维老手。今天咱们聊聊vLLM和K8s怎么搭伙过日子。
说实话，我第一次接触vLLM时，心里还挺没底的。那时候公司要上线一个大模型推理服务，GPU资源紧张得要命，每次部署都像在刀尖上跳舞。后来发现vLLM+K8s这套组合拳，才算是找到了方向。
1.1 vLLM是什么？
vLLM，全称是Virtual Large Language Model，说白了就是一个专门为LLM推理加速设计的开源库。它最牛的地方在于——显存管理。
你想想看，大模型推理时最头疼的是什么？显存爆炸。一个70B的模型，光参数就得占140GB显存。vLLM通过PagedAttention技术，把显存利用率从40%直接拉到95%以上。我在项目中遇到过，同样的硬件，用vLLM能多塞2-3个模型实例。
核心特性一览：
- PagedAttention：像操作系统的虚拟内存一样管理显存
- 连续批处理：动态合并请求，吞吐量提升10倍
- 量化支持：FP16、INT8、INT4，按需选择
- OpenAI兼容API：无缝对接现有工具链
嗯，这里要注意：vLLM不是万能的。它主要优化的是推理阶段的显存和吞吐，对训练场景不适用。我见过有人拿vLLM做微调，结果踩坑踩得怀疑人生。
1.2 K8s核心概念速览
Kubernetes，简称K8s，是Google开源的容器编排平台。说白了，它就是一群服务器的管家，帮你管着容器怎么跑、跑在哪、挂了怎么办。
我个人习惯把K8s的核心概念分成三层：
| 层级 | 核心对象 | 一句话解释 |
|---|---|---|
| 工作负载层 | Pod、Deployment、StatefulSet | 管你的应用怎么跑 |
| 网络层 | Service、Ingress、Endpoint | 管流量怎么进来 |
| 存储层 | PV、PVC、ConfigMap、Secret | 管数据和配置 |
对于vLLM部署，你最需要关注的是Pod和Service。Pod是跑模型的最小单元，Service负责把流量分发给这些Pod。
我的小建议：刚开始学K8s时，别急着搞太复杂。先把Pod和Service玩明白，后面再慢慢加Ingress、HPA这些。我曾经带过一个新人，上来就搞Istio，结果三天没睡好觉。
1.3 为什么需要负载均衡？
这个问题问得好。你想想，如果只有一个vLLM实例，那流量来了它扛得住吗？扛不住。如果搞多个实例，流量怎么分？这就是负载均衡要解决的问题。
具体来说，有三大痛点：
- 单点故障：一个实例挂了，整个服务就瘫了。我经历过一次，半夜三点被叫起来，那滋味...嗯，你懂的。
- 资源不均：有的GPU卡忙死，有的闲死。负载均衡能把请求均匀分配，让每张卡都物尽其用。
- 弹性伸缩：流量高峰时自动加实例，低谷时自动减。没有负载均衡，伸缩就是个笑话。
避坑指南：我曾经在项目中只用了一个vLLM实例，结果用户量一上来，显存直接爆了，所有请求都返回502。后来加了负载均衡和自动伸缩，再也没出过类似问题。
1.4 vLLM+K8s架构概览
好了，前面铺垫了这么多，咱们来看看整体架构长什么样。我画了一张图，帮你快速理解：
从这张图你能看到，整个架构分四层：
- 用户层：所有请求先打到K8s Service上
- 负载均衡层：Service根据策略（比如Round Robin）把请求分给后端的vLLM Pod
- 推理层：每个Pod跑一个vLLM实例，独占一张GPU卡
- 存储层：模型权重、配置文件通过PV/PVC共享
我个人习惯在架构里再加一个监控层，用Prometheus盯着每个Pod的GPU利用率、请求延迟、显存占用。这样一旦哪个Pod出问题，能第一时间发现。
关键设计原则：
- 每个vLLM Pod绑定一张GPU，避免资源争抢
- Service用ClusterIP模式，内部负载均衡
- 模型权重放在共享存储，方便滚动更新
- 监控指标暴露给Prometheus，配置告警规则
好了，第一章的内容就到这里。记住这个架构图，后面我们会一步步把它落地成真正的K8s YAML文件。