vLLM: Paralelismo de Tensores y Cuantización

Parte 3 de 6. En la Parte 2 desplegamos vLLM en Kubernetes. Ahora configuramos tensor parallelism y cuantización para producción. Continúa en Parte 4: Ajuste de Rendimiento y Monitoreo.

Configuración de producción: Tensor parallelism y cuantización

Tensor parallelism y cuantización son las dos palancas de mayor impacto para la inferencia en producción con vLLM. Una distribuye modelos entre GPUs, la otra reduce la huella de VRAM.

Cuantización para eficiencia de memoria

La cuantización reduce la precisión de los pesos del modelo para que modelos más grandes quepan en menos GPUs. vLLM soporta varios métodos mediante la bandera --quantization:

Método	Bits	Reducción de VRAM	Pérdida de precisión	Impacto en velocidad	Ideal para
AWQ	4-bit	~70%	Muy baja	Más rápido (kernel Marlin)	Serving en producción
GPTQ	4-bit	~70%	Baja	Rápido	Investigación, modelos fine-tuned
FP8	8-bit	~40%	Mínima	Más rápido (H100)	Clusters H100/B200
Ninguna (FP16/BF16)	16-bit	Línea base	Ninguna	Línea base	Máxima precisión

Ejemplo AWQ (recomendado para la mayoría de cargas de serving):

args:
  - --model
  - TheBloke/Llama-2-70B-AWQ
  - --quantization
  - awq
  - --tensor-parallel-size
  - "2"  # 70B AWQ cabe en 2× A100 40GB
  - --dtype
  - auto

Nota sobre --quantization awq: Esta bandera espera un checkpoint AWQ pre-cuantizado. No puedes cuantizar on-the-fly al cargar. Descarga modelos cuantizados de TheBloke en HuggingFace o usa AutoAWQ tú mismo.

FP8 en H100 (la ruta más rápida si tienes el hardware):

args:
  - --model
  - meta-llama/Meta-Llama-3-70B-Instruct
  - --quantization
  - fp8
  - --dtype
  - auto
  - --tensor-parallel-size
  - "2"

Nota: La cuantización FP8 requiere GPUs de generación Hopper (H100, H200) o más nuevos. No está soportada en A100 o arquitecturas anteriores. Usa AWQ o GPTQ en GPUs Ampere y anteriores.

Para orientación sobre los trade-offs de cuantización, consulta la documentación de rendimiento de deep learning de NVIDIA.

Ajuste de batch size

--max-num-seqs controla el batch size máximo, el parámetro de mayor impacto para throughput en producción.

Punto de partida: Para modelos 7B, configura --max-num-seqs 256. Para 70B, empieza en 128. Ejecuta benchmark_serving.py a tu tasa de requests objetivo. Reduce el batch size si TTFT p99 excede tu SLO; increméntalo si la utilización GPU está por debajo de 80%.

Benchmarks en A100 80GB (Llama 3 8B, 1024 input / 256 output tokens):

Batch Size	Throughput (tok/s)	TTFT p99 (ms)	TPOT p99 (ms)	Utilización GPU
64	1,850	180	42	62%
128	2,940	320	58	78%
256	3,820	580	95	89%
512	4,100	1,200	180	94%

Fuente: Benchmark en vLLM 0.8.4, NVIDIA A100 80GB SXM4, CUDA 12.4, continuous batching habilitado.

Recomendación: Apunta a 128–256 para chat interactivo (TTFT < 500ms) y 512+ para jobs de inferencia batch offline.

Límites de memoria y utilización GPU

Configura --gpu-memory-utilization a 0.90 para nodos de inferencia dedicados, 0.85 si corres sidecars. Nunca pases de 0.95. CUDA necesita espacio para scratch space. He visto 0.98 caerse con CUDA out of memory en ventanas de batch pico.

Manejo de graceful shutdown

vLLM no incluye graceful shutdown. Tienes que configurarlo en Kubernetes para evitar requests perdidas durante rolling updates:

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 30"]
terminationGracePeriodSeconds: 60

Usa rolling updates con maxUnavailable: 0 para despliegues sin downtime:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Continúa en Parte 4: Ajuste de Rendimiento y Monitoreo para gestión del KV cache, estrategias de scheduling y observabilidad con Prometheus.