Cómo Reducir los Costes de Tokens LLM en 2026: Routing, Caching, Compresión y el Modelo Adecuado

Los precios por token se desplomaron y, aun así, muchos equipos pagan hoy más por el uso de LLM que hace un año. La razón es simple. El precio por token bajó, pero los productos con agentes hacen ahora de decenas a cientos de llamadas al modelo por tarea, y la mayoría de esos tokens son contexto que el modelo nunca necesitó. Tokens baratos por un alto volumen de llamadas sigue siendo una factura grande. Este es el manual con el que la reducimos sin sacrificar calidad, en el orden en que lo aplicamos.

Perspectiva de ingeniería, no un pitch de proveedor. Los datos de precio y benchmark de abajo son orientativos, sacados de tendencias públicas de precios de 2026, no son quotes de un proveedor concreto. Los puntos de referencia vienen del trabajo de Wavect en productos de IA.

¿Por qué tu factura de LLM sigue alta si los precios por token se desplomaron?

Dentro de una factura grande se esconden tres cosas, y ninguna es el precio por token del titular:

• Volumen de llamadas. Un bucle de agente con 50 a 200 llamadas al modelo por tarea convierte un precio barato por token en un precio caro por tarea. La unidad que pagas es la tarea, no el token.
• Contexto desperdiciado. Buena parte de los tokens de entrada de una llamada típica es contexto que el modelo no necesita para ese paso. Los análisis del sector sitúan el desperdicio en el rango del 40 al 60 por ciento en flujos con agentes sin optimizar. Pagas por cada uno de esos tokens en cada llamada.
• El modelo equivocado para la tarea equivocada. Enrutar cada petición a un modelo frontier "por si acaso" es la forma más común de pagar de más. La mayoría de las peticiones no necesitan tu modelo más caro.

Arréglalo en este orden. Las victorias más baratas van primero, y no requieren reentrenar el modelo ni reescribir la arquitectura.

¿Cuál es la victoria más rápida? Prompt caching y batch.

Antes de tocar tu arquitectura, llévate los dos descuentos que los proveedores te dan gratis.

• Prompt caching. Cuando llamadas consecutivas comparten un prefijo estable (system prompt, instrucciones, contexto recuperado), el proveedor puede saltarse su reprocesado. El input cacheado es alrededor de un 90 por ciento más barato en Anthropic, sobre medio precio en OpenAI, y Google cobra cerca del 10 por ciento de la tarifa base en los aciertos de caché. La palanca de ingeniería es el orden: pon el contenido estable primero y el input volátil del usuario al final, para que el prefijo de caché se mantenga intacto entre llamadas.
• Procesado en batch. Todos los grandes proveedores ofrecen un endpoint batch a aproximadamente la mitad de la tarifa en vivo a cambio de una ventana de finalización asíncrona. Todo lo que no necesite una respuesta por debajo del segundo, evaluaciones, enriquecimiento, clasificación, trabajos de summarization, debería correr en batch.

Estos descuentos se acumulan. Acierto de caché más batch sobre el mismo workload deja el input cacheado alrededor de un 95 por ciento por debajo de la tarifa estándar. Un equipo que procesa cientos de miles de documentos al mes puede recortar una factura mensual de cuatro cifras a una fracción sin cambiar nada más que el endpoint y el orden del prompt.

"La mayoría de los equipos recurre a cambiar de modelo cuando la victoria más barata es reordenar el prompt para que la caché acierte de verdad."

¿Cómo recorta costes el model routing sin dañar la calidad?

Routing significa que un modelo barato atiende a la mayoría fácil y uno caro a la minoría difícil. Hecho a ciegas degrada la calidad. Hecho con un chequeo de confianza no.

• Default barato más escalado. Corre primero un modelo mid-tier o pequeño. Si un chequeo estructurado de confianza falla, la respuesta es de baja confianza, no válida según el schema, o marcada por un verificador, escala a un modelo frontier. Sigue la tasa de escalado como un KPI de producto. Una tasa que sube te dice que al modelo barato se le pide demasiado.
• Routers y gateways. Frameworks abiertos como RouteLLM publican cifras concretas: alrededor del 95 por ciento de la calidad frontier enviando solo del 14 al 26 por ciento de las llamadas al modelo fuerte, lo que se traduce en una reducción de coste del 75 al 85 por ciento sobre el tráfico enrutado. Un gateway LLM por delante de varios proveedores también te da un único sitio para fijar caching, fallback y límites de gasto.

Usamos el patrón de escalado en trabajo de IA en producción, incluidos engagements como Twinsoft AI. La disciplina que lo hace seguro es la misma que hace seguro todo lo demás aquí: un harness de evals que te dice si el camino barato de verdad mantuvo la calidad.

¿Qué modelos frontier deberías usar de verdad en 2026?

No hay un único mejor modelo. Hay un mejor modelo por tarea, y la brecha de precio-rendimiento es ya lo bastante amplia como para que la elección de modelo sea una de tus mayores palancas de coste. El panorama de 2026 se divide en dos bandos.

