Del SLO al número de GPUs: cómo dimensionar y justificar la inversión en hardware de inferencia

Tue, 16 Jun 2026 11:00:00 +0200

Notación: importes en N € o N USD (fuente denominada en dólares); decimales con coma; separador de millar con espacio fino (1\,234). Hardware de ejemplo genérico: nodos 4×H100 SXM5 80 GB. No se usa el símbolo de dólar (delimitador de fórmula).

TL;DR

Con un SLO de TTFT P99 ≤ 300 ms y ITL P99 ≤ 50 ms para un chat de producción, la utilización máxima de GPU debe quedar en ≤ 63 % en pico.
Un servicio que recibe 5 M peticiones/día con 512 tokens de entrada y 256 de salida en media genera un pico horario de ~11,600 tok/s (con factor de pico 1,8×). Con vLLM sobre H100 SXM5 (Llama-3.3 70B FP8, ~1,850 tok/s a 50 peticiones concurrentes), se necesitan ≥ 10 GPUs en pico para cumplir el SLO, que se traducen en 3 nodos 4×H100 (con headroom).
El coste all-in de esos 3 nodos es ~83 300 € al año por nodo (capex 3 años + opex base); el €/1M tokens en escenario base al 63 % de utilización es ~0,37 €.
Frente a AWS p5 on-demand (~3,90 USD/GPU-hora tras el recorte del 44 % de jun. 2025), el break-even de utilización se sitúa en ~55 %; frente a neoclouds on-demand (~2,01 USD/GPU-hora), no hay break-even factible a utilización media.
El payback del capex se produce entre 13 y 24 meses si la utilización sostenida supera el 70 %.

1. La cadena de dimensionado: de la demanda al número de GPUs

El dimensionado de una plataforma de inferencia sigue una cadena causal de cinco pasos. Cada paso tiene una fórmula; ninguno se puede saltar.

1.1 Paso 1 — Caracterizar la demanda

Parámetro	Símbolo	Ejemplo
Peticiones por día (media)	(D)	5 000 000
Tokens de entrada por petición (media)	(L_{\text{in}})	512
Tokens de salida por petición (media)	(L_{\text{out}})	256
Factor de pico (ratio pico-hora vs media)	(k_{\text{pico}})	1,8
Horas al día con tráfico significativo	(H)	16

El throughput de salida medio:

$$\dot{T}{\text{medio}} = \frac{D \times L{\text{out}}}{86,400,\text{s}} = \frac{5,000,000 \times 256}{86,400} \approx 14,815;\text{tok/s}$$

El throughput pico (hora punta):

$$\dot{T}{\text{pico}} = k{\text{pico}} \times \frac{D \times L_{\text{out}}}{H \times 3,600} = 1{,}8 \times \frac{5,000,000 \times 256}{16 \times 3,600} \approx 40,000;\text{tok/s}$$

Nota: si el perfil de tráfico tiene picos muy pronunciados (relación pico/media > 3), el dimensionado se hace para el pico y la utilización media cae; el análisis de sensibilidad de §5 cuantifica el efecto.

1.2 Paso 2 — Fijar el SLO y derivar la utilización máxima

El SLO de latencia impone un techo a la utilización de GPU. Usando teoría de colas (modelo M/G/1):

$$\rho_{\max} \approx 1 - \frac{1}{\sqrt{1 + C_{s}^{2}}} \cdot \frac{W_{\text{cola}}^{*}}{\bar{s}}$$

donde (\rho) es la utilización, (W_{\text{cola}}^{*}) el tiempo máximo de cola admisible y (\bar{s}) el tiempo medio de servicio por petición. Para el caso simplificado M/M/1 con tiempo de prefill dominante:

$$\rho_{\max} = 1 - \frac{W_{\text{cola}}^{}}{\bar{s} \cdot (1 + W_{\text{cola}}^{}/\bar{s})}$$

La tabla de referencia práctica (derivada de la fórmula de Spheron/Littles Law, 2026):

SLO TTFT P99	Utilización máxima (\rho_{\max})
200 ms	55 %
300 ms	63 %
400 ms	70 %
500 ms	75 %

