LiteLLM, Kong, Cloudflare, Portkey et Odock : une comparaison honnête des IA gateways

La version courte

Si vous cherchez aujourd'hui la LLM gateway open-source la plus mature, LiteLLM est difficile à ignorer. Elle offre une large prise en charge des providers, un accès compatible OpenAI, des virtual keys, le suivi des dépenses, des budgets, des rate limits, des fallbacks, des intégrations d'observability, des travaux autour d'une gateway MCP et un écosystème sérieux de guardrails.

Si votre entreprise utilise déjà Kong, Kong AI Gateway est une trajectoire logique. Elle étend une API gateway éprouvée avec du proxying AI, des plugins sensibles aux prompts, des gardes sémantiques, du rate limiting, du logging et des modèles de déploiement enterprise. Son principal avantage n'est pas seulement l'AI. C'est la puissance déjà établie de Kong en API management.

Si vous voulez rapidement de la visibilité, du caching, du routing, du DLP et des contrôles au niveau edge dans le réseau de Cloudflare, Cloudflare AI Gateway est attractive. Si vous voulez une plateforme productisée d'opérations AI avec dashboards, gestion des prompts, guardrails et ergonomie hébergée, Portkey est solide. Si votre plateforme est profondément Kubernetes-native et que vous voulez des primitives de routing ouvertes basées sur Envoy, Envoy AI Gateway mérite d'être suivie.

Odock doit être évalué autrement. L'objectif n'est pas de prétendre qu'un projet plus récent est plus mature que ces plateformes. L'objectif est de construire une AI-native gateway où la sécurité modulaire et les workflows augmentés par plugins ne sont pas des fonctionnalités secondaires. Ils constituent le modèle opérationnel central.

Là où LiteLLM est fort

Le centre de gravité de LiteLLM est l'accès aux models pour les équipes plateforme. Elle est conçue pour donner aux développeurs une interface compatible OpenAI sur de nombreux model providers, tout en donnant aux responsables plateforme des contrôles sur les coûts, l'accès aux models, les clés, les budgets, les rate limits, les fallbacks, l'observability et les guardrails.

Cela fait de LiteLLM un bon choix lorsque le problème principal est la dispersion des providers. Les équipes peuvent standardiser l'accès à OpenAI, Anthropic, Azure, Bedrock, Vertex, aux models self-hosted et à beaucoup d'autres. Elle est aussi solide lorsque les équipes finance et plateforme ont besoin d'attribuer l'usage par clé, utilisateur, équipe ou organisation.

L'approche guardrails de LiteLLM est plus mature que beaucoup ne l'imaginent. Elle prend en charge des guardrails intégrés et tiers, des classes de guardrails personnalisées et des lifecycle hooks avant l'appel, pendant l'appel, après l'appel et sur les réponses en streaming. C'est une vraie extensibilité.

Le compromis est que l'architecture de LiteLLM ressemble encore principalement à une gateway d'accès aux models avec des guardrails et callbacks autour. Ce n'est pas une faiblesse pour beaucoup d'équipes. C'est exactement ce dont elles ont besoin. Mais si votre objectif de conception central est un moteur de sécurité modulaire et un graphe de workflow plugins qui traite les requêtes AI, les appels d'outils MCP, les décisions de politique et les transformations comme un pipeline programmable unique, Odock vise une autre forme.

Là où Kong est fort

Kong part d'un autre monde : l'API management. Kong AI Gateway n'est pas seulement un proxy LLM. C'est Kong Gateway plus des plugins spécifiques à l'AI. C'est important, car Kong a déjà une histoire mature pour le routing, l'auth, le rate limiting, les plugins, les modes de déploiement, Konnect, Kubernetes, l'observability, la gouvernance et les opérations enterprise.

Pour les organisations déjà standardisées sur Kong, c'est convaincant. Le trafic AI devient une autre classe de trafic API avec des plugins sensibles aux prompts par-dessus. AI Proxy de Kong gère la traduction des providers. AI Proxy Advanced ajoute le load balancing, les retries et le fallback. Les plugins Prompt Guard peuvent analyser les messages utilisateur avec des regex ou de la similarité sémantique. Les plugins Response Guard et Semantic Cache étendent encore ce modèle.

