Capacity planning para inferencia LLM on-premise: cómo dimensionar GPUs a partir de un SLO

Mon, 01 Jun 2026 15:00:00 +0200

Este post complementa los de KV cache (la pieza que domina el presupuesto de VRAM), Continuous batching (lo que define la utilización efectiva del compute) y Siete capas del stack (las piezas que el sizing presupone). Antes de leer este, asegúrate de que tu equipo tiene escritos los SLOs que va a perseguir; sin esa entrada el cálculo no es defendible.

TL;DR

El capacity planning de inferencia LLM no responde a “cuántos tokens/segundo da una GPU” — esa pregunta carece de respuesta universal porque el throughput depende de la concurrencia, el reparto prefill/decode, la longitud de contexto, el motor de inferencia y la quantization. La pregunta correcta tiene tres entradas (SLO: TTFT P95, TPOT P95, RPS sostenidos), una referencia de hardware (modelo de GPU, VRAM, ancho HBM, FLOPs efectivos) y un modelo (parámetros, arquitectura GQA/MHA/MoE, formato de pesos). El cálculo se resuelve en dos presupuestos acoplados que se cruzan. Presupuesto de VRAM: del total de la GPU restas pesos del modelo y activaciones, lo que queda es KV cache budget, y de ahí derivas la concurrencia máxima posible al contexto promedio que esperas. Presupuesto de tiempo: el motor (vLLM, SGLang, TensorRT-LLM) tiene un techo de tokens/s en decode dado por el ancho de HBM y otro en prefill dado por el FLOP útil; de ahí derivas la TPOT esperada y, dividiendo prefill_tokens entre el throughput de prefill, la TTFT esperada. Ambos presupuestos deben cumplir el SLO simultáneamente: el que esté más ajustado dicta el dimensionamiento. Sobre el ejemplo Llama 70B BF16 con tensor parallel 4 en 4×H100 SXM, una sola réplica satura a ~28 requests concurrentes y entrega ~3 200 tokens/s de decode agregado con TPOT mediano de 35 ms; para 200 RPS sostenidos a un perfil de 800 tokens de prompt + 250 de output, hacen falta entre 4 y 5 réplicas con un colchón del 25 % sobre el pico observado. La quantization (FP8 → INT4) divide entre 1.5 y 4× el coste de VRAM y de tiempo de decode, pero degrada calidad de forma medible — no se asume gratis, se valida con evals. Las cinco trampas habituales: confundir media con P95, ignorar el reparto prefill/decode del workload real, dimensionar sin head-room para retrain ni rollback, olvidar que la GPU al 100 % de SM util no significa nada si la HBM está saturada, y no documentar los supuestos del cálculo (un sizing sin supuestos escritos es un cálculo desechable).

Estás aquí: DEPLOY (con un pie en OBSERVE)

El capacity planning es una pieza con doble residencia. Vive en DEPLOY porque sin un sizing válido no se compra hardware ni se configura el motor de inferencia. Pero su input son las observaciones reales: distribución de longitudes de prompt y output, mezcla prefill/decode del workload, P95 reales que ya se están viendo en preproducción. Sin esos datos el cálculo es una servilleta — defendible solo hasta que llegue el primer cliente que no encaja en la media asumida.

La analogía: el hotel con habitaciones de tamaño variable

Imagina un hotel donde las habitaciones no tienen tamaño fijo: cada huésped paga por los metros cuadrados que necesita, y la planta del edificio se reorganiza dinámicamente para acomodar a quien llega. La dirección quiere maximizar ocupación, pero tiene dos restricciones reales y una métrica de calidad.

Restricción 1 — espacio físico. La planta tiene 1 000 m² totales. Si entra una familia que necesita 200 m², esa familia ocupa esa superficie y no se puede entregar al siguiente huésped. La habitación más grande limita cuántos huéspedes simultáneos caben.

Restricción 2 — personal de servicio. Hay 10 recepcionistas. Cada uno puede gestionar el check-in de un huésped cada dos minutos. Cuando llegan 60 huéspedes en una hora, los últimos esperan en cola; el tiempo desde que entran a recepción hasta que reciben su llave depende de cuántos hay delante.