Para nuestro ejemplo (SLO 300 ms P99): (\rho_{\max} = 0{,}63).

El SLO de ITL impone una restricción adicional: el motor de inferencia debe ser capaz de generar el siguiente token en ≤ 50 ms. En H100 SXM5 con vLLM y Llama-3.3 70B FP8, el ITL P50 a 50 peticiones concurrentes es ~20 ms, con P99 ~45 ms. El ITL es la restricción dominante solo cuando el batch size es muy alto (>64 secuencias) o la VRAM está casi llena.

1.3 Paso 3 — Throughput requerido y throughput por GPU

El throughput que debe servir el cluster en pico, respetando (\rho_{\max}):

$$\dot{T}{\text{requerido}} = \frac{\dot{T}{\text{pico}}}{\rho_{\max}} = \frac{40,000}{0{,}63} \approx 63,500;\text{tok/s (capacidad instalada)}$$

El throughput por GPU (benchmark de referencia, vLLM v0.18.0, Llama-3.3 70B FP8, H100 SXM5 80 GB, 50 peticiones concurrentes):

Motor	Throughput (tok/s por GPU)	TTFT P50 / P95 (50 req)	Fuente
vLLM 0.18.0	1 850	380 ms / 720 ms	Spheron benchmarks, mar. 2026
SGLang 0.5.9	1 920	360 ms / 680 ms	Spheron benchmarks, mar. 2026
TensorRT-LLM 1.2.0	2 100	340 ms / 620 ms	Spheron benchmarks, mar. 2026

Los datos de throughput corresponden al test con Llama 3.3 70B Instruct FP8, 512 tokens entrada / 256 salida, 50 peticiones concurrentes, en H100 SXM5 bare-metal. Véase el análisis de motores en comparativa motores serving Pareto.

Usamos vLLM como referencia de producción generalista: (\dot{T}_{\text{GPU}} = 1,850) tok/s.

1.4 Paso 4 — Número de GPUs y número de nodos

$$N_{\text{GPU}} = \left\lceil \frac{\dot{T}{\text{requerido}}}{\dot{T}{\text{GPU}}} \right\rceil = \left\lceil \frac{63,500}{1,850} \right\rceil = \lceil 34{,}3 \rceil = 35;\text{GPUs}$$

Con nodos 4×H100 SXM5:

$$N_{\text{nodos}} = \left\lceil \frac{N_{\text{GPU}}}{4} \right\rceil = \left\lceil \frac{35}{4} \right\rceil = 9;\text{nodos}$$

Añadimos un headroom del 15 % para fallos de hardware (tasa ~5 % anual en clusters pequeños), upgrades y picos imprevistos:

$$N_{\text{nodos, final}} = \lceil 9 \times 1{,}15 \rceil = 11;\text{nodos} \approx 44;\text{GPUs}$$

Para el ejemplo TL;DR (5 M peticiones/día con perfil de 16 h activas, k 1,8 y SLO 300 ms) el número de nodos es 11. El caso simplificado del TL;DR con k=1 y H=24 da 3 nodos; la diferencia ilustra el impacto del perfil horario.

1.5 Resumen de la cadena

2. Del sizing al coste: modelo TCO

Con (N_{\text{nodos}} = 11) nodos 4×H100 SXM5, el TCO sigue el modelo detallado en TCO on-premise GPU cluster. Aquí se replica la fórmula compacta y se aplica al cluster dimensionado.

2.1 Coste anual por nodo (escenario base)

$$C_{\text{nodo/año}} = \frac{\text{capex nodo}}{\text{años}} + \text{opex nodo/año}$$

Partida	Valor (USD / €)	Nota
Capex nodo 4×H100 (punto medio)	178 500 USD	GPUs + servidor + red + almacenamiento + rack
Amortización 3 años	59 500 USD/año ≈ 55 300 €/año	Lineal
Opex/año (escenario base, cluster 8–16 nodos)	~28 000 €/año	Energía + personal + mant. + colocación
Total anual por nodo	~83 300 €/año	—

Para 11 nodos: 915 300 €/año de coste total fijo.

2.2 Del €/nodo-año al €/GPU-hora

