El problema: llamar al LLM sin gobierno

Una llamada a un modelo de lenguaje se escribe como cualquier otra petición HTTP, y esa familiaridad engaña. Un fetch a tu propia API cuesta microcéntimos, responde en decenas de milisegundos y deja rastro en tus logs. Una llamada a un LLM cuesta céntimos, tarda segundos, se factura por tokens que no ves hasta fin de mes y ocurre por completo fuera de tu observabilidad. Este nivel empieza reconociendo ese desajuste, porque AI Gateway no es un producto que se entienda leyendo su lista de funciones: se entiende cuando duele el problema que resuelve.

Las cuatro patologías de la llamada directa

La primera es el coste. En una API tradicional pagas por petición o por servidor, y una petición repetida es esencialmente gratis. En inferencia pagas por token, de entrada y de salida, y el precio varía uno o dos órdenes de magnitud entre modelos. Dos usuarios que preguntan exactamente lo mismo generan dos facturas idénticas. Un prompt de sistema de tres mil tokens que se reenvía en cada turno de una conversación se paga íntegro en cada turno.

Hay además un efecto de segundo orden que hace el coste especialmente traicionero: crece con el historial. Una conversación larga reenvía todo lo anterior en cada turno, así que el gasto de una sesión no es lineal en el número de mensajes sino que se acelera con ellos. Una función que parecía barata con tres turnos de prueba puede ser ruinosa con treinta, y nada en tu código avisa del cambio de régimen.

La segunda es la latencia. La inferencia no es un cómputo de milisegundos: es un proceso generativo que produce tokens de uno en uno. Una respuesta larga puede tardar varios segundos, y esa espera es estructural, no un problema de red que puedas optimizar acercándote al origen. Peor aún: no puedes conocerla de antemano, porque depende de cuánto decida escribir el modelo. Eres el único servicio de tu arquitectura cuya duración la decide un tercero en tiempo de ejecución.

La tercera es la opacidad. El panel de tu proveedor agrega el gasto por clave de API, no por funcionalidad, ni por cliente, ni por equipo. Cuando la factura sube un treinta por ciento, no tienes forma de responder a la única pregunta que importa: qué parte de tu producto lo causó. Y la respuesta habitual ante esa ceguera —repartir claves distintas por servicio para poder distinguirlos— multiplica los secretos que hay que custodiar sin darte todavía la dimensión que de verdad querías, que es por funcionalidad y por cliente.

La cuarta, y la más peligrosa, es la falta de control. Entre un bucle accidental en tu código y tu tarjeta de crédito no hay absolutamente nada. Ni un límite de caudal, ni un presupuesto, ni un aviso. Un agente mal terminado que reintenta sin freno puede gastar en una noche el presupuesto de un trimestre, y te enterarás por el correo del proveedor, no por tu propia instrumentación.

Conviene notar que estas cuatro no son cuatro problemas independientes: son la misma ausencia vista desde cuatro ángulos. En una arquitectura clásica, el tráfico hacia un servicio externo atraviesa alguna capa tuya —un cliente compartido, un sidecar, una malla de servicios— donde viven los reintentos, las métricas y los cortacircuitos. Con la IA, casi todo el mundo se saltó ese paso: el SDK del proveedor es tan cómodo que se llama desde donde haga falta, y de repente tienes decenas de puntos de salida sin nada en común. La factura sorpresa y la caída sin plan B son síntomas del mismo hueco topológico.

Qué aporta un proxy delante de todos tus proveedores

Un gateway de IA es, estructuralmente, algo muy simple: un intermediario por el que pasan todas tus llamadas a modelos, sea cual sea el proveedor. No sustituye a nadie ni ejecuta inferencia. Se limita a estar en medio. Y estar en medio, cuando todo el tráfico pasa por ti, es una posición de un poder enorme: es el único sitio del sistema donde puedes observar, contar, cachear, limitar y desviar sin tocar el código de la aplicación.

Conviene ser preciso sobre qué significa aquí “estar en medio”, porque no es una metáfora vaga. Significa que existe un lugar del sistema por el que pasa el cien por cien de las peticiones de IA, que conoce el proveedor, el modelo, el cuerpo, la respuesta, los tokens y el tiempo, y que puede decidir antes de reenviar. Cualquiera de esas cuatro capacidades —observar, recordar, frenar, redirigir— es trivial de implementar cuando tienes ese lugar, y prácticamente imposible de implementar bien cuando no lo tienes.

Adoptarlo no exige reescribir nada. Sigues usando el SDK del proveedor; lo único que cambia es a dónde apunta.

import OpenAI from "openai";

