Rtx4090 on lo0 — Blog Técnico

Optimizando el decode en vLLM: exprimir cada token en hardware pequeño

Thu, 04 Jun 2026 23:00:00 +0000

TL;DR

El decode es la fase en la que vLLM genera tokens de salida uno a uno. Es memory-bound, no compute-bound: la GPU pasa más tiempo esperando que lleguen los pesos desde VRAM que haciendo cálculos. En hardware pequeño —RTX 4090 (24 GB) o L40 (48 GB)— el decode mal configurado desaprovecha la mitad de la capacidad de la tarjeta. Cinco parámetros de vLLM cambian la ecuación: gpu-memory-utilization, max-num-seqs, speculative decoding, KV cache en FP8 y un swap-space correctamente en cero. Bien calibrados, la diferencia es real: de 15 tokens/s a 35–50 tokens/s en el mismo hardware.

La analogía

Un obrero de cadena de montaje que ensambla coches. Cada coche requiere exactamente el mismo proceso: va a buscar la pieza al almacén, vuelve, la atornilla, repite. El tiempo de transporte al almacén —la latencia de VRAM— es fijo y no se puede eliminar. Pero hay formas de hacerlo menos doloroso:

Tener varios coches en paralelo en la cadena (más concurrencia, mismo tiempo de transporte amortizado).
Que un ayudante prefabrique piezas comunes (speculative decoding: el draft model propone, el verifier confirma).
Almacenar en el taller sólo las piezas más usadas (KV cache cuantizado: caben más contextos en el mismo espacio).

Las tres estrategias son exactamente los tres ejes de optimización del decode en vLLM.

Por qué el decode es memory-bound

Durante el prefill, la GPU procesa N tokens en paralelo: la operación de atención es un matmul grande y las unidades de cómputo están ocupadas. Durante el decode, procesa 1 token por paso: el matmul se convierte en un vector-matrix product, operación que infrautiliza los tensor cores.

El ratio de utilización de cómputo durante decode típico en una RTX 4090:

$$\text{MFU}_{decode} \approx 5–15% \quad \text{(vs 40–60% en prefill)}$$

El cuello no es la potencia de cálculo, sino el ancho de banda. Para generar cada token, el modelo tiene que leer sus pesos completos desde VRAM:

$$\text{tiempo_por_token} \approx \frac{\text{tamaño_pesos_bytes}}{\text{ancho_banda_VRAM}}$$

Para Qwen2.5-7B en BF16 (14 GB de pesos) en una RTX 4090 (1.008 GB/s):

$$t \approx \frac{14 \times 10^9}{1.008 \times 10^{12}} \approx 13.9 \text{ ms/token} \approx 72 \text{ tokens/s teórico máximo}$$

El valor real es menor (~30–50 tok/s) por overhead de scheduler, atención sobre el KV cache creciente y otras latencias. Pero el límite teórico marca el techo.

Con Q4_K_M (pesos ~4 GB):

$$t \approx \frac{4 \times 10^9}{1.008 \times 10^{12}} \approx 3.97 \text{ ms/token} \approx 252 \text{ tokens/s teórico}$$

Cuantizar el modelo es la forma más directa de mejorar el throughput de decode en hardware memory-bound. Todo lo demás optimiza sobre ese techo.

Las cinco palancas

1. Darle a vLLM toda la VRAM que puedas — `--gpu-memory-utilization`

--gpu-memory-utilization (abreviado --gpu-mem-util) define la fracción de VRAM disponible que vLLM puede usar para el KV cache, una vez cargados los pesos del modelo. El resto lo reserva para activaciones durante el forward pass y el contexto CUDA.

vllm serve mi-modelo \
 --gpu-memory-utilization 0.92

El valor por defecto es 0.90. En bare metal donde ningún otro proceso usa la GPU, 0.92–0.95 es seguro. No subas de 0.95: vLLM necesita margen para activaciones durante picos de batch, y quedarse sin VRAM en medio de una inferencia resulta en un crash del proceso, no en un error limpio.

