Lo que cuesta realmente ejecutar LLMs en producción (con números)

Todo el mundo habla de integrar IA en sus productos. Pocos hablan de la factura que llega a fin de mes.

En Soamee llevamos dos años construyendo funcionalidades de IA para clientes de distintos sectores: desde chatbots de soporte hasta sistemas RAG para procesamiento de documentos legales. En ese tiempo hemos aprendido que el coste real de ejecutar LLMs en producción tiene muy poco que ver con lo que uno imagina al principio. Las sorpresas, casi siempre, van en la dirección incorrecta.

Este artículo es el que me hubiera gustado tener cuando empezamos. Números reales, escenarios concretos y estrategias que funcionan.

Precios de tokens en 2025-2026: la tabla que necesitas

Antes de hablar de escenarios, necesitamos tener claros los precios base. Los modelos relevantes hoy en producción son estos:

Referencia de tipo de cambio: A efectos prácticos, 1 USD ≈ 0,92 EUR (varía). Los precios de APIs comerciales están denominados en USD.

Una aclaración importante: el precio por token es el coste de los propios tokens generados o consumidos. En producción real, el prompt del sistema (que se repite en cada llamada), el historial de conversación y el contexto de RAG inflan enormemente la cuenta de tokens de entrada. Es el error más común al estimar costes.

Escenarios reales: ¿cuánto cuesta exactamente?

Vamos con números concretos para los cuatro casos de uso más habituales.

Escenario 1: Chatbot de atención al cliente (1.000 consultas/día)

Parámetros típicos:

• Prompt de sistema: 500 tokens (instrucciones, tono, FAQ base)
• Historial de conversación promedio: 800 tokens (4-5 turnos)
• Consulta del usuario: 100 tokens
• Respuesta del modelo: 300 tokens

Total por llamada: ~1.400 tokens input + 300 tokens output

Para un chatbot simple con volumen bajo-medio, GPT-4o mini, Claude Haiku o Gemini Flash son opciones perfectamente válidas a coste mínimo. La clave está en si la calidad de respuesta es suficiente para tu caso de uso.

Escenario 2: Procesamiento de documentos (500 docs/día, ~5 páginas c/u)

Los documentos cambian radicalmente la ecuación. Una página A4 tiene aproximadamente 400-500 palabras, lo que equivale a unos 500-600 tokens.

Parámetros:

• Documento de 5 páginas: ~2.500 tokens de input
• Prompt de instrucciones: 300 tokens
• Resumen/extracción generada: 500 tokens

Total por documento: ~2.800 tokens input + 500 tokens output

Para procesamiento de documentos donde la precisión es crítica (contratos, documentación médica, financiera), Claude Sonnet o GPT-4o justifican su sobrecoste. Para extracción de datos estructurados en documentos más simples, Gemini Flash ofrece un ROI imbatible.

Escenario 3: Asistente de código (200 desarrolladores activos/día)

Un asistente de código tiene un perfil de tokens muy diferente: los snippets de código son densos en tokens (el código con su sintaxis consume más tokens por caracter que el texto natural).

Parámetros estimados por sesión:

• Contexto de código: 3.000 tokens
• Historial de conversación: 1.500 tokens
• Prompt de sistema: 400 tokens
• Respuesta con código: 800 tokens
• Promedio: 4 interacciones/sesión

Total por sesión: ~23.600 tokens input + 3.200 tokens output

Para asistentes de código en equipos medianos, el coste oscila entre 370 y 720 USD/mes dependiendo del modelo. Nada desorbitado, pero hay margen de optimización significativo con caching del contexto del proyecto.

Escenario 4: Sistema RAG (base documental + 2.000 consultas/día)

Los sistemas RAG añaden una capa: el retrieval trae fragmentos relevantes de una base de datos vectorial que se insertan en el prompt de cada consulta.

Parámetros:

• Fragmentos recuperados: 3 chunks × 400 tokens = 1.200 tokens
• Prompt de sistema: 600 tokens
• Consulta del usuario: 150 tokens
• Respuesta generada: 400 tokens

Total por consulta: ~1.950 tokens input + 400 tokens output

En RAG con alto volumen, la diferencia entre modelos premium y económicos empieza a ser muy relevante.

Los costes ocultos que nadie menciona

Los tokens son solo la punta del iceberg. En producción real, hay varias categorías de coste que se ignoran en las estimaciones iniciales:

Infraestructura y observabilidad

• Base de datos vectorial: Pinecone cuesta desde 70 USD/mes para un índice pequeño. Weaviate Cloud o Qdrant tienen opciones más económicas desde 25 USD/mes. Self-hosted en un VPS añade coste de DevOps.
• Monitoring y trazabilidad: Herramientas como LangSmith (desde 39 USD/mes), Langfuse (open source con self-hosting) o Helicone (desde 20 USD/mes) son imprescindibles en producción. Sin ellas, depurar un agente que falla es un infierno.
• API gateway y rate limiting: Gestionar rate limits, reintentos y fallbacks requiere o una solución SaaS o tiempo de engineering.

Latencia y su coste indirecto

La latencia de los LLMs es real y tiene coste de negocio:

• GPT-4o: 500-1.500 ms tiempo de primera respuesta
• Claude Sonnet 4: 400-1.200 ms
• Gemini 2.5 Flash: 200-600 ms
• Llama 3.3 70B (self-hosted, buena GPU): 300-800 ms

Para interfaces de usuario conversacionales, una latencia superior a 2 segundos tiene impacto directo en la satisfacción del usuario. Streaming mitiga la percepción, pero no el tiempo real de respuesta.

El coste indirecto: si tienes workers procesando en batch y la latencia media es 1 segundo por llamada, para 100.000 llamadas/día necesitas suficiente concurrencia para no crear cuellos de botella. Más concurrencia = más infraestructura.

Manejo de errores y reintentos

Los LLMs fallan. Las APIs de OpenAI y Anthropic tienen SLAs de uptime altos (>99,9%), pero en producción con miles de llamadas diarias, los errores ocurren. Un sistema robusto necesita:

• Lógica de reintento con exponential backoff
• Circuit breakers para evitar cascadas de fallos
• Fallback a modelos alternativos cuando el principal no está disponible

Este engineering tiene coste de desarrollo (típicamente 2-4 semanas de trabajo para hacerlo bien) y coste de infraestructura (si tienes redundancia de proveedores).

Coste de llamadas fallidas

Las llamadas que devuelven error, timeout o respuesta inválida también consumen tokens (parcialmente) o tiempo de compute en self-hosted. En un sistema mal optimizado, el 5-10% de las llamadas pueden ser “desperdicio”. Con 10.000 llamadas/día, eso es 500-1.000 llamadas/día de pérdida neta.

Estrategias de optimización: cómo reducir la factura un 40-70%

Después de haber trabajado en varios sistemas en producción, estas son las estrategias que realmente funcionan:

1. Caching semántico (ahorro potencial: 30-60%)

El caching semántico va más allá del caching tradicional de respuestas exactas. En lugar de buscar matches exactos de strings, usa embeddings para encontrar consultas similares y reutilizar la respuesta si la similitud supera un umbral.

Implementación típica:

1. Al recibir una consulta, generar su embedding (coste: fracción de céntimo)
2. Buscar en la cache de embeddings si hay algo similar (cosine similarity > 0.92)
3. Si hay hit, devolver la respuesta cacheada sin llamar al LLM
4. Si no hay hit, llamar al LLM y cachear el resultado

En chatbots con consultas repetitivas (soporte, FAQs), el hit rate puede llegar al 40-60%. En sistemas RAG con preguntas más diversas, el 15-25%. Herramientas como GPTCache o implementaciones propias sobre Redis son opciones viables.

