Orden de optimización de costes de los LLM
Actualizado September 27, 2026 · publicado originalmente September 27, 2026
En septiembre de 2026, un hilo de r/LLMDevs preguntó cómo se controlan realmente los costes de LLM en producción y qué se haría si el tiempo de ingeniería no fuera un límite. La respuesta más votada dejó una lección más útil que cualquier guía de un proveedor: el orden importa mucho más de lo que se reconoce. Su equipo empezó por la caché de prompts y redujo mucho los prompts de sistema. El intento de ajustar un modelo pequeño para las tareas repetitivas salió mal: el mantenimiento resultó agotador y la calidad siguió deteriorándose.
El orden que funciona
- Activar la caché de prompts. Es una de las horas de ingeniería más rentables. En Opus 5.5, leer un millón de tokens de la caché cuesta 0,20 $ frente a 4,00 $ por un millón de tokens de entrada nuevos: un descuento del 95 % para esa partida. Si el prompt de sistema, las definiciones de herramientas o el contexto recuperado se repiten entre llamadas, conviene empezar aquí.
- Acortar el prompt de sistema. La misma respuesta recomendaba reducirlo. Las instrucciones extensas se cobran en cada llamada. Es ante todo un trabajo de redacción, no de ingeniería.
- Eliminar herramientas sin uso. Cada definición se incluye en el contexto de cada solicitud, se invoque o no la herramienta. Es el mismo coste adicional que generan las definiciones de herramientas MCP. Quitar una herramienta puede ser un cambio de una línea de configuración con efecto permanente.
- Enrutar según la tarea. Solo entonces empieza a compensar el enrutamiento entre modelos. Un enrutador construido tras el primer paso ya cuesta menos incluso antes de cambiar de modelo.
- Agrupar o aplazar. La API por lotes ofrece un descuento directo para trabajos que no requieren respuesta inmediata al usuario. El tráfico fuera de producción debería usar lotes desde el principio cuando sea posible.
- Ajustar el modelo al final, si acaso. Es el paso al que muchos equipos recurren primero y el que falló en este caso. El mantenimiento y la pérdida de calidad crean un coste operativo continuo para un ahorro que la caché y el enrutamiento quizá ya hayan capturado.
Por qué importa tanto el orden
Cada paso cambia la cantidad de tokens y el coste sobre los que actúa el siguiente. Si acorta el prompt de sistema antes de configurar el enrutamiento, el modelo económico puede atender más tráfico con la misma lógica. Si activa la caché antes de ajustar un modelo, el presupuesto de ajuste solo tiene que justificarse frente a los fallos de caché. En el orden equivocado se paga dos veces: por un ajuste que una reescritura del prompt habría evitado, o por un enrutador que manda 60 000 tokens de instrucciones a un modelo económico incapaz de gestionarlos bien.
Un patrón de error
El problema descrito en el hilo fue ajustar un modelo pequeño para trabajo repetitivo. El ahorro esperado era real, pero cada cambio en el trabajo exigía volver a entrenarlo. La calidad se alejaba de la del modelo base a medida que este mejoraba, y la carga operativa hacía difícil mantener el ajuste. Es posible que ese trabajo representara apenas el 15 % del volumen y el 2 % del gasto: un ahorro pequeño rodeado de un coste continuo grande.
Aplicar la secuencia a una solicitud
Tome una solicitud representativa y aplique cada paso por orden, registrando tokens facturados y coste:
| Paso | Qué cambia | Reducción típica indicada |
|---|---|---|
| Activar la caché | El prefijo repetido pasa a ser una lectura de caché | 40–70 % |
| Acortar el prompt de sistema | Menos tokens sin caché en cada llamada | 10–25 % |
| Quitar herramientas sin uso | Bloque de herramientas más pequeño | 5–15 % |
| Enrutamiento | Modelo más barato para la mayor parte del tráfico | 30–60 % |
| Lotes para tráfico no productivo | Tarifa con descuento | 25–50 % de ese tráfico |
Los efectos se acumulan. En el ejemplo, aplicar los pasos en orden puede llevar a un coste un 80–90 % menor para la misma solicitud. Si se empieza por el ajuste, se puede acabar con un modelo ajustado para el 15 % del volumen y una regla de enrutamiento que nunca amortiza su coste. Las cifras de caché y enrutamiento expresan ahorros de coste; el enrutamiento no reduce por sí solo el número de tokens.
Conclusión
La caché, la reducción de prompts y la eliminación de herramientas sin uso son medidas baratas, de bajo riesgo y con efectos acumulativos. Después vienen el enrutamiento y los lotes. El ajuste del modelo queda para el final, si llega a ser necesario. Lo difícil no es la lista, sino respetar la secuencia.
Relacionado
- El coste de los prompts extensos
- Coste adicional de las definiciones MCP
- Límites de concurrencia de subagentes
- El nivel gratuito es un coste de captación
- Tres presupuestos para agentes
¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita →