Optimización 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

Instrumentar vLLM con OTel: medir lo que las optimizaciones realmente hacen

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

TL;DR

vLLM expone dos señales de observabilidad independientes: métricas Prometheus (pull, agregadas) y trazas OTel (push, por request). Para medir si chunked prefill, prefix caching, speculative decoding, KV cache FP8 y la concurrencia realmente están funcionando, necesitas ambas. Las métricas dicen qué está pasando en el sistema; las trazas dicen por qué un request concreto fue lento. Este artículo configura el pipeline completo y mapea cada optimización a su métrica diagnóstica.

La analogía

Un piloto de Fórmula 1 y sus ingenieros de telemetría. El piloto siente que el coche “va raro” en la curva 3, pero sin los datos de los sensores no sabe si es el neumático trasero, el diferencial o el combustible. Los ingenieros ven exactamente qué pasó en ese giro, temperatura por sensor, carga lateral por milisegundo.

vLLM sin OTel es el piloto solo: notas que el TTFT “parece alto” pero no sabes si es el prefill largo, un miss de prefix cache, o una preemption de KV cache. Con OTel tienes el cuadro completo: las métricas son el resumen de carrera (aggregated), las trazas son la telemetría vuelta a vuelta (per-request).

Arquitectura de las dos señales

vLLM separa intencionalmente sus dos canales de observabilidad:

 ┌─────────────────────────────┐
│ vLLM │
│ │
requests ────────────►│ SchedulerStats │
│ │ │
│ ├─► Prometheus /metrics │◄── scrape (pull)
│ │ (agregado, ~15s) │
│ │ │
│ └─► OTLP exporter │──► push (por request)
│ (spans, inmediato) │
└─────────────────────────────┘
│ OTLP gRPC/HTTP
▼
┌─────────────────────┐
│ OTel Collector │
│ │
│ receivers: │
│ otlp (traces) │
│ prometheus │
│ exporters: │
│ langfuse │
│ prometheus remote│
│ loki (logs) │
└─────────────────────┘

Prometheus pull expone métricas con prefijo vllm: en :8000/metrics. Son histogramas, gauges y contadores actualizados cada iteración del scheduler. Buenos para dashboards y alertas sobre el sistema completo.

OTLP push envía un span por cada request, inmediatamente al completarse. Contiene atributos del request concreto: tokens de prompt, tokens generados, TTFT, modelo. Bueno para debuggear requests anómalos y para Langfuse.

Instalación y configuración básica

# vLLM con soporte OTel
pip install "vllm[otel]"
# Instala: opentelemetry-sdk, opentelemetry-api,
# opentelemetry-exporter-otlp, opentelemetry-semantic-conventions-ai

# Arrancar vLLM con OTel habilitado
export OTEL_SERVICE_NAME="vllm-produccion"
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="http://otel-collector:4317"
export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="grpc"
export OTEL_EXPORTER_OTLP_TRACES_INSECURE="true" # en red interna sin TLS

vllm serve Qwen/Qwen2.5-7B-Instruct \
 --otlp-traces-endpoint http://otel-collector:4317 \
 --enable-chunked-prefill \
 --enable-prefix-caching \
 --kv-cache-dtype fp8 \
 --speculative-model Qwen/Qwen2.5-0.5B-Instruct \
 --num-speculative-tokens 5

Las métricas Prometheus no requieren configuración extra: siempre están en :8000/metrics.

OTel Collector: configuración mínima

# otel-collector-config.yaml
receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317
 http:
 endpoint: 0.0.0.0:4318

 prometheus:
 config:
 scrape_configs:
 - job_name: vllm
 scrape_interval: 15s
 static_configs:
 - targets: ["vllm:8000"]

processors:
 batch:
 timeout: 5s
 resource:
 attributes:
 - key: deployment.environment
 value: "produccion"
 action: upsert

exporters:
 otlphttp/langfuse:
 endpoint: "https://cloud.langfuse.com/api/public/otel"
 headers:
 Authorization: "Basic <base64(pk:sk)>"

 prometheusremotewrite:
 endpoint: "http://prometheus:9090/api/v1/write"

service:
 pipelines:
 traces:
 receivers: [otlp]
 processors: [batch, resource]
 exporters: [otlphttp/langfuse]
 metrics:
 receivers: [prometheus]
 processors: [batch]
 exporters: [prometheusremotewrite]

Las cinco métricas que importan

Cada optimización tiene una señal diagnóstica primaria. Si la métrica no se mueve como se espera después de activar el flag, hay un problema de configuración o de carga.

1. Chunked prefill → `vllm:time_to_first_token_seconds`

Chunked prefill debería reducir la varianza del TTFT, no necesariamente la mediana. Su objetivo principal es que los percentiles altos (p99) bajen aunque el p50 suba ligeramente.

# TTFT p50 y p99 — esperar que p99 baje con chunked prefill activo
histogram_quantile(0.50, rate(vllm:time_to_first_token_seconds_bucket[5m]))
histogram_quantile(0.99, rate(vllm:time_to_first_token_seconds_bucket[5m]))

Señal de que funciona: ratio p99/p50 se acerca a 1. Sin chunked prefill, un prefill largo de un request bloquea todos los demás y el p99 sube desproporcionadamente.

Señal de problema: p50 y p99 ambos suben. --max-num-batched-tokens demasiado bajo hace que los chunks sean tan pequeños que el prefill tarda muchos pasos en completarse aunque las demás requests no se bloqueen. Subir el budget.

También útil observar en las trazas OTel el atributo llm.usage.prompt_tokens por span: los requests con muchos tokens de prompt deberían tener TTFT proporcional, no bloqueante.

2. Prefix caching → `vllm:gpu_prefix_cache_hit_rate`