2. Routing de modelos (ahorro potencial: 40-70%)

No todas las consultas necesitan el mismo modelo. Un sistema de routing clasifica la complejidad de cada consulta y la envía al modelo apropiado:

• Consulta simple (“¿Cuál es el horario?”) → Gemini Flash o GPT-4o mini
• Consulta media (“Explícame las condiciones del contrato”) → Claude Haiku o GPT-4o mini
• Consulta compleja (“Analiza estos tres contratos y dame las diferencias principales”) → Claude Sonnet o GPT-4o

El clasificador puede ser otro LLM pequeño (coste mínimo) o un clasificador tradicional entrenado con ejemplos de tu dominio. En sistemas con distribución típica de consultas (70% simples, 20% medias, 10% complejas), el ahorro es enorme.

3. Optimización de prompts (ahorro potencial: 20-40%)

El prompt de sistema es uno de los mayores culpables de inflación de tokens. Hemos visto prompts de 2.000-3.000 tokens que podían reducirse a 400-600 sin perder efectividad. Algunas técnicas:

• Eliminar redundancias: “Eres un asistente de atención al cliente profesional y amable que siempre responde de forma educada y profesional” → “Asistente de soporte. Tono: profesional y directo.”
• Usar estructuras compactas: Listas en lugar de párrafos, YAML en lugar de texto descriptivo
• Mover info estática a context caching (Anthropic y Google ofrecen precios reducidos para prompts cacheados que se repiten en muchas llamadas)

El context caching de Anthropic cobra el prompt de sistema a precio reducido (~0,30 USD/1M tokens vs 3 USD/1M en Sonnet) cuando se usa en múltiples llamadas consecutivas. Para un prompt de sistema de 1.000 tokens con 10.000 llamadas/día, el ahorro es sustancial.

4. Batching y procesamiento asíncrono

Para tareas que no requieren respuesta en tiempo real (procesamiento de documentos, generación de reportes, análisis), el procesamiento en batch permite:

• Usar la Batch API de OpenAI (50% de descuento a cambio de latencia mayor de hasta 24h)
• Optimizar el uso de GPUs en self-hosted evitando infrautilización
• Gestionar mejor los rate limits sin necesidad de infraestructura adicional de cola

Para 500 documentos/día sin necesidad de resultado inmediato, la Batch API de OpenAI reduce la factura a la mitad.

5. Optimización del contexto en RAG

En sistemas RAG, cuánto contexto se pasa al LLM es crítico:

• Retrieval preciso: Mejorar la calidad del retrieval para recuperar solo los chunks más relevantes (3 buenos chunks > 10 mediocres)
• Chunking optimizado: Chunks más pequeños y precisos reducen tokens sin sacrificar calidad
• Reranking: Un modelo de reranking barato (ej: Cohere Rerank) mejora la selección de chunks antes de pasarlos al LLM

Self-hosted vs API: cuándo tiene sentido cada opción

La pregunta que más nos hacen: “¿No sería más barato hostear el modelo nosotros?”

La respuesta honesta: depende, pero para la mayoría de empresas la API comercial gana hasta volúmenes altos.

Costes de self-hosting (Llama 3.3 70B como referencia)

Para ejecutar Llama 3.3 70B con rendimiento de producción necesitas:

• GPU requerida: Mínimo 2× A100 80GB o equivalente para servir con buena throughput
• Coste en AWS: p4d.24xlarge (~32 USD/hora) o g5.48xlarge (~16 USD/hora)
• Instancia dedicada 24/7: 32 USD × 24 × 30 = ~23.000 USD/mes (AWS on-demand)
• Con Reserved Instances (1 año): Se puede bajar a ~11.000-14.000 USD/mes
• Alternativa spot: Posible, pero instabilidad en producción requiere gestión adicional

Alternativas más económicas de self-hosting:

