GPU idle: el coste que no aparece en ninguna factura pero lo paga todo el TCO

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

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

TL;DR

El coste por token de inferencia on-premise es ( \text{€/GPU-hora} \div \text{throughput} ). El throughput es función directa de la ocupación útil de la GPU. En un nodo genérico de 4×H100 SXM con un coste de referencia de ~11 € por GPU-hora (amortización + energía + infraestructura), la curva de coste sobre ocupación tiene este aspecto:

Ocupación útil	Throughput efectivo (tok/s)	Coste por 1M tokens
20 %	~700	~43 €
40 %	~1 400	~21 €
70 %	~2 500	~12 €
85 % (techo práctico)	~3 000	~10 €

Doblar la ocupación del 20 % al 40 % recorta el coste por token a la mitad, sin comprar más hierro. A 70 % el coste compite con proveedores cloud europeos (~2,2 €/GPU-hora en on-demand Scaleway). A 20 % on-prem es cuatro veces más caro que alquilar. La palanca no es el modelo, ni la precisión: es cuántas GPU-horas de pago producen tokens de servicio.

1 · La identidad fundamental

El coste por millón de tokens (CPM) en inferencia propia no es un precio de lista. Es:

$$ \text{CPM} = \frac{C_{\text{GPU}} \cdot N_{\text{GPU}}}{T_{\text{ef}} \times 3600 / 10^6} $$

donde ( C_{\text{GPU}} ) es el coste por GPU-hora (€/h), ( N_{\text{GPU}} ) el número de GPUs asignadas al servicio y ( T_{\text{ef}} ) el throughput efectivo (tok/s). Despejando la dependencia con la ocupación:

$$ T_{\text{ef}} = T_{\text{pico}} \times \rho $$

siendo ( \rho \in [0,1] ) la tasa de ocupación útil (fracción del tiempo en que la GPU está procesando tokens de servicio real). La identidad resultante:

$$ \text{CPM} = \frac{C_{\text{GPU}} \cdot N_{\text{GPU}}}{T_{\text{pico}} \times \rho \times 3600 / 10^6} $$

La consecuencia directa: CPM es inversamente proporcional a ( \rho ). Duplicar ( \rho ) divide CPM por dos. El numerador (coste del hierro) no cambia.

Los posts coste-por-token-y-por-request y capacity-planning-inferencia-llm-on-premise cubren cómo calcular ( C_{\text{GPU}} ) y el throughput pico de referencia. Este artículo se ocupa de ( \rho ): cómo medirlo, qué lo limita y cómo subirlo.

2 · Por qué la métrica estándar engaña: `DCGM_FI_DEV_GPU_UTIL`

El campo DCGM_FI_DEV_GPU_UTIL (field ID 203) aparece en nvidia-smi como «GPU-Util». Su definición oficial en la documentación DCGM:

«GPU Utilization» — porcentaje de tiempo durante el que uno o más kernels estaban ejecutándose en la GPU.

El problema para inferencia LLM: la fase de decode es memory-bound. La GPU corre un kernel de lectura de pesos desde HBM token a token; por tanto GPU_UTIL registra cercano al 100 % aunque los tensor cores estén al 15 % de su capacidad. El campo mide actividad, no trabajo útil.

La distinción es crítica para FinOps: un operador que ve GPU_UTIL 98 % asume «GPU saturada, no cabe más carga». La realidad puede ser «los tensor cores están al 20 % y el cuello de botella es la HBM», lo que abre espacio a continuous batching o bin-packing adicional.

Las métricas que miden ocupación real son las del subsistema _FI_PROF_*, disponibles en DCGM 3.x con el módulo de profiling activado:

Tabla de campos DCGM relevantes

Campo DCGM	Field ID	Qué mide	Unidad	Nota operativa
`DCGM_FI_DEV_GPU_UTIL`	203	% tiempo con ≥1 kernel activo	%	Engañoso en decode LLM
`DCGM_FI_PROF_SM_ACTIVE`	1002	Ratio de ciclos con ≥1 warp activo por SM	0–1	Actividad de compute, no ocupación
`DCGM_FI_PROF_SM_OCCUPANCY`	1003	Warps residentes / máximo teórico por SM	0–1	Paralelismo intra-SM real
`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE`	1004	% ciclos con tensor cores (HMMA) activos	0–1	La métrica de eficiencia compute real
`DCGM_FI_PROF_DRAM_ACTIVE`	1005	% ciclos con HBM transfiriendo	0–1	Saturación de memoria
`DCGM_FI_PROF_PCIE_TX_BYTES`	—	Bytes TX por PCIe	bytes/s	Útil en inferencia PCIe
`DCGM_FI_DEV_FB_USED`	252	HBM usada	MiB	Presupuesto VRAM
`DCGM_FI_DEV_POWER_USAGE`	—	Consumo real	W	Para coste energético real
`DCGM_FI_DEV_CLOCK_THROTTLE_REASONS`	—	Bitmap causas de throttle	bitmap	Detecta degradación silenciosa