Por qué importa: más KV cache disponible = más requests simultáneos en vuelo = mejor utilización de la GPU durante decode. PagedAttention asigna el KV cache en bloques de tamaño fijo (16 tokens/bloque por defecto), y vLLM los gestiona como páginas de memoria virtual. A más bloques disponibles, más requests puede servir sin que ninguna se quede esperando por espacio.

RTX 4090, Qwen2.5-7B-BF16 (14 GB pesos):
VRAM total: 24 GB
Pesos: 14 GB
Disponible para KV cache: 10 GB
gpu-memory-utilization 0.90 → 0.90 × 10 GB = 9 GB para KV cache
gpu-memory-utilization 0.94 → 0.94 × 10 GB = 9.4 GB → ~4% más de tokens en vuelo

El impacto es modesto con modelos que caben cómodos, pero se amplifica con modelos que apuran la VRAM.

2. Concurrencia real — `--max-num-seqs`

--max-num-seqs es el número máximo de requests que vLLM puede tener en proceso simultáneamente (sumando prefill y decode). Es el parámetro que controla la concurrencia efectiva del sistema.

vllm serve mi-modelo \
 --max-num-seqs 128

El efecto es directo: más requests en decode simultáneo = mejor amortización del coste fijo de leer pesos. Cuando el batch de decode crece de 1 a 8, el tiempo de generar 8 tokens es casi el mismo que generar 1 (los pesos se leen una sola vez para todos). El throughput agregado escala casi linealmente hasta que el KV cache o la VRAM de activaciones se convierten en el cuello.

$$\text{throughput_agregado}(B) \approx B \times \text{throughput}(1) \quad \text{para } B \ll B_{max}$$

Error común: subir --max-num-seqs sin asegurarse de que hay suficiente KV cache en VRAM para todas las requests. Si vLLM no puede alojar los KV cache de 128 requests simultáneas, hace preemption (pausa alguna request y libera su KV cache) con coste de latencia. Monitoriza vllm:num_preemptions_total.

Interacción con --max-num-batched-tokens: el scheduler de vLLM procesa hasta max-num-batched-tokens tokens por paso. Si tienes 128 requests en decode generando 1 token cada una, eso son 128 tokens de decode. El presupuesto de decode consume 128 tokens del presupuesto total; el resto lo dedica a prefill en chunks. Ajusta ambos valores conjuntamente.

# Para RTX 4090 sirviendo ~50 usuarios concurrentes con respuestas de hasta 512 tokens
vllm serve mi-modelo \
 --max-num-seqs 64 \
 --max-num-batched-tokens 8192
# 64 tokens de decode por paso + hasta 8128 tokens de prefill chunked

3. Speculative decoding — `--speculative-model` + `--num-speculative-tokens`

Speculative decoding es el cambio más impactante para decode en hardware pequeño. La idea es simple: un modelo draft pequeño propone varios tokens a la vez, y el modelo verifier los valida o rechaza en un solo forward pass.

vllm serve Qwen/Qwen2.5-7B-Instruct \
 --speculative-model Qwen/Qwen2.5-0.5B-Instruct \
 --num-speculative-tokens 5 \
 --speculative-draft-tensor-parallel-size 1

Por qué funciona: el verifier de 7B tiene que leer 14 GB de pesos por paso. Con 5 tokens propuestos, si el acceptance rate es del 80%, se generan de media 4–5 tokens por paso de verifier en vez de 1. El throughput efectivo sube sin que la GPU trabaje más.

El acceptance rate (α) depende de qué tan bien el draft predice la distribución del verifier. Para el mismo dominio, modelos de la misma familia suelen tener α > 0.75:

$$\text{speedup} \approx \frac{1 + \alpha \cdot k}{1 + \alpha \cdot k / \text{cost_ratio}}$$

Donde $k$ es el número de tokens propuestos y cost_ratio es el ratio de coste draft/verifier. Para un 0.5B draft y 7B verifier (ratio ~14×):

$$\text{speedup} \approx 1 + 0.8 \times 5 \approx 5 \text{ (teórico máximo, no alcanzable)}$$

