# LLM 自回归生成与 KV Cache

> 通用 LLM 原理，与 OpenClaw 代码无关，但解释了 streaming 延迟和 prompt cache 的底层依据。

---

## 自回归生成（Autoregressive Generation）

LLM 每次只生成一个 token，然后把它追加到输入序列末尾，重新跑一遍前向传播，生成下一个 token，循环直到 `<|EOS|>`：

```
输入: [token1, token2, ... tokenN]    →  Transformer  →  tokenN+1
输入: [token1, token2, ... tokenN+1]  →  Transformer  →  tokenN+2
...
```

这就是为什么 LLM 的输出是"流式逐字出现"的——每个 token 生成后立即可以返回给调用方，不需要等全部生成完。

---

## KV Cache

如果每次都把整个序列从头重算，代价随序列长度线性增长。实际上 transformer 每层 attention 会把历史 token 的 Key/Value 矩阵缓存下来，新 token 只需计算自己的 Q 与历史 KV 的 attention，不重算历史。

```
第1步（prefill）：完整计算所有输入 token 的 KV，存入缓存
第2步以后（decode）：只算新 token，复用缓存中的历史 KV
```

**这解释了两个常见现象：**

- **首 token 慢、后续 token 快**：prefill 是全量计算，耗时与输入长度成正比；decode 是增量计算，每步耗时基本固定
- **长 system prompt 影响首 token 延迟**：system prompt 越长，prefill 越慢，但后续 decode 速度不受影响

---

## Prompt Cache（服务端 KV Cache）

Anthropic、OpenAI 等服务商把 KV Cache 做到了服务端——把 system prompt + tools 的 KV 矩阵持久化存储，下次相同前缀的请求直接命中缓存，跳过 prefill 阶段。

**命中条件：前缀必须完全一致（逐 token 匹配）。**

这就是 OpenClaw 里多处保证顺序确定性的原因：
- `src/tools/planner.ts` 的 `buildToolPlan()` 用 `sortKey ?? name` 对 tool 列表排序
- `src/llm/providers/openai-responses-tools.ts` 在 `convertResponsesToolPayload()` 里再次按 name 排序
- Anthropic 的 `cache_control` 打在 tools 数组最后一个 tool 上，标记缓存边界

顺序一旦变化，前缀不匹配，缓存失效，重新 prefill。