1. vLLM与K8s基础：架构、部署与模型缓存
大家好，我是你们的老朋友。今天咱们聊聊vLLM在K8s上的那些事儿。说实话，这个组合我折腾了快两年，踩过的坑比走过的路还多。但别担心，我会把最实用的经验分享给你。
vLLM架构概述
vLLM是什么？说白了，它是一个高性能的大模型推理引擎。我刚开始接触时，觉得它就是个普通的推理框架。后来才发现，它的核心优势在于PagedAttention技术。
你想想看，传统推理框架处理KV Cache时，就像在内存里找连续的空位。如果找不到，就得重新整理——这多浪费时间。vLLM的做法很聪明，它把KV Cache切成小块，像操作系统的虚拟内存一样管理。这样一来，内存利用率直接拉满。
核心组件一览：
- LLMEngine：推理引擎的核心，负责调度请求
- ModelRunner：实际执行模型前向传播
- Worker：分布式推理的工作节点
- CacheManager：管理KV Cache的分配与释放
我记得第一次在生产环境部署vLLM时，有个细节差点让我翻车——vLLM默认会预分配大量显存给KV Cache。如果你的GPU显存只有16GB，而模型参数占了12GB，那剩下的4GB根本不够用。嗯，这里要注意，--gpu-memory-utilization参数一定要调。
K8s核心概念速览
Kubernetes，大家都叫它K8s。我习惯把它理解成一个「数据中心操作系统」。你不需要关心Pod跑在哪台机器上，K8s会帮你搞定。
几个你必须掌握的概念：
| 概念 | 我的理解 | 在vLLM场景中的作用 |
|---|---|---|
| Pod | 最小调度单元，就像一台微型服务器 | 每个vLLM实例运行在一个Pod中 |
| Deployment | 管理Pod的声明式更新 | 保证vLLM服务始终有指定数量的副本 |
| Service | 稳定的网络入口 | 对外暴露vLLM的API接口 |
| PVC | 持久化存储声明 | 存储模型文件和缓存数据 |
| Node | 集群中的物理或虚拟机器 | 运行vLLM Pod的工作节点 |
你可能会问：「为什么非要用K8s？直接在一台机器上跑vLLM不行吗？」当然可以。但当你需要管理10个、100个模型服务时，K8s的自动扩缩容、滚动更新、故障恢复这些能力，会让你省心不少。
vLLM on K8s部署模式
我在项目中试过三种部署模式，各有优劣：
模式一：单Pod部署
最简单的方式。一个Pod里跑一个vLLM实例，挂载一个GPU。适合模型不大、请求量稳定的场景。
apiVersion: v1
kind: Pod
metadata:
name: vllm-single
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
args: ["--model", "meta-llama/Llama-2-7b-chat-hf"]
resources:
limits:
nvidia.com/gpu: 1模式二：Deployment + Service
这才是生产级的玩法。用Deployment管理多个副本，用Service做负载均衡。我曾经帮一个客户从单Pod迁移到这种模式，吞吐量直接翻了3倍。
我的小技巧：设置spec.replicas时，不要只设一个固定值。配合HPA（Horizontal Pod Autoscaler），根据GPU利用率自动扩缩容，能省下不少成本。
模式三：StatefulSet + 分布式推理
当模型大到单卡放不下时，就需要分布式推理了。比如175B的GPT-3，得用多张GPU分片加载。StatefulSet能保证每个Pod有稳定的网络标识，这对分布式通信很重要。
注意：分布式部署时，Pod之间的通信延迟会直接影响推理速度。我建议把相关Pod调度到同一个K8s节点上，或者至少保证节点间有高速网络（比如RDMA）。
模型缓存的价值与挑战
说到缓存，我得先讲个真实案例。去年有个客户，每天要处理上百万次推理请求。每次请求都要重新加载模型，GPU利用率只有20%。我帮他们做了模型缓存优化后，利用率直接飙到85%。
模型缓存的价值体现在三个方面：
- 减少加载时间：模型从磁盘加载到显存，动辄几十秒。缓存后，秒级启动。
- 降低资源消耗：不用每次请求都重新计算KV Cache，节省大量算力。
- 提升吞吐量：缓存命中率高时，系统能处理更多并发请求。
但挑战也不小：
- 缓存一致性：模型更新后，旧缓存怎么处理？我曾经遇到过缓存没及时清理，导致推理结果还是旧模型的情况。
- 内存管理：缓存占用的显存和模型本身争抢资源。调优时就像走钢丝，多了少了都不行。
- 分布式缓存同步：多节点部署时，缓存数据怎么共享？用Redis还是直接挂载共享存储？
下面这张图，是我总结的vLLM在K8s上的缓存架构：
从图上你能看到，缓存管理是整个架构的「大脑」。它决定哪些KV Cache该保留，哪些该淘汰。我曾经踩过一个坑：默认的LRU策略在长对话场景下表现很差，因为早期的对话上下文被频繁淘汰。后来我改成了基于token数量的加权策略，效果好了很多。
避坑指南：如果你用共享存储做模型缓存，一定要关注IOPS。我曾经用NFS挂载，结果并发高时IO成了瓶颈。后来换成本地SSD + 分布式缓存层，问题才解决。
好了，这一章的内容就到这里。模型缓存是个系统工程，后面我们会深入每个环节的优化细节。