# Hit rate del prefix cache en GPU (0.0–1.0)
vllm:gpu_prefix_cache_hit_rate

# Evolución en ventana de 5 minutos
rate(vllm:gpu_prefix_cache_hit_rate[5m])

Señal de que funciona: hit rate sostenido > 0.5 en workloads con system prompt compartido. Con hit rate = 0.8, el 80% de los requests omite el prefill del prefijo; el TTFT de esos requests cae al coste del sufijo variable únicamente.

Señal de problema: hit rate cercano a cero pese a system prompts que “parecen” iguales. Causas habituales:

# ❌ Esto rompe el hash de prefix caching:
system_prompt = f"Hoy es {datetime.now()}. Eres un asistente..."
# ^^^ timestamp diferente en cada request

# ✅ El system prompt debe ser idéntico byte a byte:
system_prompt = "Eres un asistente especializado en infraestructura..."

Cualquier variación en el system prompt —timestamps, IDs de sesión, versiones de prompt interpoladas— produce un hash distinto y un miss de caché. Las trazas OTel no exponen directamente el hit/miss por request en la implementación actual; úsalas para correlacionar llm.usage.prompt_tokens alto con TTFT alto en el mismo request.

3. Speculative decoding → `vllm:spec_decode_draft_acceptance_rate`

# Acceptance rate del draft model (0.0–1.0)
vllm:spec_decode_draft_acceptance_rate

# Speedup efectivo estimado (con k=5 tokens propuestos)
# speedup ≈ (1 + α·k) / (1 + overhead_draft)
# Simplificado: si α=0.75 y k=5 → speedup ≈ 1 + 0.75×5×(1 - cost_ratio)

Señal de que funciona: acceptance rate > 0.70 sostenido. Por debajo de 0.60, el overhead del draft model supera la ganancia de los tokens aceptados y el speculative decoding es contraproducente.

Señal de problema: acceptance rate < 0.50. Causas habituales:

Drafter de familia distinta al verifier (p.ej., Mistral 0.5B como draft de Qwen 7B).
Temperatura de generación alta (>0.9): a mayor temperatura, más diverge la distribución del draft de la del verifier.
Batch muy grande: a alta concurrencia, el draft puede quedar fuera del dominio de los requests actuales.

# Alerta: speculative decoding ineficiente
ALERT SpecDecodeIneficiente
 IF vllm:spec_decode_draft_acceptance_rate < 0.60
 FOR 5m
 LABELS { severity = "warning" }
 ANNOTATIONS { summary = "Draft acceptance rate bajo: desactivar spec decode o cambiar drafter" }

En las trazas OTel, el span completo del request incluye el tiempo total de decode. Sin acceptance rate por span, la forma de detectar spec decode funcionando es comparar el tiempo total de decode dividido por los tokens generados: si es significativamente menor que el baseline sin spec decode, está ayudando.

4. KV cache FP8 y concurrencia → `vllm:gpu_cache_usage_perc` + `vllm:num_preemptions_total`

Estas dos métricas son las dos caras de la gestión del KV cache:

# Utilización del KV cache (0.0–1.0)
# Con FP8 activo, el mismo hardware soporta más requests antes de saturar
vllm:gpu_cache_usage_perc

# Preemptions acumuladas (contador)
# Sube cuando vLLM no puede alojar más requests y pausa alguna
rate(vllm:num_preemptions_total[5m])

Señal de que FP8 funciona: con --kv-cache-dtype fp8 activo, gpu_cache_usage_perc debería saturar a niveles de concurrencia ~2× superiores respecto al baseline BF16 antes de que num_preemptions_total empiece a crecer.

Señal de problema: num_preemptions_total crece en tasas > 1/minuto con gpu_cache_usage_perc por debajo de 0.90. Indica que max-num-seqs está demasiado alto para el KV cache disponible: las requests entran al sistema pero no hay bloques libres para asignarles. Bajar max-num-seqs o reducir max-model-len.

# Alerta: KV cache saturado con preemptions
ALERT KVCacheSaturado
 IF rate(vllm:num_preemptions_total[2m]) > 0.5
 AND vllm:gpu_cache_usage_perc > 0.85
 FOR 3m
 LABELS { severity = "critical" }
 ANNOTATIONS { summary = "KV cache saturado: bajar max-num-seqs o max-model-len" }

El impacto del FP8 en la capacidad se puede cuantificar:

$$\Delta\text{capacity} = \frac{\text{tokens_max_FP8}}{\text{tokens_max_BF16}} \approx 2\times$$

Medir antes y después de activar --kv-cache-dtype fp8: el nivel de gpu_cache_usage_perc para una concurrencia dada debería caer a la mitad.

5. Concurrencia efectiva → `vllm:num_running_seqs` + `vllm:num_waiting_seqs`

# Requests activos en el motor (decode + prefill en curso)
vllm:num_running_seqs

# Requests en cola esperando slot
vllm:num_waiting_seqs

# Ratio de espera: si > 0.2 sostenido, hay cuello de concurrencia
vllm:num_waiting_seqs / (vllm:num_running_seqs + vllm:num_waiting_seqs)

Señal saludable: num_running_seqs estable cerca del valor de --max-num-seqs configurado, num_waiting_seqs bajo (< 10% de running).

Señal de problema: num_waiting_seqs elevado con gpu_cache_usage_perc bajo. Indica que el scheduler no está llenando los slots disponibles porque max-num-batched-tokens es demasiado bajo: el budget de tokens por paso no permite procesar los prefills pendientes rápido enough. Subir max-num-batched-tokens.

Dashboard de referencia: las 5 métricas en Grafana

