Slo on lo0 — Blog Técnico

Observabilidad GPU para inferencia LLM: las doce métricas DCGM y vLLM que dictan la salud de tu producción

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

Este post complementa los de Tracing LLM con OpenTelemetry GenAI (la capa de tracing por encima de las métricas), Capacity planning (qué se dimensionó y qué se debe vigilar) y Continuous batching (el mecanismo que explica varias de las métricas del motor).

TL;DR

La observabilidad de un cluster de inferencia LLM se construye sobre dos fuentes complementarias: las métricas del hardware GPU expuestas por DCGM (Data Center GPU Manager) Exporter —parte del NVIDIA GPU Operator— y las métricas del motor de inferencia (vLLM, SGLang, TensorRT-LLM) expuestas en /metrics Prometheus-compatibles. Ninguna de las dos basta sola. La métrica clásica de nvidia-smi llamada GPU utilization es engañosa para LLMs: marca alto cuando hay cualquier kernel ejecutándose, sin distinguir tensor cores ardiendo de SMs esperando por HBM. La cabina de pilotaje completa tiene doce métricas DCGM en cuatro familias (compute: DCGM_FI_PROF_SM_OCCUPANCY, DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, DCGM_FI_PROF_DRAM_ACTIVE; memoria: DCGM_FI_DEV_FB_USED, DCGM_FI_DEV_FB_FREE, DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL; térmico-energético: DCGM_FI_DEV_GPU_TEMP, DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_CLOCK_THROTTLE_REASONS; salud: DCGM_FI_DEV_XID_ERRORS, DCGM_FI_DEV_ECC_DBE_VOL_TOTAL, DCGM_FI_DEV_RETIRED_DBE) y cinco métricas del motor vLLM (vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds). Cada una tiene un umbral verde/ámbar/rojo defendible, una PromQL para alerta, y al menos una falsa lectura habitual que confunde al operador junior. Las seis alertas críticas que cualquier cluster productivo debe disparar son: HBM > 92 %, throttle por térmico o por power, XID error, ECC double-bit, KV cache pool > 95 %, y TTFT P95 fuera de SLO durante 5 minutos. El objetivo de tener este panel: que el operador de turno diagnostique el origen de una degradación en menos de cinco minutos, sin abrir consola SSH a las GPUs. Cuando esto se cumple, el cluster ha pasado a operación profesional; mientras no, se opera por intuición.

Estás aquí: OBSERVE (la otra mitad del tracing)

El tracing —ya cubierto en Tracing LLM con OpenTelemetry GenAI— responde qué pasó en esta request concreta. Las métricas responden qué está pasando en el cluster en agregado. Son complementarias: una alerta del lado de métricas te dice “el clúster está degradando”, el tracing te dice “y esta es la traza concreta que te lo demuestra”. Un cluster sin tracing pero con métricas opera; un cluster sin métricas pero con tracing no opera, debuggea.

La analogía: la cabina de un avión moderno

En un avión comercial moderno, el panel de instrumentos del piloto tiene más de 70 indicadores activos. Si solo hubiese uno —el altímetro, por ejemplo— el avión volaría hacia el suelo en el primer momento de baja visibilidad. Hace falta el altímetro y el indicador de actitud, y el de velocidad, y el de viraje, y el de combustible, y los de presión de aceite de cada motor, y las temperaturas de salida de turbina. Cada uno responde una pregunta distinta. Y todos juntos cubren la pregunta operacional: ¿está el avión sano, está donde debe, y va donde queremos?

La observabilidad de un cluster de inferencia LLM funciona igual. Una sola métrica —“GPU utilization 99 %"— no responde nada útil. Es como mirar solo el cuentakilómetros del coche para diagnosticar por qué hace ruido el motor. La cabina completa es doce instrumentos del lado de hardware más cinco del lado del motor de inferencia, organizados en familias que responden preguntas distintas:

Compute y eficiencia: ¿están los tensor cores haciendo el trabajo que esperamos o están esperando?
Memoria: ¿queda VRAM para nuevas requests o estamos al borde del OOM?
Térmico y energético: ¿el hardware está sano o está limitando el throughput silenciosamente?
Salud y errores: ¿hay degradación del hardware en curso (ECC, XID, NVLink)?
Motor de inferencia: ¿la cola crece, el KV pool está saturado, el SLO se está cumpliendo?

