ES
La pasarela de PayPal reúne bajo reglas comunes el acceso a IA de varios proveedores
Governing Enterprise AI Traffic at Scale: Design and Operation of a Policy-Driven, Multi-Vendor LLM Gateway on Envoy · arXiv:2610.35509
En palabras sencillas
Este artículo describe Cosmos LLM Gateway, un sistema que PayPal creó para que las aplicaciones empresariales accedan a modelos de distintos proveedores mediante un único punto de entrada con reglas comunes. Un servicio separado comprueba la identidad, los permisos y los presupuestos, mientras un filtro dentro del intermediario que dirige el tráfico traduce las solicitudes y lleva la cuenta de los tokens a medida que llegan los fragmentos de respuesta.
En las pruebas con un servicio de origen simulado, el tiempo añadido a la ruta de la solicitud se mantuvo en una mediana de 4 ms cuando la carga subió a unas 2.300 solicitudes por segundo. La prueba no midió el procesamiento del cuerpo de la respuesta ni el rendimiento cerca de la capacidad máxima.
La investigación
Cuando las aplicaciones se conectan directamente a varios proveedores de modelos, las credenciales, los formatos de solicitud, los controles de gasto y las reglas sobre datos pueden quedar dispersos.
¿Puede una organización reunir esas funciones en un único punto de acceso compartido y mantener bajo el retraso añadido a las solicitudes?
Cosmos LLM Gateway centraliza el acceso a modelos y las reglas de uso, y separa las decisiones de control de la traducción dentro del intermediario de tráfico para limitar el retraso en las respuestas transmitidas.
Cosmos LLM Gateway centraliza el acceso a modelos y las reglas de uso, y separa las decisiones de control de la traducción dentro del intermediario de tráfico para limitar el retraso en las respuestas transmitidas. Con dos instancias, duplicar la carga de 1.137 a 2.257 solicitudes por segundo mantuvo el tiempo añadido por la pasarela en 4, 10 y 11 ms en la mediana, el percentil 95 y el percentil 99.
Los autores midieron el tiempo hasta el inicio de la respuesta del servicio de origen y restaron el tiempo de servicio del sistema simulado; los resultados con cuatro instancias fueron igual de estables. Estas mediciones respaldan la conclusión de los autores de que una empresa puede centralizar las reglas de uso entre distintos proveedores con una demora mediana de unos pocos milisegundos en la ruta de la solicitud, bajo las condiciones probadas.
La prueba de latencia usó un servicio de origen simulado y solo abarcó la ruta de la solicitud hasta antes de que comenzara la respuesta de ese servicio; excluyó el procesamiento del cuerpo de la respuesta y los autores no probaron el sistema cerca de su capacidad máxima. El sistema y los resultados en producción corresponden a una sola organización.
Qué muestran las pruebas
- Un punto de acceso para los modelos
Cosmos LLM Gateway es el sistema que PayPal usa en producción para que las aplicaciones empresariales accedan a modelos de distintos proveedores mediante un único punto de entrada con reglas comunes. El artículo aborda el problema de conectar cada aplicación directamente con cada proveedor: las credenciales, los formatos de datos, los controles de gasto y las reglas de uso pueden quedar dispersos entre equipos.
Los autores preguntan si una pasarela compartida puede reunir esas funciones y mantener ágil la ruta de las solicitudes.
- Separar las decisiones de la traducción
La pasarela distribuye las tareas según lo que cada una necesita. Un servicio separado gestiona la identidad, las credenciales y las decisiones de política que dependen de información externa.
Un filtro dentro del intermediario que dirige el tráfico traduce las solicitudes y mide el uso de tokens —unidades de texto que procesa el modelo— mientras llegan los fragmentos de respuesta. De forma predeterminada, así se evita que los fragmentos transmitidos esperen una llamada externa, aunque algunos usos de protección de datos requieren procesar la respuesta.
- Probar la ruta de la solicitud
Los autores midieron el tiempo añadido a la ruta de la solicitud enviándola a través de la pasarela hacia un servicio de origen simulado con latencia fija y restando luego el tiempo de servicio de ese sistema. Con dos instancias, duplicar la carga de 1.137 a 2.257 solicitudes por segundo mantuvo la sobrecarga en 4, 10 y 11 milisegundos en la mediana, el percentil 95 y el percentil 99, respectivamente.
Los resultados con cuatro instancias también se mantuvieron estables entre las cargas probadas y no hubo solicitudes fallidas.
- Añadir evidencia de producción
La medición de latencia solo abarca la ruta de la solicitud antes de que comience la respuesta del servicio de origen. El artículo añade cifras de producción y observaciones de despliegues durante llamadas de voz en directo: en septiembre de 2026, la pasarela daba servicio a más de 12.000 desarrolladores y, en más de diez despliegues con tráfico en directo, mantuvo más de 2.000 llamadas simultáneas sin llamadas interrumpidas según lo informado.
Estas observaciones muestran su funcionamiento en PayPal, pero la conclusión de los autores se limita a una empresa y a las condiciones descritas.
Detalles
- Autores del paper original
- Mithun Sasidharan, Srinivasan Manoharan, Rupesh Thakur, Abhinav TK, Ashwin Hegde
- Enviado a arXiv
- Licencia
- arXiv non-exclusive