Arquitectura de presupuestos para AI Gateways: Virtual Keys, Provider Keys y cuotas distribuidas

Como establecimos al hablar de los retos de agrupar claves de API, al construir un AI Gateway como interfaz principal entre tus usuarios y los LLMs upstream, enrutar peticiones es solo la mitad del trabajo. El reto más difícil es diseñar un sistema de presupuestos a nivel de producto.

Si no diseñas tu sistema de cuotas correctamente, un pico repentino de peticiones concurrentes puede saltarse tus límites, arruinar tus cuentas de API upstream y causar interrupciones generalizadas de 429 Too Many Requests para todos tus clientes.

En este último post, recorreremos un plano para arquitectar un motor de cuotas distribuido para IA.

La división arquitectónica: ejecución vs. verdad

El error más común al construir un AI Gateway es tratar al propio proxy como fuente de verdad.

Una arquitectura de producción debe separar la ejecución de peticiones de la verdad del presupuesto. El gateway puede parsear headers, gestionar Server-Sent Events (SSE) en streaming y manejar timeouts. Pero un módulo de presupuesto dedicado (o microservicio) debe ser el dueño de la vista autorizada de los presupuestos de los usuarios, los contadores y el gasto.

Límites de demanda vs. de oferta

Un AI Gateway en producción opera como un mercado de dos lados. Una petición solo es válida si pasa las verificaciones en ambos lados de la ecuación.

1. Límites de demanda (el usuario)

Estas son las restricciones impuestas sobre la entidad que hace la petición.

• Identidad: ¿Quién es? (Mapeado vía una Virtual Key)
• Modelos permitidos: ¿Puede usar gpt-4o o solo gpt-3.5-turbo?
• Gasto máximo: ¿Ha excedido este equipo su límite mensual de $500?
• Rate limits: ¿Está superando sus 50 Requests Per Minute (RPM) asignados?

2. Límites de oferta (el provider)

Estas son las restricciones de tu infraestructura upstream real.

• Provider Keys: ¿Qué claves de OpenAI/Anthropic están disponibles?
• Capacidad: ¿Tiene sk-key-1 suficientes Tokens Per Minute (TPM) restantes para completar este prompt?
• Cooldowns: ¿Está esta clave específica bloqueada por un 429 del provider?

Las Virtual Keys son la frontera del presupuesto

Una Virtual Key no es simplemente un token de autenticación; es la frontera fundamental del presupuesto.

En un sistema multi-tenant, la Virtual Key representa identidad, acceso a modelos y atribución de gasto al mismo tiempo. Esto muestra por qué las arquitecturas que no sincronizan el estado de las Virtual Keys entre múltiples nodos (como los despliegues open-source de Bifrost que analizamos antes) están rotas. Si el estado de las Virtual Keys no es globalmente coherente, tu frontera de presupuesto simplemente no existe bajo carga.

El flujo de peticiones de un módulo de presupuesto

Para orquestar estas restricciones de forma segura, tu módulo de presupuesto debe ejecutar una secuencia específica de operaciones:

1. Resolver la Virtual Key: Identificar al usuario, equipo o política de cliente.
2. Verificar el acceso al modelo: Asegurar que el modelo solicitado está permitido para esta Virtual Key.
3. Verificar la cuota de demanda: Consultar Redis/Postgres para asegurar que el usuario tiene suficiente RPM/TPM y presupuesto monetario.
4. Selección de candidatos: Pedir al layer de routing las Provider Keys disponibles.
5. Verificar la cuota de oferta: Asegurar que la Provider Key seleccionada tiene capacidad.
6. Reservar la cuota: Atomically reservar el coste estimado antes de reenviar la petición.
7. Ejecutar: Hacer proxy de la petición al provider del LLM.
8. Liquidar: Calcular los tokens reales usados de los headers de respuesta del provider y actualizar el coste final.
9. Persistir: Escribir el libro mayor durable de gasto a Postgres.

Por qué importa la reserva bajo concurrencia

El paso 6 (Reserva) es la pieza central de todo el sistema.

Imagina que el Usuario X tiene $1.00 restantes en su presupuesto. Lanza un script que dispara 100 peticiones concurrentes al gateway.

Si tu gateway usa una verificación de presupuesto de "solo lectura", las 100 peticiones consultarán la base de datos en el mismo milisegundo. Las 100 peticiones verán "$1.00 restantes" y dejarán que la petición continúe. Unos segundos después, el LLM responde, los costes se liquidan, y el Usuario X ha consumido $10.00 de cómputo, superando su hard limit por 10x.

iWarning+

Para evitar esto, el sistema necesita reserva atómica. Cuando llega una petición, el gateway debe deducir inmediatamente el coste estimado de la petición (p. ej., input_tokens + max_tokens) del contador en caliente en Redis.

Si la reserva empuja el presupuesto por debajo de cero, la petición se bloquea. Una vez que la petición termina, el gateway devuelve los tokens no usados al contador de Redis. Al ejecutar la verificación del presupuesto y la deducción atómicamente dentro de Redis, eliminas por completo la race condition.

Hard limits, soft caps y liquidación

Hacer cumplir estos límites requiere estrategias distintas según la métrica:

• Hard RPM (Requests Per Minute): Esto es directo. Incrementas atómicamente un contador de Redis antes del route. Si excede el límite, lo bloqueas.
• Hard-ish TPM (Tokens Per Minute): Debes reservar tokens estimados antes de enrutar. Como los tokens de salida del LLM son impredecibles, usas el parámetro max_tokens como reserva del peor caso.
• Soft budgets (gasto total): La documentación del AI Gateway de Vercel describe los presupuestos de las claves de API explícitamente como soft caps verificados al inicio de una petición. Permites que la "petición que cruza" (la que empuja a un usuario de $49.95 a $50.10) termine, pero bloqueas inmediatamente todas las peticiones futuras durante la fase de liquidación.

El rol de Redis y Postgres

Un módulo de presupuestos robusto divide las responsabilidades entre almacenes de datos efímeros y durables.

Redis es el dueño del hot path:

• Buckets de tokens RPM/TPM en vivo.
• Reservas atómicas para peticiones en vuelo.
• Contadores de peticiones paralelas máximas.
• Locks de cooldown de provider de corta duración.

Postgres es el dueño del path durable:

• La lista autorizada de Virtual Keys, usuarios y equipos.
• Definiciones de presupuesto y políticas de facturación.
• El libro mayor inmutable de gasto y los registros de reconciliación.

Tesis final

Un AI Gateway en producción es, en su núcleo, un motor de cuotas distribuido de dos lados. Las Virtual Keys representan tu identidad y ejecución de presupuesto del lado de la demanda, mientras que las Provider Keys representan tu capacidad upstream.

Usando herramientas que separan el estado durable del efímero, como LiteLLM, para coordinar reservas en vivo vía Redis y registrar gasto durable vía Postgres, puedes escalar tu infraestructura de IA para manejar alta concurrencia sin arruinar tus cuentas de API. Cualquier arquitectura de gateway que no pueda sincronizar este estado entre sus nodos, como vimos en nuestra comparación LiteLLM vs. Bifrost, no es segura para producción.