Las cuatro primeras responden a “¿la GPU está bien?”. La quinta responde a “¿está dando el servicio que prometimos?”. Las dos preguntas son distintas y ambas deben tener respuesta a un golpe de vista.

Por qué `nvidia-smi` `GPU-Util` engaña en LLMs

La métrica clásica que aparece en nvidia-smi como GPU-Util corresponde a DCGM_FI_DEV_GPU_UTIL. Su definición oficial: “porcentaje del tiempo durante el cual uno o más kernels estuvieron ejecutándose en la GPU”. El problema en LLMs: la fase de decode es memory-bound, no compute-bound. Cuando el motor de inferencia hace decode token a token, la GPU pasa el 90 % del tiempo esperando que la HBM termine de entregar los pesos del modelo y el KV cache. Hay un kernel corriendo (lectura de HBM); por tanto GPU-Util reporta valores cercanos al 100 %. Pero los tensor cores están parados — el cuello de botella es la memoria, no el compute.

Resultado práctico: el operador ve “GPU-Util 99 %” en Grafana y asume “GPU saturada, no se puede meter más carga”. Pero la realidad puede ser “compute al 25 %, HBM saturada al 95 %”, lo que cambia las decisiones operativas (quantization, batch size, paralelismo). La métrica clásica miente por simplificación.

Lo correcto es mirar las tres métricas de profiling DCGM del subsistema _FI_PROF_*:

DCGM_FI_PROF_SM_OCCUPANCY — ratio de warps activos sobre máximos por SM. ¿Hay trabajo paralelo?
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — % de ciclos con tensor cores efectivamente activos. ¿Está el compute trabajando?
DCGM_FI_PROF_DRAM_ACTIVE — % de ciclos con la HBM transfiriendo. ¿Está la memoria saturada?

Una decode-bound GPU típica de Llama 70B en H100 muestra: SM occupancy 35–55 %, tensor active 15–30 %, DRAM active 80–95 %. Esa es la “GPU saturada” real para LLMs. Las tres juntas distinguen los regímenes; cada una sola no dice nada accionable.

Cómo se montan en producción

La parte de plataforma se cubre en Cinco niveles de madurez (nivel 4 — GPU plane) y Siete fases de despliegue (fase F5). Para el observador, las piezas clave son:

NVIDIA GPU Operator. Manifiestos Helm que despliegan en cada nodo GPU: drivers, container toolkit, MIG manager y DCGM Exporter. Este último expone /metrics en formato Prometheus con todos los DCGM_FI_* listados arriba. Se scrapea desde el Prometheus interno del cluster.

Motor de inferencia. vLLM expone /metrics en el puerto 8000 (default) con métricas vllm:*. SGLang lo expone también con prefijo sglang:. TensorRT-LLM lo expone vía Triton Inference Server con prefijo nv_inference:. La convención básica de nombres es similar entre los tres motores; los umbrales y queries de este post asumen vLLM, pero se traducen.

ServiceMonitor / PodMonitor. Recurso del operador de Prometheus que indica qué scrapear. Ejemplo mínimo:

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
 name: vllm-inference
spec:
 selector:
 matchLabels: { app: vllm }
 podMetricsEndpoints:
 - port: metrics
 interval: 15s

Dashboards. El operador de NVIDIA publica dashboards Grafana de referencia para DCGM en nvidia/dcgm-exporter (repo oficial). vLLM publica uno en vllm-project/vllm (carpeta examples/). Ambos sirven como base; cada equipo añade los paneles propios de su SLO.

Las doce métricas DCGM organizadas por familia

Familia 1 — Compute

DCGM_FI_PROF_SM_OCCUPANCY — Ratio de warps activos por SM sobre el máximo posible. Valor entre 0 y 1.

