Módulo 1: Decision Framework para Acceso a LLMs

Errores Comunes al Elegir Proveedor LLM

Siguiente →

Descripción de la cápsula

Aprender de los errores de otros es más barato que cometerlos tú mismo.

Esta cápsula documenta los 7 errores más comunes al elegir proveedor LLM, basados en experiencia real de proyectos fallidos, pivotes costosos, y decisiones que generaron tech debt.

Cada error incluye:

  • 🚫 Qué se hizo mal
  • ⚠️ Por qué es problemático
  • ✅ Cómo evitarlo
  • 📖 Ejemplo real

Objetivo: Que NO cometas estos errores en tu proyecto.

❌ Error #1: Optimizar Costo Prematuramente

Qué se hizo mal:

"Ollama es gratis, voy a usarlo desde día 1 para ahorrar costos."

Eligen Ollama local sin evaluar otras opciones, porque $0/mes operativo es atractivo. Ignoran que setup toma 2 semanas, equipo no tiene skills, y hardware cuesta $3k.

Por qué es problemático:

  1. Costo REAL es mayor:

    • Hardware: $2-5k upfront
    • DevOps time: 40-80 horas ($2-4k)
    • Mantenimiento: $200-500/mes
    • Total año 1: $5-10k

  2. Comparado con OpenAI:

    • Volumen típico startup: 5k queries/día
    • OpenAI cost: $75/mes = $900/año
    • Ollama es 5-10x MÁS CARO año 1

  3. Opportunity cost:

    • 2 semanas setup = no shipping features
    • Competidor con OpenAI lanza primero

Ejemplo real:

Startup: E-commerce chatbot
Decisión: Ollama local para "ahorrar"
Resultado:

  • Semana 1-2: Setup Ollama (servidor, GPU, networking)
  • Semana 3: Problemas VRAM (modelo no carga)
  • Semana 4: Downgrade a modelo más pequeño (peor calidad)
  • Semana 5: CTO se rinde, migra a OpenAI API en 1 día
  • Costo total: $4k desperdiciados + 1 mes perdido

Qué debieron hacer:

  • Empezar con OpenAI ($75/mes)
  • Validar producto-market fit primero
  • Migrar a Ollama DESPUÉS si escala (>50k queries/día)

✅ Cómo evitarlo:

Regla: Optimiza costo DESPUÉS de validar product-market fit

  1. Fase MVP (0-6 meses):

    • Usa opción más SIMPLE (OpenAI API)
    • Enfócate en producto, no en infra
    • Costo típico: $50-500/mes (aceptable para validar)

  2. Fase Growth (6-18 meses):

    • Si volumen crece 10x, ENTONCES evalúa alternativas
    • Costo OpenAI > $2k/mes → Considera Ollama/OpenRouter

  3. Fase Scale (18+ meses):

    • Volumen alto (millones queries/mes)
    • Ollama cluster tiene sentido (ROI positivo)

Excepción: On-premise OBLIGATORIO (compliance) → Ollama desde día 1 es válido.

❌ Error #2: Ignorar Skills del Equipo

Qué se hizo mal:

"Modal es la arquitectura ideal (serverless, autoscaling). Vamos con eso."

Eligen tecnología "best practice" sin evaluar si equipo puede implementarla. DevOps junior no entiende cold starts, no sabe debuggear lambdas, proyecto se estanca.

Por qué es problemático:

  1. Curva de aprendizaje consume timeline:

    • Junior aprende Docker: 2 semanas
    • Junior aprende Modal: 1 semana
    • Junior debuggea issues: 2 semanas
    • Total: 5 semanas (vs 1 día con OpenAI)

  2. Mantenimiento imposible:

    • Junior no puede resolver outage solo
    • Founders deben intervenir (no escalable)

  3. Tech debt:

    • Código complejo que nadie entiende
    • Miedo a tocar (bugs en producción)

Ejemplo real:

Startup: Content generation tool
Equipo: 2 founders (1 dev mid, 1 designer)
Decisión: Modal serverless (leyeron blog post)
Resultado:

  • Semana 1-2: Siguieron tutorial (funcionó)
  • Semana 3: Custom logic (no funciona)
  • Semana 4: Cold starts 10s (users complain)
  • Semana 5: Stackoverflow, ChatGPT, no resuelven
  • Semana 6: Contrataron consultant ($3k) para arreglarlo
  • Semana 8: Migraron a OpenAI API (debieron empezar así)

Costo total: $3k consultant + 2 meses perdidos

✅ Cómo evitarlo:

Regla: Matchea tecnología con skills reales (no aspiracionales)

Skill LevelPuede mantenerNO puede mantener
JuniorOpenAI API, OpenRouterOllama cluster, Modal
MidOllama single node, ModalOllama cluster multi-nodo
SeniorTodo lo anteriorN/A

