Kong contre Portkey : quelle passerelle IA fonctionne pour l'infrastructure LLM d'entreprise ?

Présentation

Alors que les grands modèles de langage passent de l'expérimentation à la production, les équipes repensent la manière dont le trafic d'IA doit être géré, sécurisé et observé. Ce qui semblait autrefois être une simple intégration d'API implique désormais des invites, des jetons, le routage des modèles, les nouvelles tentatives, le suivi des coûts et des problèmes de fiabilité que l'infrastructure applicative traditionnelle n'a jamais été conçue pour gérer.

De nombreuses équipes d'ingénierie commencent cette aventure en étendant des passerelles API familières telles que Kong, en tirant parti des modèles de routage, d'authentification et de limitation de débit existants. À mesure que l'utilisation du LLM augmente, les passerelles natives de l'IA telles que Clé de port entrez l'image, en proposant des abstractions adaptées aux invites, aux modèles et à l'observabilité au niveau des jetons.

Les deux approches visent à résoudre des problèmes réels, mais elles partent de points de départ fondamentalement différents. Kong est ancré dans la gestion des API HTTP et des microservices, tandis que Portkey est conçu spécifiquement pour les flux de travail des applications LLM. Les différences entre ces philosophies deviennent de plus en plus importantes à mesure que les systèmes d'IA évoluent en fonction des équipes, des environnements et des cas d'utilisation de production.

Dans cet article, nous comparons Kong et Portkey en termes d'architecture, d'observabilité, de gouvernance et de préparation à l'entreprise. Nous verrons où chaque outil convient le mieux, où les limites commencent à apparaître et ce que les équipes de plateforme devraient prendre en compte à mesure que l'IA devient un élément essentiel de leur infrastructure.

Qu'est-ce que Kong ?

Kong est une passerelle API largement adoptée conçue pour gérer, sécuriser et acheminer le trafic HTTP via des microservices. Il est couramment utilisé comme couche d'entrée dans les architectures basées sur Kubernetes et est bien connu pour gérer des problèmes tels que l'authentification, la limitation du débit, le routage du trafic et l'observabilité au niveau des requêtes.

D'un point de vue architectural, Kong est optimisé pour Systèmes axés sur les API. Ses abstractions principales tournent autour des points de terminaison, des services, des itinéraires et des plugins, ce qui en fait une solution idéale pour les environnements de backend et de microservices traditionnels où les requêtes sont sans état, prévisibles et uniformes.

Où Kong fonctionne bien

• Gestion du trafic d'API mature : Support robuste pour l'authentification, la limitation, les nouvelles tentatives et l'équilibrage de charge
• Déploiements natifs de Kubernetes : Fonctionne bien en tant que couche d'entrée ou de passerelle dans les piles natives du cloud
• Écosystème de plugins extensible : Les équipes peuvent personnaliser le comportement à l'aide de plugins et d'intergiciels
• Familiarité opérationnelle : Les équipes de la plateforme gèrent déjà souvent Kong pour les charges de travail non liées à l'IA

Utilisation de Kong pour les charges de travail LLM

Lorsque les équipes introduisent des LLM, Kong est souvent le premier outil réutilisé pour gérer le trafic d'IA, en traitant les appels LLM comme un simple point de terminaison d'API. Cela fonctionne initialement pour :

• Centralisation de l'accès aux API des modèles
• Application des limites tarifaires de base
• Application des clés d'authentification et d'API

Cependant, le trafic LLM introduit des propriétés qui ne correspondent pas clairement aux API traditionnelles.

Limitations des cas d'utilisation de l'IA et du LLM

• Aucune compréhension native des instructions ou des jetons : Les requêtes sont des blobs JSON opaques
• Absence d'observabilité au niveau des jetons : Les codes de latence et d'état sont visibles, mais pas l'utilisation et le coût des jetons
• Aucun routage ou solution de secours tenant compte des modèles : Les règles de trafic sont basées sur les API et ne tiennent pas compte des modèles ou des charges de travail
• Primitives de gouvernance de l'IA limitées : Aucun concept intégré pour un contrôle rapide, des politiques de modèle ou une attribution de l'utilisation entre les équipes

