La mayoría de las funciones LLM en producción las llevan equipos que tratan la factura mensual como un problema que finanzas tiene que escalar. El CFO hace una pregunta, alguien reenvía un dashboard, los ingenieros se encogen de hombros y prometen mirarlo el próximo trimestre. Para cuando alguien se lo toma en serio, la factura es un múltiplo de lo que debería ser y el sistema está demasiado enredado para arreglarlo barato.
El coste es un problema de ingeniería. Tiene palancas de ingeniería. Es una de las decisiones de mayor apalancamiento que puedes diseñar desde el día uno en lugar de descubrir en el mes tres, y la diferencia entre un equipo que diseña para ello y uno que no, suele ser un orden de magnitud en la factura, no unos pocos puntos porcentuales.
Este es el conjunto de palancas al que recurrimos, más o menos en el orden en que importa.
1. Un techo por petición, fijado al inicio
Lo primero que hacemos en cualquier proyecto de LLM es nombrar un techo por petición. No un presupuesto. Un techo: el número por encima del cual una sola llamada hacia el usuario se considera un defecto, no un gasto.
El techo se deriva hacia atrás desde los datos del eval, no hacia adelante desde una suposición del equipo financiero. Coges tu eval set, ejecutas el modelo más barato que pasa la barra de calidad, mides la distribución real de tokens de entrada y salida sobre inputs realistas, y fijas el techo en un múltiplo saludable del p95: suficiente margen para inputs inusuales, lo bastante ajustado para que un prompt descontrolado o una explosión de ventana de contexto haga saltar una alarma en vez de diez mil invocaciones silenciosas.
Una vez que el techo existe, cada decisión de diseño se comprueba contra él. ¿Añades un paso de retrieval? Enséñame el peor caso de tokens. ¿Dejas que el modelo escriba un documento entero? Limita los tokens de salida, en duro, y degrada con gracia si llega al límite. El techo es la cosa desde la que el equipo diseña hacia atrás. Sin él, estás haciendo compras exploratorias con la tarjeta de la empresa.
2. Un techo mensual por tenant, configurable, con un fallback elegante
Un techo por petición detiene una llamada descontrolada. Un techo mensual por tenant detiene un cliente descontrolado.
Cada sistema LLM multi-tenant que hemos visto a escala ha tenido al menos un tenant que, por razones perfectamente legítimas, usaba diez o veinte veces más que la mediana. A veces son power users. A veces un script. A veces una integración que nadie recuerda haber escrito. La respuesta correcta no es sorprenderles con una suspensión; es caer, con suavidad, a un modelo más barato o local una vez que se haya consumido una fracción saludable del techo mensual.
El umbral importa más que el número absoluto. Caer en el último token es hostil. Caer en el primer token es teatro. En algún punto intermedio —bien por debajo del techo pero bien por encima de la mediana— hay un umbral que le da al usuario una experiencia degradada pero funcional y le da a tu equipo tiempo para upsell o investigar. El número debe ser configurable por tenant, porque la respuesta para un plan enterprise es distinta a la del free tier, y porque el número estará mal el primer día.
3. Cacheo agresivo de dos cosas concretas
El cacheo es la palanca de mayor apalancamiento de esta lista, y casi nadie lo hace bien.
Embeddings: cachéalos indefinidamente. Los embeddings son idempotentes: el mismo input y el mismo modelo producen el mismo vector para siempre. No hay razón para recalcularlos. Hashea el input normalizado, guarda el vector, no busques nunca dos veces el mismo string. Sobre cualquier corpus medianamente grande, esto solo es la diferencia entre una factura creíble y una absurda.
Respuestas: cachéalas con TTLs cortos. Cachear respuestas es más difícil porque los outputs no son deterministas y los inputs varían en formas sutiles. Pero en cargas de lectura predominante —"resume esta página", "explica este concepto", "responde esta pregunta tipo FAQ"— un TTL de cache medido en minutos u horas tiene una tasa de aciertos desproporcionada. El tráfico real de producción no está uniformemente distribuido; un pequeño número de queries representa una fracción enorme del volumen, y solo necesitas pagarle al modelo por una de ellas.
La superficie de la cache key requiere cuidado. Quieres que la clave incluya el modelo, la versión de la plantilla de prompt, el contexto de retrieval relevante y una forma normalizada del input del usuario —en minúsculas, con whitespace colapsado, con PII obvia o bien eliminada o bien hasheada antes de tocar la clave. Un SHA-256 sobre la tupla normalizada está bien; es de una sola vía, compone limpiamente y no filtra nada a quien inspeccione la cache después. Acierta con la superficie de la clave una vez y la cache se paga sola durante toda la vida del sistema.
4. Selección de modelo como un ejercicio de tiering
No existe un único mejor modelo. Existe un mejor modelo para una tarea dada con una barra de calidad dada, y ese modelo casi nunca es el frontier.
Hacemos tiering de la carga. Modelos pequeños y baratos para extracción y clasificación no críticas: sacar campos estructurados de un documento, decidir en cuál de tres cubos cae una query, normalizar input de usuario. Modelos frontier para los pasos que realmente requieren razonamiento: síntesis a través de varias fuentes, planificación multi-paso, cualquier cosa donde una respuesta equivocada sea cara. Modelos fine-tuned o destilados para casos estrechos y de alto volumen donde tienes suficientes datos para entrenar y la tarea está lo bastante bien definida como para que la generalidad del frontier se desperdicie.
La regla práctica es: elige el modelo más barato que pase la barra del eval, y suele ser un escalón por debajo del frontier. Los modelos frontier se usan correctamente como fallback cuando aparece algo más difícil, no como default. Un sistema que usa el modelo frontier para cada paso casi siempre paga de más por un factor que da vergüenza una vez que lo mides.
5. Guiado por evals, no por intuición
Todo lo anterior solo funciona si puedes medir la calidad. Sin un eval set, lo más que puedes decir es: "la factura bajó y las quejas de usuarios no subieron, que sepamos, todavía." La primera mitad de esa frase es ingeniería. La segunda mitad es esperanza.
Un eval set no necesita ser elaborado. Unos pocos cientos de inputs representativos con outputs conocidos como buenos, puntuados automáticamente donde sea posible y revisados por un humano donde no, basta para hacer legible cada palanca de coste de arriba. Cambias el modelo, ¿se mueve la puntuación? Añades una cache, ¿se mueve la puntuación? Acortas el prompt, ¿se mueve la puntuación? Sin ese loop, estás adivinando en público.
Este es el trabajo que la IA en sí misma más fiablemente se salta. Casi cada sistema LLM heredado que hemos auditado no tenía eval set, ni regression suite, ni baseline de calidad. Añadir uno suele ser cuestión de unos días de trabajo y desbloquea cada otra palanca de esta lista.
Lo que esto compra de verdad
En sistemas heredados hemos recortado facturas de LLM por factores grandes —cómodamente más de la mitad, a menudo mucho más— sin regresiones medibles de calidad. El truco no es un truco listo. Es preocuparse pronto, medir con honestidad y diseñar hacia atrás desde un techo en lugar de hacia adelante desde un default.
El trabajo no es glamuroso. Es leer logs de prompts, montar eval harnesses, etiquetar cache keys, configurar fallbacks por tenant. Es la capa de operaciones por debajo de la demo, y es exactamente la capa que la demo nunca tiene.
Por qué tiene que hacerlo el ingeniero, no el modelo
Hay una simetría tentadora en la idea de que la IA debería ayudarte a ponerle una correa al coste de la IA. En su mayor parte no lo hace, y la razón es estructural. El modelo no puede razonar de forma fiable sobre su propio envolvente de coste, porque es la cosa que se está presupuestando. Con gusto te recomendará un modelo más capaz cuando el más barato bastaría. Con gusto expandirá un prompt cuando uno más corto puntuaría igual. No va a construir, por sí mismo, el eval set que te diría que cualquiera de esas decisiones estaba mal.
El juicio de ingeniería tiene que venir desde fuera del sistema. Ese es el trabajo. Bien hecho, es la diferencia entre una función LLM que se paga sola y una que silenciosamente se come el margen del producto que se suponía que debía mejorar.