← 返回概念解读

Concept Fable精修版

前缀缓存

Prefix Caching · Inference

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

码头总号不再每天重抄同一段开场信

海边商会每天给外地分号写回信。每封信开头都要写同一段规矩:哪些货能赊账,哪些客人要复核,哪些承诺不能越权。老书记一字一句重抄,年轻伙计在旁边排队等批示。

起初这不算麻烦。后来分号变多,信件也变厚,真正的问题还没写到,半天时间已经耗在那段固定开场上。急单等不到回音,普通单也被拖到傍晚。

掌柜先让书记多招两个人,又把开场信缩短。新手抄得更快,却仍要从第一句开始;开场一改,所有人还得重新背。看起来省了几行,队伍仍然堵在入口。

有人建议把开场信印成小册子,谁来都发一本。可书记批信时仍要把册子内容重新读进脑子,真正耗费的不是纸墨,而是每封信都把同一段背景重新加工一遍。

账房后来做了一个暗格。凡是完全相同的商会开场、同一套权限和同一份参考账簿,先由老书记处理一次,留下可复用的批注底稿。下一封信若前面完全一致,就从底稿后继续写。

他没有允许所有信混用底稿。客栈账本换了、权限不同、开场里夹了新条款,就必须重新批注。复用只发生在前面真的相同、边界也相同的时候。

几天后,队伍明显短了。书记把精力放在每封信真正不同的尾部:这笔欠款该不该批,这个客户是否越线,这次交付是否需要主管签字。

掌柜终于看清,省下来的不是纸,而是重复处理同一段开头的时间。固定前段越长、来信越多,暗格越值钱;一旦前段不同,贪快复用反而会把旧规矩带进新案子。后来商会把常用开场分成几类:普通赊账、贵客复核、跨港交付、争议处理。每类都有自己的底稿和失效条件。老书记说,暗格省力的前提,是知道哪一段真的是同一段;若只看开头相似,就会把别人的规矩抄进这封信。年轻伙计也学会了先核对前段,再享受省下来的时间。只要前段有一处不同,就宁可重批,不把旧底稿当成万能钥匙。

揭示

这个故事讲的是:前缀缓存

前缀缓存复用相同提示词前缀已经计算好的 KV 缓存,比如系统提示、共享策略文本、产品文档或长参考上下文。它缓存的是共同上下文的计算结果,不是直接缓存最终答案。

在企业 Agent 中,它可以减少预填充计算、改善首 token 时间和吞吐,并降低成本。但缓存必须按模型、tokenizer、prompt 字节、租户、权限和版本隔离与失效,避免复用过期或越权上下文。

隐喻映射

  • 商会开场信:多个请求共享的 system prompt、策略说明或长上下文前缀
  • 老书记每次重抄:每个请求都重新执行 prefill
  • 批注底稿:可复用的 KV cache prefix
  • 前缀一致才复用:prefix cache 的命中条件
  • 账本和权限变化必须重算:租户隔离、版本、权限和失效策略
  • 队伍变短:TTFT、GPU 占用和请求延迟下降
  • 最后洞察:Prefix Caching 的价值不是缓存答案,而是缓存已经计算过的共同上下文

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

KV cacheprefillsystem promptthroughput

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。