Orquestación multi-LLM: cambio de modelo, comparación y fallback

El despliegue de un solo modelo es una decisión que superas

Los equipos no se mantienen fieles a un solo LLM, y no deberían. El modelo local rápido que responde perfectamente a las preguntas de soporte falla en el análisis legal matizado. El modelo de frontera que maneja el razonamiento cuesta demasiado para responder a «¿qué hay en este documento?». Un provider cambia precios, retira un modelo o entra en outage - y de repente todo el producto está caído o en renegociación. Una plataforma de IA seria trata por tanto «qué modelo» como una decisión de runtime, no de instalación.

Simmetric Chat la trata así de punta a punta: cada frontera de provider es una estrategia, el modelo es seleccionable por chat, la evaluación está integrada en la interfaz y el fallo degrada con gracia en lugar de dar error. Este artículo recorre la capa de orquestación - los providers, la experiencia de cambio, el modo de comparación y la cadena de fallback.

Cinco providers de primera clase, veinte presets

Listos para usar, la plataforma habla con cinco providers de primera clase: Ollama (local, el default privacy-first), OpenAI, Anthropic, OpenRouter y Gemini. Cada uno tiene un parser de streaming dedicado - los formatos de red difieren lo suficiente como para que tratar el streaming como un problema genérico produzca bugs sutiles - así que el streaming de tokens, las citas y los eventos terminales se analizan por provider en lugar de aproximarse.

Más allá de los cinco de primera clase, veinte presets de provider cubren el ecosistema compatible con OpenAI: DeepSeek, Mistral, Kimi/Moonshot, NVIDIA NIM, Qwen, xAI, Z.AI/GLM, MiniMax, LM Studio, GitHub Copilot y otros. Como esos servicios implementan el protocolo de red OpenAI, añadir uno es una línea de configuración - URL base, clave, lista de modelos - no un cambio de código. Un despliegue puede por tanto mezclar un Ollama local para el trabajo sensible, un modelo de frontera cloud para el análisis profundo y un provider compatible OpenAI barato para la summarización en bloque, todo en un solo workspace.

La configuración sigue las reglas de precedencia de la plataforma: las variables de entorno establecen los defaults a nivel de infraestructura, los cambios desde el panel de administración tienen efecto inmediato, y los ajustes se resuelven base de datos sobre entorno sobre defaults. El provider global por defecto es exactamente eso - un default, sobrescribible por workspace y por chat.

Cambiar de modelo sin salir de la conversación

La selección del modelo vive donde vive la conversación. El input del chat lleva un badge de modelo que muestra qué responderá al próximo mensaje; al hacer clic en él - o pulsar Cmd+K (Ctrl+K en Windows/Linux) - se abre la paleta de cambio rápido. La paleta agrupa los modelos por provider y los anota con badges de capacidad derivados de los metadatos del modelo:

• local-only - corre on-premise, sin datos salientes
• fastest - la latencia más baja en el conjunto actual de providers
• smartest - la calidad más alta disponible
• reasoning - capaz de chain-of-thought

Escribir /model <nombre> en la caja de entrada cambia instantáneamente a un modelo coincidente, con una paleta filtrada como repliegue cuando el nombre no es una coincidencia exacta. El texto del comando se elimina del mensaje antes del envío, para que el slash command nunca contamine el historial del chat.

Dos detalles hacen esto ergonómico en lugar de solo posible. Primero: el cambio es a mitad de conversación - el mismo chat puede moverse de un modelo local a uno de frontera y volver, con cada mensaje persistiendo qué modelo lo sirvió realmente - la traza de auditoría del uso de modelos sobrevive al cambio. Segundo: la paleta es una superficie keyboard-first - el patrón Cmd+K hace que elegir modelo cueste una tecla, no un viaje a una página de ajustes, que es la diferencia entre una funcionalidad que la gente usa y una que configura una vez y olvida.

Comparación lado a lado

Elegir un modelo a partir de una descripción es un tiro al aire; elegirlo viendo dos respuestas a tu prompt real es ingeniería. Pulsar Cmd+Shift+M (Ctrl+Shift+M) abre la comparación lado a lado de modelos: dos paneles fluyen simultáneamente con respuestas de modelos distintos para el mismo prompt, token a token.

El flujo que habilita es el que los harnesses de evaluación formalizan, mantenido en la superficie cotidiana:

• Pregunta una vez, observa ambos modelos razonar - latencia, formulación y diferencias de grounding son inmediatamente visibles
• Conserva una respuesta y continúa la conversación con ese modelo
• Envía a un panel único para reunir las salidas en un solo hilo
• Cierra la comparación y continúa con uno u otro modelo

Como la comparación usa la misma infraestructura de streaming y citas que el chat normal, las respuestas comparadas llegan con sus citas RAG intactas - puedes evaluar no solo cómo formula un modelo una respuesta sino si la funda en las fuentes correctas. Esta distinción importa en una plataforma de retrieval: un modelo que escribe espléndidamente pero cita el documento equivocado es peor que uno que escribe sencillamente y cita correctamente.

La cadena de fallback

Los modelos se vuelven no disponibles: un outage del provider, un nombre de modelo retirado, una cuota agotada a mitad de conversación. La respuesta de Simmetric Chat es una cadena de fallback determinista - si el modelo seleccionado se vuelve no disponible, el sistema recae automáticamente en el default del workspace, luego en el default global, luego en cualquier modelo disponible. Un toast te avisa del cambio, con una opción Deshacer.

La cadena se activa tanto en el polling periódico (cada treinta segundos) como en los errores SSE durante el streaming, para que un fallo del provider a mitad de respuesta se redirija sin perder la conversación. El objetivo de diseño es específico: un outage de modelo debería degradar la plataforma a su modelo siguiente, no degradarla a una página de error. Los usuarios ven una notificación en lugar de una stack trace, y el operador ve una plataforma que siguió sirviendo.

Para los despliegues multi-instancia la misma filosofía de diseño se extiende hacia fuera - el fan-out del streaming y la cola de jobs que mantienen el chat reactivo bajo carga son estado externalizado, tratado aparte en el artículo de escalado.

Qué te compra la capa de orquestación

Reuniendo los hilos, la capa de orquestación es lo que transforma la elección de provider de una decisión de aprovisionamiento en un conjunto de palancas de runtime:

• Control de costes. Enruta el trabajo masivo a un provider compatible OpenAI barato y reserva el modelo de frontera a los prompts que lo exigen, por chat en lugar de por despliegue.
• Zonas de privacidad. Mantén los workspaces sensibles anclados a modelos local-only dejando que los workspaces generales usen providers cloud - los badges de capacidad hacen la zona visible en el momento de la selección.
• Resiliencia. Los outages de provider se convierten en cambios de modelo, no en tiempos de inactividad, con la cadena de fallback y la redirección del streaming.
• La evaluación como hábito. La comparación lado a lado convierte «¿en qué modelo estandarizamos?» en un control de dos minutos a la semana en lugar de un proyecto de investigación trimestral.

Todo descansa en la misma frontera de provider en patrón estrategia que usa el resto de la plataforma, así que añadir un provider - de primera clase o preset compatible OpenAI - nunca toca el chat, el RAG o el bucle del agente.

Lee la guía completa en la documentación →