La force de Kong est aussi son compromis. C'est d'abord une API gateway. Les capacités AI sont puissantes, mais elles vivent dans un framework large d'API management. Si vous avez besoin de gestion enterprise du cycle de vie des API, c'est excellent. Si vous voulez seulement un control plane AI ciblé pour les LLMs, les serveurs MCP, les modules de sécurité et les workflow plugins, Kong peut sembler plus large que le problème.

L'idée de plugins d'Odock est plus étroite et plus spécifique à l'AI : enrichir ou contraindre le workflow AI lui-même, et pas seulement attacher des politiques à une route API. Cela signifie des plugins pour la transformation de prompts, le masquage de données, la politique de retrieval, l'approbation des tool calls, la validation de schema, la réparation de sortie, les indices de routing, le comportement des budgets, les métadonnées d'audit et les règles de workflow propres à chaque tenant.

Où Cloudflare AI Gateway s’inscrit

Cloudflare AI Gateway est particulièrement forte lorsque les équipes veulent une voie rapide vers une observability et un contrôle AI centralisés à l'edge. Elle met l'accent sur les analytics, les logs, le caching, le rate limiting, le routing dynamique, les model fallbacks, le BYOK, les guardrails, le DLP et le suivi des coûts sur les providers pris en charge.

Le principal avantage est la commodité opérationnelle. Si votre application est déjà derrière Cloudflare, ajouter de la visibilité et des contrôles AI avec peu de changements applicatifs est attractif. Le caching et le rate limiting s'intègrent aussi naturellement aux forces d'infrastructure de Cloudflare.

Le compromis est la gravité de l'écosystème. Cloudflare AI Gateway est meilleure lorsque vous êtes à l'aise avec l'idée de placer cette couche de contrôle dans la plateforme Cloudflare. Pour beaucoup d'équipes, c'est une bonne décision. Pour celles qui veulent une gateway open-source autonome avec des modules de workflow personnalisés, un contrôle MCP plus profond et une logique de plugins capable de s'exécuter là où tourne la plateforme AI, Odock vise davantage de portabilité et d'extension personnalisée.

Où Portkey s’inscrit

Portkey est plus proche d'une plateforme productisée d'opérations AI. Elle combine une gateway avec observability, logs, gestion des prompts, guardrails, caching, retries, fallbacks, load balancing, limites budgétaires et intégrations avec des frameworks d'agents. Elle propose un ensemble de fonctionnalités large et un modèle opérationnel soigné pour les équipes qui veulent des dashboards et des workflows autour de l'usage des LLM.

Portkey est particulièrement intéressante pour les équipes qui veulent la gestion du cycle de vie des prompts et l'observability AI à côté des contrôles de gateway. Ses guardrails peuvent être déterministes, basés sur des models, fournis par des partenaires ou personnalisés, et les résultats des guardrails peuvent influencer le comportement de routing.

Le compromis est que Portkey est davantage une plateforme complète. C'est utile si vous voulez cette plateforme. C'est moins idéal si vous voulez posséder une couche de gateway plus petite, garder la logique de workflow proche de votre infrastructure et construire des modules de sécurité/plugins personnalisés comme primitives code-first.

Odock ne doit pas essayer de surpasser Portkey sur les dashboards dès le premier jour. L'objectif plus net est de rendre le cycle de vie de la requête lui-même plus programmable et gouvernable pour les équipes qui construisent leur propre plateforme AI.

Où Envoy AI Gateway s’inscrit

Envoy AI Gateway est importante parce qu'elle vient du côté infrastructure cloud-native. Elle s'appuie sur les patterns Envoy Gateway et les ressources Kubernetes pour router et gérer le trafic LLM. Ses forces sont la connectivité provider, les endpoints compatibles OpenAI et Anthropic, la virtualisation des models, le fallback, le rate limiting tenant compte des tokens, l'observability et la configuration Kubernetes-native.

C'est une direction solide pour les équipes plateforme qui utilisent déjà Kubernetes et veulent gérer le trafic AI à travers des primitives d'infrastructure familières. C'est aussi prometteur pour des déploiements ouverts, performants et de niveau infrastructure.

