Reduzca los costos de API de LLM con trabajos por lotes y almacenamiento en caché rápido: un manual práctico

Muchos equipos pagan de más por las API de LLM porque envían cada solicitud a través de la misma ruta sincrónica. Esto es apropiado para chat, asistentes de codificación, agentes de soporte, flujos de pago y cualquier cosa que esté esperando a un usuario. Es un desperdicio para evaluaciones, etiquetado, enriquecimiento, barridos de moderación, incrustación de rellenos, informes nocturnos y preprocesamiento de contenido.

La pregunta práctica no es "¿Qué modelo es más barato?" Es: ¿qué trabajo realmente necesita una respuesta inmediata y qué trabajo puede esperar? Una vez que responda a eso, el control de costos de la API de IA se convierte en un flujo de trabajo de ingeniería: clasificar el tráfico, enviar trabajos tolerantes a la latencia al procesamiento por lotes cuando sea compatible, estructurar solicitudes repetidas para el almacenamiento en caché y medir los ahorros reales después de fallas, reintentos y gastos generales operativos.

Comience con una auditoría de costos por carga de trabajo, no por modelo

Antes de cambiar la arquitectura, exporte una muestra del uso reciente de API y agrúpela por carga de trabajo. Una tabla de auditoría útil debe incluir:

• Punto final y modelo: finalizaciones de chat, respuestas, incrustaciones, moderación o puntos finales específicos del proveedor.
• Tokens de entrada y salida promedio: separe las indicaciones largas de las tareas de clasificación cortas.
• Forma del mensaje: instrucciones estables del sistema, ejemplos reutilizables, esquemas, contexto de recuperación y datos de usuario dinámicos.
• Requisito de latencia: segundos, minutos, horas o el siguiente día hábil.
• Visibilidad del usuario: si una persona está esperando el resultado.
• Tasa de reintentos y fallos: solicitudes con formato incorrecto, fallos de validación, tiempos de espera del proveedor, trabajos caducados y envíos duplicados.
• Propiedad: proyecto, equipo, cliente, clave API o cuenta de socio.
• SLA empresarial: la última vez que el resultado sigue siendo útil.

Esta auditoría generalmente revela que el “tráfico LLM” no es una carga de trabajo. Es una combinación de características interactivas del producto, automatización interna, informes, preparación de datos y evaluación de calidad. Tratarlos como un solo centro de costos oculta los ahorros más fáciles.

Utilice un clasificador de cargas de trabajo de tres carriles

Un clasificador simple evita que los equipos muevan el tráfico incorrecto a lotes y luego se sorprendan por expectativas incumplidas.

Carril 1: solicitudes interactivas en tiempo real

Manténgalos sincrónicos. Incluyen UX de chat, copilotos, agentes de soporte, revisión humana, flujos de búsqueda o recuperación en vivo y llamadas de herramientas con efectos secundarios inmediatos. Si un usuario está esperando, la latencia puede borrar el valor de una respuesta más barata.

Recomendación: optimice este carril con selección de modelo, recorte rápido, gestión de límite de velocidad, almacenamiento en caché cuando corresponda y reintentos cuidadosos. No lo envíe a una cola por lotes de 24 horas a menos que el producto lo presente explícitamente como una tarea en segundo plano.

Carril 2: solicitudes nearline que pueden esperar minutos

Estos trabajos no necesitan bloquear la carga de una página, pero aun así pueden tener una expectativa de duración de la misma sesión o la misma hora. Los ejemplos incluyen análisis de documentos posteriores a la carga, enriquecimiento de CRM después del envío del formulario o un informe que puede notificar al usuario cuando esté listo.

Recomendación: coloque el trabajo nearline detrás de una cola con estados de estado explícitos. Dependiendo del soporte del proveedor y la fecha límite, ejecútelo a través de lotes pequeños o trabajadores sincrónicos con menor prioridad. Este carril se beneficia de identificaciones de trabajos, webhooks y progreso visible para el usuario.

Carril 3: solicitudes por lotes sin conexión que pueden esperar hasta 24 horas

Esta es la principal vía de optimización de costes. Los buenos candidatos incluyen:

• evaluaciones a gran escala;
• etiquetado de conjuntos de datos;
• enriquecimiento de catálogo o CRM;
• resumen nocturno;
• colas de revisión de cumplimiento;
• incrustar rellenos;
• barridos de moderación;
• generación de informes periódicos;
• preprocesamiento del contenido antes de indexarlo o publicarlo.

