考察点
这道题考的是你有没有真正运营过一个在线推理服务。面试官想听的不是定义背诵，而是指标之间的牵制关系：batch size 调大吞吐上去了，延迟怎么变、哪个阶段先恶化；不同业务（聊天、批处理、实时翻译）该优先保哪个指标。追问常落在 decode 阶段为什么加大 batch 几乎"免费"、SLO 怎么定、以及怎么压测。
参考答案
先把指标定义清楚
一个 LLM 请求的耗时天然分两段，所以延迟也要拆开看：
- TTFT（Time To First Token）：从请求发出到收到第一个 token 的时间，主要包括排队 + prefill。它决定用户"等了多久开始有反应"，是流式对话体验的第一指标。
- TPOT（Time Per Output Token）：首 token 之后，相邻两个 token 的平均间隔，也叫 ITL（Inter-Token Latency）。它决定流式输出"流得顺不顺"，一般要求低于人的阅读速度（每秒 10-20 token 对应的 50-100ms）。
- 端到端延迟 ≈ TTFT + TPOT × 生成长度。
- 吞吐：单位时间系统处理的 token 数，常用 output tokens/s（全实例合计）或 requests/s。换算成成本就是每百万 token 多少钱。
核心 trade-off：batch size 这个旋钮
Decode 阶段是 memory-bound：每步都要把全部权重从 HBM 搬一遍，batch=1 和 batch=32 搬的权重一样多，多出来的请求几乎白捡——所以加大 batch，吞吐近似线性涨，单请求 TPOT 却涨得很少，这是 LLM 服务和传统 web 服务很不一样的地方，直到 batch 大到把算力打满（进入 compute-bound 区间）后 TPOT 才开始明显劣化。
但 batch 不是白来的，有三条约束：
- 显存：batch 大意味着同时驻留的 KV Cache 多，显存上限直接封顶 batch。
- TTFT：凑 batch 要等请求，且大批量的 prefill 会挤占 decode 的资源。一个长 prompt 进来做 prefill，正在 decode 的请求那几步 TPOT 会抖（这就是 chunked prefill 要解决的问题）。
- 尾延迟：动态 batching 的等待窗口让 P99 变难看。
工程上的做法是先定 SLO 再调参：比如聊天业务定 TTFT P95 < 2s、TPOT P95 < 80ms，然后在满足 SLO 的前提下把 batch 推到显存极限换吞吐；离线批处理（数据清洗、批量打标）则反过来，延迟无所谓，batch 拉满榨干算力。
不同业务的取舍
| 业务 | 优先保 | 策略 |
|---|---|---|
| 在线对话/客服 | TTFT + TPOT | 限 batch 上限、流式输出、prefix caching |
| 代码补全 | TTFT 极致 | 小模型、投机采样、预留余量防排队 |
| 离线批处理 | 吞吐 | batch 拉满、可用量化换容量 |
| 长文摘要 | TTFT | chunked prefill、PD 分离 |
压测和观测
上线前用真实流量分布压测：prompt 长度、生成长度、到达率三个维度都要贴近生产，别拿固定长度打匀速流量自欺欺人。观测上要分位看（P50/P95/P99），平均延迟会掩盖排队雪崩；同时盯 GPU 利用率、KV Cache 占用率、排队长度这三个内部指标，它们比延迟更早预示容量见顶。
可能的追问
- 为什么 decode 加大 batch 吞吐近似线性？ decode 每步算力需求小，瓶颈在搬权重和读 KV，权重被整批共享，多塞请求只多读各自的 KV Cache，算力远没打满，所以边际成本低。
- TTFT 高怎么单独优化？ 排队占大头就扩容量或限制并发；prefill 本身慢就用 prefix caching 复用公共前缀、chunked prefill 减少队头阻塞、PD 分离把 prefill 挪到专门的实例。
- TPOT 劣化从哪个 batch 开始，怎么找拐点？ 打满算力为止。实测：固定输入逐步加并发画吞吐-延迟曲线，吞吐不再线性增长、TPOT 开始上翘的点就是拐点，生产 batch 上限定在拐点之前留 20% 左右余量。