⚖️ OpenRouter Fusion
El otro patrón de orquestación: en vez de dividir la tarea y delegar partes (Fugu), Fusion envía el mismo prompt a varios modelos en paralelo y deja un juez fusionar las respuestas. Ensemble, no descomposición, y la mentalidad de orquestar teniendo en cuenta los costos.
Nota: todos reciben el mismo prompt (no fragmentos diferentes). Es ensemble en paralelo + juez: lo opuesto a la descomposición de Fugu. Quédate con esta imagen: define toda la ruta.
Mapa de la ruta
Contenido detallado
⚖️ El mismo prompt, N modelos, un juez
El mecanismo de Fusion, por qué mejora y qué lo distingue de Fugu: ensemble en paralelo frente a descomposición en partes.
Fusion toma uno envía el prompt, sin modificarlo, a varios modelos al mismo tiempo. Cada modelo responde a toda la tarea por su cuenta: nadie recibe solo un fragmento.
Es la diferencia de fábrica de Fugu. Quien confunde "varios modelos" con "descomponer la tarea" no entiende ninguno de los dos. Aquí hay replicación, no reparto.
Ensemble · fan-out · mismo prompt · candidatos en paralelo.
Después de que N modelos responden, un modelo juez lee todas las respuestas y produce la final: elige la mejor, vota o reescribe una híbrida. Es la «fusión» de Fusion.
El juez es donde el ensemble se convierte en una respuesta. Sin él, solo tienes N candidatas sueltas. La calidad del juez es la mitad de la calidad de Fusion.
LLM-as-judge · merge · agregación · elegir la mejor vs. síntesis.
Los distintos modelos se equivocan de maneras diferentes. Cuando varios responden al mismo prompt, los aciertos tienden a coincidir y los errores se dispersan; entonces, el juez puede favorecer el consenso.
Es la teoría detrás del ensemble: la diversidad reduce el error idiosincrático. Pero solo funciona si los modelos son realmente diversos; los modelos iguales se equivocan igual.
Diversidad · errores no correlacionados · consenso · sabiduría de las multitudes.
Fugu descompone: divide la tarea, asigna partes a especialistas y las reúne. Fusion replica: el mismo prompt completo se envía a todos, y un juez fusiona las respuestas en competencia.
Son dos respuestas opuestas a la pregunta «quién hace cada parte». Entender el contraste te da el vocabulario para clasificar cualquier orquestador que encuentres.
Descomponer vs. replicar · partes vs. candidatos · gerente vs. juez.
Fusion tiene una familia. Autoconsistencia: preguntar varias veces al mismo modelo y votar por la respuesta más común. Mixture-of-agents: capas de modelos que refinan las respuestas de los demás.
Reconocer los parientes muestra que «paralelo + agregación» es un patrón antiguo y bien estudiado: Fusion solo lo empaqueta entre proveedores detrás de una API.
Autoconsistencia · LLM-as-judge · mixture-of-agents · votación.
Ejecutar N modelos significa pagar N respuestas completas, más la llamada del juez, que las lee todas. Gastas ≈ N+1 veces para entregar una sola respuesta.
El costo es el talón de Aquiles del ensemble. Sin sumar los N+1, "preguntarles a todos" parece gratis; al hacer las cuentas, queda claro cuándo conviene (y cuándo no).
Costo N+1 · tokens del juez · latencia del más lento · costo × beneficio.
🚀 Fusion en la práctica y el futuro de la skill
Cuándo conviene el ensemble, cuándo basta con 1 modelo potente, cómo crear tú mismo el patrón "juez" y cómo orquestar con conciencia de costos.
El ensemble destaca cuando el error es costoso y no hay una respuesta verificable: decisiones abiertas, redacción de alto riesgo, tareas en las que la diversidad de perspectivas detecta lo que un solo modelo pasaría por alto.
Define el nicho real de Fusion. Sin saber dónde gana, la aplicas a todo (caro) o a nada (pierdes la ganancia de robustez).
Costo del error · sin respuestas correctas · robustez · alta varianza.
Si un modelo de primer nivel ya resuelve la tarea, el ensemble solo añade costo y espera sin cambiar el resultado; eso es exactamente lo que mostraron las 38 pruebas de Fugu (empate en 36/38).
Es la opción predeterminada más honesta. La mayoría de las tareas "se resuelven en la cima del ladder": 1 modelo potente empata, más rápido y barato. Orquestar es la excepción, no la regla.
Límite ya alcanzado · ladder de decisión · default = 1 modelo.
No necesitas una API especial para el patrón Fusion. Pídele a Claude Code N respuestas desde distintos enfoques y un agente juez que las fusione: ensemble manual, control total.
Desmitifica Fusion: el patrón es tuyo, no del producto. Saber montarlo a mano te permite elegir cuándo vale la pena ejecutarlo y ver el costo antes de pagar.
Ensemble manual · agente-juez · fan-out + merge · copy-run.
La pregunta correcta no es «qué modelo es mejor», sino «cuál es el costo por resultado aceptable». A veces, 3 modelos baratos + un juez superan a 1 modelo caro por el mismo dinero.
Es la métrica que usa el autor de la prueba de campo: optimizar la economía unitaria, no la vanidad del benchmark. Pensar en $/resultado cambia todas las decisiones de orquestación.
Costo por resultado · barato×bueno · equilibrio entre calidad y costo · ROI de la llamada.
Ejecutar modelos de varios proveedores a través de una sola API es un seguro: si un modelo deja de funcionar, se vuelve caro o pierde calidad, tu aplicación no se detiene; continúa con los demás.
Es el beneficio de Fusion que no depende de la calidad adicional. Incluso cuando el ensemble no mejora la respuesta, la cobertura frente al lock-in puede valer por sí sola.
Dependencia de un proveedor · hedge · resiliencia · entre proveedores.
La habilidad que se desarrolla: saber cuándo orquestar, cuál predeterminado (descomponer vs. ensemble), y a qué costo — en vez de adoptar el producto más automático por moda.
Es el destino del curso. La idea es el futuro; el criterio para saber cuándo aplicarla es lo que distingue a quien orquesta bien de quien solo quema tokens.
Juicio de orquestación · conciencia de costos · patrón adecuado · mentalidad.