最佳实践指南：前缀缓存卸载
概览
高效缓存前缀计算状态以避免重复计算，对于提升大语言模型 (LLM) 推理性能（如首字延迟 TTFT 和整体吞吐量）以及降低成本至关重要。对于自注意力机制，生成下一个 token 需要利用前缀的键值 (KV) 张量。对于 Mamba 等状态空间模型 (SSM)，重用其前缀位置的 SSM 状态缓存也能节省后续 token 的计算。在本指南中，我们使用“前缀缓存” (prefix cache) 一词来统称目标 token 之前的前缀 token 的计算状态缓存，包括前缀 KV 张量缓存及其他形式的缓存。推理调度中关于前缀感知的请求调度优化同样适用于此场景。
目前最先进的推理引擎已经实现了在加速器显存 (HBM) 中跨请求的原生前缀缓存重用，但在大多数服务环境中，HBM 已经是受限资源。为了在 HBM 之外增加可用内存量，需要更多的缓存存储空间，这推动了将前缀缓存从 HBM 卸载到更具成本效益的存储选项（如 CPU RAM）的需求。
本指南根据不同的缓存存储类型提供了多个子指南，这些存储类型既可以独立使用，也可以组合成多级缓存体系。本指南还提供了关于它们对不同工作负载适用性的高层指导，并就如何选择和配置前缀缓存卸载实现给出了建议。
存储类型
CPU RAM
推荐启用 CPU 前缀缓存卸载，原因如下：
- 极低的运维开销。
- 主机上的 CPU RAM 通常比加速器 HBM 更充足，能提供大得多的缓存容量。
- 在大多数情况下，CPU 与加速器之间的传输速度比重新计算更快。
- （进行中）具备前缀缓存存储层感知能力的推理调度可以根据缓存层级（加速器 HBM vs. CPU RAM）做出智能决策。
在主要使用 HBM 的小缓存容量场景下，异步 CPU 卸载几乎不会产生额外开销。在大缓存容量场景下，从 CPU RAM 加载缓存比仅使用 HBM 提供显著更高的缓存命中率，从而获得更好的性能。
请参阅 CPU 卸载指南 了解如何通过 llm-d 启用 CPU RAM 卸载。
本地磁盘
利用本地磁盘存储可以显著增加缓存容量。然而，磁盘通常比 CPU RAM 慢得多。
在以下情况下考虑使用此方案：
- 您的工作负载可以容忍延迟开销。
- 本地磁盘的缓存容量足以满足您的使用场景。
否则，我们推荐使用共享存储，因为它：
- 支持实例间的缓存共享，
- 有更多选项可以在成本和性能之间取得平衡，
- 提供显著更大的容量。
共享存储
将前缀缓存卸载到共享（远程）存储具有以下优势：
- 海量存储容量，独立于推理引擎的部署容量。
- 在推理引擎副本之间以及重启期间无缝共享前缀缓存。
但是，这会增加运维和性能开销，具体取决于存储系统的特性（如延迟和吞吐量）。因此，决定是否卸载到共享存储系统需要仔细权衡。
当满足以下至少一个条件时，请考虑共享存储选项：
- 缓存容量需求超出了 HBM + CPU RAM 的总和。
- 输入长度较长（>10k）且缓存命中率高。
- 频繁的缓存迁移需求（例如模型或引擎版本滚动更新）。
P2P 缓存共享
可以在推理引擎实例之间形成 P2P 网络，以共享 HBM 或 CPU 内存中的缓存。这可以在不需要额外存储资源的情况下实现更多的缓存共享。然而，该策略会增加运维开销，并可能与张量并行 (Tensor Parallelism) 等模型并行流量产生竞争。我们将在后续版本中添加更多建议。
缓存分层 (Cache Tiering)
通常可以根据缓存读/写延迟应用多个缓存层级，让频繁访问的缓存尽可能靠近加速器，而将容量大或访问频率较低的缓存卸载到较慢的层级。我们建议始终设置 HBM 和 CPU RAM 层级，并在缓存需求超出 HBM + CPU RAM 时考虑设置第三或第四层级。
此内容自动同步自 llm-d/llm-d 仓库 main 分支下的 guides/tiered-prefix-cache/README.md。