大规模前缀缓存：何时能节省 80% 的预填充成本，以及那些悄然将其效果降至 5% 的驱逐策略

你的聊天机器人在 8 块 H100 显卡上部署了 700 亿参数的 Llama 模型。对于短提示词，稳态下的首字延迟（TTFT）约为 180 毫秒，团队对此表示满意。随后，你启用了检索增强生成（RAG）功能：每个请求都发送一个包含检索文档的 6,000 个 token 的上下文，加上一个简短的系统提示词，再加上用户的问题。首字延迟飙升至 1.4 秒。第 99 百分位延迟达到 2.1 秒。令人惊讶的是，这些 token 中有相当一部分在每个请求中都是相同的——系统提示词、针对热门查询检索到的相同的 6k 文本块、工具定义。模型反复重新计算相同的注意力状态，然后将其丢弃。这正是前缀缓存所要解决的问题，而上周关于键值（KV）缓存量化的文章也以此作为下一个主题收尾——因为这两个特性可以组合使用：量化后的前缀缓存比 BF16 格式的缓存更易于保持热状态，而节省下来的内存要么让你支持更多并发用户，要么支持更长的共享前缀。

以下是前缀缓存的实际含义，vLLM 和 SGLang 如何实现它的差异，以及生产部署中为何会悄然失去大部分收益。

为何这在实际应用中至关重要

现代大语言模型服务栈每个请求分为两个阶段：预填充（处理整个提示词以构建键值缓存）和解码（一次生成一个 token，并针对不断增长的缓存进行注意力计算）。对于长上下文工作负载，预填充占据主导地位。在拥有 8k 输入长度的 700 亿参数 Llama-3 模型上，预填充约占首字延迟的 70–85%——相比之下，解码速度很快。

大多数“长输入”工作负载并非在每个请求中都既长又独特。它们既长又重复：

检索增强生成（RAG）流水线。 相同的检索文本块会命中相同的热门查询。系统提示词和工具模式在每个请求中都是字节级完全相同的。用户问题是唯一的可变部分，且篇幅很短。
多轮对话。 每一轮都是上一轮的严格前缀扩展。第二轮共享除最新的助手消息和新用户回合之外的所有内容。
智能体循环。 相同的工具模式、规划提示词和少样本示例在每一步都会被前置添加。只有最新的工具结果不同。
长文档问答。 用户反复就同一份 200 页的 PDF 文档提问。文档是前缀，问题是后缀。

前缀缓存是一种优化策略，其核心思想是：如果此请求的前 N 个 token 与我已处理的某个请求匹配，请直接返回这 N 个 token 对应的键值缓存，而不是重新计算它们。 在理想情况下，模型输出与无缓存运行时逐位相同，但预填充成本降至一小部分。报道中提到的“节省 80% 预填充成本”的数据来自前缀重叠率超过 90% 的检索增强生成场景。而 5% 的数据则来自前缀很少匹配，或者缓存在被重用之前就被不断驱逐的工作负载。

“前缀缓存”的实际含义

高层理念很简单。具体实现涉及三个决定系统其余部分的决策：基于什么单位进行哈希计算、如何查找，以及当缓存已满时如何处理。

flowchart LR
    A[新请求<br/>token 0..N-1] --> B[分词 &<br/>分割为块]
    B --> C[对每个块进行哈希计算<br/>token + 父级哈希]
    C --> D{在<br/>块表中查找}
    D -- 命中 --> E[复用键值块<br/>跳过预填充]
    D -- 未命中 --> F[计算该块的<br/>键值]
    F --> G[在

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。