Orquestación multi-modelo: mitad del costo, 2 puntos abajo

¿La orquestación multi-modelo cambia calidad por costo?

La orquestación multi-modelo cambia las dos columnas de la cuenta: reduce el costo por tarea casi a la mitad y pierde dos puntos en el índice. La Artificial Analysis midió US$ 5,59 por tarea para la composición de GitHub, frente a US$ 11,42 para Claude Code con Opus 5.5 en la configuración máxima. El ahorro es real en la medición. La puntuación menor también.

La conclusión no es que mezclar modelos gane siempre. Es que elegir un modelo por su posición en el ranking compra un promedio, y la cuenta llega por tarea. El responsable de ingeniería necesita saber si la diferencia cae en el trabajo que su equipo no puede equivocar.

La tesis es esta: la orquestación multi-modelo, o composición de modelos, solo merece el cambio cuando el ahorro por tarea sobrevive al test de aceptación de la carga real. Sin ese test, un precio menor es una propuesta, no una decisión.

¿Qué mide el índice, al final?

Mide tres benchmarks con el mismo peso y devuelve un promedio agregado, no el desempeño de una carga concreta. El Coding Agent Index v2.0 reúne Terminal-Bench 4.0, FrontierCode y SWE-Atlas-QnA-AA, y el resultado permite comparar configuraciones en la distribución que eligió la medición. No informa cuánto ahorrará una organización ni qué error encontrará en su propia aplicación.

En la configuración máxima, Copilot Fusion en GitHub Copilot CLI lidera Terminal-Bench 4.0 con 71. En FrontierCode queda tercero con 51, por detrás de 56 y 54. En SWE-Atlas-QnA-AA registra 57, según la Artificial Analysis. El mismo resultado agregado alberga posiciones distintas según la prueba.

Ese detalle cambia la compra. El benchmark tiene que representar el trabajo, y un liderazgo no borra la desventaja en las otras pruebas.

Dos puntos en el índice no son dos por ciento menos de calidad. La relación entre puntuación y daño depende de la tarea, del criterio de aceptación y de la consecuencia del error, y nada de eso se recupera de un único promedio agregado. Quien convierte la diferencia en tasa de fallo sin medir vende una precisión que el índice no ofrece.

¿Qué cambia en la composición de modelos?

En la composición de modelos, la decisión deja de estar concentrada en la elección anticipada de un único modelo para todo el trabajo. El sistema selecciona modelos durante la ejecución. Eso cambia la forma de evaluar gasto y resultado, pero el mecanismo específico tiene que conocerse antes de atribuir mérito a cualquier etapa.

El caso medido es Copilot Fusion. GitHub describe la selección y la coordinación de modelos de Anthropic y de OpenAI en tiempo de ejecución para equilibrar desempeño, costo y latencia por tarea, según relata la Artificial Analysis. El cobro de tokens acompaña a los modelos usados para concluir la solicitud, no a una tarifa única de la composición.

Una arquitectura que elige modelos por etapa evalúa cada pasada por su objetivo: examinar la entrada, producir un cambio o verificar el resultado. Esa es una posibilidad de diseño, no una descripción de las decisiones internas del producto medido. La fuente no publica la descomposición por etapa, lo que limita cualquier afirmación sobre enrutamiento de modelos de IA y no autoriza a decir qué modelo ejecutó qué parte.

Hay una diferencia entre cambiar de modelo y terminar bien. La llamada más barata puede exigir corrección, otra llamada o revisión humana, y eso entra en la cuenta. Un error de enrutamiento traslada el gasto a después del primer resultado.

Una traza puede unir la llamada al contexto de ejecución, pero no comprueba que el resultado fue aceptado ni sustituye el cobro del proveedor.

¿Cómo comparar los números publicados?

Se comparan costo, consumo y resultados de los benchmarks dentro de la misma medición, con la configuración declarada para cada número. Los tres datos salen de la misma prueba de la Artificial Analysis. Los valores se refieren a las configuraciones probadas, no a una tarifa universal ni al costo de implantación en otra empresa. Donde la fuente ofrece solo una relación entre consumos, la tabla conserva esa relación.

