De LiteLLM à Wäg en un après-midi, pas un trimestre
LiteLLM amène rapidement les équipes au multi-fournisseurs — c'est pourquoi il tourne dans tant de piles de production. Ce qu'il n'apporte pas, c'est une couche de gouvernance : des budgets hiérarchiques qui arrêtent la dépense avant l'appel au fournisseur, une politique appliquée dans le chemin de la requête, des appels d'outils retenus pour un approbateur nommé, et une trace d'audit remettable à une équipe conformité. Wäg prend la place du proxy LiteLLM et ajoute cette couche. Vous gardez votre SDK, vos alias de modèles et votre code applicatif. Vous changez une URL de base.
Ce qui change
- L'URL de base vers laquelle pointent vos clients
- L'emplacement de la configuration
- Le processus proxy que vous exploitez
Ce qui ne change pas
- Votre SDK — openai, langchain, llamaindex, le SDK LiteLLM comme client, tout ce qui est compatible OpenAI
- Les alias de modèles référencés par votre code
- Les formats de requête et de réponse
- Le comportement du streaming, l'appel d'outils, la vision
- Vos comptes fournisseurs et vos clés d'API
Quatre étapes, aucune n'est une réécriture
1 · Importez votre configuration
Lit votre config.yaml LiteLLM — en ligne de commande, ou collé sous Platform → System → Import dans la console — et produit une configuration Wäg : modèles et alias, références aux identifiants fournisseurs, stratégie de routage, replis, Redis, projets transformés en applications avec budgets, clés virtuelles, serveurs MCP et agents A2A.
$ waeg import litellm --from config.yaml -o waeg.yaml$ waeg config validate --config waeg.yamlCe qu'il faut vérifier, c'est le rapport d'import. Chaque clé aboutit dans l'une de quatre listes — mapped, skipped, needs_human et notes — et la ligne de commande affiche les décomptes avec des exemples :
mapped
model_list (12 rows) → 6 aliases: gpt-4o, claude, fast, cheap, embed, vision
model_list[3].litellm_params.rpm: 600 → relative deployment weight
litellm_settings.fallbacks → alias fallbacks
litellm_settings.num_retries: 3 → routing.max_retries: 3
router_settings.routing_strategy → routing.strategy: weighted (see notes)
projects[0] (max_budget, budget_duration) → application app_ll_search + application budget
skipped
litellm_settings.success_callback → re-create under Observability
needs_human
general_settings.master_key: os.environ/LITELLM_MASTER_KEY → set WAEG_MASTER_KEY
litellm_settings.cache_params → re-create under Caching
notes
routing_strategy "latency-based-routing-v2" is not known → weightedSortie illustrative. L'intérêt de la montrer est que le rapport est un artefact réel : rien n'échoue en silence, tout ce qui n'a pas d'équivalent Wäg est listé pour revue plutôt qu'approximé, et les secrets ne sont jamais réaffichés.
2 · Changez une URL de base
Wäg expose la surface compatible OpenAI — /v1/chat/completions, /v1/responses (sans état), /v1/embeddings, /v1/images/*, /v1/audio/*, /v1/videos, /v1/rerank, /v1/ocr, /v1/moderations, /v1/files, /v1/batches, /v1/realtime, /v1/models — plus /v1/messages d'Anthropic, /v1beta de Gemini, et /v1/mcp et /v1/a2a pour les agents. Les clients LiteLLM comme Cline et Roo continuent de fonctionner : GET /model/info répond avec ou sans /v1, x-litellm-api-key est accepté sur les routes pass-through et MCP, et x-litellm-session-id regroupe les appels en conversations. Le streaming est du vrai SSE.
client = OpenAI(
- base_url="http://litellm:4000/v1",
+ base_url="https://waeg.internal/v1",
api_key=os.environ["GATEWAY_KEY"],
)À vérifier : GET /v1/models renvoie vos alias, puis une requête en streaming et une requête avec appel d'outils par alias.
3 · Vérifiez en parallèle
Faites tourner les deux. Envoyez une part du trafic vers Wäg, ou dupliquez-y le trafic de production, et comparez. Comme les réplicas sont sans état et partagent leurs compteurs via Redis et leur configuration via Postgres, vous pouvez faire varier la taille du canari sans perdre l'état des budgets.
- Décisions de routage — x-waeg-routed-model sur chaque réponse, x-waeg-route-reason avec le routage intelligent
- Comportement du cache — x-waeg-cache, et si les taux de succès correspondent à vos attentes
- Comptage des tokens et imputation des coûts face à la facture de votre fournisseur
- Latence p50 / p95 / p99, taux d'erreur et taux de repli
- Signaux de compatibilité — les champs de requête et de réponse dont dépendent vos clients que la passerelle a transmis ou supprimés, comptés sur votre propre trafic
4 · Basculez
Changez l'URL de base pour un service, puis pour les autres. Laissez tourner le déploiement LiteLLM jusqu'à ce que vous soyez satisfait — revenir en arrière consiste à refaire la même modification d'une ligne.
Un ordre raisonnable : d'abord les outils internes, puis les charges batch et hors ligne, puis un service de production, puis tout le reste.
Remettez l'URL de base. C'est toute la procédure — Wäg ne détient aucun état dont dépendent vos applications, et vos comptes fournisseurs, clés et alias de modèles restent intacts. Gardez les deux déploiements pendant la transition. Il n'y a volontairement aucune étape de verrouillage dans cette migration.
Champ de configuration par champ de configuration
| LiteLLM | Wäg | Remarques |
|---|---|---|
model_list[].model_name | alias de modèle | Repris à l'identique — votre code continue de fonctionner |
litellm_params.model | deployment: provider + model_id | Plusieurs lignes avec le même model_name deviennent des déploiements pondérés d'un même alias |
api_key: os.environ/X | api_key_env: X | Lue depuis l'environnement à l'exécution ; passez plus tard à une référence de coffre si vous préférez |
litellm_params.api_base | base_url du fournisseur | Un autre hôte ou une autre région devient un autre fournisseur |
router_settings.routing_strategy | routing.strategy | simple-shuffle et usage-based → weighted, least-busy et latency-based → latency, cost-based → cost ; tout le reste → weighted, avec une note. Wäg ajoute intelligent |
litellm_settings.fallbacks | replis de l'alias | Du plus fort au plus faible avec la stratégie intelligent |
litellm_settings.num_retries | routing.max_retries | Plus un disjoncteur par déploiement |
general_settings.master_key | master_key | Une référence os.environ est listée pour revue : définissez WAEG_MASTER_KEY. Plus des clés virtuelles avec budgets et listes de modèles autorisés |
projects[]: max_budget / budget_duration | application + budget | Wäg est hiérarchique : org → équipe → utilisateur → application → modèle → clé |
rpm sur un déploiement | poids du déploiement | Un poids relatif, pas une limite de débit. Les rpm_limit et tpm_limit d'un projet vont dans la politique de budget de son application ; le TPM par déploiement n'a pas d'équivalent |
cache_params | à recréer après l'import | Sous Caching : niveaux exact, canonique, quasi-doublon et sémantique avec protections contre les faux positifs |
guardrails | à recréer après l'import | Les mêmes fournisseurs existent comme éléments du catalogue, dans une chaîne ordonnée : avant l'appel, en cours de flux et après l'appel |
success_callback / failure_callback | à recréer après l'import | Sous Observability : callbacks OTLP, Langfuse et HTTP, plus les métriques Prometheus |
custom Python callbacks | — aucun équivalent | Wäg n'est pas un processus Python. Utilisez plutôt un moteur de politique en webhook HTTP |
keys[] avec un project_id | clés virtuelles | Rattachées à l'application du projet, si bien que le budget d'un agent de code suit sa clé |
mcp_servers | serveurs MCP de plateforme | L'authentification Bearer et par clé d'API devient des identifiants statiques ; OAuth utilisateur et échange de jetons demandent Enterprise. Les outils importés sont épinglés |
agents[] | agents A2A de plateforme | Actualisez la carte de chaque agent après l'import ; la passerelle la récupère et la vérifie |
import litellm (in-process) | un client de la passerelle | Le SDK continue de fonctionner pointé vers Wäg ; son routage en processus et ses callbacks, non |
Y compris ce que LiteLLM fait et que Wäg ne fait pas
Confrontez ces points à votre installation avant de commencer. Si l'un des deux premiers est structurant chez vous, la migration est un vrai projet et non un après-midi — et mieux vaut le savoir maintenant qu'à mi-parcours.
Pas de routage en processus
LiteLLM peut s'importer comme bibliothèque Python. Pointé vers Wäg, le SDK continue de fonctionner comme client, mais son routage en processus et ses callbacks ne sont pas repris — le routage se fait dans la passerelle à la place.
Pas de callbacks Python personnalisés
LiteLLM permet d'insérer du Python arbitraire dans le cycle de vie de la requête. Le point d'extension de Wäg est un moteur de politique en webhook HTTP — plus simple à exploiter et à sécuriser, moins immédiatement souple. Une logique de callbacks importante devient un petit service.
Moins de fournisseurs exotiques, plus de fidélité
La couverture fournisseurs de LiteLLM est plus large. Wäg compte une douzaine de types de fournisseurs natifs, plus tout serveur compatible OpenAI, avec des adaptateurs natifs Anthropic et Gemini qui préservent la fidélité des outils, de la vision et des sorties structurées au lieu de tout uniformiser. Vérifiez votre liste d'abord.
Une autre philosophie de routage
Wäg évalue les requêtes structurellement — outils, vision, longueur de contexte, indices de raisonnement — en déduit des seuils de capacité stricts, puis choisit le modèle le moins cher qui les franchit. Déterministe et explicable via les en-têtes. Aucun routeur ML dans le chemin critique.
Une autre philosophie de cache
Quatre niveaux — exact, canonique, quasi-doublon, sémantique — avec garde-fous contre les faux positifs. « Capitale de la France » et « capitale de l'Espagne » sont un échec de cache. Chiffres, négations et changements d'entités invalident un succès.
La gouvernance est hiérarchique, pas plate
C'est la vraie raison de migrer. Les budgets de LiteLLM sont par clé. Ceux de Wäg s'empilent sur org → équipe → utilisateur → application → modèle → clé avec des plafonds d'équité, si bien que le modèle correspond à la structure réelle des organisations.
Ce que vous avez gagné
Des budgets qui arrêtent la dépense d'abord
Limites empilées sur org → équipe → utilisateur → application → modèle → clé. Chaque requête est contrôlée face à chaque compteur applicable ; le premier dépassement rejette l'appel avant toute dépense fournisseur. Avec WAEG_CLUSTER=1, ils échouent aussi en position fermée si Redis est injoignable.
La politique dans le chemin de la requête
Une chaîne d'analyseurs ordonnée avant l'appel, en cours de flux sur une fenêtre glissante et après l'appel. Données personnelles, injection de prompt, modération ou votre propre webhook. Bloquer, masquer ou caviarder, règle par règle.
Des boucles d'agents gouvernées
Les serveurs MCP distants reçoivent des identifiants par serveur — clé statique, jeton utilisateur relayé ou identifiants client OAuth, et avec Enterprise la connexion OAuth propre de l'utilisateur ou l'échange de jetons — plus des listes d'outils autorisés et l'épinglage. Les appels d'outils peuvent attendre un approbateur nommé, dans Slack ou Teams avec Enterprise, et chaque étape est budgétée et journalisée.
Une trace d'audit
Chaque requête, décision de routage, verdict de politique et coût en journaux de requêtes, traces OTLP et métriques Prometheus — et, une fois activé, un registre de preuves signé et chaîné par hachage que chacun peut vérifier hors ligne avec waeg ledger verify. Enterprise ajoute des paquets de preuves rattachés au règlement sur l'IA et à DORA, lacunes signalées, et le marquage des contenus IA.
Un seul binaire
Rust, distroless, sans root. Aucun shell, interpréteur ni gestionnaire de paquets dans l'image de la passerelle, des versions signées avec SBOM, et aucune exécution Node dans la passerelle — l'assistant de console optionnel tourne comme service distinct.
Un opérateur pour l'exploiter
Un opérateur Kubernetes maison déclare la passerelle — topologie, stockage, OpenFGA, mise à l'échelle HPA ou KEDA — et réconcilie fournisseurs, modèles, budgets, clés et garde-fous comme ressources. Les erreurs de configuration apparaissent comme des conditions assorties d'une raison, pas comme un pod qui échoue une heure plus tard.
Voir où s'arrête la gateway et où commence la control plane · Voir les benchmarks
Questions fréquentes
Dois-je modifier mon code applicatif ?
Non. Vous changez l'URL de base que votre client compatible OpenAI utilise déjà.
Ma configuration LiteLLM est-elle reprise ?
En grande partie, via waeg import litellm ou Platform → System → Import dans la console. Vous obtenez un rapport de ce qui a été repris, de ce qui a été ignoré et de ce qui demande une intervention humaine, et rien n'échoue en silence.
Puis-je faire tourner les deux en même temps ?
Oui, et c'est la démarche recommandée. Dupliquez ou répartissez le trafic et comparez décisions de routage, coûts et latence avant de basculer.
Wäg est-il un fork de LiteLLM ?
Non. C'est une implémentation indépendante en Rust, bâtie autour d'un modèle de requête d'inférence plutôt que d'une répartition via les SDK fournisseurs. La compatibilité est délibérée ; la filiation est distincte.
Le streaming est-il pris en charge ?
Oui — de vrais Server-Sent Events, pas un flux mis en tampon puis découpé.
Appel d'outils et vision ?
Oui, sur les formats de requête OpenAI, Anthropic et Gemini. Les adaptateurs natifs préservent les comportements propres à chaque fournisseur au lieu de les réduire au plus petit dénominateur commun.
Qu'en est-il des API natives d'Anthropic et de Gemini ?
Elles sont prises en charge comme formats de requête de premier ordre, pas seulement comme traduction du format OpenAI.
Redis est-il nécessaire ?
Au-delà d'un réplica, oui — il garde budgets et limites de débit cohérents entre réplicas, aux côtés de Postgres et d'OpenFGA dont la production a besoin de toute façon. Le mode embarqué ne demande rien d'externe, mais il est mononœud et garde son état en mémoire.
Cela fonctionne-t-il sur Kubernetes ?
Oui, de deux façons. Un opérateur maison déclare la passerelle et son catalogue comme ressources — réplicas sans état, mise à l'échelle HPA ou KEDA, compteurs de budget partagés, sondes de santé et de disponibilité — et un chart Helm existe si vous préférez l'exploiter vous-même.
Est-ce vraiment de l'Apache-2.0 ?
Oui. Le chemin de production de la passerelle est sous Apache-2.0 : routage, haute disponibilité, cache, bascule, budgets, garde-fous, MCP, tâches, observabilité et registre de preuves. Enterprise ajoute l'identité (SSO, SCIM, jetons d'IdP), les paquets d'audit et de preuves, les paiements par agent, les approbations Slack et Teams, les garde-fous pass-through et le support.
Est-ce que cela appelle vers l'extérieur ?
Non. Aucune télémétrie ni analyse, et la licence est un jeton signé hors ligne, sans serveur de licences. Il fonctionne entièrement isolé du réseau : observez ses connexions sortantes et vous ne verrez que les fournisseurs que vous avez configurés.
Et si nous avons besoin d'aide pour migrer ?
Les partenaires de conception bénéficient d'un accompagnement de migration, y compris depuis LiteLLM — nous la faisons avec vous plutôt que de vous remettre un guide.
Un point d'entrée. Tous les modèles. Un contrôle total.
Exploitez-le dans votre propre infrastructure
Tout ce qu'il faut pour exploiter une control plane en production est sous Apache-2.0 et le restera — routage, haute disponibilité, cache, bascule, budgets, politique, MCP, tâches et observabilité. Auto-hébergé, sans compte, sans appel vers l'extérieur.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Ce n'est pas un pull qui fonctionne : les images ne sont pas encore publiques. Les partenaires de conception reçoivent les informations du registre en privé.
Déployer en 5 minutesFaçonnez-le en tant que partenaire de conception
Wäg n'est pas encore disponible publiquement. Nous travaillons avec un petit groupe d'équipes qui exploitent de l'IA multi-fournisseurs en production et prennent au sérieux la gouvernance et la souveraineté, afin de durcir la control plane sur des charges réelles.
- Toutes les capacités Enterprise incluses, sans coût de licence
- Migration accompagnée — nous la faisons avec vous, y compris depuis LiteLLM
- Un lien direct avec les ingénieurs et une influence réelle sur la suite