
随着大语言模型线上应用的普及,检索增强生成、多轮对话、智能体管线等场景的请求往往会携带大量重复的文档上下文、系统提示或对话历史,推理流程也逐步进入prefill占主导的阶段。前缀缓存技术通过复用公共前缀的KV缓存,已经成为这类场景下提升推理效率的核心手段,但其实际收益高度依赖调度器对请求批次的组织效率。在近年快速普及的混合大语言模型架构下,原有默认调度策略的适配缺陷逐渐显现,会产生不必要的执行气泡浪费算力资源。

论文标题:RadixFlow: Filling Execution Bubbles in Prefix-Cached Hybrid LLM Serving
论文链接:https://arxiv.org/pdf/2610.18143
开源集成:相关技术已全部实现并集成至 vllm-jev
研究背景
前缀缓存的核心逻辑是提前存储公共前缀的计算状态,新请求匹配到对应前缀后就不需要重新计算这部分内容,直接复用缓存状态即可。在传统全注意力架构的大语言模型中,只要前缀匹配成功,调度器就能直接调用对应的KV缓存执行请求,这套逻辑运行得十分顺畅。但混合大语言模型(融合了结构化状态空间模型、Mamba等架构的模型)打破了这个假设,这类模型恢复执行时除了需要KV缓存之外,还需要前缀匹配边界处的循环状态、卷积状态,否则无法正常运行。
如果同一个工作轮次中,生成某组状态的生产者分支和需要读取该状态的消费者分支同时进入调度队列,消费者分支就会因为状态还未完成生成出现同轮依赖,无法进入当前批次。原有vLLM的调度逻辑碰到分配失败的请求就会直接停止等待队列的扫描,导致队列后方已经满足状态要求、也符合剩余资源预算的独立请求无法被选中,空出来的批次槽位就成了可避免的执行气泡。这种头阻塞问题在前缀共享率高的场景下会造成大量的算力浪费,原本可以塞满的批次出现不必要的空缺,请求延迟也会随之上升。

RadixFlow核心设计思路
RadixFlow的核心优化思路是将前缀匹配和状态就绪两个判断逻辑解耦,把原本的全局扫描障碍转化为单个请求的局部等待,在不修改原有缓存存储、原生状态检查逻辑的前提下,尽可能填满每个批次的可用容量。
其核心机制是状态就绪遍历:调度器按照原生顺序扫描等待队列时,会对每个请求调用原生的状态检查逻辑,如果请求状态就绪、资源也足够,就正常加入当前批次;如果请求是因为同轮依赖被阻塞的消费者,就把它放入单独的等待队列,留到下一轮再重新检查状态,不会停止整个队列的扫描,后续符合要求的独立请求可以正常加入当前批次;如果是其他原因导致的分配失败,比如资源预算耗尽、分配异常等,还是保留原生的处理逻辑。这种设计保证了每一轮选中的批次都是原生调度批次的超集,不会漏过任何本来可以执行的请求,也不会引入不符合状态要求的错误请求。
除了核心的遍历机制之外,RadixFlow还搭配了灵活的准入控制:设置了5ms的等待窗口,先收集短时间内到达的请求再统一扫描,如果等待过程中批次已经占满槽位或者词元预算,就提前释放批次开始执行,平衡批次大小和等待延迟。另外还有可选的碎片化扩展优化,当剩余预算不足以让请求跑完一个对齐段时,暂时推迟该请求,寻找其他更适合的请求填充,减少碎片化带来的资源浪费。

实验效果验证
为了验证RadixFlow的实际效果,研究团队在vLLM 0.29的基础上实现了整套方案,在A800 GPU上进行了测试。实验选取了4款Qwen3.5系列混合模型(0.8B、4B、9B、27B)、Mamba2架构的Nemotron-9B混合模型,以及全注意力架构的Qwen3-8B作为对照组。Workload来自QuALITY和RACE阅读理解数据集,每个问题对应4个候选答案的打分请求,同个问题的多个请求共享文档前缀,高度贴合实际RAG、多候选打分场景的prefill特征。所有调度策略共享前缀索引、原生状态检查、模型权重和缓存原语,仅修改调度规则,保证对比的公平性。
实验结果显示,在5款混合模型上,RadixFlow相比原生的Radix调度,平均延迟降低了3%到24%,工作轮次减少了11%到44%,同时前缀复用率仅相差不到0.03个百分点,几乎没有影响缓存的复用效率。在吞吐量方面,Qwen3.5-4B、9B、27B的**完成吞吐量分别提升了4.2%、4.0%和3.0%**,轻负载的Qwen3.5-0.8B和Nemotron-9B场景下,吞吐量维持和基线一致的同时请求延迟明显下降。
通过消融实验可以看到,状态就绪遍历是收益的主要来源:在Qwen3.5-27B上,仅用灵活准入只能减少1.6%的轮次,加上遍历机制后轮次直接减少44% ,即使是没有跨请求前缀共享的冷流场景,同个请求内部的多分支也会产生同轮依赖,遍历机制依然能带来收益。而在全注意力的对照组上,遍历机制几乎没有带来额外收益,验证了该优化是针对混合大语言模型的同轮依赖问题定向设计的。
研究团队还对轮次减少和延迟收益的差异做了分析:RadixFlow填充了原本闲置的槽位,每个轮次的工作量更大,单轮的处理时间会有所上升,但整体资源利用率更高,每千个调度词元的处理成本反而有所下降,比如Qwen3.5-27B的单千词元处理成本从183ms降到了175ms,最终整体延迟依然有明显下降。从请求分布来看,RadixFlow不仅降低了平均延迟,p95、p99等长尾延迟也有明显优化,比如Qwen3.5-9B的p95延迟从73.3s降到了70.6s,Nemotron-9B的p95延迟从15.8s降到了13.3s。



适用场景与落地价值
RadixFlow的优化特别适合当前主流的混合大语言模型线上部署场景,尤其是前缀共享率较高的RAG问答、多候选打分、批量推理等场景。由于整套方案只修改了调度的批次构建逻辑,不需要调整模型结构、缓存存储逻辑,也不需要额外的状态存储开销,落地成本极低,而且相关代码已经集成到vllm-jev中,开发者可以直接复用。
当然目前的方案也存在一定的局限性,当前实验主要针对单token生成的prefill主导场景,后续还可以进一步扩展到长生成、动态负载等更复杂的生产环境场景,探索更大的优化空间。
整体来看,RadixFlow为混合大语言模型的调度优化提供了一个轻量且高效的思路,通过把同轮依赖导致的全局队列阻塞转化为单个请求的局部等待,充分挖掘了现有算力的利用空间,在几乎不损失缓存复用率的前提下实现了明显的延迟和吞吐量提升,为混合大语言模型的大规模落地提供了新的调度优化方向。
> 本文由 AI 生成,机智流编辑部校对
-- 完 --
机智流推荐阅读:
1.
2.
3.
4.
cc | 大模型技术交流群 hf | HuggingFace 高赞论文分享群 lc|LangChain 技术交流群 code | AI Coding 交流群 具身 | 具身智能交流群 硬件 | AI 硬件交流群 推理 | AI 推理框架交流群 智能体 | Agent 技术交流群