De las mejoras de calificación a los pagos: la ilusión de la demanda en la fusión de modelos
chaincatcherI. ¿Qué es la fusión de modelos?
En junio de 2026, el mercado de la IA vio aparecer dos productos llamados "Fusion" en menos de tres semanas.
El 12 de junio, OpenRouter lanzó Fusion Router, bajo el lema " Superando el rendimiento de vanguardia con Fusion ". En su evaluación exhaustiva de DRACO, el grupo de modelos compuesto por Fable 5 y GPT-5.5 obtuvo 69,0 puntos, superando los 65,3 puntos del modelo individual Fable 5. El argumento de venta de OpenRouter es sencillo: cuando un solo modelo no es suficiente, varios modelos responden a la misma pregunta, y luego un revisor los compara y sintetiza.

El 29 de junio, Cognition lanzó Devin Fusion, pero el título era " Rendimiento de vanguardia con un 35 % menos de coste ". En lugar de que varios modelos completen repetidamente toda la tarea, permite que el modelo principal se encargue de la planificación y la toma de decisiones, dejando las pruebas, las modificaciones mecánicas y otras tareas al modelo secundario, más económico, y cambiando dinámicamente de modelo durante la ejecución.

El mismo término apunta a dos lógicas económicas opuestas. OpenRouter utiliza más capacidad de procesamiento para adquirir mayores límites de capacidad; Cognition intenta reducir los costosos cálculos manteniendo su calidad original. Este contraste es más revelador que cualquier clasificación de modelos. La propuesta técnica de la fusión de modelos es cierta: múltiples intentos tienen la posibilidad de superar a uno solo. Pero lo que el mercado realmente premia no son "más llamadas a modelos", sino quién puede gastar menos y ofrecer resultados más rápido tras cumplir con los umbrales de calidad.
▲ Figura 1: Dos tipos de fusión en el mismo mes. Este artículo define la fusión de modelos como una arquitectura más específica: varios modelos responden a la misma tarea en paralelo, se revisan los modelos y se comparan sus resultados, y finalmente un modelo proporciona la respuesta. Devin Fusion no se ajusta a esta definición; se asemeja más al enrutamiento dinámico y la delegación de tareas. Se menciona al principio porque el mercado utiliza el término «fusión» como genérico para toda la orquestación multimodelos, mientras que los productos realmente eficaces suelen alejarse de la definición estricta de fusión de modelos.
Nuestra valoración es pesimista: Model Fusion es una costosa póliza de seguro de calidad. Si bien puede mejorar el rendimiento absoluto de ciertas tareas, rara vez amplía realmente la frontera de eficiencia entre costo, calidad y latencia. Muy pocas tareas justifican la inversión en este seguro. Si bien seguirá existiendo, es más probable que se convierta en una función de activación poco frecuente que en la arquitectura predeterminada, y es menos probable que llegue a ser una categoría independiente.
II. ¿Qué opciones de modelos están disponibles actualmente?
Las discusiones sobre Fusion suelen desviarse hacia clasificaciones de precisión, pero las empresas no compran clasificaciones. Compran resultados aceptables para una tarea, teniendo en cuenta también el precio, la latencia, la privacidad y la estabilidad. Siempre y cuando ya exista un modelo económico...
Una vez superado el umbral de aceptación empresarial, seguir pagando por funciones más avanzadas puede dejar de ser económicamente viable. La rentabilidad es el verdadero motor del mercado de los modelos.
▲ Figura 2: Inteligencia del modelo y coste de una sola tarea. Los puntos más destacables en la escala logarítmica no son las puntuaciones más altas en la esquina superior derecha, sino aquellos que se desvían de la tendencia precio-capacidad: estos ofrecen capacidad suficiente a un precio menor y representan valores atípicos de eficiencia para cargas de trabajo específicas. Si bien el índice compuesto no puede responder directamente qué modelo es el más adecuado para la revisión de código, la investigación en China o la implementación regulada, revela una tendencia: la oferta de modelos se está convirtiendo en un bien de consumo y el "modelo más potente" se está distanciando de la "opción óptima".
Actualmente existen cuatro estrategias de compra principales en el mercado para abordar la misma brecha de calidad.
El primer enfoque consiste en actualizar directamente a un modelo único más robusto. Este es el más sencillo y fácil de auditar; por lo general, sigue siendo la opción preferida siempre que el aumento marginal en el costo del modelo de gama alta sea menor que el costo de los errores o el retrabajo. El segundo enfoque consiste en aumentar el cálculo en tiempo de prueba en el mismo modelo, por ejemplo, extendiendo la inferencia, la autoconsistencia o el muestreo múltiple. El tercer enfoque es el enrutamiento, la cascada y la delegación de tareas: primero se utiliza un modelo más económico para manejar las partes verificables o mecánicas, y solo se actualiza si se presentan dificultades. El cuarto enfoque, en un sentido más estricto, es la fusión de modelos: hacer que varios modelos respondan repetidamente a la misma pregunta, y luego obtener la respuesta final mediante la revisión y síntesis de los modelos.
Los cuatro métodos permiten priorizar la calidad sobre la capacidad de cálculo, pero la diferencia radica en dónde se invierte dicha capacidad. Las extensiones de un solo modelo priorizan la inferencia profunda, el enrutamiento optimiza la asignación de recursos, mientras que Fusion prioriza la obtención de más respuestas candidatas. Los tres primeros métodos concentran sus presupuestos en las etapas con mayor probabilidad de modificar el resultado; Fusion, en cambio, prioriza las opiniones duplicadas y luego confía en que el modelo de revisión pueda identificar diferencias válidas. Los modelos candidatos deben proporcionar suficiente información independiente, y los revisores deben ser capaces de reconocerla.
La fusión es la única opción que puede superar a las otras tres.
El enrutamiento ha demostrado que las diferencias de capacidad entre los modelos representan principalmente una oportunidad de planificación. RouteLLM redujo los costos en más del doble en algunas evaluaciones sin sacrificar la calidad; Switchcraft logró una reducción de costos del 84 % con una precisión del 82,9 %, lo que, según el informe, se traduce en ahorros de más de 3600 dólares por millón de solicitudes. Si bien los resultados aún deben reproducirse con el tráfico de la propia empresa, la lógica económica es sencilla: en lugar de tener varios modelos en una conferencia, basta con asignar cada tarea al modelo más económico y calificado.
Esto significa que el mercado abordará primero la brecha de calidad mediante actualizaciones, enrutamiento y validación; solo cuando estos métodos sigan siendo insuficientes habrá una razón para comprar más respuestas candidatas para Fusion.
III. ¿Por qué mejorar las puntuaciones no equivale a tener valor?
Porque Fusion debe superar simultáneamente tres obstáculos: la calidad incremental debe cubrir el costo y la latencia adicionales, los modelos candidatos deben proporcionar información independiente y los revisores deben identificar consistentemente mejores respuestas. Si alguno de estos falla, la mejora de la puntuación no se puede traducir en valor de producción. Costo computacional: ¿Cuánto presupuesto y latencia adicionales se requieren? La mejora de la puntuación de Fusion es, ante todo, un gasto computacional definido. OpenRouter llama a múltiples modelos de panel en paralelo, y luego los revisores y el modelo integrado generan la respuesta. Los tres grupos de control en DRACO mostraron mejoras en la puntuación: Fable 5 + GPT-5.5 aumentó de 65.3 a 69.0; Opus 4.8 autofusión aumentó de 58.8 a 65.5; y el grupo de tres modelos de bajo costo aumentó de 60.3 a 64.7.
Sin embargo, la mejora de la autofusión de Opus es mayor, lo que sugiere que las ganancias pueden provenir de la búsqueda y el muestreo adicionales en lugar de la complementariedad del conocimiento entre modelos . Se debería hacer una comparación justa de la autoconsistencia, la inferencia más larga y los modelos de un solo agente fuertes bajo el mismo presupuesto de tokens. La investigación existente también muestra que los modelos multiagente pueden mejorar el rendimiento hasta en 7,1 puntos porcentuales con aproximadamente 20 veces el costo computacional; con el mismo presupuesto, el debate y la mezcla de agentes son solo 1,3 y 2,7 puntos porcentuales más altos que la autoconsistencia, respectivamente, mientras que otro estudio con tokens de razonamiento iguales encontró que los modelos de un solo agente están a la par o mejor. Muchas "ganancias de colaboración" desaparecen después de la alineación del libro mayor computacional.
▲ Figura 3: Mejora de la puntuación de referencia y coste del producto de OpenRouter. El panel predeterminado de 3 modelos de OpenRouter cuesta aproximadamente 4-5 veces más que un panel generado estándar y es 2-3 veces más lento . Sin embargo, no revela los tokens, costes y latencia completos para cada configuración de DRACO, lo que hace imposible determinar si la mejora de 3,7 puntos merece la pena. La evaluación solo incluyó 100 tareas de texto en inglés plano, con solo 93 de las configuraciones relacionadas con Fable completadas. Cambiar el modelo de revisión puede modificar la puntuación absoluta en 10-25 puntos porcentuales. Esto demuestra que Fusion puede mejorar las puntuaciones, pero no demuestra que Fusion mejore el ROI de producción.
La invocación selectiva solo puede reducir los costos. Según las estimaciones divulgadas por OpenRouter, el costo total es aproximadamente 1,03-1,04 veces mayor cuando la tasa de activación es del 1%; 1,30-1,40 veces mayor cuando es del 10%; y 1,75-2,00 veces mayor cuando es del 25%.
▲ Figura 4: Economía general de la invocación selectiva de Fusion. Las solicitudes más difíciles son las que tienen más probabilidades de activar Fusion, pero el sistema debe esperar a los miembros del panel más lentos antes de completar la revisión y la generación en serie. Por lo tanto, la latencia de cola se concentra en las tareas más valiosas. La invocación de múltiples proveedores también amplía la superficie de fallos, la complejidad de la auditoría y la exposición de la privacidad. El coste de Fusion no es solo el precio de la API, sino también el tiempo de espera y los riesgos adicionales del sistema. Complementariedad de la información: ¿Los múltiples modelos realmente proporcionan información diferente? El valor de Fusion depende de si los modelos candidatos aportan información independiente, pero los diferentes modelos a menudo comparten corpus de entrenamiento, fuentes de páginas web y premisas erróneas. En las tareas de investigación, esto lleva al "blanqueo de citas" : múltiples modelos se remontan a la misma fuente, pero se empaquetan como múltiples piezas de evidencia independientes. Si el sistema no conserva la procedencia a nivel de afirmación y las rutas de búsqueda, el coste de la API aumenta casi linealmente con el número de modelos, pero la diversidad de la evidencia no necesariamente aumenta.
En su artículo de 2026 , *¿Cuándo ayuda la combinación de modelos de lenguaje?* , Josef Chen, cofundador y CEO de KAIKAKU.AI, estudió 67 modelos de 21 proveedores de servicios. En tareas matemáticas abiertas, la probabilidad predicha de que todos los modelos respondieran incorrectamente de forma simultánea era del 2,3 %, pero la probabilidad real alcanzó el 5,2 %, aproximadamente 2,3 veces el valor predicho . La tasa de fallo conjunto aumentó aún más al 7,9 % y al 12,7 % en la tarea de codificación de puntuación y la versión de respuesta libre de GPQA-Diamond, respectivamente. Con 100 preguntas de GPQA-Diamond, aproximadamente 13 preguntas harían que todos los modelos candidatos respondieran incorrectamente, sin dejar ninguna respuesta correcta para la votación, revisión o síntesis. La divergencia del modelo en preguntas fáciles amplifica el valor combinado, mientras que en las preguntas más cruciales del final, podrían fallar todos. Evaluar la fiabilidad: ¿Puede el sistema identificar y sintetizar mejores respuestas? Incluso con respuestas complementarias de los candidatos, el valor sigue dependiendo de la revisión. Cuando los candidatos son consistentes, los revisores podrían interpretar erróneamente errores similares como un alto grado de confianza; cuando los candidatos divergen, se requiere suficiente experiencia para seleccionar la respuesta correcta. El modelo integral también puede eliminar opiniones minoritarias clave o transformar desacuerdos reales en conclusiones definitivas.
En tareas de codificación, los compiladores, las pruebas y el análisis estático suelen ser más fiables que la opinión de otro modelo; en tareas creativas, la revisión y la síntesis pueden fácilmente diluir las diferencias en una respuesta promedio. Incluso el modelo de revisión estándar más potente de LitBench solo alcanza un 73 % de concordancia con las preferencias humanas en la escritura creativa. Cuando existen validadores externos económicos para la tarea, o cuando la propia definición de "bueno" depende del juicio subjetivo, las mejoras en la puntuación de Fusion son difíciles de traducir en valor comercial.
IV. ¿Quién pagará por Fusion?
La demanda de Fusion depende de dos factores: si la tarea puede beneficiarse de múltiples modelos y si este beneficio es suficiente para generar ingresos sostenidos. El primero es una cuestión técnica, mientras que el segundo es una cuestión de mercado. Desde la aplicabilidad técnica hasta la viabilidad económica, Fusion exige que la probabilidad de corregir un error multiplicada por la pérdida evitable de un solo error supere el costo, la latencia, la complejidad operativa y los riesgos de privacidad que implica agregar nuevas API.
Las puntuaciones de referencia no pueden responder a esta pregunta sobre pérdidas y ganancias. La fusión solo es viable cuando el costo del error es alto, los modelos candidatos proporcionan rutas de búsqueda complementarias, faltan validadores externos más económicos y la empresa puede aceptar una latencia adicional y el riesgo del proveedor; el resultado final aún debe ser confirmado por evidencia humana o externa.
▲ Figura 5: De la aplicabilidad tecnológica a las necesidades sostenibles Quienes cumplen estos criterios incluyen principalmente investigación de alto valor y debida diligencia, revisiones de arquitectura y seguridad, y "segundas opiniones" antes de decisiones irreversibles. Comparten características comunes: restricciones incompletas, altos costos de omisiones y el valor inherente de un enfoque independiente. Por el contrario, el código regular, las aplicaciones de consumo inmediato, los flujos de trabajo de alto rendimiento y bajo margen, y las tareas directamente verificables mediante pruebas o reglas generalmente no requieren fusión. Los organismos reguladores también pueden rechazar paneles de múltiples proveedores debido a límites de datos y requisitos de auditoría. De la disposición a pagar a las necesidades sostenibles La utilidad tecnológica puede generar una alta disposición a pagar, pero no equivale a una demanda escalable. Para que se materialice una demanda sostenible, las pérdidas por errores deben ser cuantificables, las tareas deben ser recurrentes, debe haber responsabilidades presupuestarias claramente definidas dentro de la organización, y la fusión debe superar consistentemente a los expertos humanos, los modelos de entidad única fuertes y la validación externa. Sin embargo, los presupuestos destinados a la debida diligencia suelen ir a parar a analistas y fuentes de confianza, los presupuestos de seguridad a auditorías profesionales, y las decisiones irreversibles se toman con demasiada poca frecuencia.
Por lo tanto, no somos optimistas con respecto a las empresas que solo proporcionan adaptadores multimodelos, ejecutan paneles por defecto o tratan los algoritmos de selección de modelos estáticos como una ventaja competitiva. Conectar API es fácil de replicar, y las estrategias fijas se vuelven rápidamente ineficaces a medida que cambian las capacidades y los precios de los modelos; sin conocer la tasa de error y cuántas veces Fusion corrigió realmente los errores, es imposible fijar el precio de este seguro. Quienes controlan los resultados reales tienen más probabilidades de capturar valor: plataformas de puerta de enlace y agentes, aplicaciones verticales, propietarios de flujos de trabajo y productos de evaluación y observabilidad. Conocen el costo de los errores, pueden observar los resultados y pueden optimizar las estrategias de activación. Lo que realmente es difícil de replicar no es la lista de paneles, sino determinar cuándo no invocar a Fusion. Validación de mercado: los mercados públicos son insuficientes para determinar la escala de la demanda de Fusion, pero ya muestran cómo se está utilizando. Perplexity Model Council solo está disponible para usuarios de Max y Enterprise Max que pagan $200 por mes. Los usuarios seleccionan manualmente tres modelos en la web para investigación de inversiones, toma de decisiones complejas y validación de información; los casos de uso públicos incluyen la integración de Model Council en flujos de trabajo de investigación de acciones a través de la automatización del navegador. La solución Mixture of Agents de Hermes presenta Fusion como un modelo virtual seleccionable dentro del agente: los usuarios pueden actualizar a un único problema complejo mediante /moa, o habilitarlo continuamente en sesiones complejas, con análisis proporcionados por múltiples modelos de referencia, y el agregador llama a herramientas para completar la tarea. Posteriormente, Hermes redujo la frecuencia de ramificación predeterminada y reutilizó la retroalimentación de modelos anteriores para controlar los costos. Estos ejemplos ilustran que la demanda real de Fusion se concentra en tareas complejas y de baja frecuencia, como la investigación, la depuración, la revisión y la toma de decisiones críticas. El uso típico consiste en actualizaciones proactivas después de que un único modelo encuentra un cuello de botella, en lugar de un proceso automatizado de alta frecuencia habilitado por defecto. La evidencia existente demuestra que esta demanda existe, pero la información disponible públicamente aún es insuficiente para determinar si puede conformar un mercado de pago independiente y a gran escala.
V. El futuro de la fusión
Si bien la disminución de los costos de inferencia parece beneficiar a Fusion, también reduce simultáneamente los costos de los modelos individuales robustos, el enrutamiento y la validación externa. Fusion no compite en función de las llamadas a modelos del pasado, sino en la mejora continua de los modelos individuales de próxima generación y las bases de orquestación.
Devin Fusion de Cognition demuestra la dirección de esta competencia: dejar los modelos costosos para la etapa de toma de decisiones y delegar tareas mecánicas y verificables a modelos más económicos. En las pruebas internas del proveedor, la puntuación general de Fusion + Fable 5 aumentó ligeramente de 57,0 a 57,6, con un costo promedio que disminuyó de $5,12 a $3,00; sin embargo, en los cinco estudios de caso publicados, si bien los costos disminuyeron entre un 25 % y un 62 %, las puntuaciones de las tareas fluctuaron entre +12 y -27. Las refactorizaciones ES6 bien definidas y exhaustivamente probadas aumentaron de 98 a 100 puntos; las funciones de React/Redux que dependen de la comprensión de la interacción y los requisitos implícitos, cuando se delegan incorrectamente, cayeron de 54 a 27 puntos.
▲ Figura 6: Puntuaciones y costes de las tareas de Devin Fusion. Estos son ejemplos seleccionados por los proveedores y no representan la distribución general, pero señalan claramente lo siguiente: la capacidad principal de los futuros sistemas multimodelo no es llamar a más modelos, sino definir los límites de degradación correctos. Las tareas mecánicas y verificables pueden asignarse a modelos más económicos, mientras que las tareas que requieren un juicio profundo deben dejarse a los modelos de vanguardia. OpenRouter vende "más inteligencia", mientras que Cognition vende "inteligencia equivalente a un coste menor"; la segunda propuesta se acerca más a la dirección a largo plazo. Cuanto más se acerque el sistema a la economía de producción, menos se parecerá a Model Fusion en sentido estricto y más se parecerá al enrutamiento, la delegación y la verificación.
A finales de julio, los medios informaron que Stripe estaba en conversaciones para adquirir OpenRouter por aproximadamente 10 mil millones de dólares, aunque el acuerdo aún no se ha confirmado. Esta señal no debe interpretarse como una validación de mercado para Fusion: el valor principal de OpenRouter no reside en ningún panel en particular, sino en su capa de llamadas neutral que conecta a más de 5 millones de desarrolladores con más de 400 modelos. Stripe ya proporciona facturación, impuestos y control de riesgos para OpenRouter, y permite a los desarrolladores crear cuentas, obtener claves API y conectarse a pagos directamente a través de Stripe Projects. Lo que Stripe probablemente esté adquiriendo es la pasarela de transacciones para la inferencia de IA: OpenRouter controla la selección de modelos, el uso de tokens y los costos, mientras que Stripe gestiona los precios, la facturación y los pagos. Esto proporciona una señal de mercado para el juicio de valor mencionado anteriormente: es más probable que el valor en la era multimodelo permanezca en la capa de orquestación, que puede observar tareas, asignar llamadas y completar liquidaciones; Fusion es simplemente una estrategia de actualización de alto costo que se añade a eso.
Los futuros sistemas multimodelos no invocarán automáticamente los paneles; en su lugar, primero estimarán la dificultad de la tarea, los costos de validación y las penalizaciones por errores. La búsqueda de divergencia multimodelos solo se llevará a cabo cuando los modelos individuales más robustos, la inferencia extendida y las herramientas externas resulten insuficientes. La tasa de activación, la tasa de éxito incremental y el costo validado por unidad de resultado son las únicas métricas de producto relevantes. La fusión seguirá siendo una característica de baja frecuencia, en lugar de convertirse en la arquitectura predeterminada o una categoría independiente.
VI. Fuentes
OpenRouter: Superando el rendimiento de vanguardia con Fusion
Documentación del enrutador OpenRouter Fusion
Cognición: Devin Fusion --- Rendimiento de vanguardia con un 35 % menos de coste.
Microsoft Research: Switchcraft --- Enrutador de modelos de IA para llamadas a herramientas agenciales
¿Cuándo resulta útil combinar modelos de lenguaje?
El razonamiento multiagente mejora la eficiencia computacional.
Los sistemas LLM de un solo agente superan a los sistemas multiagente en el razonamiento de múltiples saltos bajo presupuestos de tokens de pensamiento iguales.
La combinación de agentes mejora las capacidades de los modelos de lenguaje a gran escala.
RouteLLM: Aprendiendo a enrutar LLM con datos de preferencias
LitBench: Un referente para la evaluación de la escritura creativa
Comparación de modelos de análisis artificial
El precio del progreso: rendimiento de los precios y el futuro de la IA
Perplejidad: ¿Qué es un Consejo Modelo?
Ejemplo de usuario de Perplexity: Consejo Modelo para la investigación financiera
Documentación de Hermes Agent: Mixture of Agents
Stripe impulsa el acceso al modelo de IA global de OpenRouter.
Axios: ¿Qué hay detrás del supuesto cambio de Stripe hacia OpenRouter?
Este contenido se proporciona únicamente con fines informativos y educativos y no constituye asesoramiento de inversión relacionado con BTCC. BTCC realiza todos los esfuerzos posibles, pero no puede garantizar la veracidad, exactitud u originalidad del contenido anterior.