À mesure que l'utilisation de l'IA va au-delà de la simple expérimentation, ces lacunes deviennent de plus en plus visibles, en particulier dans les environnements impliquant plusieurs équipes ou sensibles aux coûts.

Qu'est-ce que Portkey ?

Clé de port est une passerelle native d'IA conçue spécifiquement pour les applications basées sur de grands modèles de langage. Au lieu de traiter les appels LLM comme des requêtes d'API génériques, Portkey introduit des abstractions qui correspondent au fonctionnement réel des applications d'IA : invites, modèles, jetons et fournisseurs.

Portkey agit essentiellement comme une couche intermédiaire entre les applications d'IA et plusieurs fournisseurs de LLM. Il permet aux développeurs de passer d'un modèle à l'autre, d'acheminer le trafic et d'observer l'utilisation sans associer étroitement le code de l'application à l'API d'un fournisseur spécifique.

Où Portkey fonctionne bien

• Abstraction du modèle : Les applications peuvent acheminer les demandes vers plusieurs fournisseurs LLM via une interface unique
• Routage sensible aux commandes rapides : Le trafic peut être acheminé en fonction du modèle, de la logique de repli ou de la disponibilité du fournisseur
• Observabilité au niveau des jetons : Visibilité des entrées et sorties des jetons, de la latence et de l'utilisation des modèles
• Expérience axée sur le développeur : SDK et tableaux de bord simples optimisés pour les applications LLM

Comment Portkey améliore les passerelles API traditionnelles

Comparé aux passerelles API comme Kong, Portkey est Conçu pour être compatible avec le LLM. Il comprend que :

• Le coût est déterminé par les jetons, et non par les demandes
• La fiabilité implique de nouvelles tentatives, des replis et un changement de modèle
• L'observabilité doit inclure des détails d'exécution rapides

Cela fait de Portkey un excellent choix pour les équipes qui créent et itèrent sur des applications basées sur LLM, en particulier dans les environnements de production en phase initiale ou intermédiaire.

Là où Portkey commence à échouer

Au fur et à mesure que l'utilisation de LLM se développe dans les équipes et les environnements, certaines limites apparaissent :

• Concentration au niveau de l'application : Principalement optimisé pour les applications individuelles, et non pour les plateformes d'IA à l'échelle de l'entreprise
• Gouvernance limitée de l'infrastructure : Ne gère pas le déploiement, l'isolation de l'environnement ou les politiques infra-niveaux
• Contraintes de l'entreprise : Les déploiements sur site et isolés et les exigences strictes en matière de résidence des données ne sont pas des objectifs de conception fondamentaux
• Attribution partielle des coûts : L'utilisation des jetons est visible, mais il peut être difficile de lier les coûts aux équipes, aux environnements ou aux unités commerciales

Ces contraintes deviennent importantes lorsque l'IA passe du statut de fonctionnalité d'application à celui de capacité d'entreprise partagée.

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Comparaison architecturale : Kong contre Portkey

Alors que Kong et Clé de port peuvent tous deux faire face à des charges de travail liées à l'IA, ils reposent sur des hypothèses architecturales très différentes. Comprendre cette différence est essentiel pour les équipes chargées de la plateforme qui décident comment étendre l'IA au-delà d'une seule application.

Quand utiliser Kong contre Portkey

Quand Kong prend tout son sens

Kong est un bon choix si :

• L'utilisation de l'IA est minimal ou expérimental
• Vous utilisez déjà Kong en tant que passerelle API principale
• Les appels LLM sont traités comme n'importe quelle autre API tierce
• Vous n'avez pas besoin d'observabilité au niveau des jetons ni de gouvernance spécifique à l'IA

Dans cette configuration, Kong fonctionne comme extension temporaire de l'infrastructure d'API existante.

Quand Portkey prend tout son sens

Portkey convient parfaitement lorsque :

• Vous êtes en train de construire Applications centrées sur le LLM
• L'abstraction du modèle et le changement de fournisseur sont importants
• Vous voulez une visibilité au niveau des jetons sans travail infrarouge intense
• AI est la propriété d'un une seule équipe ou un seul produit