Dato: los principales proveedores ahora ofrecen API por lotes asíncronas para cargas de trabajo adecuadas. La API Batch de OpenAI lee solicitudes de un archivo cargado, escribe los resultados en un archivo de salida y apunta al procesamiento dentro de las 24 horas. OpenAI afirma que el uso de API por lotes admitido se ofrece con un descuento del 50% en comparación con las API síncronas. La API Message Batches de Anthropic está diseñada para grandes volúmenes de solicitudes de mensajes, procesamiento asincrónico, mayor rendimiento y un 50 % menos de costo. La API Gemini Batch de Google está diseñada para solicitudes asincrónicas de gran volumen al 50% del costo estándar, con un tiempo de respuesta objetivo de 24 horas.

Compensación: “hasta 24 horas” es excelente para reposiciones y evaluaciones, pero inaceptable para flujos de trabajo interactivos. Batch es una estrategia de programación, no un reemplazo universal de la inferencia sincrónica.

Diseñar la ruta del lote como un ciclo de vida del trabajo

El error de implementación que se debe evitar es tratar el lote como una única llamada API. Es un ciclo de vida: aceptar el trabajo, validarlo, persistirlo, enviarlo, sondearlo, conciliarlo y exponer los resultados.

Arquitectura de referencia

1. Acepte una solicitud normalizada: mantenga la forma de la solicitud cercana a su formato API compatible con OpenAI existente siempre que sea posible. Agregue metadatos como proyecto, equipo, cliente, clave de idempotencia, fecha límite solicitada y centro de costos.
2. Clasifique la carga de trabajo: asigne la solicitud a lotes en tiempo real, nearline o offline. Esto debería estar basado en políticas, no oculto dentro del código de la aplicación.
3. Crear un ID de trabajo: devolver un identificador de trabajo inmediatamente para trabajos nearline y offline.
4. Validar compatibilidad: compruebe si el proveedor y el modelo seleccionados admiten lotes para el punto final solicitado, la modalidad, el tamaño del archivo, las herramientas, el formato de respuesta y otras características.
5. Filas de solicitud persistentes: almacena filas JSONL normalizadas o cargas útiles específicas del proveedor. Incluya un ID de fila estable para la conciliación.
6. Envíe el lote: cargue el archivo de solicitud o la carga útil del lote en línea según los límites del proveedor y el tamaño del trabajo.
7. Estado de la encuesta: realice un seguimiento de los estados del proveedor, como validando, en curso, completado, fallido, vencido, cancelando y cancelado, cuando corresponda.
8. Almacenar filas de resultados: escriba respuestas correctas, errores a nivel de fila, uso de tokens, recuentos de tokens almacenados en caché cuando estén disponibles e identificadores de proveedores.
9. Notificar a los consumidores: exponer un punto final de recuperación, un webhook, una notificación del panel o una alerta de Telegram.
10. Conciliar facturación: atribuya el costo al proyecto, equipo, cliente, clave API e ID del trabajo originales.

Este patrón mantiene la aplicación simple. Los equipos de productos envían trabajos y reciben estados de trabajo. La puerta de enlace o la capa de orquestación maneja las diferencias de proveedores, los archivos por lotes, los reintentos y la contabilidad.

Usar estados de trabajo explícitos

Defina estados internos incluso si cada proveedor usa nombres diferentes:

• en cola: aceptado pero no enviado;
• validando: el proveedor o la puerta de enlace está verificando el archivo;
• en ejecución: enviado y en proceso;
• completado: todos los resultados disponibles recopilados;
• completed_with_errors: algunas filas fallaron en la validación o ejecución;
• expirado: fecha límite vencida antes de que se completaran todas las filas;
• cancelado: detenido por usuario, sistema o política;
• fallido: error a nivel de trabajo que requiere intervención.

Hecho: OpenAI documenta los estados de los lotes, incluidos los de validación, fallido, en curso, completado, caducado, cancelado y cancelado. También señala que si un lote vence, el trabajo ya completado se devuelve y se cobra, mientras que el trabajo restante se cancela.

Recomendación: nunca asuma que los trabajos por lotes son de todo o nada. Cree un manejo de estado a nivel de fila desde el principio.

Calcular ahorros después de fallas y gastos generales

Un modelo de ahorro simple es suficiente para la mayoría de los equipos:

costo_línea base = costo_entrada_sincrónica + costo_salida_sincrónica
costo_por lotes = costo_de_entrada_por_lotes con descuento + costo_de_salida_por_lotes_con descuento
costo_por_lote_ajustado = costo_por_lote + costo_de_orquestación + costo_de_almacenamiento + costo_de_repetición
ahorro_estimado = costo_inicial - costo_por_lote_ajustado