$$\text{EUR/GPU-hora} = \frac{C_{\text{nodo/año}}}{4;\text{GPUs} \times 8,760;\text{h} \times \rho}$$

Utilización (\rho)	EUR/GPU-hora
40 %	5,93
55 %	4,31
63 % (SLO 300 ms)	3,76
70 %	3,39
80 %	2,97
100 %	2,38

2.3 Del €/GPU-hora al €/1M tokens

$$\text{EUR/1M tokens} = \frac{\text{EUR/GPU-hora} \times 10^{6}}{\dot{T}_{\text{GPU}} \times 3,600}$$

Con (\dot{T}_{\text{GPU}} = 1,850) tok/s (vLLM, Llama-3.3 70B FP8):

Utilización	EUR/GPU-hora	EUR/1M tokens
40 %	5,93	0,891
55 %	4,31	0,647
63 % (SLO 300 ms)	3,76	0,564
70 %	3,39	0,509
80 %	2,97	0,446
100 %	2,38	0,357

La identidad completa coste/token en función del throughput y la utilización se desarrolla en coste por token y por request.

2.4 Comparación con cloud (€/1M tokens equivalente)

Para comparar, se convierte el precio cloud al equivalente €/1M tokens usando el mismo throughput de referencia ((\dot{T}_{\text{GPU}} = 1,850) tok/s):

$$\text{EUR/1M tokens (cloud)} = \frac{P_{\text{cloud}} \times 10^{6}}{1,850 \times 3,600}$$

Proveedor / Modalidad	Precio GPU-hora (USD)	EUR/GPU-hora ((1,\text{USD} \approx 0{,}93,\text{EUR}))	EUR/1M tokens equiv.
AWS p5 on-demand (post jun. 2025)	3,90	3,63	0,545
AWS p5 reserved 1 año	~2,50	2,33	0,350
CoreWeave on-demand	~2,01	1,87	0,281
CoreWeave reserved 3 años	~1,49	1,39	0,209
GCP A3 on-demand	~3,67	3,41	0,512
Azure ND H100 v5 on-demand	~6,98	6,49	0,975

Fuentes: IntuitionLabs (jun. 2026), CloudZero (jun. 2026), Spheron GPU pricing (may. 2026).

3. Break-even y payback de la inversión propia

3.1 La fórmula del break-even de utilización

El break-even de utilización (u^{*}) es la utilización a la que el coste anual on-prem por GPU-hora iguala el precio cloud:

$$u^{*} = \frac{\text{capex/año} + \text{opex/año}}{4 \times 8,760 \times P_{\text{cloud}}}$$

donde (P_{\text{cloud}}) es el precio cloud en la misma divisa que los costes on-prem.

Con el escenario base (capex/año 55 300 €, opex/año 28 000 €, total 83 300 €/nodo/año):

Referencia cloud	Precio cloud (EUR/GPU-hora)	(u^{*}) break-even
Azure on-demand (~6,49 EUR)	6,49	23 %
AWS on-demand post-recorte (~3,63 EUR)	3,63	41 %
GCP on-demand (~3,41 EUR)	3,41	44 %
CoreWeave on-demand (~1,87 EUR)	1,87	80 %
CoreWeave reserved 3a (~1,39 EUR)	1,39	>100 % (imposible)
AWS reserved 1a (~2,33 EUR)	2,33	64 %

3.2 Payback del capex

El payback es el tiempo (T_{\text{pay}}) en el que el ahorro acumulado frente al cloud iguala el capex inicial:

$$T_{\text{pay}} = \frac{\text{capex total cluster}}{(\text{coste cloud/año}) - (\text{opex on-prem/año})}$$

donde el coste cloud/año se calcula a la misma utilización sostenida.

Para el cluster de 11 nodos (capex total 11 × 178 500 USD ≈ 1 825 000 USD ≈ 1 697 000 €):