En práctica, con α = 0.75 y k = 5 en hardware sin NVLink: 1.8–2.5× más tokens/s comparado con decode solo.

EAGLE-3 en 2026: los mejores drafters actuales no son versiones small del mismo modelo, sino redes especializadas en predecir la distribución del verifier. EAGLE-3 reporta 3–6.5× speedup sobre decode vanilla en benchmarks públicos. En producción con batches mixtos el speedup real es más conservador (1.5–3×). vLLM soporta EAGLE/EAGLE-2 via --speculative-model:

# Con un drafter EAGLE (requiere drafter entrenado específicamente para el base model)
vllm serve meta-llama/Llama-3.1-8B-Instruct \
 --speculative-model yuhuili/EAGLE3-LLaMA3.1-Instruct-8B \
 --num-speculative-tokens 6

Cuándo el speculative decoding NO ayuda:

Batches muy grandes (>32 requests): el acceptance rate varía entre requests y el batch pasa más tiempo en re-draft que en aceptar.
Tareas de alta entropía (brainstorming, código muy creativo): el draft predice peor, α cae por debajo de 0.5 y el overhead del draft pesa más que la ganancia.
Si el modelo draft no cabe en la VRAM disponible junto al verifier.

En una RTX 4090 con un 7B verifier y un 0.5B draft (BF16): 14 + 1 GB = 15 GB. Quedan 9 GB para KV cache. Funciona.

4. KV cache cuantizado — `--kv-cache-dtype fp8`

Ya se cubrió en el artículo de prefill para su efecto en capacidad de contexto. Desde el punto de vista del decode, el beneficio es diferente: más tokens caben en el KV cache → más requests simultáneas sin preemption → mejor throughput agregado.

vllm serve mi-modelo \
 --kv-cache-dtype fp8 \
 --calculate-kv-scales

Advertencia de precisión en decode: el KV cache se lee en cada paso de atención del decode. La cuantización introduce ruido en las activaciones de atención. Para textos largos (>4K tokens de contexto) puede acumularse. En benchmarks de calidad (MMLU, HellaSwag) la degradación con FP8 KV y --calculate-kv-scales es <0.5% en modelos modernos. Sin --calculate-kv-scales, la degradación puede ser mayor porque las escalas se fijan estáticamente.

Combinación óptima para RTX 4090:

vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
 --quantization awq \  # pesos en INT4: 4 GB modelo
 --kv-cache-dtype fp8 \  # KV cache a mitad de tamaño
 --calculate-kv-scales \
 --gpu-memory-utilization 0.94

# VRAM disponible: 24 - 4 = 20 GB para KV cache
# Con FP8: ~40 KB/token (vs 80 KB BF16) → 20 GB / 40 KB = 500.000 tokens de contexto total
# Con max-num-seqs 64 y ctx de 4K: 64 × 4096 × 40KB = 10 GB → cabe con margen

5. Eliminar el swap — `--swap-space 0`

--swap-space define cuánta RAM de sistema (no VRAM) puede usar vLLM para hacer preemption de KV caches. Cuando vLLM tiene más requests activas de las que caben en VRAM, puede “pausar” algunas moviendo su KV cache a RAM y reactivarlas más tarde.

El problema: mover un KV cache de 4K tokens de VRAM a RAM y de vuelta tiene una latencia de decenas de milisegundos vía PCIe. Para un sistema donde quieres latencia predecible, el swap introduce jitter inaceptable.

vllm serve mi-modelo \
 --swap-space 0

Con --swap-space 0, cuando vLLM no puede alojar más requests en VRAM, directamente las encola en vez de hacer preemption. La cola añade latencia de espera, pero es predecible y no interrumpe las requests ya en vuelo.

¿Cuándo sí tener swap? Si tu workload tiene picos de demanda cortos y puedes tolerar jitter ocasional a cambio de no rechazar requests, un swap de 4–8 GB puede ser útil. En despliegues ENS donde la latencia es un SLA contrato, --swap-space 0 es la opción correcta.

La configuración de referencia por hardware

RTX 4090 (24 GB) — modelo 7B, uso interno