Los campos _PROF_* requieren el módulo de profiling de DCGM y permisos adecuados del driver. Se documentan exhaustivamente en la referencia de field IDs de NVIDIA DCGM y en el post hermano observabilidad-gpu-dcgm-llm.

Lectura característica en decode LLM (Llama 70B FP8 en H100)

Métrica	Valor típico decode	Interpretación
`DCGM_FI_DEV_GPU_UTIL`	95–99 %	Mentira: hay kernel activo
`DCGM_FI_PROF_SM_ACTIVE`	0,45–0,65	SMs con warps el 45–65 % del tiempo
`DCGM_FI_PROF_SM_OCCUPANCY`	0,30–0,55	Warps residentes al 30–55 % del máximo
`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE`	0,10–0,25	Tensor cores activos solo el 10–25 %
`DCGM_FI_PROF_DRAM_ACTIVE`	0,75–0,90	HBM ocupada el 75–90 % del tiempo

Lectura: el decode es memory-bound. Los pesos del modelo se cargan desde HBM para cada token; la HBM está saturada pero los tensor cores esperan. Toda la «utilización» del nvidia-smi viene de lecturas de memoria, no de cómputo.

3 · MFU y HFU: la ocupación expresada en FLOPs

La métrica canónica de eficiencia de cómputo es el MFU (Model FLOPs Utilization), definida en el paper PaLM (Chowdhery et al., arXiv 2204.02311, sección 4):

$$ \text{MFU} = \frac{T_{\text{obs}} \times C_{\text{modelo}}}{P_{\text{pico}}} $$

donde ( T_{\text{obs}} ) es el throughput observado (tok/s) y ( P_{\text{pico}} ) es el rendimiento teórico pico del hardware (FLOP/s).

donde ( C_{\text{modelo}} ) es el número de FLOPs por token en un forward pass completo. Para un transformer denso con ( P ) parámetros, la aproximación habitual (forward + backward = 6P FLOPs por token; solo forward = 2P):

$$ C_{\text{modelo}} \approx 2P \quad \text{(inferencia)} $$

$$ C_{\text{modelo}} \approx 6P \quad \text{(entrenamiento, forward + backward)} $$

El HFU (Hardware FLOPs Utilization) mide los FLOPs realmente ejecutados en hardware, incluyendo recomputación de activaciones (gradient checkpointing). En entrenamiento con recompute:

$$ C_{\text{hardware}} \approx 8P \quad \text{(forward × 2 + backward × 4)} $$

por tanto HFU > MFU cuando hay recompute; son idénticos sin recompute.

Valores típicos de MFU

Régimen	Hardware	MFU típico	Régimen limitante
Entrenamiento (large batch, BF16)	H100 SXM	35–50 %	compute-bound
Entrenamiento PaLM 540B	TPU v4	46,2 %	compute-bound
Inferencia prefill (batch grande)	H100 SXM	25–45 %	compute-bound
Inferencia decode (bs=1)	H100 SXM	3–8 %	memory-bound
Inferencia decode (continuous batching, bs=32–64)	H100 SXM	15–30 %	memory-bound atenuado

El decode con batch size 1 tiene MFU de un solo dígito porque el hardware pasa la mayor parte del tiempo esperando que la HBM entregue pesos. Subir el batch size (continuous batching) amortiza la lectura de pesos entre más tokens simultáneos y sube el MFU.

El modelo Roofline

El roofline sitúa cada operación en el espacio (intensidad aritmética, throughput):

El decode con batch size 1 cae en la zona memory-bound de la izquierda del ridge point. Subir el batch (continuous batching) desplaza el punto hacia la derecha y arriba, acercándolo al roofline.

4 · Sensibilidad del TCO a la ocupación

Hipótesis del ejemplo: nodo genérico con 4×H100 SXM 80 GB, coste total del nodo ~44 €/hora (amortización 5 años de ~220 000 €, energía ~4×700 W a ~0,12 €/kWh, más infraestructura rack/colocation; ver coste-por-token-y-por-request para el detalle de la identidad). Throughput pico de referencia con Llama 70B FP8 + continuous batching: ~3 500 tok/s agregado.

