A mediados de 2026, el error arquitectónico más común que observamos en producción es pagar demasiado por la inferencia. Los equipos implantan funcionalidades basadas en LLM, comprueban que funcionan y después reciben facturas mensuales de cinco cifras que crecen con el uso. Algunas funcionalidades dejan de ser rentables; otras se eliminan pese a que habrían sido viables con una mayor disciplina de costes.
La mayoría de las facturas de LLM son muy superiores a lo necesario. El ahorro no procede de una técnica mágica, sino de una combinación de optimizaciones, cada una modesta por separado.
Este artículo cubre las técnicas, los números y la disciplina de producción. Suponemos que ya has realizado el enrutamiento básico de modelos (cubierto en otro artículo); vamos más allá.
La estructura de costes
Los costes de los LLM proceden de:
- Tokens de entrada. Lo que envías al modelo. Incluye el prompt del sistema, el contexto y la consulta del usuario.
- Tokens de salida. Lo que devuelve el modelo. Normalmente cuestan 4-6x más que los de entrada (Anthropic 5x y OpenAI ~6x con los precios actuales; consulta la referencia de modelos y precios, verificada el 2026-07-07).
- Tokens de razonamiento. Para modelos de razonamiento, tokens internos de “pensamiento”. A menudo tan caros como la salida.
- Llamadas a herramientas. Cuando se utilizan, cada definición de herramienta consume tokens de entrada.
- Reintentos. Las llamadas fallidas también tienen coste.
La optimización funciona en cada capa.
Técnica 1: Almacenamiento en caché de prompts
Es la palanca más eficaz. La mayoría de los proveedores modernos guardan en caché los prefijos de entrada repetidos: pagas el precio completo la primera vez y mucho menos en las llamadas posteriores con el mismo prefijo.
Precios (típicos):
- Anthropic: entrada almacenada en caché ~10% del coste normal.
- OpenAI: caché automática de prefijos coincidentes, ~50% del coste normal (varía según el modelo).
- Google: contenido almacenado en caché explícito, varía.
Cómo funciona: la primera llamada a un modelo con un prefijo de entrada específico tiene el precio normal. Las llamadas posteriores dentro del período de caché (normalmente 5-60 minutos, dependiendo del proveedor) reutilizan la representación almacenada en caché.
Implementación práctica:
Estructura tus prompts para que el contenido estático vaya primero, y el contenido dinámico al final:
[CACHED: 10K tokens]
- System prompt
- Tool descriptions
- User's static profile
- Knowledge base snippets unlikely to change per call
[NOT CACHED: 1K tokens]
- Conversation history (changes each turn)
- Current user query
Los primeros 10K tokens se almacenan en caché después de la primera llamada. Las llamadas posteriores pagan ~10% en ellos y el precio completo en los 1K.
Ejemplo de ahorro:
Sin caché:
- 11K tokens de entrada × €3/millón = €0.033 por llamada.
- 100K llamadas/día = €3,300/día.
Con caché (el 90% de la entrada está en caché):
- 1K al precio completo + 10K en caché al 10%:
- 1K × €3/millón + 10K × €0.30/millón = €0.003 + €0.003 = €0.006 por llamada.
- 100K llamadas/día = €600/día.
Ahorro del 82%. Cifras reales de sistemas reales.
Disciplina de implementación:
- Distingue las partes estáticas de las dinámicas en los prompts.
- Coloca las partes estáticas primero.
- Usa marcadores de caché donde el proveedor lo admita (Anthropic) para un control explícito.
- Comprueba los aciertos de caché: la observabilidad debe mostrar su tasa. Si es baja, la estructura del prompt no es adecuada.
Esta es la optimización con mayor ROI. Implántala antes que cualquier otra.
Técnica 2: Enrutamiento de modelos
Cubierto en detalle en otro lugar. Breve: diferentes solicitudes a diferentes modelos según la complejidad.
- 60% de las solicitudes a modelos pequeños.
- 30% a modelos intermedios.
- 10% a modelos principales.
Ahorro típico: 60-80% frente a utilizar modelos principales para todo.
Combinado con la caché, el ahorro alcanza el 90%+ frente a una referencia ingenua.
Técnica 3: Control de longitud de salida
Los tokens de salida concentran el coste en la mayoría de los casos de uso. Suelen costar 4-6x más que los de entrada, dependen del modelo y del prompt, y a menudo son más numerosos de lo necesario.
Estrategias:
Instrucciones explícitas de longitud.
Respond in at most 100 words.
Los modelos suelen cumplirlo razonablemente bien, lo que reduce de forma notable los costes de salida.
Salida estructurada.
Cuando la respuesta visible al usuario es datos estructurados cortos (JSON con campos específicos), la salida está limitada. No hay riesgo de verbosidad innecesaria.
Parámetro max_tokens.
Establece el valor. No lo dejes en el valor predeterminado. Si 200 tokens son suficientes, establece el máximo en 250 (pequeño margen). El modelo no puede excederlo.
Restricciones de formato.
“Solo viñetas” o “un único párrafo” generan salidas más breves que un formato libre.
Viñetas en lugar de prosa.
Las viñetas suelen consumir la mitad de tokens que una explicación en prosa con la misma información.
Sin introducción.
“Omite las frases introductorias. Ve directamente a la respuesta.” Los modelos suelen empezar con “Gran pregunta…” o “Permíteme explicarlo…”: tokens desperdiciados.
Ejemplo de ahorro:
Un flujo de trabajo de resumen. Salida predeterminada: 500 tokens. Salida restringida: 200 tokens.
- 500 tokens × €10/millón = €0.005 por llamada.
- 200 tokens × €10/millón = €0.002 por llamada.
Ahorro del 60% en la salida. Es menos llamativo que el 90% de la caché, pero afecta a la partida de mayor coste.
Técnica 4: Muestreo de salida y detención temprana
Para algunos casos de uso, no necesitas la salida completa del modelo de lenguaje de gran tamaño (LLM) — necesitas una decisión o una clasificación.
Logprobs para la clasificación.
# Use a small NON-reasoning model here: reasoning-family models
# (GPT-5.x thinking tiers and similar) reject logprobs/logit_bias.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
Pides al modelo que emita un único token (la categoría). El coste es un solo paso de entrada + 1 token de salida. Resulta más rápido y barato, y a menudo funciona tan bien como respuestas más largas.
Logit bias.
Para salidas de conjunto conocido, sesga los logits hacia opciones válidas.
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_bias keys are token IDs (as strings), not words.
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[...],
logit_bias=bias,
max_tokens=1,
)
Orienta al modelo para que emita el tipo de salida correcto. Es barato y fiable para clasificar.
Técnica 5: Procesamiento por lotes
Cuando estás procesando muchos elementos, agrúpalos.
Lotes asincrónicos a nivel de API.
La mayoría de los proveedores ofrecen APIs asíncronas o por lotes que procesan varias solicitudes a menor coste.
- API por lotes de OpenAI: 50% de descuento, SLA de 24 horas.
- Message Batches de Anthropic: 50% de descuento, SLA de 24 horas.
Si tienes trabajo pendiente que no necesita respuesta en tiempo real, procésalo por lotes y paga la mitad.
Lotes en el prompt.
Procesa múltiples elementos en una sola llamada de LLM cuando sea posible.
En lugar de:
[10 separate calls, each classifying one ticket]
Haz:
[1 call, classifying 10 tickets in one prompt]
La única llamada contiene más entrada (10 elementos), pero solo una vez la sobrecarga fija del prompt del sistema y las descripciones de herramientas. El total de tokens es menor que en 10 llamadas separadas.
Advertencia: la calidad puede disminuir con demasiados elementos por prompt. Prueba el punto óptimo para tu caso de uso. Normalmente 5-20 elementos por prompt es aceptable.
Técnica 6: Modelos más pequeños para tareas específicas
Más allá del enrutamiento estándar — considera si una tarea realmente necesita un modelo grande.
Clasificación: un modelo intermedio suele rendir tan bien como uno principal en clasificaciones sencillas. Con los precios actuales (verificados el 2026-07-07), Claude Haiku 4.5 a $1/$5 por M frente a Claude Opus 4.8 a $5/$25 ofrece un ahorro directo de 5x; la gama pequeña de OpenAI frente a GPT-5.5 presenta un múltiplo similar.
Extracción: modelos intermedios funcionan para extracción estructurada. Guarda el modelo principal para los casos que fallan.
Traducción: los modelos especializados o los LLM más pequeños resuelven la mayoría de los casos.
Embeddings: usa modelos especializados, no LLM de propósito general, para generarlos.
El patrón: identifica tus cargas de trabajo “simples y específicas”. Enrútalas al modelo más pequeño que haga el trabajo adecuadamente. Guarda el modelo principal para las tareas complejas y de juicio.
Técnica 7: Modelos pequeños finamente ajustados
Para tareas específicas de alto volumen, ajusta finamente un modelo pequeño.
Ejemplo: 100K solicitudes de clasificación por día.
- GPT-5 sin modificar: €30/día en costes de API.
- Modelo de 8B con ajuste fino e inferencia dedicada: €5-10/día de inferencia, más el coste único del ajuste.
Con suficiente volumen, la inversión en modelos pequeños con ajuste fino se recupera pronto. El cálculo depende de tu volumen.
Lo explicamos en el artículo sobre ajuste fino. El principio es que, cuando coinciden la escala y la especificidad, el ajuste fino se convierte en una potente palanca de costes.
Técnica 8: Filtro previo
En flujos LLM de varios pasos, un filtro barato detecta los casos obvios antes del procesamiento caro.
Ejemplo: clasificación de soporte al cliente + respuesta.
Filtro previo barato:
- “¿Es realmente una pregunta de soporte o spam/ruido?” (clasificación de 1 token en un modelo pequeño.)
- “¿Es una pregunta de FAQ conocida?” (búsqueda de embedding; barata.)
Solo las solicitudes que superan el filtro llegan a la costosa generación de respuestas.
Ahorro: si el 30% de las solicitudes entrantes son ruido o pueden responderse con FAQ, se elimina el 30% de las llamadas caras.
El filtro previo es barato (€0.0001 por llamada) en comparación con la generación de respuesta (€0.05 por llamada). ROI fácil.
Técnica 9: Almacenamiento en caché más allá del almacenamiento en caché de prompts
Más allá del almacenamiento en caché de prompts del proveedor de modelos, almacenamiento en caché a nivel de aplicación:
Almacenamiento en caché de respuestas. Misma consulta, mismo contexto, misma respuesta. Almacena en caché y devuelve sin llamar al modelo.
def cached_call(prompt, model, ttl=3600):
cache_key = hash(prompt + model)
cached = redis.get(cache_key)
if cached:
return cached
response = call_llm(prompt, model)
redis.set(cache_key, response, ttl=ttl)
return response
Para consultas idempotentes, esto elimina completamente las llamadas duplicadas.
Caché de embeddings. Conserva los embeddings ya calculados.
Caché de resultados de recuperación. Conserva durante períodos breves los resultados de búsqueda de una consulta.
Caché de resultados de herramientas. Conserva los resultados de llamadas a herramientas cuando los datos subyacentes cambian con poca frecuencia.
Los niveles de almacenamiento en caché se superponen. En cada capa, ahorras llamadas.
Técnica 10: Ejecución especulativa
Para flujos sensibles a la latencia donde puedes predecir los pasos siguientes, ejecuta especulativamente.
Ejemplo: agente de soporte al cliente. Sabes que el siguiente paso suele ser “resumir el problema” después de que el cliente lo describe. Inicia ese resumen en paralelo con mostrar el reconocimiento al usuario.
Si la predicción es correcta, la respuesta está lista cuando se necesita. Si es incorrecta, has desperdiciado una llamada.
Es una optimización de latencia más que de coste, pero mejora considerablemente la experiencia de usuario en algunos flujos.
Técnica 11: Arbitraje de proveedores
Los precios de modelos similares varían entre proveedores. Aprovéchalo.
Modelos de código abierto en proveedores de inferencia baratos.
Llama 3.3 70B en Together AI: $0.88/M entrada y salida (precio de lista, verificado el 2026-07-07). El nivel de modelos cerrados con el que compite, Claude Sonnet 5: $3/M entrada, $15/M salida (intro $2/$10 hasta 2026-08-31).
Para tareas donde un modelo de código abierto de 70B es suficiente, eso es ~3.4x en entrada y ~17x en salida — digamos 3-17x según tu mezcla de entrada/salida.
El mismo modelo en distintos proveedores.
Algunos modelos de código abierto están alojados por varios proveedores con precios diferentes. Compara el mercado.
Autogestión a gran escala.
A un volumen suficiente (digamos €10K+/mes en un modelo específico), la autogestión se vuelve más barata que las llamadas a la API. Requiere capacidad operativa.
El arbitraje entre proveedores añade complejidad: enrutamiento multiproveedor con alternativa de respaldo y pruebas de calidad para cada variante. Compensa a gran escala.
Técnica 12: Aceleración de inferencia
Para autogestión: optimización de la capa de inferencia en sí misma.
vLLM, TGI, SGLang. Servidores de inferencia optimizados. Ofrecen 2-10x más rendimiento que las implantaciones ingenuas.
Cuantización. Ejecuta los modelos con menor precisión (4-bit, 8-bit). Ofrece 2-4x más rendimiento a cambio de una ligera pérdida de calidad.
Flash Attention, atención paginada. Optimizaciones arquitectónicas habilitadas en servidores modernos.
Batching continuo. Servidores que agrupan solicitudes en curso para una mejor utilización de GPU.
Esto importa para los equipos que se autoalojan a gran escala. En el caso de las APIs, se ocupa el proveedor.
Técnica 13: Streaming
El streaming no reduce el número de tokens, pero mejora la experiencia de usuario y, con ello, la percepción de rentabilidad.
Para salidas largas, los usuarios ven el contenido apareciendo inmediatamente. Pueden leer mientras se completa la generación. Se siente mucho más rápido que esperar la respuesta completa.
Para agentes, el streaming de pasos intermedios da a los usuarios visibilidad sobre el progreso.
Implementación: cada API moderna admite streaming. Úsalo para flujos orientados al usuario.
Técnica 14: Protecciones de presupuesto
Además de optimizar, aplica presupuestos estrictos para evitar costes descontrolados.
Presupuesto por solicitud. Máximo de tokens por solicitud. Detén si se excede.
Presupuesto por usuario. Límite diario o mensual de coste por usuario. Restringe el uso cuando se aproxime.
Presupuesto por funcionalidad. Cada funcionalidad tiene un presupuesto y se desactiva automáticamente al alcanzar 10x el promedio diario.
Presupuesto global. Límite total diario/mensual. Pausa el trabajo no esencial cerca de los límites.
No ahorran dinero de forma directa, pero evitan desastres. Sin estas protecciones, un solo error o ataque puede disparar rápidamente los costes.
Ejemplo práctico: una reducción real de costes
Un equipo que operaba un agente de soporte al cliente tenía una factura de €12,000/mes. Seis meses después, con las técnicas aplicadas, era €1,800/mes — una reducción del 85%.
Los cambios:
-
Caché de prompts. Reestructuración de los prompts para maximizar el prefijo estático. Ahora, ~70% de la entrada está en caché. Ahorro: ~30%.
-
Enrutamiento de modelos. Clasificación y triaje de tickets se movieron de Claude Sonnet a Claude Haiku. Ahorro ~15%.
-
Control de longitud de salida. Respuestas restringidas a 250 palabras desde las anteriores 800-1500. Ahorro ~25%.
-
Filtro previo. Una clasificación barata detecta los tickets que pueden responderse con FAQ desde la caché. Se elimina ~20% de los tickets del flujo caro. Ahorro: ~10%.
-
Caché de respuestas para FAQ. Las preguntas idénticas devuelven respuestas almacenadas. Ahorro: ~5%.
Los porcentajes indicados representan la contribución de cada técnica al ahorro final: suman el ~85% total y cada uno se midió sobre la factura restante tras el cambio anterior. No son multiplicadores independientes que puedas aplicar a tu propia factura.
Calidad: en todas las métricas medidas (satisfacción del cliente, exactitud de las respuestas y tasa de resolución), la calidad se mantuvo o mejoró ligeramente.
Coste de implantación: ~80 horas de ingeniería durante 3 meses. ROI: la inversión se recuperó en 2 semanas.
Errores comunes
Algunos patrones que vemos:
Error 1: no realizar un seguimiento de costes. El equipo desconoce el coste de cada funcionalidad, usuario o llamada. Sin medición no es posible optimizar.
Error 2: Optimizar lo incorrecto. Se dedicaron semanas a reducir los tokens de entrada en un 5% cuando los tokens de salida eran el 80% de la factura. Mide primero; optimiza los principales contribuyentes.
Error 3: regresión de calidad. Se aplicaron recortes de costes sin monitorizar la calidad. Se ahorró dinero, pero se perdieron usuarios. Combina siempre la optimización de costes con baterías de evaluaciones.
Error 4: enrutamiento excesivo. Se envían de forma agresiva a modelos pequeños tareas que en realidad no pueden gestionar. El ahorro es falso.
Error 5: Contaminación de caché. El caché se llena con consultas raras. La mayoría de las entradas de caché se usan una vez. Los fallos de caché dominan. Se necesita una mejor estrategia de caché.
Error 6: omitir la API por lotes. Se utiliza tiempo real cuando podría procesarse por lotes, dejando escapar la mitad del ahorro.
Error 7: sobrediseño. Se construye una optimización de costes compleja para funcionalidades que nunca serán rentables. A veces la respuesta correcta es “eliminar la funcionalidad”.
Error 8: carecer de protecciones presupuestarias. Un solo error provoca un gasto descontrolado: una catástrofe en lugar de un inconveniente menor.
La parte cultural
La disciplina de costes es, en parte, cultural. Los equipos que tienen éxito:
- Tratan el coste como una métrica, no como algo que se considera a posteriori.
- Asignan una persona responsable, a menudo en la intersección entre ingeniería y finanzas.
- Revisan los costes en las métricas semanales.
- Investigan picos inmediatamente.
- Establecen presupuestos por funcionalidad y alertas al superar los umbrales.
- Toman decisiones explícitas sobre coste, calidad y latencia.
Los equipos que no:
- Tratan el coste como un problema ajeno.
- Descubren la factura al final del mes.
- Reaccionan a los picos cuando ya han ocurrido.
- No tienen concepto de presupuesto.
- Evitan debatir los compromisos y optimizan una sola dimensión cada vez.
El cambio cultural es más difícil que el cambio técnico. Pero es lo que hace que los cambios técnicos se mantengan.
Evolución de los precios
Una nota sobre la tendencia más amplia.
El coste por unidad de capacidad ha caído drásticamente año tras año, sobre todo porque los modelos pequeños alcanzan el nivel de los modelos principales de ayer, no porque se desplomen los precios de catálogo de los modelos principales. Trata cualquier cifra de “precio dentro de un año” como una hipótesis modelizada y vuelve a comprobar la referencia de modelos y precios antes de citarla.
Esto significa:
- Algunas optimizaciones pierden importancia con el tiempo (el coste absoluto disminuye de todos modos).
- Algunas cargas de trabajo actualmente no rentables se volverán rentables.
- Diseña a largo plazo: arquitectura limpia > exprimir ahora cada céntimo.
Aun así, la optimización sigue importando aunque bajen los precios. Los sistemas ineficientes desperdician dinero a cualquier precio, y la ventaja competitiva suele favorecer a los equipos que operan con eficiencia y menor coste.
Plan de optimización de costes de 90 días
Para un equipo que parte de “tenemos una funcionalidad de IA y los costes superan lo previsto”:
Semanas 1-2: Medir.
- Instrumentar los costes por llamada.
- Crear paneles por funcionalidad y por usuario.
- Identificar las principales fuentes de coste.
Semanas 3-4: Ganancias rápidas.
- Habilitar almacenamiento en caché de prompts donde sea compatible.
- Reestructurar los 3 prompts principales para maximizar la tasa de aciertos de caché.
- Establecer max_tokens en todas las llamadas.
- Implementar alertas de presupuesto.
Semanas 5-6: Enrutamiento.
- Identificar tareas simples actualmente en modelos principales.
- Crear un enrutador para los 3-5 endpoints con más llamadas.
- Comprobar que no haya regresiones de calidad.
Semanas 7-8: Salida y caché.
- Restringir longitudes de salida donde no sea visible al usuario.
- Añadir caché de respuestas en la aplicación para consultas frecuentes.
- Añadir filtros previos a los flujos de mayor volumen.
Semanas 9-10: Avanzado.
- API de lotes para trabajo no en tiempo real.
- Evaluar alternativas de proveedor.
- Caché de embedding, caché de recuperación.
Semanas 11-12: Refuerzo.
- Protecciones presupuestarias en cada funcionalidad.
- Paneles de costes en las revisiones periódicas del equipo.
- Documentar los patrones para futuras funcionalidades.
Al cabo de los 90 días, una reducción de costes del 50-80% es realista, con la calidad monitorizada y la disciplina integrada.
Mide primero, luego compone los ahorros
Los costes de los LLM pueden reducirse —normalmente en un 60-90%— sin perder calidad. Las técnicas son bien conocidas: caché, enrutamiento, control de salida, procesamiento por lotes, filtrado previo, caché de respuestas, selección de modelos y protecciones presupuestarias.
Por separado, cada técnica ofrece un ahorro modesto. Combinadas, producen reducciones drásticas.
Los equipos que lo hacen bien convierten funcionalidades de IA deficitarias en rentables. Quienes no lo hacen terminan eliminando funcionalidades que deberían haber sido viables.
Mide primero. Optimiza las principales fuentes de gasto. Mantén la monitorización de calidad. Integra la disciplina de costes en el trabajo habitual del equipo.
El resultado son funcionalidades de IA que escalan tanto económica como técnicamente. Así, la IA se convierte en una parte sostenible del producto y no solo en un titular de lanzamiento.
