LLMs en producción: costes, latencia y las métricas que nadie cuenta
La demo es fácil, la factura es la sorpresa
Montar una demo con GPT-4 que impresione en una reunión de dirección tarda una tarde. Llevar ese mismo sistema a producción con 10.000 usuarios y mantenerlo rentable es un proyecto de ingeniería de meses. La distancia entre la demo y la producción es donde mueren la mayoría de los proyectos de LLM, y las razones rara vez son técnicas. Son económicas y operacionales.
Llevamos 18 meses operando LLMs en producción para clientes en logística, legal y servicios financieros. Este artículo documenta las métricas 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 millón de tokens. Parece barato. Hasta que calculas cuántos tokens consume tu aplicación.
Anatomía de una llamada típica
Un chatbot de atención al cliente con contexto:
| Componente | Tokens (aproximado) |
|---|---|
| System prompt | 500-1.500 |
| Contexto RAG (documentos recuperados) | 2.000-8.000 |
| Historial de conversación (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 típica: ~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 páginas 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 qué 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.
Además, la calidad de las respuestas degrada con contextos muy largos (el efecto “lost in the middle” documentado por Liu et al., 2023). Más 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 | Análisis y redacción |
| GPT-4o mini | 0.15 | 0.60 | Clasificación, extracción |
| Claude 3.5 Haiku | 0.80 | 4.00 | Tareas rápidas |
| 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 generación. Ambos importan, pero de formas diferentes.
TTFT determina cuánto 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) están en 200-800 ms.
Velocidad de generación determina cuánto tarda la respuesta completa. GPT-4o genera 50-80 tokens/segundo. Con streaming, el usuario ve la respuesta formarse progresivamente, lo que mejora la percepción 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 crítico | < 30 s/documento |
| Clasificación inline | 300 ms | 1 s |
| Generación de emails | 2 s | 8 s |
Si tu caso de uso requiere latencia sub-segundo, los modelos grandes están descartados para la ruta crítica. Necesitas modelos pequeños, fine-tuning, o pre-computación.
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 región en West Europe reduce esto a 20-40 ms.
- Input largo: más tokens de entrada = más tiempo de procesamiento. Un prompt de 50.000 tokens tarda significativamente más 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 estándar de OpenAI.
Caching: la optimización más subestimada
El caching semántico es probablemente la optimización con mayor ROI en producción. La idea: si dos preguntas son suficientemente similares, la respuesta cacheada es válida 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 técnico que operamos, el cache exacto tiene un hit rate del 35%, lo que reduce costes y latencia en esa misma proporción.
Cache semántico: preguntas similares (no idénticas) devuelven la misma respuesta. Requiere embeddings: se genera un vector de la pregunta, se buscan preguntas similares en un índice vectorial (Pinecone, Qdrant, pgvector), y si la similitud supera un umbral (típicamente 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 recuperación (no de la generación). Si 10 preguntas diferentes recuperan los mismos 3 documentos, la búsqueda vectorial se ejecuta una vez y se reutiliza para las 10. Reduce latencia y coste del embedding retrieval.
Invalidación
El problema clásico del caching aplica multiplicado: ¿cuándo invalido una respuesta cacheada? Si los datos subyacentes cambian (nuevo producto, nueva política, corrección de precio), las respuestas cacheadas pueden ser incorrectas. Estrategia recomendada: TTL (time to live) agresivo para datos volátiles (1-4 horas) y conservador para datos estables (24-72 horas), combinado con invalidación explícita 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 mayoría no. Model routing es el patrón de enviar cada petición al modelo más económico que pueda resolverla con calidad aceptable.
Router basado en clasificación
Un clasificador ligero (puede ser un modelo de 3B parámetros o incluso reglas) analiza la petición entrante y decide:
- Tarea simple (clasificación, extracción de datos, formato) -> GPT-4o mini o Haiku
- Tarea media (resumen, traducción, Q&A sobre documentos) -> GPT-4o mini o Sonnet
- Tarea compleja (razonamiento multi-paso, análisis legal, redacción 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 degradación 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:
- Enviar al modelo pequeño
- Evaluar la respuesta (longitud, confianza, presencia de “no sé”)
- Si la evaluación falla, reenviar al modelo grande
- Cachear que esa clase de pregunta requiere modelo grande
Con el tiempo, el sistema aprende qué preguntas necesitan qué modelo. El coste medio converge al óptimo.
Las métricas que deberías monitorizar
Más allá del clásico “funciona o no funciona”, estas son las métricas que separan un sistema de LLM operacional de uno que se está desmoronando silenciosamente:
Calidad
- Faithfulness (fidelidad): ¿la respuesta es consistente con el contexto proporcionado? Se mide automáticamente 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 información no soportada por el contexto. Objetivo: < 5%. Para datos críticos (precios, fechas, números), objetivo: 0%.
Operacionales
- Tokens/request: media y p95. Si crece sin cambios de producto, hay prompt bloat.
- Coste/request: desglosado por modelo. La métrica más 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 cuánto estás ahorrando. Objetivo: > 25% para aplicaciones con queries repetitivas.
Negocio
- Coste por sesión de usuario: cuánto cuesta servir una conversación completa. Es la métrica que el CFO entiende.
- Deflection rate (si es soporte): porcentaje de consultas resueltas por el LLM sin escalación humana. El ROI directo.
- Satisfacción del usuario: thumbs up/down en las respuestas. La única métrica 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 más de 200 horas de ingeniero en el último año solo a optimización de prompts para sistemas en producción. Eso es un coste de personal que no aparece en la factura del API.
Herramientas que reducen ese coste: PromptFoo para testing sistemático de prompts, LangSmith para tracing y debugging, y un repositorio de prompts versionado con git (sí, los prompts deben estar en version control).
Evaluación 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 evaluación que ejecute automáticamente tus test cases contra el modelo actual y alerte si la calidad cae. Sin esto, descubres la regresión cuando los usuarios se quejan.
Infraestructura de RAG
Si usas RAG (y probablemente deberías), el coste de la base de datos vectorial, el pipeline de indexación, y la ingesta de documentos es significativo. Pinecone: desde 70 $/mes para empezar. Qdrant self-hosted: coste de la VM + operación. pgvector en PostgreSQL: la opción más económica si ya tienes Postgres, pero con limitaciones de escala.
La regla de oro
Antes de poner un LLM en producción, responde estas tres preguntas:
- ¿Cuánto cuesta servir a un usuario durante un mes? Si no puedes calcularlo, no estás listo para producción.
- ¿Qué pasa cuando el modelo falla? Timeout, alucinación, respuesta incorrecta. Cada escenario necesita un fallback definido.
- ¿Cómo mido la calidad automáticamente? Si la única forma de saber si el sistema funciona bien es leer respuestas manualmente, no escalará.
Los LLMs en producción son un problema de ingeniería, no de ciencia de datos. Los modelos ya son suficientemente buenos. La diferencia está en cómo los operas.
Nuestro equipo de IA y machine learning implementa LLMs en producción con las métricas, el caching y el model routing necesarios para que sean económicamente viables. Si ya tienes un prototipo que necesita pasar a producción, podemos ayudarte con la ingeniería necesaria. Para el proceso completo de llevar modelos a producción, consulta nuestro whitepaper sobre MLOps: del notebook al pipeline. Y para un caso de uso aplicado, nuestro artículo sobre IA generativa en logística muestra cómo estos patrones funcionan en el sector logístico.