Luego calcule esto por carga de trabajo, no globalmente. Una suite de evaluación nocturna puede ahorrar sustancialmente. Un flujo de trabajo casi en línea con muchas filas con formato incorrecto, respaldos urgentes o repeticiones repetidas puede ahorrar menos de lo esperado.

Realice un seguimiento de al menos estas métricas:

• sincronización versus gasto de tokens por lotes;
• tokens de entrada y salida por modelo;
• recuento de trabajos por lotes y promedio de filas por trabajo;
• tasa de fallos a nivel de fila;
• tarifa de trabajo vencido;
• costo de repetición;
• coste de respaldo para sincronización;
• coste por equipo, proyecto, clave, cliente y cuenta de socio.

Recomendación: trate el respaldo sincrónico automático como una excepción, no como el valor predeterminado. Protege los plazos, pero si se utiliza en exceso puede borrar los ahorros esperados. Agregue una política como "respaldar solo si la fecha límite comercial es dentro de dos horas y el trabajo no ha comenzado".

Agregar almacenamiento en caché de mensajes para prefijos largos repetidos

El procesamiento por lotes reduce el precio unitario del trabajo elegible. El almacenamiento en caché de avisos reduce el costo efectivo y la latencia de avisos prolongados y repetidos cuando el comportamiento del proveedor lo admite.

Hecho: el almacenamiento en caché de solicitudes de OpenAI se aplica automáticamente a solicitudes de más de 1024 tokens en modelos compatibles, almacena en caché el prefijo más largo calculado previamente e informa cached_tokens en los detalles de uso de API. OpenAI dice que los cachés de avisos generalmente se borran después de 5 a 10 minutos de inactividad y se eliminan dentro de una hora después del último uso, y que los cachés de avisos no se comparten entre organizaciones.

El patrón de implementación es sencillo: poner el contenido estable primero y el contenido volátil al final.

Mejor estructura de avisos para el almacenamiento en caché

Instrucciones del sistema
Texto de política estable
Esquema de salida estable
Ejemplos estables
Contexto de referencia reutilizable
---
Entrada dinámica específica de registro
Metadatos dinámicos de usuario o fila

Por ejemplo, un trabajo de enriquecimiento de catálogo podría reutilizar la misma taxonomía, esquema de salida, reglas de marca y ejemplos en 50.000 productos. Cada fila cambia solo el título, la descripción y los atributos del producto. Colocar el prefijo reutilizable primero le da al proveedor una mejor oportunidad de reutilizar el cálculo almacenado en caché cuando sea compatible.

Compensación: el almacenamiento en caché no es un almacenamiento permanente y no debe considerarse como garantizado. Las ventanas de caché, el aislamiento, la duración mínima del mensaje y los informes varían según el proveedor. Mida los tokens almacenados en caché en lugar de asumir ahorros.

Validar el soporte del proveedor antes del envío

Las API por lotes difieren. La puerta de enlace debe validar la elegibilidad antes de enviar un trabajo.

Datos: OpenAI Batch API no admite streaming y tiene límites de velocidad por lotes separados. Limitaciones de lotes de documentos de Anthropic, incluido un límite de tamaño de lote de 100 000 solicitudes o 256 MB, vencimiento en 24 horas, disponibilidad de resultados en 29 días, límites de velocidad y la posibilidad de que los lotes excedan ligeramente los límites de gasto del espacio de trabajo configurado. Google admite solicitudes por lotes en línea para trabajos más pequeños de menos de 20 MB y archivos de entrada JSONL para solicitudes por lotes más grandes.

Utilice una lista de verificación de compatibilidad:

• ¿El modelo solicitado está disponible a través de la API por lotes de ese proveedor?
• ¿Se admite el punto final?
• ¿La solicitud requiere transmisión? En caso afirmativo, rechace el lote.
• ¿Utiliza herramientas o efectos secundarios que deben ocurrir inmediatamente?
• ¿El archivo por lotes excede los límites del proveedor?
• ¿El resultado esperado sigue siendo útil dentro del plazo de finalización del proveedor?
• ¿Los resultados están disponibles el tiempo suficiente para que los sistemas posteriores los recuperen?
• ¿Puede la carga de trabajo tolerar una finalización parcial?

Recomendación: fallar la validación tempranamente con una razón clara. Un lote de candidatos rechazado es más barato que un trabajo caducado o con formato incorrecto que debe reelaborarse más adelante.

Protección para equipos, agencias y socios

Los sistemas por lotes pueden gastar silenciosamente mucho dinero porque procesan archivos grandes en segundo plano. Agregue controles antes de la implementación generalizada:

