Orchestrazione multi-LLM: cambio modello, confronto e fallback

Il deployment a un solo modello è una decisione che superate

I team non restano fedeli a un solo LLM, e non dovrebbero. Il modello locale veloce che risponde perfettamente alle domande di supporto fallisce nell'analisi legale sfumata. Il modello di frontiera che gestisce il ragionamento costa troppo per rispondere a "cosa c'è in questo documento?". Un provider cambia prezzi, dismette un modello o va in outage - e all'improvviso l'intero prodotto è giù o in renegotiazione. Una piattaforma AI seria quindi tratta "quale modello" come una decisione di runtime, non di installazione.

Simmetric Chat la tratta così su tutto: ogni confine di provider è una strategia, il modello è selezionabile per chat, la valutazione è integrata nell'interfaccia e il guasto degrada con grazia anziché dare errore. Questo articolo percorre lo strato di orchestrazione - i provider, l'esperienza di cambio, la modalità di confronto e la catena di fallback.

Cinque provider di prima classe, venti preset

Pronti all'uso, la piattaforma parla con cinque provider di prima classe: Ollama (locale, il default privacy-first), OpenAI, Anthropic, OpenRouter e Gemini. Ognuno ha un parser di streaming dedicato - i formati di rete differiscono abbastanza che trattare lo streaming come un problema generico produca bug sottili - così lo streaming dei token, le citazioni e gli eventi terminali sono analizzati per provider anziché approssimati.

Oltre i cinque di prima classe, venti preset di provider coprono l'ecosistema compatibile OpenAI: DeepSeek, Mistral, Kimi/Moonshot, NVIDIA NIM, Qwen, xAI, Z.AI/GLM, MiniMax, LM Studio, GitHub Copilot e altri. Poiché quei servizi implementano il protocollo di rete OpenAI, aggiungerne uno è una riga di configurazione - URL di base, chiave, lista modelli - non una modifica al codice. Un deployment può quindi mescolare un Ollama locale per il lavoro sensibile, un modello di frontiera cloud per l'analisi approfondita e un provider compatibile OpenAI economico per la summarizzazione in blocco, tutto in un solo workspace.

La configurazione segue le regole di precedenza della piattaforma: le variabili d'ambiente stabiliscono i default a livello di infrastruttura, le modifiche dal pannello di amministrazione hanno effetto immediato, e le impostazioni risolvono database sopra environment sopra default. Il provider predefinito globale è esattamente questo - un default, sovrascrivibile per workspace e per chat.

Cambiare modello senza lasciare la conversazione

La selezione del modello vive dove vive la conversazione. L'input della chat porta un badge del modello che mostra cosa risponderà al prossimo messaggio; cliccandolo - o premendo Cmd+K (Ctrl+K su Windows/Linux) - si apre la palette di cambio rapido. La palette raggruppa i modelli per provider e li annota con badge di capacità derivati dai metadati del modello:

• local-only - gira on-premise, nessun dato in uscita
• fastest - latenza più bassa nell'insieme attuale di provider
• smartest - la qualità più alta disponibile
• reasoning - capace di chain-of-thought

Digitando /model <nome> nella casella di input si passa istantaneamente a un modello corrispondente, con una palette filtrata come ripiego quando il nome non è una corrispondenza esatta. Il testo del comando viene rimosso dal messaggio prima dell'invio, così lo slash command non inquina mai la cronologia della chat.

Due dettagli rendono questo ergonomico anziché semplicemente possibile. Primo, il cambio è a metà conversazione: la stessa chat può muoversi da un modello locale a uno di frontiera e ritorno, con ogni messaggio che persiste quale modello l'ha effettivamente servito - la traccia di audit dell'uso dei modelli sopravvive al cambio. Secondo, la palette è una superficie keyboard-first: il pattern Cmd+K fa sì che la scelta del modello costi un tasto, non un viaggio in una pagina di impostazioni, che è la differenza tra una funzionalità che le persone usano e una che configurano una volta e dimenticano.

Confronto affiancato

Scegliere un modello da una descrizione è un tiro nel buio; sceglierlo guardando due risposte al vostro prompt reale è ingegneria. Premendo Cmd+Shift+M (Ctrl+Shift+M) si apre il confronto affiancato dei modelli: due pannelli fluiscono simultaneamente con risposte di modelli diversi per lo stesso prompt, token per token.

Il flusso che consente è quello che gli harness di valutazione formalizzano, mantenuto nella superficie quotidiana:

• Chiedete una volta, osservate entrambi i modelli ragionare - latenza, formulazione e differenze di grounding sono immediatamente visibili
• Conservate una risposta e continuate la conversazione con quel modello
• Inviate a un pannello singolo per riunire gli output in un solo thread
• Chiudete il confronto e continuate con l'uno o l'altro modello

Poiché il confronto usa la stessa infrastruttura di streaming e citazioni della chat normale, le risposte confrontate arrivano con le loro citazioni RAG intatte - potete valutare non solo come un modello formula una risposta ma se la fonda sulle giuste fonti. Questa distinzione conta in una piattaforma di retrieval: un modello che scrive splendidamente ma cita il documento sbagliato è peggiore di uno che scrive semplicemente e cita correttamente.

La catena di fallback

I modelli diventano non disponibili: un'outage del provider, un nome di modello dismesso, una quota esaurita a metà conversazione. La risposta di Simmetric Chat è una catena di fallback deterministica - se il modello selezionato diventa non disponibile, il sistema ricade automaticamente sul default del workspace, poi sul default globale, poi su qualsiasi modello disponibile. Un toast vi avvisa del cambio, con un'opzione Annulla.

La catena si attiva sia sul polling periodico (ogni trenta secondi) sia sugli errori SSE durante lo streaming, così un guasto del provider a metà risposta viene reindirizzato senza perdere la conversazione. L'obiettivo di progettazione è specifico: un'outage di modello dovrebbe degradare la piattaforma al suo modello successivo, non degradarla a una pagina di errore. Gli utenti vedono una notifica anziché uno stack trace, e l'operatore vede una piattaforma che ha continuato a servire.

Per i deployment multi-istanza la stessa filosofia di progettazione si estende verso l'esterno - il fan-out in streaming e la coda di job che tengono la chat reattiva sotto carico sono stato esternalizzato, trattato separatamente nell'articolo sullo scaling.

Cosa vi compra lo strato di orchestrazione

Riunendo i fili, lo strato di orchestrazione è ciò che trasforma la scelta del provider da una decisione di approvvigionamento a un insieme di leve di runtime:

• Controllo dei costi. Instradate il lavoro di massa a un provider compatibile OpenAI economico e riservate il modello di frontiera ai prompt che lo richiedono, per chat anziché per deployment.
• Zone di privacy. Mantenete i workspace sensibili ancorati a modelli local-only lasciando che i workspace generali usino provider cloud - i badge di capacità rendono la zona visibile al momento della selezione.
• Resilienza. Le outage dei provider diventano cambi di modello, non tempi di fermo, con la catena di fallback e il reindirizzamento dello streaming.
• Valutazione come abitudine. Il confronto affiancato rende "su quale modello standardizzarci?" un controllo di due minuti a settimana anziché un progetto di ricerca trimestrale.

Tutto poggia sullo stesso confine di provider a pattern strategico che il resto della piattaforma usa, così aggiungere un provider - di prima classe o preset compatibile OpenAI - non tocca mai chat, RAG o il ciclo dell'agente.

Leggi la guida completa nella documentazione →