Capítulo 8: Inferencia por lotes y asíncrona

Visión general#

Un pipeline de análisis de feedback clasifica miles de comentarios cada noche. Nadie lee el informe hasta la mañana siguiente, y aun así la aplicación puede estar usando el mismo modo de API en tiempo real que un asistente de cara al cliente.

Algunos proveedores aplican descuentos a la inferencia diferida, pero conviene separar tres cosas: la ejecución asíncrona, las Batch APIs de los proveedores y el batching de inferencia a nivel de GPU.

Un worker en segundo plano que llama a la API estándar es asíncrono para tu usuario, pero puede seguir pagando el precio estándar por token. La Batch API de un proveedor puede ofrecer una tarifa más baja para peticiones no urgentes. El batching continuo dentro de un motor de serving mejora el rendimiento (throughput) y no tiene nada que ver con los descuentos de la API.

Práctica#

Empieza por el plazo del producto. El soporte interactivo suele necesitar segundos; el procesamiento de documentos históricos puede tolerar horas. Los pasos dependientes de un agente limitan lo que puedes diferir, porque una acción posterior no se puede enviar hasta que el paso anterior produzca sus entradas.

Google, OpenAI y Anthropic documentan cada uno un modo por lotes con descuento para peticiones que pueden esperar, con resultados devueltos dentro de una ventana de entrega. En el momento de esta edición, Google indica una reducción de precio del 50 % para el uso elegible de la Gemini Batch API y un objetivo de entrega de 24 horas. Los descuentos, las ventanas y los modelos elegibles varían según el proveedor y cambian con el tiempo, así que revisa las condiciones vigentes de cada modelo y endpoint antes de contar con ellas.

Con un precio estándar hipotético de 0,012 $ por tarea, 500.000 tareas cuestan 6.000 $. Un modo por lotes elegible con una salida equivalente a mitad de precio cuesta 3.000 $ en cargos de inferencia. El ahorro neto puede quedarse por debajo de 3.000 $ cuando cuentas la gestión de los trabajos, las peticiones fallidas o caducadas, los reenvíos y cualquier trabajo que siga necesitando ejecución inmediata.

Haz el seguimiento de cada elemento del lote por separado, para poder reparar un trabajo que ha fallado en parte sin reenviar el lote entero. La sección En profundidad, más abajo, cubre los detalles.

Ledgerline. Una cuarta parte de las facturas de Ledgerline llega en importaciones masivas mensuales que nadie lee hasta la mañana siguiente. Ahora pasan por el modo por lotes del proveedor a mitad de precio, con cada factura seguida por su propio ID. Esa cuarta parte costaba 162 $ de los 648 $, así que la mitad de precio ahorra 81 $ y la extracción se queda en 567 $ al mes.

En profundidad#

En la inferencia autoalojada, el batching es una técnica de rendimiento: el motor de serving intercala peticiones de distinta longitud para que la GPU siga ocupada. La ganancia depende de la carga de trabajo, de la presión sobre la KV cache y del presupuesto de latencia, y Economía de la inferencia en GPU y del despliegue cubre la mecánica.

Un mejor rendimiento reduce el coste asignado a cada tarea, pero la factura de capacidad sigue siendo la misma salvo que el cambio te permita reducir o evitar capacidad.

El procesamiento por lotes también se combina con la caché y la deduplicación. Si solo cambió el 5 % de los documentos de ayer, saltarte los que no han cambiado puede ahorrar más que el descuento del precio por lotes.

Ejecutar trabajos por lotes del proveedor#

Antes de enviar, escribe cada elemento en tu propio almacén con su ID de aplicación, un hash de la entrada, el modelo y la versión del prompt, el ID de trabajo del proveedor y un estado como pending, submitted, succeeded, failed o expired. Pon el ID de aplicación en el campo de identificador personalizado de la petición cuando la API lo ofrezca, y úsalo para cruzar los resultados con tus registros. Un fichero de resultados puede volver en un orden distinto al de la entrada, y pueden faltar algunos elementos.

Un trabajo terminado puede contener elementos correctos, elementos que devolvieron un error y elementos que caducaron antes de que el proveedor los procesara. Trata cada uno por separado. Una petición mal formada o una entrada que supera el límite de contexto volverá a fallar si no la cambias, así que corrígela o descártala. Los elementos caducados, los errores de rate limit (límite de tasa) y los errores transitorios del servidor sí merecen un reenvío.

Pon los elementos reintentables en un trabajo nuevo que conserve los ID de aplicación originales, y deja en paz los que han ido bien. Limita los intentos por elemento, por ejemplo a dos reenvíos, y después pasa lo que siga fallando a una cola de revisión. Sin límite, un fallo sistemático, como una plantilla de prompt que siempre supera el límite de contexto, sigue generando trabajos nuevos.

Haz que el procesamiento posterior sea idempotente. Un worker puede caerse después de leer un fichero de resultados y volver a leerlo, y un elemento que reenviaste tras un timeout puede seguir produciendo un resultado del primer intento. Escribe los resultados con un upsert cuya clave sea el ID de aplicación y la versión del prompt, y haz que los consumidores se salten los ID que ya han tratado. Un resultado duplicado cuesta entonces tokens, pero no crea un segundo ticket, correo o fila en la base de datos.

Cuenta todo lo que ha costado el trabajo. Incluye los cargos de los elementos cuya salida descartaste, los cargos de cada reenvío y cualquier elemento que pasaste a la API en tiempo real a precio estándar. Divide ese total entre el número de elementos que produjeron un resultado utilizable. Esa es la cifra que hay que comparar con el procesamiento en tiempo real y, con una tasa de fallos alta, puede quedar muy por encima del precio por lotes anunciado.

Decide qué pasa con los elementos que no llegan al plazo antes de que se ejecute el primer trabajo. Si el informe de la mañana tiene que estar a las 08:00 y la ventana del proveedor permite hasta un día, un trabajo enviado a medianoche puede no terminar a tiempo. Las opciones son mandar los elementos tardíos a la API en tiempo real, publicar el informe con esos elementos marcados como pendientes u omitirlos cuando los datos vayan a estar desfasados de todos modos. Cada opción tiene un coste distinto, así que el responsable de producto debería elegir una y el pipeline debería implementarla de forma explícita.

Referencias: Gemini Batch API, Modos de optimización de Gemini, OpenAI Batch API, Procesamiento por lotes de Anthropic.