• Presupuestos por lotes por equipo: límites de gasto separados en línea y fuera de línea.
• Tamaño máximo de archivo y número de filas: aplique los límites del proveedor y sus propios límites operativos.
• Cola de mensajes no entregados: conserva las filas no válidas con errores de validación para su revisión.
• Claves de idempotencia: evitan que se reenvíen accidentalmente cargos duplicados.
• Revisión de PII: los archivos por lotes pueden crear nuevas obligaciones de privacidad y retención de datos.
• Política de retención: define durante cuánto tiempo se almacenan los archivos de solicitud, los archivos de salida y los registros.
• Política de notificación: alerta a los propietarios cuando los trabajos fallan, caducan o superan el presupuesto.
• Atribución: registre el proyecto, el equipo, el cliente, la clave API, el modelo, el proveedor, el ID del trabajo y el ID de la fila.

Para agencias y revendedores, la atribución es especialmente importante. Si un socio ejecuta trabajos de enriquecimiento o evaluación para muchos clientes, el sistema debe informar el costo por cliente y por trabajo, no solo por factura del proveedor.

Cómo se asigna esto a una puerta de enlace API de IA

Una puerta de enlace AI API es un lugar natural para implementar esto porque ya se encuentra entre las aplicaciones y los proveedores de modelos. La puerta de enlace puede preservar una superficie API compatible con OpenAI para los desarrolladores y, al mismo tiempo, agregar una programación consciente de los costos.

Las capacidades útiles de la puerta de enlace incluyen:

• Facturación unificada: compare el gasto sincrónico, por lotes, en caché y alternativo en un solo lugar.
• Análisis de uso de IA: desglose el uso por modelo, proveedor, punto final, equipo, proyecto y clave de API.
• Controles del equipo: establezca presupuestos separados para cargas de trabajo interactivas y fuera de línea.
• Atribución de clave de API: identifique qué servicio o cliente creó cada trabajo.
• Notificaciones de estado: envíe alertas cuando los trabajos por lotes se completen, fallen, caduquen o se acerquen a una fecha límite.
• Flujos de trabajo de API de socios: permita a las agencias o revendedores crear trabajos y recuperar resultados en nombre de los clientes, preservando al mismo tiempo la contabilidad a nivel de cliente.

Predicción: más equipos gestionarán los costos de LLM con políticas de programación, no solo con sustituciones de modelos. A medida que el soporte por lotes madure entre proveedores, la arquitectura ganadora se dirigirá según la urgencia, la compatibilidad de funciones y los requisitos de contabilidad antes de hacerlo según el precio del modelo.

Lista de verificación de implementación

• Exporta 30 días de uso de API LLM.
• Clasifique cada carga de trabajo como en tiempo real, nearline o offline.
• Elija una carga de trabajo fuera de línea con un propietario claro y una fecha límite indulgente.
• Valide el soporte por lotes del proveedor para el punto final y el modelo requeridos.
• Defina estados de trabajo internos y estados a nivel de fila.
• Agregue claves de idempotencia, ID de trabajo e ID por fila.
• Almacene registros de solicitudes y respuestas normalizados con controles de retención.
• Envíe el primer lote detrás de una marca de característica.
• Mida el costo base sincrónico versus el costo del lote ajustado.
• Reestructurar mensajes largos y repetidos para poner los prefijos estables primero.
• Realice un seguimiento de los tokens almacenados en caché, las filas fallidas, los trabajos caducados y el gasto alternativo.
• Expandir solo después de que los ahorros y el comportamiento operativo sean visibles en los análisis.

Conclusión procesable

No empieces a controlar los costes de la API de IA pidiendo a cada equipo que utilice un modelo más económico. Empiece por separar el trabajo urgente del trabajo que puede esperar. Mantenga las solicitudes interactivas sincrónicas. Mueva las evaluaciones, el enriquecimiento, el etiquetado, los reabastecimientos, los barridos de moderación y los informes a lotes cuando el soporte del proveedor y los plazos comerciales coincidan. Estructura repetidas indicaciones largas para el almacenamiento en caché. Luego mida los ahorros reales después de fallas, repeticiones, almacenamiento y costos de respaldo.

La mejor implementación es aburrida a propósito: ID de trabajo, validación, estados a nivel de fila, presupuestos, análisis de uso y propiedad clara. Esa capa operativa es lo que convierte los descuentos de los proveedores en ahorros confiables.

Lectura relacionada

• Controles de gastos de equipo y atribución de claves de API
• políticas de enrutamiento, reintentos y respaldo para API LLM
• notas relacionadas con la implementación de Model Gate