Self-hosted AI Enterprise Stack: vLLM, SGLang, Docker. Una plataforma de IA interna para el equipo

Módulo: 13. Práctica profesional | Tiempo: ~40 min de teoría + 60 min de práctica

Lo esencial

Usar la API de Anthropic es comprar electricidad de la red de la ciudad. Cómodo, confiable, pagas según el medidor. No tienes que pensar en transformadores, cables ni en la sala de control.

Self-hosted AI es construir tu propia planta eléctrica junto al edificio. Caro al principio: turbina, enfriamiento, operador. Pero si tienes una fábrica con 50+ máquinas trabajando 24/7, tu propia planta se paga en 1-2 años y te da independencia del proveedor.

Cuándo se paga el self-host:

• Un gasto en LLM de $5000+/mes de forma estable (punto de equilibrio del hardware)
• 50+ usuarios simultáneos (carga de trabajo)
• Industria regulada (el cumplimiento exige residencia de datos)
• Geopolítica (riesgo de sanciones, soberanía)
• Modelos a la medida (fine-tuned para un dominio)

En los demás casos, la API es más barata, más simple y más confiable.

Los umbrales y montos de esta lección son referencias para hacer cuentas, no una lista de precios: los precios del hardware y las tarifas cambian, verifícalos antes de comprar. Precios vigentes de la API: Lo vigente.

🎨 Imagínalo así: un restaurante de comida rápida vs. un restaurante con su propia granja. El de comida rápida compra los insumos a un proveedor: rápido, barato al empezar. La granja propia es una gran inversión en tierra y equipo, pero en unos años el costo por porción es bastante menor y controlas la calidad de la semilla al plato.

🎯 Decision tree: ¿necesitas self-host?

Antes de gastar $50K en hardware, recorre este checklist. Si respondes "no" en todos los nodos, quédate con la API.

¿Gasto en LLM > $5000/mes estable en los últimos 3 meses?
→ Sí → Self-host llega al punto de equilibrio en 12-18 meses
→ No → La API es más barata, no toques el hardware

¿Industria regulada (salud, finanzas, gobierno, defensa)?
→ Sí → Self-host requerido para cumplimiento (HIPAA, PCI DSS, GDPR estricto)
→ No → siguiente pregunta

¿Un equipo de 50+ personas usa IA a la vez todos los días?
→ Sí → Self-host por costo + privacidad + latencia
→ No → La API es más sencilla, no compliques

¿Se requiere un modelo específico (fine-tuned con datos del dominio, a la medida)?
→ Sí → Self-host (en los proveedores en la nube, el fine-tuning está limitado a ciertos modelos y condiciones)
→ No → siguiente pregunta

¿Restricciones geográficas o políticas (países que los proveedores no atienden, sanciones)?
→ Sí → Self-host = seguro de soberanía
→ No → La API sirve

¿Todas las respuestas son "no"?
→ Quédate con la API. Para ti, el self-host es sobreingeniería.

🎨 Imagínalo así: comprar un tractor. Si tienes un huerto de 100 m², la pala es más barata y rápida. El tractor tiene sentido a partir de 10 hectáreas. El self-host es un tractor. A los terrenos pequeños solo los arruina.

Conceptos clave

• Inference engine: el programa que recibe la solicitud y genera la respuesta del LLM (vLLM, SGLang, TGI, Ollama). El equivalente al motor de un coche
• vLLM: el inference engine open source más popular, Apache 2.0, con un excelente equilibrio entre throughput y comodidad
• SGLang: uno de los más rápidos en throughput; nació del proyecto LMSYS (Berkeley); optimizado para structured outputs y parallel sampling
• API gateway: una capa proxy que convierte la inferencia local en un endpoint compatible con OpenAI (LiteLLM). Los clientes existentes funcionan sin cambios
• Tensor parallelism: repartir el modelo entre varias GPU. Un modelo de 70B requiere ~140GB de VRAM en FP16: una sola tarjeta no alcanza
• Quantization: comprimir el modelo a 4 u 8 bits para reducir la VRAM de 2 a 4 veces con una pérdida mínima de calidad
• Throughput: cuántos tokens por segundo genera el sistema (importante en entornos multiusuario)
• Latency: la demora del primer token (TTFT, time to first token). Crítica para una UX interactiva
• Concurrent users: cuántos usuarios pueden trabajar a la vez sin que se degrade la latencia

