Résumé Technique : Brick - Routage de Capacité Spatiale pour le Paradigme Mixture-of-Models (MoM)

1. Énoncé du Problème

L'article traite du défi consistant à router efficacement les requêtes à travers un pool hétérogène de modèles de langage (LLM) lors de l'inférence. La difficulté centrale réside dans la définition empirique de la « difficulté » : la complexité d'une requête n'est pas déterminée par des caractéristiques superficielles comme le nombre de tokens ou des étiquettes de domaine, mais par les exigences spécifiques de capacité de la tâche par rapport aux forces et faiblesses d'un modèle.

Les stratégies de routage existantes reposent sur un routage superficiel (basé sur le domaine ou sur la longueur/mots-clés), qui échoue à capturer la variance intra-domaine. Par exemple, une requête courte peut cibler un problème non résolu nécessitant un modèle de pointe, tandis qu'un long prompt de type "boilerplate" peut envelopper une tâche triviale traitable par un petit modèle à poids ouverts. Cela conduit à deux inefficacités :

1. Inefficacité des Coûts : Envoyer des requêtes faciles vers des modèles de pointe coûteux (ex: Kimi 2.6) gaspille le budget, alors que des modèles locaux à poids ouverts (ex: Qwen 3.5-9B) suffisent souvent.
2. Compromis Latence et Précision : Le routage en cascade (tester les modèles du moins cher au plus cher) induit un overhead significatif dans les flux de travail agentiques où une seule requête utilisateur déclenche plusieurs appels LLM, amplifiant le coût des tentatives "bon marché" rejetées.

L'objectif est de dispatcher chaque requête vers le modèle le moins cher qui saura y répondre correctement, en équilibrant coût, latence et précision sans dépendre d'heuristiques superficielles.

2. Méthodologie : Le Routeur Brick

Les auteurs proposent Brick, un routeur multimodal opérant dans le paradigme Mixture-of-Models (MoM). Contrairement à la Mixture of Experts (MoE), qui active des sous-réseaux au sein d'un seul modèle, le MoM envoie des requêtes entières vers des modèles distincts et indépendants.

2.1 Le Paradigme MoM

Brick utilise un pool de trois modèles hétérogènes :

• Qwen3.5-9B : Un modèle à poids ouverts de pointe (<10B de paramètres).
• DeepSeek-V4-Flash : Un modèle à poids ouverts de pointe (<500B de paramètres).
• Kimi2.6 : Un concurrent de pointe en open-source.