Referencia cloud	Utilización sostenida	Ahorro anual vs cloud	Payback
AWS on-demand (3,63 EUR/h)	70 %	(3,63 − 3,39 EUR) × 4 × 8760 × 0,70 × 11 nodos ≈ 63 900 €/año	~27 meses
AWS on-demand (3,63 EUR/h)	80 %	(3,63 − 2,97) × 4 × 8760 × 0,80 × 11 ≈ 203 600 €/año	~10 meses
GCP on-demand (3,41 EUR/h)	70 %	(3,41 − 3,39) × 4 × 8760 × 0,70 × 11 ≈ 5 400 €/año	~315 meses (no rentable)
Azure on-demand (6,49 EUR/h)	70 %	(6,49 − 3,39) × 4 × 8760 × 0,70 × 11 ≈ 830 000 €/año	~2 meses

El payback de 13 meses citado en estudios como Lenovo TCO 2026 corresponde a utilización ~80 % frente a hyperscalers de precio alto (Azure/AWS pre-recorte). Con los precios actuales (post junio 2025, AWS a 3,90 USD), la ventana se amplía.

3.3 Payback simple (solo capex vs cloud equivalente)

Si se omite el opex on-prem y se compara solo el capex con el ahorro bruto:

$$T_{\text{pay,simple}} = \frac{\text{capex}}{P_{\text{cloud}} \times 4 \times 8,760 \times \rho \times N_{\text{nodos}}}$$

Utilización	AWS (3,63 EUR)	Azure (6,49 EUR)
50 %	54 meses	30 meses
70 %	39 meses	22 meses
80 %	34 meses	19 meses

4. Tabla de decisión: cuándo comprar, alquilar o híbrido

La tabla siguiente es un Pareto de cinco dimensiones. No hay orden implícito entre columnas; la lectura depende de las restricciones de la organización.

Opción	EUR/GPU-hora (util. 70 %)	Capex inicial	Utilización requerida	Soberanía dato	Elasticidad pico
On-prem compra, util. ≥ 70 %	3,39	alto (178 k USD/nodo)	≥ 70 % sostenido	total	ninguna
On-prem compra, util. < 50 %	> 4,75	alto	< 50 % → pierde vs cloud	total	ninguna
Cloud EU soberano OD (Scaleway/Nebius EU)	2,00–3,59	ninguno	cualquiera	sí (UE)	total
AWS p5 on-demand (post jun. 2025)	3,63	ninguno	cualquiera	no (CLOUD Act)	total
CoreWeave on-demand	1,87	ninguno	cualquiera	parcial (US)	total
CoreWeave reserved 3 años	1,29–1,39	compromiso financiero	contrato rígido	parcial (US)	ninguna
AWS reserved 1 año	~2,17	compromiso 1 año	contrato	no (CLOUD Act)	ninguna
Híbrido on-prem base + cloud EU pico	2,50–3,39 (ponderado)	medio	base ≥ 70 %, pico elástico	sí (UE)	pico elástico

Criterios de corte previos a la tabla:

Soberanía RGPD: si los datos son personales o el sistema es de riesgo EU AI Act, CoreWeave/AWS quedan descartados antes de comparar precios.
Volumen mínimo para amortizar capex: por debajo de ~2 M tokens/día sostenidos durante 3 años, el capex on-prem no se amortiza frente a AWS on-demand.
Elasticidad de tráfico: picos >3× la base favorecen el híbrido o el cloud puro; base estable favorece el on-prem.

La frontera de Pareto coste/soberanía para datos RGPD deja tres opciones: on-prem, cloud EU soberano e híbrido. Entre ellas decide la utilización sostenida y la predecibilidad del tráfico. Véase el análisis cruzado de los cuatro ejes en on-premise soberano vs hyperscalers.

5. Análisis de sensibilidad

5.1 Sizing vs perfil horario y factor de pico

El número de GPUs crece linealmente con (k_{\text{pico}}) e inversamente con (\rho_{\max}):

$$N_{\text{GPU}} = \left\lceil \frac{D \times L_{\text{out}} \times k_{\text{pico}}}{H \times 3,600 \times \rho_{\max} \times \dot{T}_{\text{GPU}}} \right\rceil$$

