Kimi 极速缓存引擎

解决什么问题

长对话里，每一轮都要把历史消息重新塞进上下文。请求越长，prompt 里重复的 token 越多，延迟和成本基本是线性上涨；而且只要前几轮有任何轻微改动，整段历史都得重算一遍。另一种浪费更隐蔽：用户追问时，模型把已经说过的内容重新生成一次，前文被反复引用，挤掉了本该留给新信息的额度。

v2 的缓存方案解决了一部分重复，但它没有做「用户还没说完就准备好」这件事——而短句、追问、修正这类高频输入，等待时间恰恰主要花在首轮的全量生成上。

引擎怎么工作

意图预测在收到前 3-5 个词时就尝试推断完整意图，问题还没发完就可能完成缓存匹配与模板预热；当 预测准确率 >85% 时，直接预生成响应骨架。增量响应让后续轮次只输出变化部分，引用前文使用 [↑N] 锚点，修正类回答用 [-旧] [+新] 的 diff 格式。

微缓存单元把常见回答拆成定义块、代码块、对比行这类可复用片段，同一对话中重复出现的概念或代码走哈希索引直接命中，不重新生成。超压缩模板放弃 Markdown 的冗余语法，改用符号承载语义，非核心信息默认折叠。上下文蒸馏把长对话提炼为决策树、待办、关键数据三要素，每轮注入的是蒸馏结果而非原始历史，作者给出的说法是 Token 占用降低 60-80%。

适用边界

这套机制强依赖预测质量。置信度低于 85% 时不预生成，首次响应的等待和普通流程没有区别，短输入、一次性提问这类场景拿不到收益。

增量响应要求模型理解 [↑N] 锚点的含义。如果下游只做纯文本存储或转发，锚点在别的系统里会被当成噪声；修正类的 diff 片段也不擅长表达复杂的多段重排。

微缓存单元在内容变更时需要能失效并更新。代码块如果频繁改动，命中率会迅速下降，缓存反而变成额外的维护负担。超压缩模板在检测到理解困难时会自动展开，但「理解困难」这个判断来自当前模型，换到别的模型上行为未必一致。上下文蒸馏会丢细节——当某条历史要到后面几轮才显出价值时，蒸馏当时丢掉的信息无法恢复。