Métrica de calidad — promesa de tiempo. La carta dice “check-in en menos de 15 minutos”. Si llegan demasiados huéspedes a la vez, esa promesa se rompe aunque haya espacio físico libre.

El espacio físico es la VRAM de la GPU. Cada habitación es una request con su KV cache (más grande cuanto más larga la conversación). Los recepcionistas son los compute units (Streaming Multiprocessors + Tensor Cores). El check-in es la fase de prefill; las noches que el huésped pasa después son los pasos de decode. La promesa de 15 minutos es el SLO de TTFT P95.

El capacity planning del hotel es exactamente este: dado el perfil esperado de huéspedes (cuántos llegan por hora, cuánto espacio piden de media, cuántos minutos toleran de espera), calcular cuántas plantas y cuántos recepcionistas hace falta. No se hace estimando “habitaciones por hora” en abstracto — se hace cruzando los dos presupuestos con la promesa de tiempo. La analogía sostiene el cálculo hasta el final.

Las tres entradas del SLO

Antes de poner un solo número en la hoja, hay que escribir las tres dimensiones del SLO. Sin esto el cálculo es estética, no ingeniería.

TTFT P95 (Time-To-First-Token). El tiempo desde que el cliente envía la request hasta que recibe el primer token. Está dominado por la fase de prefill (procesar el prompt entero de una vez) más la cola del scheduler. Para chat conversacional, un objetivo razonable está entre 0.5 y 2 segundos P95. Para asistentes de programación con prompts grandes (5–10 K tokens de contexto), entre 2 y 4 s P95. Por debajo de 500 ms entra en regla de UX para conversaciones tipo voz, pero exige compromisos serios de arquitectura.

TPOT P95 (Time-Per-Output-Token). El tiempo entre tokens consecutivos durante decode. Domina la “fluidez percibida” del streaming. Por encima de 80 ms/token el lector humano percibe pausas; por debajo de 30 ms/token la salida fluye más rápido de lo que se lee. Objetivo industrial habitual: 40–60 ms P95.

RPS sostenidos cumpliendo SLO. El throughput que el sistema debe soportar sin violar TTFT ni TPOT. Esto es la métrica clave de DistServe llamada goodput —ver Continuous batching—. “200 RPS pico” no es lo mismo que “200 RPS con TTFT P95 ≤ 1.5 s”. Sin la condición de SLO, el número de RPS no significa nada.

Estas tres dimensiones se acompañan de un perfil de workload: distribución de longitudes de prompt y de output. Las medianas no bastan; hace falta P50, P95, P99. Un perfil mal medido es el principal motivo de sizing fallido.

La fórmula central: dos presupuestos que se cruzan

El cálculo se resuelve en dos cuentas independientes que después se cruzan. La menor de las dos manda.

Presupuesto de VRAM

Para una GPU con VRAM total $V$, el espacio disponible para KV cache es:

$$V_{\text{kv}} = V - V_{\text{model}} - V_{\text{activations}} - V_{\text{overhead}}$$

donde:

$V_{\text{model}}$ es el tamaño de los pesos: para un modelo de $P$ parámetros en formato $b$ bytes/parámetro, $V_{\text{model}} = P \cdot b$. Llama 70B BF16 = $70 \times 10^9 \times 2 = 140$ GB. En tensor parallel TP=4, cada GPU lleva $140 / 4 = 35$ GB.
$V_{\text{activations}}$ son los buffers intermedios del forward pass. Para vLLM con batch razonable, entre 2 y 6 GB por GPU dependiendo de batch size y longitud máxima.
$V_{\text{overhead}}$ son CUDA context, NCCL buffers, pool de PagedAttention, paged blocks reservados. 2–4 GB típicos.

El KV cache budget por GPU queda como el residuo. Para H100 SXM 80 GB con Llama 70B TP=4 BF16:

$$V_{\text{kv}} = 80 - 35 - 4 - 3 = 38 \text{ GB por GPU} = 152 \text{ GB agregados sobre TP=4}$$

El coste por token de KV cache para un modelo con $L$ capas, $H_{\text{kv}}$ heads KV (GQA), dimensión por head $d_h$, en formato $b$ bytes:

$$\text{kv_per_token} = 2 \cdot L \cdot H_{\text{kv}} \cdot d_h \cdot b$$

El factor 2 es porque se guardan K y V. Para Llama 70B (L=80, $H_{\text{kv}}$=8 con GQA, $d_h$=128, BF16 = 2 bytes):

$$\text{kv_per_token} = 2 \cdot 80 \cdot 8 \cdot 128 \cdot 2 = 327,680 \text{ bytes} = 320 \text{ KB/token}$$

Y la concurrencia máxima al contexto promedio $C$:

$$N_{\text{max}} = \frac{V_{\text{kv}}}{C \cdot \text{kv_per_token}}$$

Con $V_{\text{kv}}$ agregado de 152 GB y un contexto promedio de 1 500 tokens (800 prompt + 700 generados en el peor instante de la conversación):

$$N_{\text{max}} = \frac{152 \times 10^9}{1,500 \cdot 320 \times 10^3} \approx 316 \text{ requests concurrentes}$$

Este es el techo físico de concurrencia para esa réplica. No es lo que vas a usar — es lo que no puedes superar sin OOM. El número operativo está bastante por debajo (head-room para spikes).

Presupuesto de tiempo

Aquí entran dos sub-cálculos: el de decode (memory-bound) y el de prefill (compute-bound).

Decode TPOT. Por cada token que se genera, hay que pasear los pesos del modelo (relevantes para esa request) y leer el KV cache acumulado. El cuello de botella es el ancho de banda HBM. Para una GPU con ancho $B$ GB/s y un modelo de $V_{\text{model_per_gpu}}$ GB de pesos:

$$\text{tpot}{\text{teórico}} \approx \frac{V{\text{model_per_gpu}}}{B}$$

Para H100 SXM con HBM3 a 3.35 TB/s y Llama 70B TP=4 BF16 (35 GB/GPU):

$$\text{tpot}_{\text{teórico}} \approx \frac{35}{3,350} \approx 10.4 \text{ ms/token}$$

Este es el mejor caso teórico con batch=1 y eficiencia HBM al 100 %. En la práctica vLLM en H100 con Llama 70B TP=4 alcanza 12–18 ms/token a batch bajo y 30–45 ms/token a batch alto (con concurrencia 32, los tokens compiten por la HBM compartida). El número operacional defendible: 35 ms/token en concurrencia 24–32.

Prefill throughput. El prefill procesa N tokens de prompt en un único forward pass. Es compute-bound: cuello en FLOPs. Para H100 SXM con 989 TFLOPs BF16 sostenidos y Llama 70B (cada forward pass cuesta aproximadamente $2 \cdot P \cdot N$ FLOPs por sequence de longitud N):

$$\text{prefill_tps} = \frac{4 \cdot \text{TFLOPs} \cdot \eta}{2 \cdot P} = \frac{4 \cdot 989 \times 10^{12} \cdot 0.5}{2 \cdot 70 \times 10^9} \approx 14,000 \text{ tokens/s}$$

(el factor 4 son las GPUs en TP, $\eta$ es eficiencia real entre 0.4 y 0.6 en H100). Un prompt de 800 tokens tarda en prefill:

$$\text{prefill_time} = \frac{800}{14,000} \approx 57 \text{ ms}$$

Sumando una cola típica de 100–300 ms a concurrencia alta, TTFT P95 ≈ 350–500 ms para ese perfil. Muy por debajo del objetivo de 1.5 s — hay margen.

El cruce

La concurrencia operativa real $N_{\text{op}}$ es el mínimo entre el techo de VRAM, la concurrencia a la que el TPOT empieza a degradar por encima del SLO, y la concurrencia a la que el TTFT empieza a degradar por encima del SLO (cola de prefill). Para el ejemplo:

VRAM techo: 316.
TPOT degrada a 80 ms (SLO) alrededor de concurrencia ~80–100 (medido empíricamente con benchmark, no fórmula cerrada).
TTFT degrada a 1.5 s alrededor de concurrencia ~40–60 por cola de prefill.

La concurrencia operativa de la réplica es ~50. Aplicando un 25 % de head-room para spikes y rebalanceos, concurrencia objetivo por réplica ≈ 35–40.

