Módulo 1: Decision Framework para Acceso a LLMs

Casos de Uso Reales: Decisiones Justificadas

Descripción de la cápsula

La mejor forma de aprender el framework es viendo casos reales donde otros lo aplicaron.

Esta cápsula presenta 5 proyectos reales (anonimizados) con contexto completo, scorecard de evaluación, decisión tomada, y retrospectiva 6 meses después. Verás:

  • ✅ Decisiones que funcionaron (y por qué)
  • ⚠️ Trade-offs aceptados
  • ❌ Errores (para que no los repitas)

Todos los casos son de proyectos reales de startups, empresas, y side projects entre 2024-2026.


📖 Caso 1: LegalBot - Prioridad Privacidad

Contexto:

Empresa: Estudio legal mediano (50 abogados)
Proyecto: Chatbot para búsqueda de casos previos (jurisprudencia)
Volumen: 200 queries/día (abogados internos)
Datos: CRÍTICOS (expedientes de clientes, confidencialidad absoluta)

Stakeholders:

  • Socio fundador: "Datos NO pueden salir del servidor, cláusula en contrato con clientes"
  • IT Manager: Equipo 2 personas (1 DevOps junior, 1 helpdesk)
  • Budget: $10k setup, $1k/mes operativo

Scorecard:

DimensiónPrioridadEvaluación
PrivacidadCRÍTICAOn-premise OBLIGATORIO
CostoImportanteBudget limitado pero existe
CalidadImportanteBusqueda jurisprudencia (no crítica accuracy 95%+)
VelocidadSecundariaUsuarios internos (5-10s aceptable)
SimplicidadImportanteEquipo junior (needs mentoring)

Decisión: Ollama local (Mixtral 8x7B)

Justificación:

Cumple privacidad (dimensión CRÍTICA):

  • 100% on-premise (servidor local en oficina)
  • Datos NUNCA salen de red interna
  • Compliance con cláusulas de confidencialidad

Costo dentro de budget:

  • Hardware: $5k servidor con RTX A6000 (GPU profesional)
  • Setup: Consultant DevOps 2 semanas = $3k
  • Operativo: $0/mes (solo electricidad ~$50/mes)
  • Total año 1: $8600 < $22k budget (setup $10k + operativo $1k × 12)

Calidad suficiente:

  • Mixtral 8x7B: 70.6% MMLU (suficiente para búsqueda)
  • RAG sobre base de datos jurisprudencia (no respuestas generativas puras)

Trade-offs aceptados:

  • Velocidad: 8s/query (vs 2s con OpenAI) → OK porque usuarios internos
  • Simplicidad: Setup 2 semanas con consultant → OK porque privacidad es NO negociable

Retrospectiva (6 meses después):

✅ Funcionó:

  • Compliance 100% (auditoría pasada sin issues)
  • Costo final: $50/mes electricidad (dentro de lo esperado)
  • Usuarios satisfechos (velocidad 8s aceptable)

⚠️ Challenges:

  • Primera semana: Problemas con VRAM (Mixtral 8x7B requiere 48GB)
    • Solución: Downgrade a Mixtral 8x7B quantized (4-bit)
  • Mes 3: Modelo se corrompe después de update de Ollama
    • Solución: Versionado de modelos + backups

❌ Si repitieran:

  • Contratar DevOps senior (no junior) desde inicio
  • Presupuestar 20% más para hardware (GPUs suben de precio)

Rating: 8/10 ✅ Decisión correcta


📖 Caso 2: TravelAssist - Startup MVP

Contexto:

Empresa: Startup pre-seed (3 fundadores)
Proyecto: Chatbot para recomendaciones de viajes (MVP)
Volumen: 500 usuarios beta, ~2k queries/día
Timeline: 2 semanas para demo con inversionistas

Stakeholders:

  • CEO: "Necesito demo funcionando YA, inversionistas en 2 semanas"
  • CTO (technical founder): Python mid, no DevOps
  • Budget: $300/mes (founders bootstrapping)

