Coste y límites: neurons, rate limits y cuándo salir fuera

La pregunta que decide si un proyecto con IA sobrevive al contacto con la realidad no es cuál es el mejor modelo, sino cuánto cuesta cada invocación y cuántas caben por minuto. Workers AI responde a la primera con una unidad propia, el neuron, que unifica modalidades que de otro modo serían incomparables; y a la segunda con límites por modelo que conviene conocer antes de que un pico de tráfico te los enseñe. Y cuando ninguna de las dos respuestas encaja con lo que necesitas, existe una tercera decisión perfectamente legítima: salir de la plataforma, con criterio.

Neurons: una unidad para modalidades incomparables

Facturar por tokens funciona mientras todo sea texto, y se rompe en cuanto no lo es. ¿Cuántos tokens tiene una imagen generada? ¿Y un minuto de audio transcrito? ¿Cómo se compara un embedding de un párrafo con seiscientas palabras redactadas por un modelo de setenta mil millones de parámetros? Los tokens no sirven como moneda común porque no significan lo mismo en cada modalidad.

El neuron resuelve eso convirtiéndose en una medida de trabajo de GPU, no de contenido. Cada modelo tiene una tarifa expresada en neurons por unidad de su propia modalidad: neurons por millón de tokens de entrada y de salida en los modelos de texto, neurons por segundo de audio en la transcripción, neurons por imagen o por paso de difusión en la generación visual. La consecuencia práctica es que un único número resume el gasto de un sistema que mezcla cuatro tipos de inferencia distintos, y que puedes comparar directamente lo que te cuesta indexar un corpus con lo que te cuesta contestar una pregunta.

Sobre esa unidad se monta un modelo de facturación de asignación diaria más excedente: hay una cantidad de neurons incluida cada día, y a partir de ahí se cobra por cada mil neurons consumidos. El plan gratuito ofrece esa asignación diaria como techo duro, lo que lo hace excelente para prototipar y desaconsejable para producción, porque agotarla significa quedarse sin inferencia hasta el día siguiente. Verifica siempre las cifras vigentes en la documentación antes de construir un presupuesto sobre ellas.

Lo que sí conviene interiorizar, más allá de las cifras concretas, son los órdenes de magnitud relativos entre familias, porque son bastante estables y determinan el diseño mucho antes que el precio exacto.

Leer esa tabla con atención evita los dos errores de presupuesto más caros que se cometen al empezar. El primero es temer al coste de los embeddings y acabar recuperando peor de lo necesario: indexar es barato, y casi siempre merece la pena trocear fino y guardar de más. El segundo es tratar la generación de imágenes como una llamada más dentro de un manejador fetch, cuando su perfil de coste y latencia pide a gritos vivir en una cola con notificación posterior.

Las palancas para bajar ese número son casi siempre las mismas cuatro, y ninguna requiere renunciar a nada esencial. Elegir el modelo más pequeño que resuelva la tarea es la que más ahorra, con diferencia de un orden de magnitud. Poner un max_tokens ajustado impide que una respuesta se vaya por las ramas a tu costa. Recortar el contexto —truncar el historial, no inyectar documentos enteros cuando basta un fragmento— ataca la entrada, que en las tareas de tipo RAG suele dominar el gasto. Y cachear las respuestas de peticiones repetidas convierte una inferencia en una lectura, que es gratis.

Los límites: peticiones por minuto y tamaño

Además del coste hay un techo de ritmo. Cada modelo tiene su propio límite de peticiones por minuto, y no es el mismo para todos: los modelos de embeddings, que son ligeros, admiten un caudal muy superior al de un modelo grande de texto o al de un difusor de imágenes, que ocupan la GPU durante mucho más tiempo por invocación. Cuando lo rebasas, la llamada devuelve un 429 y hay que estar preparado.

La forma correcta de absorber un 429 no es un reintento inmediato, que solo empeora la congestión, sino una espera que crece con cada intento y lleva un poco de ruido aleatorio para que mil clientes no reintenten a la vez.

async function inferir(env: Env, modelo: string, entradas: object, intentos = 3) {
  for (let i = 0; i < intentos; i++) {
    try {
      return await env.AI.run(modelo, entradas);
    } catch (error) {
      const esRitmo = String(error).includes("429");
      if (!esRitmo || i === intentos - 1) throw error;
      const espera = 2 ** i * 250 + Math.random() * 200;
      await new Promise((r) => setTimeout(r, espera));
    }
  }
}

Pero el patrón que de verdad escala no es reintentar más, sino no llamar tanto. Si la inferencia no tiene que ocurrir mientras alguien espera, sácala del camino de la petición: encola el trabajo, procésalo con el consumidor a un ritmo que tú controlas, y notifica al terminar. Una cola convierte un pico de tráfico que habría reventado el límite en una fila ordenada que lo respeta sin perder ni una tarea.