Teoría

Niveles de hardware para una empresa

El tamaño del hardware lo definen tres parámetros: el tamaño del modelo (B de parámetros), el número de usuarios simultáneos y los requisitos de latencia.

Tier 1: Departamental (5-20 usuarios)

Perfil objetivo: un área de desarrollo, marketing o soporte en una empresa mediana. Carga no crítica, un experimento o una herramienta interna.

Ejemplo: un equipo de 10 desarrolladores para code review y generación de documentación. Armado: dos tarjetas gráficas de consumo de gama alta de 24GB cada una, un gabinete de servidor, un procesador clase Threadripper o Xeon, 128GB de RAM, NVMe de 4TB, fuente de 1500W. En total, del orden de $10K (es una referencia: verifica los precios de los componentes al momento de comprar).

🎨 Imagínalo así: una planta de luz compacta en una casa de campo. Le alcanza a la casa, no a los vecinos.

Tier 2: Team (20-100 usuarios)

Perfil objetivo: una empresa donde la IA se volvió una herramienta crítica de producción. Una startup SaaS con IA integrada, una agencia con 50 desarrolladores, una fintech mediana.

En este nivel ya hace falta un cuarto de servidores con control de temperatura (HVAC), un UPS de 5-10 kW y una infraestructura de red dedicada. Se necesita un ingeniero de operaciones dedicado, al menos de medio tiempo.

Tier 3: Enterprise (100-1000+ usuarios)

Perfil objetivo: una gran empresa, un banco, una institución de gobierno. La IA es infraestructura central.

Esto ya es un segmento de data center aparte. Hace falta un equipo de 3-5 personas: SRE, ML engineer, seguridad, redes. Un SLA de 99.9%+ requiere redundancia en todos los niveles.

Inference engines: comparación (a octubre de 2026)

El inference engine es el corazón del sistema. De la elección dependen el throughput, la latencia y la complejidad operativa. Una lista corta realista de 5 opciones:

vLLM (github.com/vllm-project/vllm): el estándar de oro. PagedAttention es su técnica distintiva para aprovechar la VRAM. API compatible con OpenAI de fábrica. La mayoría de los tutoriales y casos en producción usan vLLM.

SGLang (github.com/sgl-project/sglang): en varios benchmarks supera a vLLM en throughput, pero mídelo con tu carga. RadixAttention reutiliza la KV-cache entre solicitudes. Es especialmente bueno cuando tienes muchos system prompts parecidos (el escenario típico de agentes). Desventaja: el ecosistema es más joven y hay menos guías listas.

TGI (Text Generation Inference) (github.com/huggingface/text-generation-inference): producto de HuggingFace. Se integra bien con HF Hub y se despliega fácil. Pero a octubre de 2026 el proyecto está en modo mantenimiento (maintenance mode): solo se aceptan correcciones menores y los propios autores recomiendan vLLM y SGLang. Para un proyecto nuevo es mejor empezar con ellos.

Ollama: para pilotos y equipos pequeños. Arranca con un comando y tiene una CLI muy cómoda. No escala más allá de ~10 usuarios simultáneos. Detalles: Modelos de IA locales: Ollama, LM Studio e IA privada.

🎨 Imagínalo así: elegir el motor de un coche. vLLM es un Toyota (confiable, accesible, todo funciona). SGLang es un Porsche (más rápido, pero requiere experiencia). Ollama es una motoneta (arranca al instante, no llega lejos).

Stack de Docker para desplegar en equipo

Un setup de producción se arma con 3-4 contenedores: inference engine + gateway + UI + auth. Configuración básica para el Tier 1:

# docker-compose.yml — setup de equipo Tier 1 (5-20 usuarios)
# En el Docker Compose actual no hace falta la clave version