vllm serve Qwen/Qwen2.5-7B-Instruct \
 --gpu-memory-utilization 0.92 \
 --max-model-len 8192 \
 --max-num-seqs 64 \
 --max-num-batched-tokens 8192 \
 --enable-chunked-prefill \
 --enable-prefix-caching \
 --kv-cache-dtype fp8 \
 --calculate-kv-scales \
 --swap-space 0 \
 --speculative-model Qwen/Qwen2.5-0.5B-Instruct \
 --num-speculative-tokens 5 \
 --speculative-draft-tensor-parallel-size 1 \
 --dtype bfloat16

Throughput esperado: 35–55 tokens/s por usuario, hasta 64 simultáneos, TTFT <500ms para prompts <1K tokens.

L40 (48 GB) — modelo 14B, multi-usuario

vllm serve Qwen/Qwen2.5-14B-Instruct \
 --gpu-memory-utilization 0.90 \
 --max-model-len 16384 \
 --max-num-seqs 128 \
 --max-num-batched-tokens 16384 \
 --enable-chunked-prefill \
 --enable-prefix-caching \
 --kv-cache-dtype fp8 \
 --calculate-kv-scales \
 --swap-space 0 \
 --speculative-model Qwen/Qwen2.5-1.5B-Instruct \
 --num-speculative-tokens 5 \
 --dtype bfloat16

Throughput esperado: 25–40 tokens/s por usuario, hasta 128 simultáneos con speculative decoding activo, TTFT <800ms para prompts <2K tokens.

Cómo medir que el decode está optimizado

# Métricas clave en vllm:8000/metrics

vllm:generation_tokens_total # tokens generados en total → tendencia
vllm:e2e_request_latency_seconds_* # latencia end-to-end por percentil
vllm:time_per_output_token_seconds_* # ITL (inter-token latency)
vllm:num_preemptions_total # si sube, KV cache se está llenando
vllm:spec_decode_draft_acceptance_rate # hit rate del speculative decoding

Si spec_decode_draft_acceptance_rate < 0.6, el drafter no está ayudando: desactiva speculative decoding o busca un drafter mejor entrenado para tu modelo/dominio.

Si num_preemptions_total crece, tienes demasiadas requests simultáneas para el KV cache disponible. Opciones: bajar max-num-seqs, activar FP8 KV cache, bajar max-model-len, o cuantizar más el modelo.

Implicaciones para inferencia on-premise

En un despliegue soberano con hardware fijo, no puedes comprar más GPUs a voluntad. Cada décima de gpu-memory-utilization bien calibrada, cada punto de acceptance rate del speculative decoding y cada MB de KV cache liberado por FP8 son capacidad real que no tienes que provisionar con otro nodo.

La combinación de pesos cuantizados (AWQ/GPTQ), KV cache FP8 y speculative decoding permite que un 14B sirva en una L40 lo que sin optimizaciones requeriría dos L40 en tensor parallel. Eso es el argumento económico para invertir tiempo en estos parámetros.

El decode no se puede acelerar infinitamente en hardware memory-bound: el límite teórico lo pone el ancho de banda de VRAM. Pero la diferencia entre el mínimo y el máximo alcanzable en ese hardware puede ser 3–4× con las palancas correctas.

Ver también

https://blog.lo0.es/posts/prefill-optimizaciones-vllm/ — las optimizaciones de la fase de prefill: chunked prefill, prefix caching y FP8 KV
https://blog.lo0.es/posts/speculative-decoding-fundamentos/ — cómo funciona el speculative decoding por dentro
https://blog.lo0.es/posts/kv-cache-fundamentos/ — la estructura que el decode consulta en cada token
https://blog.lo0.es/posts/quantization-fundamentos-inferencia/ — por qué cuantizar pesos cambia el techo de velocidad del decode
https://blog.lo0.es/posts/continuous-batching-fundamentos/ — la base de la gestión de concurrencia en vLLM
https://blog.lo0.es/posts/vllm-otel-instrumentacion-optimizaciones/ — cómo medir con Prometheus si speculative decoding, gpu-memory-utilization y max-num-seqs están funcionando: spec_decode_draft_acceptance_rate, num_preemptions_total y la matriz de diagnóstico

