LLM 推理服务性能指标详解
基于 DeepSeek v4 节点监控数据的实战解析
一、核心概念：用餐厅来理解推理服务
把推理服务比作一家餐厅，可以非常直观地理解所有性能指标：
| 餐厅概念 | 推理服务概念 |
|---|---|
| 餐厅桌子 | GPU 资源 |
| 顾客入座 | 请求被处理 |
| 门口排队 | 请求队列（Queue） |
| 正在就餐 | 正在推理（Running） |
| 上第一道菜 | 返回第一个 Token |
| 全程就餐时间 | 端到端延迟（E2E Latency） |
| 厨房操作台 | 显存 / KV Cache |
二、延迟指标
2.1 TTFT（Time To First Token）—— 上第一道菜的时间
从用户发送请求，到收到第一个 Token 的等待时间。
这是用户最直接的"响应感"，TTFT 越低，用户越不会觉得系统卡死。
百分位数（P50 / P95 / P99）解释
百分位数用来描述"不同运气的用户的体验"：
| 指标 | 含义 | 通俗理解 |
|---|---|---|
| P50 | 50% 的请求在此时间内收到第一个 Token | 普通用户的体验（中位数） |
| P95 | 95% 的请求在此时间内收到第一个 Token | 较差情况下的体验 |
| P99 | 99% 的请求在此时间内收到第一个 Token | 最倒霉的 1% 用户的体验 |
示例： TTFT P50=2.5s / P95=20s / P99=40s
每 100 个请求里，有 1 个用户需要盯着空白屏幕等超过 40 秒才能看到第一个字。对用户体验来说，40 秒的空白基本等同于"系统卡死"。
2.2 E2E Latency（End-to-End Request Latency）—— 全程就餐时间
从发送请求到收到完整回复的总时间。
同样用 P50 / P95 / P99 衡量。P99 反映最差用户的体验上限。
示例数据中： E2E P99 最高达到 13.3 分钟，意味着最倒霉的用户等了超过 13 分钟才拿到完整结果。
2.3 Average E2E Latency —— 平均就餐时长
所有请求的端到端延迟均值。
- 反映系统整体负载趋势
- 均值持续上涨，说明系统开始吃力
- 需结合 Queue / Running 数据一起判断根因
三、队列指标
3.1 Queue（排队人数）
在门口等候、尚未被 GPU 处理的请求数量。
- Queue 接近 0 → 请求进来基本立刻能被处理
- Queue 持续高企 → 系统已过载，请求积压严重
3.2 Running（正在就餐人数）
正在被 GPU 推理处理的请求数量。
- Running 数量反映 GPU 的实际并发负载
- Running 高但 Queue 低 → 不是进不来，而是每个请求处理本身就慢
3.3 Queue / Running Ratio（排队比）
排队人数 ÷ 正在处理人数 的比值。
- 比值接近 0 → 系统健康，几乎没有积压
- 偶发尖刺 → 瞬间并发高峰，短暂积压但很快消化
- 持续偏高 → 系统长期过载
四、显存与 KV Cache
4.1 Used Tokens / KV Pressure —— 操作台占用率
推理过程中每个请求都需要在显存中存放 KV Cache（注意力机制的中间结果）。
- KV Pressure 低（如 30%）→ 显存压力不大，不是瓶颈
- KV Pressure 接近 100% → 显存不足，系统开始换页，速度大幅下降
五、吞吐指标
5.1 Prompt Token Rate vs Generation Token Rate —— 备菜速度 vs 出菜速度
推理分为两个阶段，性质完全不同：
| 阶段 | 别名 | 餐厅比喻 | 特点 |
|---|---|---|---|
| Prefill | Prompt Token Rate | 备菜速度 | 输入 Token 全部并行计算，速度极快 |
| Decode | Generation Token Rate | 出菜速度 | 每次只生成一个 Token，必须串行，天然慢 |
典型数据对比：
Prompt Token Rate：~20,000 tok/s（备菜飞快）
Generation Token Rate：~121 tok/s（出菜极慢）
速度差：约 100 倍
这 100 倍的差距不是故障，是大模型的物理特性。Decode 阶段无法并行，是推理延迟的天然瓶颈。
六、为什么不同模型的出菜速度有差异？
对比 DeepSeek v4、GLM、Kimi 三个模型，Generation tok/s 都在几百量级，这是正常的。但仍有差异，原因如下：
6.1 模型体量
- DeepSeek v4 是 MoE 超大模型，激活参数量大
- 每生成一个 Token 消耗的计算量更多，速度自然更低
6.2 部署并行策略的影响
| 并行策略 | 原理 | 对单请求速度的影响 | 对并发的影响 |
|---|---|---|---|
| 数据并行（Data Parallel） | 多卡各跑一份模型，请求分流 | 不加速单个请求 | 提升整体吞吐 |
| 张量并行（Tensor Parallel） | 多卡协同处理同一个请求 | 加速单个请求 | 减少可并发数 |
示例： Kimi-k2.6 使用张量并行，单请求延迟更低；DeepSeek v4 使用数据并行，单请求速度不如张量并行，但整体吞吐更高。两种策略各有取舍。
七、影响"出菜速度"的综合因素
GPU 使用率只是其中一个因素，完整的影响因素如下：
出菜速度 = f(GPU算力, 显存容量, 请求复杂度, 并发数量, 部署策略)
| 因素 | 说明 |
|---|---|
| GPU 算力 | 厨师的能力上限，算力越强越快 |
| 显存（KV Cache） | 操作台大小，不够用时要换页，速度骤降 |
| 输出 Token 数 | 菜品复杂度，输出越长耗时越久 |
| 并发请求数 | 同时开几桌，越多每桌分到的资源越少 |
| 并行策略 | 数据并行 vs 张量并行，影响单请求 vs 整体吞吐的取舍 |
八、实战案例总结
以下是单次 DeepSeek v4 节点的综合诊断结果：
| 指标 | 状态 | 结论 |
|---|---|---|
| KV Cache 压力 | 正常（~30%） | 显存不是瓶颈 |
| Queue 积压 | 基本没有 | 不存在大量排队 |
| Queue/Running Ratio | 接近 0 | 系统健康，偶发尖刺正常 |
| Prompt Token Rate | 高（~20,000 tok/s） | Prefill 阶段正常 |
| Generation Token Rate | 低（~121 tok/s） | Decode 慢，但符合模型特性 |
| E2E P99 | 最高 13.3 分钟 | 高并发时长尾延迟明显 |
根本原因：
不是显存不够、不是请求排队，而是 DeepSeek v4 体量大 + 数据并行策略 导致单请求 Decode 速度有限。高并发时多请求争抢 Decode 算力，长尾延迟显著上升。