Switchyard vs LiteLLM : quel proxy LLM choisir en 2026 ?

Symptôme : votre passerelle doit tout faire ; solution la plus rapide : choisir selon le risque principal

Le dépôt officiel de Switchyard indique une exigence Python 3.12 ou ultérieure. Ce détail suffit déjà à distinguer un outil de routage récent, que vous devez intégrer avec précaution, d’une passerelle d’entreprise dont la priorité est la gouvernance multi-fournisseurs. (dépôt officiel de Switchyard)

Si vous avez besoin de fournisseurs multiples, de clés virtuelles, de budgets par projet et d’un contrôle centralisé, choisissez LiteLLM. Si votre objectif principal est de connecter Claude Code ou Codex à des modèles locaux ou ouverts, ou d’évaluer un routage typé, testez Switchyard en parallèle, sans remplacer immédiatement votre passerelle de production.

Dernière mise à jour : 13 août 2026. Vérification effectuée à partir du dépôt officiel de Switchyard, de sa documentation d’architecture et de la documentation officielle de LiteLLM. Toute évolution majeure de version ou de configuration doit déclencher une nouvelle comparaison.

Cet article s’adresse :

aux ingénieurs plateforme qui maintiennent une passerelle LLM interne ;
aux équipes qui veulent faire passer Claude Code ou Codex par un autre modèle ;
aux décideurs techniques qui évaluent le routage, la maîtrise budgétaire et le niveau d’exploitation acceptable.

1. Commencez par séparer deux produits qui ne répondent pas exactement au même problème

La comparaison Switchyard vs LiteLLM devient trompeuse si vous les traitez comme deux remplaçants parfaitement symétriques.

Switchyard est présenté comme un proxy Python capable de traduire les formats OpenAI Chat, Anthropic Messages et OpenAI Responses. Il peut transmettre les requêtes vers vLLM, NVIDIA NIM, Ollama ou d’autres points d’accès compatibles OpenAI, tout en conservant le format attendu par le client. Son dépôt décrit également plusieurs familles de routage : transmission vers un modèle unique, routage aléatoire, classification par modèle LLM, routeur par étapes et routeurs personnalisés. (fonctionnalités et architecture de Switchyard)

LiteLLM se positionne plus largement comme une passerelle et une interface unifiée vers plus de 100 modèles ou fournisseurs, avec traduction vers plusieurs points de terminaison, gestion des reprises et des replis, suivi des coûts, authentification, clés virtuelles, budgets et limitation de débit. La documentation distingue aussi le serveur proxy central du module Python utilisé directement dans une application. (documentation officielle de LiteLLM)

La différence pratique est donc la suivante :

Switchyard traite d’abord le problème « comment conserver le protocole de mon agent tout en changeant le modèle ou la logique de sélection ? » ;
LiteLLM traite d’abord le problème « comment exposer plusieurs fournisseurs derrière une couche d’accès, de budget et d’exploitation commune ? ».

Cette distinction compte particulièrement dans les usages audio, vidéo et design. Une équipe peut vouloir envoyer une demande de génération de script vidéo vers un modèle distant, une extraction de storyboard vers un modèle moins coûteux et une tâche de correction de code vers un modèle local. Le routage n’est alors qu’une partie du système : il faut aussi savoir quelle équipe a appelé quel modèle, avec quelle clé, pour quel projet et à quel coût.

2. Vérifiez d’abord les formats d’API et le coût réel de migration

Switchyard conserve mieux le contexte du client dans certains scénarios d’agents

La documentation de Switchyard affirme que les clients peuvent continuer à parler les formats OpenAI ou Anthropic pendant que le proxy sélectionne un backend et effectue la traduction nécessaire. Le dépôt cite explicitement les formats OpenAI Chat, Anthropic Messages et OpenAI Responses.

Pour un agent de programmation, cela peut réduire les modifications du lanceur ou de la couche d’environnement :

