1. Introducción: De Notebook a Producción

Descripción

Lo que cambia cuando tus prompts sirven a usuarios reales: SLAs de latencia, presupuestos de costo, requisitos de reliability, versioning, monitoring. De experimentación sin fricción a producción con responsabilidad.

El Salto de Notebook a Producción

Hay un momento en todo proyecto LLM cuando pasas de "esto funciona en mi máquina" a "esto necesita funcionar para mis usuarios". Ese salto es más grande de lo que parece.

NOTEBOOK:
─────────
prompt = "Clasifica esto: {texto}"
response = client.chat.completions.create(...)
print(response.choices[0].message.content)
# Funciona ✓

PRODUCCIÓN (lo que en realidad necesitas):
──────────────────────────────────────────
- ¿Qué pasa si la API de OpenAI cae?
- ¿Qué pasa si el output tiene formato incorrecto?
- ¿Cómo sé si la calidad está degradando?
- ¿Cuánto me costará al mes con 10,000 usuarios?
- ¿Puedo hacer rollback si un cambio de prompt rompe algo?
- ¿Cómo sé si la latencia está superando el SLA de 3 segundos?

Qué Cambia en Producción

Los 5 Pilares de Producción

Este módulo cubre los 5 pilares que hacen que un sistema LLM sea production-ready:

1. Versioning y Registries

Sin versioning, cada cambio de prompt es irreversible y opaco:

Antes: "Cambié el prompt para mejorar X, ahora está peor pero no sé cómo regresar"
Después: prompt_registry.rollback("clasificador", to_version="v1.2")

2. Cost Optimization

Sin optimización, el costo crece de forma no lineal con los usuarios:

# Sin optimización:
# 1,000 usuarios/día × 500 tokens/request × $0.60/1M tokens = $0.30/día

# Con optimización (prompt comprimido + caching + routing):
# Mismo tráfico → $0.08/día (73% reducción)

3. Caching

Sin caché, cada request llama a la API — incluso queries idénticas o muy similares:

# Sin caché: 1,000 requests de "¿Cuál es el horario de atención?" → $1.50/día
# Con caché (TTL 24h): mismos requests → $0.05/día el segundo día

4. Prompt Management

Sin un sistema de gestión, los prompts viven en el código, en archivos sin estructura, o en la cabeza del desarrollador:

Sin gestión: prompt está hardcodeado en 3 archivos distintos
Con gestión: prompt_manager.get("clasificador", version="latest")

5. Monitoring y Observability

Sin monitoring, eres el último en saber cuando algo falla:

Sin monitoring: "Oye, el clasificador lleva 2 días respondiendo basura"
Con monitoring: Alerta a los 5 minutos → "Accuracy bajó de 94% a 67%"

El Costo de No Prepararse

Veamos los números reales de no prepararse para producción:

# Escenario: Clasificador de sentimiento, 10,000 requests/día

# Sin optimización de costo:
requests_por_dia = 10_000
tokens_promedio = 800  # Prompt largo sin optimizar
precio_input = 0.15 / 1_000_000   # GPT-4o-mini
precio_output = 0.60 / 1_000_000

costo_diario = requests_por_dia * tokens_promedio * precio_input
costo_mensual_sin_opt = costo_diario * 30
print(f"Sin optimización: ${costo_mensual_sin_opt:.2f}/mes")

# Con optimización (prompt 200 tokens + 40% cache hit rate):
tokens_optimizado = 200
cache_hit_rate = 0.40
requests_efectivos = requests_por_dia * (1 - cache_hit_rate)
costo_con_opt = requests_efectivos * tokens_optimizado * precio_input * 30
print(f"Con optimización: ${costo_con_opt:.2f}/mes")
print(f"Ahorro: ${costo_mensual_sin_opt - costo_con_opt:.2f}/mes")

Arquitectura de un Sistema LLM Production-Ready

CLIENTE
   │
   ▼
┌──────────────────────────────────────────────┐
│              API GATEWAY                      │
│  Rate limiting, Auth, Input validation        │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│           CACHE LAYER                         │
│  Exact match + Semantic cache                 │
│  Cache hit? → Return immediately              │
└──────────────────┬───────────────────────────┘
                   │ Cache miss
                   ▼
