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 不是生产容量。满足延迟目标、错误率目标和输出完整性的吞吐，才是可承诺的服务能力。

10 月 22 日：DeepInfer 的评测与性能口径

DeepInfer 将离线能力评测的生成与评分分开，性能示例另有预填充和解码测量。准确率、总吞吐、单用户速度与首 Token 时间应分开报告，不用单一分数概括服务能力。

其示例说明中的 decode 吞吐存在按草稿全部接受计算的统计口径，比较时还需核对接受率、上下文、缓存和并行条件。Profiler 轨迹带有额外开销，不能把轨迹耗时直接代入稳态吞吐。

保存原始配置与测量窗口，避免把不同硬件、设备数量或缓存比例的曲线直接相除。能力协议见DeepInfer 离线评测教程。

10 月 25 日：读懂新报告的吞吐分母

vLLM 新报告的端到端吞吐包含缓存输入、未缓存输入和输出 Token，不能直接当作生成 Token/s。比较时把缓存命中率、请求分布和用户输出速度放在同一记录中。

其 DeepInfer 预填充对照采用不同硬件与配置，原文明确不将曲线差距解读为引擎加速比。按相同负载与延迟目标记录自己的结果，再决定是否扩容或调整并行设置；报道见vLLM 服务工程解读。