Cloudflare Workers AI se ha convertido en una de esas piezas que cambian el cálculo mental de muchos equipos: en lugar de levantar infraestructura, desplegar GPUs o pelearse con escalado, se puede exponer una API en el edge (Workers) que llama a modelos de IA ya disponibles en la plataforma —y pagar por uso con una métrica unificada (neurons) y un catálogo amplio de modelos.
La parte más llamativa es que, en el propio Worker, no hace falta “gestionar” claves de terceros ni SDKs complejos: se usa un binding (env.AI.run(...)) y listo. El resultado es un patrón muy práctico: microservicios de IA que nacen y mueren rápido, baratos de operar y fáciles de integrar con el resto del stack (KV, R2, D1, Durable Objects, etc.).
1) Ejemplo real: API de generación de imágenes en ~10 líneas
Un Worker mínimo que recibe un prompt y devuelve un PNG (usando un modelo tipo FLUX “schnell”) puede quedar así:
export default {
async fetch(req, env) {
const { prompt, steps = 4 } = await req.json();
const out = await env.AI.run("@cf/black-forest-labs/flux-1-schnell", { prompt, steps });
const bytes = Uint8Array.from(atob(out.image), c => c.charCodeAt(0));
return new Response(bytes, { headers: { "content-type": "image/png" } });
}
}
Y el binding en wrangler.toml es igual de directo:
[ai]
binding = "AI"
Eso ya permite montar una demo (o una API interna) para: generar banners para un blog, creatividades para un ecommerce, “placeholders” para prototipos, o imágenes para pruebas A/B sin depender de pipelines pesados.
¿De dónde sale el coste de “$0,000318 por imagen 1.280×720”?
En el caso de @cf/black-forest-labs/flux-1-schnell, Cloudflare publica un precio por tile de 512×512 y otro por step. El precio por tile es $0,0000528. Una imagen de 1.280×720 “ocupa” 3 tiles en ancho (1.280/512 ≈ 2,5 → 3) y 2 en alto (720/512 ≈ 1,4 → 2): en total 6 tiles.
Solo la parte de tiles ya da: 6 × $0,0000528 = $0,0003168, que redondeado es $0,000317–$0,000318. En la práctica, el coste final puede subir según los steps (y otros parámetros del modelo), porque el propio modelo también publica coste por step. Es decir: el número cuadra, pero conviene entenderlo como una referencia “mínima” por tamaño, y no como un precio fijo universal.
2) Ejemplo real: API barata de resumen y extracción (ideal para backoffice)
Workers AI también publica precios por tokens (entrada/salida) para modelos de texto. Por ejemplo, hay variantes optimizadas (FP8 “fast”) pensadas para latencia y coste.
Un Worker típico para resumir un texto (o extraer campos en JSON) puede ser:
export default {
async fetch(req, env) {
const { text } = await req.json();
const r = await env.AI.run("@cf/meta/llama-3.1-8b-instruct-fp8-fast", {
messages: [
{ role: "system", content: "Resume en 5 puntos, claro y accionable." },
{ role: "user", content: text }
]
});
return Response.json(r);
}
}
Coste orientativo (para hacerse una idea): si una petición consume ~1.000 tokens de entrada y genera ~300 tokens de salida, con precios por millón de tokens el cálculo sale en fracciones de milésima de dólar por llamada. Esto abre casos de uso de “IA de utilidad” que antes eran difíciles de justificar en coste.
3) Ejemplo real: buscador semántico (embeddings) para documentación, tickets o runbooks
Otro patrón muy “sysadmin-friendly” es embeddings + búsqueda semántica: indexar documentación interna (procedimientos, postmortems, runbooks) y responder con contexto.
Workers AI publica modelos de embeddings con precios por tokens, pensados para indexación masiva. El flujo típico sería:
- generar embedding del texto,
- guardarlo en una base vectorial (por ejemplo, Cloudflare Vectorize),
- recuperar los chunks más cercanos cuando el usuario pregunta,
- pasar esos chunks a un modelo de texto para responder.
La clave aquí es que el coste de embeddings suele ser muy bajo por volumen, y se paga una vez al indexar; después, la consulta recupera contexto y el LLM solo “redacta”.
Lo importante: cómo se paga y por qué esto escala bien
Workers AI usa neurons como unidad de cómputo (además de mostrar equivalencias por tokens en muchos modelos). En plan Free y Paid hay una asignación diaria de neurons, y el plan Paid cobra por cada 1.000 neurons adicionales. Esto simplifica la contabilidad: no es “GPU por hora”, es “pago por inferencia real”.
Además, el plan Paid de Workers tiene un mínimo mensual y una estructura pensada para que muchos proyectos pequeños no se disparen en costes solo por tráfico irregular.
Preguntas frecuentes
¿Cómo calcular el coste real de generar imágenes con Workers AI según la resolución?
La documentación de precios publica el coste por tiles (por ejemplo, 512×512) y, en algunos modelos, también por steps. Para resoluciones tipo 1.280×720 conviene convertir a tiles (ceil(ancho/512) × ceil(alto/512)) y sumar el componente adicional si el modelo tarifa por steps.
¿Se puede montar una API de IA en Cloudflare Workers sin gestionar claves de terceros?
Sí. Dentro del Worker se usa el binding (env.AI.run) y no se necesita API key de un proveedor externo. La autenticación y el despliegue dependen de la cuenta de Cloudflare y el flujo habitual con Wrangler.
¿Qué casos de uso tienen más sentido para administradores de sistemas?
Resumen y clasificación de alertas, normalización de logs, extracción de campos de tickets, generación de runbooks, embeddings para búsqueda semántica en documentación interna, y “colas” de trabajo con Durable Objects para tareas de IA bajo demanda.
¿Qué modelos suelen ser más rentables para producción: grandes o “fast/quantized”?
Para tareas operativas (resúmenes, extracción, routing, soporte interno), los modelos optimizados (FP8/quantizados) suelen dar mejor equilibrio entre coste, latencia y calidad. Los modelos grandes brillan cuando el razonamiento y la redacción importan más que el coste por llamada.
Fuentes:
- Cloudflare Workers AI – Pricing
- Cloudflare Workers AI – Model: flux-1-schnell
- Cloudflare Workers AI – Bindings (env.AI.run / wrangler.toml)
