Chimera: Latency- and Performance-Aware Multi-agent Serving for Heterogeneous LLMs

[pentium3]

https://arxiv.org/pdf/2603.22206

[pentium3]

这篇是 Chimera: Latency- and Performance-Aware Multi-agent Serving for Heterogeneous LLMs。一句话：它不是在训练一个更聪明的 multi-agent，而是在做一个 heterogeneous LLM serving scheduler：面对一个多阶段 agent workflow，每个 LLM call 到底送给哪个模型、进哪个队列、怎么按优先级调度，从而同时压低 E2E latency、维持/提升 task performance。 ([arXiv][1])

1. 它解决的问题是什么？

作者的观察是：现在很多 LLM 应用不是单次请求，而是 multi-stage workflow，比如 planner → coder → verifier → coder；每一阶段都是一次 LLM call，前一阶段输出会进后一阶段上下文。传统 serving 系统通常假设同质集群，也就是一堆相同模型 replica；但真实部署里经常有多个不同大小、不同能力、不同速度的模型，所以“选哪个模型”本身会影响性能、延迟和队列拥塞。([arXiv][1])

他们把目标定义成一个 latency–performance Pareto frontier 问题，而不是简单把延迟和准确率加权成一个 scalar objective。也就是说，系统好不好看的是：能不能在同样 performance 下更快，或者在同样 latency 下性能更高。([arXiv][1])

2. Chimera 的核心设计

Chimera 是夹在 multi-agent application 和后端 vLLM inference engines 之间的一层 middleware。它有四个模块：Semantic Router、Length Predictor、Activity Monitor、Load Balancer。对每个 incoming request，它估计每个模型的成功置信度、预测当前 workflow 剩余总输出 token 数、统计每个 engine 当前 in-flight token workload，然后决定这个 request 派给哪个模型、用什么优先级排队。([arXiv][1])

它的调度逻辑大概是：

第一，先选模型。Semantic Router 会给每个候选模型一个 confidence score，表示这个模型对当前 request 成功的概率。然后系统根据每个模型当前负载估计一个 delay，选 在 fastest model 延迟 slack 范围内、confidence 最高的模型。这里有两个 knob：latency slack τ 控制你愿意为了更强模型多等多少，confidence margin Δs 避免为了一点点置信度收益频繁切模型。([arXiv][1])

第二，模型一旦被某个 workflow 选中，后续同一个 workflow 的请求会复用这个 assignment。作者说这样是为了 preserve execution locality、减少 router 调用开销，也有利于 KV-cache reuse。这个点很重要：它不是每个 agent step 都重新自由 route，而是 workflow 级别有 stickiness。 ([arXiv][1])

第三，选完模型以后，它预测这个 request 所属 workflow 从当前 stage 到结束还会生成多少 token，把这个预测长度作为 priority。短 job 优先，也就是它叫的 STJF：Shortest Total Job First。作者说普通 SJF 已经比 FCFS 减少 26–48% queue time，但 workflow-aware 的 STJF 又能比 SJF 多减少 15–34%。([arXiv][1])

第四，为了避免长任务被短任务一直饿死，它加了一个 aging-based anti-starvation 机制：如果一个请求连续很多轮没被选上，就临时提升优先级；执行若干 quantum 后再降回去。实现上每个 engine 的 priority key 类似 (starvation level, priority, arrival time)。([arXiv][1])

3. Router 和 predictor 是怎么训练的？

Semantic Router 本质上是一个 ModernBERT-large encoder + multi-label head。输入是 request prompt 和候选模型，输出每个模型的成功置信度。训练数据来自 offline traces：每个 (prompt, model) pair 用任务是否正确作为标签，正确是 1，不正确是 0，用 binary cross entropy 训练。([arXiv][1])

它不是那种特别复杂的 RL router。附录里说 router fine-tune 5 个 epoch，learning rate 1e-5，batch size 16；ModernBERT-large 在 APPS 上 mAP 0.521，在 MATH 上 mAP 0.740，平均 0.631。这个数不算离谱强，说明它更像一个可用但不完美的 lightweight classifier。([arXiv][1])