Portkey brille au couche d'application, en particulier pour les équipes de produits d'IA qui évoluent rapidement.

Où Kong et Portkey sont loin d'être à la hauteur de l'IA d'entreprise

Les deux Kong et Clé de port répondent aux véritables défis de la pile d'IA, mais ils le font à des niveaux différents et, en fin de compte, limités. Ces limites deviennent apparentes à mesure que l'IA évolue d'une fonctionnalité d'application unique à une capacité d'entreprise partagée couvrant de multiples équipes, environnements et limites réglementaires.

La gouvernance de l'IA va au-delà de la gestion du trafic

Kong est conçu pour régir les demandes d'API, et non le comportement de l'IA. Les invites, les jetons, la sélection du modèle et l'exécution des agents sont opaques pour la passerelle.
Portkey introduit des contrôles compatibles avec le LLM, mais la gouvernance reste largement maintenue limité à l'application.

Les équipes d'IA d'entreprise ont toutefois besoin de réponses à des questions telles que :

• Quelles équipes peuvent accéder à quels modèles et dans quels environnements ?
• Quelles instructions, quels agents ou quels outils sont approuvés pour une utilisation en production ?
• Comment les politiques sont-elles appliquées de manière cohérente dans des dizaines de services et d'équipes ?

Ni Kong ni Portkey ne fournissent gouvernance de l'IA à l'échelle de l'organisation en tant que capacité de première classe.

Le contrôle des coûts nécessite une attribution au niveau de l'infrastructure

Les coûts de l'IA sont déterminés par une combinaison de :

• Utilisation des jetons
• Sélection du modèle
• Demande de simultanéité
• Infrastructure d'exécution sous-jacente

Kong n'a aucune visibilité sur ces facteurs de coûts spécifiques à l'IA.
Portkey expose des métriques au niveau des jetons, mais l'attribution des coûts devient de plus en plus difficile car l'utilisation concerne plusieurs équipes, applications et environnements.

Sans attribution au niveau de l'infrastructure, les équipes chargées de la plateforme et des finances ont du mal à répondre à une question fondamentale : qui dépense quoi et pourquoi ?

L'isolation environnementale n'est pas négociable en production

Les systèmes d'IA de production exigent une séparation stricte entre :

• Environnements de développement, de mise en scène et de production
• Charges de travail internes et externes
• Données réglementées et non réglementées

Kong n'a pas été conçu en gardant à l'esprit l'isolation de l'environnement d'IA.
Portkey optimise les flux de travail des applications plutôt que d'imposer des limites d'environnement strictes.

Pour les entreprises des secteurs réglementés, ce manque d'isolement devient rapidement un obstacle au déploiement.

La conformité et la résidence des données ne peuvent pas être renforcées

Les déploiements d'IA d'entreprise doivent répondre à des exigences telles que :

• GDPR
• SOC 2
• ITAR
• Résidence des données régionales et exécution isolée

Ces contraintes doivent être appliquées au niveau de l'infrastructure, qui n'est pas intégré au code de l'application ni géré manuellement par les équipes.

Kong traite le trafic de l'IA comme des requêtes HTTP génériques.
Portkey suppose une utilisation axée sur le cloud au niveau de l'application.

Aucune des deux approches n'est conçue pour déploiements d'IA axés sur la conformité.

Les systèmes d'IA modernes vont au-delà des simples instructions

L'IA en production ne se limite plus aux appels synchrones à réponse rapide. Les systèmes du monde réel incluent :

• Agents de longue date
• Appels d'outils et orchestration
• Tâches en arrière-plan et inférence par lots
• Flux de travail dynamiques et en plusieurs étapes

Les passerelles qui se concentrent uniquement sur le trafic API ou le routage rapide ne parviennent pas à régir le cycle de vie complet des charges de travail liées à l'IA.

La réalité de l'entreprise

À mesure que l'adoption de l'IA progresse, les entreprises convergent vers le même constat : Les passerelles seules ne suffisent pas. L'exécution de l'IA en production nécessite une couche d'infrastructure qui unifie accès, déploiement, observabilité, gouvernance et conformité. C'est pourquoi les organisations finissent par aller au-delà des passerelles API et des passerelles d'applications LLM pour Plateformes d'infrastructure natives d'IA conçues pour l'échelle de l'entreprise