Verde: 0.30–0.70 (régimen típico LLM en decode).
Ámbar: < 0.20 sostenido (batch demasiado pequeño, GPU infrautilizada en paralelismo).
Rojo: 0.95 sostenido con DRAM_ACTIVE bajo (kernel patológico saturando SMs).

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — % de ciclos con tensor cores ejecutando. La métrica clave de “¿el compute está produciendo?”.

Verde en prefill: 50–80 %.
Verde en decode: 15–30 % (decode es memory-bound, no es síntoma de problema).
Rojo: < 5 % sostenido en prefill o el motor no usa los tensor cores (mala config, formato incompatible).

DCGM_FI_PROF_DRAM_ACTIVE — % de ciclos con HBM transfiriendo datos. Métrica clave para detectar saturación de memoria.

Verde en decode: 60–85 %.
Ámbar: > 90 % sostenido (HBM cuello de botella firme — explica la TPOT alta).
Rojo: > 95 % sostenido con KV cache pool < 70 % (algo está pidiendo HBM que no es el motor; investigar leaks).

Familia 2 — Memoria

DCGM_FI_DEV_FB_USED — Frame Buffer (HBM) usado en MiB.

Verde: 70–85 % del total.
Ámbar: 86–92 %.
Rojo: > 92 % (riesgo de OOM en el siguiente paged-attention allocation).

PromQL para porcentaje sobre cluster: 100 * sum(DCGM_FI_DEV_FB_USED) / sum(DCGM_FI_DEV_FB_TOTAL).

DCGM_FI_DEV_FB_FREE — Frame Buffer libre. Complementaria de la anterior; útil para alertas absolutas (< 4096 MiB libres).

DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL — Bandwidth NVLink agregado en MB/s. Para topologías TP (tensor parallel) que cruzan GPUs vía NVLink, esta métrica revela si el reparto de paralelismo está saturando el bus.

Verde: variable según topología. En 4×H100 SXM con NVLink 4.0, capacidad teórica 450 GB/s por GPU. Régimen TP=4 típico: 50–150 GB/s sostenido.
Rojo: > 90 % capacidad sostenido (revisar si el modelo cabría con TP menor o pipeline parallel).

Familia 3 — Térmico y energético

DCGM_FI_DEV_GPU_TEMP — Temperatura del die en °C.

Verde: < 75 °C.
Ámbar: 75–82 °C.
Rojo: > 83 °C (cerca del thermal throttle automático de H100; revisar ventilación, caudal de aire, temperatura de entrada al rack).

DCGM_FI_DEV_POWER_USAGE — Consumo en watts. Para H100 SXM, TDP nominal 700 W. Útil para tres cosas: detectar workload inusualmente bajo (sospechar idle o stall), facturar coste energético real, y disparar alertas si el draw se acerca al límite de la PDU.

DCGM_FI_DEV_CLOCK_THROTTLE_REASONS — Bitmap codificado con las razones de throttle activas. Es la métrica que silenciosamente explica las degradaciones de TPOT.

Bits relevantes:

0x0000000000000001 — Idle (no es problema).
0x0000000000000002 — App clocks setting.
0x0000000000000004 — SW Power Cap (límite de software, p. ej. por nvidia-smi -pl).
0x0000000000000008 — HW Slowdown.
0x0000000000000010 — Sync Boost (NVIDIA Sync).
0x0000000000000020 — SW Thermal Slowdown (límite térmico de software).
0x0000000000000040 — HW Thermal Slowdown (límite térmico de hardware — emergencia).
0x0000000000000080 — HW Power Brake Slowdown (caída de tensión PSU).
0x0000000000000100 — Display Clock Setting.

Cualquier throttle salvo Idle con valor > 0 sostenido es alerta. La degradación de TPOT con DRAM_ACTIVE ya alto y throttle térmico activo es el clásico “el rack está mal ventilado, no es problema del motor”.

Familia 4 — Salud

DCGM_FI_DEV_XID_ERRORS — Contador acumulado de XID errors del driver. Los XID son códigos de evento crítico que NVIDIA documenta exhaustivamente (XID 13: graphics engine exception; XID 31: GPU memory page fault; XID 43: reset channel verif error; XID 79: GPU has fallen off the bus; XID 95: uncontained ECC error; etc.). Cualquier incremento es alerta inmediata: muchos XID requieren reset del nodo o RMA de la GPU.

