KV-aware Router 打分机制详解：缓存亲和性与负载均衡的工程实践

1. 从一次线上推理抖动说起KV-aware Router到底在解决什么去年帮一个团队排查线上推理服务的尾延迟抖动现象很典型同一批请求P50 稳定在 200ms 左右但 P99 会突然飙到 2s 以上而且抖动没有明显的时间规律。一开始怀疑是某个 Worker 的 GPU 被打满了但看监控所有 Worker 的利用率都在 60% 上下谁也没到瓶颈。后来把请求链路拆开看才发现问题出在路由层——请求被均匀地轮询分发到各个 Worker但每个 Worker 上已经缓存的 KV 前缀分布完全不同。有的请求命中了缓存首 token 延迟只有几十毫秒有的请求完全没命中需要从头做 prefill光这一项就吃掉了一秒多。这就是 KV-aware Router 要解决的核心问题。在大模型推理场景里KV Cache 是决定首 token 延迟的关键因素。一个请求如果能在已经缓存了相同前缀的 Worker 上执行就能跳过重复的 prefill 计算直接进入 decode 阶段。而传统的轮询或随机路由完全无视这个信息导致缓存命中率低、尾延迟高。KV-aware Router 的思路很直接在候选 Worker 里挑一个最划算的——既要有缓存亲和性又不能把某个 Worker 压垮。Dynamo 是这套思路的一个工程实现用 Rust 写的性能上比较讲究。它的 KV-aware Router 不是简单地谁缓存多就选谁而是给每个候选 Worker 打一个综合分分数由多个维度加权得出。这篇就围绕打分这件事展开把每个维度的设计意图、计算逻辑、参数取舍讲清楚。如果你正在做推理服务的路由优化或者单纯想理解一个生产级 Router 是怎么做决策的下面的内容应该能直接用上。2. 打分之前候选 Worker 是怎么被筛出来的2.1 候选集不是全部 Worker很多人一上来就想看打分公式但实际工程里打分只是最后一步。在打分之前Router 已经做了一轮粗筛。原因很简单如果集群有几百个 Worker对每一个都算一遍完整分数路由本身的开销就不可忽略了。Dynamo 的做法是先用轻量级的条件把候选集缩小再在候选集里做精细打分。粗筛通常包含几个维度。第一是健康状态心跳超时或正在重启的 Worker 直接排除这个没什么好说的。第二是负载水位如果一个 Worker 的并发请求数已经超过它的软上限或者显存占用超过阈值就先放到一边。第三是模型匹配不同 Worker 可能加载了不同的模型或不同的量化版本请求只能路由到匹配的 Worker 上。这三层筛完候选集通常从几百降到个位数到几十个。这里有个容易踩的坑粗筛的阈值不能设得太死。我见过有团队把显存阈值卡在 90%结果高峰期大量 Worker 被排除候选集只剩两三个反而造成热点。粗筛的目的是排除明显不合适的不是选出最优的精细判断留给打分阶段。2.2 候选集大小对打分策略的影响候选集的大小会直接影响打分的策略。如果候选集只有三五个那可以每个都算精确分数甚至可以做更复杂的组合优化。但如果候选集有几十个就得考虑打分开销和收益的平衡。Dynamo 在实现上对候选集做了上限控制超过一定数量会先按一个廉价指标比如缓存命中长度的粗略估计排序只保留 Top-N 进入精细打分。这个设计背后的逻辑是路由决策的收益是有边际递减的。从完全没命中到命中一半前缀收益很大但从命中 80%到命中 85%收益就小很多了。所以没必要为了最后那点精度把候选集铺得太大。实际调参时N 取 16 到 32 之间通常够用具体看集群规模和请求的前缀重复度。3. 缓存亲和性打分里权重最大的那一项3.1 前缀匹配长度怎么算缓存亲和性是 KV-aware Router 区别于普通 Router 的核心。它的基本逻辑是请求的 prompt 前缀如果在某个 Worker 的 KV Cache 里已经存在那这个 Worker 就能省掉这部分 prefill 计算。匹配的前缀越长省得越多分数越高。但前缀匹配长度这个事说起来简单算起来有讲究。请求的 token 序列和 Worker 缓存的 token 序列要做最长公共前缀匹配。这里不能按字符匹配必须按 token 匹配因为 KV Cache 是按 token 粒度存的。而且要注意 tokenizer 的一致性——如果不同 Worker 用了不同的 tokenizer 版本同样的文本可能切出不同的 token 序列匹配就会出错。生产环境里tokenizer 版本必须和模型版本绑定不能随意升级。匹配长度本身还要做归一化。一个 100 token 的前缀命中 50 token和一个 2000 token 的前缀命中 50 token意义完全不同。前者命中了一半后者只命中了 2.5%。所以打分时用的通常是命中比例或者命中长度经过某种饱和函数处理后的值。Dynamo 里对匹配长度做了对数饱和避免超长前缀的请求把分数拉得过高挤占其他请求的路由机会。3.2 缓存的时间衰减与失效风险KV Cache 不是永久有效的。Worker 上的缓存会随着新请求的进入被逐步淘汰也可能因为显存压力被主动清理。所以 Router 在打分时不能只看当前缓存里有没有还要考虑这个缓存还能活多久。一个实用的做法是给缓存命中加时间衰减因子。如果某个前缀是最近才被写入缓存的那它大概率还会保留一段时间命中收益比较可靠如果某个前缀已经很久没被访问了那它可能随时被淘汰命中的收益就要打个折扣。Dynamo 的实现里缓存条目会记录最后访问时间打分时根据这个时间做一个衰减计算。这个衰减因子的参数需要根据实际的缓存淘汰策略来调。如果 Worker 用的是 LRU 淘汰那衰减可以设得缓一些如果用的是更激进的策略衰减就要快一些。我一般会先观察缓存条目的平均存活时间然后把衰减半衰期设在这个时间附近效果比较稳。3.3 缓存亲和性和负载均衡的天然矛盾缓存亲和性越强路由就越倾向于把请求往少数几个缓存热的 Worker 上送这必然导致负载不均。这是 KV-aware Router 最核心的矛盾也是打分机制存在的意义——它不是在追求单一目标的最优而是在多个目标之间找平衡。实际调参时这个矛盾的激烈程度取决于请求的前缀分布。如果请求的前缀高度重复比如大量请求共享同一个 system prompt那缓存亲和性的收益很大可以给它更高的权重同时接受一定程度的负载不均。如果请求的前缀很分散那缓存命中的收益本来就有限就应该把权重更多给到负载均衡避免为了那点命中率把某个 Worker 压垮。4. 负载维度不只是看当前并发数4.1 瞬时并发和排队长度的区别负载这个维度最直觉的指标是当前并发请求数。但只看并发数是不够的因为不同请求的计算量差异很大。一个短 prompt 的请求和一个长 prompt 的请求占用的资源可能差一个数量级。所以更合理的做法是看排队长度或者看预估的剩余处理时间。Dynamo 的打分里负载项通常综合了几个信号当前活跃请求数、等待队列长度、最近一段时间的吞吐量。这几个信号各有侧重——活跃请求数反映当前压力队列长度反映积压趋势吞吐量反映处理能力。把它们组合起来比单看一个指标要稳得多。实测经验队列长度的权重不宜过高。因为队列长度波动很大一个突发请求就能让队列从 0 跳到 10。如果权重太高路由会变得很神经质频繁在 Worker 之间跳来跳去反而降低缓存命中率。我一般把队列长度的权重控制在总分的 15% 以内。4.2 负载预估用历史数据预测未来压力更进阶的做法是做负载预估。Router 可以根据 Worker 最近的处理速率预估它在接下来一小段时间内的负载情况。比如某个 Worker 当前并发不高但最近一秒内接收了大量请求那它很快就会变忙打分时就应该提前反映这个趋势。这个预估不需要很精确用一个简单的滑动窗口平均就够了。窗口大小取几秒比较合适——太短了噪声大太长了反应迟钝。Dynamo 里用的是指数移动平均对近期数据给更高权重这样既能反映趋势又不会因为单个突发而剧烈波动。4.3 异构 Worker 的处理能力差异还有一个容易被忽略的点Worker 之间可能不是同构的。有的 Worker 用的是 A100有的是 H100有的可能还混着不同显存大小的卡。同样的并发数在不同 Worker 上的实际压力完全不同。所以负载打分时要用归一化后的指标把 Worker 的处理能力考虑进去。具体做法是给每个 Worker 维护一个能力系数打分时用负载 / 能力系数作为归一化负载。能力系数可以通过压测得到也可以根据硬件规格估算。这个系数不需要很精确量级对了就行因为打分本身是个相对比较不是绝对测量。5. 打分公式的组装权重怎么定分数怎么比5.1 各维度分数的归一化处理在把各个维度的分数加权求和之前必须先做归一化。缓存亲和性的原始值是命中 token 数负载的原始值是并发数这两个量纲完全不同直接加权没有意义。归一化的目标是把每个维度都映射到 0 到 1 之间这样权重才有可比性。归一化的方法有几种。缓存亲和性可以用命中比例天然就在 0 到 1 之间。负载可以用当前负载除以最大承载能力也落在 0 到 1 之间。如果某个维度的分布很不均匀还可以用排名归一化——把候选 Worker 按这个维度排序用排名代替原始值。排名归一化的好处是对异常值不敏感缺点是丢失了绝对差异信息。Dynamo 的实现里缓存亲和性用的是饱和后的命中比例负载用的是归一化负载两者都在 0 到 1 之间。这样加权求和后总分也在 0 到 1 之间方便做阈值判断和比较。5.2 权重配置的实践建议权重怎么定没有标准答案取决于业务对延迟和吞吐的偏好。但有几个实践原则可以参考。如果业务对首 token 延迟极其敏感比如交互式对话缓存亲和性的权重应该高一些我一般会设到 0.6 到 0.7。如果业务更看重整体吞吐比如批量处理负载均衡的权重应该高一些可以到 0.5 以上。如果两者都要兼顾那就各占一半但要注意缓存亲和性的收益通常是非线性的实际效果可能偏向缓存一侧。权重配置最好做成可动态调整的而不是写死在代码里。因为业务负载模式会变高峰期和低谷期的最优权重可能不同。Dynamo 支持通过配置中心下发权重这样不用重启服务就能调参排查问题时很方便。5.3 平局怎么破次级排序键打分难免出现平局尤其是候选 Worker 状态相近的时候。这时候需要一个次级排序键来打破平局。次级键的选择也有讲究通常用一些开销小、区分度高的指标比如 Worker 的 ID 哈希、最近一次被选中的时间等。用最近被选中的时间做次级键有个好处它能起到隐式的轮询效果避免在分数相同时总是选中同一个 Worker。这在缓存亲和性权重不高的时候特别有用能防止某个 Worker 被反复选中而形成热点。6. 打分之外的工程细节缓存同步与一致性6.1 Router 怎么知道 Worker 上缓存了什么这是整个 KV-aware Router 最关键的工程问题。Router 要打分首先得知道每个 Worker 上缓存了哪些前缀。这个信息怎么来最直接的做法是 Worker 主动上报。每次缓存写入或淘汰时Worker 把变更同步给 Router。但这样同步量可能很大尤其是缓存频繁变动的时候。折中的做法是 Worker 定期上报缓存摘要比如用布隆过滤器或者前缀树的部分节点来表示缓存内容。布隆过滤器的问题是只能判断可能存在不能精确匹配长度前缀树更精确但同步开销大。Dynamo 的实现里缓存信息是通过一个轻量级的元数据通道同步的。Worker 只上报缓存条目的 key 和长度不上报完整的 token 序列。Router 侧维护一个全局的缓存视图用于打分。这个视图允许有一定的延迟和不一致因为打分本身是个概率决策不需要百分之百精确。6.2 缓存信息不一致时的兜底缓存视图和实际缓存不一致是常态不是异常。可能 Worker 刚淘汰了一个前缀但 Router 还没收到通知也可能 Router 认为某个前缀存在但实际已经被覆盖了。这种不一致会导致打分偏高但不会导致错误——请求发过去之后Worker 发现缓存没命中就正常做 prefill只是没省到时间而已。所以 KV-aware Router 的设计要容忍这种不一致。打分是尽力而为的优化不是正确性的保证。真正保证正确性的是 Worker 侧的缓存查找逻辑Router 的打分只是提高命中概率。理解这一点很重要它决定了整个系统的容错边界。6.3 缓存同步的频率与开销权衡同步频率是个需要权衡的参数。同步太频繁Router 和 Worker 之间的元数据流量大可能影响正常请求的处理同步太稀疏缓存视图滞后严重打分准确度下降。我的经验是同步频率应该和缓存的变动速率匹配。如果缓存变动很快比如请求前缀很分散缓存频繁淘汰同步频率就要高一些如果缓存比较稳定比如大量请求共享固定前缀同步频率可以低一些。Dynamo 里这个频率是可配置的默认值适合大多数场景但在极端场景下需要手动调整。7. 实测中的几个反直觉现象7.1 缓存命中率高不等于尾延迟低这是我在压测中印象最深的一点。有一次调参把缓存亲和性权重拉满缓存命中率从 40% 提到了 75%但 P99 延迟反而变差了。排查后发现高权重导致请求过度集中在少数几个缓存热的 Worker 上这些 Worker 的队列排得很长虽然命中了缓存省了 prefill但排队时间把省下的时间又吃回去了。这个现象说明缓存亲和性和负载均衡必须一起看不能单独优化。命中率是个中间指标不是最终目标。最终目标是端到端延迟而端到端延迟是排队时间加计算时间的总和。只看命中率很容易掉进局部最优的陷阱。7.2 短请求对缓存不敏感另一个反直觉的发现是短请求prompt 很短对缓存亲和性几乎不敏感。因为短请求的 prefill 计算量本来就小命中缓存省下的时间有限但为了命中缓存而绕路或排队的成本却是实打实的。所以对短请求路由策略应该更偏向负载均衡。Dynamo 的打分里其实隐含了这个逻辑——缓存亲和性的分数是饱和的短请求的命中长度本来就短饱和后的分数不高自然就不会主导决策。但如果你的实现里没有做饱和处理就需要显式地按请求长度做区分。7.3 预热期的路由策略要单独设计服务刚启动或者扩容后所有 Worker 的缓存都是空的这时候缓存亲和性维度完全没有信息量打分退化成纯负载均衡。这个阶段的路由策略需要单独考虑不能直接套用稳态的策略。一个实用的做法是在预热期降低缓存亲和性的权重甚至暂时关闭这个维度等缓存积累起来再逐步恢复。Dynamo 里可以通过配置在启动时设置一个预热标志Router 检测到这个标志就切换到预热策略。这个细节在文档里往往不会写但实际运维中很关键。8. 自己实现一个打分器要注意什么8.1 打分开销必须可控Router 本身也是服务它的处理能力是有限的。如果打分逻辑太复杂单个请求的路由耗时就会上升在高 QPS 下成为瓶颈。所以打分逻辑要尽量简单避免复杂的计算和锁竞争。具体来说打分用到的数据应该尽量是内存里的、无锁的。缓存视图可以用读多写少的数据结构负载数据可以用原子变量。避免在打分路径上做 IO 或加锁这些都会成为性能杀手。Dynamo 用 Rust 实现很大程度上就是为了在保证安全的同时把开销压到最低。8.2 打分结果要可观测打分是个黑盒决策如果不做可观测出问题时根本没法排查。所以每次路由决策的关键信息都要记录下来候选集有哪些、每个候选的各维度分数是多少、最终选中了谁、为什么。这些信息可以采样上报不需要全量但采样率不能太低否则偶发问题抓不到。我一般会在 Router 里加一个调试接口能对指定请求回放打分过程。这个接口在排查为什么这个请求被路由到了那个 Worker这类问题时特别有用。没有这个排查基本靠猜。8.3 参数调优要有数据支撑打分涉及一堆参数权重、阈值、衰减系数、饱和参数等等。这些参数不能拍脑袋定必须用真实流量或压测数据来调。调优的目标函数要明确——是优化 P99 延迟还是优化吞吐还是优化成本。目标不同最优参数完全不同。调优的方法可以先用网格搜索找大致范围再用贝叶斯优化做精细调整。但要注意参数对流量模式很敏感在一个流量模式下调好的参数换一个模式可能就不行了。所以参数要定期回顾不能一劳永逸。9. 写在最后的一点个人体会KV-aware Router 的打分机制本质上是在信息不完全的情况下做一个概率性的优化决策。它不追求每次决策都最优而是追求整体期望最优。理解这一点很多设计上的取舍就说得通了——为什么允许缓存视图不一致为什么打分要饱和为什么权重需要动态调整都是因为这个本质。我在实际项目里最大的体会是不要试图把打分做得太聪明。越复杂的打分逻辑越难调参越容易在边界情况下出问题。反而是那些简单、可解释、参数少的方案在长期运维中更稳。Dynamo 的打分逻辑拆开看每个维度都不复杂组合起来却能解决实际问题这个平衡点找得挺好。如果你正在做类似的路由优化建议先从最简单的两维度打分开始——缓存亲和性加负载跑起来看效果再逐步加维度。每加一个维度都要问自己它带来的收益能不能覆盖它增加的调参复杂度和排查难度。这个账算清楚了方案就不会跑偏。