KV Cache：多轮对话的隐性账单

一个 Agent 的单次任务往往要发十几轮请求，每一轮都带着前面所有轮次的完整历史。如果服务端每次都从头算一遍，你付的钱里有一大半是重复劳动。KV Cache 把这份重复劳动变成缓存命中，而命中率取决于一个平时根本不会被注意的细节：前缀稳定性。

编辑部注 · 本章是全站最重要的成本一章。读完后请务必把「前缀稳定性破坏点清单」写进你自己的笔记。

先看一个真实的账单形态。同一个 Agent 任务，第一轮请求 2,000 token 的输入，第二轮变成 2,400，第三轮 2,800……输入长度线性增长，而如果每一轮都要从头算一遍全部前缀，总成本就会呈平方级增长。这不是假设，这是绝大多数「感觉 Agent 很贵」的真实原因。

一、重复计算发生在哪

生成式模型是自回归（Autoregressive）的：生成第 t 个 token 时，需要前面所有 token 的信息。而在 Transformer 里，每一层的信息都浓缩成两个张量——K（键）和 V（值）。

关键点在于：这两个张量只依赖已经出现过的前缀，与后面要生成什么完全无关。

所以第 2 轮请求里，那 2,000 个 token 的历史算出来的 K/V，和第 1 轮里算出来的完全一样。既然一样，就没有理由重算。把每一层的 K/V 存下来，下一轮直接复用，这就是 KV Cache。

二、前缀稳定性：被忽略的成本开关

KV Cache 是按前缀逐位比对（Prefix Stability）命中的。从序列的第一个 token 开始，一旦某一位不同，其后全部失效。这个机制带来一个反直觉但极其重要的结论：

在中间插入内容，比在末尾追加内容昂贵得多。

常见的「插在中间」的操作，在工程里几乎随处可见：

三、显存估算：缓存的代价

缓存不是免费的，它要占相当可观的KV Cache 显存（KV Cache Footprint）。估算公式不长，记住它就能在面试里立刻给出数量级。

def kv_cache_bytes(
    batch: int,        # 并发请求数
    seq_len: int,      # 序列长度（含历史）
    n_layers: int,     # 层数
    n_kv_heads: int,   # K/V 头数（注意：不一定等于注意力头数）
    head_dim: int,     # 每个头的维度
    bytes_per_num: int = 2,   # fp16=2, fp8=1
) -> int:
    # 每层缓存 K 和 V 两份，所以乘 2
    return 2 * batch * seq_len * n_layers * n_kv_heads * head_dim * bytes_per_num
# 一个典型的 70B 级模型（GQA，kv_heads 远少于 query_heads）
total = kv_cache_bytes(
    batch=32, seq_len=32_000, n_layers=80, n_kv_heads=8, head_dim=128
)
print(f"{total / 1024**3:.1f} GiB")   # 大约 312 GiB —— 仅缓存，不含权重
# 关键观察：这个数是随 seq_len 线性长的
for s in (8_000, 32_000, 128_000):
    n = kv_cache_bytes(32, s, 80, 8, 128)
    print(f"seq_len={s:>7}: {n/1024**3:6.1f} GiB")

三点必须记住：

1. KV Cache 显存随序列长度线性增长，与注意力的算力平方增长不是同一回事。算力是平方问题，显存是线性问题——两者要分开讲。
2. GQA（Grouped-Query Attention） / MQA（Multi-Query Attention） 的工程意义就在这里：把 K/V 头数（n_kv_heads） 从 h 降到 h/8 甚至 1，每个头的 维度（head_dim） 不变，缓存直接缩小同样倍数。这是长上下文能跑起来的关键手段之一。
3. 缓存有淘汰策略（Cache Eviction）。服务端不会让你无限占显存，通常按 LRU 或分页（PagedAttention）管理。这意味着你的前缀如果排在很久不用的位置，可能已经被淘汰——命中率还受并发与调度影响，不只看你自己。这也就是缓存命中率（Cache Hit Rate）不完全由你决定的原因。

3.1 缓存也有一本账：命中 / 未命中怎么计价

显存讲的是「技术代价」，真正决定上不上缓存的往往是钱。多数按 token 计费的服务里，输入 token 因为能复用前缀缓存，价格会分档：

• 缓存命中（cache hit）：这段前缀此前已经算过、还在缓存里，这次只做增量计算，单价最低；
• 缓存未命中（cache miss）：这段前缀要么是新的、要么已被淘汰，要完整重算，单价最贵（往往是命中的数倍）。

所以同样的输入 token，因为「前缀有没有命中」会落到完全不同的价位。这带来两个反直觉但必须算清的结论：