DCGM_FI_DEV_ECC_DBE_VOL_TOTAL — Errores ECC double-bit volátiles (no corregibles). A diferencia de los single-bit (que ECC corrige silenciosamente y se contabilizan en DCGM_FI_DEV_ECC_SBE_*), los double-bit corrompen datos. Cualquier valor > 0 es alerta crítica: la GPU debe ser drenada y revisada.

DCGM_FI_DEV_RETIRED_DBE — Páginas físicas de HBM retiradas por double-bit errors acumulados. NVIDIA retira páginas defectuosas automáticamente para prevenir corrupción futura. Más de 4–8 páginas retiradas en una GPU sugiere degradación del silicio: documentar y planificar reemplazo en próxima ventana de mantenimiento.

Las cinco métricas del motor de inferencia (vLLM)

Las métricas DCGM responden “¿está sana la GPU?”. Las del motor responden “¿está el servicio cumpliendo el SLO?”. Sin ellas, sabes que el hardware funciona pero no sabes si los clientes están contentos.

vllm:num_requests_running — Requests actualmente en el batch. Si llega al --max-num-seqs configurado y no baja, el motor está saturado en concurrencia (revisar VRAM y rebalancear vía autoscaler — ver Autoscaling LLM en Kubernetes).

vllm:num_requests_waiting — Requests en cola, sin entrar al batch. Cualquier valor > 0 sostenido durante minutos indica que el cluster no escala con la carga. Esta es la métrica primaria para HPA.

vllm:gpu_cache_usage_perc — % del KV cache pool usado.

Verde: 50–80 %.
Ámbar: 80–92 %.
Rojo: > 92 % (riesgo de preempt-on-OOM: vLLM tirará requests para liberar memoria, lo que aumenta TTFT visiblemente).

vllm:time_to_first_token_seconds — Histograma de TTFT por request. Se consume como histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket[5m]))). Comparado contra el SLO de TTFT P95 dispara la alerta primaria de servicio.

vllm:time_per_output_token_seconds — Histograma de TPOT. Equivalente al anterior pero para fluidez de streaming. Comparado contra el SLO de TPOT P95 dispara la alerta secundaria.

Las seis alertas que deben pagear en producción

Cualquier cluster productivo serio dispara estas seis alertas a un canal con rotación de guardia. Sin estas, el SLO se cumple por suerte, no por proceso.

groups:
 - name: gpu-llm-critical
 rules:
 - alert: GpuHbmNearOom
 expr: 100 * (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL) > 92
 for: 2m
 labels: { severity: critical }
 annotations:
 summary: "HBM de {{ $labels.gpu }} en {{ $value }}% — riesgo OOM"

 - alert: GpuThermalOrPowerThrottle
 expr: (DCGM_FI_DEV_CLOCK_THROTTLE_REASONS != 0) and ignoring(reason) (DCGM_FI_DEV_CLOCK_THROTTLE_REASONS != 1)
 for: 1m
 labels: { severity: warning }
 annotations:
 summary: "GPU {{ $labels.gpu }} en throttle (reasons={{ $value }})"

 - alert: GpuXidErrorDetected
 expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
 labels: { severity: critical }
 annotations:
 summary: "XID error en GPU {{ $labels.gpu }} — investigar inmediatamente"

 - alert: GpuEccDoubleBit
 expr: DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0
 labels: { severity: critical }
 annotations:
 summary: "ECC double-bit en GPU {{ $labels.gpu }} — drenar nodo"

 - alert: VllmKvCachePoolNearFull
 expr: vllm:gpu_cache_usage_perc > 0.95
 for: 3m
 labels: { severity: warning }
 annotations:
 summary: "KV cache pool > 95% en {{ $labels.instance }}"

 - alert: VllmTtftP95OutOfSlo
 expr: histogram_quantile(0.95, sum by(le, instance)(rate(vllm:time_to_first_token_seconds_bucket[5m]))) > 1.5
 for: 5m
 labels: { severity: warning }
 annotations:
 summary: "TTFT P95 sobre SLO ({{ $value }}s > 1.5s)"