Referencias

Efficient Memory Management for Large Language Model Serving with PagedAttention — Kwon et al., 2023
EAGLE-2: Faster Inference of Language Models with Dynamic Draft Trees — Li et al., 2024
Fast Inference from Transformers via Speculative Decoding — Leviathan et al., 2022
vLLM Optimization and Tuning — documentación oficial
vLLM Speculative Decoding
FP8 KV Cache en vLLM

Optimizando el prefill en vLLM: los knobs que tu TTFT no perdona

Thu, 04 Jun 2026 22:00:00 +0000

TL;DR

El prefill es la fase en la que vLLM procesa tu prompt de entrada y produce el KV cache inicial. Es compute-bound (a diferencia del decode, que es memory-bound), tarda más cuanto más largo es el prompt, y bloquea el decode de todas las demás requests en cola. Hay cuatro palancas en vLLM que cambian radicalmente su comportamiento: chunked prefill, prefix caching, FP8 KV cache y el presupuesto de tokens por batch. Con hardware modesto —una RTX 4090 de 24 GB o una L40 de 48 GB— la diferencia entre ignorarlas y usarlas bien puede ser un TTFT 3× menor y un 40% más de throughput agregado.

La analogía

Imagina una imprenta de principios del siglo XX. Componer los tipos de plomo (preparar el molde) es lento y bloquea la prensa. Imprimir las páginas ya compuestas es rápido, pero necesita el molde listo antes de empezar.

El prefill es componer los tipos. El decode es imprimir. Una prensa que sólo puede hacer una cosa a la vez —o compone o imprime— deja la maquinaria parada la mitad del tiempo. La solución histórica fue tener un obrero componiendo la siguiente plana mientras la anterior ya estaba en prensa. Eso es, exactamente, chunked prefill.

Qué es el prefill realmente

Cuando llega un request a vLLM, el motor tiene que procesar todos los tokens del prompt de una vez antes de poder emitir el primer token de respuesta. Durante ese procesamiento calcula, para cada token del prompt, sus vectores Key y Value de la atención. El resultado —el KV cache inicial— se almacena en VRAM y se usa durante todo el decode posterior.

A diferencia del decode, donde el modelo procesa un token nuevo por paso, en el prefill procesa N tokens de golpe. Eso lo hace mucho más eficiente en FLOPs/token (las GPUs son buenas en matmuls grandes), pero tiene un coste cuadrático en atención:

$$\text{FLOPs_atención_prefill} \approx 4 \cdot N^2 \cdot d_{model}$$

Con un prompt de 1.000 tokens y $d_{model} = 4096$ (Qwen2.5-7B): $4 \cdot 10^6 \cdot 4096 \approx 16 \times 10^9$ FLOPs sólo en atención. Con 4.000 tokens, 256× más por la naturaleza cuadrática.

Prefill (compute-bound):
prompt tokens → [attention O(N²)] → [FFN] → KV cache inicial
Decode (memory-bound):
1 token nuevo → [cross-attention sobre KV cache] → siguiente token

Por qué el prefill es un problema en hardware pequeño

En una H100 con 3,35 TB/s de ancho de banda, un prefill largo se amortiza rápido. En una RTX 4090 (1,008 TB/s) o una L40 (864 GB/s), el cuello de botella aparece antes y tiene consecuencias concretas:

El problema del head-of-line blocking. Por defecto, vLLM procesa un prefill completo antes de hacer cualquier decode. Si tienes 10 requests en cola —9 en decode, 1 con un prompt de 8.000 tokens— esas 9 requests se detienen mientras la GPU mastica el prefill largo. Sus usuarios ven que el streaming se congela. Esto se llama head-of-line blocking y es el enemigo número uno del TTFT en producción.

Las cuatro palancas

1. Chunked prefill — `--enable-chunked-prefill` + `--max-num-batched-tokens`

