2024.6谈LLM的Context Cache功能

主要观点总结

文章介绍了Context Cache功能，它是一种LLM推理时的跨请求缓存相同前缀的计算结果的方案。文章分析了各家的实现方案包括Google Gemini、NVIDIA TensorRT-LLM、Moonshot和SiliconFlow的特点，并给出了个人评价。文章还提到了LLM的流式增量输入场景和相关的讨论合作机会。

关键观点总结

关键观点1: Context Cache功能简介

Context Cache是LLM推理时的跨请求缓存相同前缀的计算结果的方案，但实用场景中意义有限，需要不同请求间共享足够长的prompt前缀，且缓存大小不小。

关键观点2: 各家的实现方案对比

目前能看到四种Context的实现：Google Gemini、NVIDIA TensorRT-LLM、Moonshot和SiliconFlow。其中Google Gemini是目前唯一公开发布且广泛可用的Context Cache功能，其定价按token和时间长度线性收费。

关键观点3: 应用侧评价

Context Cache在减少延迟上有作用，但费用减免有限。更适用于有公共的长context的情况，如workflow执行、大量同context请求并发或用户回复很快的场景。

关键观点4: 实现侧评价

Google Gemini使用的工程架构和硬件能力更强，能够实现理想的长时间缓存。而Moonshot的缓存方案更受限于硬件能力，成本较高。

关键观点5: 关于LLM的流式增量输入场景

对于延迟非常敏感的应用场景，context cache类方案似乎适合用来实现LLM的流式输入增量计算能力。

文章预览

1、Context Cache 功能简介 Context Cache简单来说是一个LLM推理时候的跨请求缓存相同前缀的计算结果的方案。由于KV Cache已经在LLM推理中普遍采用，所以作为其跨请求的自然推广，Context Cache这个设计是很自然的。 但在实用场景中，Context Cache的实用意义似乎没有那么强： 一方面这需要不同请求间共享足够长的prompt前缀，但在API平台上收到的实际请求中，不同用户不同请求能满足这个要求的比例很低，一般只有system prompt与prompt模版的前部才满足。在私有化部署场景下，硬件资源更少、请求的类型也更集中，所以Context Cache类的功能会更适合一些。 另一方面缓存的Cache大小又不小，显存很宝贵，把未来不知道何时会再来的请求缓存放在显存中是一种浪费。所以把cache转移到host memory是一个自然的选择，但这成本仍然很高，内存-显存带宽、host memory都不是白来 ………………………………