Estas seis cubren el 80 % de los incidentes que afectan a SLO. El 20 % restante exige investigación con tracing (ver Tracing LLM con OpenTelemetry GenAI).

Tabla maestra: umbrales y queries

Métrica	Verde	Ámbar	Rojo	Query base (PromQL)
SM occupancy	0.30–0.70	0.15–0.30	< 0.10 sostenido	`DCGM_FI_PROF_SM_OCCUPANCY`
Tensor active (decode)	15–30 %	< 10 %	< 3 %	`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE`
DRAM active	60–85 %	85–95 %	> 95 % con KV bajo	`DCGM_FI_PROF_DRAM_ACTIVE`
FB used	70–85 %	86–92 %	> 92 %	`100 * DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL`
NVLink BW	< 70 % cap	70–90 % cap	> 90 % cap	`DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL`
GPU temp	< 75 °C	75–82 °C	> 83 °C	`DCGM_FI_DEV_GPU_TEMP`
Power usage	< 90% TDP	90–98 % TDP	> 98 % TDP	`DCGM_FI_DEV_POWER_USAGE`
Throttle reasons	0 o Idle	App/SW	HW Therm/Power	`DCGM_FI_DEV_CLOCK_THROTTLE_REASONS`
XID errors	sin cambio	—	cualquier delta	`increase(DCGM_FI_DEV_XID_ERRORS[5m])`
ECC DBE	0	—	> 0	`DCGM_FI_DEV_ECC_DBE_VOL_TOTAL`
Retired pages	< 4	4–8	> 8	`DCGM_FI_DEV_RETIRED_DBE`
KV cache used	50–80 %	80–92 %	> 92 %	`vllm:gpu_cache_usage_perc`
Requests waiting	0	1–5 sostenido	> 10 sostenido	`vllm:num_requests_waiting`
TTFT P95	< SLO	80–100 % SLO	> SLO	ver query alerta arriba
TPOT P95	< SLO	80–100 % SLO	> SLO	`histogram_quantile(0.95, sum by(le)(rate(vllm:time_per_output_token_seconds_bucket[5m])))`

Tres pitfalls que confunden al operador junior

Pitfall 1 — “GPU-Util al 99 % = saturada”. Como se explicó al inicio: DCGM_FI_DEV_GPU_UTIL se enciende con cualquier kernel. Lo correcto es mirar las tres _PROF_* (SM occupancy, tensor active, DRAM active) juntas. GPU util 99 % + tensor active 8 % + DRAM active 92 % = “saturada por memoria, no compute”; GPU util 99 % + tensor active 75 % + DRAM active 50 % = “saturada por compute, prefill heavy”. Las dos situaciones piden palancas distintas.

Pitfall 2 — confundir ECC single-bit (SBE) con double-bit (DBE). Los single-bit se corrigen silenciosamente y son inevitables en cualquier HBM bajo carga (radiación cósmica, fluctuaciones de tensión). Un contador SBE creciendo lentamente no es alerta — es física. El DBE sí: corrompe datos. Distinguir las dos métricas evita falsas alarmas y falsos negativos a partes iguales.

Pitfall 3 — alertar sobre num_requests_waiting > 0 sin contexto. Un valor instantáneo de 1 o 2 durante un pico es normal. Lo que importa es la cola sostenida: usar for: 5m con umbral 3–5. Sin esa ventana, el sistema satura el canal de alertas con ruido.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4×H100 SXM 80 GB con NVLink intra-nodo:

DCGM Exporter desplegado vía NVIDIA GPU Operator, un DaemonSet por nodo GPU.
Prometheus interno con retención 30 días para métricas de alta frecuencia, 1 año para downsampled (Thanos/Mimir si el volumen lo justifica).
Grafana con tres dashboards estándar: hardware GPU (DCGM), motor (vLLM), SLO (TTFT/TPOT/RPS contra objetivos escritos).
Alertmanager con rotación de guardia y rate-limiting por silencio agrupado por nodo.
Cardinalidad controlada: gpu (id local), node, pod, model — no añadir request_id ni labels de alta cardinalidad a métricas (eso es trabajo del tracing).