{
 "panels": [
 {
 "title": "TTFT p50 / p99 (chunked prefill)",
 "targets": [
 {"expr": "histogram_quantile(0.50, rate(vllm:time_to_first_token_seconds_bucket[5m]))", "legendFormat": "p50"},
 {"expr": "histogram_quantile(0.99, rate(vllm:time_to_first_token_seconds_bucket[5m]))", "legendFormat": "p99"}
 ]
 },
 {
 "title": "Prefix cache hit rate",
 "targets": [{"expr": "vllm:gpu_prefix_cache_hit_rate", "legendFormat": "GPU hit rate"}]
 },
 {
 "title": "Spec decode acceptance rate",
 "targets": [{"expr": "vllm:spec_decode_draft_acceptance_rate", "legendFormat": "acceptance rate"}]
 },
 {
 "title": "KV cache usage + preemptions",
 "targets": [
 {"expr": "vllm:gpu_cache_usage_perc", "legendFormat": "cache uso"},
 {"expr": "rate(vllm:num_preemptions_total[2m]) * 60", "legendFormat": "preemptions/min"}
 ]
 },
 {
 "title": "Concurrencia efectiva",
 "targets": [
 {"expr": "vllm:num_running_seqs", "legendFormat": "running"},
 {"expr": "vllm:num_waiting_seqs", "legendFormat": "waiting"}
 ]
 }
 ]
}

Conectar trazas a Langfuse

Las trazas OTel de vLLM son spans GenAI semconv compatibles. Langfuse los acepta directamente via OTLP:

# En el OTel Collector (ya configurado arriba)
# El exporter otlphttp/langfuse envía trazas a Langfuse Cloud o self-hosted

# Para Langfuse self-hosted (ENS/soberano):
exporters:
 otlphttp/langfuse:
 endpoint: "http://langfuse-interno:3000/api/public/otel"
 headers:
 Authorization: "Basic <base64(pk_xxx:sk_xxx)>"

En Langfuse, cada request de vLLM aparece como una traza con:

gen_ai.system: modelo servido
gen_ai.usage.input_tokens: tokens de prompt
gen_ai.usage.output_tokens: tokens generados
Duración del span: latencia end-to-end

Lo que no aparece directamente en el span: acceptance rate de speculative decoding, prefix cache hit/miss, ni número de preemptions. Esos datos sólo están en Prometheus. El workflow correcto es:

Langfuse identifica un request anómalo por latencia.
Prometheus/Grafana muestra si en ese intervalo hubo preemptions elevadas, spec decode bajo, o prefix cache miss.
Se correlacionan por timestamp.

Matriz de diagnóstico rápido

Síntoma observable	Métrica Prometheus	Causa probable	Acción
TTFT p99 muy alto	`ttft p99/p50 >> 2`	Prefills largos bloqueantes	Subir `--max-num-batched-tokens`
TTFT p50 alto, p99 idem	`ttft p50 > 500ms`	Prefix cache no funciona	Verificar hash del system prompt
Decode lento sin mejora	`spec_decode_acceptance < 0.60`	Drafter incompatible	Cambiar drafter o desactivar
OOM / crash esporádico	`gpu_cache_usage_perc = 1.0` + preemptions	KV cache lleno	Bajar `max-num-seqs` o activar FP8
Cola alta con cache libre	`waiting >> 0` + `cache < 0.70`	Budget de tokens bajo	Subir `--max-num-batched-tokens`

Implicaciones para inferencia on-premise soberana

En un despliegue ENS donde no puedes usar Langfuse Cloud ni DataDog, el stack self-hosted completo es:

# docker-compose.yml (o manifests K8s equivalentes)
services:
 otel-collector:
 image: otel/opentelemetry-collector-contrib:latest
 volumes: [./otel-config.yaml:/etc/otel/config.yaml]

 langfuse:
 image: langfuse/langfuse:latest
 environment:
 DATABASE_URL: postgres://...

 prometheus:
 image: prom/prometheus:latest

 grafana:
 image: grafana/grafana:latest

Todo el pipeline corre on-premise. Las trazas nunca salen del perímetro. El cumplimiento ENS no depende de qué observabilidad eliges: depende de que los datos de inferencia no salgan a terceros. Con stack local, ambas condiciones se cumplen.

Ver también

https://blog.lo0.es/posts/tracing-llm-otel-genai/ — los fundamentos de OTel GenAI semconv: qué son los spans, los atributos estándar y cómo fluyen desde el SDK al collector
https://blog.lo0.es/posts/prefill-optimizaciones-vllm/ — las optimizaciones de prefill que este artículo instrumenta: chunked prefill, prefix caching, FP8 KV
https://blog.lo0.es/posts/decode-optimizaciones-vllm/ — las optimizaciones de decode: speculative decoding, gpu-memory-utilization, max-num-seqs
https://blog.lo0.es/posts/anatomia-metricas-dcgm-vllm-anomalias/ — DCGM para las métricas de GPU debajo de vLLM: SM utilization, memory bandwidth, temperatura; la capa de hardware bajo las métricas de aplicación
https://blog.lo0.es/posts/observabilidad-gpu-dcgm-llm/ — cómo correlacionar métricas de GPU (DCGM) con métricas de aplicación (vLLM Prometheus) para diagnóstico completo
https://blog.lo0.es/posts/continuous-batching-fundamentos/ — el scheduler que produce las métricas de num_running_seqs y num_waiting_seqs; sin entender el scheduler, las métricas de concurrencia no tienen contexto

Referencias

Knowledge Distillation: enseñar a un modelo pequeño a pensar como uno grande

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

TL;DR