• RunPod o Lambda Labs: 2-4 USD/hora para A100, frente a los 8-16 USD de AWS. Para cargas intermitentes, mucho más viable.
• Ollama + servidor propio: Para volúmenes muy bajos o uso interno, un servidor con 2× RTX 4090 (coste ~3.000 USD) puede amortizarse en 6-12 meses si el volumen lo justifica.

Punto de equilibrio

El breakeven entre API y self-hosting (asumiendo RunPod a 3 USD/hora para Llama 70B equivalente a Claude Haiku en calidad):

• RunPod 24/7: ~2.160 USD/mes
• Claude Haiku equivalente: 0,0023 USD/llamada × N llamadas/mes

Breakeven: 2.160 / 0,0023 ≈ 940.000 llamadas/mes (~31.000 llamadas/día)

Por debajo de ese volumen, la API comercial es más económica cuando se cuenta el coste real del self-hosting (infraestructura, DevOps, actualizaciones de modelos, monitorización). Por encima, self-hosting empieza a tener sentido financiero.

Hay casos donde self-hosting gana independientemente del volumen:

• Datos altamente sensibles que no pueden salir de tu infraestructura (sanidad, finanzas reguladas)
• Latencia ultra-baja donde los milisegundos importan y tienes la GPU cerca del usuario
• Fine-tuning intensivo donde necesitas un modelo muy especializado en tu dominio

El coste real de un proyecto de IA completo

Para dar una perspectiva más completa, estos son los rangos típicos de coste total (no solo tokens) para diferentes tipos de proyectos:

Chatbot de soporte básico (1.000 consultas/día):

• Tokens: 12-240 USD/mes según modelo
• Infraestructura (hosting, DB vectorial): 50-100 USD/mes
• Monitoring: 20-40 USD/mes
• Total: 80-380 USD/mes

Sistema RAG departamental (500 usuarios, base documental de 10K docs):

• Tokens: 200-800 USD/mes
• Vector DB (Pinecone o similar): 70-200 USD/mes
• Infraestructura adicional: 100-200 USD/mes
• Monitoring y observabilidad: 40-80 USD/mes
• Total: 410-1.280 USD/mes

Agente de IA con integraciones (200 usuarios activos, múltiples herramientas):

• Tokens: 500-2.000 USD/mes (los agentes consumen más tokens por los tool calls)
• Infraestructura: 200-500 USD/mes
• Monitoring avanzado: 80-150 USD/mes
• Total: 780-2.650 USD/mes

Estos rangos asumen arquitecturas optimizadas. Sin optimización, los costes pueden ser 2-3 veces mayores.

Conclusión: la IA es rentable si se diseña bien

La IA en producción no es barata si se hace mal, pero tampoco es prohibitiva si se diseña con cabeza. Las diferencias entre una implementación naive y una optimizada pueden ser de 5-10x en costes.

Los principios que aplico en todos los proyectos:

1. Empezar con el modelo más barato que resuelva el problema. Escalar a uno más potente solo si hay evidencia de que lo necesitas.
2. Medir todo desde el primer día: tokens por llamada, tasa de error, latencia, coste por usuario. Sin métricas, no puedes optimizar.
3. Implementar caching desde el principio, no como mejora posterior. Es la optimización de mayor impacto.
4. Presupuestar la infraestructura además de los tokens: el error más común en estimaciones iniciales.
5. Revisar la factura mensualmente y correlacionar con el uso real. Los picos de coste suelen revelar bugs o uso inesperado.

Si estás evaluando integrar IA en tu producto o proceso y quieres una estimación honesta adaptada a tu caso de uso, en Soamee hacemos exactamente eso. Puedes revisar nuestros servicios de IA o contactarnos directamente.

También te puede interesar nuestro artículo sobre cómo construir un agente de IA personalizado con LLM para atención al cliente si ya tienes claro el caso de uso y quieres entender la arquitectura.