LLM Proxy vs AI Gateway: arquitectura, control y decisiones

Un proxy para LLM y un AI gateway pueden ocupar la misma posición entre una aplicación y los proveedores de modelos, pero no necesariamente asumen las mismas responsabilidades. Un proxy se centra en transportar solicitudes y respuestas. Un AI gateway suele añadir decisiones conscientes del modelo: políticas de enrutamiento, fallback, registros de uso, atribución de costes y reglas de acceso por carga de trabajo.

Los nombres no son estándares. Algunos productos llaman «proxy» a una capa con control de modelos; otros llaman «gateway» a poco más que un endpoint administrado. Por eso, la decisión debe basarse en responsabilidades verificables y no en la etiqueta comercial.

Empieza por las responsabilidades, no por el nombre

Ambas capas suelen aparecer en la misma posición de red:

Aplicación o agente de programación
        ↓
Proxy para LLM o AI gateway
        ↓
Proveedor y modelo seleccionado

El diagrama no explica qué hace realmente la capa intermedia. Una matriz de responsabilidades permite compararlas de forma más útil.

Responsabilidad	Proxy orientado al transporte	AI gateway consciente del modelo
Terminación TLS y reenvío HTTP	Habitual	Habitual
Gestión de URL y headers upstream	Habitual	Habitual
Reenvío de streaming	Frecuente	Frecuente, pero hay que verificar el contrato de eventos
Aislamiento de credenciales del proveedor	A veces	Habitual, con límites de almacenamiento y acceso por verificar
Superficie OpenAI-compatible	A veces	Habitual, con diferencias por modelo y función
Enrutamiento por modelo o proveedor	Limitado o propiedad de la aplicación	Habitual
Reintentos y fallback ordenado	Como mucho, reintentos básicos	A menudo depende del modelo y del tipo de fallo
Límites por carga de trabajo	Normalmente externos	Habituales
Registros de tokens, uso y coste	Normalmente externos	Habituales
Diagnóstico de latencia por solicitud	Normalmente externo	Habitual
Políticas y auditoría	Normalmente externas	Depende del producto

«Habitual» no significa garantizado. Para cada fila crítica hay que pedir el contrato exacto, el comportamiento ante fallos, los datos que quedan registrados y los controles disponibles para operaciones.

Qué suele resolver un proxy para LLM

Un proxy orientado al transporte puede ser suficiente cuando el objetivo principal es colocar un endpoint estable delante de una API upstream. Puede centralizar TLS, hostname, headers, límites de tamaño, timeouts y logs básicos. Si entiende Server-Sent Events, también puede reenviar streaming sin almacenar la respuesta completa.

Es una capa útil: crea una ruta de red controlada, evita exponer credenciales del proveedor en ciertos clientes y ofrece un punto para autenticación y políticas de red convencionales.

La frontera cambia cuando el proxy traduce formatos, selecciona proveedores, cuenta tokens o calcula el coste de una petición. Esas decisiones ya son conscientes del modelo. A partir de ahí conviene evaluarlo como gateway, aunque el producto siga llamándose proxy.

Un proxy sencillo suele encajar cuando:

• una aplicación usa un proveedor y un conjunto pequeño de modelos fijados;
• la aplicación ya controla reintentos, uso y diagnóstico de incidentes;
• las funciones nativas del proveedor deben pasar sin traducción;
• no se necesitan políticas distintas por equipo o carga de trabajo;
• se busca la capa operativa mínima posible.

Qué añade un AI gateway

Un AI gateway trata una petición de modelo como algo más que tráfico HTTP. Puede decidir la ruta según el modelo solicitado, el protocolo, la política de la clave, la capacidad de cada grupo y los resultados de intentos anteriores. Después puede asociar el intento final con tokens, tiempos, estado y coste.

Las funciones no son idénticas entre productos. La documentación de Cloudflare AI Gateway reúne analytics, logging, caché, rate limiting, reintentos y fallback. La documentación de métricas de Kong AI Gateway describe métricas de modelo, tokens, coste, caché, latencia y errores. Son ejemplos del control que suele esperarse, no una definición universal.

Un gateway resulta especialmente útil cuando coinciden varias necesidades:

