Table of contents
Open Table of contents
一、 大模型缓存(Prompt Caching) vs 传统 Redis 缓存
在 Coding Agent(如 Cline、Claude Code)频繁读写项目文件的场景下,大模型的 API 计费会出现“命中缓存(Cache Hit)”的折扣。这里的缓存机制与传统的 Redis 有着本质的区别。
1. 核心机制对比
| 特性 | 传统 Redis 缓存 | 大模型 Prompt Caching(提示词缓存) |
|---|---|---|
| 匹配规则 | 全字匹配(Exact Match) Key 变动一个字节,整个缓存完全失效。 | 前缀匹配(Prefix Matching) 只要输入的文本从第一个字符开始有一大段连续一致,即可命中该段前缀。 |
| 存储内容 | 业务数据 如字符串、JSON 序列化对象等。 | 数学矩阵(KV Cache) 输入文本在 Prefill 阶段计算好的 Attention K 和 V 矩阵。 |
| 颗粒度与门槛 | 开发者自由定义 Key,大小通常不限。 | 有严格的起步门槛(如前缀必须大于 1024 tokens 才触发缓存)和对齐块大小(如以 256 tokens 为一块)。 |
2. 为什么 Coding Agent 的命中率极高?
虽然代码一直在改,但 Agent 发送给模型的上下文结构通常是高度局域化且分层递进的:
[层级 1:系统提示词 (System Prompt) + Tools 定义] <-- 永远不变
[层级 2:整个项目的目录树 + 核心文件的源码] <-- 在一轮修复内基本静态
[层级 3:前几轮对话的历史记录(报错与建议)] <-- 转化为固定历史前缀
[层级 4:当前这一轮用户新输入的动态命令] <-- 唯一在变的部分
即使“层级 4”一直在变,只要前面的层级 1、2、3 保持稳定,云端就能成功识别这段极长的**“前缀”**,直接触发缓存折扣(通常可省下 50% - 90% 的输入成本)。
3. Active Session ≠ 云端缓存:关于 Timeout
在 IDE 或 CLI 窗口中,即使你没有断开 Session,云端的缓存依然是滑动短期缓存。
- 无状态的 API:大模型 API 物理上是 Stateless 的。每一次回车,都是一次独立的 HTTPS 请求。
- 显存的高淘汰率(TTL):云端显存极其宝贵。如 Anthropic (Claude) 的 Ephemeral Cache 默认生存时间(TTL)仅为 5 分钟。如果用户在这一轮生成后,停下来思考、查文档超过 5 分钟,云端就会因 LRU 机制擦除该缓存。下一轮请求时,即使本地 Session 完好,云端也会遭遇 Cache Miss,重新全额计费并引发首字卡顿。
二、 大模型推理的双子星:Prefill 与 Decode 阶段
大模型处理一次请求的完整生命周期,必须经历两个物理特性截然不同的阶段:
graph TD
A[用户输入 Prompt / Agent 打包上下文] --> B[Prefill 阶段: 预填输入]
B -->|并行计算所有输入 Token| C{计算 Attention}
C -->|产出初始 KV Cache| D[显存 / 缓存服务器]
B -->|输出第一个字| E[TTFT 首字延迟]
E --> F[Decode 阶段: 逐字生成]
F -->|串行自回归: 每次处理上一个字| G[结合历史 KV Cache 计算]
G -->|更新并追加新 KV Cache| D
G -->|输出新 Token| H[TPS 吞吐率]
H -->|是否生成结束符 EOS| F1. Prefill(预填 / 输入阶段)
- 核心任务:一次性加载用户输入的全部 Prompt,计算所有 Token 两两之间的注意力权重,并构建出初始的 KV Cache。
- 物理瓶颈:算力受限(Compute-bound)。因为所有 Token 同时丢进 GPU 进行并行计算,其 Attention 复杂度随长度呈平方级增长。GPU 的 Tensor Core 会瞬间拉满。
- 业务指标:决定了首字延迟(TTFT, Time to First Token)。
2. Decode(解码 / 生成阶段)
- 核心任务:利用上一步刚刚生成的单个 Token,结合显存中已有的 KV Cache,通过自回归(Autoregressive)的方式预测下一个 Token。
- 物理瓶颈:带宽受限(Memory-bound / IO-bound)。每生成一个字,GPU 只需要极小的算力,但却必须把整个模型的权重参数以及几个 GB 的 KV Cache 从显存里完整读取到 GPU 核心一次。显存带宽的传输速度决定了打字速度。
- 业务指标:决定了吞吐率(Tokens Per Second)。
三、 拆解 KV Cache:注意力机制的物理缓存
要理解大模型缓存,必须厘清 Transformer 架构中 Q, K, V 三个矩阵在 Attention(注意力)计算中的角色。
1. 概念通俗化类比:职场/相亲匹配系统
当任何一个字(Token)进入模型,它都会通过三组不同的滤镜,被复制并转换成三个向量:
- Query (Q —— 诉求):“我是当前最新的字,我在找什么?”
- Key (K —— 特征标签):“我是历史字,这是我的简历,用来给 Q 匹配。”
- Value (V —— 核心内涵):“我是历史字,这是我包含的真实语义价值,匹配成功就把我带走。”
2. 什么是“做一次 Attention 计算”?
以句子“小明买了一本书,他很喜欢看它”为例,当模型处理到“它”字时:
- 对眼神(计算相似度 Q × K):“它”产生的 Q 去和历史所有字(小、明、买…书)的 K 做点积运算,算出一个原始关联得分。
- 分配权重(Softmax):将得分转化为总和为 100% 的概率权重。例如模型计算出:注意力应该有 85% 放在“书”上,10% 放在“小明”上。
- 打包带走(权重 × V):拿着 85% 的权重去乘以“书”的 V(语义内涵),10% 乘以“小明”的 V,加权求和,融合成一个新的抽象语义向量(Hidden State)。
3. KV Cache 究竟缓存了什么?
因为大模型是自回归的,前面已经产生的字序列(历史)是绝对固定、不会再变的。这意味着,历史字的 K(特征)和 V(内涵)也永远不会变。
KV Cache 的本质: 在 Prefill 阶段和后续的每一次 Decode 步中,把历史字算好的 K 和 V 矩阵直接钉在显存里。新字进来时,只需要生成自己的 Q, K, V;然后用自己的 Q 去跟显存里庞大的历史 K 缓存对眼神,再把历史的 V 缓存打包带走。算完后,新字自己的 K 和 V 也追加进显存,变成下一轮的缓存。
四、 最后一公里:大模型如何摇号并保持连贯性
注意力机制加权求和后得到的新向量,只是一个极其复杂的**“抽象语义向量”,它并不直接等于任何一个字。要把它变成最终输出,需要经过对齐词表**、概率抽样,并在这个过程中对抗**“自回归的诅咒”**。
graph TD
A[Attention 加权求和新向量] --> B[与词表矩阵做全量比对]
B --> C[产出全词表原始得分 Logits]
C --> D[Softmax 转化]
D --> E[总和 100% 的概率分布列表]
E --> F[庄家剪枝 Top-P / Top-K]
F -->|剔除语病/低概率词| G[受约束的候选池]
G --> H{判断 Temperature 温度参数}
H -->|T = 0 绝对理性| I[贪婪搜索: 永远选概率最高的字]
H -->|T > 0 具备创造力| J[概率抽样: 摇号/掷骰子决定]
I --> K[最终吐出 Token]
J --> K
K -->|瞬间变成千分之一秒后的绝对历史| L[动态前缀约束: 滚雪球式诅咒]
L -->|作为新输入| A1. 从抽象向量到“概率列表”
- 对齐词表 (Logits):模型拿着这个新向量,去和它自带的“密码本”(词表矩阵,通常包含十几万个字词)做点积,算出新向量和字典里每一个字的几何接近度得分。
- 概率归一 (Softmax):通过数学转换,把原始得分变成清晰的百分比概率。例如:“书”的概率是 85.5%,“看”是 12.0%,“苹果”是 0.0001%。
2. 掷骰子(Sampling)与创造力控制
模型最终输出什么字,取决于采样参数:
- Temperature(温度)= 0:绝对理性。模型不做任何动摇,永远只选概率最高的那个字(如写代码的 Agent 场景),输出具有确定性。
- Temperature(温度)> 0:摇号/抓阄。概率分布变成一个转盘,“书”占了 85.5% 的面积,“看”占 12%。模型通过掷骰子随机决定落在哪。这赋予了模型创造力与多样性。
3. 为什么摇号不会导致语句颠三倒四?(如何保证连贯性)
大模型没有全局大纲规划能力,它能保持完美的语法和逻辑连贯,全靠以下三大机制:
① 动态的“滚雪球”约束(自回归的诅咒)
上一轮摇号摇出来的字,在千分之一秒后,就会变成下一轮推理的“铁历史”。 当模型前文产生了“我肚子饿了,所以想去吃…”,并且掷骰子摇出了一个“火”字。那么在极短的下一轮推理中,整个历史上下文变成了“我肚子饿了,所以想去吃火…”。在几万亿人类语料的引力场下,“锅”的概率会被瞬间拉高到 99.9%,而“车”、“星”等字的概率会直接归零。前文编织的概率场,死死地诅咒并约束着未来的每一个字。
② 庄家剪枝(Top-P / Top-K)
在真正掷骰子之前,算法会进行严格的概率剪枝。那些可能导致严重语法错误或逻辑断层的烂牌(低概率字词,如“吃火昨天”),在入场前就直接被抽走。模型只能在一群同样合理的“优秀备选项”中抓阄。
③ Transformer 的长距离结构对齐
Attention 机制对长距离的符号配对(如括号闭合 ()、主谓一致、时态对应)有着像素级的物理记忆力。即使中间隔了上百个字,前面的左括号依然会在后续计算中强行把右括号的概率像蓄水池一样越推越高,直到将其逼出。
4. 机制的代价:大模型的翻车现场
这种“走一步看一步”的自回归机制,导致了大模型的固有缺陷:
- 画地为牢(Painted into a corner):模型为了追求当下的词藻华丽,前半句摇出了一个极端的词,导致后半句在逻辑上无法收场,为了维持语法通顺,只能强行编造逻辑(幻觉的成因之一)。
- 复读机死循环:若前文不小心产生了重复的句式,Attention 机制会在后续计算中疯狂自我强化,导致模型陷入“因为…所以…因为…所以…”的死胡同。
五、 总结与工程启示
- Prompt Caching(云端提示词缓存) 玩的是前缀匹配,存的是 Prefill 阶段的 KV Cache,它有高昂的显存成本和极短的云端 TTL(如 5 分钟)。
- 在开发和使用 Coding Agent 时,若想榨干缓存红利,应当采取**“小步快跑、高频交互”**的策略,在 2-3 分钟内持续发送短小指令给云端续命,避免长时间长考导致云端 Cache Miss。
- 大模型的推理是一个**“Prefill(算力填满算 KV) → Decode(带宽卡死读 KV 逐字自回归) → 词表映射 → 剪枝抽样”**的精妙流水线。文字在自回归的“概率轨道”上受过去所有字的诅咒和指引,向前滑行。