1. 「输入便宜、输出贵」不一定成立。 传统说法是输出 token 更贵，但一个长前缀如果每次都未命中，输入端的累计成本可能反过来成为大头。
2. 压缩上下文可能在「省钱」上适得其反。 为了省 token 而压缩/改写历史，一旦改动发生在前缀部分，缓存就从命中变未命中——token 数省了，单价却翻了数倍，总价可能不降反升。

def estimate_cost(input_tokens: int, output_tokens: int,
                  hit_ratio: float,          # 输入里缓存命中的比例 0~1
                  input_hit_price: float,    # 每 token 命中价（$）
                  input_miss_price: float,   # 每 token 未命中价（$）
                  output_price: float) -> float:
    hit = input_tokens * hit_ratio
    miss = input_tokens * (1 - hit_ratio)
    return (hit * input_hit_price
            + miss * input_miss_price
            + output_tokens * output_price)
# 例：同样 80k 输入 + 2k 输出，命中率 0% vs 90% 的差别
LOW  = estimate_cost(80_000, 2_000, 0.0, 0.50, 2.50, 10.0)
HIGH = estimate_cost(80_000, 2_000, 0.9, 0.50, 2.50, 10.0)
print(f"命中 0%：${LOW/1e6:.2f}/M-token 折算")    # 未命中为主，输入占大头
print(f"命中 90%：${HIGH/1e6:.2f}/M-token 折算")  # 命中为主，输入成本骤降

面试里能把「缓存命中率是一条成本线、不只是延迟线」讲清，比背显存公式更能体现你真正在生产里管过这块。判断标准一句话：改任何「省 token」的优化（压缩、去重、重排历史），都要先问一句——它会不会把前缀从「命中」打成「未命中」？ 会的话，省的 token 可能远抵不上单价的上涨。

四、动手：把「前缀稳定性」变成可检查的东西

下面这套做法用一个前缀指纹（Prefix Fingerprint），把「相邻两轮是否共享同一前缀」从「肉眼比对」落成「可自动跑的检查」——上一节讲的那些前缀破坏点，用它能被断言出来，而不是靠人记得。脚本可以直接接进你自己的 Harness 里做日常检查。

import json, hashlib
from typing import Any
def serialize_stable(obj: Any) -> str:
    """稳定序列化：键排序、分隔符固定、禁用 ascii 转义以保证同一对象字节一致"""
    return json.dumps(obj, sort_keys=True, separators=(",", ":"), ensure_ascii=False)
def prefix_fingerprint(messages: list[dict], tools: list[dict]) -> str:
    """对 tools + 前 N-1 条消息取指纹，验证相邻两轮是否共享同一前缀"""
    stable_part = {
        "tools": tools,                 # 工具定义必须在 messages 之前，且顺序稳定
        "history": messages[:-1],       # 最后一条是新增内容，不参与指纹
    }
    return hashlib.sha256(serialize_stable(stable_part).encode()).hexdigest()[:16]
def append_only_messages(system: str, history: list[dict], user_input: str) -> list[dict]:
    """唯一推荐的组装方式：头部固定，只在尾部追加"""
    fixed_head = [{"role": "system", "content": system}]
    return fixed_head + history + [{"role": "user", "content": user_input}]
# --- 使用示例：连续两轮，观察指纹是否一致 ---
tools = [{"name": "get_weather"}, {"name": "get_time"}]   # 注意：顺序必须写死
h1 = [{"role": "user", "content": "北京天气"}]
fp1 = prefix_fingerprint(h1, tools)
h2 = h1 + [{"role": "assistant", "content": "正在查询"},
           {"role": "tool", "content": "晴 24℃"}]
fp2 = prefix_fingerprint(h2, tools)   # 注意这里的「-1」语义：最后一轮的新输入不入指纹
print(fp1, fp2)   # 这里的差异是因为 history 长度变了，实际检查时应比较「相同长度部分」

五、常见误区与追问

5.1 误区：命中率只由自己请求的写法决定

错在哪：以为只要自己两轮请求前缀一致，KV Cache 就一定能命中。为什么自然：前缀确实按字节比对，一致就该命中。正确做法：服务端还有 LRU 或分页（PagedAttention）淘汰策略，并发高、显存紧时你的长前缀可能已被换出。给个数字：70B 级模型在 32k 上下文下单条缓存约 10 GiB，32 路并发就是 300 GiB 量级。判据：高频复用的前缀要短而稳定，别指望超长前缀一直驻留；命中率不完全由你，要按最坏情况设计。

5.2 误区：GQA / MQA 缩小的是「模型」或「算力」

