Orquestração multi-LLM: troca de modelo, comparação e fallback

A implantação de um único modelo é uma decisão que você supera

As equipes não permanecem fiéis a um único LLM, e não deveriam. O modelo local rápido que responde perfeitamente às perguntas de suporte falha na análise jurídica nuançada. O modelo de fronteira que lida com raciocínio custa caro demais para responder "o que há neste documento?". Um provider muda preços, descontinua um modelo ou entra em outage - e de repente todo o produto está fora do ar ou em renegociação. Uma plataforma de IA séria trata, portanto, "qual modelo" como uma decisão de runtime, não de instalação.

O Simmetric Chat trata isso de ponta a ponta: cada fronteira de provider é uma estratégia, o modelo é selecionável por chat, a avaliação está integrada na interface e a falha degrada graciosamente em vez de dar erro. Este artigo percorre a camada de orquestração - os providers, a experiência de troca, o modo de comparação e a cadeia de fallback.

Cinco providers de primeira classe, vinte presets

Prontos para usar, a plataforma fala com cinco providers de primeira classe: Ollama (local, o padrão privacy-first), OpenAI, Anthropic, OpenRouter e Gemini. Cada um tem um parser de streaming dedicado - os formatos de rede diferem o suficiente para que tratar o streaming como um problema genérico produza bugs sutis - então o streaming de tokens, as citações e os eventos terminais são analisados por provider em vez de aproximados.

Além dos cinco de primeira classe, vinte presets de provider cobrem o ecossistema compatível com OpenAI: DeepSeek, Mistral, Kimi/Moonshot, NVIDIA NIM, Qwen, xAI, Z.AI/GLM, MiniMax, LM Studio, GitHub Copilot e outros. Como esses serviços implementam o protocolo de rede OpenAI, adicionar um é uma linha de configuração - URL base, chave, lista de modelos - não uma mudança de código. Uma implantação pode então misturar um Ollama local para o trabalho sensível, um modelo de fronteira na nuvem para análise profunda e um provider compatível com OpenAI barato para sumarização em massa, tudo em um único workspace.

A configuração segue as regras de precedência da plataforma: as variáveis de ambiente estabelecem os padrões no nível da infraestrutura, as mudanças pelo painel de administração têm efeito imediato, e as configurações se resolvem banco de dados sobre ambiente sobre padrões. O provider global padrão é exatamente isso - um padrão, sobrescrevível por workspace e por chat.

Trocar de modelo sem sair da conversa

A seleção de modelo vive onde vive a conversa. O input do chat carrega um badge de modelo que mostra o que responderá à próxima mensagem; clicar nele - ou pressionar Cmd+K (Ctrl+K no Windows/Linux) - abre a paleta de troca rápida. A paleta agrupa os modelos por provider e os anota com badges de capacidade derivados dos metadados do modelo:

• local-only - roda on-premise, sem dados de saída
• fastest - a menor latência no conjunto atual de providers
• smartest - a maior qualidade disponível
• reasoning - capaz de chain-of-thought

Digitar /model <nome> na caixa de entrada troca instantaneamente para um modelo correspondente, com uma paleta filtrada como repliegue quando o nome não é uma correspondência exata. O texto do comando é removido da mensagem antes do envio, para que o slash command nunca polua o histórico do chat.

Dois detalhes tornam isso ergonômico em vez de apenas possível. Primeiro: a troca acontece no meio da conversa - o mesmo chat pode se mover de um modelo local para um de fronteira e voltar, com cada mensagem persistindo qual modelo realmente a serviu - a trilha de auditoria do uso de modelos sobrevive à troca. Segundo: a paleta é uma superfície keyboard-first - o padrão Cmd+K faz a escolha de modelo custar uma tecla, não uma viagem a uma página de configurações, que é a diferença entre uma funcionalidade que as pessoas usam e uma que configuram uma vez e esquecem.

Comparação lado a lado

Escolher um modelo a partir de uma descrição é um tiro no escuro; escolhê-lo vendo duas respostas ao seu prompt real é engenharia. Pressionar Cmd+Shift+M (Ctrl+Shift+M) abre a comparação lado a lado de modelos: dois painéis fluem simultaneamente com respostas de modelos diferentes para o mesmo prompt, token a token.

O fluxo que isso habilita é o que os harnesses de avaliação formalizam, mantido na superfície cotidiana:

• Pergunte uma vez, observe os dois modelos raciocinarem - latência, formulação e diferenças de grounding ficam imediatamente visíveis
• Conserve uma resposta e continue a conversa com aquele modelo
• Envie para um painel único para reunir as saídas em uma só thread
• Feche a comparação e continue com um ou outro modelo

Como a comparação usa a mesma infraestrutura de streaming e citações do chat normal, as respostas comparadas chegam com suas citações RAG intactas - você pode avaliar não apenas como um modelo formula uma resposta, mas se a fundamenta nas fontes corretas. Essa distinção importa numa plataforma de retrieval: um modelo que escreve magnificamente mas cita o documento errado é pior que um que escreve com simplicidade e cita corretamente.

A cadeia de fallback

Os modelos ficam indisponíveis: um outage do provider, um nome de modelo descontinuado, uma cota esgotada no meio da conversa. A resposta do Simmetric Chat é uma cadeia de fallback determinística - se o modelo selecionado ficar indisponível, o sistema recua automaticamente para o padrão do workspace, depois para o padrão global, depois para qualquer modelo disponível. Um toast avisa sobre a troca, com uma opção Desfazer.

A cadeia dispara tanto no polling periódico (a cada trinta segundos) quanto nos erros SSE durante o streaming, para que uma falha do provider no meio de uma resposta seja redirecionada sem perder a conversa. O objetivo de design é específico: um outage de modelo deveria degradar a plataforma para seu próximo modelo, não degradá-la para uma página de erro. Os usuários veem uma notificação em vez de um stack trace, e o operador vê uma plataforma que continuou a servir.

Para implantações multi-instância, a mesma filosofia de design se estende para fora - o fan-out do streaming e a fila de jobs que mantêm o chat responsivo sob carga são estado externalizado, tratado separadamente no artigo sobre escalabilidade.

O que a camada de orquestração compra para você

Reunindo os fios, a camada de orquestração é o que transforma a escolha de provider de uma decisão de aquisição em um conjunto de alavancas de runtime:

• Controle de custos. Encaminhe o trabalho em massa para um provider compatível com OpenAI barato e reserve o modelo de fronteira para os prompts que o exigem, por chat em vez de por implantação.
• Zonas de privacidade. Mantenha workspaces sensíveis ancorados em modelos local-only, deixando os workspaces gerais usarem providers na nuvem - os badges de capacidade tornam a zona visível no momento da seleção.
• Resiliência. Os outages de provider se tornam trocas de modelo, não tempo de inatividade, com a cadeia de fallback e o redirecionamento do streaming.
• Avaliação como hábito. A comparação lado a lado transforma "em qual modelo padronizamos?" em uma verificação de dois minutos por semana em vez de um projeto de pesquisa trimestral.

Tudo repousa sobre a mesma fronteira de provider em padrão de estratégia que o resto da plataforma usa, então adicionar um provider - de primeira classe ou preset compatível com OpenAI - nunca toca o chat, o RAG ou o ciclo do agente.

Leia o guia completo na documentação →