大模型推理为什么慢？首 Token 延迟和吞吐怎么优化？
面试怎么回答
推理分两个阶段：Prefill 一次性处理所有输入并生成第一个 Token，输入越长越慢；Decode 逐个生成后续 Token，每步都要读全部 KV Cache，通常受显存带宽限制。所以关注首 Token 延迟和每 Token 延迟。优化首 Token 延迟靠缩短输入、前缀缓存复用稳定前缀的 KV Cache、减少排队和流式输出。优化吞吐靠连续批处理、高效的 KV Cache 显存管理、权重和 KV Cache 量化、推测解码。批次越大吞吐越高但单请求延迟越高，所以在线交互和离线批量分开部署。应用层还可以限制输出长度、简单任务用小模型、能并行的调用并行发出。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
用户抱怨 AI 助手「转圈半天才开始输出」，运维抱怨 GPU 很贵但每秒处理的请求很少。大模型推理的性能，和传统服务完全不同。面试官问这题，想看你是否理解推理过程的两个阶段，以及延迟和吞吐各受什么影响。
推理的两个阶段
- Prefill（预填充）：一次性处理全部输入 Token，计算并缓存它们的中间结果（KV Cache），生成第一个输出 Token。输入越长，这一步越久；
- Decode（解码）：逐个生成后续 Token，每生成一个都要读取全部 KV Cache。这一步通常受显存带宽限制，单个请求很难把 GPU 算力用满。
所以有两个关键延迟指标：
- 首 Token 延迟（TTFT）：用户等多久才看到第一个字，主要由排队时间和 Prefill 决定；
- 每 Token 延迟（TPOT）：后续输出的速度，由 Decode 决定。总耗时 ≈ TTFT + 输出 Token 数 × TPOT。
优化首 Token 延迟
- 缩短输入：精简系统提示、减少无关的检索内容和历史；
- 前缀缓存：相同的前缀（系统提示、工具定义、同一份文档）的 KV Cache 复用，不用重复计算。提示词结构上把稳定内容放前面；
- 减少排队：容量规划、按优先级调度；
- 流式输出：第一个 Token 生成后立即返回，用户感知的等待时间大幅缩短。
优化吞吐
- 批处理：多个请求一起解码，共享模型权重的读取，GPU 利用率大幅提高。连续批处理（continuous batching）让请求可以随时加入和离开批次，而不是等一整批都结束；
- KV Cache 显存管理：显存决定能同时处理多少请求，高效的显存管理（比如分页管理）能装下更多请求；
- 量化：更低精度的权重和 KV Cache，降低显存和带宽压力；
- 推测解码：用一个小模型先猜多个 Token，大模型一次验证，减少大模型的解码步数。
延迟和吞吐的取舍
批次越大吞吐越高，但单个请求的延迟会上升。在线交互场景要保证延迟上限，离线批量任务可以追求最大吞吐。通常把两类流量分到不同的部署上。
应用层能做的
- 输出更短：明确要求简洁的格式，限制最大输出长度；
- 选择合适大小的模型：简单任务用小模型；
- 能并行的调用并行发出，减少串行等待。