🤖 AI

Brick: Spatial Capability Routing for the Mixture-of-Models (MoM) Paradigm

Brick 是一种用于混合模型（Mixture-of-Models）范式的多模态路由，它根据六个能力维度和估计的难度动态地将查询分发给模型，与单模型基准及现有路由相比，实现了更高的准确率以及显著的成本与延迟降低。

原作者： Francesco Massa, Marco Cristofanilli

发布于 2026-06-12

📖 1 分钟阅读☕ 轻松阅读

原作者： Francesco Massa, Marco Cristofanilli

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你经营着一家规模宏大、高端的餐厅。你的员工中有三位不同的厨师：

厨师 Qwen：一位才华横溢、手脚麻利且非常便宜的本地厨师。
厨师 DeepSeek：一位技术精湛、价格中等的专家。
厨师 Kimi：一位世界闻名的、昂贵的名厨，收费极高，但几乎精通所有领域。

问题所在：
每天都有成千上万的顾客走进店里提出不同的需求。有些要求是简单的烤奶酪三明治（简单任务）。另一些则是复杂的、包含十道菜的分子美食品鉴菜单（困难任务）。
在过去，餐厅经理使用“表面路由”（superficial routing）来决定谁来做菜。他们观察订单的长度或使用的关键词。

缺陷在于： 一个像“证明黎曼猜想”这样短小的订单，实际上是非常困难的任务，需要名厨来处理。而一个关于“如何制作吐司”的长篇大论，其实是非常简单的任务，完全可以由本地厨师搞定。如果你仅仅因为订单看起来很长或很复杂，就把它发给昂贵的名厨，你会破产。如果你把所有东西都交给廉价的厨师，你会得到很多烧焦的吐司和愤怒的顾客。

解决方案：“Brick”
这篇论文介绍了 Brick，一个聪明的“领班”（路由器），它不仅仅是看订单的长度，而是分析该订单所需的具体技能。

Brick 将每个请求分解为六种特定的“难度风味”：

编程
文学创作
执行指令
数学推理
规划/策略
通用世界知识

Brick 的运作方式（类比）：

品尝订单：当一个订单进来时，Brick 会阅读它并询问：“这其中有多少是数学？有多少是文学创作？”它会为请求创建一个“风味剖面图”。
检查厨师的技能：Brick 有一个秘密评分表（“技能矩阵”）记录每位厨师。它知道，例如，厨师 Kimi 在数学方面表现惊人，但有时会拒绝回答关于晦涩历史事实的问题（倾向于说“我不知道”而不是瞎猜）。它也知道厨师 DeepSeek 在历史方面出奇地擅长，甚至在某些情况下比名厨还要好。
“成本 vs 质量”旋钮：Brick 有一个特殊的旋钮，餐厅老板可以调节它。
- 调至“最高质量”：Brick 会忽略价格标签。它会将订单发送给最有可能完美完成任务的厨师，即使那位厨师很贵。
- 调至“最大节省”：Brick 会尝试使用尽可能便宜的厨师，即使这意味着有微小的出错风险。
- 调至“中性”：Brick 会寻找平衡点，大多数事情交给价格适中的厨师，只有在绝对必要时才请出名厨。

结果：
研究人员在 5,504 个不同的“订单”（查询）上测试了这个系统。以下是他们的发现：

击败了单一最强厨师：即使当 Brick 设置为“最高质量”时，它完成正确订单的数量也超过了将所有订单都交给名厨（Kimi）的情况。为什么？因为名厨有时会拒绝回答那些廉价厨师其实可以解决的问题。Brick 知道何时绕过名厨的“我不知道”态度。
节省资金：在“中性”设置下，与始终使用名厨相比，Brick 节省了大约 4.7 倍的资金，而仅损失了极小的准确度（不到 1%）。
速度：因为 Brick 经常将简单或中等难度的任务发送给更快、更便宜的厨师，所以客户拿到食物的平均速度几乎快了两倍。
击败竞争对手：其他系统试图通过查看字数或领域名称来猜测难度，但它们失败了。Brick 通过观察实际所需的技能，表现优于所有测试过的其他路由方法。

