La despensa por casilleros: PagedAttention y el block manager de vLLM

Mon, 08 Jun 2026 05:20:00 +0200

Sigue la serie por debajo del motor. El post del scheduler terminó con un cabo suelto: el scheduler tiene un segundo presupuesto, los bloques de KV, y cuando se agotan, preempta. Este post abre ese presupuesto. Es la pieza que el post de KV cache daba por buena —qué se guarda— para explicar cómo se gestiona en memoria. Y es el que el post de FlashAttention llevaba meses prometiendo.

TL;DR

El KV cache crece un poco con cada token generado, y el problema nunca fue su tamaño total sino la forma de reservarlo. Los primeros servidores pedían, por petición, un trozo contiguo de HBM del tamaño del contexto máximo posible. Como casi ninguna petición llega a ese máximo, el resultado era catastrófico: 60-80% de la HBM desperdiciada en fragmentación. PagedAttention aplica al KV la idea más vieja y probada de los sistemas operativos —la paginación—: partir el KV en bloques de tamaño fijo (16 tokens por defecto), guardarlos en HBM no contigua donde haya hueco, y mantener una block table que traduce el bloque lógico de cada secuencia a su bloque físico. El desperdicio cae a ~4% (solo el último bloque, a medio llenar). Y como cada bloque se puede identificar por el hash de su contenido, dos peticiones que comparten un prefijo apuntan al mismo bloque físico y comparten memoria —con copy-on-write cuando una diverge—: ese es el motor del prefix caching. Este post explica la fragmentación con números, el block manager, el block table, el COW, el compromiso del tamaño de bloque, los 10 knobs y la trampa de confundir “fragmentación resuelta” con “cero desperdicio”. Sobre el cluster genérico 4×H100 SXM.

Dónde estás: la despensa, debajo del scheduler

Vuelve a la cocina del post anterior. El jefe de sala arma bandejas, pero detrás hay una despensa donde se guardan los ingredientes que cada mesa va acumulando a lo largo de su comida —su KV cache—. La pregunta de este post es cómo está organizada esa despensa.

La forma ingenua: a cada mesa se le asigna una estantería entera y contigua, dimensionada para el cliente más glotón imaginable. El problema salta a la vista: una mesa que pide poco deja casi toda su estantería vacía, pero esa estantería ya está reservada y nadie más puede usarla. Con muchas mesas, la despensa se llena de estanterías medio vacías y no caben mesas nuevas, aunque sumando huecos sobre sitio de sobra.

La forma de PagedAttention: la despensa se divide en casilleros pequeños e idénticos. A cada mesa se le dan los casilleros que va necesitando, uno a uno, donde haya hueco —no tienen que estar juntos—. Un libro de mapas anota qué casilleros físicos tiene cada mesa y en qué orden. Cuando una mesa se va, sus casilleros vuelven al montón. No hay estanterías medio vacías: solo se desperdicia el último casillero de cada mesa, el que está a medio llenar. Eso es, casi literalmente, la memoria virtual de un sistema operativo aplicada al KV cache.

Por qué la memoria contigua fragmentaba

Reservar contiguo y por adelantado produce tres desperdicios distintos:

Fragmentación de reserva. Apartas espacio para max_model_len (p. ej. 8192 tokens) aunque la petición vaya a usar 800. Reservado y nunca usado.
Fragmentación interna. Dentro de lo reservado, lo que queda por encima de lo que de verdad usas en cada momento.
Fragmentación externa. Huecos entre reservas contiguas demasiado pequeños para una petición nueva, aunque sumados sobren.

El paper original de vLLM medía que los sistemas previos desperdiciaban del 60% al 80% de la memoria de KV por estas tres vías (Kwon et al., SOSP 2023). Es decir: en una GPU con sitio para 100 peticiones reales, solo cabían 20-40. La paginación ataca las tres a la vez —elimina la reserva (asignación on-demand) y la externa (los bloques no necesitan ser contiguos), y deja solo un resto de la interna: el último bloque parcial.

El mecanismo: bloques, block table y el gather del kernel

