Hay una decisión de precios silenciosa incorporada en cada producto de GPU en la nube, y la mayoría de los equipos la paga sin darse cuenta: se le cobra por que la GPU esté caliente y en espera, no por el trabajo que realmente hace. La inferencia en tiempo real necesita eso. Un trabajo por lotes a las 3 de la madrugada, no. La brecha entre esos dos mundos es de aproximadamente 10x en costo.
Esta publicación explica qué significa realmente la inferencia asíncrona por lotes, las cargas de trabajo donde encaja y la aritmética de costos que la convierte en la decisión correcta cuando la respuesta por debajo del segundo no está en la ruta crítica.
Qué significa realmente "asíncrono por lotes".
La inferencia en tiempo real es una solicitud — la GPU está caliente, el modelo cargado, el worker reservado y la respuesta regresa en streaming en milisegundos. Usted paga por que la GPU esté lista, sin importar si su solicitud llega justo en ese segundo o no.
La inferencia asíncrona por lotes invierte el modelo. Usted envía un trabajo y recibe un ID de trabajo. El trabajo entra en una cola. El planificador lo asigna a un worker disponible — uno que de todos modos no iba a usarse en ese momento —, el worker toma el trabajo, lo ejecuta y devuelve el resultado. Usted recupera el resultado mediante webhook o consulta periódica.
De extremo a extremo, normalmente verá de 30 segundos a 5 minutos por trabajo bajo carga normal. Para una carga de trabajo que se ejecuta de noche o fuera de la ruta crítica del usuario, esa latencia es invisible. Para una carga de trabajo donde una persona está esperando la respuesta ahora mismo, no es la herramienta adecuada.
Cargas de trabajo que encajan.
El patrón es "ninguna persona está esperando este resultado concreto en tiempo real". Eso abarca mucho más de lo que la gente suele suponer:
- Procesamiento de documentos. Resumir decenas de miles de PDF, extraer estructura de contratos, normalizar la salida de OCR. Envíelo a las 11 de la noche y los resultados estarán listos para la reunión de la mañana.
- Enriquecimiento de conjuntos de datos. Clasificar, etiquetar, generar embeddings y puntuar registros a escala de almacén de datos. Webhook de vuelta al pipeline de ETL.
- Generación de contenido a escala. Resúmenes personalizados, informes, traducciones. Envíe 10,000 trabajos en una hora y recíbalos en unas pocas horas.
- Investigación y experimentación. Cuadrículas de modelo × prompt × conjunto de datos. Sin reservas, sin tiempo de arranque, sin gasto ocioso entre ejecuciones.
- Pipelines de automatización. Pasos con LLM en Airflow, Temporal, n8n. Reintentos idempotentes, recibos firmados, ejecución en cola.
- Procesamiento nocturno. Cualquier cosa cuya fecha límite sea "antes de que empiece la jornada laboral" y no "antes de que este usuario se vaya".
Si su carga de trabajo está en esta lista, es candidata para el procesamiento por lotes.
Cargas de trabajo que no encajan.
Conviene ser claros sobre el límite:
- Chat de cara al usuario. Un chatbot necesita empezar a transmitir tokens en menos de un segundo. No ponga un trabajo en cola delante de una conversación.
- Autocompletado interactivo. Completado de código, búsqueda mientras se escribe, cualquier cosa donde los milisegundos importan.
- Bucles de control en tiempo real de misión crítica. Monitoreo en vivo, puntuación de fraude en el pago de un usuario, cualquier cosa donde un retraso tenga una consecuencia en el mundo real.
Para estos casos, use un proveedor de inferencia en tiempo real. La prima paga garantías de capacidad, y usted realmente las necesita.
Los cálculos de costo.
Tomemos un ejemplo concreto. Llama 3.1 8B, 1,000 tokens de salida por trabajo, 100,000 trabajos al mes.
| Modelo de proveedor | Costo por trabajo | Factura mensual |
|---|---|---|
| Inferencia serverless en una nube principal | ~$0.15 | ~$15,000 |
| GPU dedicada reservada (H100, mes completo) | n/a | ~$3,500 base + su costo operativo |
| MicroDC.ai asíncrono por lotes | ~$0.011 | ~$1,100 |
La GPU dedicada es más barata que serverless si logra mantenerla utilizada. La mayoría de los equipos no puede — necesitaría un flujo constante de ~30 trabajos por minuto, todo el mes, sin margen para redespliegues, cambios de modelo o mantenimiento. Empíricamente, los clientes con GPU dedicada operan al 15–40% de utilización, lo que significa que el costo efectivo por trabajo es de 2–6x la tarifa anunciada.
La cifra del procesamiento asíncrono por lotes es el costo por trabajo en un mercado. No paga entre trabajos. No paga por que el worker esté caliente. No paga por la carga del modelo. Paga por el trabajo que se ejecutó. Con 100k trabajos al mes, eso es aproximadamente un orden de magnitud más barato que serverless y competitivo con la GPU dedicada incluso con utilización perfecta — sin que usted tenga que administrar la GPU.
¿Y los picos de carga?
Una preocupación legítima sobre el procesamiento por lotes es el tiempo de espera variable bajo carga. Si la cola se acumula, sus trabajos tardan más. Dos cosas ayudan:
Primero, la cola es multirregión y multiworker. Una avalancha de trabajos de un cliente no se atasca en una sola GPU; se reparte entre el conjunto disponible. El sistema escala horizontalmente con la red de workers.
Segundo, el procesamiento por lotes es para cargas de trabajo donde no necesita un SLA de latencia estricto. Si envía 10,000 trabajos y tardan tres horas en lugar de dos, normalmente eso está bien para un caso de uso por lotes. Si no lo está, tiene una carga de trabajo en tiempo real, no por lotes — elija la herramienta correcta.
Para cargas de trabajo que a veces necesitan tiempo real y a veces pueden esperar, el patrón correcto son dos proveedores: una API en tiempo real para la ruta de cara al usuario y una cola por lotes para todo lo demás. En la práctica, la mayor parte de los costos de LLM está en ese "todo lo demás".
Enviar su primer lote.
En la práctica, el procesamiento asíncrono por lotes en MicroDC.ai es una llamada a la API:
from microdc import Client, LLMCall
client = Client(api_key=os.environ["MICRODC_API_KEY"])
job = LLMCall(model="llama-3.1-8b")
job.add_user_message("Summarize the attached contract...")
job_id = client.send_job(job, callback_url="https://your-api.example.com/done")Repita eso en un bucle sobre su conjunto de entrada y tendrá un lote. Añada un manejador de webhook en la URL de callback y se olvida del asunto. O prescinda del callback y consulte con client.wait_for_job(job_id).
Para código con forma de OpenAI, el mismo patrón funciona a través de nuestro endpoint compatible con OpenAI — envíe una chat completion de forma síncrona y el trabajo pasa por la misma cola asíncrona por debajo.
La conclusión.
La inferencia en tiempo real es cara porque usted paga por una garantía. La mayoría de las cargas de trabajo con LLM a escala no necesitan esa garantía — necesitan la respuesta dentro de un plazo razonable, con el costo por trabajo como objetivo de optimización. Para esas cargas de trabajo, el procesamiento asíncrono por lotes es la forma correcta, y la diferencia de precio es lo bastante grande como para importar en cualquier volumen significativo.
Audite su factura. Si una fracción significativa corresponde a procesos nocturnos, programados, en cola o de algún otro modo no interactivos, esa es la parte que debería ejecutarse de forma asíncrona en una red distribuida.