conserver l’interface attendue par l’agent ;
changer l’URL de base vers le proxy ;
déclarer le modèle ou le profil de routage ;
vérifier les outils, le flux de sortie, les erreurs et les appels MCP ;
mesurer les écarts de comportement avec le modèle d’origine.

Cette compatibilité ne signifie pas que toutes les fonctions avancées sont interchangeables. Les noms d’outils, le raisonnement, les sorties structurées, les caches de contexte et les limites propres au fournisseur peuvent encore créer des erreurs. Le dépôt de Switchyard documente par exemple une limite de nom d’outil de 64 caractères dans un scénario Claude Code avec un backend Bedrock ; vous devez donc tester les requêtes avec outils, et pas seulement une conversation texte. (limites et problèmes connus de Switchyard)

LiteLLM réduit le travail de normalisation pour une plateforme multi-fournisseurs

LiteLLM documente la traduction vers plusieurs interfaces, dont les appels de conversation, les réponses, les embeddings, les images, l’audio et les traitements groupés. Il expose également une interface de réponse cohérente et mappe les erreurs des fournisseurs vers des exceptions compatibles avec l’écosystème OpenAI. (interfaces prises en charge par LiteLLM)

Pour une équipe backend, l’avantage se situe moins dans la première requête que dans la durée :

les applications utilisent une couche d’accès commune ;
les changements de fournisseur restent concentrés dans la configuration ;
les mécanismes de reprise peuvent être appliqués au niveau du routeur ;
la télémétrie peut être branchée sur des outils externes ;
les clés fournisseurs restent côté passerelle plutôt que dans chaque application.

Le coût caché est la configuration. Plus vous ajoutez de fournisseurs, de variantes de modèles, de règles de reprise et de politiques de journalisation, plus vous devez traiter la configuration comme du code : revue, validation, déploiement progressif et retour arrière.

Attention : une réponse HTTP réussie ne prouve pas que la migration est compatible. Pour un agent, validez aussi les outils, les sorties structurées, le streaming, les erreurs de limite et les longues conversations.

3. Évaluez le routage selon le type de décision que vous devez prendre

Pour une politique déterministe, documentez les conditions avant de choisir l’outil

Dans une architecture d’entreprise, « routage intelligent » peut désigner deux choses très différentes.

Le premier cas est déterministe : le projet A utilise un modèle approuvé, le projet B utilise un modèle local, les requêtes dépassant une certaine classe de contexte sont envoyées vers une autre cible, et une panne déclenche une cible de secours explicitement définie.

Le second cas est expérimental : un classificateur choisit un modèle en fonction du contenu, un routeur par étapes change de cible selon l’avancement d’un agent, ou un système compare plusieurs modèles pour mesurer leur comportement.

Switchyard documente des profils de routage, un classificateur LLM, un routeur par signaux et des profils YAML qui possèdent la logique d’appel, de traduction et de statistiques. Cette approche est intéressante pour un agent de programmation qui alterne exploration, correction d’erreurs et modifications mécaniques. (guide officiel du routage Switchyard)

LiteLLM documente pour sa part le routage avec reprises, replis et équilibrage entre plusieurs déploiements. La documentation de présentation couvre également le suivi des coûts et l’équilibrage au niveau applicatif. (routage, reprises et replis dans LiteLLM)

Dans les deux cas, vous devez distinguer :

la sélection initiale d’un modèle ;
la répartition de charge ;
le refroidissement d’une cible en erreur ou limitée ;
le repli vers un autre fournisseur ;
la conservation ou non de la session ;
la traçabilité de la décision prise.

Les documents officiels consultés ne permettent pas d’attribuer automatiquement à Switchyard l’ensemble des fonctions d’équilibrage, de reprise, de budget et de gestion de parc que LiteLLM expose comme passerelle. Si vous avez besoin de ces fonctions avec Switchyard, prévoyez des composants complémentaires ou une validation spécifique ; ne les déduisez pas du simple fait qu’un routeur est présent.