Knowledge Distillation es la técnica de entrenar un modelo pequeño (student) usando como supervisión las probabilidades de salida de un modelo grande (teacher), en vez de usando sólo las etiquetas duras del dataset de entrenamiento. El resultado es un modelo pequeño que razona mejor de lo que sugiere su tamaño, porque aprende las distribuciones de incertidumbre del teacher en vez de memorizar respuestas binarias. Es la razón por la que Phi-4 (14B) supera en razonamiento a la mayoría de modelos de 70B, y por la que los modelos de la familia Gemma 3 son sorprendentemente capaces para su tamaño. No es una técnica de compresión de modelo existente: es un proceso de entrenamiento que produce un modelo más pequeño desde cero o desde un punto de partida diferente.

La analogía

Un maestro cirujano con treinta años de experiencia y un residente de primer año. Si el residente sólo aprende del manual de anatomía —respuestas correctas binarias: “aquí se corta, aquí no”— tardará años en desarrollar el juicio clínico del maestro. Pero si opera a su lado, observando sus microdecisiones, sus dudas, los casos ambiguos donde el maestro sabe que dos opciones son casi igualmente válidas, aprende algo que el manual no puede enseñar: la estructura de la incertidumbre.

Knowledge distillation es exactamente eso. El “manual de anatomía” son las etiquetas duras (la respuesta correcta). El “maestro cirujano” es el teacher LLM. Las distribuciones de probabilidad sobre el vocabulario son la materialización de esa incertidumbre que el student absorbe.

Qué es realmente

Cuando un LLM genera texto, no produce una sola palabra: produce una distribución de probabilidad sobre todo su vocabulario en cada posición. Para el token siguiente, el modelo podría decir:

"París": 42%
"Lyon": 8%
"Marsella": 6%
"la ciudad": 5%
...resto del vocabulario: 39%

Esta distribución es información densa. Dice no sólo qué es la respuesta correcta, sino también qué otras respuestas eran plausibles y en qué medida. Un student entrenado sólo con la etiqueta “París” (probabilidad 1.0 al token correcto, 0.0 al resto) no ve esta riqueza.

Destilación usa la distribución completa del teacher como objetivo de entrenamiento del student. La función de pérdida tiene dos términos:

$$\mathcal{L}{total} = (1 - \alpha) \cdot \mathcal{L}{CE}(y, \hat{y}S) + \alpha \cdot \mathcal{L}{KD}(p_T, p_S, T)$$

Donde:

$\mathcal{L}_{CE}$ es la cross-entropy estándar con las etiquetas duras (supervisión clásica).
$\mathcal{L}_{KD}$ es la KL-divergencia entre las distribuciones del teacher y el student.
$\alpha$ controla el peso relativo de cada término (típicamente 0.5–0.9 a favor de KD).
$T$ es la temperatura, un parámetro que suaviza las distribuciones para hacer la señal de KD más informativa.

El papel de la temperatura

Si el teacher asigna 99% a “París” y 0.001% a cada otra palabra, la distribución es casi tan informativa como una etiqueta dura. La temperatura $T > 1$ suaviza esa distribución:

$$p_T(k) = \frac{\exp(z_k / T)}{\sum_j \exp(z_j / T)}$$

Con $T = 4$ y los logits originales, la distribución que antes era [99%, 0.001%, 0.001%…] pasa a ser algo como [42%, 8%, 6%…]. El student ve el vecindario de probabilidad real del teacher, no sólo su respuesta puntual.

Ejemplo numérico con temperatura:

Logits del teacher para “La capital de Francia es _____”:

París: 8.5
Lyon: 3.2
Europa: 2.1
una: 1.8

Con T=1 (softmax estándar): $$p(\text{París}) = \frac{e^{8.5}}{e^{8.5} + e^{3.2} + e^{2.1} + e^{1.8}} \approx 99.3%$$

Con T=4: $$p(\text{París}) = \frac{e^{8.5/4}}{e^{8.5/4} + e^{3.2/4} + e^{2.1/4} + e^{1.8/4}} = \frac{e^{2.125}}{e^{2.125} + e^{0.8} + e^{0.525} + e^{0.45}} \approx 54%$$

La señal con T=4 es mucho más informativa para el student: aprende que Lyon es más plausible que Europa, que Europa es más plausible que “una”, etcétera.

Los tres modos de destilación

Offline (o “black-box”)

El teacher genera un dataset sintético de respuestas antes del entrenamiento. El student se entrena sobre ese dataset como si fuera etiquetas duras normales.

teacher → genera 100M pares (prompt, completion) → dataset
student → se entrena sobre ese dataset

Es la forma más barata de escalar: el teacher se ejecuta una sola vez, el student se entrena sobre los datos generados con hardware convencional. La mayoría de los modelos de instrucción open source (Alpaca, Vicuna, WizardLM en sus primeras versiones) usaron esta estrategia: GPT-4 como teacher, datos guardados, Llama-7B como student.

Limitación: el student no ve las distribuciones de probabilidad del teacher, sólo sus respuestas. Es destilación de “comportamiento”, no de “conocimiento” en el sentido estricto. Si el teacher se equivoca (y GPT-4 se equivoca), el error queda cristalizado en el dataset.

Online (o “white-box”)

Teacher y student se ejecutan juntos durante el entrenamiento. El student procesa cada batch, el teacher procesa el mismo batch en paralelo, y la pérdida KD se calcula en tiempo real con las distribuciones de probabilidad completas.

for batch in dataset:
logits_teacher = teacher(batch) # forward pass del teacher
logits_student = student(batch) # forward pass del student
loss = KL(softmax(logits_teacher/T), softmax(logits_student/T))
loss.backward() # sólo actualiza student

El teacher tiene los gradientes desactivados (torch.no_grad()). La señal de aprendizaje es richer que en offline, pero el coste es alto: necesitas mantener el teacher en VRAM durante todo el entrenamiento. Para destilación de un teacher de 405B a un student de 8B, necesitarías varias H100 sólo para el teacher.

En-policy (on-policy)

