LLMs en produccion: costes, latencia y las metricas que nadie cuenta

La demo es facil, la factura es la sorpresa

Montar una demo con GPT-4 que impresione en una reunion de direccion tarda una tarde. Llevar ese mismo sistema a produccion con 10.000 usuarios y mantenerlo rentable es un proyecto de ingenieria de meses. La distancia entre la demo y la produccion es donde mueren la mayoria de los proyectos de LLM, y las razones rara vez son tecnicas. Son economicas y operacionales.

Llevamos 18 meses operando LLMs en produccion para clientes en logistica, legal y servicios financieros. Este articulo documenta las metricas reales, los costes que no aparecen en los tutoriales, y los patrones que reducen la factura sin sacrificar calidad.

El coste real de los tokens

Los precios de los modelos se publican por millon de tokens. Parece barato. Hasta que calculas cuantos tokens consume tu aplicacion.

Anatomia de una llamada tipica

Un chatbot de atencion al cliente con contexto:

Componente	Tokens (aproximado)
System prompt	500-1.500
Contexto RAG (documentos recuperados)	2.000-8.000
Historial de conversacion (5 turnos)	1.500-3.000
Pregunta del usuario	50-200
Total input	4.050-12.700
Respuesta del modelo	200-800
Total output	200-800

Con GPT-4o (Marzo 2025): input a 2.50 $/M tokens, output a 10.00 $/M tokens. Una llamada tipica: ~0.003-0.012 $. Parece irrelevante. Con 50.000 llamadas al mes: 150-600 $/mes. Con 500.000: 1.500-6.000 $/mes. Y eso es un chatbot sencillo.

Un sistema de procesamiento de documentos que analiza contratos de 30 paginas puede consumir 50.000-80.000 tokens por documento. A 100 contratos/mes con GPT-4o, estamos en 1.500-2.500 $/mes solo en API calls.

La trampa del context window largo

Los modelos con context windows de 128K o 200K tokens invitan a meter todo el contexto posible. “¿Por que hacer RAG si puedo meter el documento entero en el prompt?” Porque el coste escala linealmente con el input. Un prompt de 100.000 tokens con GPT-4o cuesta 0.25 $ por llamada. Con 1.000 llamadas diarias, son 7.500 $/mes.

Ademas, la calidad de las respuestas degrada con contextos muy largos (el efecto “lost in the middle” documentado por Liu et al., 2023). Mas contexto no es siempre mejor contexto.

La escalera de costes por modelo

Modelo	Input ($/M)	Output ($/M)	Caso de uso
GPT-4o	2.50	10.00	Razonamiento complejo
Claude 3.5 Sonnet	3.00	15.00	Analisis y redaccion
GPT-4o mini	0.15	0.60	Clasificacion, extraccion
Claude 3.5 Haiku	0.80	4.00	Tareas rapidas
Llama 3.1 70B (self-hosted)	~0.50*	~0.50*	Alto volumen, control
Mistral Large	2.00	6.00	Alternativa EU

*Coste estimado incluyendo GPU, inferencia en A100/H100.

La diferencia entre usar GPT-4o para todo y usar el modelo adecuado para cada tarea puede ser 10-20x.

Presupuestos de latencia

La latencia de un LLM tiene dos componentes: Time to First Token (TTFT) y tokens por segundo de generacion. Ambos importan, pero de formas diferentes.

TTFT determina cuanto espera el usuario antes de ver algo. Para interfaces interactivas, TTFT > 2 segundos se percibe como lento. Los modelos grandes (GPT-4o, Claude Opus) tienen TTFT de 1-3 segundos. Los modelos pequeños (GPT-4o mini, Haiku) estan en 200-800 ms.

Velocidad de generacion determina cuanto tarda la respuesta completa. GPT-4o genera 50-80 tokens/segundo. Con streaming, el usuario ve la respuesta formarse progresivamente, lo que mejora la percepcion de velocidad aunque la latencia total sea la misma.

Presupuestos por caso de uso

