Hay una creencia instalada en la comunidad dev que dice que distribuir la inferencia de IA cerca del usuario es, por definición, bueno. Más velocidad, menos latencia, mejor experiencia. Y sí, en abstracto tiene sentido. El problema es que "distribuido" y "descentralizado" no son sinónimos, y hay una diferencia enorme entre los dos que se está perdiendo en todo el entusiasmo alrededor de Cloudflare AI Platform.
Cuando algo corre en 300 PoPs alrededor del mundo pero todo pasa por una sola empresa, con una sola política de uso, un solo punto de facturación y una sola decisión corporativa que puede cambiar las reglas de juego de un día para el otro... eso no es distribución. Eso es centralización con mejor latencia.
Y antes de que me digas que estoy siendo paranoico: recordá que ya hablamos de la opacidad en el uso de tokens de las herramientas IA. El patrón se repite.
Qué es exactamente la apuesta de Cloudflare en la Cloudflare AI Platform para agentes e inferencia
Cloudflare Workers AI no es nuevo. Llevan un tiempo con inferencia en el edge: modelos como Llama, Mistral, Phi corriendo en sus data centers distribuidos, accesibles mediante una API simple desde un Worker. La propuesta técnica es real y está bien ejecutada.
Pero lo que cambió en los últimos meses es el foco. Cloudflare dejó de hablar de "inferencia de IA" en general y empezó a hablar específicamente de agentes. Y eso cambia todo el análisis.
La arquitectura que están promoviendo tiene algunas piezas concretas:
Workers AI — El motor de inferencia en sí. Modelos corriendo en el edge, cerca del usuario, con latencias que en algunos casos son realmente impresionantes.
Durable Objects — El mecanismo para mantener estado entre llamadas. Si un agente necesita recordar qué hizo en el paso anterior, acá vive esa memoria.
Queues + Workflows — Orquestación de tareas asíncronas. El agente dispara trabajo, el trabajo se encola, otro Worker lo procesa. Razonablemente bien pensado.
AI Gateway — El proxy de observabilidad. Todo el tráfico de IA pasa por acá: logging, rate limiting, caché de respuestas, control de costos.
En papel, es una plataforma completa para construir sistemas agénticos. Y lo que más me llama la atención es que resuelve un problema real: hoy, si querés construir un agente con estado persistente, lógica de reintentos y observabilidad decente, estás pegando cuatro servicios distintos de cuatro proveedores distintos. Cloudflare ofrece eso integrado.
// Un agente básico corriendo en Cloudflare Workers
// La simplicidad es real — eso es parte del problema también
export default {
async fetch(request: Request, env: Env): Promise<Response> {
// La inferencia corre en el edge, cerca del usuario
const respuesta = await env.AI.run('@cf/meta/llama-3.1-8b-instruct', {
messages: [
{
role: 'system',
// El contexto del agente vive acá
content: 'Sos un agente que ayuda con análisis de código'
},
{
role: 'user',
content: await request.text()
}
],
// Control de tokens — importante para los costos
max_tokens: 1024
})
return Response.json(respuesta)
}
}
// Durable Object para mantener estado del agente entre turnos
export class AgenteConMemoria implements DurableObject {
private historial: Array<{role: string, content: string}> = []
constructor(private state: DurableObjectState, private env: Env) {}
async fetch(request: Request): Promise<Response> {
const { mensaje } = await request.json() as { mensaje: string }
// Recuperamos el historial persistido (sobrevive entre requests)
this.historial = await this.state.storage.get('historial') ?? []
// Agregamos el mensaje nuevo
this.historial.push({ role: 'user', content: mensaje })
// Inferencia con contexto completo
const respuesta = await this.env.AI.run('@cf/meta/llama-3.1-8b-instruct', {
messages: this.historial
})
const textoRespuesta = (respuesta as any).response
this.historial.push({ role: 'assistant', content: textoRespuesta })
// Persistimos el historial actualizado
await this.state.storage.put('historial', this.historial)
return Response.json({ respuesta: textoRespuesta })
}
}
Esto funciona. Lo probé. La latencia es notablemente mejor que ir a OpenAI desde Buenos Aires. El DX es bueno. El problema no está en la implementación técnica.
Los gotchas que nadie menciona cuando habla de Cloudflare AI Platform para agentes
Acá es donde me pongo en modo reflexivo, porque esto conecta con algo que aprendí a los golpes durante 30 años de infraestructura.
El modelo de precios es opaco cuando escala. Workers AI tiene un tier gratuito generoso. Pero los Durable Objects tienen su propia facturación. Las Queues también. El AI Gateway también. Cuando montás el stack completo para un agente en producción, el costo real no es la suma de los componentes — hay interacciones entre ellos que te van a sorprender. Ya hablé de la opacidad en el consumo de tokens, y acá el problema se multiplica porque tenés múltiples recursos facturándose en paralelo.
Vendor lock-in con sabor a plataforma abierta. Los Workers se ven como JavaScript estándar. Los modelos son open source. Pero la integración entre Workers AI + Durable Objects + Queues es específica de Cloudflare. Si mañana decidís migrar, no estás migrando código — estás rediseñando arquitectura. Eso tiene un costo que no aparece en ninguna calculadora de precios.
Los modelos disponibles no son los mejores modelos. Workers AI corre modelos cuantizados, optimizados para correr en el edge. Llama 3.1 8B cuantizado no es lo mismo que Llama 3.1 70B en full precision. Para muchos casos de uso de agentes — especialmente los que involucran razonamiento complejo, planificación de múltiples pasos, o decisiones con consecuencias reales — la diferencia importa. Mucho.
La privacidad tiene matices que hay que leer fino. Cloudflare tiene políticas de uso razonables y no dice que va a entrenar con tus datos. Pero "razonables" no es lo mismo que "garantizadas legalmente". Si tu agente procesa información sensible, recordá lo que ya analizamos sobre el privilegio legal de las conversaciones con IA — la capa de dónde corre la inferencia no resuelve el problema de qué pasa con esos datos.
La observabilidad es buena pero el control es limitado. AI Gateway te da logs, métricas, caché. Excelente. Pero si Cloudflare decide cambiar cómo funciona el rate limiting, o deprecar un modelo, o ajustar los límites del tier gratuito, vos te enterás cuando ya está hecho. Centralizar la inferencia significa centralizar también ese riesgo operacional.
// Lo que parece simple tiene capas de dependencia ocultas
// Este código "inocente" te ata a: Workers Runtime, AI Binding,
// Durable Objects API, Cloudflare Storage — todo junto
export class AgentePeligrosamenteSimple implements DurableObject {
constructor(private state: DurableObjectState, private env: Env) {}
async fetch(request: Request): Promise<Response> {
// Cada una de estas líneas es Cloudflare-specific
// No hay abstracción que te permita swapear el provider
const memoria = await this.state.storage.get('estado')
const inferencia = await this.env.AI.run('...', { messages: [] })
await this.state.storage.put('estado', inferencia)
// Esto no corre en ningún otro lado sin reescritura significativa
return Response.json(inferencia)
}
}
Lo que me genera la incomodidad más específica es esto: los agentes que valen la pena — los que van a tener impacto real — van a tomar decisiones con consecuencias. Enviar un email, ejecutar una transacción, modificar un sistema externo. Y concentrar la inferencia que alimenta esas decisiones en una sola plataforma, con los límites de control que describí, es una decisión de arquitectura con implicancias de seguridad que van mucho más allá del compliance de superficie.
No es que Cloudflare sea malicioso. Es que la concentración de riesgo es un problema estructural independientemente de las intenciones del proveedor.
FAQ: Lo que la gente realmente pregunta sobre Cloudflare AI Platform y agentes
¿Cloudflare Workers AI puede reemplazar a OpenAI para agentes en producción?
Depende del caso de uso. Para tareas que requieren modelos potentes (GPT-4 level), todavía no — los modelos disponibles en Workers AI son capaces pero tienen limitaciones de razonamiento en comparación. Para tareas más simples, clasificación, extracción de información, generación de texto estructurado, funciona bien y con latencia mejor. El tradeoff real es capacidad vs. latencia vs. vendor lock-in, y esa ecuación la tenés que resolver vos para tu caso específico.
¿Los Durable Objects son una buena solución para el estado de agentes a largo plazo?
Son una solución sólida para estado conversacional de corto y mediano plazo. Para memoria de largo plazo de agentes (recordar información de conversaciones de hace semanas o meses, hacer búsqueda semántica sobre historial), los Durable Objects solos no alcanzan — necesitás combinarlos con Vectorize (el servicio de vector DB de Cloudflare) o una solución externa. Lo cual, de nuevo, agrega capas al lock-in.
¿Qué pasa con mis datos cuando proceso información sensible a través de Workers AI?
Cloudflare afirma no usar datos de Workers AI para entrenar modelos. Pero "afirma" y "garantiza contractualmente con consecuencias legales" son cosas distintas. Si procesás datos de salud, datos financieros o cualquier cosa regulada, necesitás leer los términos de servicio en detalle y probablemente consultar con alguien que entienda las implicancias legales en tu jurisdicción. Ya vimos que las conversaciones con IA tienen menos protección legal de la que asumimos.
¿Tiene sentido usar Cloudflare AI Platform si ya estoy usando Vercel AI SDK?
Pueden coexistir, pero el stack se complica. Vercel AI SDK abstrae providers de inferencia razonablemente bien. Workers AI es uno de esos providers. Pero si empezás a usar Durable Objects para estado, estás fuera del mundo Vercel. En la práctica, la gente que usa Workers AI para inferencia tiende a usar el resto del stack de Cloudflare también, porque la integración es el valor real. Si ya tenés inversión en Vercel, pensá bien si el beneficio de latencia justifica la complejidad adicional.
¿Cloudflare AI Gateway realmente ayuda a controlar los costos de tokens?
Sí, genuinamente. El caché de respuestas es útil para queries repetitivas (frecuentes en agentes que hacen las mismas llamadas de herramientas). El rate limiting ayuda a evitar sorpresas en la factura. El logging te da visibilidad real sobre qué está consumiendo qué. Es una de las partes más sólidas de la propuesta. El catch es que te da visibilidad sobre el consumo dentro de Cloudflare — si tu agente también llama a APIs externas (OpenAI, Anthropic, etc.) a través del gateway, también las captura, lo cual es útil.
¿Cuándo SÍ tiene sentido apostar fuerte a Cloudflare como capa de inferencia para agentes?
Cuando la latencia es crítica y los usuarios están globalmente distribuidos. Cuando los modelos disponibles son suficientes para el caso de uso. Cuando el equipo ya vive en el ecosistema Cloudflare. Cuando el volumen de requests es alto y el caché del AI Gateway puede generar ahorro real. Y cuando tenés claridad sobre los tradeoffs de lock-in y los aceptás conscientemente — no porque no los viste, sino porque para tu contexto específico el valor supera el riesgo.
Mi posición después de darle vueltas durante semanas
Me pasó algo parecido a lo que describí con la inferencia local: la alternativa que parece obvia tiene limitaciones que no aparecen en el pitch inicial. Con Cloudflare, el pitch es "inferencia distribuida y cercana al usuario para tus agentes". Lo que no aparece en ese pitch es la concentración de riesgo, los límites de los modelos disponibles y la profundidad del lock-in.
Nada de esto significa que Cloudflare AI Platform sea una mala opción. Significa que es una opción con tradeoffs específicos que necesitás entender antes de construir tu arquitectura de agentes sobre ella.
Lo que me genera más incomodidad — y esto es genuino, no FUD — es que el ecosistema de agentes todavía está en una etapa donde no tenemos buenas herramientas de curación para saber qué funciona y qué es hype. En ese contexto, una plataforma que te ofrece integración completa y DX excelente tiene una ventaja de adopción enorme. Y cuando algo tiene ventaja de adopción enorme en una etapa temprana, tiende a volverse estándar de facto aunque no sea la mejor opción técnica a largo plazo.
Voy a seguir experimentando con Cloudflare AI Platform para casos específicos. La latencia es real, el DX es real, algunas piezas como AI Gateway son genuinamente útiles. Pero mi arquitectura de agentes no va a depender exclusivamente de ningún proveedor single hasta que el espacio madure lo suficiente como para que pueda evaluar las opciones con más claridad.
Esa es la lección que aprendí tirando servidores de producción con rm -rf a los 19 años: los sistemas que parecen sólidos desde afuera tienen puntos de falla que solo encontrás cuando algo sale mal. Y con los agentes tomando decisiones con consecuencias reales, prefiero distribuir ese riesgo antes de que tengamos que aprender la lección a los golpes.
¿Estás construyendo agentes sobre Cloudflare? Me interesa saber con qué te encontraste en producción — los casos reales siempre son más informativos que los benchmarks.
Este artículo fue publicado originalmente en juanchi.dev