Chunked prefill parte el prefill largo en trozos (chunks) y los intercala con pasos de decode en el mismo batch. En vLLM V1 (≥ 0.6) está activo por defecto.

vllm serve mi-modelo \
 --enable-chunked-prefill \
 --max-num-batched-tokens 4096

--max-num-batched-tokens es el presupuesto total de tokens que vLLM puede procesar en un único paso del motor, sumando prefill y decode. Es el parámetro más importante para controlar el trade-off:

`max-num-batched-tokens`	Efecto
Bajo (512–2048)	Más pasos de decode por ciclo → mejor ITL, peor TTFT
Alto (8192–32768)	Chunks de prefill grandes → mejor TTFT y throughput, peor ITL

Para una RTX 4090 sirviendo modelos 7B–13B con contextos mixtos (256–4096 tokens):

--max-num-batched-tokens 8192 # punto de equilibrio razonable

Para una L40 (48 GB) con modelos más grandes y prompts más largos:

--max-num-batched-tokens 16384

Cómo funciona internamente: con un presupuesto de 4.096 tokens y un prefill de 10.000, vLLM lo parte en 3 chunks (4.096 + 4.096 + 1.808). Entre chunks, procesa los pasos de decode pendientes. Las requests en decode siguen avanzando; el prefill largo tarda más en terminar, pero no congela nada.

Sin chunked prefill:
t=0 [prefill 10k tokens]─────────────────────────────┐
t=1 └─[decode r1,r2...r9]
Con chunked prefill (budget 4096):
t=0 [prefill chunk 4096][decode r1..r9]
t=1 [prefill chunk 4096][decode r1..r9]
t=2 [prefill chunk 1808][decode r1..r9]
t=3 [decode todos, incluido el nuevo]

El TTFT del request largo aumenta ligeramente (3 pasos en vez de 1), pero el ITL de las otras 9 requests no se interrumpe.

2. Prefix caching — `--enable-prefix-caching`

Si múltiples requests comparten el mismo prefijo —un system prompt, un few-shot, un documento de contexto— vLLM puede calcular el KV cache de ese prefijo una sola vez y reutilizarlo.

vllm serve mi-modelo \
 --enable-prefix-caching

Esto se llama Automatic Prefix Caching (APC). Internamente, vLLM divide el KV cache en bloques de tamaño fijo (por defecto 16 tokens/bloque) y les asigna un hash SHA basado en el contenido. Cuando llega un request nuevo, comprueba si algún bloque inicial ya está en la caché. Si hay hit, se salta ese prefill.

El impacto numérico: supón un system prompt de 512 tokens que aparece en el 80% de tus requests, y una tasa de 100 req/min:

Sin APC: 80 req/min × 512 tokens × costo_prefill = 41.000 tokens/min de prefill redundante
Con APC (hit rate 80%): 20 req/min × 512 = 10.240 tokens/min de prefill → reducción del 75%

El TTFT de esos 80 requests cae a lo que cuesta procesar sólo el sufijo nuevo.

Limitación con chunked prefill: cuando chunked prefill está activo, sólo el primer chunk del prefill se beneficia de APC en la implementación actual de vLLM. Para workloads donde el hit de caché es muy alto y los sufijos son cortos, considera reducir --max-num-batched-tokens para que el primer chunk cubra más del prefijo compartido.

# Configuración optimizada para alto hit rate de prefix cache
vllm serve mi-modelo \
 --enable-prefix-caching \
 --enable-chunked-prefill \
 --max-num-batched-tokens 4096 # chunks más pequeños = prefijo cabe en chunk 1

3. FP8 KV cache — `--kv-cache-dtype fp8`

El KV cache ocupa VRAM. Cuanta más VRAM consume, menos requests concurrentes puedes mantener en vuelo. En una RTX 4090 de 24 GB, el modelo Qwen2.5-14B en BF16 ya ocupa ~28 GB —no cabe. En Q4 ocupa ~9 GB, dejando ~14 GB para KV cache.

¿Cuántos tokens de contexto caben en 14 GB de KV cache BF16 para un 14B con GQA?