services:
  # Inference engine
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    ports:
      - "8000:8000"
    volumes:
      - ./models:/root/.cache/huggingface
    command:
      # El modelo en bf16 pesa ~65GB: en 2×24GB usa una versión cuantizada (AWQ o GPTQ),
      # en A100/H100 80GB, tal cual
      - --model
      - Qwen/Qwen3-32B
      - --tensor-parallel-size
      - "2"
      - --gpu-memory-utilization
      - "0.90"
      - --max-model-len
      - "32768"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]
    restart: unless-stopped

  # API gateway: proxy compatible con OpenAI con rate limiting + auditoría
  litellm:
    # Fija una versión concreta en lugar de main-latest (ver abajo lo de marzo de 2026)
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    environment:
      - DATABASE_URL=postgres://litellm:secret@postgres:5432/litellm
      - MASTER_KEY=sk-master-clave-interna-cambiala
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    depends_on:
      - postgres
      - vllm
    restart: unless-stopped

  # PostgreSQL para LiteLLM (auditoría, claves, presupuestos)
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=litellm
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=litellm
    volumes:
      - postgres-data:/var/lib/postgresql/data
    restart: unless-stopped

  # UI para los usuarios
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OPENAI_API_BASE_URL=http://litellm:4000/v1
      - OPENAI_API_KEY=sk-master-clave-interna-cambiala
      - WEBUI_AUTH=true
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - litellm
    restart: unless-stopped

volumes:
  open-webui:
  postgres-data:

Configuración de LiteLLM (litellm-config.yaml):

model_list:
  - model_name: qwen-32b
    litellm_params:
      model: openai/Qwen/Qwen3-32B
      api_base: http://vllm:8000/v1
      api_key: dummy  # vLLM no requiere autenticación real

general_settings:
  master_key: sk-master-clave-interna-cambiala
  database_url: postgres://litellm:secret@postgres:5432/litellm

litellm_settings:
  drop_params: true
  set_verbose: false
  json_logs: true
  cache: true

Arranque:

docker compose up -d
# vLLM descargará el modelo Qwen3 32B (~65GB en bf16) en el primer arranque
# Para ver el avance: docker compose logs -f vllm

Después del arranque:

• http://localhost:8000/v1: endpoint de vLLM en bruto
• http://localhost:4000/v1: gateway de LiteLLM (usamos este)
• http://localhost:3000: Open WebUI para los usuarios

🎨 Imagínalo así: un juego de Lego. Cada contenedor es una pieza con una función. vLLM calcula, LiteLLM controla el acceso, Postgres recuerda quién hizo qué y WebUI da la interfaz.

API gateway compatible con OpenAI: LiteLLM

LiteLLM (github.com/BerriAI/litellm) es un componente crítico del stack. Sin él, el self-host se queda como un juguete interno; con él, se vuelve una plataforma de nivel enterprise.

Qué te da LiteLLM:

• API compatible con OpenAI: todos los clientes que funcionan con OpenAI/Anthropic (Cursor, Continue.dev, Aider, scripts propios) funcionan con el vLLM local sin reescribir código
• Claves de API por usuario: cada desarrollador recibe su propia clave. Revocar una no rompe las demás
• Rate limiting: límites por usuario o por equipo para que un script no acapare todo el hardware
• Seguimiento de costos + presupuestos: quién gastó cuántos tokens, alertas al superar el límite
• Audit log: todas las solicitudes en PostgreSQL con user_id, modelo, tokens, latencia
• Enrutamiento multimodelo: puedes mandar las solicitudes sencillas a un modelo pequeño y las complejas a uno grande
• Fallback a la API: si el vLLM local se cae, puedes enrutar a la API de Anthropic

La seguridad del propio gateway: el 24 de marzo de 2026 llegaron a PyPI, por poco tiempo, versiones maliciosas del paquete litellm (1.82.7 y 1.82.8) que robaban credenciales. El análisis de los autores: Security Update: Suspected Supply Chain Incident. La conclusión para cualquier gateway con claves: fija la versión (pin), instala solo de fuentes verificadas e imágenes firmadas, y actualiza de forma consciente, no automática.

Crear una clave de usuario con el admin de LiteLLM:

# Creamos un team
curl -X POST http://localhost:4000/team/new \
  -H "Authorization: Bearer sk-master-clave-interna-cambiala" \
  -H "Content-Type: application/json" \
  -d '{
    "team_alias": "backend-team",
    "max_budget": 100.0,
    "models": ["qwen-32b"]
  }'

# Creamos una clave para un desarrollador
curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-master-clave-interna-cambiala" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "backend-team",
    "user_id": "dev_user_42",
    "max_budget": 10.0,
    "duration": "30d",
    "rpm_limit": 60,
    "tpm_limit": 100000
  }'
