我在 4 月份写的博客《LLM 推理优化 Prefix Caching 及其实现》带来了不少流量，这篇博客在 Google 搜索“Prefix Caching”时排在比较靠前的位置，也给我的微信公众号“边际效应”带来了超过 100 个关注者，由此可以看到大家对这项技术的广泛兴趣。
新认知
最近关于 Prefix Caching 我又产生了一次认知升级：在一个 Eureka 时刻，我忽然领悟到 Prefix Caching 实际上可以是一种效果优化手段——但让其充分发挥效能需要跟长上下文语言模型 Long-Context LLM 和基于 Prefix Cache 的调度技术相结合。
RAG v.s. Super Long Domain Specific Prefixes
为了减少模型的幻觉，提升时效性，我们往往会采取 RAG 技术来增强模型。召回的结果本身会增加 Prompt 的长度，会加大 Context 的计算量，会影响模型的推理时长，因而召回结果的补充也是谨慎克制的，不会让 Prompt 变得非常长。
但是 Prefix Caching 优化技术给我们开了个口子：如果把信息放在 Prompt 的共享 Prefix 中，加长 Prompt 的代价就由计算和时延，转化到了存储。而存储代价可以通过 Cache 复用来摊薄，这就是一笔很划算的经济账。
如果把 RAG 召回的结果当作 Prompt 里的变量，那么 Prefix 就是 Prompt 里的常量，当增加变量信息的规模受到限制时，增加常量信息的规模也可以提升生成的效果。
举个例子：如果你做 K12 领域的模型，把 12 个年级的语文知识点都放在 Prefix 里，然后再叠加 RAG，然后回答用户语文方面的提问，肯定能更好地保证生成的效果。
所以，LLM 技术后续的一个新发展分支，也许会是超长特定领域专用的前缀设计。
Inference Time Scaling
最近讨论很多的一个技术方向，是从基于预训练提升效果的 Scaling Law 转向基于 reasoning at inference time 的 Scaling Law，使用更多的推理计算来获得更好的效果。
但这些 Scaling Law 还是基于“computing”的 Scaling，我认为也许会存在基于“memory”的 Scaling Law，即更长的共享 Domain Specific Prefix 带来更好的效果。因为这里的“memory”是计算的缓存，memory 的共享本质上是计算的共享。
Long Context Large Language Model
在无法共享计算的场景下，长上下文的大语言模型应用往往由于其计算成本或显著延迟而无用武之地。但如果基于 memory 的 Scaling Law work 的话，那长上下文大语言模型将成为必经之路。
这也许是 Moonshot 和 Gemini 早早投入百万 Token 级别长上下文模型的背后逻辑。
Prefix Cache Aware Scheduling
在没有理想的大一统 Prefix 之前（大概率也不可能），共享 Prefix 只能是 Domain Specific 才最合适。那就意味着会有很多个共享 Prefix，而 Prefix Cache 占用的空间又是不可忽视的，所以不可能在每张卡/每台机器上都存储所有的共享 Prefix。
这就要求在用户请求调度时，根据 Prefix 分配到不同的卡/机器/集群上。Prefix Cache 也需要能够根据请求的热度在不同的服务器间弹性扩散或者收缩，甚至在显存、内存、SSD 之间调度。其实 Kimi 的论文“Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving”就是在解决这个问题，只是我之前没有意识到这个技术的广泛重要性。