Fuente de la tabla: Artificial Analysis, medición publicada el 28 de octubre de 2026. La posición relativa en el índice no revela los valores absolutos de las configuraciones.

La tercera configuración de la misma medición, Devin Fusion con Opus 5.5 en la configuración máxima y GPT-6 Luna en high, entrega 62 puntos a US$ 8,00 por tarea, 43% por encima de los US$ 5,59 del Fusion de GitHub. Dos arquitecturas de composición, por lo tanto, quedan en franjas de costo distintas, y la etiqueta arquitectónica no determina el costo por tarea.

La medición compara productos de agente, no políticas de gateway. Un gateway elige un modelo por solicitud. Una orquestación dentro del producto emite varias llamadas por tarea, con estado. El harness del agente entrega herramientas, contexto y caché. El ahorro de un producto de agente no dimensiona una decisión de gateway sin medición propia.

El consumo de 7,2 millones de tokens por tarea es aproximadamente la mitad del consumo de Opus 5.5 en Claude Code, según la Artificial Analysis. Menos tokens ayudan a explicar la diferencia, pero la causa no es única: harness, diseño de herramientas, reutilización de caché y tarifas de los modelos compiten por la explicación.

¿Qué medidas separan el ahorro real del aparente?

Separar el ahorro real del aparente exige cinco medidas: calidad por tipo de tarea, elegibilidad de datos, costo por etapa, tokens por tarea y costo del error de enrutamiento. La comparación empieza con la misma carga, la misma definición de aceptación y una cuenta que incluya el trabajo necesario para llegar al resultado. El promedio publicado orienta la investigación y no sustituye esas mediciones cuando el enrutamiento falla.

1. Calidad por tipo de tarea. El responsable separa las tareas por características relevantes y define quién acepta el resultado, con criterios verificables. Después compara los grupos, no el agregado. El promedio esconde fallas en las tareas más sensibles.
2. Elegibilidad de datos. Antes del precio, el equipo marca las tareas que no pueden ir a uno de los proveedores por clasificación de la información, residencia de datos o cláusula contractual. La ruta que no cumple queda fuera, por más barata que sea.
3. Costo por etapa y por tarea. El equipo asocia llamadas e intentos a la tarea de origen, identifica los modelos usados y aplica las condiciones de cobro vigentes. Cuando el cobro no permite atribución detallada, el valor queda desconocido en ese nivel, y desconocido no es costo cero. El costo por tarea en el enrutamiento de modelos detalla esa cuenta por ruta.
4. Tokens por tarea. Entrada y salida, cuando están disponibles, deben seguirse junto al modelo y a la regla de precio. El conteo indica dónde hay consumo; no es la factura. Las tareas simples y las largas exigen comparación separada.
5. Costo del error de enrutamiento. El equipo registra rechazo, corrección, reintento e intervención humana, incluido el costo de las tareas no aceptadas. Si la medición excluye esos casos, una ruta que falla y abandona trabajo puede parecer más barata que una que concluye.

La fórmula de costo por tarea aceptada exige declarar la cohorte y el tamaño mínimo: sumar los costos de las tareas incluidas, con las rechazadas y abandonadas según la política definida, y dividir por el número de aceptadas en la misma cohorte. La cuenta necesita dispersión e intervalo, porque una cohorte pequeña convierte el ruido en diferencia. Sin aceptadas no hay promedio; sin atribución confiable, la cuenta es parcial.

La latencia entra en la misma cuenta. Si la ruta respeta el criterio de calidad y termina fuera del plazo del proceso, el descuento no recompone el servicio. El comprador mira la distribución de los tiempos, no el promedio.

¿Cuándo el modelo único sigue siendo la elección correcta?

El modelo único sigue siendo la elección correcta cuando la composición no alcanza el criterio de aceptación, no cumple la latencia exigida o no ofrece evidencia suficiente para atribuir sus costos. La ventaja de una ruta más simple no es estética: reduce la necesidad de justificar elecciones intermedias sin observabilidad.

La objeción a la orquestación multi-modelo merece tomarse en serio. Un sistema que elige entre modelos introduce decisiones adicionales y exige investigación cuando el resultado falla. Si la ganancia medida es pequeña frente al costo de evaluación, integración y operación, mantener la configuración existente puede ser la decisión económica correcta. La ruta consume llamada propia, y cambiar de modelo invalida la caché de prompt.