TrueFoundry : une meilleure alternative pour les plateformes d'IA d'entreprise

Les limites de Kong et Clé de port proviennent de la même cause fondamentale : les deux ont été conçus pour résoudre problèmes au niveau de la passerelle, pas problèmes d'infrastructure d'IA d'entreprise.

Alors que l'IA devient une capacité partagée et essentielle à la production, les entreprises ont besoin de plus que le routage du trafic ou une abstraction rapide. Ils ont besoin d'une plateforme qui traite Gouvernance, déploiement, observabilité et sécurité de l'IA en tant que problèmes d'infrastructure de premier ordre. C'est ici True Foundry se distingue.

TrueFoundry repose sur l'idée que les charges de travail de l'IA doivent être gérées comme tout autre système de production critique, mais avec Primitives natives de l'IA. Au lieu de fonctionner uniquement dans le chemin de la demande, TrueFoundry fonctionne comme un plan de contrôle IA unifié.

À un niveau élevé, TrueFoundry réunit :

• Un Passerelle IA pour les modèles, les agents et les outils
• UNE plateforme de déploiement pour les services d'IA et les tâches par lots
• Gouvernance au niveau de l'infrastructure et application des politiques
• Observabilité unifiée à travers les jetons, les modèles et le comportement d'exécution
• Sécurité, conformité et isolation de niveau professionnel

TrueFoundry en tant que plan de contrôle IA

‍

Dans de nombreuses piles d'IA, l'utilisation de LLM est traitée comme un problème d'intégration d'API : les demandes sont acheminées, authentifiées et enregistrées, mais tout ce qui dépasse les limites de la demande est laissé aux applications individuelles. TrueFoundry adopte une approche différente en traitant les charges de travail, les services, les emplois et les agents d'IA comme objets d'infrastructure avec cycle de vie, propriété et limites opérationnelles.

Plutôt que de simplement décider si une demande doit être autorisée, TrueFoundry contrôle où les systèmes d'IA fonctionnent, comment ils s'exécutent et sous quelles contraintes, du déploiement à l'exécution. Ce passage du routage des demandes au contrôle du cycle de vie permet une gouvernance cohérente à mesure que l'utilisation de l'IA évolue.

Concrètement, cela se manifeste sous plusieurs aspects critiques.

Application des politiques au niveau de l'environnement

Dans les architectures centrées sur les passerelles, politiques d'accès sont généralement intégrés au code de l'application, à la configuration du SDK ou aux règles de passerelle par service. Cela devient rapidement fragile à mesure que les équipes, les services et les environnements se multiplient.

TrueFoundry applique les politiques d'accès et d'utilisation au niveau d'espace de travail et d'environnement. Les modèles, les agents et les outils sont limités à des environnements tels que le développement, le staging et la production, les autorisations et les contrôles étant appliqués de manière cohérente à toutes les charges de travail déployées dans cet environnement.

Parce que les politiques sont liées à des environnements plutôt qu'à des applications individuelles :

• Les contraintes de production ne peuvent pas être contournées par des clients mal configurés
• Les nouveaux services héritent des politiques appropriées par défaut
• La gouvernance reste stable même si les équipes et les bases de code changent

Garde-corps d'utilisation imposés par l'exécution

Les systèmes d'IA échouent en production, non pas parce qu'une seule demande n'est pas valide, mais parce que l'utilisation s'accumule de manière inattendue en raison de pics de simultanéité, de tempêtes de nouvelles tentatives ou de charges de travail en arrière-plan exécutées à grande échelle.

TrueFoundry impose l'utilisation garde-corps au moment de l'exécution, avec une visibilité sur le comportement des charges de travail au moment de l'exécution. Les limites de simultanéité, les contraintes de débit et les limites d'utilisation sont appliquées de manière centralisée aux services et aux tâches qui partagent des modèles ou une infrastructure sous-jacents.

Parce que ces limites sont appliquées au niveau de la plate-forme :