Test del "bus factor":

  • Si tu dev principal se va, ¿el resto puede mantener el sistema?
  • Si NO → Elige tecnología más simple

Principio: Simplicidad > Perfección técnica

❌ Error #3: No Tener Plan de Fallback

Qué se hizo mal:

"OpenAI es confiable, no necesitamos backup."

Dependen 100% de un proveedor sin contingencia. OpenAI API tiene outage de 4 horas, aplicación down completamente, pierden revenue.

Por qué es problemático:

  1. Downtime = Revenue loss:

    • E-commerce: $1k/hora perdido (promedio)
    • B2B SaaS: Clientes churning
    • Reputación: HN post "X está down otra vez"

  2. Todos los proveedores tienen outages:

    • OpenAI: ~99.5% uptime (4 horas/mes)
    • Anthropic: Similar
    • Ollama local: Tu responsabilidad

  3. Migración emergency es caótica:

    • Sin plan: 6-12 horas para implementar fallback
    • Con plan: 5 minutos (flip switch)

Ejemplo real:

Startup: AI writing assistant
Revenue: $50k/mes
Decisión: OpenAI GPT-4 (sin fallback)
Incidente:

  • OpenAI outage: 6 horas (Sábado)
  • App completamente down
  • 200 usuarios intentan usar, falla
  • Twitter: "X no funciona, buscando alternativa"
  • Lunes: 15 cancellations ($750 MRR perdido)

Costo total: $750/mes MRR + damage reputacional

Qué debieron tener:

  • OpenRouter configurado como fallback (5 min setup)
  • Auto-switch si OpenAI latency >5s por 2 min
  • Cost: $0 hasta activar fallback

✅ Cómo evitarlo:

Regla: Siempre tener Plan B listo (incluso si nunca lo usas)

Setup fallback básico (30 minutos):

# 1. Abstrae proveedor detrás de interface
class LLMProvider(Protocol):
    def chat(self, messages: list) -> str: ...

class OpenAIProvider(LLMProvider):
    def chat(self, messages): 
        return openai.chat.completions.create(...)

class OpenRouterProvider(LLMProvider):
    def chat(self, messages):
        return requests.post("https://openrouter.ai/api/v1/chat/completions", ...)

# 2. Config primary + fallback
PRIMARY = OpenAIProvider()
FALLBACK = OpenRouterProvider()

# 3. Auto-fallback en producción
def chat_with_fallback(messages):
    try:
        return PRIMARY.chat(messages)
    except (Timeout, APIError) as e:
        logger.error(f"Primary failed: {e}, using fallback")
        return FALLBACK.chat(messages)

Cost: $0 hasta que activas fallback

❌ Error #4: Seguir el Hype sin Evaluar

Qué se hizo mal:

"GPT-4 es el mejor modelo, voy a usarlo para todo."

Usan GPT-4 ($30/1M tokens input) para queries simples donde GPT-3.5 ($0.50/1M) funciona igual. Factura 60x más alta sin beneficio.

Por qué es problemático:

  1. Overpaying por calidad innecesaria:

    • GPT-4: 86% MMLU
    • GPT-3.5: 70% MMLU
    • FAQ chatbot: 70% es suficiente

  2. Velocidad más lenta:

    • GPT-4: 3.2s latency
    • GPT-3.5: 1.5s latency
    • Users notan (bounce rate)

  3. Costo 60x sin reason:

    • 100k queries/mes × 500 tokens = 50M tokens
    • GPT-4: $1500/mes
    • GPT-3.5: $25/mes
    • Diferencia: $1475/mes desperdiciados

Ejemplo real:

Startup: Recipe recommendation
Decisión: GPT-4 para "máxima calidad"
Resultado:

  • Mes 1: $50/mes (low volume)
  • Mes 3: $800/mes (scale)
  • Mes 6: $3200/mes (CFO alert)
  • Auditoría: 90% queries son simples ("sugiere receta con pollo")
    • GPT-3.5 da misma respuesta
    • No necesitaban reasoning complejo

Solución:

  • Clasificador: Query simple → GPT-3.5, compleja → GPT-4
  • 90% queries a GPT-3.5: $3200 → $400/mes
  • Ahorro: $2800/mes

✅ Cómo evitarlo:

Regla: Usa modelo más barato que cumple requirement

Metodología:

  1. Define accuracy mínimo:

    • FAQ chatbot: 70%
    • Legal analysis: 85%
    • Medical diagnosis: 95%

  2. Test modelos ascendentemente:

    • Start: Mixtral 8x7B (70%) → ¿Cumple?
    • Si NO: GPT-3.5 (70%) → ¿Cumple?
    • Si NO: GPT-4 (86%) → Debe cumplir

  3. Benchmark en TUS datos:

    • No uses benchmarks generales (MMLU)
    • Crea test set de 100 queries reales
    • Evalúa accuracy manual