Hoja de cálculo paso a paso: Llama 70B BF16 en 4×H100 SXM

Entrada del ejercicio:

SLO: TTFT P95 ≤ 1.5 s; TPOT P95 ≤ 60 ms; 200 RPS sostenidos.
Workload: prompt P50=600, P95=1 200, P99=2 500; output P50=180, P95=500, P99=900. Promedio prompt 800, output 250.
Hardware genérico: 4×H100 SXM 80 GB con NVLink, motor vLLM v1, tensor parallel 4, BF16.

Paso 1 — VRAM por GPU. Pesos 35 GB, activaciones 4 GB, overhead 3 GB → KV budget 38 GB/GPU = 152 GB agregados. KV/token a Llama 70B GQA = 320 KB. Techo de tokens vivos en cache: $152 \times 10^9 / 320 \times 10^3 \approx 475,000$ tokens. Al contexto promedio operacional (800 prompt + 200 ya generados = 1 000 tokens vivos por request), techo de concurrencia $\approx 475$.

Paso 2 — duración media de una request. Prefill 800 tokens / 14 000 tps = 57 ms. Decode 250 tokens × 35 ms/token = 8 750 ms. Total $\approx 8.8$ s por request.

Paso 3 — throughput de la réplica. Si la réplica sostiene concurrencia operativa 40 y cada request dura 8.8 s, la réplica entrega aproximadamente $40 / 8.8 \approx 4.5$ requests/s en régimen estacionario.

Paso 4 — número de réplicas. Para 200 RPS objetivo: $200 / 4.5 \approx 45$ réplicas. Eso son 45 × 4 = 180 GPUs. Demasiado: este sizing no funciona porque el coste por request es alto.

Paso 5 — revisar palancas. Antes de comprar más hardware, hay tres palancas que se exploran en este orden:

Quantization. Bajar a FP8 reduce pesos a 17.5 GB/GPU (queda más VRAM para KV cache → más concurrencia), aproximadamente duplica tokens/s en decode (HBM saturada por la mitad), y degrada calidad MMLU típicamente 0.5–1.5 puntos en modelos como Llama 70B. Reescribiendo el cálculo en FP8: TPOT baja a ~18 ms, tiempo total por request a 4.7 s, RPS por réplica sube a ~8.5, réplicas necesarias ≈ 24, equivalente a 96 GPUs.
Speculative decoding. Con un drafter pequeño y aceptación del 60–70 %, TPOT efectivo cae 30–40 %. RPS por réplica sube a ~12, réplicas ≈ 17 = 68 GPUs.
Disaggregated serving. Separar prefill workers y decode workers permite escalar cada uno a la mezcla real del workload —ver Disaggregated serving—. Suele recortar otro 20–40 % bajo workloads asimétricos.

Paso 6 — sizing recomendado. Para el ejemplo, con FP8 + speculative decoding y un head-room del 25 %: 20 réplicas vLLM TP=4 sobre 80 H100 SXM. Si el equipo no quiere depender de quantization agresiva (BF16 puro para máxima fidelidad), el cálculo sube a 30 réplicas = 120 GPUs y obliga a renegociar SLO o presupuesto.

Paso 7 — escribir los supuestos. Esta es la parte que ningún sizing válido se salta. En el repo del equipo, junto al cálculo:

# sizing/llama70b-prod.yaml
fecha: 2026-06-01
slo:
 ttft_p95_ms: 1500
 tpot_p95_ms: 60
 rps_target: 200
workload:
 prompt_tokens_p50: 600
 prompt_tokens_p95: 1200
 output_tokens_p50: 180
 output_tokens_p95: 500
 asunto: chat productivo con RAG ligero
modelo:
 arquitectura: llama-70b-instruct
 formato_pesos: fp8
 motor: vllm-v1
hardware:
 gpu: H100-SXM-80GB
 topologia: TP=4 con NVLink intra-nodo
 red_inter_replica: 25 GbE
optimizaciones:
 - paged_attention
 - chunked_prefill
 - speculative_decoding (drafter llama-1.1b, aceptación esperada 65%)
asunciones_criticas:
 - utilizacion_hbm_eficiente: 0.55
 - head_room_pico_sobre_p95: 0.25
 - aceptacion_speculative_min: 0.55