• Les garde-corps s'appliquent uniformément à tous les clients et services
• Les charges de travail incontrôlables peuvent être contenues même si les vérifications côté application échouent
• Les pics de coûts sont évités avant qu'ils ne se propagent à l'ensemble des équipes

Cela est fondamentalement différent des contrôles côté client ou au niveau du SDK, qui supposent que les applications se comportent correctement et indépendamment.

Isolation au niveau de la couche de déploiement

TrueFoundry renforce l'isolation au niveau du couche de déploiement et d'environnement, et pas seulement sur demande d'admission. Les services d'IA, les tâches par lots et les flux de travail des agents sont déployés sous forme de charges de travail isolées dans des environnements définis, avec un accès, des politiques et des ressources délimités par environnement.

Ces charges de travail s'exécutent comme déploiements et tâches séparés avec des processus d'exécution et des domaines de défaillance indépendants, plutôt que de partager un seul contexte d'exécution plat derrière une passerelle. En conséquence :

• Les défaillances d'un service ou d'une tâche n'ont pas automatiquement d'impact sur les autres
• Les charges de travail hors production sont isolées de la production par défaut
• La contention des ressources et la propagation des pannes sont contenues

Les passerelles LLM au niveau de l'application, qui fonctionnent principalement dans le chemin de la demande, ne contrôlent pas l'exécution de l'exécution ni l'état de l'infrastructure. Par conséquent, ils ne peuvent pas fournir ce niveau de déploiement et d'isolation de l'environnement, un problème qui devient de plus en plus visible à mesure que les charges de travail de l'IA évoluent entre les équipes et les environnements de production.

Observabilité et coût à la bonne couche

Les métriques au niveau des jetons sont utiles, mais insuffisantes une fois que les charges de travail d'IA couvrent des services de longue durée, des tâches en arrière-plan et des flux de travail des agents. Dans les systèmes de production, les coûts et les performances découlent de l'interaction entre :

• Utilisation des jetons et sélection du modèle
• Simultanéité des demandes et durée d'exécution
• Consommation de ressources d'exécution
• Environnement et esprit d'équipe

TrueFoundry met en corrélation ces signaux au niveau de la plateforme, ce qui permet aux équipes de raisonner sur le comportement de l'IA de la même manière qu'elles raisonnent sur les autres systèmes de production :par environnement, service et propriétaire, et non par des appels d'API individuels.

Conçu pour les déploiements réglementés et privés

De nombreux déploiements d'IA d'entreprise sont soumis à des contraintes que les passerelles au niveau des applications suppriment implicitement, notamment :

• Exécution dans des VPC privés ou des environnements sur site
• Exigences relatives à la résidence des données liées à la géographie ou à la réglementation
• Configurations de réseaux restreints ou à espaces restreints

Le plan de contrôle de TrueFoundry est conçu pour fonctionner sur tous ces modèles de déploiement, garantissant ainsi la cohérence de la gouvernance, de l'isolation et de l'observabilité, quel que soit l'endroit où l'inférence est exécutée. Par conséquent, les propriétés de conformité, telles que les limites des données et l'auditabilité, sont appliquées dans le cadre de l'infrastructure elle-même, au lieu d'être ajoutées ultérieurement par le biais de la logique des applications ou des contrôles de processus.

Conclusion

Kong et Portkey résolvent chacun des problèmes importants à différents stades de l'adoption de l'IA. Kong étend les modèles de passerelle API familiers au trafic d'IA, tandis que Portkey introduit des abstractions natives LLM qui facilitent la création et l'exploitation d'applications basées sur l'IA.

Cependant, à mesure que l'IA devient une capacité partagée critique pour la production, les entreprises sont rapidement confrontées à des défis qui vont au-delà du routage des demandes ou de la gestion rapide. La gouvernance, l'attribution des coûts, l'isolation de l'environnement et la conformité nécessitent tous des contrôles au niveau de l'infrastructure et pas seulement au niveau de la passerelle.

C'est pourquoi de nombreuses organisations vont au-delà des passerelles d'applications API et LLM pour se tourner vers des plateformes d'infrastructure natives d'IA telles que True Foundry, qui sont conçus pour exécuter, gouverner et faire évoluer les systèmes d'IA de manière fiable au sein des équipes et des environnements.

‍