4. Traitez l’identité et le budget comme des fonctions de production

C’est ici que LiteLLM prend généralement l’avantage pour un usage d’entreprise.

La documentation officielle décrit des fonctions d’authentification et d’autorisation, des clés virtuelles, le suivi des dépenses par projet ou utilisateur, des budgets et de la limitation de débit. La configuration de démarrage montre également l’utilisation d’une base de données pour le serveur proxy. (clés virtuelles et gestion des dépenses dans LiteLLM)

Cela permet de construire une séparation raisonnable :

une clé virtuelle par application ou équipe ;
une limite de dépense associée au projet ;
une limite de débit adaptée au fournisseur ;
des identifiants fournisseurs conservés uniquement dans la passerelle ;
des statistiques utilisables lors de la refacturation interne ;
une procédure de rotation et de révocation.

Vous devez toutefois vérifier le niveau exact de permissions dont vous avez besoin. Une fonction de clé virtuelle ne constitue pas automatiquement un système complet de rôles, de séparation des responsabilités ou d’intégration avec votre fournisseur d’identité. Si les documents ne déclarent pas explicitement une capacité, considérez qu’elle doit être apportée par un composant externe ou confirmée lors d’un essai.

Pour Switchyard, les documents consultés mettent en avant les statistiques de requête, notamment la latence, les jetons et le coût, mais ne déclarent pas l’équivalent complet d’un catalogue de clés virtuelles, de budgets par équipe et de portail d’administration multi-locataire.

Pour une équipe de recherche, cette absence peut être acceptable. Pour une plateforme qui doit expliquer pourquoi le budget d’un projet audio ou vidéo a été dépassé, elle devient une charge d’architecture.

5. Contrôlez l’observabilité avant de laisser passer des données sensibles

Une passerelle LLM voit généralement les prompts, les réponses, les noms de modèles, les métadonnées utilisateurs et parfois les contenus envoyés aux outils. Le choix ne doit donc pas se limiter à « possède-t-elle des journaux ? », mais à « que journalise-t-elle, pendant combien de temps et avec quel mécanisme de masquage ? ».

LiteLLM documente des rappels d’observabilité vers plusieurs systèmes externes, ainsi que le suivi des coûts, de la latence et de l’utilisation. Cela facilite l’intégration dans une chaîne existante, mais ne supprime pas votre responsabilité :

désactiver les corps de requête lorsque leur conservation n’est pas nécessaire ;
masquer les secrets, données personnelles et extraits de dépôt ;
séparer les journaux d’audit des traces de débogage ;
vérifier le traitement des flux de sortie ;
tester les erreurs avant et après le repli ;
documenter qui peut consulter les prompts.

La documentation de Switchyard indique une collecte de statistiques par requête, notamment la latence, les jetons et le coût. Les documents consultés ne déclarent pas un système d’audit multi-locataire ou une politique complète de rétention et de masquage. Vous devrez donc définir votre propre couche de collecte si les exigences de conformité dépassent les métriques opérationnelles de base. (statistiques de requête dans Switchyard)

Expérience à appliquer dès le prototype : injectez volontairement un secret factice, un nom de client et un contenu confidentiel dans trois requêtes de test, puis vérifiez chaque journal, trace, export et tableau de bord. Une politique de confidentialité non testée n’est qu’une hypothèse.

6. Comparez la charge d’exploitation, pas seulement la simplicité du dépôt

Switchyard peut être lancé comme proxy local, service partagé ou environnement intégré. Son dépôt décrit une installation Python, des extras pour le serveur et la ligne de commande, ainsi que des options de déploiement comprenant FastAPI et Uvicorn. Le démarrage peut donc être rapide pour un poste de développement ou une validation d’agent.