Le compromis est la surface produit. Envoy AI Gateway est un projet d'infrastructure de plus bas niveau comparé aux plateformes d'opérations AI hébergées ou aux gateways orientées application. Si vous voulez un moteur de sécurité modulaire riche, des workflow plugins, des politiques AI tenant-aware et une gouvernance MCP comme concepts visibles de premier plan, vous devrez probablement assembler davantage de pièces vous-même.

Où WSO2, Tyk et Apigee s’inscrivent

WSO2, Tyk et Apigee viennent de l'API management enterprise. Leur travail d'AI gateway consiste à intégrer l'accès LLM, la gouvernance, le contrôle du trafic, l'observability, le suivi des coûts, l'abstraction des models, les politiques de sécurité et l'accès développeur dans des systèmes établis d'API management.

C'est utile pour les grandes organisations qui ont déjà besoin de portails, de workflows de cycle de vie, de gouvernance enterprise, de SSO, de gestion des politiques et de rapports de conformité. Ils conviennent souvent mieux aux équipes plateforme centralisées qu'aux petites équipes qui veulent une AI-native gateway légère.

Le compromis est la complexité et le focus. Les plateformes d'API management enterprise résolvent beaucoup de problèmes au-delà de l'AI. Odock est volontairement plus étroit : un dock unique pour les LLM providers, les serveurs MCP, les modules de sécurité, les budgets, les quotas et les workflow plugins.

La vraie différence : l’approche

La plupart des AI gateways partagent désormais la même checklist :

• Accès provider unifié
• Chemins de requête compatibles OpenAI
• Gestion des provider keys et des identifiants
• Logs, métriques et suivi d'usage
• Budgets, quotas et rate limits
• Caching, retries, routing et fallbacks
• Guardrails sur prompts ou réponses
• Une forme d'extension personnalisée

Cette checklist n'explique pas la différence architecturale. La meilleure question est : quel objet la gateway considère-t-elle comme central ?

• LiteLLM traite principalement la requête model comme l'objet à normaliser, mesurer, router et gouverner.
• Kong traite principalement le trafic AI comme du trafic API enrichi par des plugins conscients de l'AI.
• Cloudflare traite principalement les appels AI comme du trafic à observer, mettre en cache, router et sécuriser à l'edge.
• Portkey traite principalement l'usage AI comme un workflow d'opérations avec gateway, logs, prompts, guardrails et dashboards.
• Envoy AI Gateway traite principalement le trafic AI comme du routing d'infrastructure cloud-native avec des primitives Kubernetes et Envoy.
• Odock traite le workflow AI comme l'objet : appels model, outils MCP, politique tenant, contrôles de sécurité, plugins, budgets et observability dans un control plane programmable unique.

C'est le positionnement. Odock n'est pas seulement un proxy. Il est pensé comme une workflow gateway.

Le moteur de sécurité modulaire d’Odock

La sécurité dans les systèmes AI n'est pas un filtre unique. Une vraie requête AI comporte plusieurs moments où des décisions de sécurité peuvent être nécessaires :

• Avant que le prompt atteigne un provider
• Après que le retrieval ajoute du contexte privé
• Avant qu'un outil MCP soit exposé à un agent
• Avant l'exécution d'un tool call
• Pendant le routing vers un provider avec des politiques de données différentes
• Après que le model renvoie une sortie
• Avant que les logs, traces et enregistrements de dépenses stockent des métadonnées

Le moteur de sécurité d'Odock doit être modulaire sur tous ces moments. Un module peut être déterministe, basé sur un model, externe, propre à un tenant ou propre à un workflow. Un module peut expurger des PII. Un autre peut détecter une prompt injection. Un autre peut faire respecter une frontière de données client. Un autre peut approuver ou bloquer un tool call MCP. Un autre peut retirer des données sensibles avant l'écriture de la télémétrie.

C'est la différence importante avec une simple case "guardrails". Le moteur de sécurité n'est pas seulement de la modération de prompts. C'est une chaîne de modules de politique capables d'inspecter, transformer, refuser, router, annoter ou escalader à différents stades du workflow AI.

Les plugins de workflow d’Odock

