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