vLLM Producción: Conclusión FAQ y Próximos Pasos
Tabla de contenidos
Parte 6 de 6. Esta es la parte final de la serie. Empieza desde la Parte 1: Introducción y Arquitectura, o navega a cualquier parte usando los enlaces a continuación.
Conclusión
Desplegar vLLM en Kubernetes es construir un sistema que aguante tráfico real a escala real. Esta serie cubrió GPU-aware scheduling, tensor parallelism, cuantización, autoscaling con métricas personalizadas y observabilidad en Grafana con TTFT, TPOT y throughput.
Empieza pequeño: despliegue de una sola GPU, valida SLIs contra tablas de benchmark, luego escala a tensor parallelism multi-GPU y HPA según lo demande el tráfico.
Siguientes pasos:
- Lee Ollama vs vLLM: Choosing the Right LLM Inference Engine para una comparación más profunda
- Explora LLMOps: Monitoring and Observability for AI Workloads para observabilidad de IA más amplia
- Aprende Kubernetes GPU Scheduling: A Complete Guide para la historia completa de GPUs
- Prueba How to Deploy Ollama on Kubernetes for Local LLMs para un punto de entrada más ligero
Si te fue útil esta guía, dale star al repositorio de vLLM en GitHub y suscríbete para más contenido de infraestructura de IA en producción.
Preguntas frecuentes
¿Qué es vLLM?
vLLM es un motor de inferencia open-source construido para serving de LLM de alto rendimiento. Usa PagedAttention, continuous batching y tensor parallelism para servir modelos eficientemente en GPUs NVIDIA mediante una API compatible con OpenAI. Consulta la documentación oficial para la lista completa.
¿Cuánta memoria GPU necesito para vLLM?
Depende del tamaño del modelo y la precisión. Aquí tienes una referencia práctica para producción:
| Tamaño de modelo | FP16/BF16 | AWQ 4-bit | GPTQ 4-bit | GPU mínimo |
|---|---|---|---|---|
| 7B | ~14 GB | ~5 GB | ~5 GB | 1× A10G (24 GB) |
| 13B | ~26 GB | ~9 GB | ~9 GB | 1× A100 40GB |
| 70B | ~140 GB | ~45 GB | ~45 GB | 2× A100 80GB |
| 405B | ~810 GB | ~270 GB | ~270 GB | 10× H100 80GB (FP16); 4× H100 80GB (AWQ) |
Agrega ~20% para el KV cache a tu batch size objetivo. En caso de duda, elige AWQ, que ofrece la mejor relación calidad-por-VRAM en vLLM hoy.
¿Cómo cuantizo un modelo para vLLM?
vLLM carga modelos pre-cuantizados mediante la bandera --quantization. No puedes cuantizar on-the-fly en runtime. Tus opciones:
- AWQ: Descarga de TheBloke en HuggingFace; usa
--quantization awq --dtype auto - GPTQ: Descarga un checkpoint GPTQ; usa
--quantization gptq - FP8: Usa
--quantization fp8 --dtype autoen GPUs H100/B200
La cuantización reduce la VRAM en 40–70%, permitiendo modelos más grandes en menos GPUs.
¿Es vLLM mejor que Ollama para producción?
Sí, para serving en producción. vLLM ofrece 3–5× mayor throughput gracias al continuous batching y al tensor parallelism multi-GPU nativo. Ollama brilla para desarrollo local pero se queda corto en scheduling, escalado y observabilidad. Consulta la comparación completa para más detalles.
¿Puedo ejecutar vLLM en CPUs en lugar de GPUs?
vLLM tiene soporte experimental para CPU, pero no es adecuado para serving. El throughput en CPU es 50–100× menor que en GPU. Quédate con GPUs NVIDIA (A10G, A100, H100) para producción.
¿Cómo escalo vLLM horizontalmente entre múltiples nodos?
Usa el vLLM production stack con Ray, o KServe con pipeline parallelism. Los Deployments nativos de Kubernetes tienen un límite de multi-GPU de un solo nodo. Para modelos 70B+ a escala, el Helm chart de Production Stack maneja service discovery y routing entre réplicas automáticamente.
¿Cuál es el mejor batch size para vLLM?
Para chat interactivo, apunta a 128–256 secuencias concurrentes (TTFT p99 < 500ms). Para jobs batch offline, empuja 512+ para máximo throughput. Siempre valida con benchmark_serving.py antes de fijar un batch size.
¿Cómo monitoreo vLLM en producción?
Prometheus hace scrape del endpoint /metrics y Grafana visualiza los datos. Trackea cuatro SLIs: TTFT p99, TPOT p99, profundidad de cola (vllm_num_requests_waiting), y utilización de memoria GPU. La Parte 4 tiene las queries PromQL exactas.
¿Puedo usar HPA con vLLM?
Sí, pero solo con métricas personalizadas. HPA basado en CPU no sirve para inferencia de LLM. Instala Prometheus Adapter, expone vllm_num_requests_running como métrica personalizada, y configura HPA para escalar en la profundidad de la cola. Configura la estabilización de scale-down a 5+ minutos, ya que el cold-start del modelo lo exige.