Variante reciente (2024–2026) que combina lo mejor de ambos: el teacher genera respuestas dinámicamente durante el entrenamiento, pero el student las evalúa con su propia distribución. El ciclo es:

Student genera una propuesta de respuesta (rollout).
Teacher puntúa esa propuesta con su distribución de probabilidad.
El student actualiza con la señal del teacher.

Esto evita que el student aprenda de distribuciones fuera de su propio dominio (problema de distribution shift en offline). Es la base de algoritmos como SimCT (2026) que usan teachers de diferentes familias (Qwen, Phi, Gemma) para generar señal cross-tokenizer.

Por qué los mejores modelos pequeños usan destilación

Phi-4 (Microsoft, 14B), Gemma 3 (Google, 9B/27B), y los modelos de la familia Qwen3 compactos son los ejemplos más claros. Sus benchmarks son anómalos respecto a su tamaño: Phi-4-14B supera a LLaMA-3-70B en MATH y GPQA-Diamond, dos benchmarks de razonamiento matemático y científico donde el tamaño suele ser determinante.

¿Por qué? La clave está en qué supervisa el entrenamiento:

Un modelo entrenado con datos de internet aprende la distribución de texto humano, que incluye mucho texto de baja calidad, errores, ambigüedades.
Un student que aprende de un teacher frontier (GPT-4o, Claude 3 Opus, Gemini 1.5 Pro) absorbe una distribución filtrada hacia texto de alta calidad y razonamiento correcto.

El student con 14B parámetros no “sabe más” que uno sin destilación del mismo tamaño, pero ha aprendido a usarlos mejor porque sus gradientes de entrenamiento nunca estuvieron contaminados por texto de baja calidad.

Dato empírico: Phi-4 (14B destilado) vs LLaMA-3-70B (no destilado) en MATH benchmark (2025):

Phi-4: 80.4%
LLaMA-3-70B: 68.0%

Un modelo 5× más pequeño supera al grande porque la señal de entrenamiento es mejor, no porque tenga más parámetros.

Destilación de razonamiento: el caso de los thinking models

Los modelos de razonamiento (DeepSeek-R1, Qwen3-thinking, QwQ) generan cadenas de pensamiento internas antes de dar la respuesta final. Destilar razonamiento es más complejo porque no sólo se quiere transferir la respuesta: se quiere transferir la forma de pensar.

La estrategia actual (2025–2026) es destilación de trazas de razonamiento:

El teacher (modelo thinking grande) genera respuestas con su cadena de pensamiento interna completa.
El dataset incluye esas cadenas de pensamiento como parte del output.
El student aprende a imitar tanto la cadena como la respuesta final.

Esto explica por qué Qwen3-7B-thinking puede razonar formalmente sobre matemáticas siendo 10× más pequeño que los modelos que lo precedieron sin destilación: aprendió el proceso, no sólo el resultado.

Cuándo usar destilación vs. las alternativas

Técnica	Qué hace	Requiere reentrenamiento	Resultado
Quantización	Reduce precisión de pesos	No	Mismo modelo, más pequeño
Poda	Elimina pesos irrelevantes	No (PTQ)	Mismo modelo, más disperso
Destilación	Entrena modelo nuevo	Sí	Modelo diferente, más pequeño

La destilación no comprime un modelo existente: produce uno nuevo. Por eso es complementaria, no sustitutiva: puedes destilar un 405B a un 8B, y luego cuantizar ese 8B a INT4 para reducir su coste de inferencia.

Cuándo es la opción correcta:

Necesitas un modelo 5–10× más pequeño que el mejor disponible.
Tienes acceso (API o local) a un teacher de calidad.
Tienes datos de entrenamiento o capacidad de generarlos.
La latencia o el coste de inferencia son un constraint duro.

Cuándo no:

Quieres comprimir un modelo existente rápidamente: usa cuantización + poda.
No tienes presupuesto de entrenamiento (destilación online requiere semanas de GPU).
El teacher no es significativamente mejor que el student base: la señal de KD será débil.

Implicaciones para inferencia on-premise

En un despliegue soberano, el teacher puede ser un modelo grande que se ejecuta localmente (no es necesaria una API externa). El flujo es:

4×H100 genérico:
teacher: Llama-3.3-70B-Instruct (en los 4×H100, carga completa)
→ genera dataset de 10M pares (prompt, completion con logits)
→ 3-4 semanas de generación a batch 32
Después del dataset:
student: Qwen2.5-7B (fine-tuned con KD loss sobre el dataset)
→ 2-3 días de entrenamiento en los mismos H100
→ resultado: 7B que razona como el 70B en el dominio específico
Producción:
RTX 4090: sirve el student 7B cuantizado a INT4 (4 GB)

El teacher sólo se necesita para generar los datos. El student es lo que va a producción. La inversión en cómputo de entrenamiento se amortiza en meses de inferencia más barata.

Para ENS/NIS2: este flujo es 100% on-premise, cero dependencia de APIs externas, y el modelo resultante es tuyo en todos los sentidos.

Ver también

https://blog.lo0.es/posts/poda-pruning-llm-fundamentos/ — alternativa técnica: en vez de entrenar un modelo nuevo, eliminar partes del modelo existente; destilación y poda son complementarias
https://blog.lo0.es/posts/quantization-fundamentos-inferencia/ — el paso siguiente después de destilar: cuantizar el student para inferencia eficiente
https://blog.lo0.es/posts/speculative-decoding-fundamentos/ — los drafters de speculative decoding son frecuentemente students destilados del model base que aprenden a predecir su distribución
https://blog.lo0.es/posts/fine-tuning-continuo-produccion/ — destilación como forma de fine-tuning continuo: el teacher es el modelo en producción, el student es la siguiente versión
https://blog.lo0.es/posts/alignment-moderno-dpo-kto-orpo-simpo/ — DPO y sus variantes pueden verse como destilación de preferencias humanas hacia el modelo; la matemática de la distribución de referencia es análoga al teacher en KD