El KV de una secuencia se trocea en bloques lógicos de $b$ tokens (por defecto $b = 16$). Cada bloque lógico se mapea, vía la block table, a un bloque físico en algún punto de la HBM. La block table es el “libro de mapas”: una lista, por petición, de qué físico corresponde a cada lógico (implementación vLLM).

La clave es que el kernel de atención sabe leer así. En lugar de asumir un tensor de KV contiguo, el kernel de PagedAttention recibe la block table y hace un gather: para cada secuencia, recorre sus bloques físicos en el orden lógico y lee K y V como si estuvieran juntos. Por eso PagedAttention no es solo una estructura de datos: es un kernel que sabe atender sobre memoria paginada. Y por eso el backend de atención y el block manager están atados —el segundo decide dónde vive el KV, el primero sabe leerlo de ahí.

El block manager: el bibliotecario de la despensa

El block manager (en V1, el KVCacheManager) es quien lleva el libro de mapas. Sus responsabilidades:

Mantener un pool de bloques físicos libres (una cola de bloques disponibles).
Asignar bloques a una secuencia cuando crece (un bloque nuevo cada $b$ tokens).
Liberar los bloques cuando la secuencia termina o es preemptada.
Mantener las block tables (logical→physical) de cada petición.
Gestionar el prefix caching: detectar bloques con contenido idéntico y compartirlos.
Cuando se acaban los bloques libres, avisar al scheduler para que preempte (ver el post del scheduler).

Cuando el block manager dice “no quedan bloques”, el scheduler tiene que bajar a alguien del tren. Por eso los dos presupuestos —tokens y bloques— son las dos manos del mismo motor.

Prefix caching: compartir casilleros con copy-on-write

Aquí está la parte elegante. Si dos peticiones empiezan con el mismo prefijo —el mismo system prompt, el mismo documento de contexto—, los primeros bloques de KV de ambas son idénticos byte a byte. ¿Por qué calcularlos y guardarlos dos veces?

vLLM le pone a cada bloque un hash que resume su contenido (los tokens que lo formaron, más el hash del bloque anterior, para que el hash capture la posición). Mantiene una tabla global de bloques por hash. Cuando una petición nueva produce un bloque cuyo hash ya existe, no asigna memoria nueva: apunta su block table al bloque físico que ya estaba (automatic prefix caching, vLLM).

El copy-on-write es la salvaguarda: mientras A y B comparten un bloque, ninguna lo puede modificar. En el momento en que una de las dos necesita escribir algo distinto en ese bloque (porque sus secuencias divergen, o en parallel sampling / beam search donde varias ramas comparten prefijo), el block manager copia el bloque para esa rama y solo entonces escribe (details, vLLM). Es el mismo COW que usa fork() en un SO: compartir hasta que alguien escriba.

El ahorro es directo: si 50 peticiones comparten un system prompt de 1000 tokens, en lugar de 50 copias del KV de ese prefijo hay una. Cómo maximizar ese ahorro en la práctica es el tema del post de prefix cache hit rate.

Las matemáticas que importan: cuánto KV, cuántos bloques

Bytes de KV por token. Para un bloque transformer con $L$ capas, $h_{kv}$ cabezas de KV (GQA), dimensión por cabeza $d$ y $s$ bytes por elemento (2 en FP16):

$$\text{KV/token} = 2 \cdot L \cdot h_{kv} \cdot d \cdot s$$

Para un Llama-70B ($L=80$, $h_{kv}=8$, $d=128$, FP16):

$$\text{KV/token} = 2 \cdot 80 \cdot 8 \cdot 128 \cdot 2 = 327680 \text{ bytes} \approx 320 \text{ KB}$$

Un bloque de 16 tokens ocupa $16 \times 320,\text{KB} = 5,12$ MB.

Cuántas peticiones caben. Si tras cargar los pesos quedan ~120 GB de los 320 del nodo para KV:

$$\text{tokens de KV} = \frac{120 \cdot 10^9}{327680} \approx 366000 \text{ tokens} \approx 22900 \text{ bloques}$$

