Cómo realmente desplegué vLLM en Kubernetes (y la realidad de una GTX 1080)

6 Feb 2026 5 min read Technology
Cómo realmente desplegué vLLM en Kubernetes (y la realidad de una GTX 1080)

vLLM no es difícil de iniciar. Es difícil de ejecutar bien en hardware limitado. Aprendí esto cuando intenté desplegarlo en mi GTX 1080 y me di cuenta de que la mayoría de los modelos ni siquiera cabían en memoria.

He visto muchas discusiones de vLLM en r/LocalLLaMA y r/MachineLearning. Los mismos patrones de fallo aparecen: error de paralelismo de tensores, falta de memoria CUDA, descargas de modelos al iniciar el pod, errores de NCCL entre nodos. Solía pensar que estos eran casos extremos. Luego intenté desplegar vLLM yo mismo y golpeé el muro de memoria inmediatamente.

Este post es cómo realmente desplegué vLLM en Kubernetes. Es una opinión y asume que ya has probado que la inferencia autohospedada tiene sentido para tu carga de trabajo. Yo no lo había probado. Solo quería ver si podía hacerlo.

Para qué sirve realmente vLLM

vLLM es para servir a muchos usuarios concurrentes desde un número pequeño de GPUs. Sus ventajas, batching continuo, PagedAttention, paralelismo de tensores, solo importan cuando tienes concurrencia y presión de GPU.

Si tienes un usuario, Ollama probablemente sea mejor. Si tienes diez usuarios, tal vez todavía Ollama. Si tienes cien peticiones concurrentes o requisitos estrictos de latencia, vLLM empieza a tomar ventaja. Yo tengo un usuario. Yo mismo. Estaba optimizando algo que no necesitaba todavía. A veces hago eso.

La realidad del hardware

Mi homelab tiene una GTX 1080 con 8GB de VRAM. Esto no es mucho para LLMs modernos. Esto es lo que realmente cabe:

ModeloTamaño¿Cabe en 8GB?Notas
Llama 3.1 8B~4GB (Q4)El modelo más grande que puedo ejecutar cómodamente
Llama 3.1 70B~35GB (Q4)NoNecesitaría múltiples GPUs o cloud
Mistral 7B~4GB (Q4)Buena alternativa a Llama
CodeLlama 13B~7GB (Q4)Tal vezAl límite, podría fallar por memoria durante contextos largos

No puedo ejecutar los modelos para los que vLLM está diseñado. Todo el punto de vLLM es servir modelos grandes eficientemente. Mi GPU no puede contener modelos grandes. Esta fue la primera señal de que estaba usando la herramienta equivocada.

El despliegue que realmente funcionó

Mi despliegue base de Kubernetes se ve así:

apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-llama
namespace: vllm
spec:
replicas: 1
selector:
matchLabels:
app: vllm-llama
template:
metadata:
labels:
app: vllm-llama
spec:
runtimeClassName: nvidia
nodeSelector:
gpu-type: nvidia
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- --model
- meta-llama/Meta-Llama-3-8B-Instruct
- --tensor-parallel-size
- "1"
- --gpu-memory-utilization
- "0.75"
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: "1"
memory: 16Gi
volumeMounts:
- name: models
mountPath: /models
volumes:
- name: models
persistentVolumeClaim:
claimName: vllm-models

Nota que --gpu-memory-utilization es 0.75, no 0.90. En una tarjeta de 8GB, necesito más margen. Empecé en 0.90 y obtuve OOMKills durante la primera petición. Bajé a 0.75 y funcionó. Apenas.

Los errores más comunes (que realmente cometí)

  1. Asumir que vLLM haría mi GPU mágicamente más grande. No lo hace. vLLM optimiza throughput. No crea VRAM. Pasé una hora intentando cargar un modelo de 13B antes de revisar los requisitos de memoria.

  2. Descarga de modelo al iniciar. No pre-escenifiqué los pesos del modelo. El pod inició, vio que necesitaba Meta-Llama-3-8B-Instruct, y comenzó a descargar desde HuggingFace. Mi internet no es rápido. El pod tomó 15 minutos en estar listo. Durante ese tiempo, Kubernetes lo mató dos veces por fallar el readiness probe. Arreglé esto descargando el modelo al PVC primero, luego apuntando vLLM a la ruta local.

  3. Sin margen de memoria GPU. Ya mencioné esto. Poner --gpu-memory-utilization a 0.90 funciona en una 3090. En una 1080, se cae inmediatamente.

  4. Formato de cuantización equivocado. vLLM espera safetensors de HuggingFace, no GGUF. Tenía una versión GGUF del modelo de mi configuración de Ollama. vLLM se negó a cargarla. Tuve que re-descargar la versión safetensors. Eso fueron otros 20 minutos.

Lo que realmente observo

Cuatro métricas cubren la mayoría de lo que importa:

  • TTFT: tiempo hasta el primer token. Te dice qué tan rápido empiezan las peticiones nuevas. En mi 1080 con modelo de 8B, esto es unos 200ms. No es genial, pero usable.
  • TPOT: tiempo por token de salida. Te dice la velocidad de generación. Unos 50ms por token para prompts cortos. Más lento que una 3090, pero esperado.
  • Profundidad de cola: cuántas peticiones están esperando. Raramente veo esto por encima de 1 porque soy el único usuario.
  • Utilización de GPU: si la GPU está realmente ocupada. Sube al 95% durante la generación y cae a 0% entre peticiones. Esto es normal para un solo usuario.

Si la profundidad de cola crece mientras la utilización de GPU es baja, tu batching está mal o tu concurrencia es demasiado baja. Si la utilización de GPU es alta y la latencia es mala, necesitas más GPUs o un modelo más pequeño. En mi caso, la profundidad de cola nunca crece porque soy el único usuario. Estaba midiendo métricas para una carga de trabajo que no tenía.

Para qué realmente uso vLLM

Después de toda esta configuración, uso vLLM para exactamente una cosa: benchmarking. Quería comparar el throughput de vLLM con Ollama bajo carga. Usé un script simple de Python para enviar peticiones concurrentes y medir los resultados.

Peticiones ConcurrentesOllama (tokens/seg)vLLM (tokens/seg)
11215
21014
4713
8412

Para un solo usuario, la diferencia es insignificante. Para usuarios concurrentes, vLLM es claramente mejor. Pero no tengo usuarios concurrentes. Tengo yo.

Mantengo vLLM ejecutándose porque podría necesitarlo algún día. Pero honestamente, Ollama está bien para mi carga de trabajo actual. vLLM fue una optimización para un problema que no tengo todavía, en hardware que no puede soportarlo.

Conclusión

vLLM es el motor de inferencia correcto para IA autohospedada de alto throughput y multi-usuario. El despliegue no es conceptualmente difícil, pero los detalles importan. En una GTX 1080, los detalles son principalmente sobre restricciones de memoria.

Ejecuta Ollama hasta que tengas una razón para no hacerlo. Cuando esa razón sea real, y tengas el hardware para soportarla, vLLM estará esperando. No despliegues vLLM solo porque es “de producción”. Desplígualo cuando tengas carga de producción y hardware de producción.

La GTX 1080 me enseñó que no toda GPU sirve para servir LLMs. Es una gran tarjeta para aprender, experimentar, y modelos pequeños. No es un servidor de inferencia de producción. Pasé un día aprendiendo eso. Tú no tienes que hacerlo.

#Vllm #Kubernetes #IA #Gpu #Llm #produccion #gtx-1080