$$ \text{CPM}(\rho) = \frac{44\ \text{€/h}}{3500 \times \rho \times 3600 / 10^6} = \frac{44 \times 10^6}{3500 \times \rho \times 3600} = \frac{3{,}49}{\rho}\ \text{€/1M tok} $$

Ocupación ( \rho )	Throughput efectivo (tok/s)	CPM on-prem	CPM cloud on-demand (~2,2 €/GPU-h)
20 %	700	~17,5 €	~6,3 €
40 %	1 400	~8,7 €	~6,3 €
60 %	2 100	~5,8 €	~6,3 €
70 %	2 450	~5,0 €	~6,3 €
85 %	2 975	~4,1 €	~6,3 €

Punto de cruce on-prem / cloud: con este hardware de ejemplo, la ventaja de coste on-prem respecto a un cloud europeo comparable empieza en ( \rho \approx 55\text{-}60,% ). Por debajo, el idle convierte on-prem en más caro que alquilar. La columna de cloud es fija porque el cloud factura por hora usada, no por el throughput que se extrae de ella.

Cifras de ejemplo con hardware genérico. Los números reales dependen del precio de la amortización, el coste de la energía local, el modelo y la precisión. La estructura de la curva —CPM inversamente proporcional a ( \rho )— es universal.

5 · Métricas de idle: dónde se pierde la ocupación

Antes de aplicar palancas, hay que saber qué tipo de idle domina. Tres categorías:

Tipo de idle	Síntoma en métricas	Causa habitual
Idle scheduling	`DCGM_FI_DEV_POWER_USAGE` bajo, `SM_ACTIVE` < 0,05	No hay requests en cola; GPU esperando trabajo
Idle batching	`SM_ACTIVE` alto, `PIPE_TENSOR_ACTIVE` bajo, `DRAM_ACTIVE` bajo	Batch demasiado pequeño; prefill stall entre requests
Idle memory-bound	`DRAM_ACTIVE` alto, `PIPE_TENSOR_ACTIVE` bajo	Decode normal; HBM es el cuello; batch size insuficiente

El idle de scheduling es el más caro y el más directo de atacar con bin-packing. El idle de batching se ataca con continuous batching. El idle memory-bound en decode no desaparece del todo (es la física del transformador), pero se atenúa con batch size mayor.

Las métricas de motor de inferencia que complementan el diagnóstico desde el lado del servicio se documentan en observabilidad-gpu-dcgm-llm y anatomia-metricas-dcgm-vllm-anomalias.

6 · Palancas para subir la ocupación

Tabla palanca × efecto × cuándo aplica

Palanca	Efecto sobre ( \rho )	Cuándo aplica	Complejidad operativa
Continuous batching	Alto: elimina idle entre requests; sube MFU decode de ~5 % a ~20 %	Siempre en inferencia; activado por defecto en vLLM	Baja (parámetro del motor)
Bin-packing del scheduler (kube-scheduler / Kueue)	Alto: concentra cargas en menos nodos; libera nodos completos para apagado o rebalanceo	Clusters con carga variable a lo largo del día	Media (política de scheduler)
MIG (Multi-Instance GPU)	Medio: llena GPUs con cargas ligeras que antes vivían solas en una GPU entera	Cargas heterogéneas: embeddings + reranker + guardrail + modelo grande	Alta (reparticionado en caliente no disponible)
Time-slicing	Bajo-medio: sube ocupación en dev/ráfagas; sin aislamiento	GPUs de consumo (RTX 5090/4090); dev multi-tenant de bajo riesgo	Baja
MPS	Medio: ejecución concurrente de múltiples procesos pequeños; reduce overhead context-switch	Muchos kernels pequeños concurrentes en GPU datacenter; confianza entre cargas	Media
Chunked prefill	Medio: intercala prefill y decode; reduce TTFT spike y sube throughput	Cargas con mix de prompts cortos y largos	Baja (flag vLLM)
Quantización (FP16→FP8→INT4)	Indirecto: sube throughput pico, lo que baja CPM para la misma ( \rho )	Modelos con soporte de kernels quantizados (Hopper FP8 nativo)	Media
Autoscaling (KEDA)	Mantiene ( \rho ) alta escalando réplicas según cola	Carga variable y predecible; cluster con capacidad de spare	Media

El post compartir-gpu-time-slicing-mps-mig detalla los tres mecanismos de compartición (time-slicing, MPS, MIG) con presupuestos de VRAM.

