Cómo recortar costes de LLM: caché, enrutamiento de modelos y prompts más cortos

Un prototipo con un LLM detrás rara vez cuesta mucho. Luego llega el tráfico, y un sistema que parecía barato durante el desarrollo se ejecuta miles o millones de veces al mes. En ese momento la factura de inferencia se convierte en una partida por la que preguntan en las reuniones. Poner un modelo más pequeño en todas partes es la reacción obvia, y a menudo la equivocada. La mayor parte del ahorro sale de tres decisiones: cómo se llama a los modelos, qué se les envía y qué modelo atiende cada petición. A continuación verás estrategias de caché, enrutamiento y prompts que reducen el gasto sin dañar la calidad que los usuarios realmente notan.

Qué dispara la factura

Varios factores mueven el coste de un LLM:

• cuántas peticiones llegan
• tokens de entrada y tokens de salida
• qué modelo atiende cada llamada
• el tamaño de la ventana de contexto
• con qué frecuencia se repite la misma pregunta
• llamadas a agentes y herramientas
• reintentos tras fallos
• cargas de embeddings y recuperación
• necesidades de procesamiento por lotes

Un chatbot sencillo hace una llamada al modelo por pregunta. Un agente puede encadenar varias para una sola tarea: usuario, agente, recuperación, herramienta, modelo, herramienta, modelo, respuesta final. Si cada eslabón corre sobre un modelo caro, el total se dispara. Por eso el control de costes debe formar parte de la arquitectura desde el principio: añadirlo después de que la factura asuste a alguien es mucho más difícil.

Mide antes de cambiar nada

Optimizar a ciegas es adivinar. Empieza por registrar:

• peticiones al día y tokens por petición
• tokens de entrada frente a tokens de salida
• coste por petición, por usuario, por funcionalidad y por modelo
• tasa de aciertos de caché
• latencia, tasa de errores y tasa de reintentos
• llamadas a herramientas de los agentes

Los datos reales suelen dar sorpresas. Puede que descubras que el 20 % de los usuarios genera el 70 % del gasto, o que un flujo RAG mete enormes cantidades de contexto inútil en cada llamada. Nada de eso aparece hasta que alguien mira.

Guarda en caché el trabajo repetido

La caché es una de las formas más fáciles de saltarse la inferencia por completo. Piensa en un asistente de soporte. Miles de clientes preguntan alguna variante de «¿Cuál es vuestra política de reembolsos?». Si la respuesta apenas cambia, no tiene sentido generarla de nuevo cada vez.

El flujo es corto. Llega una consulta y se revisa la caché. Si hay acierto, la respuesta guardada vuelve al usuario. Si no, se llama al modelo, se guarda el resultado y se envía la respuesta. Las llamadas repetidas al modelo caen en picado.

Caché semántica

Una caché normal necesita que la cadena coincida exactamente, y «¿Cuál es vuestra política de reembolsos?» y «¿Me podéis devolver el dinero?» son cadenas distintas. Una caché semántica compara el significado. Cada petición se representa con embeddings y, cuando la similitud supera un umbral elegido, el sistema reutiliza una respuesta existente. Funciona bien para:

• preguntas frecuentes
• atención al cliente
• asistentes internos de conocimiento
• documentación de producto
• flujos empresariales repetitivos

Ajusta el umbral con cuidado. Si es demasiado laxo, preguntas distintas reciben la misma respuesta; si es demasiado estricto, la caché casi nunca salta.

Enruta según la dificultad

Un error de arquitectura habitual es mandar cada petición al modelo más potente disponible. Compara tres peticiones: «¿Cuál es vuestro horario de soporte?», «Resume esta queja de un cliente» y «Analiza estos documentos financieros e identifica posibles riesgos». Un modelo de razonamiento premium resolvería las tres, pero pagarlo para la primera es un despilfarro.

El enrutamiento de modelos lo soluciona. Las tareas fáciles van a un modelo pequeño y eficiente, las intermedias a uno de gama media y las difíciles a uno de alta capacidad. Un clasificador a la entrada examina cada petición y elige el destino. Un enrutador en producción puede sopesar la complejidad de la consulta, la precisión requerida, la longitud del contexto, la prioridad del usuario, el tipo de tarea, las necesidades de latencia y los límites de coste. El gasto baja de forma notable, y nada obliga a que todo el tráfico pase por un modelo débil.