# Respuesta: {"key": "sk-1a2b3c4d...", "expires": "..."}

El desarrollador usa su clave en cualquier herramienta compatible con OpenAI:

# Aider (el prefijo openai/ indica que es un endpoint compatible con OpenAI)
export OPENAI_API_BASE=http://internal-llm:4000/v1
export OPENAI_API_KEY=sk-1a2b3c4d...
aider --model openai/qwen-32b

# Cursor: indicar una Custom API en la configuración
# Continue.dev en VS Code: config.yaml (config.json está obsoleto):
# models:
#   - name: Internal Qwen
#     provider: openai
#     model: qwen-32b
#     apiBase: http://internal-llm:4000/v1
#     apiKey: sk-1a2b3c4d...
# El formato exacto está en la documentación de Continue.

Autenticación y control de acceso

Repartirles el master_key a los usuarios es como darle a todo el personal la llave del cuarto de servidores. Hace falta SSO + aprovisionamiento por usuario.

Authentik (goauthentik.io): un IdP open source, competidor directo de Okta. Autoalojado; admite SAML, OAuth2, OIDC. Se integra con Google Workspace, Microsoft 365, LDAP.

Keycloak: el hermano mayor, probado en empresas, pero más pesado de configurar. Si la empresa ya tiene un stack de Java, es la elección natural.

Esquema típico:

El empleado entra a Open WebUI
  ↓
Open WebUI redirige a Authentik
  ↓
Authentik verifica con el SSO de Google Workspace
  ↓
Authentik devuelve un JWT con user_id y groups
  ↓
Open WebUI crea la sesión
  ↓
Open WebUI llama a LiteLLM con la API key del usuario
  ↓
LiteLLM verifica la clave y los límites, registra y pasa a vLLM
  ↓
vLLM genera la respuesta

Controles clave:

• Groups → models: los desarrolladores junior solo usan el modelo pequeño; los senior tienen acceso al grande (70B)
• Presupuestos por usuario: un presupuesto por defecto pequeño por usuario, ampliable a solicitud a través del manager
• Rate limits: 60 req/min por defecto, para que un script de bash en un ciclo no tumbe el sistema
• Audit logging: todas las solicitudes se escriben en Postgres, con retención de 90 días (o más por cumplimiento)

Stack de monitoreo

Sin monitoreo, el self-host se vuelve una caja negra. Cuando los usuarios empiecen a quejarse de que "va lento", necesitas ver las métricas de inmediato.

Stack mínimo:

• Prometheus: recolección de métricas. vLLM expone el endpoint /metrics de forma nativa
• Grafana: dashboards. Hay plantillas listas para vLLM en grafana.com/dashboards
• Loki: agregación de logs (opcional, para setups grandes)
• OpenTelemetry: distributed tracing (opcional, para multiservicio)

Métricas que hay que seguir desde el día 1:

• GPU utilization (%: subutilización = pagas de más, sobrecarga = fila)
• VRAM usage (%: acercarse al 95% = OOM pronto)
• Tokens/sec (throughput agregado)
• Time to first token (P50, P95, P99: métrica de UX)
• Queue depth (si crece, hace falta más hardware)
• Costo por usuario (LiteLLM lo exporta)
• Error rate (5xx, timeouts)

Ampliación del docker-compose para el monitoreo:

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin-cambialo
    volumes:
      - grafana-data:/var/lib/grafana
    restart: unless-stopped

prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: vllm
    static_configs:
      - targets: ['vllm:8000']
    metrics_path: /metrics

  - job_name: litellm
    static_configs:
      - targets: ['litellm:4000']
    metrics_path: /metrics

🎨 Imagínalo así: el tablero de instrumentos de un avión. Sin él, el piloto se entera del problema cuando el motor ya está echando humo. Con el tablero, 10 minutos antes.

Fine-tuning de tu propio modelo: una posibilidad adicional

Si la empresa tiene datos específicos de su dominio (documentos legales, protocolos médicos, código en un DSL interno), el fine-tuning puede dar un salto importante de calidad.

Cifras base (referencias, verifícalas para tu tarea):

