大模型是怎么生成下一个字的？自回归生成和 KV Cache 是什么关系？

我要答我要考

Q1-02生成机制中常见自回归KV CacheprefilldecodeTTFT

谁在问：二面·有算法背景的面试官；推理服务 / 平台组

口语化问法

你从 API 层往下说说，模型收到你的 prompt 之后，一个字一个字是怎么吐出来的？
KV Cache 是干嘛的？没有它会怎么样？
为什么流式接口第一个字总是最慢，后面反而唰唰的？

考察意图

判断你是不是只会调 API。具体看两点：能不能说清一次生成分 prefill 和 decode 两个阶段、且两个阶段的瓶颈完全不同；能不能把这套机制和你在应用层观测到的现象（首 token 延迟、吐字速度、并发上限、显存占用）对上号。

这题答透的人，后面聊部署、成本、流式、缓存都能接得住；答不透的，基本可以判定所有工程侧问题都会是背的。

参考答案

图 2 · 60 分与 90 分差在哪：代价、演进、怎么验证

60 分答案（及格线）

模型是自回归生成：每次只预测下一个 token 的概率分布，采样出一个 token，把它拼到序列末尾，再预测下一个，直到遇到停止条件。

因为每一步都要重新看全部前文，如果每次都从头算一遍，代价会非常高。KV Cache 就是把前文每一层算出来的 Key 和 Value 存下来，新 token 只需要算自己这一列，再和缓存里的 K/V 做注意力，从而避免重复计算。

90 分答案（有生产经验的回答）

在上面基础上加三层：

第一，分两个阶段，瓶颈完全不同。 prefill 把整段输入并行算完、产出全部 K/V，这一段是算力密集，决定首 token 延迟（TTFT）；decode 一次只算一个 token，但每一步都要把整个 KV Cache 读一遍，是显存带宽密集，决定吐字速度。这就解释了「第一个字慢、后面快」，也解释了为什么批处理对 decode 阶段的吞吐提升特别明显——多个请求可以摊薄同一次权重读取。

第二，KV Cache 是一次成本转移，不是白捡的。 它把每步的注意力代价从「重算全部前文」降到「只算新的一列」，代价转移到了显存：大小随序列长度线性增长，还要乘并发数。所以长上下文服务的真正瓶颈往往不是算力，是显存装不下多少并发。这也是为什么 GQA/MQA、KV Cache 量化、PagedAttention 这些方向都在压同一个数。

第三，应用层的 prompt 缓存本质上是同一个机制的产品化。 服务端把某个前缀的 K/V 留住，下次同样前缀直接复用，省掉 prefill。但作为产品它多了一堆契约：有效期、最小可缓存长度、缓存断点位置、前缀完全一致才命中。所以不能默认「我开了缓存就一定省了」，要看返回里的命中字段（详见 Q1-14）。

追问链

图 1 · 五层追问树：面试官会往哪儿挖

不问机制本身，问「这套机制对应线上哪个数」

没有 KV Cache 会怎样？复杂度差多少？
期望每生成一个 token 都要对整段序列重算注意力，总代价从大致线性累加变成对序列长度的平方级重复，表现是生成越长越慢、慢得不成比例；关键是省掉的是重复计算不是首次计算 —— prefill 那一次省不掉
信号主动指出「prefill 省不掉」→ 真理解机制；说成「缓存了答案下次直接返回」→ 完全没理解
KV Cache 占多少显存？怎么估？
期望量级正比于 2（K 和 V）× 层数 × KV 头数 × 头维度 × 序列长度 × 精度字节，再乘并发数；加分是知道 GQA/MQA 靠减 KV 头数压这个量、知道 KV Cache 量化的存在
信号写得出这条乘法链并强调「并发是乘数」→ 做过容量规划；只说「很占显存」→ 听说过
prefill 和 decode 瓶颈不同，这对你的应用意味着什么？
期望TTFT 由输入长度和是否命中缓存决定，吐字速度由显存带宽与并发决定 → 优化方向分开：降 TTFT 就缩短或缓存前缀，提吞吐就上批处理、缩短输出、拆并行；加分是指出「长输入短输出」与「短输入长输出」是两类负载，不能共用一套容量模型
信号把用户口中的「慢」拆成 TTFT 和吐字速度两个可分别归因的指标 → 有线上经验的明确标志
应用层的 prompt 缓存和这里的 KV Cache 是一回事吗？
期望底层同源（复用前缀 K/V、省掉 prefill），但作为产品多了契约：TTL、最小长度门槛、断点位置、前缀必须完全一致，且被缓存的部分仍然占上下文窗口；所以要拿返回里的缓存读写字段去验证，不能假设
信号说得出「看 cache read / cache creation 这类字段验证」→ 一定亲手调过
流式接口 TTFT 从 800ms 涨到 3s，QPS 没变、吐字速度也没变，只有首字慢，怎么定位？
期望① 用现象缩范围：只有 prefill 慢就排除带宽与并发，只剩「输入变长」「缓存不命中」 → ② 查前缀一致性：时间戳、会话 ID、工具定义乱序、JSON 键顺序不稳、系统提示词被改、检索上下文变长、effort/思考配置被调（渲染进 prompt 一改就废缓存） → ③ 最后看基础设施：排队、调度、供应商波动；④ 看缓存命中字段和输入 token 分布
信号顺序是「现象缩范围 → 查一致性 → 查基础设施」、举得出两个「看着没改其实改了前缀」的元凶 → 强；答「加机器」→ 差

只会说「Transformer 就是预测下一个词」的，第 1 层就见底。第 3 层是转折点 —— 从这里起必须把机制换算成 TTFT 与吐字速度两个可归因指标；第 5 层考排查顺序。

评分要点

说清自回归：一次一个 token，输出回灌成输入
说清 KV Cache 省的是重复计算，代价是显存
能区分 prefill 与 decode 两个阶段及其不同瓶颈
能把机制对应到 TTFT / 吐字速度两个可观测指标
知道 KV Cache 显存估算要乘并发
知道应用层 prompt 缓存与之同源但多了产品契约
排障时先用现象缩范围，再查前缀一致性

常见错误

把 KV Cache 说成「把回答缓存起来，下次直接返回」。

认为有了 KV Cache，生成就不再受序列长度影响。

只会说「Transformer 就是预测下一个词」，再往下一层就说不出东西。

把 TTFT 慢和吞吐低当成同一个问题，一律回答「加机器」。

谈显存只会说「要看模型多大」，不知道 KV Cache 是随请求变化的那一部分。

含糊标志词：「底层它会自动优化」「框架都封装好了」「大概就是缓存了中间结果吧」。