1. 项目背景与目标：大模型推理的痛点、为什么选择vLLM、为什么上K8s、压测的目标与指标定义
1.1 大模型推理的痛点：我踩过的那些坑
说实话，大模型推理这件事，远没有训练那么「光鲜」。训练再慢，大不了多挂几张卡等几天。但推理不一样——用户在线等着呢，延迟高了直接骂娘。
我最早接触大模型推理时，用的是 Hugging Face 的 Transformers 库直接加载模型做推理。嗯，当时觉得挺简单，模型加载、输入文本、输出结果，完事。但一上生产就崩了——显存爆炸、响应超时、吞吐量惨不忍睹。
总结下来，大模型推理有三大痛点：
- 显存瓶颈：一个 70B 的模型，光参数就要 140GB 显存（FP16）。单卡 A100（80GB）根本放不下，得做模型并行。但并行之后，通信开销又上来了。
- 计算效率低：Transformer 的 Decoder 结构，每次推理只能生成一个 token，前面的 token 还得重复计算。说白了，就是「算力浪费在重复劳动上」。我见过一个项目，单次推理耗时 30 秒，用户早跑了。
- 请求波动大：线上流量忽高忽低，高峰期请求排队，低谷期 GPU 空转。你想想看，一张 A100 一小时成本几十块，空转就是烧钱。
核心矛盾：大模型推理既要「快」（低延迟），又要「多」（高吞吐），还要「省」（低成本）。这三者往往不可兼得。
1.2 为什么选择 vLLM：一个让我「真香」的框架
市面上推理框架不少，比如 Hugging Face TGI、FasterTransformer、TensorRT-LLM。但我最终选了 vLLM，原因很简单——它解决了上面提到的「重复计算」问题。
vLLM 的核心创新是 PagedAttention。这名字听着玄乎，说白了就是：把 KV Cache 像操作系统的虚拟内存一样分页管理。
传统做法是：每个请求分配一块连续的显存存 KV Cache。但请求长度不一样，有的长有的短，连续分配容易产生碎片，浪费显存。vLLM 的做法是：把 KV Cache 切成固定大小的「页」，按需分配，不够了再申请新页。这样显存利用率从 60% 直接干到 95% 以上。
我在项目中遇到过类似场景：一个 13B 模型，用 Transformers 跑，最大并发只能到 4 个请求，显存就满了。换成 vLLM 后，同样的显存，并发能到 16 个。这差距，你品，你细品。
个人经验：vLLM 对长文本场景尤其友好。如果你的业务涉及长文档摘要、多轮对话，vLLM 的显存优势会非常明显。
另外，vLLM 还支持 Continuous Batching（连续批处理）。传统做法是等一批请求凑齐了再一起推理，但这样空闲时间多。vLLM 的做法是：只要有请求进来，就动态加入当前正在执行的批次中。说白了，就是「边推理边接客」，GPU 利用率拉满。
1.3 为什么上 K8s：单机玩不转了
一开始，我是在单机上跑 vLLM 的。模型不大，7B 左右，单卡 A10 就能跑。但后来业务扩张，模型升级到 70B，需要多卡并行，还要支持多个模型版本同时在线。单机显然不行了。
为什么上 K8s？我总结了三个理由：
- 资源弹性：线上流量有波峰波谷。K8s 可以根据 GPU 利用率自动扩缩容。高峰期加 Pod，低谷期减 Pod。说白了，就是「按需付费」，不花冤枉钱。
- 故障自愈：GPU 卡偶尔会挂，显存泄漏也是常有的事。K8s 的 Liveness Probe 和 Readiness Probe 可以自动检测异常 Pod 并重启。我曾经遇到过显存泄漏导致推理服务 OOM，K8s 自动拉起新 Pod，用户几乎无感知。
- 多模型管理：不同业务线需要不同模型。K8s 的 Namespace 和 Deployment 可以隔离管理，互不干扰。你想想看，如果每个模型都单独部署一台物理机，运维成本得多高？
避坑指南：我曾经在 K8s 上部署 vLLM 时，忘记配置 GPU 的 nvidia.com/gpu 资源限制，结果多个 Pod 抢同一张卡，导致推理性能急剧下降。记住，一定要在 Pod 的 resources 中显式声明 GPU 数量。
1.4 压测的目标与指标定义：到底测什么？
很多人做压测，上来就一顿猛打，看 QPS 多少。但这样测出来的数据，说实话，参考价值不大。压测的核心目标是：找到系统在「可接受延迟」下的「最大吞吐」。
我习惯把压测指标分为三类：
| 指标类别 | 具体指标 | 说明 |
|---|---|---|
| 延迟 | TTFT（首 Token 延迟） TPOT（每个 Token 延迟） 端到端延迟 |
TTFT 衡量「用户看到第一个字」的速度 TPOT 衡量「后续每个字」的生成速度 |
| 吞吐 | QPS（每秒请求数） TPS（每秒 Token 数） 并发数 |
QPS 适合短文本场景 TPS 适合长文本场景 |
| 资源 | GPU 显存利用率 GPU 算力利用率 CPU 内存 |
显存利用率决定你能跑多少并发 算力利用率决定 GPU 是否「吃饱」 |
举个例子：假设你的业务是智能客服，用户发一句话，模型回复一段话。这时候，TTFT 比 TPOT 更重要——用户等第一个字的时间超过 2 秒，体验就很差了。但如果是文档生成，用户更关心总耗时，TPOT 就很重要。
我的建议：压测前先定义好「SLA 红线」。比如：TTFT ≤ 1.5 秒，TPOT ≤ 50ms，在这个前提下，最大化 QPS。没有 SLA 的压测，就是耍流氓。
1.5 本章知识体系总览
下面这张图，是我做这个项目时梳理的思维导图。它把本章的核心逻辑串起来了：
这张图把本章的核心逻辑串起来了：痛点驱动选型 → 选型决定架构 → 架构需要验证 → 验证依赖指标。后面的章节，我们会一步步把这个流程落地到 K8s 上。
一个小建议：如果你刚接触这个领域，建议先在自己笔记本上跑一遍 vLLM 的 Quick Start，感受一下它的推理速度。然后再想 K8s 的事。别一上来就搞集群，容易劝退。
公众号:蓝海资料掘金营，微信deep3321