Bin-packing con Kueue

Kueue (sigs.k8s.io/kueue) es el gestor de colas de jobs GPU nativo de Kubernetes. Su modelo de cohorts y nominal quotas permite bin-packing activo: los jobs se acumulan en cola y se lanzan solo cuando hay un nodo que puede recibirlos completo, en lugar de fragmentar la carga entre nodos parcialmente ocupados.

El BestFit packing en el ClusterQueue se configura con:

apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
 name: gpu-prod
spec:
 preemption:
 reclaimWithinCohort: Any
 withinClusterQueue: LowerPriority
 resourceGroups:
 - coveredResources: ["nvidia.com/gpu"]
 flavors:
 - name: h100-sxm
 resources:
 - name: "nvidia.com/gpu"
 nominalQuota: 16

La política de preemption por prioridad asegura que los jobs de producción desplacen los de experimentación cuando hay escasez, manteniendo la ocupación de los nodos de producción alta.

MIG como palanca de bin-packing dentro de la GPU

MIG permite rellenar una H100 con cargas ligeras que de otro modo vivirían solas en una GPU entera. Un perfil 3×2g.20gb + 1×1g.10gb en una H100 puede alojar simultáneamente un modelo 7B FP8 (~14 GB de pesos), dos servicios de embeddings y un guardrail INT4, todos con aislamiento de hardware. Sin MIG, cada una de esas cargas ocuparía una GPU completa con ( \rho ) individual < 10 %.

Los perfiles disponibles en H100 80 GB (SXM5) según la MIG User Guide de NVIDIA:

Perfil MIG	Compute slices	Memoria	Máx. instancias
`1g.10gb`	1/7 SMs	10 GB	7
`1g.20gb`	1/7 SMs	20 GB	4
`2g.20gb`	2/7 SMs	20 GB	3
`3g.40gb`	3/7 SMs	40 GB	2
`4g.40gb`	4/7 SMs	40 GB	1
`7g.80gb`	7/7 SMs	80 GB	1 (GPU entera)

MIG no está disponible en GPUs de consumo (RTX 5090, RTX 4090). Time-slicing es la única opción de compartición en ese hardware.

7 · Continuous batching: el efecto sobre MFU

El continuous batching (también llamado iteration-level scheduling o in-flight batching) es el mecanismo que mayor impacto tiene sobre la ocupación en inferencia. La idea: en lugar de esperar a que un batch completo termine para lanzar el siguiente, el motor evalúa el pipeline tras cada token y sustituye las secuencias completadas por nuevas requests de la cola de espera.

Efecto cuantificado en vLLM:

Sin batching (bs=1, estático): MFU decode ~3–8 %; GPU en idle entre requests.
Con continuous batching (bs dinámico 16–64): MFU decode ~15–30 %; la GPU casi nunca espera.
En cargas de prefill puro con batch grande (bs=128+): MFU prefill 25–45 %; se acerca al roofline compute.

El parámetro --max-num-seqs de vLLM controla el número máximo de secuencias en el batch concurrente. Aumentarlo sube la ocupación hasta que la HBM se convierte en cuello de botella (ver DCGM_FI_PROF_DRAM_ACTIVE > 90 % sostenido).

8 · Hardware y escala: qué aplica a qué

Hardware	MIG	MPS	Time-slicing	Continuous batching	Nota
H100 SXM / H200	Sí (7 inst.)	Sí	Sí	Sí	Referencia on-prem datacenter
A100 SXM/PCIe	Sí (7 inst.)	Sí	Sí	Sí	Generación anterior; HBM2e
L40S / L40	No	Sí	Sí	Sí	Ada Lovelace; sin MIG; buen precio/VRAM
RTX 5090	No	Sí (limitado)	Sí	Sí	Consumo; sin MIG; no escala en producción
RTX 4090	No	Sí (limitado)	Sí	Sí	Consumo; 24 GB VRAM; sin MIG

La RTX 5090 y RTX 4090 ilustran el caso de hardware que no escala para multi-tenant con aislamiento: no soportan MIG, la VRAM es escasa para modelos > 7B con KV-cache amplio, y el TDP (600 W / 450 W) es alto respecto al throughput. Para inferencia en producción a escala, el 4×H100 SXM es el nodo de referencia de esta serie.

9 · Flujo de diagnóstico FinOps: del CPM alto a la causa

10 · Ejemplo numérico: impacto del continuous batching sobre el CPM