Referencias

Distilling the Knowledge in a Neural Network — Hinton, Vinyals & Dean, 2015 (paper fundacional)
Phi-4 Technical Report — Microsoft Research, 2024
DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning — DeepSeek, 2025 (destilación de razonamiento)
Awesome LLM On-Policy Distillation — colección de papers de destilación en-policy, 2025–2026
Knowledge Distillation for LLMs: Survey — ICLR 2025

Poda de modelos LLM: eliminar sin amputar

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

TL;DR

Un modelo de 7B parámetros tiene decenas de miles de millones de conexiones neuronales. Muchas de ellas contribuyen tan poco que podrías eliminarlas sin que ningún benchmark razonable lo notase. Eso es la poda (pruning): identificar los pesos irrelevantes y suprimirlos para obtener un modelo más pequeño, más rápido o que consuma menos memoria. Las técnicas modernas (SparseGPT, Wanda, 2:4 structured sparsity) hacen esto sin reentrenamiento, en pocas horas de GPU, y con menos de 1 punto de perplexity de penalización. No reemplaza a la cuantización, se combina con ella.

La analogía

Un árbol de roble con cien ramas. Cuando llega el invierno, el árbol poda sus ramas débiles: redirige los recursos hacia los troncos principales. Un podador experto no corta al azar, observa cuáles ramas tienen poco follaje, cuáles están secas, cuáles crecen en dirección equivocada, y corta sólo esas.

Un modelo de lenguaje es ese árbol. Sus “ramas” son los pesos que conectan neuronas. Después del entrenamiento, muchas de esas conexiones son vestigios del proceso de optimización: existían para que el gradiente descendiera con suavidad, pero en producción apenas modifican la salida. El podador que las elimina con precisión es SparseGPT o Wanda. El que corta al azar es magnitude pruning sin calibración. Ambos dan un árbol más pequeño; sólo el experto da uno que sigue produciendo el mismo fruto.

Qué es la poda realmente

Un modelo de lenguaje transformer almacena su conocimiento en matrices de pesos. Una capa de atención tiene cuatro matrices: $W_Q, W_K, W_V, W_O$. Una capa FFN tiene al menos dos ($W_{up}, W_{down}$, más $W_{gate}$ en SwiGLU). Para un modelo de 7B con 32 capas, el número de parámetros individuales supera los 7.000 millones.

Poda es el proceso de fijar a cero un subconjunto de esos parámetros de forma que:

El modelo resultante ocupe menos memoria (si se almacena en formato disperso) o compute menos operaciones.
La calidad de las respuestas no caiga de forma apreciable.

Hay dos dimensiones de clasificación que importan:

Granularidad: qué unidad se elimina.

Poda no estructurada: pesos individuales, dispersos por toda la matriz. Alta compresión, difícil de acelerar en hardware convencional.
Poda estructurada: cabezas de atención completas, neuronas FFN enteras, o capas completas. Menor compresión, pero el modelo resultante es denso y compatible con cualquier hardware.
Semi-estructurada N:M: para cada grupo de M pesos consecutivos, exactamente N son cero. El caso 2:4 (2 zeros de cada 4) es el que soportan los Tensor Cores de NVIDIA Ampere y posteriores.

Momento: cuándo se elimina.

Post-entrenamiento (PTQ de pesos): no requiere gradient, es el estándar en LLMs grandes.
Durante entrenamiento (gradual/iterativa): más precisa, incompatible con modelos de 70B+ por coste.

Por qué existen tantos pesos redundantes

La respuesta está en cómo se entrenan los modelos. El descenso de gradiente estocástico con millones de pasos y learning rate decreciente produce redes sobre-parametrizadas por diseño: los parámetros extra no representan conocimiento adicional, sino margen de maniobra para que la optimización converja más fácilmente.

La Hipótesis del Ticket de Lotería (Frankle & Carlin, ICLR 2019) formalizó esta intuición: dentro de cualquier red densa entrenada existe una subred que, entrenada desde cero en aislamiento, alcanza la misma calidad. La red original es esa subred envuelta en ruido paramétrico generado por el proceso de entrenamiento.

Para LLMs, la evidencia empírica es consistente: modelos de 7B–70B toleran hasta el 50% de sparsidad no estructurada sin degradación observable en tareas conversacionales. En modelos más grandes, el umbral de tolerancia aumenta.

Las matemáticas que importan

¿Qué pesos son seguros eliminar?

Magnitude pruning: el criterio ingenuo

$$\text{importance}(w_{ij}) = |w_{ij}|$$

Se eliminan los pesos con menor valor absoluto. Intuitivo, pero incompleto: un peso pequeño conectado a una activación muy grande sigue contribuyendo significativamente a la salida.

Wanda: magnitud × activación

$$\text{importance}(w_{ij}) = |w_{ij}| \cdot |x_j|_2$$

Donde $x_j$ es el vector de activación de entrada correspondiente al peso $j$, calculado sobre un dataset de calibración de ~128 samples. El producto captura ambas dimensiones: un peso es seguro eliminar sólo si él es pequeño y su neurona de entrada está poco activa.

Ejemplo numérico:

Peso A: $|w| = 0.001$, $|x|_2 = 500$ → importancia = 0.5
Peso B: $|w| = 0.01$, $|x|_2 = 10$ → importancia = 0.1

Magnitude pruning eliminaría A (valor absoluto menor). Wanda elimina B (importancia menor). B es más seguro suprimir.