Factor de pico (k)	SLO 300 ms ((\rho_{\max}=0{,}63))	SLO 500 ms ((\rho_{\max}=0{,}75))
1,2	8 GPUs (2 nodos)	6 GPUs (2 nodos)
1,8	12 GPUs (3 nodos)	10 GPUs (3 nodos)
2,5	16 GPUs (4 nodos)	13 GPUs (4 nodos)
3,5	22 GPUs (6 nodos)	18 GPUs (5 nodos)

(Ejemplo simplificado a 5 M pet/día con H=24 para ilustrar la sensibilidad al factor de pico)

Un factor de pico 3,5× triplica el número de nodos respecto a k=1,2 manteniendo el mismo SLO. Dimensionar hardware para (k > 2{,}5) deja GPUs paradas el 70 %+ del tiempo; el cloud de pico es más eficiente a partir de ese umbral.

5.2 Break-even vs utilización sostenida

$$u^{*} = \frac{83,300}{4 \times 8,760 \times P_{\text{cloud}}}$$

Precio cloud (EUR/GPU-hora)	(u^{*}) break-even	Escenario
6,49 (Azure OD)	23 %	On-prem gana casi siempre
3,63 (AWS OD)	41 %	On-prem gana si util. > 41 %
3,41 (GCP OD)	44 %	—
2,33 (AWS reserved 1a)	64 %	On-prem gana si util. > 64 %
1,87 (CoreWeave OD)	80 %	Difícil de alcanzar en producción
1,39 (CoreWeave reserved 3a)	>100 %	On-prem nunca cierra brecha

5.3 Break-even vs precio de energía

La energía representa el 6–11 % del TCO total. Su impacto en el break-even es moderado:

Precio energía (EUR/kWh)	Opex energía/año por nodo	EUR/GPU-hora (70 % util.)	(u^{*}) vs AWS OD
0,034 (PPA solar)	1 604 €	3,22	38 %
0,116 (industrial ES, base)	5 475 €	3,39	41 %
0,200 (tarifa alta)	9 437 €	3,57	43 %

La diferencia entre el escenario más barato y el más caro es de solo 5 puntos porcentuales en el break-even. La variable que mueve la aguja es la utilización, no la energía.

5.4 Break-even vs crecimiento de la demanda

Si la demanda crece a una tasa anual (g), la utilización media del cluster (dimensionado para el año 1) sube con el tiempo hasta que se satura y hay que ampliar:

$$\rho(t) = \rho_{0} \times (1 + g)^{t}$$

Crecimiento anual (g)	Tiempo hasta saturación ((\rho \to 100,%))	Decisión
10 %	~11 años	Compra cómoda
30 %	~4 años	Compra con revisión a 3 años
60 %	~2 años	Híbrido: base + cloud elástico
>100 %	<1 año	Cloud puro hasta estabilización

Para crecimientos >30 % anual, la estrategia de compra-sola implica sobredimensionar para el pico futuro o re-comprar hardware en ciclos cortos. El híbrido (base on-prem + cloud para crecimiento) minimiza el capex en riesgo.

5.5 Headroom: el coste del margen de seguridad

El headroom del 15 % en (N_{\text{nodos}}) equivale a tener ~1,6 nodos adicionales de media. Su coste anual es:

$$C_{\text{headroom}} = 0{,}15 \times 83,300;\text{EUR/nodo/año} \times N_{\text{nodos,base}} \approx 12,500 \times 9 = 112,500;\text{EUR/año}$$

Este coste se justifica por:

Tasa de fallo GPU ~5 % anual (en clusters pequeños, documentada por Introl, abr. 2026)
Tiempo de reposición 2–8 semanas (según disponibilidad de mercado)
Picos imprevistos hasta un 20 % sobre el estimado

Si el servicio puede degradarse gracefully (reducción de SLO TTFT de 300 ms a 500 ms en pico extremo), el headroom se puede reducir al 10 %, con un ahorro de ~37 500 EUR/año.

6. Mapa de sensibilidad: €/GPU-hora y break-even en dos ejes

La tabla siguiente cruza utilización y escenario de opex, mostrando el EUR/GPU-hora all-in (escenario base, capex/año 55 300 €):

	Opex bajo (13 000 €/año)	Opex base (28 000 €/año)	Opex alto (75 000 €/año)
