DeepSeek 推理服务压测指南：用 vLLM Benchmark 测吞吐与尾延迟

模型基准回答“会不会做题”，服务压测回答“在真实并发下多久能开始回答、多久生成完、每秒能处理多少 Token”。对本地部署的 DeepSeek 蒸馏模型或兼容端点，二者必须分开评估。

一、先确认接口和模型名

vLLM 可以提供 OpenAI 兼容的 /v1/chat/completions。压测客户端发送的模型名必须与服务暴露的名称一致，聊天模型还需要有效的 chat template。

curl http://127.0.0.1:8000/v1/models

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model deepseek-r1-distill \
  --dataset-name random \
  --num-prompts 100 \
  --save-result \
  --save-detailed

不同 vLLM 版本的参数会变化，运行前应以本机 vllm bench serve --help 为准。

二、四个核心指标

• TTFT：从请求发出到首个 Token 的时间，直接影响交互等待感。
• TPOT：首 Token 之后每个输出 Token 的平均时间。
• 请求吞吐：单位时间完成的请求数。
• Token 吞吐：单位时间处理的输入与输出 Token 数。

只报告平均值会掩盖排队。生产评估至少同时展示 P50、P95 和 P99，尤其关注 TTFT 与端到端延迟的尾部。

三、不要只用随机短 Prompt

随机数据适合建立硬件基线，但与真实业务差距很大。应按线上日志脱敏构造短问答、长文档、代码和多轮对话四组流量，并固定输入、输出长度分布。推理模型还需单独统计 reasoning Token 带来的长尾。

四、寻找并发拐点

1. 从低请求率开始，记录 GPU 利用率、显存和延迟。
2. 逐步提高 request rate 或最大并发。
3. 当吞吐增长变慢、P99 急剧上升时，记录饱和点。
4. 超过错误率或延迟预算的结果不应算作可用容量。

五、保证不同方案可比

比较量化方式、张量并行或不同推理引擎时，应固定模型权重、Prompt 集合、输出上限、并发曲线和停止条件。同时记录 GPU、驱动、CUDA、vLLM commit、缓存冷热状态以及服务端参数。

最大 Token/s 不是生产容量。满足延迟目标、错误率目标和输出完整性的吞吐，才是可承诺的服务能力。