Wanda no requiere gradientes ni inversas de matriz hessiana. Corre en minutos sobre un modelo de 70B en una sola GPU. En benchmarks de perplexity WikiText-2 con 50% de sparsidad no estructurada, Wanda alcanza resultados comparables a SparseGPT con 10–100× menos coste computacional.

SparseGPT: compensación hessiana

SparseGPT aplica el mismo marco matemático que GPTQ (cuantización capa a capa), pero para poda. Cuando elimina un peso $w_p$, calcula una corrección $\delta w$ sobre los pesos restantes de la misma fila para minimizar el cambio en la salida de la capa:

$$\min_{\delta w} |W x - (W + \delta W) x|_2^2 \quad \text{s.t.} \quad w_p + \delta w_p = 0$$

La solución usa la inversa de la matriz Hessiana de segundo orden $H = X X^T$. El coste extra justifica la mayor precisión cuando la sparsidad objetivo es alta (>70%) o el modelo es pequeño (<7B, donde la redundancia es menor).

Método	Criterio	Coste	Sparsidad 50% (7B, ppl WikiText-2)
Magnitude	\|w\|	Instantáneo	+2–5 puntos
Wanda	\|w\| · \|x\|	Minutos	~+0.5 puntos
SparseGPT	Hessiana	1–4h GPU	~+0.4 puntos

2:4 Structured Sparsity: el caso especial de NVIDIA

NVIDIA Ampere (A100) y posteriores (H100, Ada Lovelace) incluyen hardware dedicado para el patrón 2:4: exactamente 2 de cada 4 pesos consecutivos son cero. Esto permite al hardware omitir las multiplicaciones por cero de forma eficiente, obteniendo hasta 2× speedup en matmul sobre modelos con pesos 2:4.

La restricción es que la sparsidad tiene que ser exactamente 2:4, no un patrón arbitrario. Las herramientas NVIDIA (APEX Sparse, cuSPARSELt) y frameworks como PyTorch 2.x soportan esto nativamente:

from torch.sparse import to_sparse_semi_structured, SparseSemiStructuredTensor

# Convertir pesos densos a 2:4 sparse
sparse_weight = to_sparse_semi_structured(dense_weight)
# Forward pass automáticamente usa sparse tensor cores
output = F.linear(input, sparse_weight)

Qué esperar en la práctica con 2:4:

RTX 4090 (Ada Lovelace): soporta 2:4 sparse tensor cores para FP16/BF16. Speedup teórico 2×, real 1.3–1.6× dependiendo del tamaño de batch y secuencia.
H100 (Hopper): ídem con mejoras adicionales en FP8 + 2:4 combinados.
A100: soportado, sin FP8.
GPUs consumer anteriores a Ada (3090, etc.): sin soporte de hardware. 2:4 sparsity da un modelo más pequeño en disco pero no acelera la inferencia.

Poda estructurada: eliminar cabezas y capas enteras

Poda de cabezas de atención

Un transformer de 32 capas con 32 cabezas por capa tiene 1.024 cabezas de atención. Estudios sistemáticos en modelos Llama-2 y Qwen muestran que entre el 20–40% de las cabezas tienen una influencia marginal en la salida final: su salida puede fijarse a cero sin que el benchmark cambie dentro del margen de error.

La métrica más usada es la Taylor importance: el producto del gradiente de la pérdida respecto a la salida de la cabeza por el valor de esa salida, sumado sobre un dataset de calibración:

$$\text{I}_{head} = \left| \sum_t \frac{\partial \mathcal{L}}{\partial o_t} \cdot o_t \right|$$

Las cabezas con $I_{head}$ más bajo se eliminan primero. Después de eliminar el 25% de cabezas en Llama-3-8B, la degradación en MMLU es <1% y el tiempo de inferencia de la atención cae ~20% porque los matmuls de atención son más pequeños.

Layer dropping: el atajo más agresivo

Eliminar una capa transformer completa suprime su bloque de atención y su FFN. El criterio más robusto es la Block Influence (BI), introducida en ShortGPT (2024):

$$\text{BI}(l) = 1 - \cos(\text{input}_l, \text{output}_l)$$

Una capa cuya salida es casi idéntica a su entrada (coseno próximo a 1, BI próximo a 0) actúa como función identidad: eliminarla no cambia el flujo de información. Las capas del centro del transformer suelen tener BI más bajo que las capas iniciales y finales.

Ejemplo numérico en LLaMA-2-70B:

Capas 0–5 (early): BI > 0.3 → no eliminar
Capas 20–45 (mid): BI < 0.05 → candidatas a eliminar
Capas 76–80 (final): BI > 0.2 → no eliminar

Eliminando 8 capas de 80 (10%): el modelo pasa de ~140 GB a ~126 GB en BF16. Speedup de inferencia: ~10% (proporcional al número de capas eliminadas). Degradación en benchmarks de razonamiento: 1–3%.

Implicaciones para inferencia on-premise

La poda no estructurada (50% sparsidad) produce modelos con el mismo número de parámetros pero con la mitad a cero. Sin kernels sparse especializados, eso no da speedup: la GPU sigue ejecutando las multiplicaciones, sólo que multiplica por cero muy eficientemente. El beneficio real es de almacenamiento y transferencia (el modelo ocupa menos en disco y en RAM de sistema).

Con 2:4 structured sparsity sobre hardware Ada/Hopper, el speedup es real pero moderado (1.3–1.7×) y requiere herramientas adicionales (cuSPARSELt o PyTorch sparse).

La poda estructurada (cabezas, capas) sí acelera en cualquier hardware porque reduce el tamaño real del modelo. Es la opción correcta si el objetivo es throughput en hardware sin tensor cores sparse.

Combinación con cuantización: poda + cuantización son ortogonales. Un modelo 50% sparse a INT4 ocupa aproximadamente un octavo del original en FP32. Es el punto de llegada de muchos pipelines de compresión agresiva para edge inference.

