Escalando AI Gateways: Cómo agrupar claves de API y sobrevivir a los rate limits

Cuando integras por primera vez Large Language Models (LLMs) en tu producto, todo funciona. Envías un prompt, recibes una respuesta. Pero a medida que tu base de usuarios crece, te golpeas contra un muro duro: los rate limits del provider.

Ya sean los límites estrictos de Tokens Por Minuto (TPM) de OpenAI o las restricciones de Peticiones Por Minuto (RPM) de Anthropic, una sola clave de API se convierte rápidamente en un cuello de botella. La solución intuitiva es agrupar varias claves de API para exactamente el mismo modelo para aumentar artificialmente tu capacidad total de rate limit.

Sin embargo, gestionar un pool de claves de API de provider introduce un cambio arquitectónico. Vamos a explorar por qué los reverse proxies simples no son suficientes, cómo implementar realmente la agrupación de claves de API y la arquitectura genérica necesaria para hacerlo de forma segura.

El catalizador: Golpear el muro de los rate limits

La mayoría de los grandes proveedores de LLM imponen rate limits duales:

• RPM (Peticiones Por Minuto): Limita el volumen puro de conexiones concurrentes.
• TPM (Tokens Por Minuto): Limita el throughput real de cómputo (a menudo una mezcla de tokens de entrada y salida).

Si tienes una aplicación de IA de rápido crecimiento, alcanzar un límite de 1M TPM es fácil. Unos pocos usuarios intensos que procesan documentos grandes pueden agotar tu cuota en segundos, dejando al resto de tus usuarios mirando errores 429 Too Many Requests.

El paso lógico para superar esto es provisionar varias claves de API (o varios despliegues en la nube, como varios endpoints de Azure OpenAI) y balancear el tráfico entre ellos. Si una clave te da 1M TPM, cinco claves te dan 5M TPM.

El enfoque ingenuo: Por qué los load balancers simples fallan

Tu primer instinto podría ser poner Nginx, HAProxy, o un ALB de AWS básico frente a tus peticiones y configurar una estrategia de routing round-robin simple a través de tu pool de claves de API.

Esto falla en producción.

iWarning+

Los reverse proxies estándar rastrean peticiones, no tokens.

A diferencia del tráfico web tradicional, donde las peticiones tienen costes de recursos relativamente uniformes, las peticiones LLM varían. La Petición A podría hacer una pregunta simple que consume 50 tokens. La Petición B podría pasar un PDF enorme que consume 100.000 tokens.

Si un balanceador round-robin ingenuo distribuye estas peticiones uniformemente por cuenta, agotará las cuotas de tokens de tus claves subyacentes de forma desigual. Una clave de API podría alcanzar su límite TPM al instante mientras otra permanece completamente inactiva. Para enrutar el tráfico correctamente, el load balancer necesita entender el tamaño del payload, estimar los conteos de tokens y mantener el estado de cuánta capacidad queda en cada clave de provider.

El cómo: La arquitectura de IA de 3 capas

Para construir esto de verdad, necesitas abandonar la idea de un único "proxy inteligente". La infraestructura LLM de producción divide las responsabilidades en tres capas distintas.

1. El Plano de Control (Fuente de la verdad)

Esta capa posee el estado global. Almacena tus Virtual Keys (identidades de usuario), presupuestos de usuario, claves de API de provider y contadores en vivo de RPM/TPM. Generalmente está respaldado por Postgres (para billing/claves durables) y Redis (para token buckets rápidos).

2. El Motor de Routing (Tomador de decisiones)

Esta capa decide a dónde debe ir la petición. Comprueba el Plano de Control para ver qué claves de provider tienen capacidad restante, evalúa la lógica de fallback y selecciona el provider upstream óptimo (p. ej., elegir la Clave #3 de OpenAI porque tiene más TPM disponible).

3. El Gateway (Capa de ejecución)

Este es el plano de datos "tonto". Recibe el payload, adjunta la clave de API física elegida por el router, reenvía la petición al LLM, transmite los Server-Sent Events (SSE) de vuelta al cliente y emite logs de uso de vuelta al Plano de Control.

Implementar rate limits distribuidos

¿Cómo evitas realmente que las peticiones superpuestas superen tus límites cuando ejecutas varios nodos de gateway? Debes externalizar la verificación de cuota usando bloqueo pesimista a través de Redis.

Cuando llega una petición, el Plano de Control la intercepta, estima el coste en tokens y deduce ese coste de un contador global de Redis antes de reenviar la petición al Gateway. Si el contador de Redis llega a cero, la petición se bloquea inmediatamente.

Como Redis procesa los comandos atómicamente, no importa si tienes 1 o 100 nodos de gateway procesando peticiones simultáneamente. Dos peticiones concurrentes no pueden vaciar el mismo presupuesto de 1,00 $. El Plano de Control garantiza que la cuota nunca se infringe.

Próximos pasos: Elegir tu implementación

Puedes construir este sistema de 3 capas completamente desde cero, pero la mayoría de los equipos adoptan gateways de IA open-source que implementan partes (o todo) de este patrón.

Sin embargo, no todos los gateways manejan el estado global de la misma manera. En futuros posts, profundizaremos en cómo este requisito arquitectónico impacta tus elecciones:

• LiteLLM: Empaqueta el Plano de Control (vía Redis) y el Router/Gateway juntos, haciéndolo muy capaz de rate limiting distribuido open-source out-of-the-box.
• Bifrost: Actúa como un Router/Gateway rápido, pero rastrea el estado por nodo. Para escalarlo de forma segura sin pagar por el clustering Enterprise, debes construir y adjuntar tu propio Plano de Control externo.

Para un análisis más profundo de la teoría detrás de los límites del lado de la demanda frente a los del lado de la oferta, explora nuestro plano para arquitectar presupuestos de AI gateway.