Portkey AI Gateway : un routeur LLM en TypeScript, avec garde-fous intégrés

Le problème : N fournisseurs, N SDK, N façons de réessayer

Une application qui parle à OpenAI, Anthropic et Bedrock finit avec trois clients, trois formats d'erreur et trois politiques de retry. Le gateway supprime cette duplication en exposant une seule surface HTTP compatible OpenAI. Le README insiste sur le point d'entrée : le client Python du projet accepte provider="openai", "anthropic", "bedrock" ou "groq", et la requête se fait ensuite via client.chat.completions.create avec un paramètre model. Le code appelant ne connaît plus le SDK du fournisseur. Le public visé est donc l'équipe qui a déjà deux ou trois fournisseurs en production et qui veut centraliser les règles de fiabilité plutôt que de les réécrire dans chaque service. Le README mentionne aussi le MCP Gateway pour l'authentification et l'observabilité des serveurs MCP, ce qui déplace le même raisonnement vers les outils d'agents. À noter : la description du dépôt parle de 1 600+ modèles et de 50+ guardrails, alors que le titre du README annonce 250+ LLMs. Les deux chiffres ne concordent pas, et rien dans le matériel fourni n'explique cet écart.

Ce qui se passe entre votre requête et le fournisseur

Le gateway est un proxy écrit en TypeScript. Il reçoit un appel au format OpenAI, lit la config attachée à la requête, puis applique les étapes dans l'ordre : retry, fallback, load balancing, routage conditionnel, et enfin les guardrails d'entrée ou de sortie avant de transmettre au fournisseur cible. Le README présente le paquet comme léger (122kb annoncés) et rapide (moins d'1ms de latence annoncée). Ces deux nombres viennent de la documentation du projet, pas d'une mesure indépendante, et la latence d'un proxy dépend surtout du réseau vers le fournisseur en aval. Les configs sont l'unité centrale : c'est un objet JSON qu'on attache au client, et qui décrit à la fois la politique de retry et les filtres. C'est ce qui distingue le projet d'un simple reverse proxy : la logique de routage vit dans la requête, pas dans un fichier de configuration serveur qu'il faudrait redéployer à chaque changement.

Démarrer en local avec npx

L'installation tient en une commande, à condition d'avoir Node.js et npm : npx @portkey-ai/gateway. Le README indique que le gateway écoute alors sur http://localhost:8787/v1 et que la console locale est servie sur http://localhost:8787/public/. C'est dans cette console que l'on consulte les logs des appels. Côté client, l'exemple Python s'installe avec pip install -qU portkey-ai, puis on construit un client Portkey en passant provider et Authorization, la clé du fournisseur. Le README cite aussi des guides de déploiement pour Docker, Node.js, Cloudflare Workers et Replit, ainsi qu'un bouton CloudFormation pour EC2. Un point pratique : la clé du fournisseur circule dans le client, donc si vous passez par une instance partagée, la question de qui détient cette clé se pose avant la mise en production, pas après.

Les guardrails, et le piège du retry silencieux

L'exemple du README est instructif. On définit output_guardrails avec un bloc default.contains, operator: none et words: ["Apple"], puis deny: True. Le modèle est censé répondre au hasard "Apple" ou "Bat", et le commentaire du README précise que la réponse sera toujours "Bat" puisque le guardrail rejette toute réponse contenant "Apple". Le même objet config contient retry: {attempts: 5}. Le commentaire ajoute que le retry relance cinq fois avant d'abandonner. Autrement dit, une réponse bloquée par un guardrail de sortie n'est pas renvoyée comme une erreur au client : elle est retentée. Pour un filtre de conformité, cela veut dire que le fournisseur est facturé à chaque tentative, et qu'un modèle qui produit systématiquement le mot interdit boucle cinq fois avant un échec. C'est un choix de conception discutable, et le README ne documente pas de mécanisme séparant le retry réseau du retry après rejet de guardrail. À vérifier dans votre propre config avant de compter sur ce comportement.

Le cas où le gateway n'est pas le bon outil

Si vous n'utilisez qu'un seul fournisseur, sans fallback ni filtre de sortie, le gateway ajoute un saut réseau et un composant à maintenir sans rien résoudre. Le README vante l'intégration en moins de deux minutes, et c'est crédible pour un prototype. En production, il faut compter le déploiement de l'instance, la gestion des clés fournisseurs, la surveillance de la console et les mises à jour du paquet. Autre limite : le dépôt est en TypeScript, donc si votre équipe est exclusivement Python, vous héritez d'une stack que personne ne modifiera en cas de bug dans une règle de routage. Enfin, le README signale que la version 2.0 du gateway d'entreprise fusionne avec l'open source, sur une branche 2.0.0 en pré-release. Adopter aujourd'hui la branche stable, c'est accepter qu'une partie du périmètre bouge à la prochaine version majeure.

Face à LiteLLM : proxy central ou bibliothèque embarquée

LiteLLM est l'alternative la plus directe, et la différence tient à la forme. LiteLLM se présente d'abord comme une bibliothèque Python qui traduit les appels entre fournisseurs, avec un mode proxy optionnel. Portkey se présente d'abord comme un service : on lance une instance, on l'appelle en HTTP, et la logique de routage vit dans la config envoyée avec la requête. La conséquence pratique est visible dans le code. Avec une bibliothèque, la politique de retry est dans votre processus, donc vous la versionnez avec votre application et vous la testez avec vos tests unitaires. Avec un gateway séparé, la politique est un objet JSON qui voyage dans la requête, ce qui permet de la changer sans redéployer l'application, mais aussi de la faire diverger entre appelants. Les deux approches sont défendables. Le choix dépend de qui doit modifier les règles : l'équipe qui déploie l'application, ou la plateforme qui opère le gateway.

Licence MIT et coût de maintenance

Le dépôt est publié sous licence MIT, ce qui autorise la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver la notice de licence. Le matériel fourni ne mentionne pas de clause supplémentaire ni de séparation entre édition open source et édition entreprise au niveau de la licence, mais le README annonce une fusion de la version entreprise dans l'open source avec la 2.0. Il est prudent de relire le fichier LICENSE du dépôt au moment de l'adoption plutôt que de se fier au badge affiché en tête de README. Sur la maintenance : les trois dernières versions listées sont v1.15.0, v1.15.1 et v1.15.2, publiées entre le 23 et le 24 décembre 2025 puis le 12 janvier 2026. Le rythme de publication est donc resserré, ce qui implique de suivre les notes de version si vous épinglez une version précise. La question à trancher avant de déployer reste la même : est-ce votre équipe ou celle du projet qui corrigera une règle de routage défaillante un vendredi soir.

Conclusion éditoriale

Adoptez le gateway si vous voulez un point d'entrée unique vers plusieurs fournisseurs sans écrire vous-même la couche de retry et de fallback, et si le format de config JSON vous convient. Ne l'adoptez pas si votre besoin principal est un budget par utilisateur final ou un suivi de coûts par projet : ce n'est pas ce que le README met en avant. Avant de déployer, vérifiez deux choses concrètes : la branche 2.0.0 annoncée en pré-release, qui peut changer le périmètre de la version stable, et le comportement réel de output_guardrails avec operator: none, car un filtre qui rejette une réponse déclenche ici un retry plutôt qu'un message d'erreur explicite.

Sources officielles

1. License: MIT
2. Portkey-AI/gateway on GitHub
3. Project website
4. README
5. Releases