Recorta el prompt

Los prompts largos cuestan dinero, sobre todo cuando un system prompt enorme acompaña a cada llamada. Imagina 3.000 tokens de instrucciones, 5.000 tokens de contexto recuperado y 500 tokens de entrada del usuario en cada petición. Incluso para una pregunta minúscula, el modelo procesa unos 8.500 tokens.

Revisa los prompts en busca de:

• instrucciones repetidas
• ejemplos que no aportan nada
• contexto duplicado
• reglas de formato excesivas
• detalles irrelevantes
• instrucciones obsoletas
• descripciones de herramientas que nadie usa

Un prompt más corto suele rendir igual que uno largo si plantea la tarea con claridad. El objetivo no es el prompt más corto posible, sino el más pequeño que siga dando el resultado necesario de forma fiable.

En RAG, envía menos fragmentos y mejores

Los pipelines RAG se encarecen cuando se pasan demasiados documentos recuperados al modelo. Supongamos que la recuperación devuelve 20 fragmentos de 1.000 tokens cada uno. Son 20.000 tokens de contexto para una sola petición, y lo más probable es que el modelo no necesite la mayoría.

Un camino mejor es consulta, recuperación, reranking y luego solo los fragmentos más relevantes al LLM. Bajan el consumo de tokens, la latencia y el ruido, y las respuestas incluso pueden mejorar.

Comprime lo que queda

Hasta los documentos relevantes arrastran mucho texto irrelevante. La compresión de contexto extrae las partes útiles antes de que el modelo las vea. Un documento de 10.000 tokens puede reducirse a 1.500 tokens de material pertinente. Compensa con:

• documentos legales
• informes financieros
• documentación técnica
• bases de conocimiento corporativas
• historiales largos de clientes

Limita la salida

Los modelos pueden escribir mucho más de lo que el usuario quiere. Para una pregunta como «¿En qué estado está mi pedido?», no hace falta una respuesta de 1.000 tokens. Fija límites de salida y formatos de respuesta razonables. Para tareas estructuradas, un formato compacto funciona mejor que la prosa:

Status: Shipped
Expected Delivery: Friday
Tracking Available: Yes

Menos tokens de salida significa una factura más baja y, normalmente, también una respuesta más rápida.

Usa código normal donde baste

Puede que sea la regla más importante de la ingeniería de IA: algunas tareas no necesitan un LLM. Comprobar si un pedido supera los 1.000 $ es una línea, if order_value > 1000. El software de toda la vida ya resuelve cálculos, ordenación, filtrado, validación, aritmética de fechas, consultas a bases de datos y reglas de negocio deterministas. Reserva el modelo para donde la comprensión del lenguaje o el razonamiento aporten valor de verdad.

Ata corto a los agentes

Los sistemas de agentes pueden acumular costes de inferencia sorprendentes. Una sola tarea puede disparar una llamada de planificación, otra de selección de herramienta, otra de recuperación, otra de análisis, otra de verificación y otra para la respuesta final. Ejecuta las seis en un modelo grande y el coste se multiplica.

Un diseño mejor puede:

• eliminar bucles de agente innecesarios
• usar herramientas deterministas siempre que se pueda
• limitar el número máximo de iteraciones
• pasar los pasos rutinarios a modelos más pequeños
• guardar en caché los resultados intermedios
• evitar recuperaciones repetidas
• fusionar operaciones compatibles

El objetivo no es hacer menos acciones útiles, sino quitar las que sobran.

Lo que no corre prisa, por lotes

No todo necesita respuesta en tiempo real. La clasificación de documentos, el enriquecimiento de datos, el procesamiento de contenido, la generación de informes, los resúmenes a gran escala y el etiquetado de datasets suelen poder ejecutarse de forma asíncrona o por lotes. Según el proveedor y el diseño de la carga, el procesamiento por lotes mejora el aprovechamiento y abarata los trabajos grandes.

Elige el modelo como un ingeniero

Elegir modelo es una decisión de ingeniería, y conviene juzgarla con varias preguntas:

• Calidad: ¿qué precisión debe tener el resultado?
• Coste: ¿qué precio por petición es aceptable?
• Latencia: ¿con qué rapidez debe llegar la respuesta?
• Contexto: ¿cuánta información debe asimilar el modelo?
• Razonamiento: ¿qué dificultad tiene la tarea?
• Fiabilidad: ¿qué consistencia deben tener los resultados?

Cambia «¿Qué modelo es el mejor?» por «¿Qué modelo basta para esta tarea?». Ese pequeño giro puede transformar la economía en producción.

Demuestra que nada se ha roto

Recortar costes no debería erosionar la calidad en silencio, así que mide cada cambio. Monta un conjunto de evaluación con consultas reales y compara el sistema de partida con el optimizado en precisión, relevancia, veracidad, finalización de tareas, satisfacción del usuario, latencia y coste.

Un ejemplo inventado: la versión de partida logra un 92 % a 0,020 $ por petición y la optimizada un 91 % a 0,009 $. Si el negocio acepta perder un punto de calidad, la segunda opción sale muchísimo más barata de operar.

Cómo encajar las capas

Una aplicación en producción puede encadenar estas ideas en orden: clasificar la petición, revisar la caché, recuperar o procesar datos, filtrar el contexto, enrutar a un modelo, llamar al LLM elegido, validar la salida, guardarla en una caché de respuestas y devolverla al usuario. El modelo caro solo se ejecuta cuando nada antes en la cadena ha podido responder.

Qué ahorro esperar

No tomes un «60 % menos» como una promesa. Los resultados dependen mucho de la carga. Aun así, combinar varias optimizaciones puede traer grandes reducciones. Toma una factura mensual hipotética de 10.000 $ y mira dónde podría encogerse:

• reducir un 20 % las peticiones repetidas
• pasar las cargas adecuadas a modelos más baratos
• quitar tokens de entrada innecesarios
• recuperar y enviar solo el contexto relevante
• eliminar llamadas superfluas a herramientas y modelos
• cortar las respuestas demasiado largas

Juntas, estas medidas pueden recortar una buena parte del total. La clave es que el ahorro suele salir de muchas pequeñas mejoras de arquitectura, no de un truco mágico.

Lista de comprobación antes del lanzamiento

Antes de poner una aplicación LLM bajo uso intensivo, hazte estas preguntas.

• Necesidad: ¿cada paso necesita un LLM? ¿Podría el código determinista hacer parte del trabajo? ¿Están acotados los bucles de los agentes?
• Prompts: ¿están infladas las instrucciones del sistema? ¿Hacen falta los ejemplos? ¿Se cuela contexto irrelevante?
• Recuperación: ¿se recuperan demasiados fragmentos? ¿Hay reranking? ¿Se puede comprimir el contexto?
• Modelos: ¿se usa el modelo más caro donde no hace falta? ¿Se pueden enrutar las peticiones por complejidad?
• Caché: ¿se guardan en caché las peticiones repetidas? ¿Encajaría una caché semántica?
• Salida: ¿se controla la longitud de las respuestas? ¿Tienen sentido las salidas estructuradas?
• Monitorización: ¿se registra el consumo de tokens? ¿Se conoce el coste por funcionalidad? ¿Se vigilan las métricas de calidad junto al coste?

Apunta a lo sostenible, no a lo más barato

«Que la IA salga lo más barata posible» es el objetivo equivocado. Uno mejor es alcanzar la calidad que exige el negocio al menor coste sostenible. Una app de soporte puede usar un modelo pequeño para las preguntas frecuentes sencillas y uno más fuerte para las quejas enrevesadas. Un asistente de programación puede necesitar mucho razonamiento para tareas difíciles. Un pipeline de documentos quizá priorice el rendimiento y la consistencia. No existe una receta universal, y la arquitectura adecuada depende de la carga.

El gasto en LLM no tiene por qué crecer al mismo ritmo que el uso. La caché, el enrutamiento, los prompts más ajustados, un RAG más ligero, la compresión, los agentes eficientes, los límites de salida y la evaluación continua ayudan cada uno a su manera, y la mayor victoria suele ser simplemente evitar llamadas que nunca hicieron falta. Si una aplicación de IA empieza a salir cara, recortar el uso quizá no sea la respuesta. Diseñar el sistema con más cuidado muchas veces sí lo es.