Scorecard:

DimensiónPrioridadEvaluación
SimplicidadCRÍTICATimeline 2 semanas, equipo pequeño
VelocidadCRÍTICAUX demo debe impresionar
CostoImportanteBudget ajustado pero existe
CalidadImportanteRecomendaciones deben ser coherentes
PrivacidadSecundariaDatos públicos (destinos turísticos)

Decisión: OpenAI API (GPT-3.5-turbo)

Justificación:

Cumple simplicidad (CRÍTICA):

  • Setup: <4 horas (OpenAI SDK + FastAPI + frontend)
  • Deploy: Vercel frontend + Railway backend = 1 día total
  • Zero infraestructura (CTO puede enfocarse en producto)

Cumple velocidad (CRÍTICA):

  • 1.5s latency (impresiona en demo)
  • Streaming responses (UX fluida)

Costo dentro de budget:

  • 2k queries/día × 30 días = 60k queries/mes
  • 60k × 500 tokens × $0.002/1k = $60/mes
  • ✅ Muy dentro de $300 budget

Trade-offs aceptados:

  • Privacidad: Cloud (OK porque datos son públicos)
  • Vendor lock-in: OpenAI específico (OK para MVP, refactor después si escala)

Retrospectiva (6 meses después):

✅ Funcionó:

  • Demo exitoso: Levantaron $500k seed round
  • Crecimiento: 500 → 5k usuarios (10x)
  • Costo escaló bien: $60 → $600/mes (linealmente)

⚠️ Challenges:

  • Mes 4: OpenAI API down 2 horas (perdieron usuarios)
    • Solución: Implementaron OpenRouter como fallback (Módulo 5)
  • Mes 5: Factura $900 (OpenAI cambió pricing)
    • Solución: Switchearon queries simples a Mixtral (OpenRouter)

🔄 Siguiente paso:

  • Mes 7: Evaluando migración parcial a Ollama para queries simples
  • Mantener OpenAI para queries complejas (estrategia híbrida)

Rating: 9/10 ✅ Decisión excelente para MVP


📖 Caso 3: HealthTech - Enterprise con Compliance

Contexto:

Empresa: Empresa healthcare enterprise (1500 empleados)
Proyecto: Asistente para revisión de notas médicas (análisis sentimiento)
Volumen: 50k notas/día (multi-hospital)
Datos: HIPAA-regulated (información médica sensible)

Stakeholders:

  • Compliance Officer: "HIPAA es NO negociable, multas de $100k+"
  • CTO: Equipo DevOps 10 personas senior
  • CFO: Budget $200k/año (incluyendo hardware)

Scorecard:

DimensiónPrioridadEvaluación
PrivacidadCRÍTICAHIPAA obligatorio (on-premise)
EscalabilidadCRÍTICA50k queries/día (multi-hospital)
CostoImportanteBudget alto pero finite
CalidadImportanteAnálisis sentimiento (no diagnóstico)
VelocidadSecundariaBackground processing (async OK)

Decisión: Ollama cluster (8 nodos con A100 GPUs)

Justificación:

Cumple privacidad (CRÍTICA):

  • 100% on-premise (datacenter hospital)
  • Zero data egress (compliance garantizado)
  • BAA no necesario (no terceros involucrados)

Cumple escalabilidad (CRÍTICA):

  • 8 nodos × 6k queries/día each = 48k queries/día capacity
  • Horizontal scaling (añadir nodos si crece)
  • Load balancer (distribute queries uniformly)

Costo justificado:

  • Hardware: $120k (8 servidores × $15k each)
  • Setup: $30k (consultant + equipo interno 2 meses)
  • Operativo: $2k/mes (electricity + mantenimiento)
  • Total año 1: $174k < $200k budget

Calidad suficiente:

  • Llama 2 70B: 68.9% MMLU (suficiente para análisis sentimiento)
  • Fine-tuning con datos históricos (mejora accuracy +10%)