Punto de partida: Llama 70B FP8 en 4×H100 SXM, carga de 8 requests/s con 512 tokens de salida media, sin continuous batching (bs estático = 8):

Throughput observado: ~900 tok/s (decode dominante).
( \rho_{\text{efectiva}} \approx 900 / 3500 \approx 0{,}26 ).
CPM: ( 44 / (900 \times 3600 / 10^6) \approx 13{,}6\ \text{€} ).

Misma carga, activando continuous batching con --max-num-seqs 64:

Throughput observado: ~2 300 tok/s (batch dinámico rellena las gaps).
( \rho_{\text{efectiva}} \approx 2300 / 3500 \approx 0{,}66 ).
CPM: ( 44 / (2300 \times 3600 / 10^6) \approx 5{,}3\ \text{€} ).

Reducción de CPM: del 13,6 € al 5,3 €, –61 %, sin ningún cambio de hardware y sin tocar el modelo.

Los parámetros de vLLM relevantes para subir el throughput efectivo:

--max-num-seqs 64 # batch concurrente máximo
--max-num-batched-tokens 16384 # tokens totales por iteración
--enable-chunked-prefill # intercala prefill y decode

Ver también

coste-por-token-y-por-request — la identidad CPM = €/GPU-hora ÷ throughput con los datos de LiteLLM y OpenCost.
observabilidad-gpu-dcgm-llm — las doce métricas DCGM y cinco vLLM que componen la cabina de pilotaje.
anatomia-metricas-dcgm-vllm-anomalias — profundización en las métricas DCGM con anomalías documentadas en producción.
compartir-gpu-time-slicing-mps-mig — time-slicing, MPS y MIG con presupuestos de VRAM trabajados.
capacity-planning-inferencia-llm-on-premise — dimensionamiento del cluster a partir del throughput pico y la ocupación objetivo.
opencost-cost-allocation-kubernetes — cómo OpenCost calcula el ( C_{\text{GPU}} ) que entra en la identidad del CPM.
Cloud GPU: comparativa de precios, compromiso y neoclouds soberanos — el €/GPU-hora alternativo cuando la ocupación on-premise no justifica el CAPEX: precios spot y reserved de los neoclouds europeos.
TCO del cluster GPU on-premise: amortización, energía e infraestructura — de dónde sale el ( C_{\text{GPU}} ) de la identidad cuando el hierro es propio: CAPEX, amortización, energía y operación.

Fuentes

NVIDIA — DCGM Field Identifiers reference (v3.1), lista completa de DCGM_FI_* con field IDs y definiciones. https://docs.nvidia.com/datacenter/dcgm/3.1/dcgm-api/dcgm-api-field-ids.html
NVIDIA — GPU Profiling Metrics (Run:ai / DCGM), definiciones de DCGM_FI_PROF_SM_ACTIVE (1002), SM_OCCUPANCY (1003), PIPE_TENSOR_ACTIVE (1004). https://run-ai-docs.nvidia.com/self-hosted/platform-management/monitor-performance/gpu-profiling-metrics
Chowdhery et al. — PaLM: Scaling Language Modeling with Pathways (MFU definition, sección 4). arXiv 2204.02311. https://arxiv.org/abs/2204.02311
NVIDIA — Multi-Instance GPU (MIG) User Guide (perfiles H100 SXM5, particionado, aislamiento). https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
NVIDIA — Supported MIG Profiles (catálogo completo H100 80 GB). https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html
NVIDIA — Time-Slicing GPUs in Kubernetes (GPU Operator 24.9.0). https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/24.9.0/gpu-sharing.html
NVIDIA — Multi-Process Service (MPS) Overview (kernel concurrency, SM allocation). https://docs.nvidia.com/deploy/mps/latest/index.html
Kueue — Overview (sigs.k8s.io/kueue, bin-packing, cohorts, quotas). https://kueue.sigs.k8s.io/docs/overview/
vLLM Blog — vLLM v0.6.0: 2.7x Throughput Improvement and 5x Latency Reduction (continuous batching, chunked prefill). https://blog.vllm.ai/2024/09/05/perf-update.html
GMI Cloud — NVIDIA H100 GPU Pricing: 2026 Rent vs. Buy Cost Analysis. https://www.gmicloud.ai/en/blog/nvidia-h100-gpu-pricing-2026-rent-vs-buy-cost-analysis
Saxena et al. — LLM Inference Unveiled: Survey and Roofline Model Insights. arXiv 2402.16363. https://arxiv.org/abs/2402.16363

Idle on lo0 — Blog Técnico