错在哪：把 KV Cache 显存、权重体积、注意力算力混为一谈。为什么自然：它们都叫「省资源」，直觉上是一回事。正确做法：GQA/MQA 只缩小 KV Cache 里的 K/V 头数，从 64 降到 8 甚至 1；它不改变注意力 O(n²) 复杂度，也不改变权重体积。判据：被问「GQA 解决了公式里哪个因子」时，答案必须是 n_kv_heads，而不是 n_layers、head_dim 或注意力复杂度。长上下文能跑起来，靠的是这一项的缩小。

5.3 误区：动态信息放 system prompt 开头无所谓

错在哪：以为模型能「理解」就不影响成本。为什么自然：从语言理解角度，加一句时间确实无伤大雅。正确做法：KV Cache 按前缀逐位比对，第一个 token 不同，其后全部失效，命中率直接掉到 0。判据：把第 1 轮与第 2 轮请求体打印出来，比对字节前缀，看第一个不同字符的偏移量；如果偏移量落在前 1% 内，说明缓存基本作废。纪律：时间、用户名、记忆等动态内容一律放尾部。

5.4 误区：KV Cache 显存和注意力算力都是「随长度增长」，一起优化即可

错在哪：把两种增长当成同一种瓶颈。为什么自然：都和序列长度正相关，容易合并思考。正确做法：前者线性（∝n），后者平方（∝n²），是两套独立瓶颈、两套独立手段。判据：算 seq_len 翻倍时两者各自变化倍率——显存约 ×2，算力约 ×4；优化时一个靠减 n_kv_heads / 量化 / 分页，另一个靠 FlashAttention / 分块 / 稀疏。把「长上下文优化」说成单一手段，是面试里最容易被追问的点。

5.5 误区：缓存越大越好，把整个历史都留着

错在哪：认为多留历史只会更准，没有代价。为什么自然：上下文越长，模型可利用的信息越多，看似有益。正确做法：KV Cache 显存 = 2·B·L·n_layers·n_kv_heads·head_dim·bytes，是硬预算；超了就 OOM 或被淘汰。判据：单条 32k、fp16 约 10 GiB，64 并发就 600 GiB 量级，还不算权重。结论：历史要外置（放文件 / 工具），上下文只留指针；「全留着」既不经济也可能因淘汰而失效。

5.6 误区：前缀缓存（Harness 侧）和 KV Cache 是一回事

错在哪：把两个层次的复用混为一谈。为什么自然：名字都带「缓存」，效果都是省重算。正确做法：前缀缓存是 Harness 在请求级复用相同前缀的计算结果（如 system + 工具定义），KV Cache 是推理引擎在层内缓存 K/V 张量；前者靠字节稳定命中、由应用侧保证，后者由引擎管理、还受淘汰影响。判据：前者你能完全控制（稳定序列化），后者只能间接影响（短前缀 + 高命中）。两者协同，但归属不同层。

六、自测

七、小结

前缀稳定性是那种「懂了就能立刻省一半钱、不懂也完全不知道自己在亏」的知识。面试里能主动提起它，说明你真的在为自己的系统付过账。本刊编辑部

下一章换一个角度：既然总参数可以很大而激活参数可以很小，成本结构还能再动一次手脚。

八、参考与延伸

本章的机制部分只讲到「够用」为止。想往下深挖，下面这几份材料按「先看图、再看代码、最后读论文」的顺序排好了。全站不做原文转载，这里只登记链接与「为什么值得读」。

先看图（建立直觉）

• vLLM：用 PagedAttention 把 LLM 服务做到又快又省 —— 这篇博客把 KV Cache 碎片问题讲得最直白，还配了显存占用的对比图。读本章第三节「淘汰策略」卡住时，来这儿看 PagedAttention 怎么消灭碎片最快。
• Lilian Weng · The Transformer Family v2.0 —— 把各种注意力变体（稀疏、线性、GQA/MQA）按「改了什么」整理成谱系。想理解「长上下文优化都有哪几条路」，读这一篇的目录结构就够了。

再看代码（动手实现）

• 动手学深度学习（中文，zh.d2l.ai） —— 配套可跑代码，把注意力、缓存、序列长度的关系用 NumPy 实现了一遍。把本章的显存估算公式照着敲一遍，比看十遍都记得牢。

最后读论文（对齐一手定义）

• GQA：Training Generalized Multi-Query Transformer Models（arXiv:2305.13245） —— GQA/MQA 的一手来源。重点看它怎么把 K/V 头数降下来，以及为什么 MQA 训练更难、GQA 是它的折中。
• Efficient Memory Management for Large Language Model Serving with PagedAttention（arXiv:2309.06180） —— PagedAttention 原论文，也是 vLLM 的基础。想搞清楚「服务端淘汰」到底按什么粒度发生，看它的 KV 块管理那节。