@_avichawla:前缀感知的 LLM 路由,一文讲清楚!(让首个 LLM token 提前 170 倍生成的技巧)生产环境中的提示词通常以相
摘要
文章清晰解释了前缀感知的 LLM 路由机制:通过按块哈希提示词并维护块到 worker 的索引,让请求路由到持有共享前缀 KV 缓存的 GPU,实测在 8 个 vLLM Pod(16 张 H100)上将 p90 首 token 延迟从 92.5 秒降至 0.54 秒。
查看缓存全文
缓存时间: 2026/10/29 16:03
前缀感知的 LLM 路由,一文讲清!
(让首个 LLM token 提前 170 倍生成的技巧)
在生产环境中,请求的提示词往往以相同的系统提示、工具定义和历史对话开头,只有最后一部分是每条请求独有的。
因此,处理上一轮对话的 GPU 上仍然保留着这段共享前缀的 KV 缓存,但一个“缓存盲“的路由器可能会把下一个请求发送到另一块 GPU,而那块 GPU 必须重新计算整个前缀才能生成第一个 token。
前缀感知路由器通过追踪每段提示词的哪一部分缓存在哪块 GPU 上,来避免这种浪费。
下面的图示展示了它的工作原理:
↳ 当一个请求到达,携带前缀块 A 到 D 以及一个新的后缀 E 时,路由器会对提示词逐块进行哈希,每次哈希都包含它之前的所有内容。
↳ 路由器用这些哈希值在“块到工作节点“的索引中查找,该索引只存储位置信息,绝不存储 KV 张量本身。
↳ 工作节点 A 持有 2 个匹配块,工作节点 C 持有 3 个,而工作节点 B 持有全部 4 个匹配块,所以请求被路由到工作节点 B。
↳ 工作节点 B 复用 A 到 D 的缓存 KV,只为 E 计算 KV,然后开始解码。
↳ 一旦 E 被缓存,缓存事件会更新路由器的索引,因此下一轮对话也会路由到工作节点 B。
如果没有工作节点存在匹配项,请求就会在路由器选定的任意工作节点上进行完整的预填充计算。
在一个广受欢迎的基准测试中,使用 8 个 vLLM Pod(共 16 块 H100),前缀感知路由将 p90 首 token 延迟降至 0.54 秒,而在同样的 Pod 上使用随机路由则需要 92.5 秒。
真实的路由器还会综合考虑负载情况,而不仅仅是缓存匹配,这样缓存最热的 GPU 不会因此排上最长的队列。
所有这些都依赖于前缀缓存本身能够正常工作——提示词开头部分的微小改动,就可能导致其后的所有块全部缓存未命中。
我在一篇详细的文章中介绍了前缀缓存的工作原理,以及提示词变化如何导致缓存未命中。
请在下方阅读。
相似文章
@_avichawla: LLM推理中的预填充与解码。你是否注意到,LLM的第一个令牌总是需要片刻才出现…
解释LLM推理的两个阶段——预填充和解码,详细说明GPU瓶颈如何从预填充时的计算受限转变为解码时的内存受限,以及KV缓存的重要性。
@akshay_pachaar: vLLM 如何避免一个长 prompt 拖慢其他请求:(分块预填充,讲得明明白白)每个 LLM 请求都有两个阶…
一篇技术解析,介绍 vLLM 的分块预填充(chunked prefill)如何防止长 prompt 阻塞并发的解码请求,涵盖延迟权衡、混合批处理,以及 vLLM V1 中的 `--max-num-batched-tokens` 参数。
@_avichawla:LLM 调度循环,清晰讲解:(收藏这篇)每当用户向 LLM 发送一个 prompt,生成的推……
一篇讲解 LLM 服务调度循环的教学文章,解释推理请求如何经过等待队列、批量构建、prefill、decode 和 continuous batching,使 GPU 在不同请求先后完成时仍保持满载运行。
@navaneethvb: 对于想知道 LLM 推理在实际生产环境中究竟是如何运作的人,尤其是路由部分,这就是当请求到达 GPU 集群时的样子……
一篇关于 LLM 推理请求在实际生产环境中到达 GPU 集群后如何进行路由的技术解释。
@akshay_pachaar:我会学习的 12 种 KV 缓存技术,用于优化 LLM 推理。LLM 每次生成一个 token,但每个新 token ……
该推文总结了优化 LLM 推理的 12 种 KV 缓存技术,包括滑动窗口、跨层共享、MLA、量化、前缀复用、分页、驱逐和 GQA/MQA 等,帮助开发者根据具体瓶颈选择合适的组合。