@_avichawla:前缀感知的 LLM 路由,一文讲清楚!(让首个 LLM token 提前 170 倍生成的技巧)生产环境中的提示词通常以相

X AI KOLs Timeline 新闻

摘要

文章清晰解释了前缀感知的 LLM 路由机制:通过按块哈希提示词并维护块到 worker 的索引,让请求路由到持有共享前缀 KV 缓存的 GPU,实测在 8 个 vLLM Pod(16 张 H100)上将 p90 首 token 延迟从 92.5 秒降至 0.54 秒。

前缀感知的 LLM 路由,一文讲清楚! (让首个 LLM token 提前 170 倍生成的技巧) 生产环境中的提示词通常以相同的 system prompt、工具定义和历史对话轮次开头,只有每个请求的最后一部分是新的。 因此,上一轮服务请求的 GPU 仍然持有这段共享前缀的 KV 缓存,但一个对缓存无感知的路由器可能会把下一个请求发送到另一个 GPU,而后者必须重新计算整个前缀,才能生成第一个 token。 前缀感知的路由器通过追踪每个提示词的哪一部分存储在哪个 GPU 上来避免这种浪费。 下面的图示展示了它的工作原理: ↳ 当一个请求携带前缀块 A 到 D 以及新的后缀 E 到达时,路由器会逐块对提示词进行哈希计算,因此每个哈希值都包含了它之前的所有内容。 ↳ 它会在块到 worker 的索引中查找这些哈希值,该索引只存储位置信息,而不存储 KV 张量本身。 ↳ Worker A 持有 2 个匹配块,Worker C 持有 3 个,而 Worker B 持有全部 4 个,所以请求被分配给 Worker B。 ↳ Worker B 复用 A 到 D 的缓存 KV,只为 E 计算 KV,然后开始解码。 ↳ 一旦 E 被缓存,缓存事件会更新路由器的索引,这样下一轮请求也会落到 Worker B 上。 如果没有 worker 匹配,请求就会在路由器选择的任意 worker 上执行完整的 prefill。 在一个广受欢迎的基准测试中,使用跨 16 张 H100 的 8 个 vLLm Pod,前缀感知路由将 p90 首 token 延迟降至 0.54 秒,而在相同的 Pod 上随机路由需要 92.5 秒。 实际的路由器还会在缓存匹配的基础上综合考虑负载情况,以避免缓存最热的 GPU 接到最长的队列。 所有这一切都依赖于前缀缓存本身正常工作,提示词早期的一个小改动可能会导致其后的每一个块都缓存未命中。 我在一篇详细文章中介绍了前缀缓存的工作原理,以及提示词修改如何导致缓存未命中。 请在下方阅读。
查看原文
查看缓存全文

缓存时间: 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 不会因此排上最长的队列。

所有这些都依赖于前缀缓存本身能够正常工作——提示词开头部分的微小改动,就可能导致其后的所有块全部缓存未命中。

我在一篇详细的文章中介绍了前缀缓存的工作原理,以及提示词变化如何导致缓存未命中。

请在下方阅读。

相似文章