“先知”天花板（The "Oracle" Ceiling）：
研究人员还计算了“完美世界”的情景（称为 Oracle）。如果有一个神奇的侍者可以查看每一个订单，并能瞬间知道哪位厨师能解决它，那么他们可以完成 83.25% 的订单。
Brick 完成了 76.98%。这意味着 Brick 捕捉到了大部分可能的成本节约和质量提升，但仍存在约 6% 的“空间（headroom）”，即该系统尚未完全挖掘出的潜力。

为什么这对“智能体（Agents/机器人）”很重要：
论文指出，这对于 AI “智能体”（执行一系列任务的软件）至关重要。如果一个智能体需要通过 10 个步骤来解决一个问题，而它使用了一个“懒惰”的路由系统——即先检查最便宜的厨师，如果不行再找下一个，最后才找最贵的（这种“级联”模式）——那么它在每一步都会浪费时间和金钱。Brick 是一个“一次性决策”者：它能立即选出正确的厨师。这让机器人既快速又省钱。

总结：
Brick 是一个聪明的调度员，它阻止了我们为了每一项工作都盲目地支付最昂贵 AI 模型的费用。它分析一项任务究竟需要什么，将其与不同模型的特定优势进行匹配，并允许你在节省成本与获取最佳答案之间进行权衡。

技术摘要：Brick —— 面向混合模型（MoM）范式的空间能力路由

1. 问题陈述

本文探讨了在推理阶段，如何高效地在异构的大语言模型（LLM）池中进行查询路由的问题。核心难点在于如何从经验角度定义“难度”：一个查询的复杂度并非由 Token 数量或领域标签等表面特征决定，而是由任务的具体能力需求相对于模型的优势与劣势而定的。

现有的路由策略依赖于表层路由（基于领域或长度/关键词），这无法捕捉领域内的差异性。例如，一个短查询可能针对的是需要前沿模型解决的未解难题，而一个长的模板化提示词可能只是包裹了一个可以用小型开源模型解决的琐碎任务。这导致了两种低效性：

成本低效： 将简单的查询调度给昂贵的前沿模型（如 Kimi 2.6）会浪费预算，因为本地开源模型（如 Qwen 3.5-9B）通常就足够了。
延迟与准确率的权衡： 级联路由（按从最便宜到最贵的顺序探测模型）在智能体（Agentic）工作流中会产生显著的开销，因为单个用户请求会触发多次 LLM 调用，从而使被拒绝的“廉价”尝试所带来的成本在多个步骤中不断累积。

目标是将每个查询调度给能够正确回答该问题的最便宜的模型，在不依赖表面启发式方法的情况下，平衡成本、延迟和准确率。

2. 方法论：Brick 路由

作者提出了 Brick，一种在**混合模型（Mixture-of-Models, MoM）**范式下运行的多模态路由器。与混合专家模型（MoE）在单个模型内部激活子网络不同，MoM 将整个查询调度给不同的、独立的预训练模型。

2.1 MoM 范式

Brick 使用了一个由三个异构模型组成的池：

Qwen3.5-9B： 最先进的开源权重模型（参数量 <10B）。
DeepSeek-V4-Flash： 最先进的开源权重模型（参数量 <500B）。
Kimi2.6： 前沿开源竞争者。

该模型池跨越了不同的价格区间（从每次调用约 $0.001 到$ 0.03 不等）和能力剖面，使路由器能够利用能力互补性（例如，一个模型拒绝处理的查询，另一个模型可以解决）。

2.2 六维能力空间

Brick 将路由建模为六维能力空间中的几何决策。这些维度包括：

代码（Coding）
创意合成（Creative Synthesis）
指令遵循（Instruction Following）
数学推理（Math Reasoning）
规划/智能体能力（Planning/Agentic）
世界知识（World Knowledge）

流水线流程：

能力估计： 一个经过微调的 ModernBERT 分类器将查询映射到六个维度的概率向量 $p(x)$ 。
复杂度估计： 一个独立的分类器估计一个难度得分 $\tau_q$ （由“简单/中等/困难”锚点混合而成）。
技能矩阵校准： 一个离线校准的技能矩阵 $S$ 存储了每个模型 $m$ 在每个能力 $c$ 上的经验成功率 ( $s_{m,c}$ )，这些数据源自标注数据集。
几何路由数学公式：
- 需求： 查询的需求向量 $r_{q,c}$ 由 $p(x)$ 和难度对数几率 $z_q$ 推导得出。
- 容量： 模型的容量向量 $v_{m,c}$ 由 $p(x)$ 和模型的技能对数几率 $\text{logit}(s_{m,c})$ 推导得出。
- 残差： 路由器计算非对称残差：能力不足（模型太弱）和能力过剩（模型大材小用）。
- 评分： 总分 $J_m$ 计算为残差的加权欧几里得距离加上成本惩罚：
  $J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$
  其中 $a_m$ 是归一化成本， $\lambda$ 惩罚过度容量， $\beta$ 控制成本-质量权衡。
