How Prompt Cache Works

Sat, 27 Jun 2026 17:52:52 +0800

在日常的 Agent 开发中，开发者很难直接接触到服务端的 KV Cache。然而，无论是编写 Prompt、控制对话历史的长度，还是设计 Agent 的长程反思循环，其本质都在操纵 KV Cache 的计算与复用。本文旨在系统化拆解 KV Cache 与 Prompt Cache 的工作机制，分析其在多轮对话与 Agent 架构中的应用设计原则，并深入探讨在百万级用户规模下，分布式推理系统在安全性、多级存储管理、以及调度计费上面临的工程权衡。

1. 核心概念：Prompt Cache 与 KV Cache

1.1 Prompt Cache 与 KV Cache 的区别

要理解大模型推理的成本与时延，首先必须厘清两层性质完全不同的“缓存”概念。它们处于不同的生命周期，服务于不同的系统目的：

维度	运行时 KV Cache	前缀复用缓存 (Prompt Cache / Prefix Cache)
主体对象	某个正在进行的单次生成请求，独占该内存块	已结束请求留下的、可供后续跨请求复用的前缀 KV 块
存活周期	即时焚毁：随请求开始而创建，随生成结束（吐出 EOS）而彻底释放	持久留存：请求结束后不丢弃，在内存/硬盘中留存一段时间（TTL）
系统目的	维持 Self-Attention 机制的多轮解码，让当前的 Token 生成得以持续	跳过后续相同前缀请求的 Prefill 阶段，直接加载计算结果
核心效益	将自注意力计算复杂度从 O(N^2) 降低到 O(1)	极端优化首字延迟（TTFT）与算力成本

1.2 Prompt Cache 缓存了什么

在 Prefill 阶段，推理引擎将 Prompt 中的每个 Token 转换为 K, V 向量填入缓存。Prompt Cache 做的事情，是在当前请求结束后，将这段已经算好的 KV Cache 留在服务端。下次请求若 Prompt 前缀相同，则直接加载这块 KV，跳过对这段前缀的 prefill。

Dive into KV Cache in LLM

Sat, 27 Jun 2026 17:47:41 +0800

1. 自回归生成

LLM 本质上就是一个 next-token predictor：给定一段 prompt，预测下一个 token。所有长篇回答，都是 token by token 生成的。初学者需要注意，token 与词/字符之间并不完全等价，模型的处理单位是 token，即模型的输入输出都是 token，而不是一个词或一个字符。（注：若仅关注原理部分，不关注 tokenization 的内部实现机制，粗糙地将 token ≈ 词，关系也不大）

模型在预测下一个 token 时，不是直接吐出一个确定的词，而是输出全词表的概率分布。比如，用户输入"今天天气真"，模型经过一系列计算得到全词表的概率分布，再经过采样得到一个 token：

输入："今天天气真"
"好"   → 0.62
"不错" → 0.15
"热"   → 0.08
...(其余 token 瓜分剩余概率)

==》
next token: "好"

模型一次只产出一个 token，把第 i 步的输出作为第 i+1 步的输入，用伪代码表示，大致如下：

while not finished:
    logits = model.forward(tokens)        # ① 前向: 算出词表上 N 个分数
    probs  = softmax(logits)              # ② 变概率
    next_token = sample(probs)            # ③ 采样选一个
    tokens.append(next_token)             # ④ 拼上去