Les plugins sont l'autre moitié de l'approche. Dans beaucoup de systèmes AI, les équipes applicatives réécrivent sans cesse le même code de liaison : formatage des prompts, vérifications de schema, validation des arguments d'outils, réparation de sorties, règles de fallback, métadonnées propres aux clients et hooks d'audit.

La couche de plugins d'Odock vise à déplacer cette logique dans la gateway lorsqu'elle est partagée, opérationnelle ou sensible aux politiques.

• Un plugin de validation peut rejeter des requêtes mal formées avant qu'elles consomment des tokens.
• Un plugin de transformation peut normaliser les formes de réponses propres aux providers.
• Un plugin de sécurité peut masquer les secrets avant qu'un provider les voie.
• Un plugin de routing peut ajouter des indices de model selon le tenant, la charge de travail ou l'état du budget.
• Un plugin d'outil peut exiger une approbation avant l'exécution d'une action MCP.
• Un plugin d'observability peut attacher des métadonnées d'audit sans exposer le contenu brut.
• Un plugin de réponse peut imposer un JSON schema ou des exigences de citation avant de retourner vers l'application.

C'est ici qu'Odock doit se différencier : les plugins ne doivent pas être seulement du middleware HTTP générique. Ils doivent comprendre le cycle de vie AI et permettre aux équipes d'augmenter le workflow autour du model.

Quand choisir chaque passerelle

Choisissez LiteLLM si vous voulez aujourd'hui un accès mature et open-source aux models, une large couverture provider, des virtual keys, des budgets, des fallbacks et un pattern d'AI gateway éprouvé.

Choisissez Kong si votre organisation utilise déjà Kong ou a besoin d'API management enterprise avec des plugins AI intégrés au même modèle opérationnel.

Choisissez Cloudflare AI Gateway si vous voulez rapidement des analytics, du caching, du DLP, du routing et des contrôles au niveau edge dans la plateforme Cloudflare.

Choisissez Portkey si vous voulez une plateforme productisée d'AI ops avec gateway, gestion des prompts, observability, guardrails et dashboards.

Choisissez Envoy AI Gateway si votre équipe veut une infrastructure de routing AI ouverte, Kubernetes-native et basée sur Envoy.

Choisissez WSO2, Tyk ou Apigee si votre organisation a déjà besoin de gestion enterprise du cycle de vie des API et veut une gouvernance AI dans cette plateforme plus large.

Choisissez Odock si votre priorité est une AI-native gateway où la sécurité modulaire, la gouvernance MCP et les workflow plugins sont centraux dans le design, et où la gateway ne fait pas que router les requêtes mais façonne tout le workflow AI.

La faiblesse honnête d’Odock

Odock doit être clair sur sa position actuelle. Il est plus récent. Il n'a pas encore le même historique de production, le même écosystème de providers, le même packaging enterprise ni la même taille de communauté que LiteLLM, Kong, Cloudflare, Portkey, Envoy, WSO2, Tyk ou Apigee.

C'est important. Une équipe avec des exigences de production urgentes doit évaluer la maturité, le modèle de déploiement, le support, la posture de sécurité et les preuves opérationnelles avant de choisir une gateway.

La raison de miser sur Odock n'est pas que le marché manque de gateways. La raison est que les workflows AI deviennent plus que des appels model. Ils incluent des outils, du contexte, des politiques, des approbations, des transformations, des budgets et des règles propres aux tenants. L'opportunité d'Odock est de rendre ces contrôles de workflow modulaires dès le départ.

Conclusion

Le marché des AI gateways se divise en plusieurs catégories. LiteLLM est la model gateway open-source pragmatique. Kong est l'API management gateway étendue à l'AI. Cloudflare est la couche de contrôle edge. Portkey est la plateforme d'opérations AI. Envoy est la fondation de routing cloud-native. Les plateformes d'API enterprise apportent une gouvernance à l'échelle de l'organisation.

La thèse d'Odock est plus étroite et plus nette : les équipes AI ont besoin d'une gateway où les modules de sécurité et les workflow plugins sont de premier plan, parce que les problèmes difficiles en production ne sont plus seulement "quel provider appeler ?". Les problèmes difficiles sont "que doit-il se passer avant, pendant et après ce workflow AI, pour ce tenant, avec ces données, ce model et ces outils ?"

C'est la différence d'approche.