┌──────────────────────────────────────────────┐
│         PROMPT MANAGER                        │
│  Get prompt by name + version                 │
│  Render with variables                        │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│          MODEL ROUTER                         │
│  Classify complexity → route to right model   │
│  gpt-4o-mini (70%) vs gpt-4o (30%)            │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│         LLM API (OpenAI)                      │
│  With retry logic, timeout, error handling    │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│       OUTPUT VALIDATOR                        │
│  Format check, safety check                  │
│  Retry if invalid, fallback if needed         │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│         MONITORING                            │
│  Log latency, cost, tokens, quality sample    │
│  Emit metrics to dashboard                    │
└──────────────────────────────────────────────┘

Roadmap del Módulo 8

Diferencia entre Optimización y Negligencia

Una advertencia antes de empezar: la optimización prematura es el enemigo. Pero hay una diferencia entre optimización prematura y negligencia de producción:

NEGLIGENCIA (evitar):
✗ Sin manejo de errores en llamadas a la API
✗ Sin límite de tokens (riesgo de costos infinitos)
✗ Sin versioning de prompts
✗ Sin monitoring básico

MÍNIMO VIABLE DE PRODUCCIÓN (siempre tener):
✓ Error handling con retries
✓ max_tokens configurado
✓ Variables de entorno para API keys
✓ Logging básico de errores
✓ Una forma de hacer rollback

OPTIMIZACIÓN AVANZADA (cuando el sistema escala):
→ Caching semantic
→ Model routing
→ Prompt compression
→ Full observability stack

Checklist de Lectura del Módulo

Antes de deployar cualquier sistema LLM a producción, deberías poder responder:

• ¿Tienes versioning de tus prompts con forma de hacer rollback?
• ¿Sabes el costo estimado por request y por mes?
• ¿Tienes caching para queries repetidas?
• ¿Tienes un sistema para gestionar y actualizar prompts?
• ¿Tienes monitoring de latencia, errores y calidad?
• ¿Completaste el production checklist antes del deploy?

Si respondo "no" a alguna, este módulo te dará las herramientas para resolverlo.

Ejercicios

Ejercicio 1: Auditoría de tu sistema actual

Si tienes un sistema LLM en producción o en desarrollo, haz esta auditoría:

1. ¿Cuánto cuesta por mes al nivel de tráfico actual y proyectado?
2. ¿Puedes hacer rollback a una versión anterior del prompt en < 5 minutos?
3. ¿Tienes alertas cuando la latencia sube o la calidad cae?

# Herramienta simple de auditoría
def auditar_sistema_llm(
    requests_por_dia: int,
    tokens_promedio_request: int,
    tiene_versioning: bool,
    tiene_caching: bool,
    tiene_monitoring: bool,
    tiene_error_handling: bool
) -> dict:
    """Genera un score de readiness de producción."""
    
    # Calcular costo mensual estimado
    precio_input = 0.15 / 1_000_000  # GPT-4o-mini
    costo_diario = requests_por_dia * tokens_promedio_request * precio_input
    costo_mensual = costo_diario * 30
    
    # Score de readiness
    checks = {
        "versioning": tiene_versioning,
        "caching": tiene_caching,
        "monitoring": tiene_monitoring,
        "error_handling": tiene_error_handling
    }
    
    score = sum(checks.values()) / len(checks) * 100
    
    return {
        "costo_mensual_estimado": f"${costo_mensual:.2f}",
        "readiness_score": f"{score:.0f}/100",
        "checks": checks,
        "recomendaciones": [k for k, v in checks.items() if not v]
    }

# Ejemplo:
resultado = auditar_sistema_llm(
    requests_por_dia=5000,
    tokens_promedio_request=600,
    tiene_versioning=True,
    tiene_caching=False,  # Falta
    tiene_monitoring=False,  # Falta
    tiene_error_handling=True
)
print(resultado)

Ejercicio 2: Estimar el costo de tu sistema