Estrategia híbrida (avanzado):

  • Clasificador: Simple query → Modelo barato
  • Complex query → Modelo caro
  • Costo optimizado sin sacrificar calidad

❌ Error #5: No Validar con Documentación Oficial

Qué se hizo mal:

"Vi este código en Stack Overflow, lo copio directo."

Usan código obsoleto, API deprecated, o parámetros incorrectos. En producción, falla sin razón clara.

Por qué es problemático:

  1. APIs cambian rápido:

    • OpenAI SDK v0 → v1 (breaking changes 2023)
    • Ollama API format cambió 3 veces en 2024
    • Stack Overflow tiene código 2020 (obsoleto)

  2. Debugging imposible:

    • Error message: "400 Bad Request"
    • Docs nueva: Parámetro model ahora obligatorio
    • No sabías porque usaste código viejo

  3. Security risks:

    • Código viejo no valida inputs
    • Injection attacks posibles

Ejemplo real:

Developer: Sigue tutorial YouTube (2022)
Código:

# Tutorial 2022 (OpenAI SDK v0)
import openai
openai.api_key = "sk-..."
response = openai.Completion.create(
    engine="text-davinci-003",  # DEPRECATED
    prompt="Hello",
    max_tokens=100
)

Resultado:

  • Código no funciona (2024: SDK v1, API nueva)
  • 3 horas debugging
  • Reddit post: "OpenAI API no funciona, ¿qué hago?"

Solución:

from openai import OpenAI  # SDK v1
client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",  # Chat API, no Completion
    messages=[{"role": "user", "content": "Hello"}]
)

✅ Cómo evitarlo:

Regla: SIEMPRE validar con docs oficial (updated 2026)

Checklist:

  1. Fuentes confiables (orden prioridad):

    • ✅ Docs oficial proveedor (always updated)
    • ✅ GitHub oficial (examples repo)
    • ⚠️ Stack Overflow (check fecha, votos)
    • ⚠️ Tutorials YouTube (check fecha)
    • ❌ Reddit comments (no peer-reviewed)

  2. Red flags de código obsoleto:

    • openai.Completion.create() → Deprecated 2023
    • engine="text-davinci-003" → Obsoleto
    • import openai sin from openai import OpenAI → SDK viejo

  3. Docs oficiales actualizadas:

  4. Test en local antes de producción:

    • Copy-paste código? Test primero
    • Funciona? Entonces deploy

❌ Error #6: Subestimar el Costo de Context

Qué se hizo mal:

"Voy a meter TODO el historial conversacional en cada request."

Cada mensaje incluye los últimos 50 mensajes (context), aunque solo necesitan 3-5. Costo explota porque tokens input son 10x más de lo necesario.

Por qué es problemático:

  1. Costo escala con context size:

    • 3 mensajes: 300 tokens
    • 50 mensajes: 5000 tokens (16.6x)
    • Costo: 16.6x mayor

  2. Latency aumenta:

    • Más tokens input = más tiempo procesamiento
    • 5000 tokens: +500ms vs 300 tokens

  3. Context limit hit:

    • GPT-3.5: 16k tokens max
    • 50 mensajes × 100 tokens = 5k input
    • Solo quedan 11k para output
    • Conversaciones largas fallan

Ejemplo real:

Startup: Customer support chatbot
Decisión: Incluir últimos 50 mensajes siempre
Resultado:

  • Mes 1: $200/mes (low volume)
  • Mes 3: $2500/mes (same volume!)
  • Auditoría: Average query usa 4800 tokens input
    • 4500 tokens = historial viejo innecesario
    • Solo últimos 5 mensajes son relevantes

Solución:

  • Sliding window: Últimos 5 mensajes
  • 4800 → 600 tokens input
  • $2500 → $300/mes
  • Ahorro: $2200/mes (88%)

✅ Cómo evitarlo:

Regla: Minimiza context a lo NECESARIO

Estrategias:

  1. Sliding window (más simple):
# Solo últimos N mensajes
MAX_HISTORY = 5
conversation_history = messages[-MAX_HISTORY:]
  1. Summarization (avanzado):
# Cada 10 mensajes, resume historial
if len(messages) > 10:
    summary = summarize(messages[:-5])
    messages = [summary] + messages[-5:]
  1. Relevance filtering (expert):
# Solo mensajes relevantes a query actual
relevant_messages = retrieve_relevant(query, messages)
context = relevant_messages[-5:]

Monitoring:

  • Log token usage por request
  • Alert si promedio > 1000 tokens (review needed)

❌ Error #7: No Medir Performance Real

Qué se hizo mal:

"Benchmarks dicen GPT-4 es mejor, lo usamos."