• Hardware: 1x A100 80GB para un fine-tune pequeño (7B-13B), 4x para uno grande (70B)
• Datos: 1K-10K ejemplos de calidad para un buen resultado
• Herramientas: Axolotl (github.com/axolotl-ai-cloud/axolotl), LLaMA-Factory (github.com/hiyouga/LLaMA-Factory)
• Tiempo: 2-24 horas según el tamaño del modelo y el volumen de datos
• Costo: $100-1000 rentando GPU (RunPod, Lambda Labs)

Los detalles del fine-tuning están en la lección Fine-tuning: cuando los prompts no alcanzan. Lo importante aquí: después del fine-tune, el modelo se despliega en el mismo vLLM/SGLang que el modelo base. Solo cambia el parámetro --model por la ruta al checkpoint fine-tuned.

Setups del mundo real: 3 casos de estudio

Son ilustraciones generalizadas, no reportes de empresas concretas; los montos son ilustrativos. Revisa con un abogado los requisitos sobre datos (GDPR, regulaciones médicas y bancarias): la lección no sustituye una asesoría legal.

Caso 1: una fintech regional (50 desarrolladores)

Contexto: un banco mediano que desarrolla software de core bancario; la regulación de su país exige residencia de datos y descarta las API en la nube extranjeras.

Stack:

• 4x A100 80GB (1 servidor con tensor parallel 4)
• Un modelo abierto de clase 70B (familia Qwen) + LiteLLM + Open WebUI + Authentik
• Uso: code review automático, generación de documentación, análisis de seguridad en los pull requests

Economía:

• Hardware: ~$200K (servidores + red + UPS)
• OpEx: $400/mes de electricidad, 0.5 FTE de ingeniero de operaciones
• Alternativa (Anthropic): ~$50K/año con la carga actual
• Punto de equilibrio: ~4.4 años incluso sin el sueldo del ingeniero de operaciones ($200K / ($50K − $4.8K de electricidad) al año)
• Soberanía: 100%: ningún dato sale del perímetro

Caso 2: un SaaS de salud europeo

Contexto: un SaaS para clínicas en Alemania, GDPR + la ley nacional de datos médicos. Ninguna solicitud con datos de pacientes puede salir a EE. UU. o Reino Unido.

Stack:

• 2 servidores con 2x H100 80GB cada uno (redundancia)
• SGLang + un modelo abierto de clase 70B, fine-tuned con transcripciones médicas anonimizadas
• SSO con Authentik integrado al Active Directory existente
• Uso: asistente para médicos (investigación, resúmenes), borradores de comunicación con pacientes (siempre con supervisión)

Economía:

• Hardware: €300K
• OpEx: €600/mes de infraestructura + 1 FTE de operaciones
• Cumplimiento: auditoría GDPR aprobada, certificación de datos médicos
• Reducción de riesgo (multa potencial por una filtración de datos): millones de euros

Caso 3: una empresa de medios latinoamericana

Contexto: un grupo de medios en la Ciudad de México, contenido en español, portugués, inglés y quechua. Grandes volúmenes de traducción y reescritura.

Stack:

• 2x RTX 4090 (un servidor)
• Qwen3 32B (cuantizado) + Open WebUI + LiteLLM
• Uso: pipeline de traducción a 5 idiomas, generación de borradores de artículos, variantes A/B de titulares

Economía:

• Hardware: $12K de una sola vez
• OpEx: $80/mes de electricidad
• Alternativa antes del self-host: $1500/mes (DeepL + OpenAI)
• Punto de equilibrio: ~8.5 meses ($12K / ($1500 − $80) al mes)
• Ganancia extra: la posibilidad de ajustarlo a los regionalismos del español de Latinoamérica (algo que los traductores comerciales no consideran)

Preocupaciones operativas: qué se rompe en producción

El self-host no es "instalar y olvidar". La lista real de lo que requiere atención cada semana:

• Uptime: para 99.9% hace falta un setup redundante (2 servidores como mínimo, failover automático)
• Fallas de GPU: 1-2 tarjetas al año se descomponen con carga 24/7. Ten repuestos
• Enfriamiento: el cuarto de servidores debe mantenerse a 18-22°C. Sobrecalentamiento = desgaste acelerado de las GPU
• Energía: UPS para 15+ minutos para un apagado ordenado, planta eléctrica para producción
• Actualizaciones de modelos: cada trimestre salen nuevas versiones de Qwen/Llama/Mistral. Actualizar el modelo = 1-2 horas de downtime
• Actualizaciones de SO / drivers: los drivers de NVIDIA requieren cuidado (incompatibilidades con versiones de vLLM)
• Respaldos: los modelos pesan 50-200GB, hace falta un plan para guardar los checkpoints
• Tiempo de mantenimiento: reserva 1-2 horas a la semana de operaciones incluso en un setup estable