plan_validacion:
 - benchmark vllm bench serve antes de procurement
 - canary 10% durante 7 días post-deploy

Sin este YAML, el cálculo no es reproducible un mes después.

Caso MoE: Mixtral 8×22B (~141 B totales, 39 B activos)

Los MoE cambian el cálculo en una dimensión clave: los pesos totales son grandes pero los pesos activos por token son pequeños. Para Mixtral 8×22B con top-2 routing:

VRAM de pesos: $141 \times 2 = 282$ GB BF16. Con TP=4 → 70 GB/GPU. No cabe en H100 80 GB con KV cache + activaciones. Hace falta TP=8 (~35 GB/GPU) o FP8 con TP=4 (~35 GB/GPU).
Decode TPOT: dominado por los pesos leídos por token, que son $\sim 39 / 8 \cdot 2 \approx 9.75$ GB/GPU con TP=4 (un experto top-2 por token, dividido entre 4 GPUs). En H100 con HBM 3.35 TB/s, TPOT teórico ≈ 3 ms/token. En la práctica, 10–20 ms a concurrencia razonable.
Prefill: similar al modelo denso de los pesos activos, ~39 B FLOPs/token.

El sizing MoE suele entregar más RPS por GPU que un denso equivalente — el coste por token bajo compensa el extra de VRAM. Ver MoE inference para el detalle del routing y por qué el batch alto es decisivo para que cada experto vea suficientes tokens.

Tabla de sensibilidad: contexto y quantization

Para Llama 70B sobre 4×H100 SXM (TP=4), concurrencia operativa por réplica con SLO TTFT 1.5 s / TPOT 60 ms:

Contexto promedio	BF16	FP8	INT4 (AWQ)
500 tokens	55	110	180
1 000 tokens	40	80	130
2 000 tokens	24	50	85
4 000 tokens	12	26	48
8 000 tokens	6	13	25

Números aproximados de benchmark vLLM público a junio 2026, con variación ±20 % según versión del motor y headroom adoptado. Para validar en tu hardware: vllm bench serve con tu perfil de prompts reales.

Las cinco trampas habituales

Trampa 1 — confundir media con P95. El throughput medio de una hora puede ser 50 RPS pero el pico de 5 minutos llegar a 180 RPS. Dimensionar contra la media garantiza romper SLO en cada pico. Regla: dimensionar contra P95 horario, con head-room del 20–30 % sobre P95.

Trampa 2 — no medir el reparto prefill/decode real. Un workload de “RAG con respuestas cortas” tiene 70–80 % del tiempo de GPU en prefill; un “writing assistant que genera ensayos” tiene 80 % en decode. Las optimizaciones útiles (chunked prefill vs speculative decoding) cambian radicalmente. Sin medirlo, se compra hardware mal balanceado.

Trampa 3 — dimensionar sin head-room para retrain ni rollback. El cluster productivo no es solo el motor de inferencia: hay batch de re-embeddings cuando cambia el modelo de embeddings, eval continuo de canary —ver Canary, blue-green y shadow—, fine-tune ligero, hot stand-by para rollback. Reservar 15–25 % de capacidad para esos workloads no negociables.

Trampa 4 — “GPU al 100 % de SM utilization” como objetivo. SM occupancy del 95 % con HBM saturada produce el mismo throughput que SM al 60 % con HBM saturada. El cuello de botella en decode es la HBM. Optimizar para “GPU usage 100 %” sin mirar HBM utilization y arithmetic intensity hace gastar más en GPU sin ganar throughput. Ver Observabilidad GPU para inferencia LLM para qué métricas mirar realmente.

Trampa 5 — no documentar los supuestos. Un sizing sin YAML reproducible (workload, modelo, motor, head-room, asunciones críticas) deja al equipo sin manera de saber qué cambió cuando el cluster ya no llega a SLO seis meses después. Documentar es barato; perder un trimestre depurando, no.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4×H100 SXM 80 GB con NVLink intra-nodo y 25 GbE entre nodos, las configuraciones recurrentes en mayo 2026 son:

Modelo	Formato	TP	Réplicas que caben	RPS típico por nodo (ctx 1K)
Llama 8B	BF16	1	4 (una por GPU)	240–320
Llama 8B	FP8	1	4	450–600
Llama 70B	BF16	4	1	30–45
Llama 70B	FP8	4	1	60–90
Llama 70B	INT4 AWQ	2	2	90–130
Mixtral 8×22B	FP8	4	1	90–140
Qwen 72B	BF16	4	1	28–42

Estos números son órdenes de magnitud para empezar la conversación, no compromisos. El sizing definitivo se valida con vllm bench serve o genai-perf (NVIDIA) usando el perfil de prompts/outputs reales del cliente. La asimetría prefill/decode del workload de cada caso puede mover estos números un 30–50 % arriba o abajo.

Para clusters de 8×H100 SXM (típico de servidores DGX o réplicas equivalentes), las opciones se abren a TP=8 para modelos clase 405B o multi-réplica TP=2 para modelos 70B con mayor densidad. La métrica que decide es siempre la misma: tokens cumpliendo SLO por kW y por euro de hardware amortizado.

Cómo se valida el sizing antes de comprar

El sizing en hoja de cálculo es la primera mitad. La segunda es el benchmark de validación.

Stage 1 — sizing servilleta. Las fórmulas de este post sobre el SLO y el workload esperado. Salida: número aproximado de réplicas y topología.

Stage 2 — micro-benchmark sintético. En una GPU prestada o alquilada por días, levantar el motor con el modelo elegido y correr vllm bench serve con prompts de longitudes representativas. Validar TPOT, prefill TPS y techo de concurrencia. Calibrar el factor de eficiencia HBM ($\eta$) usado en las fórmulas.

Stage 3 — load test con tráfico realista. Generar tráfico siguiendo la distribución real del workload del cliente (no Poisson, no constante: la traza real). Medir P50/P95/P99 de TTFT, TPOT, throughput. Confirmar el head-room.

Stage 4 — canary en producción. Con el cluster dimensionado, encaminar el 5–10 % del tráfico real durante 7–14 días antes de cerrar el procurement de hardware adicional. Ver Canary, blue-green y shadow para la mecánica.

Saltar de Stage 1 a procurement total es la causa más frecuente de cluster sobredimensionado en el 40 % y subdimensionado en el 60 % al mismo tiempo, en regiones distintas del workload. Cuatro semanas de validación bien hechas ahorran cuatro meses de refactor.

Lo que no hemos cubierto (próximos artículos)

Las métricas de observabilidad que cierran el bucle del sizing en producción — ver Observabilidad GPU para inferencia LLM.
El autoscaling que ajusta réplicas a la curva real de tráfico — ver Autoscaling LLM en Kubernetes.
El cost accounting detallado por tenant (showback / chargeback) sobre el hardware dimensionado.
El sizing para fine-tuning continuo (PEFT y entrenamiento ligero) que comparte cluster con la inferencia.

Ver también

KV cache: la memoria de trabajo que sostiene la inferencia LLM — el componente que domina el presupuesto de VRAM.
Continuous batching — qué define la utilización efectiva del compute y la métrica goodput.
Disaggregated serving prefill/decode — palanca avanzada para workloads asimétricos.
MoE inference — cómo cambian las cuentas con modelos MoE.
Quantization para inferencia — qué cuesta y qué ahorra cada formato.
Siete capas del stack de inferencia LLM on-premise — las piezas que el sizing presupone.
Entornos mixtos NVIDIA + Intel para inferencia LLM — el sizing cierra mejor cuando se acepta heterogeneidad: embeddings y reranker en Intel Xeon AMX liberan H100 para el LLM grande, sin comprar más GPU.

Referencias

Kwon et al. — vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention (SOSP 2023).
Zhong et al. — DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving (OSDI 2024).
Agrawal et al. — Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve (OSDI 2024).
NVIDIA — H100 Tensor Core GPU Architecture Whitepaper (memoria HBM3, bandwidth, FLOPs sostenidos).
vLLM project — vllm bench serve reference (CLI de benchmarking incluida en el repo).
NVIDIA — genai-perf (herramienta oficial para benchmark de servicios LLM).

Tpot on lo0 — Blog Técnico