Trade-offs aceptados:

  • Simplicidad: Setup complejo (2 meses) → OK porque equipo senior
  • Velocidad: 4s/query (vs 1.5s OpenAI) → OK porque background job (no real-time)

Retrospectiva (12 meses después):

✅ Funcionó:

  • HIPAA audit: Passed sin issues (cero findings)
  • Escalabilidad: Crecieron a 80k queries/día (added 4 nodos)
  • Costo año 2: $60k hardware + $24k operativo = $84k/año
    • vs OpenAI hipotético: 80k × 30 × 500 tokens × $0.002/1k = $2.4M/año
    • Ahorro: $2.3M/año

⚠️ Challenges:

  • Mes 2: GPU failure (1 nodo down 48hrs)
    • Solución: Spare GPU (ahora tienen 9 nodos, 1 spare)
  • Mes 6: Model drift (accuracy bajó 5%)
    • Solución: Re-training trimestral con nuevos datos

❌ Si repitieran:

  • Incluir 2 nodos spare desde inicio (redundancia)
  • Contratar ML engineer para fine-tuning (current team no tenía expertise)

Rating: 10/10 ✅ Única opción viable (HIPAA)


📖 Caso 4: EventBot - Tráfico Variable

Contexto:

Empresa: Startup Series A ($5M funding)
Proyecto: Chatbot para eventos (conciertos, deportes)
Volumen: Variable (1k queries/día normal, 50k en eventos grandes)
Picos: Super Bowl, World Cup final = 200k queries/día

Stakeholders:

  • CEO: "No podemos perder usuarios durante eventos grandes (revenue crítico)"
  • CTO: Equipo 5 devs Python mid-senior
  • CFO: $5k/mes budget fijo (no spikes en costo)

Scorecard:

DimensiónPrioridadEvaluación
EscalabilidadCRÍTICA1k → 200k queries/día (200x spike)
Costo predecibleCRÍTICACFO exige $5k/mes flat
VelocidadImportanteUX evento en vivo (real-time)
SimplicidadImportanteEquipo mid puede mantener
PrivacidadSecundariaDatos públicos (eventos)

Decisión inicial: OpenAI API

Problema descubierto mes 2:

  • Super Bowl Sunday: 180k queries/día
  • Factura OpenAI: $5400 ESE DÍA ($162k/mes si fuera constante)
  • CFO: "Budget es $5k/mes, esto es inaceptable"

Pivote a: Modal serverless

Justificación del pivote:

Cumple escalabilidad (CRÍTICA):

  • Autoscaling: 0 → 500 instancias en 2 minutos
  • Cold starts después optimizados (warm pool)

Costo más predecible:

  • Días normales: $50/día = $1500/mes ✅
  • Super Bowl: $2000 ESE DÍA (vs $5400 OpenAI)
  • Promedio mensual: $2500/mes (2 picos/mes) ✅ < $5k budget

Trade-offs aceptados:

  • Complejidad setup: 1 semana (vs 1 día OpenAI) → OK porque team mid-senior
  • Cold starts: Primera request 3s (vs 1.5s) → Warm pool soluciona

Retrospectiva (8 meses después):

✅ Funcionó:

  • 6 eventos grandes manejados sin downtime
  • Costo promedio: $2800/mes (dentro de budget)
  • CFO feliz (predecible)

⚠️ Challenges:

  • Mes 1 post-migración: Cold starts problem (3-5s primera request)
    • Solución: Warm pool (mantener 10 instancias always on)
  • Mes 4: Modal cambió pricing (+20%)
    • Solución: Renegociaron con Modal (enterprise plan, flat rate)

🔄 Evaluando:

  • Mes 8: Considerando Ollama cluster para baseline traffic (1k queries/día)
  • Modal solo para picos (híbrido)
  • Potencial ahorro: $1000/mes

Rating: 7/10 ⚠️ Funciona pero costo sigue siendo challenge


