Un request de IA puede funcionar técnicamente y aun así ser una falla de producto porque consumió demasiados tokens, esperó en una cola ilimitada, ocupó memoria GPU cara o disparó una cadena de llamadas cuyo valor nunca justificó el costo.
La orientación de costos de OpenAI agrupa las palancas obvias: hacer menos requests, usar menos tokens y seleccionar modelos menores cuando preservan calidad. La orientación de latencia agrega una advertencia importante: generar output suele ser la etapa más lenta, y un LLM no debería ser la opción predeterminada para trabajo que un método determinista resuelve. Son decisiones de arquitectura, no trucos de prompt.
Un presupuesto de request debe declarar el máximo de llamadas de modelo, tokens de entrada, tokens de salida, tool calls, tiempo total, tiempo en cola, retries y dinero que una tarea puede consumir. Sin ese contrato, un agente puede estar “funcionando correctamente” mientras gasta recursivamente el margen del producto.
Mide entrada sin caché, entrada con caché, salida, reasoning, tool calls, retrieval, storage, red y retries por separado. Un único total de tokens oculta si el sistema envía contexto inflado, genera respuestas verbosas o paga repetidamente por el mismo prefijo. Prompt caching de OpenAI expone cached tokens y recomienda colocar contenido estable primero para reutilizar prefijos idénticos.
En inferencia self-hosted, prefix caching cumple el mismo papel económico. vLLM documenta reutilización de bloques de KV cache cuando requests comparten prefijo, evitando computación redundante. Pero cache hit rate es una propiedad del workload. Un caché que consume memoria GPU sin atender prefijos repetidos puede aumentar el costo.
Una GPU puede ser cara cuando está ociosa y lenta cuando está sobrecargada. Dynamic batching combina requests compatibles para mejorar throughput, pero intercambia un poco de espera por mejor utilización. NVIDIA Triton expone batch size, demora máxima, tamaño de cola, prioridades y timeouts porque no existe una configuración correcta universal. Chat interactivo y enriquecimiento nocturno no deberían competir bajo la misma política de latencia.
Autoscaling solo ayuda cuando la señal representa el cuello real y la nueva capacidad llega antes de que el backlog quede obsoleto. Kubernetes HPA escala con métricas personalizadas y externas, pero opera como control loop con demoras y estabilización. Profundidad de cola, edad del mensaje más antiguo, secuencias activas, presión de caché y saturación GPU suelen ser mejores que CPU sola.
Las colas hacen sobrevivibles los bursts, pero también esconden sobrecarga hasta que el trabajo pendiente es imposible de drenar. Builders' Library de Amazon describe cómo evitar backlogs insuperables, priorizar workloads y hacer load shedding. En sistemas de IA, el trabajo stale es especialmente caro: una sugerencia retrasada, ejecución duplicada de agente o evaluación de una versión antigua puede consumir inferencia completa y no entregar valor.
Limita colas por cantidad, edad y valor económico. Rechaza temprano cuando la tarea no pueda cumplir su deadline. Cancela llamadas downstream cuando el usuario se vaya o la tarea padre expire. Separa colas interactivas, background, evaluación y baja prioridad. Backpressure no es falla de producto; gasto silencioso e ilimitado sí.
| Presión de costo | Señal observada | Control de ingeniería | Falla si se ignora |
|---|---|---|---|
| Contexto demasiado grande | Input tokens, calidad del retrieval y proporción con caché. | Filtrar contexto, resumir, versionar prompts y estabilizar prefijos. | Costo repetido de prefill y mayor latencia. |
| Generación verbosa | Output tokens, tiempo total y respuestas abandonadas. | Límites de output, respuestas estructuradas, prompts concisos y modelo menor. | Costo de decode domina mientras usuarios esperan o salen. |
| Demasiadas llamadas | Calls por tarea, profundidad, retries y tool loops. | Orquestación con presupuesto, combinar o paralelizar pasos, alternativas deterministas. | Loops de agentes multiplican costo y fallas. |
| Baja utilización GPU | Secuencias activas, batch size, memoria y compute GPU. | Dynamic batching, routing, modelos adecuados y batch programado. | Pago por capacidad ociosa. |
| Sobrecarga de cola | Profundidad, mayor edad, deadlines perdidos y cancelaciones. | Colas limitadas, prioridad, admission control, load shedding y backpressure. | Trabajo stale consume capacidad y backlog no drena. |
| Gasto descontrolado por tenant | Costo por tenant, tarea, feature, resultado y ventana. | Cuotas, presupuestos por tarea, tiers de modelo, alertas y degradación. | Un workflow destruye margen para todos. |
Construiría un control plane de costos de inferencia que asigna presupuesto a cada tarea antes de ejecutarla. Enrutaría trabajo simple a código determinista o modelos menores, preservaría prefijos favorables a caché, elegiría capacidad interactiva o batch y detendría cadenas cuando el valor marginal quedara por debajo del costo restante.
El dashboard conectaría dinero con comportamiento: costo por resultado útil, tokens de entrada, salida y caché, utilización GPU, llenado de batch, edad de cola, deadlines perdidos, cancelaciones, retries y costo evitado por routing, caching o rechazo. La mejor métrica de ahorro no es “gastó menos”; es “eliminó desperdicio sin reducir resultados útiles”.
La capacidad no es infinita solo porque una API acepta otro request. La ingeniería de costos hace explícita la escasez en cada capa. Presupuesta el trabajo antes de comenzar, reutiliza computación cuando realmente sea reutilizable, agrupa donde la latencia lo permita y aplica backpressure antes de que las colas conviertan trabajo caro en trabajo sin valor.
Artículo sobre ingeniería de costos de compute para IA, cubriendo presupuestos por request, tokens, utilización GPU, prompt y prefix caches, dynamic batching, colas limitadas, backpressure y costo por resultado útil.