LiteLLM peut être lancé comme serveur proxy avec une configuration déclarative, une clé maître et une URL de base de données ; la documentation fournit aussi une voie de déploiement par conteneur. (déploiement officiel du proxy LiteLLM)

Dans les deux architectures, les coûts d’exploitation réels incluent :

le stockage de configuration et sa publication ;
la gestion des secrets ;
la base de données si les données de gouvernance y sont persistées ;
Redis ou un mécanisme équivalent lorsque votre architecture en a besoin ;
la haute disponibilité et la reprise après redémarrage ;
les migrations de version ;
les tests de compatibilité entre client, proxy et fournisseur ;
la surveillance des erreurs de traduction.

Le fait qu’un projet récent possède un code plus simple ne prouve pas que son exploitation sera moins chère. Vous devez mesurer le nombre de composants externes, la qualité des procédures de déploiement, la précision de la documentation et la facilité de retour arrière.

7. Utilisez cette liste de décision avant toute migration

Cochez chaque condition qui correspond à votre situation :

[ ] Vous gérez plusieurs fournisseurs et plusieurs équipes : retenez LiteLLM comme passerelle principale.
[ ] Vous avez besoin de clés virtuelles, de budgets par projet ou de limites de débit : commencez par LiteLLM.
[ ] Vous voulez surtout connecter Claude Code ou Codex à Ollama, vLLM, NVIDIA NIM ou un endpoint compatible OpenAI : évaluez Switchyard en priorité.
[ ] Vous devez expérimenter un routage par étapes ou une classification propre aux agents : testez Switchyard sur un trafic non critique.
[ ] Vous avez des exigences d’audit, de rétention et de masquage : ne validez aucun outil sans démonstration des journaux et des contrôles.
[ ] LiteLLM est déjà stable en production et aucun défaut précis n’est identifié : ne migrez pas le chemin principal ; ajoutez Switchyard sur une route de test.
[ ] Le projet est nouveau : rejouez des requêtes réelles anonymisées dans les deux systèmes avant de choisir.

La règle de repli est simple : si vous cochez au moins l’une des deux premières cases, LiteLLM doit rester le candidat principal ; si vous cochez surtout les troisième et quatrième cases, Switchyard mérite une validation ciblée. Dans tous les cas, une capacité non déclarée dans la documentation officielle doit être considérée comme « à confirmer », jamais comme acquise.

8. Suivez une migration en cinq étapes, sans toucher immédiatement au trafic critique

Inventoriez les clients. Séparez les applications OpenAI, les agents utilisant Anthropic Messages, les clients Responses, les flux audio ou vidéo et les appels avec outils. Notez les en-têtes, le streaming et les exigences de contexte.
Construisez une matrice de compatibilité. Pour chaque client, testez une requête simple, une requête en flux, un appel d’outil, une sortie structurée, une erreur d’authentification et une limite de fournisseur.
Définissez deux profils de routage. Le premier doit être déterministe et facile à auditer ; le second peut exploiter une classification ou un routeur par étapes. Ne mélangez pas expérimentation et politique de production dans un même profil.
Rejouez du trafic anonymisé. Utilisez des requêtes représentatives de vos agents, de votre support, de vos tâches de design et de vos traitements audio ou vidéo. Comparez les erreurs, les jetons, la latence, les replis et les résultats, sans présenter une moyenne issue d’un petit échantillon comme une preuve générale.
Organisez une période de double exploitation. Conservez LiteLLM comme chemin de secours si vous l’utilisez déjà, placez Switchyard sur une route dédiée, puis documentez les conditions précises qui justifieraient une promotion. Si aucune condition n’est remplie, ne migrez pas par effet de nouveauté.

Pour préparer l’environnement de test, vous pouvez aussi consulter le centre d’aide de Macstripe et les informations de configuration d’une commande Mac, notamment si la validation nécessite un poste macOS isolé pour un agent ou un outil de développement.