Con contextos medios de 4000 tokens (250 bloques cada uno), eso son ~90 peticiones concurrentes. Ese número —no max_num_seqs— es el techo real de concurrencia, y es exactamente el “presupuesto de bloques” del scheduler.

El desperdicio que queda. PagedAttention no llega a cero: cada secuencia desperdicia, de media, medio bloque (el último, a medio llenar). Con bloques de 16 tokens y secuencias de 4000, eso es $8 / 4000 = 0,2%$ por secuencia —el famoso “~4%” agregado del paper incluye otros overheads—. La lección: el desperdicio no desaparece, se acota al tamaño de un bloque.

El compromiso del tamaño de bloque

El block_size (16 por defecto) es un compromiso, no una constante mágica:

Bloque	Ventaja	Inconveniente
Pequeño (8)	menos desperdicio interno; sharing de prefijo más fino	más entradas de block table; más overhead de gestión y de gather
Grande (32)	menos metadatos; gather más eficiente	más desperdicio en el último bloque; el prefix caching comparte con grano más grueso (menos hits)

Un bloque grande comparte peor: el prefix caching solo puede reutilizar bloques completos e idénticos, así que con bloques de 32 dos prompts que coinciden en 20 tokens no comparten nada (no llenan un bloque común), mientras que con bloques de 8 comparten dos bloques. El 16 por defecto es el punto que vLLM encontró razonable para la mayoría de cargas; merece la pena probarlo si tu carga tiene prefijos cortos muy repetidos.

Los 10 knobs

#	Knob	Qué controla	Coste si te pasas
1	`block_size`	tokens por bloque	desperdicio / overhead (ver tabla)
2	`enable_prefix_caching`	compartir bloques por hash	casi ninguno; suele ir on
3	`gpu_memory_utilization`	cuántos bloques físicos hay	OOM si demasiado alto
4	`kv_cache_dtype` (FP8)	bytes por elemento de KV	calidad (medir, no asumir)
5	`swap_space`	bloques que caben en host (SWAP)	tráfico PCIe en preemption
6	`max_model_len`	longitud máxima por petición	menos peticiones si muy alto
7	política de evicción	a quién se le quitan bloques	hit rate de prefix cache
8	sliding window	descartar KV viejo	calidad en contextos largos
9	TP / sharding del KV	reparto del KV entre GPUs	tráfico NVLink
10	num_gpu_blocks (override)	forzar el conteo de bloques	OOM o infrautilización

Cómo se conecta con el resto del stack

Con el scheduler. El “presupuesto de bloques” del scheduler lo administra este block manager. Cuando dice que no hay bloques, el scheduler preempta (RECOMPUTE por defecto).

Con el KV cache. El post de KV cache explica qué guarda cada token; este, cómo se coloca en memoria sin fragmentar.

Con el prefix caching. El COW y los hashes de bloque son el mecanismo; el hit rate engineering es cómo exprimirlo (estructura de prompts, routing prefix-aware).

Con la cuantización del KV. Pasar el KV a FP8 parte por la mitad los bytes/token: el mismo nodo cabe el doble de tokens. Es la palanca más directa sobre la concurrencia.

Con el backend de atención. El kernel de FlashAttention/FlashInfer tiene que saber atender sobre bloques paginados; el block manager decide dónde viven, el kernel sabe leerlos.

Con el disaggregated serving. Mover una petición de un pool de prefill a uno de decode en serving desagregado es, en el fondo, transferir sus bloques de KV entre motores —por NVLink o red—.

Con multi-LoRA. En multi-LoRA serving, la base comparte KV de prefijo entre peticiones de distintos adapters siempre que el prefijo sea idéntico.

Trampas y cosas que no son lo que parecen

“PagedAttention elimina el desperdicio.” Lo acota, no lo elimina. Queda el último bloque parcial por secuencia (~medio bloque) más los metadatos del block table. Es ~4% en vez de 60-80%, pero no es cero. Dimensionar como si fuera cero te deja sin colchón.