La segunda palanca es no repetir trabajo idéntico. Un porcentaje sorprendente de las inferencias de un sistema real son la misma entrada preguntada otra vez: la misma pregunta frecuente, el mismo documento reprocesado, el mismo texto clasificado dos veces por un reintento del cliente. Una caché con clave derivada del modelo y de las entradas convierte esas repeticiones en lecturas instantáneas y gratuitas, y de paso las saca de la cuenta del límite por minuto.

const clave = modelo + ":" + await hash(JSON.stringify(entradas));
const guardado = await env.CACHE_IA.get(clave, "json");
if (guardado) return guardado;

const salida = await env.AI.run(modelo, entradas);
ctx.waitUntil(env.CACHE_IA.put(clave, JSON.stringify(salida), { expirationTtl: 86400 }));
return salida;

Conviene aplicarla con cabeza: cachear tiene sentido cuando la misma entrada debe producir la misma salida, es decir, con temperature baja y tareas deterministas como clasificar, extraer o generar embeddings. Para una redacción creativa donde la variedad es parte del valor, la caché estropea el producto en lugar de mejorarlo.

Cuándo conviene un proveedor externo

Workers AI no es la respuesta a todo, y reconocer sus fronteras es señal de criterio y no de deslealtad. Hay cuatro situaciones en las que salir fuera es lo correcto: cuando necesitas la capacidad de razonamiento de un modelo de frontera que no está en el catálogo, cuando tu tarea exige una ventana de contexto muy superior a la que ofrecen los modelos disponibles, cuando dependes de capacidades específicas de un proveedor concreto, o cuando tienes un modelo propio entrenado desde cero que solo puede correr en tu infraestructura.

flowchart TD
N[Necesito inferencia] --> A{Esta la tarea cubierta por el catalogo}
A -->|Si| B{Basta la calidad del modelo disponible}
A -->|No| X[Proveedor externo via AI Gateway]
B -->|Si| W[Workers AI con binding]
B -->|No| C{Es critica esa diferencia}
C -->|No| W
C -->|Si| X
W --> G[AI Gateway para cache y observabilidad]
X --> G
style W fill:#a6e3a1,color:#11111b
style X fill:#fab387,color:#11111b
style G fill:#89b4fa,color:#11111b

La decisión, además, no es binaria y casi nunca debería serlo. Lo habitual en un sistema maduro es una arquitectura de dos niveles: los modelos pequeños del catálogo se ocupan del volumen —clasificar, extraer, generar embeddings, resumir, filtrar—, que es donde está el noventa por ciento de las invocaciones y donde el coste se acumula, y un modelo de frontera externo atiende la fracción minoritaria de peticiones que de verdad exigen su calidad. Eso mantiene la factura bajo control sin renunciar al techo de calidad donde importa.

La pieza que hace viable esa mezcla es AI Gateway, el tema del nivel siguiente. Puesto delante de ambos caminos te da caché de respuestas repetidas, límites de ritmo propios, reintentos, rutas de reserva hacia otro proveedor cuando uno falla, y una analítica unificada de coste y latencia. Con él, cambiar de proveedor deja de ser una reescritura y pasa a ser una configuración, que es exactamente donde quieres que viva una decisión que va a cambiar varias veces.

Observar el gasto antes de que te observe a ti

Un presupuesto estimado a mano sirve para decidir si una idea es viable; no sirve para saber qué está pasando en producción. Para eso hace falta instrumentar, y la instrumentación útil no mide el total —eso ya te lo dice el panel— sino la atribución: qué función de tu aplicación consume qué parte del gasto.

La forma más directa es registrar cada inferencia con las dimensiones que después querrás cruzar. Analytics Engine encaja bien aquí porque está pensado justo para esto: escrituras baratas desde el Worker, agregación después.

async function inferirMedido(env: Env, tarea: string, modelo: string, entradas: object) {
  const inicio = Date.now();
  const salida = await env.AI.run(modelo, entradas);

  env.METRICAS.writeDataPoint({
    blobs: [tarea, modelo],                      // por que funcion y con que modelo
    doubles: [Date.now() - inicio],              // cuanto tardo
    indexes: [tarea],                            // la dimension por la que agregar
  });

  return salida;
}

Con eso puedes contestar preguntas que sin ellas son puras conjeturas: si el gasto se concentra en una funcionalidad que apenas usa nadie, si un cambio de modelo mejoró la latencia de verdad, si el pico del martes fue tráfico legítimo o un bucle mal cerrado, o si el prompt que alargaste la semana pasada duplicó el coste de la ruta más transitada.