9. Conclusion d’adoption : gardez LiteLLM au centre, évaluez Switchyard à côté

Le choix le plus prudent pour une entreprise qui démarre avec une passerelle LLM est LiteLLM lorsque la priorité porte sur la diversité des fournisseurs, les clés virtuelles, les budgets et l’administration quotidienne. Switchyard mérite une évaluation ciblée lorsque le problème est plus spécifique : faire fonctionner un agent de programmation avec un modèle local ou ouvert, conserver son protocole natif ou expérimenter un routage typé.

Si vous avez déjà une installation LiteLLM stable, la remplacer immédiatement vous ferait perdre une couche de gouvernance, des habitudes d’exploitation et des données de référence avant même d’avoir prouvé un gain. Le meilleur compromis consiste à installer Switchyard sur un chemin séparé, à lui envoyer un trafic non productif et à comparer des requêtes identiques.

Une passerelle cloud ou un poste partagé peut sembler plus rapide, mais vous y perdez souvent la maîtrise de l’environnement, la reproductibilité des versions, la visibilité sur les journaux et la possibilité d’isoler une expérimentation d’agent. Pour une validation courte, la location d’un environnement Macstripe peut offrir un poste indépendant sans immobiliser une machine de développement ; pour une charge stable et continue nécessitant des interfaces physiques ou une capacité dédiée permanente, l’achat ou l’infrastructure interne reste généralement plus cohérent.

L’objectif n’est donc pas de déclarer un vainqueur universel. Il est de conserver LiteLLM lorsque la gouvernance est le risque principal, et de réserver Switchyard aux scénarios où son orientation agents et modèles ouverts apporte une amélioration mesurable.

Questions fréquemment posées

Quelle différence opérationnelle entre Switchyard et LiteLLM ?

Switchyard se concentre sur la traduction de formats, le raccordement d’agents de programmation et des scénarios de routage typés, notamment vers des modèles locaux ou compatibles OpenAI. LiteLLM vise davantage le rôle de passerelle LLM d’entreprise, avec clés virtuelles, suivi des dépenses, budgets par projet, contrôle d’accès, limitation de débit et intégrations d’observabilité.

Quel proxy LLM convient le mieux à une entreprise ?

Pour une organisation qui doit centraliser plusieurs fournisseurs, répartir les dépenses entre équipes et administrer des clés d’accès, LiteLLM constitue le choix par défaut le plus défendable. Switchyard devient intéressant lorsqu’un besoin précis concerne des agents de programmation, des modèles ouverts ou un routage expérimental que vous pouvez isoler derrière une validation hors production.

Switchyard peut-il remplacer LiteLLM dans une architecture existante ?

Il peut remplacer une partie du chemin technique dans certains scénarios, mais les documents officiels consultés ne déclarent pas l’équivalent complet des fonctions de gouvernance d’entreprise de LiteLLM. Une migration directe du proxy central est donc difficile à justifier sans vérifier les clés, budgets, rôles, journaux, reprise après panne et procédures d’exploitation.

LiteLLM est-il plus adapté à la gestion des budgets de plusieurs équipes ?

Oui, lorsque la priorité est le suivi des dépenses et l’application de limites par projet, utilisateur ou équipe. La documentation officielle de LiteLLM décrit les clés virtuelles, le suivi des coûts, les budgets et la limitation de débit. Vous devez néanmoins tester la précision des coûts et le comportement lors des appels en flux avant de rendre les limites bloquantes.

Quel proxy choisir pour connecter un agent de programmation à un modèle local ?

Commencez par Switchyard si vous souhaitez conserver le format natif de l’agent tout en le dirigeant vers vLLM, Ollama, NVIDIA NIM ou une autre interface compatible OpenAI. LiteLLM reste préférable si ce raccordement local doit ensuite rejoindre une gouvernance multi-équipes, plusieurs fournisseurs et une chaîne d’audit centralisée.