很多人在使用 LLM 时有个直觉：对话越长 token 越贵，应该尽早做摘要压缩 history。在构建 Agent Loop 时，也有人把多轮对话合并成一条”无状态消息”来省 token。这两种做法看似聪明，实际上都是反优化。本文从 KV Cache 原理出发，解释为什么保持原始 history 不动才是最优策略。
最常见的误区：主动做摘要压缩 History
场景
你和 LLM 聊了 20 轮，context window 用了 8K/128K。你开始焦虑：”这么长的 history，每次请求都要发过去，太浪费 token 了吧？”
于是你做了一个”优化”：让 LLM 把前面的对话总结成一段摘要，然后用摘要开启新对话。
原始对话（20轮，8000 token）:
[system] [user_1] [asst_1] [user_2] [asst_2] ... [user_20] [asst_20]
"优化"后（摘要，500 token）:
[system] [user: 以下是之前对话的摘要：...500字...] [user_21]
看起来输入从 8000 token 减少到了 600 token，省了 93%？
为什么这是反优化
1. 你摧毁了 KV Cache
原始对话中，前 19 轮的 KV 在上次请求时已经算好并缓存在 GPU 显存中。第 21 轮请求到来时：
原始方式:
[system][user_1][asst_1]...[user_20][asst_20] ← 全部 cache 命中(0计算)
[user_21] ← 只算这一条(几十token)
摘要方式:
[system][摘要...500 token][user_21] ← 全新内容，全部重算(550 token)
原始方式实际只需计算几十个 token（新消息），摘要方式反而要计算 550 个 token。你为了”省 token”，制造了十倍的计算开销。
2. 摘要本身就是额外开销
做摘要时，虽然之前的 8000 token 被 cache 覆盖（计算开销小），但你仍然需要 LLM 生成 500 token 的摘要输出。更关键的是，这 500 token 的摘要在新对话中会作为全新 input 再被完整计算一次（没有任何 cache）。相当于你为了”省 token”，先花 500 token 生成摘要，再花 500 token 重新计算摘要——净增了开销。
3. 信息不可逆丢失
摘要时你无法预判后续对话需要哪些细节。LLM 可能在第 30 轮需要第 3 轮的某个具体参数，但摘要时已经丢了。
正确的心智模型
已有的 history = 免费的（被 KV Cache 覆盖，0 计算开销）
只有新增的尾部 = 实际计算开销
打个比方：你在看一本 200 页的书，已经看到第 180 页。每次翻新一页只需要读 1 页内容。如果你这时候把前 180 页撕掉，写了一页摘要，然后声称”我只需要读 1 页摘要就够了”——但你本来就只需要读 1 页新内容啊！撕书这个操作本身还浪费了时间。
什么时候才应该做摘要？
只有当你真的快撞到 context window 上限时。 比如 128K 的窗口已经用了 120K，再加新消息就溢出了——这时候别无选择，必须压缩。
但在此之前（比如只用了 10%~50%），保持原始 history 不动就是最优策略。不要和 KV Cache 作对。
对 API 计费的影响
你可能想说：”即使 cache 命中，API 提供商不还是按 input token 数收费吗？”
事实上，主流厂商都已经对 cached token 提供大幅折扣（远不止半价）：
国内厂商的缓存折扣通常更激进，尤其是 DeepSeek 系（cached token 价格低至 new token 的 1/10 甚至更低）。
这意味着： 在 API 计费层面，保持原始 history 不动同样是经济的。假设你有 8000 token 的 history：
- 保持原样：8000 × cached 价格（1~2.5 折）+ 新消息 × 全价
- 做摘要替换：500 × 全价（摘要是新内容，无 cache）+ 新消息 × 全价 + 摘要生成的输出费用
表面上 8000 → 500 看似省了，但 8000 token 按 1 折计算 = 等效 800 token 全价。加上摘要输出费用和信息丢失，收益微乎其微甚至为负。
对于 自部署模型（vLLM/TGI）：没有按 token 计费，开销纯粹取决于 GPU 计算量。此时保持原始 history 的优势是压倒性的——cache 命中 = 零额外计算。
Agentic Loop 中的同类问题
上述误区在 Agent Loop 设计中有一个变体：把多轮工具调用历史合并成一条”无状态消息”来”省 token”。接下来用一个具体例子分析这种做法。
背景
在 Agentic RAG 的迭代搜索场景中，Agent 每轮调用 LLM 决定下一步操作（搜索、丢弃、结束）。LLM 需要知道：
- 用户的原始问题
- 之前执行了哪些工具调用
- 当前收集到了哪些 evidence
问题来了：怎么把这些信息传给 LLM？ 这本质上和上面”要不要压缩 history”是同一个问题。
两种方式
方式 A：全量合并（Stateless Merge）
每次调用 LLM 时，把所有历史压缩成一两条 user 消息：
def build_messages():
msgs = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": query},
]
# 全部 trace 合成一条文本
msgs.append({"role": "user", "content": f"[已执行的工具调用]\n{trace_text}"})
# 全部 evidence 合成一条 JSON
msgs.append({"role": "user", "content": f"[当前 evidence]\n{evidence_json}"})
return msgs
动机：看起来消息少、结构简单，且省掉了历史中 LLM 的 assistant 回复（可能包含冗长的 thinking/reasoning），直觉上能省 token。
方式 B：标准多轮对话（Stateful Messages）
保持完整的对话结构，每轮追加 assistant tool_call + tool result：
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": query},
]
for each iteration:
response = llm.chat(messages, tools=...)
messages.append(response.message) # assistant with tool_calls
result = execute_tool(response.tool_call)
messages.append({"role": "tool", "content": result, "tool_call_id": ...})
用一个例子说清楚
假设 Agent 跑了 3 轮，每轮工具返回约 500 token 的 evidence，LLM 每轮 reasoning 约 200 token。
第 1 轮: system(100) + user(50) = 150
第 2 轮: system(100) + user(50) + trace(30) + evidence(500) = 680
第 3 轮: system(100) + user(50) + trace(60) + evidence(1000) = 1210
总 input = 2040
每次都是全新内容 → KV Cache 命中率 ≈ 0% → 2040 token 全部需要 GPU 从头计算。
第 1 轮: system(100) + user(50) = 150
第 2 轮: system(100) + user(50) + asst_1(200) + tool_1(500) = 850
第 3 轮: system(100) + user(50) + asst_1(200) + tool_1(500)
+ asst_2(200) + tool_2(500) = 1550
总 input = 2550
多了 assistant 消息（+400 token），但关键区别：
- 第 2 轮的前 150 token 与第 1 轮完全相同 → cache 命中
- 第 3 轮的前 850 token 与第 2 轮完全相同 → cache 命中
实际需要计算的 token：
第 1 轮: 150（全算）
第 2 轮: 700（前 150 命中 cache，只算新增 700）
第 3 轮: 700（前 850 命中 cache，只算新增 700）
实际计算量 = 1550
对比表
| 指标 |
方式 A（全量合并） |
方式 B（标准多轮） |
| 总 input token 数 |
2040 |
2550 |
| KV Cache 命中 |
0% |
~60% |
| 实际 GPU 计算量 |
2040 |
1550 |
| LLM 理解难度 |
较高（非标准格式） |
低（原生训练格式） |
结论：方式 A 看似 token 少，实际计算量更大。
深入理解：Prefill、Decode 与 KV Cache
LLM 推理的两个阶段
你一定注意过：LLM 收到输入后，吐出第一个 token 比较慢，后续 token 则刷刷刷很快。这正是两个阶段的体现：
1. Prefill（预填充）：处理所有 input token，为每个 token 在每一层 Transformer 计算出 Key 和 Value 向量，存入 KV Cache。这是计算密集型的——需要对 N 个 token 做全量 attention 矩阵运算，复杂度 O(N²)。
2. Decode（解码）：逐个生成 output token。每生成一个新 token，只需要用它的 Query 去和 KV Cache 中已有的 Key 做 attention，复杂度 O(N)。然后把新 token 的 K、V 追加到 cache 中，为下一个 token 服务。
打个比方：
– Prefill = 读完一整本书，做好笔记（耗时，对应 TTFT 慢）
– Decode = 根据笔记逐句写答案（相对轻松，对应后续 token 快）
所以你感受到的”先卡一下，然后刷刷刷出来”就是 Prefill → Decode 的分界。
什么是 KV Cache？
Transformer 每一层的 Self-Attention 计算：
Attention(Q, K, V) = softmax(Q × K^T / √d) × V
对于一个有 32 层、每层 Key 维度 128、共 32 个 attention head 的模型（类似 LLaMA-7B），处理 1000 个 token 的 KV Cache 大小：
32层 × 2(K和V) × 32头 × 1000 token × 128维 × 2字节(fp16)
≈ 512 MB
这些 K、V 向量一旦算好，在 Decode 阶段生成后续 token 时可以反复复用——不需要对历史 token 重新计算，这就是 KV Cache 的核心价值。
Decode 阶段：每次只算一个 token
Decode 时每步永远只计算 1 个新 token 的 Q/K/V。新 token 的 KV 直接追加到 cache 的下一个 slot：
Block5 (容量16):
slot 0: token_a 的 KV ← 已算好
slot 1: token_b 的 KV ← 已算好
slot 2: token_c 的 KV ← 新 token，只算这一个，写入这里
slot 3~15: 空
Block 是 KV Cache 存储管理的单位（类似内存分页），不是计算单位。一个 block 没填满时，新 token 的 KV 直接写入同一 block 的下一个 slot，不影响已有的值，也不需要重算整个 block。
跨请求的 Prefix Caching
关键洞察：如果两次请求共享相同的前缀，那么前缀部分的 KV 向量完全一样，不需要重算。
举例：Agent Loop 中的标准多轮对话
假设 system prompt = “你是搜索助手”，用户问题 = “什么是 GraphRAG？”
第 1 轮请求：
[system: 你是搜索助手] [user: 什么是GraphRAG？]
←────────── 150 token ───────────→
Prefill 计算 150 个 token 的 KV → 存入 cache，key = hash(“你是搜索助手|什么是GraphRAG？”)
LLM 返回：调用 search({“query”: “GraphRAG”})
第 2 轮请求：
[system: 你是搜索助手] [user: 什么是GraphRAG？] [asst: search(...)] [tool: 结果A]
←──── 和第1轮完全相同 ────→ ←────── 新增 700 token ──────→
←────────────────────── 850 token ──────────────────────────→
推理引擎发现：前 150 token 的 hash 和之前缓存的匹配！
已缓存: token 1~150 的 KV（直接复用，0 计算）
需计算: token 151~850 的 KV（只算新增的 700 token）
第 3 轮请求：
[同上 850 token] [asst: search(...)] [tool: 结果B]
←─ cache 命中 ─→ ←── 新增 700 ──→
cache 命中 850 token，只需计算 700 token。
如果用全量合并方式
第 2 轮请求：
[system: 你是搜索助手] [user: 什么是GraphRAG？] [user: [已执行工具]\n search→5条] [user: [evidence]\n{...500字...}]
←──── 和第1轮相同 ────→ ←─────────── 全新内容 ───────────────→
前 150 token 匹配，后面 530 token 是新内容。
第 3 轮请求：
[system: 你是搜索助手] [user: 什么是GraphRAG？] [user: [已执行工具]\n search→5条\n search→3条] [user: [evidence]\n{...1000字...}]
←──── 和第1轮相同 ────→ ←───────── 内容变了！─────────────────→
第 3 个消息的内容从 "search→5条" 变成了 "search→5条\n search→3条"——从这里开始 cache 全部失效：
cache 命中: 150 token（只有 system + user query）
需要计算: 1060 token
对比方式 B 同一轮只需计算 700 token。差距随着迭代轮数增加越来越大。
前缀匹配的严格顺序性
Prefix caching 是从头逐块顺序匹配的。原因是 attention 机制中的 positional encoding——同一个 token 出现在位置 0 和位置 16，其 KV 值是不同的。
这意味着：如果在开头插入了新 token，整个 cache 失效，全部重算。
缓存中: [block0][block1][block2][block3][block4]
新请求: [new_block][block0'][block1'][block2'][block5][block6]
✗ → 第一个块就不匹配，后面即使内容相同也无法复用
不可能跳过前面去匹配后面——位置变了，KV 值就变了。
这也解释了为什么 system prompt 放在最前面是有利的——它是所有请求共享的固定前缀，保证了开头部分的 cache 始终命中。
Prefix Caching 的实现机制（vLLM）
- 分块哈希：将 token 序列按固定大小（如 16 token）分块，对每块内容计算 hash
- 逐块匹配：新请求到来时，从头逐块比对 hash，找到最长匹配前缀
- 复用 KV Block：匹配的块直接引用已缓存的 GPU 显存中的 KV 数据
- 只计算尾部：从第一个不匹配的块开始做 prefill
已缓存的请求: [block0][block1][block2][block3][block4]
新请求: [block0][block1][block2][block5][block6]
✓ ✓ ✓ ✗ → 从这里开始计算
可视化对比
方式 B（标准多轮）—— 每轮只计算尾部新增部分
第1轮: [████████] 计算 150
第2轮: [--------][██████████████] 计算 700 (前150 cache命中)
第3轮: [--------------------][████] 计算 700 (前850 cache命中)
总计算量 = 1550
方式 A（全量合并）—— 每轮从第3条消息开始就变了
第1轮: [████████] 计算 150
第2轮: [--------][██████████████] 计算 530 (前150 cache命中)
第3轮: [--------][████████████████] 计算 1060 (前150 cache命中,后面全变了)
总计算量 = 1740
随着轮数增加，方式 A 的劣势加速放大。
方式 A 还有哪些隐藏代价？
1. 模型理解能力下降
LLM 在训练时见到的 tool use 格式是：
assistant: I'll search for... [tool_call: search({query: "..."})]
tool: [results...]
assistant: Based on results, I'll now... [tool_call: ...]
你用纯文本模拟这个过程：
user: [已执行的工具调用]
[0] search({"query": "..."}) → 5 results
[1] search({"query": "..."}) → 3 results
模型需要额外的”认知开销”来理解这种非标准格式，可能导致：
– 重复调用已执行的工具（因为结构不如原生格式清晰）
– 无法正确判断哪些信息来自工具、哪些来自用户
2. 无法表达工具失败
标准方式中，工具失败可以明确返回：
{"role": "tool", "content": "Error: timeout after 10s", "tool_call_id": "..."}
LLM 看到后会调整策略。方式 A 中只能写 → 0 results，LLM 分不清”没搜到”和”搜索出错了”。
标准格式支持一次返回多个 tool_calls，推理引擎知道它们是同一轮的并行调用。方式 A 的扁平 trace 文本无法表达这种结构。
什么时候方式 A 有优势？
公平地说，存在少数场景方式 A 更合理：
- 推理引擎不支持 prefix caching（少见，主流引擎都支持）
- 每轮 assistant reasoning 极长（如 DeepSeek 的 thinking 动辄 2000+ token），且你确定这些 reasoning 对后续决策无帮助
- 需要跨 session 恢复——无状态设计允许从任意中间状态恢复，不依赖完整对话历史
对于第 2 点，更好的做法是：保持标准多轮格式，但在追加历史 assistant 消息时截断 reasoning 部分，只保留 tool_call 结构。这样既省 token 又保留 cache 和格式优势。
推荐做法
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": query},
]
for i in range(max_iterations):
response = await llm.chat.completions.create(
model=model, messages=messages, tools=tools_schema
)
assistant_msg = response.choices[0].message
if not assistant_msg.tool_calls:
break
# 追加 assistant 消息（可选：截断 reasoning 以省 token）
messages.append(assistant_msg.model_dump())
# 执行工具并追加结果
for tool_call in assistant_msg.tool_calls:
result = await execute(tool_call)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(result, ensure_ascii=False),
})
简洁、标准、cache 友好。
总结
|
全量合并 |
标准多轮 |
| Token 数量 |
略少 |
略多 |
| 实际推理开销 |
更大（无 cache） |
更小（cache 命中高） |
| 模型理解准确度 |
较差 |
好（原生格式） |
| 工程复杂度 |
需手动序列化 |
框架原生支持 |
| 可观测性 |
差（丢失结构） |
好（每轮清晰） |
不要为了省几百 token 而放弃 KV Cache 和原生格式带来的巨大优势。 表面上的”优化”实际上是反优化——就像为了省内存而关掉 CPU cache，得不偿失。
一句话总结
已有的 history 是免费的，新增的内容才是开销。别主动摧毁 cache。