Resumen Técnico: Brick - Enrutamiento de Capacidad Espacial para el Paradigma de Mezcla de Modelos (MoM)

1. Planteamiento del Problema

El artículo aborda el desafío de enrutar eficientemente las consultas a través de un grupo heterogéneo de Modelos de Lenguaje Extensos (LLMs) durante la inferencia. La dificultad central radica en definir la "dificultad" de manera empírica: la complejidad de una consulta no está determinada por rasgos superficiales como el recuento de tokens o etiquetas de dominio, sino por los requisitos específicos de capacidad de la tarea en relación con las fortalezas y debilidades de un modelo.

Las estrategias de enrutamiento existentes dependen del enrutamiento superficial (basado en dominios o en longitud/palabras clave), lo cual no logra capturar la varianza intradominio. Por ejemplo, una consulta corta podría apuntar a un problema no resuelto que requiere un modelo de frontera, mientras que un prompt largo de tipo boilerplate podría envolver una tarea trivial que un modelo pequeño de pesos abiertos puede resolver. Esto conduce a dos ineficiencias:

1. Ineficiencia de Costos: El despacho de consultas fáciles a modelos de frontera costosos (por ejemplo, Kimi 2.6) desperdicia presupuesto, ya que los modelos locales de pesos abiertos (por ejemplo, Qwen 3.5-9B) suelen ser suficientes.
2. Compromisos de Latencia y Precisión: El enrutamiento en cascada (probar modelos desde los más baratos hasta los más caros) incurre en una sobrecarga significativa en flujos de trabajo agénticos donde una sola solicitud de usuario desencadena múltiples llamadas a LLMs, acumulando el costo de los intentos "baratos" rechazados.

El objetivo es despachar cada consulta al modelo más barato que la responda correctamente, equilibrando costo, latencia y precisión sin depender de heurísticas superficiales.

2. Metodología: El Router Brick

Los autores proponen Brick, un enrutador multimodal que opera dentro del paradigma de Mezcla de Modelos (MoM). A diferencia de la Mezcla de Expertos (MoE), que activa subredes dentro de un solo modelo, el MoM despacha consultas completas a modelos distintos e independientes preentrenados.

2.1 El Paradigma MoM

Brick utiliza un grupo de tres modelos heterogéneos:

• Qwen3.5-9B: Un modelo de vanguardia de pesos abiertos (<10B de parámetros).
• DeepSeek-V4-Flash: Un modelo de vanguardia de pesos abiertos (<500B de parámetros).
• Kimi2.6: Un contendiente de código abierto de frontera.

El grupo abarca diferentes puntos de precio (que van desde ~$0.001 hasta ~$0.03 por llamada) y perfiles de capacidad, lo que permite al enrutador explotar la complementariedad de capacidades (por ejemplo, un modelo puede rechazar una consulta que otro resuelve).

2.2 El Espacio de Capacidad de Seis Dimensiones

Brick enmarca el enrutamiento como una decisión geométrica en un espacio de capacidad de seis dimensiones. Las dimensiones son:

1. Codificación (Coding)
2. Síntesis Creativa (Creative Synthesis)
3. Seguimiento de Instrucciones (Instruction Following)
4. Razonamiento Matemático (Math Reasoning)
5. Planificación/Agéntico (Planning/Agentic)
6. Conocimiento del Mundo (World Knowledge)

El Pipeline:

1. Estimación de Capacidad: Un clasificador ModernBERT ajustado mapea la consulta a un vector de probabilidad $p(x)$ sobre las seis dimensiones.
2. Estimación de Complejidad: Un clasificador separado estima una puntuación de dificultad $\tau_q$ (combinada de anclajes "fácil/medio/difícil").
3. Calibración de la Matriz de Habilidades: Una matriz de habilidades $S$ calibrada fuera de línea almacena las tasas de éxito empíricas ($s_{m,c}$) de cada modelo $m$ en cada capacidad $c$, derivadas de un conjunto de datos etiquetado.
4. Matemáticas de Enrutamiento Geométrico:
   • Requerimiento: El vector de requerimiento de la consulta $r_{q,c}$ se deriva de $p(x)$ y el logit de dificultad $z_q$.
   • Capacidad: El vector de capacidad del modelo $v_{m,c}$ se deriva de $p(x)$ y el logit de habilidad del modelo $\text{logit}(s_{m,c})$.
   • Residuales: El enrutador calcula residuales asimétricos: subcapacidad ($u$, el modelo es demasiado débil) y sobrecapacidad ($o$, el modelo es excesivo).
   • Puntuación: Se calcula una puntuación total $J_m$ como la distancia euclidiana ponderada de los residuales más una penalización de costo:
     $$J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$$
     Donde $a_m$ es el costo normalizado, $\lambda$ penaliza la sobrecapacidad, y $\beta$ controla el compromiso entre costo y calidad.
