48 KB por token: por qué 48 GB no aguantan 30 sesiones
La pregunta era: ¿cuántas personas caben en una GPU de 48 GB? Y la respuesta no la decide la potencia de la tarjeta, ni los 30B del modelo, ni el batching. La decide una multiplicación que casi nadie hace antes de comprar: cuántos bytes ocupa cada token en la caché KV.
Con la cuenta hecha, una L40S de 48 GB aguanta alrededor de 175.000 tokens vivos. Treinta sesiones de 16K necesitan 480.000. No caben. Y ahí se acabó la discusión de "¿compro una o dos GPUs?".
La cuenta (FP8, capa por capa)
KV por token = 2 (K y V) × 48 capas × 4 KV heads × 128 dim × 1 byte
= 49.152 bytes ≈ 48 KB por token- 2: se guardan dos tensores por capa, clave y valor.
- 48 capas: del modelo (Qwen3-Coder-30B).
- 4 KV heads × 128 dim: la geometría de atención (GQA).
- 1 byte: porque la caché KV está en FP8. En FP16 serían 96 KB/token.
Con 8 GB disponibles para caché (de los 48 GB, el resto son pesos y overhead), la capacidad es:
8 GB ÷ 48 KB/token ≈ 175.000 tokensLa consecuencia: cuánta gente cabe
| Sesiones | Contexto | Tokens vivos | ¿Cabe en 1 GPU (~175K)? |
|---|---|---|---|
| 1 | 16K | 16K | ✅ |
| 10 | 16K | 160K | ✅ (justo) |
| 10 | 32K | 320K | ❌ |
| 30 | 16K | 480K | ❌ |
| 30 | 32K | 960K | ❌ |
Y lo bonito: los resultados lo confirman. El escenario de 10 usuarios a 16K (160K tokens) funcionó con 0 fallos y 15,9 tok/s por usuario. El de 10 usuarios a 32K (320K tokens) también terminó, pero con TTFT p50 de 20.861 ms y 7,6 tok/s: la GPU estaba tan por encima de su memoria que el servidor tuvo que estar moviendo caché constantemente. No falló; se arrastró. Eso es lo que se siente cuando empujas el contexto más allá de la VRAM.
La lección que cambia cómo compras
El hardware se dimensiona por memoria, no por cómputo. La intuición dice "más potencia = más usuarios"; la realidad es "más memoria de caché = más usuarios". Puedes tener una GPU con el 90% de cómputo libre y aun así no aceptar ni una sesión más, porque no hay dónde guardar su contexto.
Tres formas de arreglarlo, en orden de costo:
- Cuantizar la caché KV a FP8 (
--kv-cache-dtype fp8): duplica la capacidad (48 KB → son 96 KB en FP16) y suele ser el primer movimiento. - Bajar el contexto máximo (
--max-model-len): cada token menos de techo es memoria libre para más sesiones. - Más GPUs con tensor parallel: escala memoria, pero el costo por hora sube (en el PoC, pasar de 1 a 2 L40S duplicaba la factura).
Lo que no medimos (y hay que decirlo)
- El
GPU KV cache sizereal que reporta vLLM al arrancar: no quedó en ningún log. Los ~175K salen de la aritmética y el informe menciona hasta ~220K tokens en la práctica; ninguna de las dos es una medición guardada. - La VRAM pico en carga y con concurrencia.
Es el tipo de número que, en una prueba de estas, conviene copiar del log de arranque el primer día. Lo dejamos anotado como pendiente.
El resto de la cadena está en Prefix caching: la misma carga, 3× más rápido y en la guía Inference Engineering: de cero a producción.
¿Sabes cuántos tokens vivos aguanta tu GPU? Cuéntame en los comentarios: es la cuenta que decide si tu servidor acepta al usuario número 11.