$$\text{KV_size_por_token} = 2 \cdot n_{kv_heads} \cdot d_{head} \cdot n_{layers} \cdot 2 \text{ bytes}$$

Para Qwen2.5-14B: $n_{kv_heads}=8$, $d_{head}=128$, $n_{layers}=40$, BF16 → $2 \cdot 8 \cdot 128 \cdot 40 \cdot 2 = 163.840$ bytes ≈ 160 KB/token.

14 GB / 160 KB ≈ 87.500 tokens de contexto total. Con 8 usuarios en paralelo y 4.096 tokens de contexto cada uno: 32.768 tokens ocupados de 87.500. Hay margen, pero es finito.

Pasando a FP8 (1 byte en vez de 2):

$$\text{KV_FP8} = 80 \text{ KB/token} \implies 14 \text{ GB} / 80 \text{ KB} = 175.000 \text{ tokens}$$

El doble de capacidad de contexto con la misma VRAM. Eso permite o bien más concurrencia, o bien contextos más largos.

vllm serve mi-modelo \
 --kv-cache-dtype fp8 \
 --calculate-kv-scales # calibra las escalas dinámicamente; sin esto hay degradación

Advertencia para RTX 4090 y L40: Ada Lovelace tiene instrucciones FP8 a nivel CUDA pero sin el hardware de scaling dedicado de Hopper (H100). La reducción de memoria es real; la aceleración de cómputo es menor que en H100. No esperes el mismo speedup que en un datacenter Hopper. En L40S (la variante con tensor cores FP8 optimizados) el beneficio es mayor que en RTX 4090.

4. Presupuesto de contexto — `--max-model-len`

--max-model-len define el máximo de tokens que vLLM puede manejar en un único request (prompt + generación). Es el límite duro que determina cuánta VRAM se reserva para el KV cache en el peor caso.

En hardware pequeño, reducirlo libera VRAM para más concurrencia:

# Modelo 7B en RTX 4090, contexto típico de 4K pero el modelo soporta 128K
vllm serve mi-modelo \
 --max-model-len 8192 \  # en vez de 131072
 --gpu-memory-utilization 0.92

Con contexto recortado a 8.192 tokens, vLLM no reserva KV cache para 131.072 tokens potenciales y puede meter más requests simultáneas. El riesgo es obvio: requests que superen 8.192 tokens fallan con un error. Ajústalo al P99 de tu distribución real de longitudes.

Interacción entre parámetros

Los cuatro parámetros no son independientes. Un error común es activar prefix caching sin ajustar el tamaño de bloque, o subir max-num-batched-tokens sin revisar que max-num-seqs permita llenarlo:

max-num-batched-tokens = 8192
max-num-seqs = 4
prompt medio = 512 tokens → 4 × 512 = 2048 tokens de prefill < 8192
El presupuesto de 8192 nunca se llena porque max-num-seqs limita antes.
Solución: subir max-num-seqs o bajar max-num-batched-tokens.

Configuración equilibrada para RTX 4090 + modelo 7B:

vllm serve Qwen/Qwen2.5-7B-Instruct \
 --gpu-memory-utilization 0.92 \
 --max-model-len 8192 \
 --enable-chunked-prefill \
 --max-num-batched-tokens 8192 \
 --max-num-seqs 64 \
 --enable-prefix-caching \
 --kv-cache-dtype fp8 \
 --calculate-kv-scales

Configuración para L40 (48 GB) + modelo 14B:

vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
 --gpu-memory-utilization 0.90 \
 --max-model-len 16384 \
 --enable-chunked-prefill \
 --max-num-batched-tokens 16384 \
 --max-num-seqs 128 \
 --enable-prefix-caching \
 --kv-cache-dtype fp8 \
 --calculate-kv-scales

Cómo medir que está funcionando

Las métricas que confirman que el prefill está optimizado:

# En las métricas Prometheus de vLLM (puerto 8000/metrics):
vllm:time_to_first_token_seconds_bucket → distribución de TTFT
vllm:gpu_cache_usage_perc → utilización de KV cache
vllm:prefix_cache_hit_rate → hit rate de APC (si está activo)
vllm:num_running_seqs → requests en vuelo simultáneos

