Prompt Caching/RadixAttention

Prompt Caching = 复用相同前缀 prompt 已计算好的 KV 缓存,跳过重复的 Prefill 计算。典型可复用前缀: 系统提示 (system prompt)、Few-shot 示例、多轮对话的早期轮次、多租户共享的公共指令块 —— 这些前缀占一次请求 token 的 50-90%,却每请求重算一遍纯属浪费。RadixAttention (SGLang 核心): 把所有活跃请求的 KV 块组织进一棵基数树 (RadixTree),树上每个节点 = 一段公共前缀,根为空,路径 = 从根到节点的 token 序列;新请求沿树做最长前缀匹配 (longest prefix match),命中的节点直接复用其 KV,只对「未命中的后缀」做 Prefill(计算量正比于未命中 token 数)。请求结束或变化时树动态分裂/合并: 公共前缀继续共享、差异分支分裂。效果: 命中前缀的请求 TTFT 可降 80%+(若 90% token 命中且 prefill 占 TTFT 的 90%,TTFT ≈ 原来的 1/10);多轮对话每轮只增量计算新增 token;多租户共享系统提示时单请求成本大幅下降。缓存淘汰: 树节点带引用计数与最后访问时间,显存容量不足时按 LRU 淘汰最久未访问的分支(类似操作系统页面置换),淘汰后再次命中需重算 prefill。对比 vLLM 的 automatic prefix caching: vLLM 按固定长度 block 做哈希前缀匹配(基于 token 的 n-gram 块哈希),实现简单;RadixAttention 用树精确复用任意长度的最长公共前缀,命中粒度更细、长共享前缀场景收益更高。

长系统提示的对话服务、Agent 多轮工具调用(每轮重发完整上下文)、RAG 检索 + 共享指令模板、多租户 SaaS;面试高频“TTFT 为什么降 80%”“RadixTree 怎么匹配前缀”“缓存淘汰策略”。

Prefill 是算力密集阶段,长 prompt 的重复 prefill 浪费 GPU 算力并拉高 TTFT;前缀 KV 复用让重复计算归零 —— 数值上命中率 80-90% 时 prefill 算力需求降一个数量级、TTFT 降 80%+,多轮/多租户场景单位 token 成本显著下降,是长上下文时代推理成本优化最直接的杠杆之一。

RadixTree 前缀复用原理: 新请求如何做最长前缀匹配;命中的前缀与未命中的后缀分别怎么处理;请求结束时树如何分裂/合并。

为什么 TTFT 能降 80%+: prefill 计算量正比于未命中 token 数;给出命中率与 prefill 占比的数值换算(prefill 占 TTFT 90% 时,90% 命中 → TTFT 约降 81%)。

缓存淘汰策略: LRU / 引用计数在基数树上怎么实现(逐分支淘汰);淘汰错误(驱逐热点前缀)对 hit rate 和 TTFT 的代价。

哪些场景收益最大: 系统提示、多轮对话、多租户共享;hint: 命中率与 token 节省如何估算,与连续批/PD 分离如何叠加。

vLLM prefix caching vs SGLang RadixAttention: block 哈希匹配 vs 基数树最长前缀匹配;命中粒度、实现复杂度、长共享前缀场景差异。