Caso de uso	TTFT max	Latencia total max
Chatbot interactivo	1.5 s	5 s (con streaming)
Autocompletado en tiempo real	200 ms	500 ms
Procesamiento batch (documentos)	No critico	< 30 s/documento
Clasificacion inline	300 ms	1 s
Generacion de emails	2 s	8 s

Si tu caso de uso requiere latencia sub-segundo, los modelos grandes estan descartados para la ruta critica. Necesitas modelos pequeños, fine-tuning, o pre-computacion.

Factores que inflan la latencia

• Distancia al endpoint: las APIs de OpenAI y Anthropic sirven desde US. Para usuarios en Europa, añade 100-200 ms de ida y vuelta. Azure OpenAI con region en West Europe reduce esto a 20-40 ms.
• Input largo: mas tokens de entrada = mas tiempo de procesamiento. Un prompt de 50.000 tokens tarda significativamente mas en procesarse que uno de 5.000, incluso antes de generar output.
• Contention: en momentos de alta demanda, las APIs pueden throttlear o aumentar latencia. No hay SLA de latencia en los planes estandar de OpenAI.

Caching: la optimizacion mas subestimada

El caching semantico es probablemente la optimizacion con mayor ROI en produccion. La idea: si dos preguntas son suficientemente similares, la respuesta cacheada es valida para ambas.

Niveles de cache

Cache exacto: misma pregunta, misma respuesta. Trivial de implementar (hash del prompt como clave, Redis como store). Efectivo para FAQs y consultas repetitivas. En un chatbot de soporte tecnico que operamos, el cache exacto tiene un hit rate del 35%, lo que reduce costes y latencia en esa misma proporcion.

Cache semantico: preguntas similares (no identicas) devuelven la misma respuesta. Requiere embeddings: se genera un vector de la pregunta, se buscan preguntas similares en un indice vectorial (Pinecone, Qdrant, pgvector), y si la similitud supera un umbral (tipicamente 0.95), se devuelve la respuesta cacheada. GPTCache y LangChain tienen implementaciones listas para usar.

Cache de fragmentos: para sistemas RAG, cachear los resultados de la recuperacion (no de la generacion). Si 10 preguntas diferentes recuperan los mismos 3 documentos, la busqueda vectorial se ejecuta una vez y se reutiliza para las 10. Reduce latencia y coste del embedding retrieval.

Invalidacion

El problema clasico del caching aplica multiplicado: ¿cuando invalido una respuesta cacheada? Si los datos subyacentes cambian (nuevo producto, nueva politica, correccion de precio), las respuestas cacheadas pueden ser incorrectas. Estrategia recomendada: TTL (time to live) agresivo para datos volatiles (1-4 horas) y conservador para datos estables (24-72 horas), combinado con invalidacion explicita cuando se detectan cambios en la fuente de datos.

Model routing: el modelo correcto para cada tarea

No todas las tareas necesitan GPT-4. De hecho, la mayoria no. Model routing es el patron de enviar cada peticion al modelo mas economico que pueda resolverla con calidad aceptable.

Router basado en clasificacion

Un clasificador ligero (puede ser un modelo de 3B parametros o incluso reglas) analiza la peticion entrante y decide:

• Tarea simple (clasificacion, extraccion de datos, formato) -> GPT-4o mini o Haiku
• Tarea media (resumen, traduccion, Q&A sobre documentos) -> GPT-4o mini o Sonnet
• Tarea compleja (razonamiento multi-paso, analisis legal, redaccion formal) -> GPT-4o o Opus

El coste del router es negligible comparado con el ahorro. En un sistema que procesamos, el routing reduce el coste medio por llamada un 65% con una degradacion de calidad medida (por evaluadores humanos) inferior al 3%.

Fallback progresivo

Otra estrategia: empezar con el modelo barato y escalar si la calidad no es suficiente. El flujo:

1. Enviar al modelo pequeno
2. Evaluar la respuesta (longitud, confianza, presencia de “no se”)
3. Si la evaluacion falla, reenviar al modelo grande
4. Cachear que esa clase de pregunta requiere modelo grande

Con el tiempo, el sistema aprende que preguntas necesitan que modelo. El coste medio converge al optimo.

Las metricas que deberias monitorizar