// antes: el SDK habla directamente con el proveedor
// ahora: la misma llamada atraviesa tu gateway
const cliente = new OpenAI({
  apiKey: env.CF_AIG_TOKEN,
  baseURL: `https://gateway.ai.cloudflare.com/v1/${env.CF_ACCOUNT_ID}/mi-gateway/openai`,
});

const respuesta = await cliente.chat.completions.create({
  model: "gpt-5.2-mini",
  messages: [{ role: "user", content: "Resume este texto" }],
});

Desde un Worker el acoplamiento es aún menor, porque el binding de IA acepta el gateway como una opción de la propia llamada y no hay ni siquiera una URL que recordar.

export default {
  async fetch(request, env): Promise<Response> {
    const salida = await env.AI.run(
      "@cf/meta/llama-4-scout-17b-16e-instruct",
      { prompt: "Explica que es un proxy de IA" },
      { gateway: { id: "mi-gateway", skipCache: false } },
    );
    return Response.json(salida);
  },
} satisfies ExportedHandler<Env>;

flowchart LR
APP[Tu Worker o backend] --> GW[AI Gateway]
GW --> CACHE[Cache de respuestas]
GW --> LIM[Rate limiting y presupuesto]
GW --> LOG[Logs tokens coste latencia]
GW --> P1[Workers AI]
GW --> P2[OpenAI]
GW --> P3[Anthropic]
style GW fill:#89b4fa,color:#11111b
style CACHE fill:#a6e3a1,color:#11111b
style LOG fill:#f9e2af,color:#11111b

Todo lo que estudiaremos en este nivel —cache, rate limiting, observabilidad, reintentos, multi-proveedor— no son cinco productos distintos. Son cinco consecuencias de la misma decisión arquitectónica: haber concentrado el tráfico de IA en un único punto de paso. Si esa idea te suena a la vieja distinción entre política y mecanismo, es exactamente eso: el mecanismo —generar tokens— sigue siendo del proveedor; la política —cuándo, cuánto, para quién y con qué presupuesto— vuelve a ser tuya.

El precio del intermediario

Un proxy añade un salto, y todo salto añade latencia. Conviene medir bien esa objeción antes de aceptarla. El gateway corre en la misma red edge que tu Worker, así que el sobrecoste se cuenta en unos pocos milisegundos. La inferencia que envuelve se cuenta en segundos. Estás añadiendo un uno por ciento de latencia para ganar la posibilidad de eliminar el cien por cien en cada acierto de caché.

La segunda objeción, más seria, es que un punto de paso único es también un punto único de fallo. Es cierta como afirmación topológica y engañosa como afirmación de riesgo, porque compara mal: la alternativa no es cero dependencias, es una dependencia directa del proveedor, que tiene disponibilidad peor y sobre la que no puedes hacer absolutamente nada. Un intermediario que además te da reintentos y desvío a otro proveedor mejora tu disponibilidad neta aunque añada un componente, y esa es la única cuenta que importa.

La tercera objeción es la del acoplamiento: cambiar una dependencia de proveedor por una de plataforma. Aquí la respuesta está en el propio diseño, y es la razón de que la última lección de este nivel trate de portabilidad. Como el gateway habla el dialecto nativo de cada proveedor sin obligarte a nada, quitarlo es volver a apuntar la URL a su destino original. Una capa de la que se puede salir en un despliegue no es una jaula.

Lo que un gateway no arregla

Tan importante como saber qué resuelve es saber dónde termina, porque un intermediario mal entendido genera expectativas que luego se cobran en desconfianza. Un gateway no mejora la calidad del modelo: si tu prompt es malo, obtendrás la misma respuesta mala, solo que registrada y con presupuesto. Tampoco acelera una inferencia real: cuando la caché falla, el usuario espera exactamente lo que esperaría sin proxy, y la única forma honesta de bajar esa cifra es elegir otro modelo o pedir menos texto.

Hay dos límites más que conviene fijar desde el principio. El primero: la caché actual exige coincidencia exacta de la petición, no equivalencia de significado, así que dos formas distintas de preguntar lo mismo se pagan dos veces. El segundo: el coste que te muestra es una estimación calculada a partir de tokens y tarifas conocidas, excelente para comparar y decidir, insuficiente para cerrar la contabilidad —esa sigue viniendo del proveedor—.

Y queda una obligación nueva que el gateway te crea en lugar de resolverte: guardar el registro de cada petición significa guardar lo que tus usuarios escribieron. Ganas visibilidad y heredas un almacén de datos potencialmente sensibles con su límite de tamaño, su política de retención y sus implicaciones legales. Es un intercambio razonable y perfectamente gobernable, pero es un intercambio, no un regalo, y merece decidirse antes de activarlo.