决策： 选择具有最小 $J_m$ 的模型。

2.3 偏好旋钮 ( $r$ )

Brick 引入了一个连续的偏好旋钮 $r \in [-1, 1]$ ，允许操作者在“最大质量”和“最大节省”配置之间进行切换。该旋钮通过校准的幂律函数调节四个路由标量（ $\mu, b, \beta, \lambda$ ），将成本-质量的权衡转化为部署时的参数，而非代码级的更改。

3. 核心贡献

MoM 公式化： 本文将跨异构池的整模型路由框架化为 MoM 范式，证明了它能回收在最佳单模型与理论上的三模型预言机（Oracle）之间可实现的 24% 的性能提升空间。
拒绝表层路由： 实验表明，基于领域以及长度/关键词的路由无法捕捉领域内的难度，其表现甚至不如一个简单的“始终使用 Kimi”的基准线。
Brick 路由器： 一个具有显式能力向量表示且带有用户界面偏好旋钮的校准 MoM 路由器。
智能体效率： 本文认为，纯单步路由（如 Brick）在结构上优于级联路由，适用于智能体工作负载，因为它避免了在智能体轨迹的每一步中都重复承担被拒绝的级联阶段所带来的成本。

4. 实验结果

在 Dataset A（包含六个能力维度的 5,504 个查询）上进行的评估显示：

准确率 vs. 成本：
- 最大质量配置 ( $r=+1$ )： Brick 达到了 76.98% 的准确率，超过了最佳单模型（Kimi 2.6 为 75.02%）以及所有外部路由器（RouteLLM, FrugalGPT, 级联路由）。同时，其成本降低了 28%（每次调用 $0.022 vs $0.031）。
- 中性配置 ( $r=0$ )： 实现了 74.11% 的准确率，其成本比“始终使用 Kimi”低 4.71 倍，且仅损失了 0.91 个百分点的准确率。它在同等成本下比级联路由高出 0.71 个百分点。
- 低成本配置 ( $r=-0.5$ )： 实现了 71.62% 的准确率，在同等成本下比 FrugalGPT（69.42%）高出 2.20 个百分点。
- 最小成本配置 ( $r=-1$ )： 准确率为 63.17%，与最便宜的模型（Qwen）持平，但成本比“始终使用 Kimi”低 22.15 倍。
延迟：
- Brick（最大质量配置）的中值端到端延迟从 51.2s（始终使用 Kimi）降至 22.8s。这是因为即使在最大质量设置下，Brick 也会将约 31% 的查询路由到更快的 DeepSeek-V4-Flash 模型。
预言机上限 (Oracle Bound)：
- 理论上限（三模型预言机）为 83.25%。Brick 捕捉到了最佳单模型与该预言机之间很大一部分差距，尽管目前仍有 6.27 个百分点的残余差距尚未被当前的容量特征所提取。

5. 重要性与主张

本文声称 Brick 证明了 MoM 范式作为一种一等公民部署模式的可行性。其重要性在于：

经验验证： 证明了基于校准能力空间的路由优于启发式路由和单模型基准。
操作灵活性： 提供了一个连续的旋钮，让操作者可以在无需重新训练或更改代码的情况下，调整成本-质量的权衡。
智能体可扩展性： 确立了纯路由是唯一能高效扩展到智能体工作负载的设计，避免了级联路由固有的线性成本和延迟惩罚。
互补性： 强调了模型池提供了互补的错误集（例如，处理“诚实拒绝”与“幻觉”的区别），而具备能力感知的路由器可以利用这一点来提高整体系统的可靠性。

作者保持了谦逊的态度，承认当前路由器与预言机之间存在的 6.27 个百分点的差距代表了当前尚未提取的信息，并指出未来的工作应侧重于针对稀疏池的贝叶斯平滑以及领域条件的复杂度估计。