Aplicado a hardware on-premise genérico

RTX 4090 (24 GB, Ada Lovelace)

Soporta 2:4 sparse tensor cores para FP16/BF16. Con Wanda + 2:4 sparsity sobre un Qwen2.5-14B:

# Pipeline de poda: Wanda 2:4 + quantización INT4
# 1. Ejecutar Wanda con calibración sobre 128 muestras
python wanda/main.py \
 --model Qwen/Qwen2.5-14B \
 --sparsity_ratio 0.5 \
 --sparsity_type 2:4 \
 --save pruned_model/

# 2. Cuantizar el modelo podado (opcional pero complementario)
python -m awq.entry --model_path pruned_model/ \
 --w_bit 4 --output_path pruned_awq_model/

Resultado esperado: ~13 GB BF16 → ~6.5 GB tras poda 2:4 en sparse format → ~3.2 GB con AWQ INT4. El modelo 14B cabrá en la RTX 4090 con margen para KV cache.

4× H100 SXM (320 GB total, Hopper)

En este hardware la poda estructurada (layer dropping) tiene más sentido que 2:4 para inferencia de alta concurrencia: reduces el número de operaciones FLOPs por token de forma proporcional, lo que beneficia al throughput bajo batch grande donde el cuello es compute, no memoria.

# Aplicar layer dropping con ShortGPT BI metric
from shortgpt import compute_block_influence, drop_layers

bi_scores = compute_block_influence(model, calibration_data)
# Eliminar el 15% de capas con BI más bajo
model = drop_layers(model, bi_scores, drop_ratio=0.15)

Un Llama-3-70B podado al 15% de capas cabe en 3 H100 en vez de 4, liberando una GPU para otra tarea.

Ver también

https://blog.lo0.es/posts/quantization-fundamentos-inferencia/ — la palanca complementaria: cuantizar reduce la precisión de los pesos que la poda ha decidido conservar; combinadas dan compresión máxima
https://blog.lo0.es/posts/kv-cache-fundamentos/ — la poda reduce el tamaño del modelo, pero el KV cache sigue creciendo con el contexto; son costes separados en VRAM
https://blog.lo0.es/posts/speculative-decoding-fundamentos/ — los drafters de speculative decoding son a menudo versiones podadas del modelo base, no modelos entrenados desde cero
https://blog.lo0.es/posts/decode-optimizaciones-vllm/ — cómo el modelo podado se sirve en vLLM: los parámetros de throughput cambian con un modelo estructuralmente más pequeño
https://blog.lo0.es/posts/knowledge-distillation-fundamentos/ — alternativa conceptual a la poda: en vez de eliminar partes del modelo grande, entrenar uno pequeño para que imite su comportamiento

Referencias

SparseGPT: Massive Language Models Can be Accurately Pruned in One Shot — Frantar & Alistarh, 2023
A Simple and Effective Pruning Approach for Large Language Models (Wanda) — Sun et al., ICLR 2024
The Lottery Ticket Hypothesis — Frankle & Carlin, ICLR 2019
ShortGPT: Layers in Large Language Models are More Redundant Than You Expect — Men et al., 2024
NVIDIA 2:4 Sparsity in PyTorch — PyTorch Blog
SparseForge: Efficient Semi-Structured LLM Sparsification — 2025

Optimización 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

Instrumentar vLLM con OTel: medir lo que las optimizaciones realmente hacen

TL;DR

La analogía

Arquitectura de las dos señales

Instalación y configuración básica

OTel Collector: configuración mínima

Las cinco métricas que importan

1. Chunked prefill → vllm:time_to_first_token_seconds

2. Prefix caching → vllm:gpu_prefix_cache_hit_rate

3. Speculative decoding → vllm:spec_decode_draft_acceptance_rate

4. KV cache FP8 y concurrencia → vllm:gpu_cache_usage_perc + vllm:num_preemptions_total

5. Concurrencia efectiva → vllm:num_running_seqs + vllm:num_waiting_seqs

Dashboard de referencia: las 5 métricas en Grafana

Conectar trazas a Langfuse

Matriz de diagnóstico rápido

Implicaciones para inferencia on-premise soberana

Ver también

Referencias

Knowledge Distillation: enseñar a un modelo pequeño a pensar como uno grande

TL;DR

La analogía

Qué es realmente

El papel de la temperatura

Los tres modos de destilación

Offline (o “black-box”)

Online (o “white-box”)

En-policy (on-policy)

Por qué los mejores modelos pequeños usan destilación

Destilación de razonamiento: el caso de los thinking models

Cuándo usar destilación vs. las alternativas

Implicaciones para inferencia on-premise

Ver también

Referencias

Poda de modelos LLM: eliminar sin amputar

TL;DR

La analogía

Qué es la poda realmente

Por qué existen tantos pesos redundantes

Las matemáticas que importan

¿Qué pesos son seguros eliminar?

Magnitude pruning: el criterio ingenuo

Wanda: magnitud × activación

SparseGPT: compensación hessiana

2:4 Structured Sparsity: el caso especial de NVIDIA

Poda estructurada: eliminar cabezas y capas enteras

Poda de cabezas de atención

Layer dropping: el atajo más agresivo

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`

1. Chunked prefill → `vllm:time_to_first_token_seconds`

2. Prefix caching → `vllm:gpu_prefix_cache_hit_rate`

3. Speculative decoding → `vllm:spec_decode_draft_acceptance_rate`

4. KV cache FP8 y concurrencia → `vllm:gpu_cache_usage_perc` + `vllm:num_preemptions_total`

5. Concurrencia efectiva → `vllm:num_running_seqs` + `vllm:num_waiting_seqs`