Reducir el coste de un agente sin empeorarlo
Cuando una factura de tokens sorprende a alguien, el instinto es cambiar a un modelo barato en todas partes y aceptar la pérdida de calidad. Rara vez hace falta. En los sistemas que hemos auditado, la mayor parte del gasto venía de contexto que no debía estar y de pasos que no necesitaban el modelo caro.
El método de abajo es aburrido y eficaz: primero medir, luego aplicar cuatro cambios por orden de retorno y después decidir si aún hay problema. La mayoría de equipos para tras el segundo.
Mide por ejecución antes de cambiar nada#
El gasto mensual agregado no dice nada accionable. Registra por ejecución: tokens de entrada y salida, número de llamadas, modelo por llamada y tipo de tarea. Luego mira el coste por tarea completada, dividido por tipo. Casi siempre uno o dos tipos dominan, y dentro de ellos, un paso. Optimizar otra cosa es esfuerzo donde no está el dinero.
Cuenta también las ejecuciones fallidas en el denominador. Un bucle de reintentos que quema tres intentos es un problema de coste disfrazado de calidad.
Los cuatro cambios, por retorno#
| Cambio | Ahorro típico | Riesgo |
|---|---|---|
| Recortar contexto: descartar documentos usados, comprimir historial | 20–40 % | Bajo si el objetivo sigue fijado |
| Bajar de nivel los pasos baratos | 20–40 % | Bajo, con evaluación por paso |
| Cachear el prefijo estable | 10–30 % con tráfico repetido | Bajo |
| Reducir pasos: mejores herramientas, menos reintentos | 10–25 % | Medio: requiere trabajo de herramientas |
La factura es el contexto#
Cada turno reenvía el contexto acumulado, así que una ejecución de ocho pasos puede pagar el mismo documento ocho veces. Tres hábitos arreglan casi todo: descartar los pasajes recuperados cuando termina su paso; comprimir turnos viejos en notas factuales; y recortar los resultados de herramienta a los campos que se usan. Ninguno reduce capacidad: quitan texto que el modelo no estaba usando.
Enruta por paso, no por gusto#
Extracción, clasificación y formato rara vez necesitan tu modelo más fuerte; planificar y escribir para el usuario, a menudo sí. Baja el primer grupo un nivel, pasa el conjunto de evaluación y conserva el cambio solo si los números aguantan. Hacerlo por paso es lo que permite quitar un tercio de la factura sin que nadie note diferencia.
- Empieza por el paso de más volumen y menos criterio.
- Cambia un paso cada vez y reejecuta la evaluación.
- Registra qué modelo produjo cada decisión para poder atribuir regresiones.
- Pon un tope de gasto por ejecución para que un caso patológico no sea ilimitado.
Lo que no hay que hacer#
No recortes la recuperación que ancla tus respuestas: una alucinación es mucho más cara que unos tokens cuando alguien tiene que corregirla. No elimines el pase crítico ante acciones irreversibles para ahorrar una llamada. Y no persigas microoptimizaciones de redacción del prompt: el ahorro es ruido al lado del recorte de contexto.
Preguntas frecuentes
¿Merece la pena el caché?
Si tus ejecuciones comparten un prefijo largo y estable — instrucciones de sistema, definiciones, texto de política — sí, y es de los ahorros más baratos. Estructura el prompt con lo estable delante.
¿Ajuste fino para ahorrar?
Solo para un paso de alto volumen, estrecho y estable donde un modelo pequeño ajustado iguale a uno grande. El ajuste añade mantenimiento y reentrenamiento; a poco volumen, enrutar y recortar ganan.
¿Cómo evito una ejecución carísima?
Topes de pasos y gasto por ejecución, detección de llamadas idénticas repetidas y parada con resultado parcial. Alerta sobre las ejecuciones que llegan al tope: suelen ser un bug, no solo un gasto.
coste de agentes iaoptimización de costes llmreducir coste de tokenscaché de promptsrouting de modelos
