Key Takeaways
- Máquina única: 1 GPU, 10-50 usuarios concurrentes, configuración simple.
- Multi-GPU: 2-8 GPUs, 50-200 usuarios, orquestación con Kubernetes.
- Empresarial: 5-50 GPUs, 500+ usuarios, distribuido, alta disponibilidad.
- Balanceo de carga: El round-robin distribuye las solicitudes entre los pods de GPU.
- Monitoreo: Rastrea latencia, profundidad de cola, utilización de GPU y tasas de error.
- A partir de abril de 2026, Kubernetes es el estándar para el despliegue empresarial de LLMs.
¿Cómo escalar de una sola máquina a un sistema distribuido?
Progresión de máquina única a producción:
| Etapa de despliegue | Número de GPUs | Usuarios concurrentes | Disponibilidad SLA | Configuración de infraestructura |
|---|---|---|---|---|
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
| — | — | — | — | — |
¿Cómo implementar el balanceo de carga?
El balanceador de carga enruta las solicitudes al pod de inferencia menos ocupado.
Round-robin: Distribuye de forma equitativa entre los pods (más simple).
Menos cargado: Envía al pod con la cola más corta (mejor latencia).
Sesiones adhesivas: El mismo usuario siempre usa el mismo pod (para contexto, pero arriesgado si el pod falla).
# Kubernetes Service con balanceo de carga
apiVersion: v1
kind: Service
metadata:
name: llm-inference
spec:
selector:
app: vllm-inference
ports:
- port: 8000
targetPort: 8000
type: LoadBalancer
sessionAffinity: None # Round-robin entre pods¿Cómo implementar redundancia y conmutación por error?
La alta disponibilidad requiere componentes redundantes:
Réplicas de pods: Varios pods de inferencia. Si uno falla, los demás manejan las solicitudes.
Comprobaciones de salud: Kubernetes elimina automáticamente los pods no saludables.
Redundancia de almacenamiento: Los archivos del modelo se replican entre nodos.
Conmutación DNS: Si falla todo un centro de datos, enruta al centro de respaldo.
¿Qué debes monitorear?
Los despliegues empresariales deben monitorear:
- Latencia: Tiempo por solicitud (percentiles p50, p95, p99).
- Profundidad de cola: Cuántas solicitudes están esperando. >10 = sobrecarga.
- Utilización de GPU: Debe ser 70-90 %. <50 % = sobredimensionado. >95 % = subdimensionado.
- Tasa de error: % de solicitudes fallidas. Debe ser <0,1 %.
- Rendimiento: Tokens/seg en todos los pods.
- Disponibilidad: % del tiempo que el servicio está disponible (objetivo 99,9 %).
- Costo por consulta: $/solicitud (hardware amortizado).
¿Cómo optimizar costos a escala?
A escala, enfócate en:
- Utilización de GPU: Cuanto más alta, menor es el costo por solicitud. Objetivo 80-90 %.
- Cuantización del modelo: Q4 vs FP16 usa 4× menos VRAM, misma velocidad. Reduce el número de GPUs necesarias.
- Tamaño de lote: Lotes más grandes = menor costo por solicitud (pero mayor latencia).
- Auto-scaling: Escala hacia abajo de noche, hacia arriba de día (ahorra 30-50 % de costos en la nube).
- Multi-tenancy: Ejecuta 2-3 modelos por GPU (si el VRAM lo permite). Mayor utilización.
Errores comunes al escalar en la empresa
- Ignorar los requisitos de latencia. Acuerda el SLA de latencia p99 antes del despliegue. Una latencia de 2 segundos puede parecer correcta hasta que los usuarios se quejen.
- Sobreaprovisionamiento para el pico. Si el pico son 100 usuarios durante 2 horas/día, no compres hardware para 100 usuarios concurrentes todo el día. Usa auto-scaling.
- Aislamiento de fallos deficiente. Si el crash de un pod detiene el balanceador de carga, la arquitectura es incorrecta. Prueba los escenarios de fallo.
- Monitorear las métricas incorrectas. Monitorear la utilización de GPU pero no la latencia es al revés. La latencia impacta a los usuarios.
- Asumir que las herramientas open-source escalan a nivel empresarial. Ollama funciona muy bien para 1 usuario. Para 500 usuarios concurrentes, se necesita monitoreo y orquestación empresarial.
¿Cuáles son las preguntas más comunes sobre el escalado de LLMs locales?
¿Cuántas GPUs necesitamos para un despliegue empresarial?
Depende de la concurrencia y los requisitos de latencia. 100 usuarios concurrentes en el modelo 7B: ~5-8 GPUs. 500 usuarios concurrentes: 20-30 GPUs. Fórmula: (usuarios concurrentes × latencia esperada) / (tokens/seg por GPU).
¿Cuál es la diferencia entre balanceo de carga y auto-scaling?
El balanceo de carga distribuye las solicitudes entre los pods existentes. El auto-scaling añade o elimina pods según la carga. Ambos son necesarios: el balanceo de carga reparte el trabajo ahora, el auto-scaling ajusta la capacidad.
¿Cómo gestionamos los fallos de GPU?
Kubernetes reprograma automáticamente los pods a GPUs saludables. Si una GPU falla, Kubernetes la marca como no disponible y enruta el tráfico a otras. Mantén redundancia: si necesitas 8 GPUs, aprovisiona 10.
¿Qué SLA de latencia debemos establecer como objetivo?
La latencia p99 <2 segundos es el estándar para chatbots. p99 <500 ms para el autocompletado en tiempo real. Define el SLA según la experiencia del usuario y elige el hardware y el tamaño de lote para cumplirlo.
¿Cómo monitoreamos un clúster de inferencia distribuido?
Monitorea por pod y a nivel de clúster: utilización de GPU, profundidad de cola, latencia (p50/p95/p99), tasa de error, rendimiento y disponibilidad. Usa Prometheus + Grafana o equivalente.
¿Es más barato el escalado local que en la nube?
Sí, a escala. El punto de equilibrio es ~500 k tokens/mes. Local: alto costo inicial ($500 k-2 M en hardware), luego bajo costo por solicitud. Nube: sin costo inicial, alto costo por solicitud ($0,15-60/1 M tokens).
Fuentes
- Documentación de Kubernetes -- kubernetes.io/docs
- Guía de despliegue de vLLM -- docs.vllm.ai/en/serving/distributed_serving.html
- Monitoreo con Prometheus -- prometheus.io