Mas alla del clasico “funciona o no funciona”, estas son las metricas que separan un sistema de LLM operacional de uno que se esta desmoronando silenciosamente:

Calidad

• Faithfulness (fidelidad): ¿la respuesta es consistente con el contexto proporcionado? Se mide automaticamente con frameworks como RAGAS o DeepEval. Objetivo: > 0.85.
• Answer relevancy: ¿la respuesta contesta la pregunta? Distinto de fidelidad: una respuesta puede ser fiel a los documentos pero no responder la pregunta. Objetivo: > 0.80.
• Hallucination rate: porcentaje de respuestas que contienen informacion no soportada por el contexto. Objetivo: < 5%. Para datos criticos (precios, fechas, numeros), objetivo: 0%.

Operacionales

• Tokens/request: media y p95. Si crece sin cambios de producto, hay prompt bloat.
• Coste/request: desglosado por modelo. La metrica mas directa de eficiencia.
• Latencia TTFT y total: por modelo y por tipo de tarea.
• Error rate de la API: timeout, rate limiting, errores 5xx del proveedor.
• Cache hit rate: el indicador de cuanto estas ahorrando. Objetivo: > 25% para aplicaciones con queries repetitivas.

Negocio

• Coste por sesion de usuario: cuanto cuesta servir una conversacion completa. Es la metrica que el CFO entiende.
• Deflection rate (si es soporte): porcentaje de consultas resueltas por el LLM sin escalacion humana. El ROI directo.
• Satisfaccion del usuario: thumbs up/down en las respuestas. La unica metrica que conecta calidad percibida con calidad medida.

Los costes que nadie presupuesta

Prompt engineering

El prompt no es algo que se escribe una vez y se olvida. Es un componente vivo que se itera, se testea y se versiona. Hemos dedicado mas de 200 horas de ingeniero en el ultimo año solo a optimizacion de prompts para sistemas en produccion. Eso es un coste de personal que no aparece en la factura del API.

Herramientas que reducen ese coste: PromptFoo para testing sistematico de prompts, LangSmith para tracing y debugging, y un repositorio de prompts versionado con git (si, los prompts deben estar en version control).

Evaluacion continua

Los modelos se actualizan. GPT-4o de enero no se comporta exactamente igual que GPT-4o de abril. Los cambios son sutiles pero pueden romper prompts finamente ajustados. Necesitas un pipeline de evaluacion que ejecute automaticamente tus test cases contra el modelo actual y alerte si la calidad cae. Sin esto, descubres la regresion cuando los usuarios se quejan.

Infraestructura de RAG

Si usas RAG (y probablemente deberias), el coste de la base de datos vectorial, el pipeline de indexacion, y la ingesta de documentos es significativo. Pinecone: desde 70 $/mes para empezar. Qdrant self-hosted: coste de la VM + operacion. pgvector en PostgreSQL: la opcion mas economica si ya tienes Postgres, pero con limitaciones de escala.

La regla de oro

Antes de poner un LLM en produccion, responde estas tres preguntas:

1. ¿Cuanto cuesta servir a un usuario durante un mes? Si no puedes calcularlo, no estas listo para produccion.
2. ¿Que pasa cuando el modelo falla? Timeout, alucinacion, respuesta incorrecta. Cada escenario necesita un fallback definido.
3. ¿Como mido la calidad automaticamente? Si la unica forma de saber si el sistema funciona bien es leer respuestas manualmente, no escalara.

Los LLMs en produccion son un problema de ingenieria, no de ciencia de datos. Los modelos ya son suficientemente buenos. La diferencia esta en como los operas.

Nuestro equipo de IA y machine learning implementa LLMs en produccion con las metricas, el caching y el model routing necesarios para que sean economicamente viables. Si ya tienes un prototipo que necesita pasar a produccion, podemos ayudarte con la ingenieria necesaria. Para el proceso completo de llevar modelos a produccion, consulta nuestro whitepaper sobre MLOps: del notebook al pipeline. Y para un caso de uso aplicado, nuestro articulo sobre IA generativa en logistica muestra como estos patrones funcionan en el sector logistico.