17 篇博文 含有标签「prompt-caching」

控制面板上的对话情况看起来很健康。每次调用的平均 token 数合理，p50 输入长度舒适地处于缓存前缀（cached prefix）之内，供应商的发票按照财务部门批准的速度增长。然后，有人导出了一个包含 200 轮对话的单次编程会话，该用户的单项支出就超过了团队其余成员每日流量的总和。控制面板没有撒谎 —— 它只是在算平均值。账单来自于长尾（long tail），而长尾并不会随着轮次增加而线性增长。

每一个多轮对话的 AI 功能最终都会遇到这种“惊喜”。每次调用的 token 数是一个错误的衡量单位，因为 30 轮对话的成本不是单次调用的 30 倍 —— 而是 50 倍到 200 倍之间，这取决于历史记录的结构方式、提示词缓存（prompt cache）的衰减情况，以及一旦输入超过 200K token 后请求所处的计费层级。根据单次调用数据为功能定价的团队，实际上是在为他们从未建模过的长尾风险承保。

提示词缓存（Prompt caching）是一种只要开启就能立即获益的优化手段。长系统提示词仅需哈希一次，KV 状态驻留在 GPU 显存中，随后任何复用该前缀的请求都能跳过预填充（prefill）成本。供应商报告称，对于缓存的请求，延迟降低了 80%，输入成本降低了 90%。在大规模应用中，这种经济效益是无法抗拒的：摊销到数百万次调用中的单一共享前缀，将一项支出变成了几乎可以忽略不计的尾差。

实现这种节省的机制本质上是一种共享资源，其命中或未命中的状态可以通过延迟来观察。这种可观察性就是侧信道（side channel）。在网络外部可以清晰分辨缓存命中与缓存未命中，这种差异巨大且具有确定性。这项在成本看板上占有一席之地的优化方案，还兼任了一份无人预料的工作：泄露同一供应商下其他租户当前正在进行的活动信息。

账单在月初寄到，金额是你电子表格预测的三倍。没有人推送过系统提示词（system prompt）的更改。仪表盘显示请求量持平。p95 延迟看起来很正常。每个正确任务消耗的 token 比例（token-per-correct-task ratio）也没有变化。然而，你却欠了推理供应商额外的四万美元，而可观测性技术栈中唯一暗示了原因的信号，是一个大多数团队从未设置过报警的指标：缓存命中率（cache hit rate）。它在计费周期的第二周，也就是某个周二的太平洋时间上午 9:47，从 71% 掉到了 18%。而那个时刻，正是你最大的租户的客户成功团队为两百名新用户启动了一场协调一致的入驻活动。

欢迎来到提示词缓存抖动（prompt cache thrashing）—— 这种多租户故障模式本该在十年前就被 SaaS 策略手册消除，如今却通过推理供应商的共享前缀缓存（shared prefix cache）从后门溜了回来。供应商的缓存是在你组织的流量中共享的。无论你是否愿意，你的租户都在共享这个缓存，而一个租户的前缀形态在夜间发生改变，就可能逐出（evict）所有其他租户的单位经济效益（unit economics）所依赖的前缀。对于那些没做任何改变的租户来说，账单也会激增。财务部呼叫工程部，工程部指着显示一切正常的仪表盘，因为仪表盘并没有测量出那个已经损坏的环节。

当你的团队第一次启用提示缓存时，感觉就像凭空得到了钱。几小时之内，token成本下降了40–60%，延迟也随之缩短。工程师们欢欣鼓舞，然后继续前行。三个月后，有人注意到成本悄悄地爬回去了。从72%起步的缓存命中率现在只剩18%。没有人故意破坏它，没有人注意到。

这是生产LLM部署中最常见的轨迹：缓存只被启用一次，从不被监控，随着代码库的演进而悄然退化。缓存命中率是LLM技术栈中最具影响力的成本杠杆，但大多数团队把它当作一次性的设置任务，而非生产指标。

你的暂存环境显示 p50 延迟为 400ms。你的生产环境仪表盘却显示 1.8 秒。你检查了代码 —— 同样的模型，同样的提示词（Prompt），同样的供应商。部署和发布之间没有任何改动。数据不应该有这么大的分歧，但事实就是如此。

罪魁祸首几乎总是缓存状态。提示词缓存（Prompt caching）—— 大多数团队依赖的最重要的延迟优化手段 —— 在暂存流量模式下的表现与生产流量模式下有着本质的不同。如果你不考虑这种差异，那么你在发布前收集的每一个延迟数据都是虚假的。