Controlar los costes de LLM en flujos de trabajo en producción
La sorpresa de costes más común con los LLM no es un piloto caro. Es un piloto barato que se convierte en un sistema de producción caro — o un proyecto viable cancelado por una proyección alarmante — porque ambos funcionan con economías distintas.
El coste es una propiedad de diseño del flujo de trabajo, no un precio que descubres a fin de mes. Los equipos que lo controlan tratan el coste por ejecución del flujo como un número que se diseña, se mide y se acepta o se rechaza — igual que la precisión.
Por qué los costes del piloto engañan
Un piloto de chat funciona con economía por puesto. Veinte personas haciendo unas pocas preguntas al día están limitadas por la paciencia humana; la factura mensual se mantiene baja casi independientemente del modelo elegido. Un flujo en producción funciona con economía por evento. Se dispara con cada email entrante, cada documento, cada webhook — el volumen lo fija el negocio, no la paciencia, y crece cuando el negocio crece.
Los pilotos, además, no están optimizados por diseño: un modelo grande para cada paso, documentos completos en el contexto, la recuperación volcada al prompt porque nadie tenía motivo para recortarla. Es la forma correcta de validar calidad y la base equivocada para un presupuesto.
De ahí salen los dos modos de fallo. Un equipo extrapola el piloto de forma lineal, ve una factura mensual de cinco cifras y cancela un proyecto que las palancas de abajo habrían abaratado. Otro asume que «en el piloto eran $200» y descubre la economía de producción en la segunda factura.
Las palancas de coste, por orden de impacto
Ajusta el modelo a cada paso. Un flujo no es una llamada a un modelo; son varios pasos de dificultad distinta. Usa un modelo frontera para los pasos realmente difíciles y un modelo pequeño para clasificación, enrutado y extracción. Es la palanca más grande — a menudo 10x por sí sola.
Disciplina de prompt y contexto. Recorta la recuperación a los fragmentos que cambian la respuesta y cachea el prompt de sistema estático. El prompt caching reduce el coste del contexto repetido hasta en un 90% aproximadamente donde está soportado.
Agrupa y pasa a asíncrono. La mayoría de los pasos no necesitan una respuesta interactiva. Las APIs de batch suelen costar alrededor de la mitad de la tarifa interactiva, y las colas asíncronas suavizan los picos.
Cachea respuestas repetidas. Si la misma pregunta llega cada día, sirve la respuesta aprobada desde una caché y llama al modelo solo cuando no hay coincidencia.
Controla la longitud de salida. Los tokens de salida suelen costar unas cinco veces más que los de entrada. Restringe las salidas a JSON con esquema, fija longitudes máximas por paso y nunca dejes que un paso de clasificación escriba una redacción.
Convierte el coste por ejecución en criterio de aceptación. Registra tokens y coste por paso y por ejecución desde el primer día, y pon ese número junto a las métricas de calidad en cada demo. Lo que no se mide no se gestiona.
El orden importa. Muchos equipos empiezan por los trucos de caché, pero el ajuste del modelo y la disciplina de contexto suelen aportar más que todo lo demás junto.
Un ejemplo calculado: triaje de soporte con 3.000 emails al mes
Toma un flujo estándar de triaje de emails de soporte: clasificar cada email entrante, extraer campos estructurados y redactar una respuesta para el 40% aproximado que la necesita. Sin optimizar, cada email supone el hilo completo más contexto recuperado de la base de conocimiento — digamos 6.000 tokens de entrada y 800 de salida.
| Diseño | Coste por email | Mensual con 3.000 emails |
| --- | --- | --- |
| Modelo frontera en cada paso, contexto completo | ~$0.15 | ~$450 |
| Modelo de gama media en cada paso, mismos prompts | ~$0.03 | ~$90 |
| Por niveles: el modelo pequeño clasifica y extrae; el de gama media redacta el 40%, contexto recortado, prompt de sistema cacheado | ~$0.006 | ~$18 |
Las cifras son ilustrativas, calculadas a partir de los rangos públicos de precio por token de 2026 — lee las proporciones, no los absolutos. La diferencia de 25x sale de decisiones de diseño, no de negociar un descuento.
Con 3.000 emails al mes, todas las filas son asumibles, y así es exactamente como se forma la trampa: nada fuerza la disciplina hasta que lo hace el volumen. El mismo flujo con 300.000 eventos al mes es la diferencia entre unos $45,000 y unos $1,800. Y bajar de nivel debe verificarse paso a paso contra un conjunto de evaluación, no aplicarse como rebaja general — elegir el modelo Claude adecuado por paso es una decisión en sí misma.
Cuándo un paso debe salir del LLM
Pasado cierto volumen, la llamada al modelo más barata es la que dejas de hacer. Las señales:
Un paso de clasificación de alto volumen con etiquetas estables — un modelo pequeño con fine-tuning, o embeddings más un clasificador clásico, hace el mismo trabajo por una fracción del precio.
Una transformación determinista — parseo de fechas, conversión de divisas, búsquedas, mapeo de esquemas — pertenece al código normal, nunca a una llamada al modelo.
Las mismas respuestas servidas una y otra vez — promociona las salidas revisadas a una caché o a una tabla de reglas y reserva el modelo para los casos realmente nuevos.
Un solo paso domina la factura a gran volumen — el fine-tuning puede encoger el propio prompt, porque un modelo afinado necesita menos instrucciones y ejemplos por llamada.
El fine-tuning no es gratis aunque entrenar sea barato: arrastra curación del dataset, evaluación y reentrenos cada vez que la tarea cambia. Justifícalo con aritmética — ahorro mensual proyectado frente a ese coste de mantenimiento — y deja que la misma aritmética te proteja en la dirección contraria: nadie debería hacer fine-tuning para ahorrar $70 al mes.
En nuestros sprints, el coste por ejecución del flujo queda escrito en los criterios de aceptación, y la demo semanal muestra el panel de costes junto a las métricas de calidad — consulta cómo se delimitan los sprints en paquetes. En la entrega sabes lo que cuesta un mes de producción antes de comprometerte a uno. La regla práctica: si hoy no puedes decir cuánto cuesta una ejecución de tu flujo, eso — y no la elección de modelo — es lo primero que hay que arreglar.