La passerelle de PayPal unifie l’accès à plusieurs fournisseurs d’IA sous des règles communes
Governing Enterprise AI Traffic at Scale: Design and Operation of a Policy-Driven, Multi-Vendor LLM Gateway on Envoy · arXiv:2610.35509
En termes simples
Cet article décrit Cosmos LLM Gateway, un système que PayPal a conçu pour permettre aux applications d’entreprise d’accéder, selon des règles communes, aux modèles de différents fournisseurs. Un service distinct vérifie l’identité, les droits d’accès et les budgets.
De son côté, un filtre intégré au proxy de trafic convertit les requêtes et suit l’utilisation des jetons au fil de l’arrivée des fragments de réponse. Lors d’essais avec un service amont simulé, le délai ajouté au parcours de la requête est resté à une médiane de 4 ms, même lorsque la charge a atteint environ 2 300 requêtes par seconde.
Le test ne mesurait ni le traitement du corps de la réponse ni les performances à proximité de la saturation.
La recherche
Quand les applications se connectent directement à plusieurs fournisseurs de modèles, les identifiants d’accès, les formats de requête, les contrôles de dépenses et les règles sur les données peuvent se disperser.
Une organisation peut-elle réunir ces fonctions derrière un point d’accès commun tout en limitant le délai ajouté aux requêtes ?
Cosmos LLM Gateway centralise l’accès aux modèles et leur gouvernance en séparant les décisions de contrôle de la conversion dans le proxy, afin de limiter les délais pour le trafic transmis en continu.
Cosmos LLM Gateway centralise l’accès aux modèles et leur gouvernance en séparant les décisions de contrôle de la conversion dans le proxy, afin de limiter les délais pour le trafic transmis en continu. Avec deux instances, le doublement de la charge, de 1 137 à 2 257 requêtes par seconde, a laissé inchangé le délai ajouté par la passerelle : 4 ms à la médiane, 10 ms au 95e centile et 11 ms au 99e centile.
Les auteurs ont mesuré le temps jusqu’au début de la réponse du service amont, moins le temps de traitement du service amont simulé ; les résultats avec quatre instances sont restés tout aussi stables. Ces mesures étayent la conclusion des auteurs selon laquelle une entreprise peut centraliser la gouvernance de plusieurs fournisseurs avec un surcoût mesuré de quelques millisecondes en médiane sur le parcours des requêtes.
Le test de latence portait sur un service amont simulé et uniquement sur le chemin de la requête, jusqu’au début de la réponse du service amont ; il excluait le traitement du corps de la réponse, et les auteurs n’ont pas testé le système à proximité de sa saturation. Le système et ses résultats en production concernent une seule organisation.
Ce que montrent les preuves
- Un point d’accès commun aux modèles
Cosmos LLM Gateway est le système que PayPal utilise en production pour permettre aux applications d’entreprise d’accéder, selon des règles communes, aux modèles de plusieurs fournisseurs. L’article traite du problème que pose la connexion directe de chaque application à chaque fournisseur : les identifiants d’accès, les formats de requête, les contrôles de dépenses et la gouvernance risquent de se disperser entre les équipes.
Les auteurs se demandent si une passerelle partagée peut réunir ces fonctions tout en gardant un parcours de requête réactif.
- Séparer les décisions de la conversion
La passerelle répartit le travail selon les besoins de chaque tâche. Un service distinct prend en charge les identités, les identifiants d’accès et les décisions de règles qui dépendent d’informations externes.
Un filtre intégré au proxy de trafic convertit les requêtes et mesure l’utilisation des jetons au fil de l’arrivée des fragments de réponse. Par défaut, les fragments de réponse transmis en continu n’attendent donc pas un appel externe, même si certains usages de protection des données nécessitent le traitement de la réponse.
- Tester le parcours des requêtes
Les auteurs ont mesuré le délai ajouté au parcours de la requête en faisant passer les requêtes par la passerelle vers un service amont simulé dont la latence était fixe, puis en soustrayant le temps de traitement de ce service.
Avec deux instances, le doublement de la charge, de 1 137 à 2 257 requêtes par seconde, a laissé inchangé le surcoût à la médiane, au 95e centile et au 99e centile : 4, 10 et 11 millisecondes. Les résultats avec quatre instances sont également restés stables aux charges testées, sans requête échouée.
- Compléter par des données de production
Le résultat de latence ne couvre que le parcours de la requête jusqu’au début de la réponse du service amont.
L’article complète ce résultat par des chiffres de production et des observations lors de déploiements en situation d’appels vocaux : en septembre 2026, la passerelle desservait plus de 12 000 développeurs et, lors de plus de dix déploiements en période de trafic, a maintenu plus de 2 000 appels simultanés sans interruption signalée. Ces observations montrent le fonctionnement du système chez PayPal ; la conclusion des auteurs reste limitée à une seule entreprise et aux conditions décrites.
Détails
- Auteurs de l’article original
- Mithun Sasidharan, Srinivasan Manoharan, Rupesh Thakur, Abhinav TK, Ashwin Hegde
- Soumis à arXiv
- Licence
- arXiv non-exclusive