🎨 Imagínalo así: una pecera. Compraste los peces: ahora hay que alimentarlos, limpiar, mantener la temperatura, medicinas si se enferman. No es "lo pongo y lo admiro".

Comparación de costos: 1 año en detalle

Comparación para un equipo de 50 desarrolladores, con un consumo de ~$5K/mes si fuera por API:

El híbrido suele ser el óptimo: la mayoría de las solicitudes van por el vLLM local (barato, soberano) y las complejas por la API de Anthropic (cuando hace falta un modelo en la nube potente). LiteLLM sabe enrutar automáticamente.

Audiencia: qué tan aplicable es

Principiante (1 desarrollador, proyecto personal)

No necesitas self-host. Vuelve cuando tus facturas de LLM pasen de $300/mes de forma estable. Hasta entonces, API de Anthropic/OpenAI: ahorrar tiempo importa más que ahorrar dinero.

Si quieres jugar con modelos locales para aprender: Ollama (ver la lección Modelos de IA locales: Ollama, LM Studio e IA privada), arranca en 10 minutos.

Intermedio (equipo pequeño, 5-20 personas)

Un setup Tier 1 tiene sentido si:

• Gastas $1500+/mes en LLM de forma estable
• O tienes al menos un requisito: privacidad, soberanía, latencia

Configuración: vLLM + LiteLLM + Open WebUI. Un servidor con 2x RTX 4090 o 1x A100. Setup en una semana, operación de 2-4 horas a la semana.

Piloto antes de producción: córrelo 2 semanas en una GPU en la nube (por ejemplo, RunPod; el precio por hora está en el sitio del proveedor), mide la carga real y luego compra el hardware con parámetros exactos.

Profesional (negocio mediano, 20-100 personas)

Se recomienda el Tier 2 cuando:

• Gastas $5K+/mes de forma estable
• Tienes un caso de uso de IA crítico para producción
• Hay un ingeniero de operaciones dedicado

Configuración: SGLang + LiteLLM + SSO con Authentik + Prometheus/Grafana. 2-4 servidores para redundancia. Setup de 2-4 semanas, operación de 1 FTE de medio tiempo.

Enterprise (100-1000+ usuarios)

Esto ya es otra categoría de peso. El Tier 3 es infraestructura aparte, equipo dedicado, SLA, recuperación ante desastres, multirregión. Está fuera del alcance de esta lección. Consulta los cursos de NVIDIA / Anyscale / RunPod sobre infraestructura de IA enterprise.

Anti-patterns: errores frecuentes

• ❌ Hacer self-host con un gasto en LLM de <$2K/mes: no hay ROI. El hardware se amortiza en 3+ años y el tiempo de operación cuesta dinero
• ❌ Ignorar el costo de la electricidad: cada GPU 24/7 consume $50-200/mes de electricidad + enfriamiento
• ❌ Sin una persona dedicada a operaciones: downtime eterno. Alguien tiene que responder por el sistema, aunque sea de medio tiempo
• ❌ Saltarse la autenticación: una brecha de seguridad es inevitable. Repartir el master_key a todos = invitación al desastre
• ❌ Sin monitoreo: los problemas quedan ocultos hasta la falla en producción. Como mínimo, Prometheus + 3 métricas clave
• ❌ Un solo servidor: sin redundancia = SPOF. En el Tier 1 todavía se vale una sola caja; del Tier 2 en adelante, siempre redundante
• ❌ Usar las versiones latest inestables: vLLM/SGLang evolucionan rápido y los breaking changes son frecuentes. Fija la versión y prueba las actualizaciones
• ❌ Ignorar las actualizaciones de modelos: los modelos envejecen. Cada pocos meses llega una generación nueva (Qwen 2.5 ya fue reemplazado por Qwen3 y posteriores). Reserva recursos para la migración
• ❌ Comprar hardware de nivel enterprise para un piloto: renta GPU en la nube los primeros 1-2 meses y luego compra con base en métricas reales

