---
title: "Del SLO al número de GPUs: cómo dimensionar y justificar la inversión en hardware de inferencia"
url: https://blog.lo0.es/posts/dimensionar-justificar-inversion-gpu/
markdown: https://blog.lo0.es/posts/dimensionar-justificar-inversion-gpu/index.md
lang: es
date: 2026-06-16
lastmod: 2026-06-17
author: "José Manuel Román"
description: "Cadena de dimensionado completa de la demanda al número de nodos 4×H100 SXM: fórmulas paso a paso desde el SLO (TTFT/ITL P99) hasta el throughput pico requerido, pasando por el TCO, el €/1M tokens y el break-even frente a cloud. Con tabla de sensibilidad y tabla de decisión comprar-alquilar-híbrido."
tags: ["finops","sizing","capacity-planning","roi","break-even","gpu","sintesis","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/slo-to-number-of-gpus-sizing-justifying-inference-hardware/index.md
---

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


> 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](https://blog.lo0.es/posts/comparativa-motores-serving-pareto/index.md).

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

> **Diagrama:** Cadena de dimensionado: demanda y SLO derivan throughput pico, que dividido entre throughput por GPU da el número de GPUs y de nodos — [verlo en la versión HTML](https://blog.lo0.es/posts/dimensionar-justificar-inversion-gpu/)

---

## 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](https://blog.lo0.es/posts/tco-on-premise-gpu-cluster/index.md). 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](https://blog.lo0.es/posts/coste-por-token-y-por-request/index.md).

### 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 %** |

> **Diagrama:** Break-even on-prem vs cloud: la curva del on-prem baja con la utilizacion y cruza AWS on-demand al 41 por ciento, GCP al 44 por ciento y CoreWeave on-demand al 80 por ciento — [verlo en la versión HTML](https://blog.lo0.es/posts/dimensionar-justificar-inversion-gpu/)

### 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:**
1. **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.
2. **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.
3. **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](https://blog.lo0.es/posts/on-premise-soberano-vs-hyperscalers-datos/index.md).

---

## 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](https://blog.lo0.es/posts/utilizacion-gpu-como-finops/index.md).

---

## 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](https://blog.lo0.es/posts/guidellm-validacion-slo-bajo-carga/index.md) | SLO TTFT/ITL P99 del paso 2 | Confirmación experimental del throughput real por GPU |
| [Capacity planning inferencia on-premise](https://blog.lo0.es/posts/capacity-planning-inferencia-llm-on-premise/index.md) | Perfil de demanda y N GPUs del paso 4 | Política de escalado y autoscaling triggers |
| [Coste por token y por request](https://blog.lo0.es/posts/coste-por-token-y-por-request/index.md) | EUR/GPU-hora del paso §2.2 | EUR/1M tokens por modelo y batching |
| [Cloud GPU commitment y spot](https://blog.lo0.es/posts/cloud-gpu-commitment-spot-neoclouds/index.md) | Precios cloud de la tabla §2.4 | Optimización del tier cloud complementario |
| [On-premise soberano vs hyperscalers](https://blog.lo0.es/posts/on-premise-soberano-vs-hyperscalers-datos/index.md) | Break-even de §3 | Decisión final compra/alquiler incluyendo eje soberanía |
| [TCO on-premise GPU cluster](https://blog.lo0.es/posts/tco-on-premise-gpu-cluster/index.md) | Capex y opex de §2.1 | Modelo TCO detallado con todas las partidas |
| [Utilización GPU como FinOps](https://blog.lo0.es/posts/utilizacion-gpu-como-finops/index.md) | 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