Apple AIML：LLM Decoding 加速先看 TTFT 与每 Token 延迟

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 以自回归 Transformer 推理服务为训练场景，先分别测 TTFT、inter-token latency、吞吐、P95 和显存；题目没有指定目标。
• 不同优化改变不同瓶颈：prefill 并行计算、decode 逐 token 串行依赖、KV cache 容量与批量调度不可混说成单一‘速度’。

解题路线

1. 先 profile：prefill 吞长 prompt 时可能是计算/IO 密集；decode 每生成一 token 读模型权重和既有 KV，常受内存带宽/批量大小影响。用请求长度分布和硬件计数确认，而非先套技术名。
2. KV cache 保存历史 token 的 K/V，避免每步重复计算旧前缀；内存随层数、KV 头数、头维、精度、并发和上下文长度增长，易限制并发。
3. 动态/连续 batching 利用多个请求的 decode 步复用硬件吞吐，代价是调度和排队；优先级、公平性与 deadline 防止长请求拖累短请求。
4. FlashAttention 通过 tile/IO-aware 算法减少 attention 的 HBM 数据搬运，尤其对长序列 prefill 有用；它不是替代 KV cache 的请求级调度。
5. 推测解码让较小 draft 模型提出多个 token、目标模型并行验证；接受率和验证成本决定收益，必须遵守相应算法的分布正确性条件。每次实验保持相同质量/采样设置，比较 TTFT、TPOT、吞吐、显存和输出差异。

手动走一遍

两个用户的长 prompt 同时进入：优化 prefill 核可缩短首 token；进入 decode 后连续 batching 可提高 GPU 利用率；若上下文很长且并发高，KV cache 可能先占满显存，此时只提高计算速度也接不了更多请求。

规模与取舍

朴素全注意力 prefill 的 score 规模随序列长度 L 二次增长；逐 token decode 仍需处理与现有上下文相关的 K/V，KV 缓存容量约正比于并发×层数×序列长度×KV 维度。实际时延由内核、硬件、批量与模型决定。

易错点与追问

容易失分的边界

• 只报 tokens/s，不区分 TTFT 和每 token 延迟。
• 说 KV cache 能消除长上下文的全部 attention 计算。
• 把 FlashAttention、PagedAttention 与 speculative decoding 说成同一种算法。
• 更大 batch 虽提吞吐却使单请求排队变差，未看 P95。
• 忽略推测解码的接受率和分布保证。

继续深挖

• prefill 与 decode 的主要资源瓶颈为何不同？
• KV cache 容量如何从层数、头数和上下文长度估算？
• 低接受率时 speculative decoding 为何可能变慢？
• 线上应怎样在吞吐与 P95 延迟之间调度？