Multi-proveedor: una puerta, muchos modelos

El mercado de modelos de 2026 tiene una propiedad incómoda para quien construye: el mejor modelo para tu caso concreto cambia de dueño cada pocos meses, y el precio de lo que hoy es caro cae un orden de magnitud sin avisar. Cualquier arquitectura que ate tu producto a un proveedor concreto está apostando a que esa rueda se detenga, y no se va a detener. La respuesta no es elegir bien: es diseñar para no tener que elegir para siempre. Ese es el último y quizá más estratégico papel del gateway —ser la capa de indirección donde el nombre del modelo deja de ser una dependencia y pasa a ser un parámetro.

Dos maneras de atravesar la misma puerta

La primera es el camino nativo. Cada proveedor soportado tiene su ruta propia dentro del gateway, y bajo ella hablas exactamente el dialecto de ese proveedor: su formato de petición, sus parámetros peculiares, su respuesta tal cual. El SDK oficial sigue funcionando sin cambios porque lo único que ha cambiado es la URL base. Es la vía de adopción con fricción cero y la que conserva hasta el último rincón de la API original.

La segunda es la API unificada, que expone endpoints compatibles en api.cloudflare.com y hace que el proveedor sea parte del nombre del modelo. Hay una ruta universal para cualquier modelo y modalidad, y rutas compatibles con el formato de chat de OpenAI, con su API de respuestas y con el formato de mensajes de Anthropic. Ahí un modelo se escribe como proveedor y modelo separados por una barra, y cambiar de casa es editar una cadena.

Que existan varias formas compatibles y no una sola inventada es una decisión deliberada y muy práctica: en lugar de pedirte que aprendas un formato nuevo, adopta los que tu equipo ya escribe. El SDK que tienes instalado sigue sirviendo, tus tipos siguen valiendo y la migración se reduce a la URL base. Es la misma filosofía que viste en el runtime al apostar por las APIs web estándar en vez de por una API propietaria.

// misma llamada, mismo SDK: solo cambia la cadena del modelo
const cliente = new OpenAI({
  apiKey: env.CF_API_TOKEN,
  baseURL: `https://api.cloudflare.com/client/v4/accounts/${env.CF_ACCOUNT_ID}/ai/v1`,
});

const barato = await cliente.chat.completions.create({
  model: "workers-ai/@cf/meta/llama-3.3-70b-instruct-fp8-fast",
  messages,
});

const potente = await cliente.chat.completions.create({
  model: "anthropic/claude-4-5-sonnet",
  messages,
});

Las dos vías aplican todo lo que has aprendido en este nivel: registro, caché, límites y protecciones se activan igual atravieses la puerta por donde la atravieses. La elección entre ellas no es de capacidades del gateway, sino de a qué renuncias.

Hay un detalle de esa API unificada que parece administrativo y es conceptual: Workers AI aparece ahí como un proveedor más, con su prefijo, junto a los externos. Los modelos que corren dentro de la propia red y los que viven en la nube de otra empresa dejan de ser dos integraciones distintas con dos SDK, dos formas de autenticarse y dos facturas, para convertirse en dos valores de la misma cadena. Esa nivelación es la que hace realista la estrategia de tener un escalón barato y local por debajo de un escalón caro y externo.

Las llaves del reino

Poner un proxy delante resuelve otra cosa que suele pasar desapercibida: dónde viven las claves de los proveedores. Con el modelo tradicional, cada aplicación, cada entorno y cada servicio guarda su copia de la clave de OpenAI, la de Anthropic y la de Google, y rotarlas es un ejercicio de arqueología.

BYOK invierte eso: guardas tus claves una sola vez en el gateway y tu aplicación se autentica solo contra Cloudflare. El secreto del proveedor deja de circular por tu código y por tus despliegues, la rotación pasa a ser un cambio en un sitio, y quien consigue tu token de gateway se encuentra con un permiso acotado en lugar de una clave con crédito ilimitado.

Ese cambio de credencial es más profundo de lo que parece y conecta con una idea que ya viste con los bindings: pasas de repartir un secreto que otorga poder ilimitado sobre una cuenta ajena a repartir una capacidad acotada sobre tu propia puerta. Si el token se filtra, lo revocas tú, en tu panel, sin hablar con nadie, y mientras tanto los límites de gasto que configuraste siguen acotando el daño. Con una clave de proveedor filtrada no tienes ninguna de esas tres cosas.

La alternativa va un paso más allá: con facturación unificada cargas crédito en tu cuenta de Cloudflare y llamas a modelos de terceros sin tener ninguna clave de proveedor. Recibes una sola factura, se aplica un recargo del cinco por ciento sobre el crédito que compras y el precio de inferencia se traslada sin margen añadido. Para un equipo que quiere probar seis modelos de cinco empresas distintas sin abrir seis contratos, la diferencia entre eso y el camino clásico no se mide en dinero sino en semanas.

