Presupuestar coste y latencia de las llamadas a modelos en un agente

Objetivo

Saber antes del despliegue cuánto cuesta una ejecución del agente y cuánto espera el usuario, mantener ambos valores dentro de límites aplicados en código y detectar cuándo un cambio modifica alguno de ellos.

Requisitos previos

Los campos de uso por llamada que devuelve el proveedor (tokens de entrada, tokens de salida, lecturas y escrituras de cache). Las convenciones semánticas GenAI de OpenTelemetry (en desarrollo y mantenidas en un repositorio aparte; la página del registro en opentelemetry.io las indica como movidas) los denominan gen_ai.usage.input_tokens, gen_ai.usage.output_tokens y gen_ai.usage.cache_read.input_tokens. Además, una lista de precios de los modelos en uso y registros de ejecución reproducibles para atribuir el coste a cada paso.

Pasos

1. Mide una línea base sobre el conjunto de evaluación: por ejecución, el número de llamadas al modelo, el total de tokens de entrada y de salida, el tiempo real transcurrido y la llamada individual más larga.
2. Fija presupuestos por ejecución: un tope de tokens, un tope de pasos y un plazo límite. Aplícalos en el bucle; cuando se alcanza un presupuesto, el agente dispone de un último turno para informar de lo que está hecho y de lo que no.
3. Reduce primero los tokens de entrada. Coloca el prompt de sistema, las definiciones de herramientas y los documentos de referencia al principio de la solicitud y márcalos para el almacenamiento en cache. La documentación del proveedor describe puntos de corte cache_control con una vigencia de 5 minutos o 1 hora, indica los aciertos en cache_read_input_tokens y afirma que cambiar cualquier bloque situado en el punto de corte o antes de él produce un hash distinto; mantén las marcas de tiempo y los valores propios de cada solicitud después del prefijo almacenado en cache.
4. Reduce los tokens de salida: pide la salida más corta que el siguiente paso pueda consumir (una llamada a herramienta, un identificador, datos estructurados), no una narración.
5. Recorta el contexto: descarta o resume los resultados antiguos de herramientas en lugar de reenviarlos en cada paso.
6. Envía el trabajo offline (ejecuciones de evaluación, extracciones nocturnas) a un endpoint batch. La documentación de batch citada indica que el uso en batch se cobra al 50 % de los precios estándar de la API y que los lotes caducan si el procesamiento no termina en 24 horas.
7. Usa un modelo más pequeño en los pasos que, según el arnés de evaluación, supera; mantén el modelo mayor donde el arnés muestre que hace falta.
8. Configura alertas sobre el coste por tarea completada y sobre la latencia p95, no solo sobre el gasto total; un modelo más barato que necesita más reintentos no es más barato.

Resultado esperado

Un coste y una latencia documentados por tipo de tarea, presupuestos aplicados en código y un panel en el que un cambio de prompt que duplique el uso de tokens sea visible el mismo día.

Límites y base de verificación

Los precios, las vigencias de la cache y las condiciones de batch son del proveedor y cambian; las cifras anteriores están tomadas de la documentación citada en el momento de la redacción. El procesamiento batch no es adecuado para el uso interactivo. Los presupuestos detienen las ejecuciones descontroladas, pero no abaratan una ejecución; eso solo lo consiguen los pasos 3 a 7.