Confían ciegamente en benchmarks públicos (MMLU) sin testear en SUS datos. En producción, GPT-3.5 funciona igual para SU use case.

Por qué es problemático:

  1. Benchmarks generales ≠ tu use case:

    • MMLU: Examen universitario (math, ciencia)
    • Tu app: Recomendar productos e-commerce
    • Skills diferentes

  2. Overpaying sin validar:

    • GPT-4: 60x más caro
    • Sin medir, asumes "es mejor"
    • En realidad, GPT-3.5 suficiente

  3. Optimizaciones imposibles:

    • Sin métricas, no sabes qué mejorar
    • Latency? Accuracy? Cost?

Ejemplo real:

Startup: Email classifier (spam/no spam)
Decisión: GPT-4 (86% MMLU, "debe ser mejor")
Resultado:

  • Costo: $800/mes
  • Accuracy: No medían (asumían perfecto)
  • Auditoría: Crearon test set 1000 emails
    • GPT-4: 94% accuracy
    • GPT-3.5: 93% accuracy
    • Mixtral: 91% accuracy
    • Diferencia: 1-3% irrelevante para negocio

Solución:

  • Switchearon a Mixtral (OpenRouter)
  • $800 → $80/mes (10x cheaper)
  • 91% accuracy suficiente (3% error aceptable)

✅ Cómo evitarlo:

Regla: Mide performance en TUS datos (no benchmarks genéricos)

Setup evaluation pipeline:

  1. Crea test set (100-1000 samples):
test_set = [
    {"input": "Hi, how are you?", "expected": "greeting"},
    {"input": "Track my order #123", "expected": "order_status"},
    # ... 98 more
]
  1. Benchmark modelos:
for model in ["gpt-3.5", "gpt-4", "mixtral"]:
    results = [evaluate(model, sample) for sample in test_set]
    accuracy = sum(r["correct"] for r in results) / len(results)
    latency = sum(r["latency"] for r in results) / len(results)
    cost = sum(r["tokens"] for r in results) * PRICE[model]
    
    print(f"{model}: {accuracy=}, {latency=}, {cost=}")
  1. Elige modelo que cumple requirement mínimo:
  • Si 85% accuracy requerido y Mixtral da 86% → Usa Mixtral
  • GPT-4 con 94% es overkill (+9% no justifica 60x costo)

📊 Resumen de Errores

Top 7 errores y cómo evitarlos:

ErrorImpactoFix
#1: Optimizar costo prematuramente$5-10k desperdiciados + 1 mesStart simple, optimiza DESPUÉS
#2: Ignorar skills del equipoProyecto estancado, tech debtMatchea tech con skills reales
#3: No tener plan de fallbackDowntime, revenue lossSetup Plan B (30 min)
#4: Seguir hype sin evaluar60x overpayingUsa modelo más barato que cumple
#5: No validar con docs oficialCódigo roto, 3hrs debuggingDocs oficial > Stack Overflow
#6: Subestimar costo de context16x costo innecesarioSliding window, solo últimos N
#7: No medir performance realPagar por accuracy innecesariaTest en TUS datos, no benchmarks

🎯 Checklist: ¿Estoy cometiendo alguno?

Antes de decidir proveedor, verifica:

  • ¿Estoy optimizando costo antes de validar PMF? (Error #1)
  • ¿Mi equipo puede MANTENER esta solución? (Error #2)
  • ¿Tengo plan de fallback listo? (Error #3)
  • ¿Elegí por hype o por evaluation? (Error #4)
  • ¿Validé código con docs oficial 2026? (Error #5)
  • ¿Estoy incluyendo solo context necesario? (Error #6)
  • ¿Medí accuracy en MIS datos? (Error #7)

Si alguno es ❌, DETENTE y corrige.

🔗 Recursos adicionales

  1. Postmortem Archive - Casos de outages reales
  2. Cost Optimization Guide - Best practices
  3. LLM Leaderboard - Benchmarks actualizados
  4. OpenAI Migration Guide (v0 → v1) - Evita código obsoleto

➡️ Próximo paso

Siguiente cápsula: 08-mini-proyecto-evaluacion-requisitos.md

Ahora que sabes qué NO hacer, es momento del mini-proyecto integrador.

Aplicarás todo el framework del Módulo 1 (5 dimensiones, panorama de opciones, matriz de decisión, trade-offs) a un caso real completo: E-commerce chatbot.

Tomarás una decisión informada y documentarás tu scorecard.

Tiempo de lectura: 10-12 minutos
Siguiente: 08-mini-proyecto-evaluacion-requisitos.md

← AnteriorCasos de Uso Reales: Decisiones JustificadasSiguiente →Mini-Proyecto: Evaluación de Requisitos - E-commerce Chatbot