• Frontier occidental. Claude, GPT y Gemini siguen liderando en el reasoning y el coding más duros y en los bucles de agente más profundos. Cuando una respuesta equivocada sale cara, el modelo frontier suele ganar en coste total una vez cuentas el tiempo de desarrollo gastado en arreglar salidas malas.
• Frontier china de pesos abiertos. DeepSeek, Qwen, Kimi y GLM han cerrado la mayor parte de la brecha de calidad en coding y reasoning reales, a precios que suelen ser de 15 a 30 veces más bajos por token que la frontier occidental. Para workloads de alto volumen y sensibles al coste, cambian las cuentas.

Precios orientativos por clase, normalizados por 1M de tokens. Trátalos como una foto de tendencias públicas, no como un quote, y vuelve a comprobarlos antes de comprometerte.

El pero para un equipo de la UE no es la calidad, es la governance. Dónde corre la inferencia y dónde aterrizan los datos importa para la residencia de datos y el compliance. Usa un modelo chino de pesos abiertos self-hosted en infraestructura de la UE y mantienes la ventaja de precio sin enviar datos fuera. Úsalo a través de una API no europea y tienes primero una pregunta de compliance que responder. En cualquier caso, corre tu propio eval antes de cambiar. Un modelo más barato que falla 1 de cada 10 tareas no es más barato.

Híbrido local más frontier: ¿cuándo compensa self-hostear pesos abiertos?

El patrón híbrido es un modelo pequeño o de pesos abiertos para el grueso del volumen, y una API frontier para la cola difícil. La pregunta es cuándo traer el grueso a casa. La respuesta honesta en 2026: más tarde de lo que cree la mayoría de los equipos.

• El punto de equilibrio lo manda el tiempo de ingeniería, no el precio del rack de GPU. El modelo es barato de correr. Las ops, la disciplina de evals y la cadencia de upgrades no lo son.
• Para la mayoría de los productos, las APIs hosteadas siguen siendo más baratas hasta que sostienes un volumen serio, a menudo cifrado en torno a 50 millones de tokens al día o más, o hasta que un requisito de residencia de datos obliga al hosting local al margen del coste.
• Cuando self-hosteas, un motor de inferencia como vLLM más pesos abiertos cuantizados (clase Llama, Qwen, DeepSeek, Mistral) es el stack de producción estándar.

Por defecto, APIs hosteadas para productos tempranos. Retoma el self-hosting cuando tu volumen o tu postura de compliance obliguen a la pregunta. Profundizamos en las implicaciones de arquitectura en qué cambian los tokens baratos en tu arquitectura de IA.

¿Cómo dejas de pagar por tokens que el modelo no necesita?

Aquí se resuelve el problema del contexto desperdiciado, y aquí viven los mayores ahorros estructurales después del caching.

• Caching semántico. Guarda pares de petición y respuesta y devuelve una respuesta cacheada para una consulta semánticamente similar. En un acierto, te saltas la llamada al modelo entera. Herramientas como GPTCache y cachés sobre Redis reportan reducciones de coste en torno al 70 por ciento en workloads con mucha repetición.
• Compresión de contexto. Los flujos con agentes y de coding reenvían los mismos archivos, logs e historial en cada llamada. Una capa de compresión lo recorta a lo que el paso necesita. Herramientas abiertas en este espacio, por ejemplo lean-ctx y RTK (Rust Token Killer), se sitúan entre tu agente y el modelo y recortan tokens de entrada antes de que pagues por ellos. El principio importa más que la herramienta concreta: manda al modelo el contexto correcto más pequeño, no todo tu workspace.
• Compresión de KV-cache a nivel de inferencia. Si self-hosteas, las técnicas de eviction y cuantización del KV-cache recortan el coste de memoria y cómputo de los contextos largos. Es una palanca para equipos que self-hostean, no para consumidores de API.

¿En qué orden deberías hacerlo?

La lista de prioridades que recorremos, lo más barato y de menor riesgo primero:

1. Prompt caching. Reordena los prompts con el prefijo estable primero. Sin riesgo de calidad, gran ahorro.
2. Batch del trabajo async. Mueve todo lo tolerante a latencia al endpoint batch a mitad de precio.
3. Routing con escalado. Default barato, escalado a frontier gobernado por confianza. Sigue la tasa de escalado.
4. Dimensiona bien el modelo. Evalúa modelos de pesos abiertos y frontier chinos contra tu tarea. Cambia con un eval probado, no con un titular de benchmark.
5. Comprime el contexto. Cachea semánticamente las repeticiones, comprime el contexto por llamada.
6. Self-hosting solo a volumen. Trae el grueso a casa cuando el volumen o el compliance obliguen, no antes.
7. Construye el harness de evals. Nada de lo anterior es seguro de lanzar sin uno. Es lo que te dice que un camino más barato mantuvo el listón de calidad. Ver SDLC.

Los pasos uno a tres suelen entregar la mayor parte del ahorro en la primera semana, sin cambio de arquitectura. Los pasos cuatro a seis son donde lo compones.