“Bloques más grandes siempre rinden mejor.” El gather es algo más eficiente, sí, pero pierdes granularidad de sharing: el prefix caching comparte peor y el desperdicio del último bloque crece. En cargas con muchos prefijos cortos repetidos, bloques pequeños pueden ganar.

“El prefix caching comparte KV entre usuarios, eso es un problema de privacidad.” Comparte solo bloques idénticos token a token (mismo system prompt, mismo documento). No expone el contenido de un usuario a otro: si los tokens no coinciden, no hay bloque común. Lo que sí conviene vigilar es la información por canales laterales de tiempo (un hit es más rápido que un miss), relevante solo en escenarios multi-tenant muy adversariales.

“FP8 en el KV es gratis: el doble de concurrencia.” Dobla los tokens que caben, sí, pero el KV en FP8 degrada la calidad de forma medible en contextos largos. Es una palanca real, no un almuerzo gratis: hay que medir la calidad (FP8 end-to-end), no asumirla.

“Volver a memoria contigua sería más simple y casi igual de bueno.” Es la nostalgia del tensor contiguo. Lo “simple” reintroduce el 60-80% de fragmentación: en una GPU, eso es la diferencia entre 30 y 90 peticiones concurrentes. La complejidad del block table se paga con creces.

SWAP frente a RECOMPUTE al preemptar. Configurar mucho swap_space “para no perder KV” mete transferencias de gigabytes por el PCIe en el camino crítico. En V1, RECOMPUTE suele ser mejor; el swap es para casos concretos.

Conclusión

El cuello de botella de servir un LLM nunca fue solo cuánta memoria tienes, sino cómo la repartes. Los primeros servidores trataban el KV cache como una estantería contigua por cliente y tiraban dos tercios de la HBM a la basura sin que apareciera en ningún dashboard. PagedAttention le robó al sistema operativo su mejor idea de hace cincuenta años —paginar— y la aplicó al sitio exacto donde dolía: casilleros pequeños, un libro de mapas, asignación bajo demanda y, de regalo, la posibilidad de que dos peticiones que empiezan igual compartan los mismos casilleros hasta que dejen de parecerse. El resultado no es magia: el desperdicio sigue ahí, pero acotado al tamaño de un bloque en vez de al tamaño del peor caso imaginable. Y esa diferencia —del 70% al 4%— es la que convirtió una GPU que servía a treinta clientes en una que sirve a noventa, sin tocar el hardware. La despensa no se hizo más grande; se organizó mejor.

Ver también

El pase: el scheduler step de vLLM — el presupuesto de bloques que este block manager administra; cuando se agota, preemption.
KV cache: la memoria de trabajo — qué guarda cada token, el dato que aquí se pagina.
Prefix cache hit rate engineering — cómo exprimir el sharing de bloques que el COW hace posible.
FlashAttention v1/v2/v3/v4 — el kernel que sabe atender sobre KV paginado.
FP8 end-to-end: pesos y KV — partir por la mitad los bytes/token y doblar la concurrencia, midiendo la calidad.
Disaggregated serving: prefill y decode separados — mover una petición entre pools es transferir sus bloques de KV.
PCIe, GPUDirect P2P y ACS — por dónde viajan los bloques cuando se hace SWAP o se mueve KV entre GPUs.
Multi-LoRA serving — compartir prefijo entre peticiones de distintos adapters.

Referencias

W. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023): https://arxiv.org/pdf/2309.06180.
vLLM, Automatic Prefix Caching (diseño, hashing de bloques): https://docs.vllm.ai/en/v0.8.1/design/automatic_prefix_caching.html.
vLLM, Automatic Prefix Caching — Implementation (block table, COW): https://docs.vllm.ai/en/v0.6.1/automatic_prefix_caching/details.html.
H. Elshafie, Paged Attention from First Principles: A View Inside vLLM: https://hamzaelshafie.bearblog.dev/paged-attention-from-first-principles-a-view-inside-vllm/.
vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention (alternativa, contexto crítico): https://arxiv.org/pdf/2405.04437.

Block-Manager on lo0 — Blog Técnico