Util. 40 %	4,74	5,93	9,06
Util. 55 %	3,45	4,31	6,59
Util. 63 %	3,01	3,76	5,75
Util. 70 %	2,71	3,39	5,18
Util. 80 %	2,37	2,97	4,54
Util. 100 %	1,90	2,38	3,63

El cruce con el precio cloud (AWS OD: 3,63 EUR):

Escenario opex bajo: break-even a ~38 % de utilización
Escenario opex base: break-even a ~41 % de utilización
Escenario opex alto: break-even a ~53 % de utilización

La palanca más grande para reducir el break-even no es el capex del hardware sino el opex (especialmente personal y colocación). Véase el análisis de utilización como palanca FinOps en utilización GPU como FinOps.

7. Integración con el resto de la cadena FinOps

El dimensionado de §1 determina el número de nodos; el TCO de §2 da el coste/hora; la comparación de §3 da el break-even. Estos tres números alimentan directamente los demás instrumentos de la serie:

Instrumento	Input de este artículo	Output
GuideLLM — validación SLO bajo carga	SLO TTFT/ITL P99 del paso 2	Confirmación experimental del throughput real por GPU
Capacity planning inferencia on-premise	Perfil de demanda y N GPUs del paso 4	Política de escalado y autoscaling triggers
Coste por token y por request	EUR/GPU-hora del paso §2.2	EUR/1M tokens por modelo y batching
Cloud GPU commitment y spot	Precios cloud de la tabla §2.4	Optimización del tier cloud complementario
On-premise soberano vs hyperscalers	Break-even de §3	Decisión final compra/alquiler incluyendo eje soberanía
TCO on-premise GPU cluster	Capex y opex de §2.1	Modelo TCO detallado con todas las partidas
Utilización GPU como FinOps	Utilización objetivo del paso 2	Palancas de scheduling para subir la utilización real

Fuentes

Spheron · LLM Inference SLO Engineering: TTFT, ITL, and P99 Latency Budgets for Production AI (2026) — https://www.spheron.network/blog/llm-inference-slo-ttft-itl-latency-budget-guide-2026/
Spheron · vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks (2026) — https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks/
Spheron · GPU Cloud Pricing 2026: H100 from 1.03 USD/hr, B200 from 2.12 USD/hr — https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/
Spheron · LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even Analysis — https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/
MLPerf Inference v5.1 — Red Hat: 5 777 tok/s (offline) en Llama 3.1-8B FP8 en H100 — https://www.redhat.com/en/blog/efficient-and-reproducible-llm-inference-red-hat-mlperf-inference-v51-results
MLPerf Inference v6.0 Results Explained: GPU Performance Rankings for AI Workloads (2026) — https://www.spheron.network/blog/mlperf-inference-v6-benchmark-results-2026/
IntuitionLabs · H100 Rental Prices Compared: 1.49–6.98 USD/hr Across 15+ Cloud Providers (2026) — https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison
CloudZero · Cloud GPU Pricing Comparison: AWS vs Azure vs GCP For AI Workloads (2026) — https://www.cloudzero.com/blog/cloud-gpu-pricing-comparison/
Lenovo Press · On-Premise vs Cloud: Generative AI Total Cost of Ownership (2026 Edition) — https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition
Introl · GPU Infrastructure TCO Model: 5-Year Cost Analysis for Enterprise AI (abr. 2026) — https://introl.com/blog/gpu-infrastructure-tco-5-year-cost-model
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
Red Hat · 233 % 3-year ROI and 13 months to payback with Red Hat AI (feb. 2026) — https://www.redhat.com/en/blog/233-3-year-return-investment-and-13-months-payback-red-hat-ai
VentureBeat · 5 % GPU utilization: the 401 billion USD AI infrastructure problem — https://venturebeat.com/infrastructure/5-gpu-utilization-the-401-billion-ai-infrastructure-problem-enterprises-cant-keep-ignoring/
DZone · Queueing Theory for LLM Inference — https://dzone.com/articles/queueing-theory-for-llm-inference
GuideLLM · Evaluate LLM deployments for real-world inference (Red Hat Developer, jun. 2025) — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference

Roi on lo0 — Blog Técnico