Práctica

Paso 1: piloto en una GPU en la nube antes de comprar hardware

Antes de comprar un servidor de $50K, renta una GPU en la nube por 1-2 semanas y mide la carga real.

# RunPod: el más cómodo para un piloto
# Registro en runpod.io, renta de una A100 80GB (el precio por hora está en el sitio)
# SSH al pod

# Instalar Docker (si no está instalado)
curl -fsSL https://get.docker.com | sh

# Arrancar vLLM con el modelo Qwen3 32B
docker run --gpus all -p 8000:8000 \
  -v ~/models:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-32B \
  --gpu-memory-utilization 0.90

# Probar una solicitud
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-32B",
    "messages": [{"role": "user", "content": "Explica RAG en tres oraciones"}]
  }'

Alternativas a RunPod: Lambda (lambda.ai), Anyscale (anyscale.com), Hyperstack, CoreWeave.

Paso 2: setup de producción en tu propio hardware

Cuando el piloto confirmó los parámetros, arma la producción. Checklist básico:

# Servidor con Ubuntu Server (la versión LTS vigente)
# Instalar los drivers de NVIDIA (elige la versión según CUDA y tu versión de vLLM)
sudo apt update && sudo ubuntu-drivers install

# NVIDIA Container Toolkit para soporte de GPU en Docker (según la documentación de NVIDIA)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Verificar que la GPU está disponible en Docker (pon la etiqueta vigente de la imagen nvidia/cuda)
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

# Clonamos el stack (creamos nuestro propio repo o usamos una plantilla)
mkdir -p /opt/internal-ai && cd /opt/internal-ai
# Copiamos el docker-compose.yml de la teoría (Tier 1)

# Arrancamos
docker compose up -d

# Vemos los logs
docker compose logs -f vllm

Paso 3: aprovisionar a los primeros usuarios

# Creamos el admin token con LiteLLM
MASTER_KEY=sk-master-clave-interna-cambiala

# Creamos el team de desarrollo
curl -X POST http://localhost:4000/team/new \
  -H "Authorization: Bearer $MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_alias": "dev-team",
    "max_budget": 500.0,
    "budget_duration": "30d",
    "models": ["qwen-32b"]
  }'
# Guarda el team_id de la respuesta

# Creamos una clave para cada desarrollador (usamos IDs seudonimizados)
for user in dev_user_001 dev_user_002 dev_user_003; do
  curl -X POST http://localhost:4000/key/generate \
    -H "Authorization: Bearer $MASTER_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"team_id\": \"<team_id_de_la_respuesta>\",
      \"user_id\": \"$user\",
      \"max_budget\": 20.0,
      \"duration\": \"90d\",
      \"rpm_limit\": 60,
      \"tpm_limit\": 100000,
      \"metadata\": {\"role\": \"developer\"}
    }"
done

Reparte las claves por 1Password o un canal seguro. Cada desarrollador configura su herramienta (Cursor, Continue.dev, Aider) con el endpoint interno.

Paso 4: monitoreo básico

# Arrancamos Prometheus + Grafana
docker compose up -d prometheus grafana

# Abrimos Grafana
# http://localhost:3001 (admin / admin-cambialo)
# Add data source → Prometheus → http://prometheus:9090

# Importamos un dashboard listo para vLLM
# Hay un dashboard de ejemplo en la documentación de vLLM (la sección sobre Prometheus y Grafana)
# Dashboards → Import → sube el JSON del ejemplo

Alertas clave que hay que configurar el primer día:

# alerts.yml para Prometheus
groups:
  - name: vllm-critical
    rules:
      # Los nombres de las métricas cambiaron entre versiones de vLLM: compáralos con el /metrics de tu versión
      - alert: GPU_OOM_Risk
        expr: vllm:gpu_cache_usage_perc > 0.95  # en las versiones nuevas, kv_cache_usage_perc
        for: 2m
        annotations:
          summary: "KV-cache llena >95% (riesgo de fila y OOM)"

      - alert: High_Latency
        expr: histogram_quantile(0.95, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le)) > 5
        for: 5m
        annotations:
          summary: "Latencia P95 > 5 segundos"

      - alert: vLLM_Down
        expr: up{job="vllm"} == 0
        for: 1m
        annotations:
          summary: "El endpoint de vLLM no está disponible"