Length Predictor 用的是 Quantile Random Forest, QRF，预测的是 workflow-level remaining output tokens 的 conditional median。特征很朴素：system/user/full prompt token count、workflow id、当前 stage、model name、TF-IDF + SVD 的文本 sketch。作者选 QRF 的理由是 CPU inference 便宜，而且 quantile 对 heavy-tailed 输出长度更稳。([arXiv][1])

4. 实验设置

他们用两个任务类型：APPS code generation 和 MATH reasoning。workflow 是基于 ReAct 构造的，每个任务需要 1 到 4 个 stage。代码生成里有 Coder-only、Planner → Coder、Planner → Coder → QAAgent → Coder；数学里有 Solver-only、Planner → Solver、Planner → Solver → Verifier → Solver。([arXiv][1])

模型包括 Qwen2.5-1.5B/3B/7B/14B、Ministral-3-8B、Llama3.2-3B。后端实验跑在 NVIDIA RTX A6000 49GB VRAM。baseline 有 vLLM、MLFQ、LTR，还有一个用 oracle workflow total length 做 STJF 的 vLLM(STJF) 参考。指标是 workflow 的 E2E latency per token 和 task performance；APPS 看 tests passed 百分比，MATH 看 exact match。([arXiv][1])

5. 主要结果

总体结果是 Chimera 的 Pareto frontier 最好：相对 vLLM、MLFQ、LTR，它既降低 E2E latency，又提升 task performance。摘要里给的总体数字是：在可比设置下，Chimera 降低 E2E latency 1.2–2.4×，平均提升 task performance 8.0–9.5 percentage points。([arXiv][1])

具体到 APPS，Qwen1.5B+7B 配置下，Chimera 相比 vLLM 达到 3.4× speedup 和 16.0% score increase；Qwen1.5B+14B 下是 2.9× speedup 和 10.5% score increase；三模型 Qwen1.5B+3B+14B 下是 2.7× speedup 和 8.2% score increase。([arXiv][1])

MATH 上提升也存在，但 performance gain 没 APPS 那么大。比如 Qwen1.5B+7B 下，Chimera 相比 vLLM 是 2.5× speedup 和 2.2% score increase；Qwen1.5B+14B 下是 2.1× speedup 和 5.0% score increase；三模型下是 2.1× speedup 和 1.6% score increase。([arXiv][1])

调度开销很低：Table 1 里 scheduler 总开销最多是 E2E latency 的 2.2%，很多情况下小于 1%。这是系统 paper 里很重要的点，因为 router/predictor 如果开销太大，调度收益会被吃掉。([arXiv][1])

6. Ablation 说明了什么？

Router 是有用的。去掉 semantic router 后，系统就只能靠固定 heuristic，比如 slack 允许就上强模型；这样会为了达到相同 performance 付出更高 latency，Pareto frontier 明显变差。([arXiv][1])

Oracle 分析也挺有意思：在 Qwen1.5B+7B 上，oracle length predictor 更有帮助，说明瓶颈主要是长度预测；在 Qwen1.5B+14B 上，oracle router 更有帮助，说明瓶颈更多是判断哪个 query 值得上大模型。作者的结论是 Chimera 在一些 setting 里已经接近 oracle，但不同模型组合下剩余瓶颈不同。([arXiv][1])

7. 我觉得这篇的真正 novelty

这篇不是单纯 “LLM router”，也不是单纯 “LLM scheduler”。它的点在于把三件事绑在一起：

第一，performance-aware routing：不是只看哪个模型快，而是看哪个模型对这个 request 更可能成功。

第二，workflow-aware scheduling：不是只预测当前 request 长度，而是预测当前 stage 到 workflow 结束的总剩余输出长度，用 STJF 排队。

第三，load-aware dispatch：不是静态说 14B 慢、1.5B 快，而是看每个 engine 当前 in-flight predicted token volume，动态决定 congestion。

所以它的系统味道比普通 routing paper 更重。