Ahorrar tokens como problema de transporte
LLMтокенымаршрутизация моделей
Hay que medir toda la trayectoria del agente
Yo no mediría los tokens de una sola solicitud, sino el coste esperado de toda la trayectoria del agente. En el debate original, el usuario 1497575255 comparó la minimización de tokens con un problema de transporte: el resultado debe ir del punto A al punto B con el menor consumo de recursos. Es una idea más precisa que el habitual «hagamos el prompt más corto».
En cada paso puede conocerse o estimarse el coste de entrada y salida. La entrada incluye instrucciones, historial, esquemas de herramientas y documentos recuperados. La salida depende del tipo de tarea, el modelo elegido, el presupuesto de generación y de si el agente tendrá que repetir la llamada.
En el nivel del pipeline aparecen más variables:
- qué modelo asignar al planificador, ejecutor y verificador;
- qué fragmentos de contexto conservar o comprimir;
- cuántas iteraciones y reintentos permitir;
- cuándo llamar a una herramienta y cuándo cerrar una rama.
Así, la función objetivo no minimiza solo el número de tokens, sino el coste total sujeto a restricciones de calidad, latencia y fiabilidad. Si una tarea se asigna a uno de varios modelos, surge un problema de selección entera. Si el flujo de solicitudes se distribuye entre modelos, configuraciones o regiones, la analogía con el transporte es casi literal.
También existe un subproblema de selección de contexto. Cada fragmento tiene tamaño y utilidad esperada, mientras que la ventana total está limitada por un presupuesto. Por su estructura, se parece a un problema de mochila conectado con el enrutamiento de modelos en un mismo esquema de optimización.
La longitud exacta de la entrada suele calcularse antes de enviar la solicitud. La salida es más difícil: exige una previsión por tipo de tarea y modelo, y en agentes hay que considerar la probabilidad de pasos adicionales. A 6 de noviembre de 2026, no es una noticia sobre un lanzamiento concreto, sino una formulación de ingeniería útil.
El ahorro no empieza con el modelo más barato
La mayor ganancia procede de gestionar las decisiones del agente, no de sustituir mecánicamente un modelo potente por otro débil. Una llamada cara puede ser más rentable si evita reintentos, búsquedas innecesarias o una larga rama de razonamiento.
Una arquitectura práctica tiene dos partes. Un predictor estima tokens, calidad, latencia y riesgo para las acciones posibles. Un controlador elige la alternativa menos costosa que cumple las restricciones y recalcula la decisión tras cada paso según el presupuesto restante.
La debilidad es evidente: un error al predecir la calidad puede costar más que los tokens ahorrados. Por eso vigilaría sobre todo las llamadas repetidas, el crecimiento del historial y el envío de resultados completos de herramientas. Ahí los pipelines de agentes suelen consumir presupuesto sin que se note.
En este sistema, los tokens dejan de ser un contador posterior a la ejecución y pasan a ser un recurso de planificación. Queda una pregunta: ¿hasta qué punto el enrutador puede prever el coste del error antes de que una ruta barata se convierta en un desvío caro?