Paso 5: fallback a la API (setup híbrido)

Para que la infraestructura local no sea un SPOF, configura un fallback automático a la API de Anthropic.

litellm-config.yaml con fallback:

model_list:
  - model_name: smart-assistant
    litellm_params:
      model: openai/Qwen/Qwen3-32B
      api_base: http://vllm:8000/v1
      api_key: dummy

  - model_name: smart-assistant-fallback
    litellm_params:
      # identificadores vigentes de los modelos: documentación de Anthropic
      model: anthropic/claude-sonnet-5-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks:
    - {"smart-assistant": ["smart-assistant-fallback"]}
  context_window_fallbacks:
    - {"smart-assistant": ["smart-assistant-fallback"]}
  timeout: 30
  num_retries: 2

Ahora, si vLLM se cae o se satura, las solicitudes se van automáticamente a Anthropic. El usuario no notará el downtime.

Checklist de preparación para producción (✅)

• El tamaño del hardware corresponde a la carga esperada (el piloto lo confirmó)
• El inference engine (vLLM/SGLang) está desplegado y estable por 7+ días
• API gateway (LiteLLM) con claves por usuario y rate limits
• Integración de SSO (Authentik/Keycloak) con el IdP corporativo
• Monitoreo (Prometheus + Grafana) con alertas críticas
• El audit log se escribe en la BD (retención de 90+ días)
• El procedimiento de fine-tune está documentado (si se usa)
• El fallback a la API de Anthropic/OpenAI está listo (enrutamiento de LiteLLM)
• Respaldo de modelos y configuraciones (regla 3-2-1)
• Runbook para fallas típicas (GPU OOM, OOM kill, red)
• Redundancia de energía y enfriamiento (UPS, enfriamiento de respaldo)
• Ingeniero de operaciones dedicado asignado (al menos de medio tiempo)
• Plan de recuperación ante desastres (RTO y RPO definidos)

Herramientas y recursos

Inference engines:

• vLLM: el más popular, equilibrado
• SGLang: el mejor throughput, funciones avanzadas
• TGI (HuggingFace): ecosistema HF (modo mantenimiento)
• Ollama: inicio fácil para pilotos

API gateway y autenticación:

• LiteLLM: proxy compatible con OpenAI con rate limiting + auditoría
• Authentik: IdP open source (SSO, SAML, OIDC)
• Keycloak: IdP enterprise (stack de Java)

UI:

• Open WebUI: una interfaz tipo ChatGPT para el equipo

Fine-tuning:

• Axolotl: framework flexible de fine-tuning
• LLaMA-Factory: UI + CLI para fine-tuning

GPU en la nube para pilotos:

• Anyscale: Ray administrado + serving
• RunPod: el más cómodo, pago por hora
• Lambda: contratos de largo plazo, venta de hardware
• CoreWeave: nivel enterprise
• Hyperstack: precios competitivos

Monitoreo:

• Grafana: nivel gratuito para equipos pequeños
• Prometheus: el estándar para métricas

Ideas clave

El self-host se paga a escala: un gasto en LLM de $5K+/mes o 50+ usuarios simultáneos. Por debajo de ese umbral, la API es más barata, simple y confiable. No compres un tractor para un huerto.

Un setup Tier 1 (1 servidor con dos tarjetas de 24GB + vLLM + LiteLLM + Open WebUI) se arma en una semana y cuesta del orden de $10-15K en hardware más la electricidad (referencia). Alcanza para un equipo de 10-20 personas.

LiteLLM es un middleware crítico: convierte la inferencia local en una plataforma de nivel enterprise: claves por usuario, rate limits, audit logs, seguimiento de costos, fallback automático a la API. Sin él, el self-host se queda como un juguete interno.

Un setup híbrido (el flujo principal local + las solicitudes complejas por la API de Anthropic) suele ser mejor que el self-host puro. El enrutamiento de LiteLLM lo hace transparente para el usuario.

El tiempo de operación es el principal costo oculto del self-host. Reserva 1-2 horas a la semana incluso en un setup estable. Sin un responsable dedicado, downtime eterno.

Qué sigue

→ AI Regulation & Compliance: qué requisitos sobre datos y modelos debe considerar un equipo que construye una plataforma de IA interna