★ FEATURED ARTICLE 1. 从Dynamo系列说起ThunderAgent到底在解决什么问题如果你最近在关注大模型推理服务这块大概率会频繁刷到Dynamo这个词。它不是一个孤立的工具而是一整套围绕大模型推理部署与调度构建的技术体系。而ThunderAgent正是这个体系里一个非常关键的组件——它承担的是智能体式调度的角色把请求路由、KV缓存感知、任务编排这几件事捏合到一起。先把背景说清楚。大模型推理服务在真实生产环境里最贵的资源从来不是GPU的算力峰值而是显存带宽和KV缓存。一个请求进来Prefill阶段要算一遍完整的注意力生成一大块KV缓存Decode阶段每生成一个token都要反复读取这块缓存。如果调度器只会轮询或者看谁空闲就发给谁那KV缓存就会被反复搬运、反复重算GPU利用率看着挺高实际吞吐却上不去。ThunderAgent要解决的核心矛盾就是这个让请求的调度决策感知到KV缓存的位置和状态。围绕它衍生出来的几个关键词——KV-Aware Router、ThunderAgentScheduler、KvRouter——其实指向的是同一件事的不同侧面。KV-Aware Router负责看缓存做路由ThunderAgentScheduler负责编排调度策略KvRouter则是这套路由能力的具体实现载体。这篇内容适合谁看如果你正在做推理服务的部署优化或者你在研究PD分离Prefill-Decode分离架构下的调度问题又或者你只是好奇为什么同样几张卡别人吞吐能高出一截那这篇值得往下读。我会尽量把原理讲透把实操里容易踩的坑摊开说也会给出可以直接参考的配置思路。需要提前说明的是ThunderAgent这类组件目前公开的完整文档并不算多很多细节散落在代码和issue里。下面涉及具体参数和配置的部分我会基于这类KV感知调度系统的通用设计逻辑来补全并明确标注哪些是常见实践推断哪些是相对确定的机制。你照着思路走具体数值按自己的硬件和模型规模调。2. KV-Aware Router的工作机制为什么看缓存路由比看负载路由更聪明2.1 传统负载均衡在大模型推理场景下的失效大部分人第一次搭推理服务用的都是最朴素的负载均衡N个worker来一个请求就发给当前连接数最少的那个。这套逻辑在无状态服务里没问题但大模型推理是有状态的——每个worker上都驻留着一部分KV缓存这些缓存对应着之前处理过的对话上下文。举个具体场景。用户A发起了一轮多轮对话第一轮请求被路由到worker-3worker-3上就存了这段对话的KV缓存。第二轮请求进来如果负载均衡器看到worker-1最闲把请求发给了worker-1那worker-1就得从头把整个对话历史重新Prefill一遍。这一遍Prefill的代价可能比Decode本身还大。更糟的是worker-3上那份缓存变成了孤儿占着显存却没人用直到被LRU淘汰。所以传统负载均衡的问题不是不均衡而是均衡的维度错了。它均衡的是连接数或请求数但真正稀缺的资源是KV缓存和它背后的显存带宽。2.2 KV-Aware Router的决策逻辑拆解KV-Aware Router的思路是路由决策时优先考虑这个请求的上下文在哪个worker上已经有缓存。它的决策链路大致是这样的请求进来先提取它的缓存指纹——通常是对对话历史或prefix做哈希得到一个能标识这段上下文的key。拿这个key去查全局的缓存索引表看哪些worker上命中。如果命中优先路由到命中worker如果多个worker都命中再结合负载、显存余量做二次排序。如果完全没命中才退回到常规的负载均衡策略。这里有个关键设计点缓存索引表怎么维护。常见做法是每个worker定期上报自己持有的缓存key列表Router侧维护一个近似索引。之所以说近似是因为精确同步的开销太大而且缓存随时可能被淘汰。所以Router的命中判断允许有一定误差命中失败最多退化成重新Prefill不会出错。提示缓存指纹的粒度选择很讲究。按整个对话历史做哈希命中率会随对话轮次增长而下降按固定长度的prefix做哈希命中率更稳定但可能丢失长上下文的复用机会。实践中常见的是分层哈希——短prefix用粗粒度长上下文用细粒度。2.3 命中率与调度开销的权衡KV-Aware Router不是命中率越高越好。这里有个反直觉的点过度追求缓存命中会导致负载倾斜。设想一个热门对话被反复请求所有请求都往持有该缓存的worker上挤这个worker很快就会被压垮而其他worker闲着。所以Router必须有一个命中收益 vs 负载代价的权衡机制。常见做法是给命中加一个权重但这个权重会随目标worker的负载上升而衰减。负载越高命中的吸引力越低请求就越可能被分流到其他worker去重新Prefill。这个权衡的调参是ThunderAgent这类系统里最考验经验的地方。权重给高了热点worker被打爆给低了缓存复用率上不去等于白做。我个人的经验是先用一个中等偏保守的权重跑起来观察热点worker的显存和队列深度再逐步微调。3. ThunderAgentScheduler的调度策略从路由到编排的跨越3.1 调度器不只是分发请求如果说KV-Aware Router解决的是这个请求该去哪那ThunderAgentScheduler解决的是这一批请求该怎么排。这两件事经常被混为一谈但在高并发场景下它们的职责边界其实很清楚。Router是单请求视角的它关心的是单个请求的最优落点。Scheduler是全局视角的它关心的是整个集群在接下来一段时间内的吞吐和延迟表现。一个请求单独看路由到了最优worker但放到全局看可能造成某个worker的队列积压反而拖累了整体。ThunderAgentScheduler的核心能力我理解下来主要有三块批处理编排、优先级调度、以及和PD分离架构的协同。3.2 连续批处理与调度窗口大模型推理的吞吐很大程度上取决于批处理效率。静态批处理等一批请求凑齐再一起算延迟高连续批处理Continuous Batching请求随到随进随出吞吐好但调度复杂。ThunderAgentScheduler在连续批处理的基础上引入了一个调度窗口的概念。它的逻辑是不立即把每个到达的请求塞进当前批次而是攒一个很短的时间窗口比如几毫秒到几十毫秒在这个窗口内到达的请求一起做调度决策。这样做的好处是调度器能看到一小批请求的全貌从而做出更优的批组合——比如把prefix相同的请求尽量排在一起让KV缓存的复用最大化。窗口长度的选择是个典型的延迟-吞吐权衡。窗口越长批组合越优吞吐越高但请求的排队延迟也越大。对于在线对话场景窗口通常设得很短对于离线批处理场景可以设得长一些。3.3 优先级与抢占长请求不该堵住短请求真实场景里请求的长度差异极大。一个生成10个token的短请求和一个生成2000个token的长请求如果排在同一个队列里按FIFO处理短请求会被长请求堵死。这在对话场景里是致命的——用户问一句你好等了三秒才回体验直接崩了。ThunderAgentScheduler的优先级机制通常会给短请求更高的优先级或者采用最短剩余时间优先的变体。更激进的做法是支持抢占当一个高优先级短请求到达时如果当前批次里全是长请求调度器可以暂停某个长请求的Decode先把短请求插进去算完再恢复长请求。抢占的代价是长请求的KV缓存要保留在显存里等待恢复这会占用额外显存。所以抢占不能太频繁通常要设一个阈值——只有当短请求的预期收益超过抢占开销时才触发。3.4 与PD分离架构的协同PD分离Prefill和Decode跑在不同实例上是现在推理服务的主流架构之一。Prefill实例算力密集Decode实例显存带宽密集分开部署能让各自的资源利用率更高。但分离之后KV缓存要从Prefill实例传到Decode实例这个传输开销就成了新的瓶颈。ThunderAgentScheduler在这里的作用是协调Prefill和Decode的节奏。它要保证Prefill产出的KV缓存能及时被对应的Decode实例消费而不是堆在传输队列里。常见做法是给Prefill和Decode之间设一个在途缓存的上限超过上限就暂停新的Prefill避免传输链路被打爆。下面这张表是我整理的几种调度策略对比方便你按场景选调度策略适用场景吞吐表现延迟表现实现复杂度轮询负载均衡无状态短请求中中低KV感知路由多轮对话、prefix复用高高低中连续批处理高并发在线服务高中中优先级抢占长短请求混合中高低高PD分离协同调度大规模集群最高低最高4. KvRouter的落地细节缓存索引、失效处理与热点打散4.1 缓存索引表怎么建、怎么查KvRouter是KV-Aware Router的具体实现它的核心是一张缓存索引表。这张表的建法直接决定了路由的准确性和开销。我见过几种做法。最简单的是中心化索引所有worker把缓存key上报到一个中心节点Router查这个中心节点。好处是查询快、一致性好坏处是中心节点容易成为瓶颈而且worker数量一多索引同步的延迟就上来了。另一种是分布式索引每个Router节点维护一份局部索引worker的缓存变更通过 gossip 协议扩散。好处是没有单点扩展性好坏处是索引有延迟可能查到过期的命中信息。实践中比较稳的是混合方案热点缓存key走中心化索引保证准确冷门key走分布式索引容忍延迟。这样既保证了高频场景的命中率又避免了中心节点的全量压力。查询的时候还有个细节索引的key用什么。如果用完整的对话历史做key那每次对话新增一轮key就变了索引里会堆积大量前缀相同但后缀不同的条目。更好的做法是用滚动哈希——只对最近N轮做哈希或者对prefix做分段哈希让索引条目能复用。4.2 缓存失效与一致性处理缓存失效是KvRouter最容易出问题的地方。worker上的缓存可能因为显存不足被淘汰可能因为worker重启丢失也可能因为请求超时被主动清理。如果Router不知道这些失效就会把请求路由到一个以为有缓存、实际没有的worker上导致命中失败。处理失效有几种思路TTL机制给每个索引条目设一个存活时间超时自动失效。简单但不够精确TTL设短了误判多设长了失效缓存被反复命中失败。主动上报worker在淘汰缓存时主动通知Router。精确但增加通信开销而且worker崩溃时来不及上报。惰性校验Router路由后worker在真正处理前校验缓存是否存在不存在就回退。这是兜底机制必须有但不能作为主要手段因为回退的代价是重新Prefill。我的建议是三者结合TTL做粗筛主动上报做精修惰性校验做兜底。这样即使某一层出问题也不会导致系统性故障。4.3 热点打散当所有人都想用同一份缓存前面提过热点worker的问题这里展开说下KvRouter层面的打散手段。最直接的是副本机制对于特别热的缓存主动在多个worker上复制一份。这样请求可以分散到多个worker每个都能命中。副本的代价是显存翻倍所以只对真正热的缓存做而且要设一个副本数上限。另一种是请求合并如果多个请求要复用同一份缓存做相同的Prefill可以把它们合并成一个批次一起算算完再把结果分发给各自的Decode。这样热点worker的压力就从处理N个请求降到处理1个合并请求。还有一种偏工程的手段是缓存迁移当某个worker的缓存过热时主动把一部分缓存迁移到空闲worker上。迁移的开销不小所以通常只在负载严重倾斜时才触发。注意热点打散的所有手段都有代价没有免费的午餐。副本吃显存合并吃调度复杂度迁移吃带宽。选哪种取决于你的瓶颈在哪。显存富裕就上副本调度能力强就上合并带宽富裕就上迁移。5. 实操中容易踩的坑从参数配置到监控盲区5.1 缓存指纹的哈希冲突这是个隐蔽的坑。缓存指纹通常是对上下文做哈希哈希就有冲突的可能。两个不同的对话哈希到了同一个keyRouter就会误判命中把请求路由到错误的worker上。worker一校验发现缓存对不上回退重新Prefill性能就崩了。哈希冲突的概率取决于哈希空间的大小。用64位哈希冲突概率极低但也不是零。更稳妥的做法是双哈希校验用两个不同的哈希函数各算一个key两个都命中才算真命中。代价是索引表翻倍但换来的是可靠性。我踩过一次这个坑当时用的是32位哈希在几十万条缓存条目下冲突开始变得可观测。表现就是偶发的、无法解释的Prefill重算。后来换成64位加双哈希问题消失。5.2 调度窗口设得太长导致延迟毛刺调度窗口这个参数调起来很微妙。设短了批组合效果差吞吐上不去设长了请求排队延迟增加P99延迟会出现明显毛刺。我见过一个案例有人为了追求吞吐把窗口设到了100毫秒。结果平均吞吐确实涨了但P99延迟从200毫秒飙到了1.5秒。用户侧的感受就是大部分时候很快但偶尔卡一下这种体验比稳定慢一点还糟糕。经验值是在线对话场景窗口不超过10毫秒离线批处理可以到50毫秒以上。而且窗口应该是自适应的——负载低时窗口短负载高时窗口长这样能在不同负载下都保持较好的延迟-吞吐平衡。5.3 监控指标的盲区大部分人对推理服务的监控停留在GPU利用率、显存占用、QPS这些指标上。但ThunderAgent这类系统有几个关键指标是常规监控覆盖不到的缓存命中率路由到有缓存的worker的请求占比。这个指标低说明KV-Aware路由没起作用。缓存复用率命中的缓存中实际被复用的比例。命中不等于复用可能命中了但缓存已经过期。Prefill重算率因为缓存未命中而重新Prefill的请求占比。这个指标直接反映浪费。热点worker的队列深度判断负载是否倾斜。这几个指标建议单独做面板监控。尤其是Prefill重算率它是衡量整个KV感知调度体系是否有效的核心指标。5.4 参数配置的常见误区最后说几个参数配置上的误区都是实际踩过的第一个误区是把缓存权重设得过高。前面说过权重过高会导致热点worker被打爆。很多人一看命中率上去了就以为调对了其实吞吐可能反而降了因为热点worker成了瓶颈。第二个误区是忽略缓存淘汰策略的影响。KvRouter的路由决策依赖缓存索引但缓存索引的准确性又依赖worker的淘汰策略。如果worker用的是激进的LRU缓存淘汰很快索引里的条目大量失效路由准确性就崩了。所以淘汰策略要和路由策略一起调不能分开看。第三个误区是PD分离下Prefill和Decode的缓存索引不统一。Prefill实例产出的缓存和Decode实例消费的缓存如果索引不统一就会出现Prefill算了但Decode找不到的情况。这个必须在架构层面保证一致。6. 从ThunderAgent看KV感知调度的演进方向把ThunderAgent拆解到这一步其实能看出KV感知调度这个方向的几个演进趋势。第一个趋势是调度决策的粒度越来越细。从最早的请求级调度到现在的token级、甚至注意力头级的调度。粒度越细优化的空间越大但调度开销也越高。未来大概率是分层调度——粗粒度用轻量策略细粒度用重策略按需切换。第二个趋势是缓存和计算的进一步解耦。现在KV缓存还是绑在worker上的未来可能会走向独立的缓存层计算实例和缓存实例分开扩缩容。这样缓存的利用率能更高但一致性维护的复杂度也上去了。第三个趋势是调度策略的学习化。现在ThunderAgentScheduler的策略还是基于规则的权重、阈值都是人调的。未来可能会引入在线学习让调度器根据实时的负载和命中情况自动调整策略。不过这条路还很长规则引擎在可解释性和稳定性上仍有优势。如果你现在就要落地一套KV感知调度我的建议是不要一上来就追求全功能。先把KV-Aware Router跑通把缓存命中率和Prefill重算率这两个指标监控起来看到实际收益之后再逐步引入优先级调度、抢占、热点打散这些高级能力。每一步都要有指标验证不要凭感觉调参。这套东西的复杂度确实不低但收益也是实打实的。在显存带宽成为瓶颈的当下KV感知调度带来的吞吐提升往往比换更贵的卡更划算。
阅读完成 · 觉得有帮助？