La concentración de proveedor es el costo que no aparece en la tarifa. Una orquestación acopla dos o más contratos, con términos de datos, límites y reajuste propios, y la política de selección es opaca por construcción: no se reproduce ni se contesta en auditoría. Antes de adoptar, exija términos por proveedor, política versionada y costo de salida estimado.

Eso no convierte al modelo único en ganador automático. La medición de la Artificial Analysis muestra que la orquestación multi-modelo redujo el costo por tarea, con una diferencia delimitada en el índice, dentro de aquella distribución. Para otra carga, la respuesta tiene que venir del test propio.

La decisión debe ser reversible. Fijar la política sin monitorear los tipos de tarea que atiende convierte una evaluación puntual en regla permanente, y un cambio en la mezcla de trabajo exige rehacer la cuenta.

Preguntas frecuentes sobre orquestación multi-modelo

<!-- FAQPage -->

La duda útil no es qué etiqueta gana. Es qué permite concluir la medición y qué necesita medir todavía la empresa. Un índice ayuda a elegir el test. No define, por sí solo, la calidad aceptable para una aplicación específica.

¿La orquestación multi-modelo es siempre más barata?

No. La Artificial Analysis encontró US$ 5,59 por tarea para la composición de GitHub frente a US$ 11,42 para Claude Code con Opus 5.5 en la configuración máxima, en el índice probado. En otra carga, el consumo, los errores y la revisión son otros, y la comparación tiene que rehacerse en ella.

¿La diferencia en el índice equivale a una tasa de error?

No. Los dos puntos de diferencia relatados por la Artificial Analysis son puntos del índice agregado, no un porcentaje de calidad ni una tasa de error por tarea. El riesgo operativo depende de la distribución de los tipos de trabajo y de los criterios de aceptación del propio equipo.

¿Menos tokens garantizan un costo menor?

No. Los tokens son una parte de la cuenta, y el precio depende de los modelos usados y de las condiciones de cobro. La Artificial Analysis informa 7,2 millones de tokens por tarea para la composición de GitHub, pero no detalla el costo de cada etapa ni prueba la causa aislada de la diferencia.

¿Cómo comparar el costo por tarea entre rutas?

El equipo debe ejecutar la misma carga con el mismo criterio de aceptación, atribuir los costos relevantes a la cohorte y declarar el tratamiento de rechazos y abandonos. También necesita comparar latencia, definir el tamaño mínimo de la cohorte y registrar los costos desconocidos. El promedio no prueba nada cuando el cobro cambia.

Referencias y lectura complementaria

La fuente primaria reúne la comparación de costo por tarea, el consumo de tokens y los resultados de los benchmarks para las configuraciones evaluadas. Los límites de la medición acompañan cualquier aplicación de esos datos fuera del conjunto probado. La referencia es esta:

• Artificial Analysis: orquestación de modelos, desempeño y costo por tarea.
• Enrutamiento de modelos de IA en producción: qué cambia cuando la ruta pasa a elegirse por tarea.

¿Qué decisión tomar antes de cambiar la ruta?

El equipo de TI debe seleccionar una carga representativa, declarar el resultado aceptable y comparar la composición con el modelo único en la misma cohorte, con tamaño mínimo, dispersión e intervalo. Solo después decide si el ahorro paga la calidad menor y el retrabajo. Un piloto sin conclusión es válido.

El Nexforce Router sitúa la discusión en la infraestructura de enrutamiento, no en el marcador de un benchmark. Para evaluarlo o evaluar cualquier alternativa, el comprador debe pedir evidencia sobre los datos necesarios para su propia cuenta y confirmar qué registra la implementación. La medición no comprueba capacidades específicas del Router.

Si la composición no cumple el criterio de aceptación para tareas críticas, el equipo mantiene el modelo único, siempre que este lo cumpla. Si la carga no es elegible para uno de los proveedores, la decisión está tomada antes del costo. Si pasa el criterio y reduce el costo de la cohorte, la ruta elegida paga su propia cuenta.