Vale la pena mirar ese recargo con la calculadora del coste total y no solo con la del precio unitario. Frente a él hay que poner el tiempo de alta y de compras con cada proveedor, la gestión y rotación de varios secretos, la conciliación de facturas distintas con periodos distintos y, sobre todo, el coste de oportunidad de las pruebas que no haces porque abrir una cuenta más da pereza. Para un equipo pequeño en fase de exploración, ese cinco por ciento suele ser lo más barato del presupuesto; para uno grande con consumo comprometido y tarifas negociadas, BYOK es evidentemente mejor. La decisión no es de precio, es de en qué fase estás.

La indirección como estrategia

Con todo lo anterior en su sitio, el paso final es dejar de nombrar modelos en el código. Una ruta dinámica es un nombre con versión que tu aplicación pide como si fuera un modelo, y detrás de ese nombre puede haber una condición, un reparto porcentual, una cuota o una cadena de alternativas. La aplicación pide dynamic/soporte; qué significa eso hoy lo decide la configuración, y mañana puede significar otra cosa sin desplegar nada.

Nombrar bien esas rutas importa más de lo que sugiere su apariencia técnica. El buen nombre describe la tarea, no el modelo ni el proveedor: clasificar tickets, redactar el resumen del cliente, extraer campos de una factura. Un nombre así sobrevive a todos los cambios de catálogo y convierte la configuración en un inventario legible de lo que tu producto le pide a la IA. Un nombre que menciona al proveedor reintroduce por la puerta de atrás exactamente el acoplamiento que acabas de eliminar.

flowchart TB
APP[La aplicacion pide una ruta con nombre] --> RT[Ruta dinamica versionada]
RT --> A[Workers AI modelo pequeno]
RT --> B[OpenAI modelo generalista]
RT --> C[Anthropic modelo de razonamiento]
RT --> D[Proveedor propio autoalojado]
A --> OUT[Misma forma de respuesta]
B --> OUT
C --> OUT
D --> OUT
style RT fill:#89b4fa,color:#11111b
style OUT fill:#a6e3a1,color:#11111b

Esa indirección desbloquea prácticas que sin ella son inviables. Un reparto porcentual convierte el cambio de modelo en un despliegue gradual con vuelta atrás inmediata, en lugar de un salto de fe el viernes por la tarde. Una condición sobre metadatos manda a los usuarios de pago al modelo bueno y a los gratuitos al económico sin una sola bifurcación en tu código. Y comparar dos modelos deja de ser una hoja de cálculo con precios de catálogo para convertirse en un experimento real sobre tu tráfico real, medido con las métricas de la lección anterior.

Fíjate en el desplazamiento que acaba de ocurrir. Elegir modelo era una decisión de ingeniería, tomada una vez, defendida con argumentos de catálogo y revisada cuando algo se rompía. Convertida en una ruta con versiones, pasa a ser una decisión operativa: se propone, se despliega a una fracción del tráfico, se mide contra el coste por respuesta útil y se acepta o se revierte en minutos. No has automatizado la elección; has abaratado el error, que es lo único que permite equivocarse a menudo y barato en lugar de poco y caro.

Lo que no viaja en el cambio

Conviene desactivar aquí una fantasía cómoda: que con una API común los modelos se sustituyen como piezas de recambio. La forma de la petición se normaliza; el comportamiento del modelo no. Cambiar de modelo mueve cosas que ninguna capa de compatibilidad puede alinear por ti.

Nada de esto es un argumento contra la portabilidad; es la definición precisa de lo que la portabilidad te da. No te regala la equivalencia entre modelos: te reduce el coste de probar si la hay. La parte mecánica del cambio pasa a costar minutos, y todo el presupuesto de esfuerzo se concentra donde de verdad está la incertidumbre, que es la evaluación. Un equipo portable no cambia de modelo sin pensar; cambia de modelo habiendo pensado solo en lo que importaba.

Aquí encajan las cuatro lecciones anteriores en una sola pieza. La observabilidad te da el criterio con el que juzgar el cambio; los metadatos te dan la dimensión sobre la que segmentarlo; el reparto porcentual te da la forma de probarlo sin arriesgar el producto entero; y el fallback te da la vuelta atrás cuando el experimento sale mal. Ninguna de las cuatro es interesante por separado, y juntas describen un ciclo completo: proponer, repartir, medir, quedarse o revertir. Eso es gobernar la IA, y es lo que da nombre a este nivel.