Volumen estimado para un cluster de 16 GPUs con scraping cada 15 s: ~2 millones de samples/min, ~25 GB/día de Prometheus crudo. Manejable con un Prometheus por cluster + retention; si el equipo escala a > 64 GPUs, considerar Thanos sidecar o VictoriaMetrics. Ver Catálogo de herramientas OSS LLMOps para alternativas equivalentes.

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

Tracing de cargas LLM: ya cubierto en Tracing LLM con OpenTelemetry GenAI.
Autoscaling basado en estas métricas: ver Autoscaling LLM en Kubernetes.
Runbooks de incident response: cómo cada una de estas alertas se traduce a acción concreta (drain, restart, RMA, escalado, rollback).
Cost accounting: usar DCGM_FI_DEV_POWER_USAGE y vllm:request_success_total para showback de coste por tenant.
Monitorización de fairness multi-tenant: cuando varios tenants comparten cluster, qué métricas detectan que uno está acaparando el KV cache.

Ver también

Tracing LLM con OpenTelemetry GenAI — la otra mitad de la observabilidad.
Capacity planning para inferencia LLM on-premise — qué se dimensionó y, por tanto, qué umbrales son defendibles aquí.
Continuous batching — explica por qué num_requests_running, num_requests_waiting y gpu_cache_usage_perc son las métricas operativas del motor.
Cinco niveles de madurez — la observabilidad LLM-aware vive en el nivel 4.
Siete capas del stack de inferencia LLM on-premise — DCGM Exporter es pieza de la capa de plataforma.
Autoscaling LLM en Kubernetes — usa estas métricas como input.
Anatomía de las doce métricas DCGM y cinco vLLM — profundización con analogía y anomalía documentada en producción para cada métrica, con cifras de incidentes públicos (Meta Llama 3, Story of Two GPUs, issues vLLM, KBs Dell/Lenovo).
Runbooks de incident response para LLM con Keep + Kafka — la traducción de cada alerta crítica a acción concreta (drain, reset, RMA, rollback) con workflow YAML, schema Kafka WORM y encaje en ISO 27035, ENS, NIS2, EU AI Act art. 73.

Referencias

NVIDIA — DCGM Exporter (repo nvidia/dcgm-exporter, métricas y unidades documentadas).
NVIDIA — DCGM Field Identifiers reference (lista completa de DCGM_FI_*).
NVIDIA — XID Errors documentation (catálogo de códigos XID y procedimientos de remediación).
NVIDIA — NVIDIA GPU Operator (Helm chart oficial).
vLLM project — examples/production_monitoring/ (PromQL y dashboards Grafana de referencia).
Prometheus — Histogram and summary best practices (para construir queries de percentiles defendibles).
NVIDIA — H100 Tensor Core GPU datasheet (TDP, HBM bandwidth, NVLink capacities).

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).

Slo on lo0 — Blog Técnico

Observabilidad GPU para inferencia LLM: las doce métricas DCGM y vLLM que dictan la salud de tu producción

TL;DR

Estás aquí: OBSERVE (la otra mitad del tracing)

La analogía: la cabina de un avión moderno

Por qué nvidia-smi GPU-Util engaña en LLMs

Cómo se montan en producción

Las doce métricas DCGM organizadas por familia

Familia 1 — Compute

Familia 2 — Memoria

Familia 3 — Térmico y energético

Familia 4 — Salud

Las cinco métricas del motor de inferencia (vLLM)

Las seis alertas que deben pagear en producción

Tabla maestra: umbrales y queries

Tres pitfalls que confunden al operador junior

Aplicado a hardware on-premise típico

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

Ver también

Referencias

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

TL;DR

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

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

Las tres entradas del SLO

La fórmula central: dos presupuestos que se cruzan

Presupuesto de VRAM

Presupuesto de tiempo

El cruce

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

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

Tabla de sensibilidad: contexto y quantization

Las cinco trampas habituales

Aplicado a hardware on-premise típico

Cómo se valida el sizing antes de comprar

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

Ver también

Referencias

Por qué `nvidia-smi` `GPU-Util` engaña en LLMs