• varias aplicaciones o agentes necesitan claves y consumo atribuibles por separado;
• el mismo modelo solicitado dispone de más de una ruta válida;
• los límites deben aplicarse antes de generar trabajo o coste upstream;
• operaciones necesita separar autenticación, selección de ruta, espera upstream, primer resultado útil y generación;
• cada cargo debe poder explicarse a nivel de solicitud;
• existe una política explícita y ordenada de fallback;
• se necesita una vista operativa común para varios grupos de modelos.

Un gateway no hace intercambiables todos los proveedores. Tampoco sustituye la validación de resultados, la idempotencia de herramientas, la protección de secretos en la aplicación ni las pruebas de funciones nativas.

Decide según la carga de trabajo

Carga de trabajo	Necesidad principal	Punto de partida razonable	Motivo
Servicio interno con un proveedor y un modelo	Ruta de red estable	API directa o proxy pequeño	Una política avanzada puede añadir complejidad sin valor actual
Aplicación para clientes con varias rutas para el mismo modelo	Disponibilidad y evidencia de intentos	AI gateway	Enrutamiento, fallback limitado y diagnóstico necesitan un único responsable
Agentes de programación para todo un equipo	Claves, cuotas, atribución y bajas	AI gateway	Una clave compartida y el gasto sin propietario son riesgos operativos
Aplicación que usa una función nativa nueva	Compatibilidad exacta del protocolo	Endpoint nativo y después una capa verificada	Una API normalizada puede omitir o retrasar campos nuevos
Procesamiento batch con cola y reintentos propios	Rendimiento y recuperación controlada por la aplicación	Proxy o gateway con reintentos desactivados o limitados	Varias capas de reintento amplifican fallos y duplican trabajo
Carga regulada o sensible	Evidencia sobre datos, retención y acceso	Depende de controles demostrados	La palabra «gateway» no prueba seguridad ni cumplimiento

La decisión puede cambiar con la madurez del producto. Empezar con un proveedor e introducir un gateway más tarde es razonable si la aplicación mantiene una interfaz interna clara para el cliente de modelos y prueba el contrato de migración.

Ten en cuenta los costes ocultos

Un salto adicional debe medirse

Un proxy o gateway añade red y procesamiento. Una media de latencia no basta: mide tiempo hasta headers upstream, primer resultado efectivo, primer texto visible, duración total y velocidad de salida bajo concurrencia real. Un pequeño coste fijo puede compensarse con una recuperación operativa más rápida, pero depende de la carga.

La compatibilidad depende de cada función

«OpenAI-compatible» puede referirse solo a la URL base, al header de autenticación y a una solicitud de Chat Completions. Responses, Structured Outputs, Tool Calls, campos de uso y errores pueden comportarse de otra manera. Prueba cada función empleada por la aplicación. La guía de API OpenAI-compatible ofrece una base de migración y Responses API frente a Chat Completions explica por qué el nombre del endpoint no demuestra compatibilidad completa.

La centralización crea un dominio de fallo

Centralizar claves, rutas, límites y logs simplifica la propiedad, pero convierte esa capa en infraestructura crítica. Comprueba el versionado y rollback de configuración, el comportamiento si el plano de control no está disponible y si las solicitudes en curso terminan durante un cambio operativo.

El coste necesita una fuente de verdad

Algunos gateways estiman el coste con precios públicos; otros usan precios configurados, multiplicadores de grupo o expresiones de facturación versionadas. Averigua cuándo se selecciona y congela el precio, cómo se representan tokens en caché y herramientas, y si el cargo final se puede reconciliar con el uso. La guía de seguimiento de costes de AI API separa estas capas.

También importa la salida

Antes de adoptar una interfaz normalizada, identifica dependencias de headers exclusivos, alias de modelos, nombres de rutas o APIs de logs. La capa debe facilitar la operación sin impedir volver al protocolo nativo.

Tres ejemplos prácticos

Asistente interno con un proveedor

Un asistente interno realiza solicitudes no streaming a un modelo fijado. La aplicación ya guarda sus job IDs y mantiene una credencial server-side. Un proxy convencional puede bastar; el enrutamiento entre proveedores no resuelve todavía un problema real. Aun así, conviene aislar el cliente del modelo detrás de una interfaz interna para permitir una evolución posterior.

Aplicación de producción con varias rutas