Un prefix_cache_hit_rate por debajo del 30% en workloads con system prompt fijo indica que algo en el hash no está funcionando (system prompt que varía por timestamp, formato de fecha en el prompt, etc.).

Implicaciones para inferencia on-premise

Chunked prefill y prefix caching son cero coste: se activan con flags, no requieren hardware adicional. FP8 KV cache requiere que el modelo sea compatible (casi todos los transformers modernos lo son) y que estés en Ada Lovelace o superior.

Para despliegues soberanos ENS donde el hardware es fijo y no puedes escalar horizontalmente a demanda, el prefill bien configurado es la diferencia entre necesitar 4 nodos y necesitar 2 para la misma carga.

El segundo artículo de esta serie cubre las optimizaciones del decode: speculative decoding, tuning del KV cache para maximizar concurrencia y cómo configurar gpu-memory-utilization sin que vLLM se quede sin VRAM a medianoche.

Ver también

https://blog.lo0.es/posts/kv-cache-fundamentos/ — cómo funciona el KV cache por dentro
https://blog.lo0.es/posts/flashattention-fundamentos/ — por qué FlashAttention cambia el consumo de memoria en prefill
https://blog.lo0.es/posts/continuous-batching-fundamentos/ — la base sobre la que chunked prefill construye
https://blog.lo0.es/posts/disaggregated-serving-prefill-decode/ — cuando escalar un solo nodo ya no basta
https://blog.lo0.es/posts/vllm-otel-instrumentacion-optimizaciones/ — cómo medir con Prometheus y OTel si chunked prefill y prefix caching están funcionando: ttft p99, gpu_prefix_cache_hit_rate y las alertas concretas

Referencias

Efficient Memory Management for Large Language Model Serving with PagedAttention — Kwon et al., 2023
Sarathi-Serve: Chunked Prefill and Stall-Free Scheduling — Agrawal et al., 2024
vLLM Optimization and Tuning — documentación oficial
Quantized KV Cache en vLLM

Rtx4090 on lo0 — Blog Técnico

Optimizando el decode en vLLM: exprimir cada token en hardware pequeño

TL;DR

La analogía

Por qué el decode es memory-bound

Las cinco palancas

1. Darle a vLLM toda la VRAM que puedas — --gpu-memory-utilization

2. Concurrencia real — --max-num-seqs

3. Speculative decoding — --speculative-model + --num-speculative-tokens

4. KV cache cuantizado — --kv-cache-dtype fp8

5. Eliminar el swap — --swap-space 0

La configuración de referencia por hardware

RTX 4090 (24 GB) — modelo 7B, uso interno

L40 (48 GB) — modelo 14B, multi-usuario

Cómo medir que el decode está optimizado

Implicaciones para inferencia on-premise

Ver también

Referencias

Optimizando el prefill en vLLM: los knobs que tu TTFT no perdona

TL;DR

La analogía

Qué es el prefill realmente

Por qué el prefill es un problema en hardware pequeño

Las cuatro palancas

1. Chunked prefill — --enable-chunked-prefill + --max-num-batched-tokens

2. Prefix caching — --enable-prefix-caching

3. FP8 KV cache — --kv-cache-dtype fp8

4. Presupuesto de contexto — --max-model-len

Interacción entre parámetros

Cómo medir que está funcionando

Implicaciones para inferencia on-premise

Ver también

Referencias

1. Darle a vLLM toda la VRAM que puedas — `--gpu-memory-utilization`

2. Concurrencia real — `--max-num-seqs`

3. Speculative decoding — `--speculative-model` + `--num-speculative-tokens`

4. KV cache cuantizado — `--kv-cache-dtype fp8`

5. Eliminar el swap — `--swap-space 0`

1. Chunked prefill — `--enable-chunked-prefill` + `--max-num-batched-tokens`

2. Prefix caching — `--enable-prefix-caching`

3. FP8 KV cache — `--kv-cache-dtype fp8`

4. Presupuesto de contexto — `--max-model-len`