Le pool couvre différentes échelles de prix (allant d'environ 0,001 $à 0,03$ par appel) et des profils de capacité, permettant au routeur d'exploiter la complémentarité des capacités (ex: un modèle peut refuser une requête qu'un autre résout).

2.2 L'Espace de Capacité à Six Dimensions

Brick cadre le routage comme une décision géométrique dans un espace de capacité à six dimensions. Les dimensions sont :

1. Codage (Coding)
2. Synthèse Créative (Creative Synthesis)
3. Respect des Instructions (Instruction Following)
4. Raisonnement Mathématique (Math Reasoning)
5. Planification/Agentique (Planning/Agentic)
6. Connaissance du Monde (World Knowledge)

Le Pipeline :

1. Estimation de la Capacité : Un classifieur ModernBERT affiné mappe la requête vers un vecteur de probabilité $p(x)$ sur les six dimensions.
2. Estimation de la Complexité : Un classifieur séparé estime un score de difficulté $\tau_q$ (mélange d'ancres "facile/moyen/difficile").
3. Calibration de la Matrice de Compétences : Une matrice de compétences $S$ calibrée hors ligne stocke les taux de succès empiriques ($s_{m,c}$) de chaque modèle $m$ sur chaque capacité $c$, dérivés d'un jeu de données étiqueté.
4. Calcul de Routage Géométrique :
   • Exigence : Le vecteur d'exigence $r_{q,c}$ est dérivé de $p(x)$ et du logit de difficulté $z_q$.
   • Capacité : Le vecteur de capacité $v_{m,c}$ est dérivé de $p(x)$ et du logit de compétence du modèle $\text{logit}(s_{m,c})$.
   • Résiduels : Le routeur calcule des résidus asymétriques : sous-capacité ($u$, modèle trop faible) et sur-capacité ($o$, modèle excessif).
   • Scoring : Un score total $J_m$ est calculé comme une distance euclidienne pondérée des résidus plus une pénalité de coût :
     $$J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$$
     Où $a_m$ est le coût normalisé, $\lambda$ pénalise la sur-capacité, et $\beta$ contrôle le compromis coût-qualité.
5. Décision : Le modèle ayant le $J_m$ minimum est sélectionné.

2.3 Le Bouton de Préférence ($r$)

Brick introduit un bouton de préférence continu $r \in [-1, 1]$ qui permet aux opérateurs de glisser entre un profil "qualité maximale" et "économie maximale". Ce bouton module les quatre scalaires de routage ($\mu, b, \beta, \lambda$) via une loi de puissance calibrée, transformant le compromis coût-qualité en un paramètre de déploiement plutôt qu'en une modification de code.

3. Contributions Clés

1. Formulation MoM : L'article cadre le routage de modèles entiers à travers des pools hétérogènes comme le paradigme MoM, démontrant qu'il récupère 24 % de la marge de progression atteignable entre le meilleur modèle unique et un oracle théorique à trois modèles.
2. Rejet du Routage Superficiel : Il démontre empiriquement que le routage basé sur le domaine et sur la longueur/mots-clés échoue à capturer la difficulté intra-domaine, étant moins performant qu'une simple ligne de base "toujours-Kimi".
3. Routeur Brick : Un routeur MoM calibré avec une représentation explicite de vecteur de capacité et un bouton de préférence pour l'utilisateur.
4. Efficacité Agentique : L'article soutient que le routage en une seule étape (comme Brick) est structurellement supérieur au routage en cascade pour les charges de travail agentiques, car il évite de multiplier le coût des étapes de cascade rejetées à chaque étape d'une trajectoire d'agent.

4. Résultats Expérimentaux

Évalué sur le Dataset A (5 504 requêtes réparties sur six dimensions de capacité) :

• Précision vs Coût :

  • Profil Qualité Maximale ($r=+1$) : Brick atteint 76,98 % de précision, battant le meilleur modèle unique (Kimi 2.6 à 75,02 %) et tous les routeurs externes (RouteLLM, FrugalGPT, Cascade Routing). Il y parvient avec un coût 28 % inférieur (0,022 $ vs 0,031 $ par appel).
  • Profil Neutre ($r=0$) : Atteint 74,11 % de précision à un coût 4,71× inférieur que toujours-Kimi, avec seulement une perte de 0,91 point de pourcentage de précision. Il surpasse le Cascade Routing de +0,71 pp à coût comparable.
  • Profil Bas ($r=-0,5$) : Atteint 71,62 % de précision, battant FrugalGPT (69,42 %) de +2,20 pp à coût comparable.
  • Profil Coût Minimum ($r=-1$) : Égal le modèle le moins cher (Qwen) avec 63,17 % de précision, mais à un coût 22,15× inférieur que toujours-Kimi.

• Latence :

  • La latence médiane de bout en bout pour Brick (profil Max) chute de 51,2s (toujours-Kimi) à 22,8s. Cela s'explique par le fait que Brick route environ 31 % des requêtes vers le modèle plus rapide DeepSeek-V4-Flash, même dans le réglage de qualité maximale.

• Borne de l'Oracle :

  • Le plafond théorique (Oracle à trois modèles) est de 83,25 %. Brick capture une part significative de l'écart entre le meilleur modèle unique et cet oracle, bien qu'un résidu de 6,27 pp reste non extrait par les fonctionnalités de capacité actuelles.

5. Signification et Revendications

L'article affirme que Brick démontre la viabilité du paradigme MoM comme un mode de déploiement de premier rang. Sa signification réside dans :

• Validation Empirique : Prouver que le routage basé sur un espace de capacité calibré surpasse le routage heuristique et les modèles uniques de base.
• Flexibilité Opérationnelle : Fournir un bouton continu aux opérateurs pour ajuster le compromis coût-qualité sans réentraînement ni changement de code.
• Scalabilité Agentique : Établir que le routage pur est le seul design qui passe à l'échelle efficacement pour les charges de travail agentiques, évitant les pénalités linéaires de coût et de latence inhérentes au routage en cascade.
• Complémentarité : Souligner que les pools de modèles offrent des ensembles d'erreurs complémentaires (ex: gestion des "refus honnêtes" vs hallucinations), ce qu'un routeur conscient des capacités peut exploiter pour améliorer la fiabilité globale du système.

Les auteurs restent modestes, reconnaissant que le résidu de l'écart par rapport à l'oracle (6,27 pp) représente une information que le routeur actuel n'extrait pas encore, et que les travaux futurs devraient se concentrer sur le lissage bayésien pour les pools épars et l'estimation de la complexité conditionnée par le domaine.