Una aplicación necesita mantener disponible el mismo modelo cuando una cuenta upstream se satura y debe saber qué ruta procesó cada intento y cuál generó coste. Es un caso de gateway: fallback, facturación y diagnóstico deben compartir la misma identidad de solicitud. Cambiar de modelo altera calidad, latencia, herramientas y precio, por lo que debe ser una política explícita. Consulta la guía de enrutamiento fiable de AI API.

Agentes de programación en un equipo

Los agentes generan sesiones largas y con herramientas desde muchos equipos. Una única clave compartida dificulta cuota, atribución, rotación y baja de usuarios. Un gateway puede emitir claves por carga, restringir acceso y asociar uso con equipos o proyectos. Los permisos del repositorio, el sandbox, la aprobación de herramientas y la validación de código siguen fuera de su responsabilidad.

Cómo encaja Modelflare

Modelflare está diseñado como una capa de acceso y enrutamiento consciente de AI, no como un relay HTTP transparente. Una API key normal puede seleccionar un grupo principal y grupos de fallback ordenados. Una Smart API Key puede evaluar grupos elegibles con su estrategia configurada. En ambos casos se busca una ruta válida para el modelo solicitado; no se debería sustituir silenciosamente por otro modelo.

El RPM del grupo se aplica al grupo concreto antes de facturar y antes de enviar trabajo upstream. Si está lleno, se puede evaluar el siguiente grupo elegible; si no queda ninguna ruta, la respuesta es 429. Los registros asocian estado, tokens, coste y tiempos, y distinguen autenticación, selección de grupo, headers upstream, primer evento, primera respuesta efectiva, primer texto visible y duración total.

La compatibilidad tiene un límite explícito: GPT, Codex y el tráfico OpenAI son el objetivo de adaptación completa. Otras familias OpenAI-compatible deben considerarse Chat Completions pass-through hasta verificar su comportamiento adicional. Una URL base común no promete el mismo contrato para Responses, herramientas o Structured Outputs.

Consulta Modelos y precios para ver modelos y grupos disponibles, y la documentación de Modelflare para configurar clientes.

Lista de verificación para producción

• Protocolo: ¿conserva exactamente las formas que usa la aplicación?
• Streaming: ¿reenvía eventos sin buffer, pérdida ni reordenación de argumentos?
• Identidad del modelo: ¿una ruta puede cambiar sin cambiar el modelo solicitado?
• Fallback: ¿qué fallos son elegibles, cuántos intentos hay y cuándo se detienen?
• Límites: ¿se aplican antes del trabajo upstream y la facturación?
• Uso y coste: ¿tokens y cargo final se conectan con ruta y precio?
• Diagnóstico: ¿se distinguen gateway, espera upstream, primer resultado y generación?
• Secretos: ¿quién puede leer credenciales y contenido de solicitudes?
• Cambios: ¿las políticas se pueden revisar y revertir?
• Salida: ¿se puede volver a un endpoint nativo sin reescribir la aplicación?

Ejecuta las pruebas con el mismo modelo, clase de prompt, longitud, streaming, herramientas, región y concurrencia real. Un «hello world» solo demuestra conectividad.

Preguntas frecuentes

¿Todo proxy OpenAI-compatible es un AI gateway?

No. La compatibilidad describe parte del contrato de API; el concepto de gateway describe responsabilidades operativas. Un proxy puede exponer el mismo formato sin controlar rutas, costes, límites ni diagnóstico.

¿Un AI gateway elimina las claves de proveedor?

No necesariamente. Puede custodiar credenciales, aceptar BYOK o mantener su propia relación de facturación. Hay que verificar dónde viven las claves y quién puede utilizarlas o exportarlas.

¿Un AI gateway reduce la latencia?

No de forma automática. Añade un salto, aunque puede mejorar disponibilidad y diagnóstico. La comparación válida es la línea temporal completa de tu carga.

¿El fallback debería elegir otro modelo?

Solo si el producto ha aceptado expresamente el cambio de calidad, compatibilidad, latencia y precio. El valor predeterminado más seguro es otra ruta para el mismo modelo y protocolo.

La diferencia práctica es sencilla: elige un proxy para controlar principalmente el transporte; elige un AI gateway cuando enrutamiento, políticas, uso, coste y evidencia necesiten un responsable común. Después verifica cada responsabilidad: el nombre por sí solo no es evidencia.