Orchestration multi-LLM : changement de modèle, comparaison et fallback

Le déploiement à un seul modèle est une décision que vous dépassez

Les équipes ne restent pas fidèles à un seul LLM, et ne devraient pas. Le modèle local rapide qui répond parfaitement aux questions de support échoue sur l'analyse juridique nuancée. Le modèle de frontière qui gère le raisonnement coûte trop cher pour répondre à « qu'y a-t-il dans ce document ? ». Un provider change ses prix, retire un modèle ou tombe en panne - et soudain tout le produit est à terre ou en renégociation. Une plateforme IA sérieuse traite donc « quel modèle » comme une décision de runtime, pas d'installation.

Simmetric Chat la traite ainsi de bout en bout : chaque frontière de provider est une stratégie, le modèle est sélectionnable par chat, l'évaluation est intégrée à l'interface et la panne dégrade gracieusement plutôt que d'erreur. Cet article parcourt la couche d'orchestration - les providers, l'expérience de changement, le mode comparaison et la chaîne de fallback.

Cinq providers de première classe, vingt presets

Prêts à l'emploi, la plateforme parle à cinq providers de première classe : Ollama (local, le défaut privacy-first), OpenAI, Anthropic, OpenRouter et Gemini. Chacun a son propre parser de streaming - les formats réseau diffèrent assez pour que traiter le streaming comme un problème générique produise des bugs subtils - donc le streaming des tokens, les citations et les événements terminaux sont analysés par provider plutôt qu'approximés.

Au-delà des cinq de première classe, vingt presets de provider couvrent l'écosystème compatible OpenAI : DeepSeek, Mistral, Kimi/Moonshot, NVIDIA NIM, Qwen, xAI, Z.AI/GLM, MiniMax, LM Studio, GitHub Copilot et d'autres. Comme ces services implémentent le protocole réseau OpenAI, en ajouter un est une ligne de configuration - URL de base, clé, liste de modèles - pas une modification de code. Un déploiement peut donc mélanger un Ollama local pour le travail sensible, un modèle de frontière cloud pour l'analyse approfondie et un provider compatible OpenAI bon marché pour la summarisation en masse, le tout dans un seul workspace.

La configuration suit les règles de précédence de la plateforme : les variables d'environnement établissent les défauts au niveau de l'infrastructure, les modifications depuis le panneau d'administration prennent effet immédiatement, et les paramètres se résolvent base de données sur environnement sur défauts. Le provider global par défaut est exactement cela - un défaut, écrasable par workspace et par chat.

Changer de modèle sans quitter la conversation

La sélection du modèle vit là où vit la conversation. L'input du chat porte un badge de modèle qui montre ce qui répondra au prochain message ; en cliquant dessus - ou en pressant Cmd+K (Ctrl+K sous Windows/Linux) - la palette de changement rapide s'ouvre. La palette regroupe les modèles par provider et les annote avec des badges de capacité dérivés des métadonnées du modèle :

• local-only - tourne on-premise, aucune donnée sortante
• fastest - la latence la plus basse dans l'ensemble actuel de providers
• smartest - la qualité la plus haute disponible
• reasoning - capable de chain-of-thought

Taper /model <nom> dans la zone de saisie bascule instantanément vers un modèle correspondant, avec une palette filtrée comme repli quand le nom n'est pas une correspondance exacte. Le texte de la commande est retiré du message avant l'envoi, pour que la slash command ne pollue jamais l'historique du chat.

Deux détails rendent cela ergonomique plutôt que simplement possible. Premier : le changement est en pleine conversation - le même chat peut passer d'un modèle local à un modèle de frontière et revenir, chaque message persistant quel modèle l'a réellement servi, la trace d'audit de l'usage des modèles survivant au changement. Second : la palette est une surface keyboard-first - le pattern Cmd+K fait que choisir un modèle coûte une touche, pas un voyage dans une page de paramètres, ce qui est la différence entre une fonctionnalité que les gens utilisent et une qu'ils configurent une fois et oublient.

Comparaison côte à côte

Choisir un modèle à partir d'une description est un coup dans le noir ; le choisir en regardant deux réponses à votre prompt réel est de l'ingénierie. Presser Cmd+Shift+M (Ctrl+Shift+M) ouvre la comparaison côte à côte des modèles : deux panneaux affluent simultanément avec les réponses de modèles différents pour le même prompt, token par token.

Le flux qu'elle permet est celui que les harnais d'évaluation formalisent, maintenu dans la surface quotidienne :

• Demandez une fois, observez les deux modèles raisonner - latence, formulation et différences de grounding sont immédiatement visibles
• Conservez une réponse et continuez la conversation avec ce modèle
• Envoyez vers un panneau unique pour réunir les sorties dans un seul thread
• Fermez la comparaison et continuez avec l'un ou l'autre modèle

Parce que la comparaison utilise la même infrastructure de streaming et de citations que le chat normal, les réponses comparées arrivent avec leurs citations RAG intactes - vous pouvez évaluer non seulement comment un modèle formule une réponse mais s'il la fonde sur les bonnes sources. Cette distinction compte dans une plateforme de retrieval : un modèle qui écrit magnifiquement mais cite le mauvais document est pire qu'un modèle qui écrit simplement et cite correctement.

La chaîne de fallback

Les modèles deviennent indisponibles : une panne de provider, un nom de modèle retiré, un quota épuisé en pleine conversation. La réponse de Simmetric Chat est une chaîne de fallback déterministe - si le modèle sélectionné devient indisponible, le système retombe automatiquement sur le défaut du workspace, puis sur le défaut global, puis sur n'importe quel modèle disponible. Un toast vous avertit du changement, avec une option Annuler.

La chaîne se déclenche à la fois sur le polling périodique (toutes les trente secondes) et sur les erreurs SSE pendant le streaming, pour qu'une panne de provider en pleine réponse soit redirigée sans perdre la conversation. L'objectif de conception est spécifique : une panne de modèle devrait dégrader la plateforme vers son modèle suivant, pas la dégrader vers une page d'erreur. Les utilisateurs voient une notification au lieu d'une stack trace, et l'opérateur voit une plateforme qui a continué à servir.

Pour les déploiements multi-instance, la même philosophie de conception s'étend vers l'extérieur - le fan-out du streaming et la file de jobs qui gardent le chat réactif sous charge sont de l'état externalisé, traité séparément dans l'article sur la mise à l'échelle.

Ce que la couche d'orchestration vous achète

En réunissant les fils, la couche d'orchestration est ce qui transforme le choix du provider d'une décision d'approvisionnement en un ensemble de leviers de runtime :

• Contrôle des coûts. Routez le travail de masse vers un provider compatible OpenAI bon marché et réservez le modèle de frontière aux prompts qui l'exigent, par chat plutôt que par déploiement.
• Zones de confidentialité. Gardez les workspaces sensibles ancrés à des modèles local-only en laissant les workspaces généraux utiliser des providers cloud - les badges de capacité rendent la zone visible au moment de la sélection.
• Résilience. Les pannes de provider deviennent des changements de modèle, pas des temps d'arrêt, avec la chaîne de fallback et la redirection du streaming.
• L'évaluation comme habitude. La comparaison côte à côte fait de « sur quel modèle standardiser ? » un contrôle de deux minutes par semaine au lieu d'un projet de recherche trimestriel.

Tout repose sur la même frontière de provider en pattern stratégie que le reste de la plateforme utilise, donc ajouter un provider - de première classe ou preset compatible OpenAI - ne touche jamais le chat, le RAG ou la boucle de l'agent.

Lire le guide complet dans la doc →