第4章性能指标

4、性能指标：吞吐量、延迟、首 Token 延迟、显存利用率

聊性能指标，其实就是在聊「钱」和「用户体验」。你想想看，模型跑得再快，显存爆了也是白搭；延迟再低，吞吐上不去，业务方照样找你麻烦。我个人习惯把这四个指标分成两组来看：一组是「快不快」（延迟类），一组是「多不多」（吞吐和利用率）。

吞吐量，说白了就是单位时间内能处理多少个请求。在 vLLM 里，我们通常用 requests per second（RPS） 或者 tokens per second（TPS） 来衡量。

我在项目中遇到过一种情况：业务方说「我的模型推理很快啊，单次推理只要 50ms」，结果一上压测，吞吐量惨不忍睹。为什么？因为单次延迟低不代表并发能力强。vLLM 的 Continuous Batching 机制就是为了解决这个问题的——它能把多个请求拼在一起处理，大幅提升吞吐。

  核心公式（简化版）：

  吞吐量 ≈ (Batch Size × 输出长度) / 总耗时

嗯，这里要注意：吞吐量不是越高越好。你得看你的业务场景。如果是实时对话，吞吐量太高反而可能导致单个请求等待时间变长。我建议你压测时至少跑 3 轮，取中位数，别被第一轮的热启动数据骗了。

延迟就是用户发出请求到收到完整回复的时间。通常我们关注 P50、P95、P99 这三个分位值。P99 延迟超过 2 秒，用户基本就跑了。

我曾经踩过一个坑：只看平均延迟，觉得「嗯，500ms，不错」。结果一查 P99，好家伙，5 秒！原因是某些长序列请求把平均延迟拉高了，但平均数据掩盖了尾部延迟的问题。所以我现在做性能评估，必看 P99。

我的小技巧：
用 vLLM 的 --max-num-batched-tokens 参数控制最大批处理 token 数，可以有效降低尾部延迟。别让一个超长请求拖慢所有人。

TTFT（Time To First Token），就是用户发出请求后，到收到第一个 token 的时间。这个指标在流式输出场景下特别关键。你想想看，用户点了一下「发送」，如果 3 秒后才看到第一个字，他可能已经关掉页面了。

TTFT 主要受两个因素影响：

我记得有一次优化，发现 TTFT 总是偏高。排查了半天，结果是 vLLM 的调度器配置不当，导致请求在 prefill 阶段被阻塞了。后来我把 --max-num-seqs 调小了一点，TTFT 直接降了 40%。

注意：
TTFT 和吞吐量是 trade-off 关系。你强行压低 TTFT，可能会牺牲吞吐。我个人习惯是：先保证 TTFT 在 500ms 以内，再往上堆吞吐。

显存利用率，说白了就是你的 GPU 显存有没有被浪费。vLLM 的 PagedAttention 机制就是为了解决显存碎片化问题的。但即使这样，你仍然需要关注几个关键点：

我建议你用 nvidia-smi 配合 vLLM 的 --gpu-memory-utilization 参数来调优。这个参数默认是 0.9，但我个人习惯设到 0.95，前提是你得留点余量给 CUDA 内核和其他开销。

  显存利用率计算公式：

  显存利用率 = (已用显存 - 模型权重) / 总显存

  理想值：85% - 95%

嗯，这里有个坑：显存利用率不是越高越好。我曾经把 --gpu-memory-utilization 设到 0.98，结果跑着跑着就 OOM 了。因为 vLLM 的显存管理虽然优秀，但总有一些临时分配的开销。留 5% 的余量是明智的。

为了让你更直观地理解这四个指标之间的关系，我画了一张图。你可以看到，它们不是孤立的，而是相互影响、相互制约的。

在实际项目中，你不可能同时优化所有指标。我一般按场景优先级排序：

场景	首要指标	次要指标	可牺牲指标
实时对话	TTFT < 500ms	P99 延迟	吞吐量
批量离线推理	吞吐量	显存利用率	TTFT
流式输出	TTFT	吞吐量	P50 延迟
高并发 API	P99 延迟	吞吐量	显存利用率

我的建议：
先确定业务场景，再定指标优先级。别一上来就追求「全优」，那是不可能的。我曾经在一个项目里为了把吞吐量从 100 提到 120，结果 TTFT 从 300ms 飙到了 800ms，业务方直接投诉。后来我学乖了，先满足业务 SLA，再优化其他指标。

好了，这四个指标你心里有数了吧？记住一句话：没有完美的指标，只有合适的 trade-off。下一节我们会聊怎么用 Prometheus + Grafana 把这些指标可视化出来，到时候你就能实时看到你的 vLLM 集群到底跑得怎么样了。