5. Decisión: Se selecciona el modelo con el mínimo $J_m$.

2.3 La Perilla de Preferencia ($r$)

Brick introduce una perilla de preferencia continua $r \in [-1, 1]$ que permite a los operadores deslizarse entre un perfil de "máxima calidad" y uno de "máximo ahorro". Esta perilla modula las cuatro escalares de enrutamiento ($\mu, b, \beta, \lambda$) mediante una ley de potencia calibrada, convirtiendo el compromiso costo-calidad en un parámetro de despliegue en lugar de un cambio en el código.

3. Contribuciones Clave

1. Formulación MoM: El artículo enmarca el enrutamiento de modelos completos a través de grupos heterogéneos como el paradigma MoM, demostrando que recupera el 24% del margen alcanzable entre el mejor modelo único y un oráculo teórico de tres modelos.
2. Rechazo del Enrutamiento Superficial: Demuestra empíricamente que el enrutamiento basado en dominios y el basado en longitud/palabras clave fallan en capturar la dificultad intradominio, rindiendo por debajo incluso de una línea base simple de "siempre-Kimi".
3. Router Brick: Un enrutador MoM calibrado con una representación explícita de vector de capacidad y una perilla de preferencia para el usuario.
4. Eficiencia Agéntica: El artículo argumenta que el enrutamiento de un solo paso (como Brick) es estructuralmente superior al enrutamiento en cascada para cargas de trabajo agénticas, ya que evita la acumulación del costo de los pasos de cascada rechazados en cada paso de una trayectoria de un agente.

4. Resultados Experimentales

Evaluado en el Dataset A (5,504 consultas a través de seis dimensiones de capacidad):

• Precisión vs. Costo:

  • Perfil de Máxima Calidad ($r=+1$): Brick logra un 76.98% de precisión, superando al mejor modelo único (Kimi 2.6 con 75.02%) y a todos los enrutadores externos (RouteLLM, FrugalGPT, Cascade Routing). Lo hace con un 28% menos de costo ($0.022 vs $0.031 por llamada).
  • Perfil Neutral ($r=0$): Logra un 74.11% de precisión con un costo 4.71× menor que siempre-Kimi, con solo una pérdida de 0.91 puntos porcentuales de precisión. Supera a Cascade Routing por +0.71 pp con un costo comparable.
  • Perfil Bajo ($r=-0.5$): Logra un 71.62% de precisión, superando a FrugalGPT (69.42%) por +2.20 pp con un costo comparable.
  • Perfil de Mínimo Costo ($r=-1$): Igual la precisión del modelo más barato (Qwen) con 63.17%, pero con un costo 22.15× menor que siempre-Kimi.

• Latencia:

  • La latencia mediana de extremo a extremo para Brick (perfil Max) cae de 51.2s (siempre-Kimi) a 22.8s. Esto se debe a que Brick enruta aproximadamente el 31% de las consultas al modelo más rápido DeepSeek-V4-Flash incluso en la configuración de máxima calidad.

• Límite del Oráculo:

  • El techo teórico (Oráculo de Tres Modelos) es 83.25%. Brick captura una parte significativa de la brecha entre el mejor modelo único y este oráculo, aunque queda un residuo de 6.27 pp no extraído por las características de capacidad actuales.

5. Significado y Reivindicaciones

El artículo afirma que Brick demuestra la viabilidad del paradigma MoM como un patrón de despliegue de primera clase. Su importancia radica en:

• Validación Empírica: Probar que el enrutamiento basado en un espacio de capacidad calibrado supera al enrutamiento heurístico y a las líneas base de un solo modelo.
• Flexibilidad Operativa: Proporcionar una perilla continua para que los operadores ajusten el compromiso costo-calidad sin necesidad de reentrenamiento o cambios en el código.
• Escalabilidad Agéntica: Establecer que el enrutamiento puro es el único diseño que escala eficientemente a las cargas de trabajo agénticas, evitando las penalizaciones lineales de costo y latencia inherentes al enrutamiento en cascada.
• Complementariedad: Destacar que los grupos de modelos ofrecen conjuntos de errores complementarios (por ejemplo, manejar "rechazos honestos" vs. alucinaciones), que un enrutador consciente de la capacidad puede explotar para mejorar la fiabilidad general del sistema.

Los autores mantienen la modestia, reconociendo que la brecha residual hacia el oráculo (6.27 pp) representa información que el enrutador actual aún no extrae, y que el trabajo futuro debería centrarse en el suavizado Bayesiano para pools dispersos y la estimación de complejidad condicionada al dominio.