📖 Caso 5: CodeReviewer - Side Project

Contexto:

Tipo: Open source side project (1 maintainer)
Proyecto: CLI tool para code reviews con AI
Volumen: 1k usuarios, ~5k queries/mes (bajo)
Budget: $0 (personal project)

Constraints:

  • Maintainer: Full-time job, 5 hrs/semana disponibles
  • Budget: Cero (no monetiza)
  • Datos: Public GitHub repos (no sensibles)

Scorecard:

DimensiónPrioridadEvaluación
CostoCRÍTICA$0 budget (no exceptions)
SimplicidadCRÍTICA5 hrs/semana disponibles
PrivacidadSecundariaPublic repos
CalidadImportanteCode review debe ser útil
VelocidadSecundariaCLI tool (users wait)

Decisión: LM Studio (desarrollo) + Ollama (producción)

Justificación:

Cumple costo (CRÍTICA):

  • LM Studio: Gratis (maintainer laptop M2 Mac)
  • Ollama: Gratis (users self-host)
  • Operativo: $0/mes

Cumple simplicidad (CRÍTICA):

  • Setup LM Studio: 15 minutos
  • Docs para usuarios: "Install Ollama + Pull Mistral 7B"
  • Mantenimiento: 1 hr/mes (solo bug fixes)

Estrategia:

  • Maintainer usa LM Studio localmente (desarrollo)
  • Users usan Ollama (cada uno en su máquina)
  • CLI tool llama a localhost:11434 (Ollama default)

Trade-offs aceptados:

  • Calidad: Mistral 7B (62.5% MMLU) vs GPT-4 (86%) → Suficiente para code review
  • Velocidad: 10-15s/review (vs 2s OpenAI) → CLI users aceptan
  • UX: Users deben instalar Ollama (friction) → Documentación clara mitiga

Retrospectiva (18 meses después):

✅ Funcionó:

  • 1k → 10k usuarios (10x growth)
  • Costo: $0 (mantuvo gratis)
  • Community contribuyó docs para instalación (redujo support)

⚠️ Challenges:

  • 30% usuarios no pueden instalar Ollama (Windows issues)
    • Solución: Añadieron opción "bring your own OpenAI key"
  • 15% se quejan de velocidad (10s)
    • Solución: Docs explican trade-off (gratis vs rápido)

🔄 Siguiente paso:

  • Considerar freemium model:
    • Free tier: Ollama local (current)
    • Paid tier ($5/mes): OpenAI API (hosted)
  • Podría generar $500/mes (100 users × $5) para sustainability

Rating: 9/10 ✅ Única opción viable con $0 budget


📊 Resumen de Casos

Tabla comparativa:

CasoDimensión CRÍTICADecisiónCosto año 1RatingLesson
LegalBotPrivacidadOllama local$8.6k8/10On-premise solo si NO negociable
TravelAssistSimplicidad + VelocidadOpenAI API$7209/10OpenAI perfecto para MVPs
HealthTechPrivacidad + EscalabilidadOllama cluster$174k10/10Compliance justifica cualquier costo
EventBotEscalabilidad + CostoModal$33.6k7/10Serverless solo si tráfico variable
CodeReviewerCosto ($0)LM Studio/Ollama$09/10Local es única opción con $0 budget

🔗 Recursos adicionales

  1. Case Studies Collection - Más casos reales
  2. Ollama Deployment Guide - Setup production
  3. OpenAI Case Studies - Enterprise examples
  4. r/LocalLLaMA - Community casos locales

➡️ Próximo paso

Siguiente cápsula: 07-errores-comunes-al-elegir.md

Ahora que viste decisiones exitosas, verás los errores más comunes al elegir proveedor:

  • Optimizar costo prematuramente
  • Ignorar skills del equipo
  • No tener plan de fallback
  • Seguir hype sin evaluar

Aprende qué NO hacer.


Tiempo de lectura: 12-15 minutos
Siguiente: 07-errores-comunes-al-elegir.md