What is latency in LLM inference, and why is it important
1️⃣ 考察意图
面试官想考察你对 LLM 推理延迟的精确定义、业务影响以及优化取舍的理解。这并非简单的概念背诵，而是检验你是否能区分“首 token 延迟”和“端到端延迟”这两个核心指标，并理解它们在不同场景（如对话 vs. 离线批处理）下的不同权重。刁钻点在于：你是否能意识到延迟与吞吐量（Throughput）是零和博弈，并给出具体的工程权衡（如动态批处理 vs. 固定批大小）。答好了能展示你从模型部署到用户体验的整条链路工程思维。
2️⃣ 标准答
定义与拆解
LLM 推理延迟通常指从用户输入请求到模型生成完整响应所经历的时间。但必须拆解为两个关键阶段：
- 首 token 延迟（Time to First Token, TTFT）：从请求到达到生成第一个 token 的时间。主要受**预填充（Prefill）**阶段影响，即对输入 prompt 进行并行计算。瓶颈在 GPU 计算能力（FLOPs）和显存带宽。
- 端到端延迟（End-to-End Latency）：从请求到生成最后一个 token 的总时间。主要受**解码（Decoding）**阶段影响，即逐个生成 token 的串行过程。瓶颈在显存带宽（因为需要反复读取 KV Cache）和模型大小。
为什么重要：用户体验与业务指标
- 交互式应用（如 ChatGPT、Copilot）：TTFT 超过 500ms 会明显感觉“卡顿”，端到端延迟超过 2-3 秒会打断用户思维流。研究表明，延迟每增加 100ms，用户满意度下降约 1%。
- 实时系统（如语音助手、自动驾驶）：延迟必须低于 100ms，否则系统无法响应。
- 离线批处理（如数据标注、批量摘要）：延迟不敏感，但吞吐量（每秒处理请求数）是核心指标。此时可以牺牲单请求延迟换取更高吞吐。
影响因素与工程取舍
- 模型大小与架构：7B 模型 vs 70B 模型，延迟差一个数量级。架构上，MHA（Multi-Head Attention） 比 MQA（Multi-Query Attention） 或 GQA（Grouped Query Attention） 延迟更高，因为 KV Cache 更大，显存带宽瓶颈更严重。取舍：MQA/GQA 牺牲少量模型质量换取显著延迟降低。
- 解码策略：贪婪解码（Greedy Decoding）延迟最低，但质量差。束搜索（Beam Search）延迟高（需维护多个候选序列），但质量好。推测解码（Speculative Decoding）通过一个小模型“草稿”大模型“验证”，在保持质量的同时降低延迟，但需要额外部署小模型。
- 批大小（Batch Size）：增大批大小能提升吞吐量（GPU 利用率更高），但会线性增加端到端延迟（因为需要等待整个批次生成完毕）。取舍：动态批处理（Continuous Batching）允许在批次内动态加入/移除请求，在保持低延迟的同时提升吞吐量。vLLM 的核心创新之一就是 PagedAttention + 动态批处理。
- 硬件与优化：使用 FlashAttention 减少显存读写，降低 TTFT。量化（如 INT4/INT8）减少模型大小和显存带宽需求，但可能带来精度损失。KV Cache 量化（如 KIVI）专门优化解码阶段的显存瓶颈。
实际落地的坑 + 解法
- 坑：只优化 TTFT 而忽略端到端延迟。例如，使用大 batch size 做预填充，TTFT 很低，但解码阶段因为 KV Cache 过大导致显存溢出或带宽瓶颈，端到端延迟反而飙升。
- 解法：使用 Splitwise 策略，将预填充和解码阶段部署在不同 GPU 上。预填充阶段用高计算能力 GPU（如 H100），解码阶段用高显存带宽 GPU（如 A100）。或者使用 Chunked Prefill，将长 prompt 分块处理，避免单次预填充占用过多显存。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从定义、业务影响和优化取舍三个层面回答。定义上，延迟分为首 token 延迟（TTFT）和端到端延迟，前者受预填充阶段计算瓶颈影响，后者受解码阶段显存带宽瓶颈影响。业务上，交互式应用对 TTFT 敏感（<500ms），离线批处理更关注吞吐量。优化上，核心取舍是延迟与吞吐量的零和博弈，常用手段包括推测解码、动态批处理和 KV Cache 量化。总结一句：理解延迟必须结合场景，没有‘最优延迟’，只有‘最合适的延迟’。”
4️⃣ 高频追问 & 应对
追问 1：如何测量和监控 LLM 推理延迟？
使用 Prometheus + Grafana 监控栈，在推理服务器（如 vLLM、Triton Inference Server）中暴露指标：TTFT（从请求入队到第一个 token 生成）、ITL（Inter-Token Latency，每个 token 生成时间）、端到端延迟。注意区分 P50、P95、P99 分位数，P99 更能反映尾部延迟。实际坑：监控本身会引入额外延迟，需使用低开销的采样方式（如每 100 个请求采样 1 个）。
追问 2：如果用户要求将延迟降低 50%，你会怎么做？
首先分析瓶颈。如果 TTFT 高，优先做 FlashAttention 和 Chunked Prefill；如果端到端延迟高，优先做 KV Cache 量化（如 INT8）或 推测解码。如果预算允许，升级硬件（如从 A100 到 H100，显存带宽提升 2x）。注意：量化可能带来 1-2% 的精度损失，需要 A/B 测试验证业务指标。最后，如果用户场景允许，可以降低模型大小（如从 70B 降到 13B），但需评估质量下降。
追问 3：延迟和吞吐量如何权衡？给出具体数字。
假设一个 7B 模型，单张 A100-80G。批大小=1 时，TTFT 约 50ms，端到端延迟约 500ms（生成 100 tokens），吞吐量约 2 req/s。批大小=32 时，TTFT 约 200ms（因为预填充计算量增大），端到端延迟约 2s，但吞吐量提升到 16 req/s。取舍点：如果业务要求 P99 延迟 < 1s，则批大小不能超过 8。实际部署时，使用 动态批处理 可以动态调整，在低负载时保持低延迟，高负载时提升吞吐量。
5️⃣ 避坑 · 常见错误答法
- ❌ “延迟就是模型生成答案的时间，越短越好。” → ✅ “延迟必须拆解为 TTFT 和端到端延迟，不同场景关注点不同。对话场景更关注 TTFT，离线批处理更关注端到端延迟。而且延迟不是越低越好，需要与吞吐量、成本做权衡。”
- ❌ “优化延迟就是量化模型。” → ✅ “量化是手段之一，但需要根据瓶颈选择。如果 TTFT 高，优先优化预填充阶段（FlashAttention、Chunked Prefill）；如果端到端延迟高，优先优化解码阶段（KV Cache 量化、推测解码）。量化可能带来精度损失，需要评估。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从检索延迟 vs 生成延迟的权衡切入。例如，检索阶段使用 BM25（低延迟但低召回）还是 DPR（高召回但高延迟），如何通过缓存或预计算优化。
- 如果你只做过传统 NLP：用传统序列模型（如 LSTM）的推理延迟做类比。LSTM 的串行解码瓶颈与 Transformer 的 KV Cache 瓶颈类似，但 Transformer 的预填充阶段是并行计算，这是关键区别。
- 如果你是校招无项目：聚焦 FlashAttention 论文复现 demo。说明如何通过分块计算和重计算降低显存访问，从而降低 TTFT。可以提到自己用 PyTorch 实现了简化版 FlashAttention，并测量了延迟对比。
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness (Dao et al., 2022)
- Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon et al., 2023)
- Speculative Decoding: Fast Generation from Large Language Models via Drafting (Leviathan et al., 2023)
- KIVI: A Tuning-Free Asymmetric 2-bit Quantization for KV Cache (Liu et al., 2024)
- vLLM 官方文档：Performance Tuning Guide