Dado el siguiente perfil de uso, estima el costo mensual y el potencial de ahorro con caching:

• 50,000 requests/día
• 400 tokens por request promedio
• 30% de las queries son repetidas (potencial de cache)

def estimar_costo_con_caching(
    requests_dia: int,
    tokens_promedio: int,
    cache_hit_rate: float,
    precio_input_por_millon: float = 0.15
) -> dict:
    precio_por_token = precio_input_por_millon / 1_000_000
    
    # Sin caché
    costo_sin_cache = requests_dia * tokens_promedio * precio_por_token * 30
    
    # Con caché
    requests_efectivos = requests_dia * (1 - cache_hit_rate)
    costo_con_cache = requests_efectivos * tokens_promedio * precio_por_token * 30
    
    ahorro = costo_sin_cache - costo_con_cache
    
    return {
        "costo_mensual_sin_cache": f"${costo_sin_cache:.2f}",
        "costo_mensual_con_cache": f"${costo_con_cache:.2f}",
        "ahorro_mensual": f"${ahorro:.2f}",
        "porcentaje_ahorro": f"{ahorro/costo_sin_cache*100:.0f}%"
    }

resultado = estimar_costo_con_caching(50_000, 400, 0.30)
print(resultado)
# {'costo_mensual_sin_cache': '$90.00',
#  'costo_mensual_con_cache': '$63.00',
#  'ahorro_mensual': '$27.00',
#  'porcentaje_ahorro': '30%'}

Resumen

• Producción requiere más que código funcional: SLAs, costos, reliability, versioning, monitoring
• Los 5 pilares: Versioning, Cost, Caching, Management, Monitoring
• Arquitectura completa: Cache → Prompt Manager → Router → LLM → Validator → Monitor
• Mínimo viable: Error handling, max_tokens, secrets en env, logging básico, rollback posible
• Este módulo: Herramientas concretas para cada pilar, con código ejecutable

Prerequisitos del Módulo

Antes de continuar, asegúrate de estar cómodo con:

• Python: Funciones, clases, decoradores, manejo de excepciones
• OpenAI SDK: Chat completions, structured output, temperature y max_tokens
• Pydantic: Validación de inputs y outputs
• Variables de entorno: os.getenv(), .env files con python-dotenv
• Git básico: Commits, branches, tags — necesarios para prompt versioning
• JSON/YAML: Para configuración y almacenamiento de prompts

Si completaste los Módulos 1-7, tienes todo lo necesario. Este módulo toma las técnicas que aprendiste y les agrega la capa de robustez que necesitan para servir usuarios reales.

Preguntas Frecuentes

¿Necesito un framework como LangChain para producción? No necesariamente. Python puro + OpenAI SDK + buenas prácticas de ingeniería te llevan lejos. Los frameworks ayudan en la orquestación compleja, pero añaden dependencias y abstracciones. Este módulo te enseña los fundamentos que aplican con o sin framework.

¿Cuál es el error más común al pasar a producción? No tener un plan de costos. Un prompt que cuesta $0.001 por llamada se ve insignificante, pero a 100,000 requests/día, es $3,000/mes. La Cápsula 03 te da las herramientas para estimar, optimizar y controlar costos.

¿Cuánto tiempo tarda poner un sistema LLM en producción? Si tienes el prompt funcionando, los 5 pilares de este módulo se pueden implementar en 1-2 semanas. El mínimo viable (error handling + max_tokens + secrets + logging + rollback) se puede hacer en un día.

¿Necesito infraestructura especial? Para empezar, no. Una API (FastAPI/Flask) en cualquier servicio de hosting es suficiente. Cuando escales, necesitarás caching (Redis), colas de trabajo (Celery/RQ), y monitoring (Prometheus/Grafana o servicios como Datadog). Las cápsulas 04 y 06 cubren esto progresivamente.

Recursos adicionales

1. OpenAI Production Best Practices — Guía oficial de OpenAI
2. Anthropic Production — Mejores prácticas de Anthropic
3. LLMOps: The Guide — MLOps community
4. Building LLM Applications for Production — Chip Huyen
5. The Production LLM Checklist — Eugene Yan