English · Español
02 — Economía del Cluster¶
🇪🇸 Una corrida de pretraining (pretraining) se decide en cuatro variables: TFLOPs por GPU, $/hora, MFU real y coste de comunicación. Si no sabes calcular el coste en dólares antes de lanzar, no entiendes el experimento.
La economía de los LLM frontera corre sobre tres SKUs de GPU y ~cinco nubes. La aritmética del coste por corrida es simple, los gotchas no.
Los SKUs de referencia (mediados de 2024)¶
| GPU | HBM | FP32 TFLOP/s | BF16 TFLOP/s (tensor) | FP8 TFLOP/s | NVLink BW | TDP | Precio de lista |
|---|---|---|---|---|---|---|---|
| A100 80GB | 80 GB HBM2e | 19.5 | 312 | — | 600 GB/s | 400 W | $10–15k (usadas) |
| H100 SXM5 | 80 GB HBM3 | 67 | 989 | 1979 | 900 GB/s | 700 W | $25–40k |
| H200 SXM5 | 141 GB HBM3e | 67 | 989 | 1979 | 900 GB/s | 700 W | $30–45k |
| B200 | 192 GB HBM3e | ~80 | ~2250 | ~4500 | 1800 GB/s | 1000 W | $40–60k |
(Fuentes: datasheet de NVIDIA H100, anuncio de NVIDIA H200 nov 2023, datasheet de B200 Blackwell mar 2024.)
Cambios clave: - A100 → H100: 3.2× throughput en bf16, 1.5× BW de NVLink. - H100 → H200: mismo cómputo, 1.76× HBM (80 → 141 GB), crítico para acomodar modelos de 70B+ por dispositivo. - H200 → B200: ~2.3× throughput en bf16, 2× NVLink, 35% más HBM. Envíos en volumen a finales de 2024 / inicios de 2025.
$/GPU-hora en la nube (spot vs on-demand, mediados de 2024)¶
| GPU | Proveedor | On-demand $/h | Spot $/h (cuartil más bajo) | Notas |
|---|---|---|---|---|
| A100 80GB | Lambda Labs | $1.79 | $1.10 | Single-GPU reservada |
| A100 80GB | RunPod community | $1.89 | $0.79 | Disponibilidad spot irregular |
| A100 80GB | vast.ai | $1.30–2.00 | $0.40–0.80 | Varianza amplia, más barata si seleccionas |
| H100 SXM5 | Lambda Labs | $3.29 | $2.49 | Nodos de 8× |
| H100 SXM5 | CoreWeave | $4.25 | — | Solo on-demand |
| H100 PCIe | RunPod community | $2.69 | $1.99 | PCIe ~70% del throughput de SXM5 |
| H200 SXM5 | Lambda Labs | $3.99 | — | Nueva, escasa |
(Fuentes: páginas de precios de proveedores en 2024-06. Los precios spot fluctúan ±30% intra-semana.)
Spot vs on-demand: spot puede ser recuperado por la nube con <2 min de aviso. Para la única corrida de 24 horas de X1, este es el principal riesgo. Mitigaciones:
1. Checkpoint cada 30 min (coste: ~5% del throughput).
2. Flag --resume-from-latest en el trainer.
3. Cron de un watchdog que auto-relanza si la instancia muere.
Para una corrida multi-día de 8-GPU H100, spot rara vez es usable — la probabilidad de que cualquier nodo sea reclamado a lo largo de la corrida se acerca a 1. Los laboratorios frontera usan capacidad reservada con 30-50% de descuento vs on-demand.
MFU: la métrica que importa¶
MFU = Model FLOPs Utilization = (FLOPs/s sostenidos del modelo) / (FLOPs/s pico del hardware).
El paper de Chinchilla reportó MFU ≈ 0.45 en TPUv4. Las corridas de entrenamiento de laboratorios frontera típicamente alcanzan:
| Config | MFU | Fuente |
|---|---|---|
| GPT-3 (V100s, fp32) | ~0.15 | Brown 2020 |
| PaLM (TPUv4) | 0.46 | Chowdhery 2022 |
| MT-NLG (A100 + Megatron) | 0.30 | Smith 2022 |
| Llama-2 (A100 + Megatron) | 0.40 | Touvron 2023b |
| Llama-3 (H100 + custom) | 0.41 | Meta 2024 (model card) |
| Mosaic LLM Foundry, A100 | 0.50 | README de mosaicml/llm-foundry |
¿Por qué MFU no es 1.0?
- Ancho de banda de memoria. La mayoría de ops en un bloque transformer son memory-bound sobre aceleradores modernos (la utilización de BW, no la de FLOP, es el cuello de botella para batches pequeños).
- Overhead de comunicación. All-reduce y all-gather toman tiempo en el que la GPU no está haciendo matmul.
- Burbujas de pipeline. Los schedules de PP tienen periodos síncronos de "burbuja".
- Ineficiencia de kernel. Los ops puros de PyTorch dan 30-60% MFU; FlashAttention-2 +
torch.compilelo llevan a 40-50%; Megatron + Transformer Engine hand-tuneados llegan a 50-60%.
Objetivo de MFU del lab de X1: 0.40 en 1× A100 80GB con FlashAttention-2 + bf16 + torch.compile. Menos es un bug; 0.45+ es un stretch.
La fórmula del coste¶
Para un único modelo decoder-only denso:
donde: - \(N\) = parámetros (excluyendo embeddings) - \(D\) = tokens de entrenamiento - \(G\) = número de GPUs - \(P\) = TFLOP/s pico bf16 por GPU (× 3600 para por-hora) - \(\text{precio/h}\) = $-por-GPU-hora
Ejemplo desarrollado 1: lab 00 de X1¶
\(N = 5 \times 10^7\), \(D = 4.3 \times 10^{10}\), \(G = 1\), \(P = 312 \times 10^{12}\) FLOP/s, MFU = 0.40, precio = $1.10/h (A100 80GB spot en Lambda).
Tiempo = \(6 \cdot 5 \times 10^7 \cdot 4.3 \times 10^{10} / (0.40 \cdot 1 \cdot 312 \times 10^{12})\) = \(1.29 \times 10^{19} / 1.25 \times 10^{14}\) = \(1.03 \times 10^5\) s = 28.7 horas.
Coste = \(28.7 \times \$1.10 = \$31.6\).
Así que lab 00 es "1× A100 80GB spot a \(1.10/h durante ~24-29 horas = ~\)26-32." Tope duro $35 con buffer de $3-9.
Ejemplo desarrollado 2: una corrida 7B compute-óptima de Chinchilla¶
\(N = 7 \times 10^9\), \(D = 1.4 \times 10^{12}\), \(G = 1024\) H100, \(P = 989 \times 10^{12}\), MFU = 0.45, precio = $2.49/h (H100 spot Lambda × 1024).
Tiempo = \(6 \cdot 7 \times 10^9 \cdot 1.4 \times 10^{12} / (0.45 \cdot 1024 \cdot 989 \times 10^{12})\) = \(5.88 \times 10^{22} / 4.56 \times 10^{17}\) = \(1.29 \times 10^5\) s × por-GPU; dividido por paralelo-1024... espera — la fórmula asume escalado ideal. Vuelvo a hacerlo:
FLOPs totales necesarios: \(C = 6ND = 5.88 \times 10^{22}\). FLOP/s del cluster: \(G \cdot \text{MFU} \cdot P = 1024 \cdot 0.45 \cdot 989 \times 10^{12} = 4.56 \times 10^{17}\) FLOP/s. Tiempo: \(C / (\text{FLOP/s del cluster}) = 5.88 \times 10^{22} / 4.56 \times 10^{17} = 1.29 \times 10^5\) s ≈ 35.8 horas.
Hmm — eso es un día y medio, no 25 días. Permíteme reconciliar contra el número reportado de Llama-2 7B-sobre-2T-tokens (Touvron 2023b): "184k A100-horas". \(2T / 1.4T = 1.43\), así que 7B-sobre-1.4T-tokens ≈ 130k A100-horas.
130k A100-horas / 1024 GPUs ≈ 127 horas ≈ 5 días sobre 1024 A100s. Mi número de H100 dice 36 horas, lo cual es aproximadamente correcto porque los H100 son 3× más rápidos (y el cálculo fue sobre 1024 H100s, no A100s). Cross-check: 36h × 3 ≈ 108h ≈ 4.5 días sobre A100s ✓ (coincide con Llama-2 dentro de tolerancia).
Coste a \(2.49/h × 1024 GPUs × 36 horas = **~\)92k. Añade 10% de buffer para spot reclaims y ablaciones = ~$100k**.
Eso es el 7B compute-óptimo Chinchilla. La mayoría de 7B modernos se sobre-entrenan a 2T+ tokens (camino Llama-⅔), a ~\(200k–\)1M de cómputo dependiendo del descuento del cluster.
Ejemplo desarrollado 3: la aritmética del 7B-por-$1M¶
La aritmética pedida por el usuario "entrena 7B durante 1.4T tokens con MFU 0.45 en 1024×H100 = ~25 días = ~$1M a $0.04/H100-hora spot":
Lo hago con los números estipulados por el usuario (que asumen $0.04/H100-hora — eso es precio de capacidad reservada de hyperscaler, no spot retail):
- FLOP/s del cluster: \(1024 \cdot 0.45 \cdot 989 \times 10^{12} = 4.56 \times 10^{17}\)
- C = \(6 \cdot 7 \times 10^9 \cdot 1.4 \times 10^{12} = 5.88 \times 10^{22}\)
- Tiempo = \(5.88 \times 10^{22} / 4.56 \times 10^{17} = 1.29 \times 10^5\) s = 35.8 h.
Hmm — sale 36 h, no 25 días. La cifra de "25 días" asume o bien (a) MFU 0.05, o (b) sobre-entrenamiento a ~15T tokens, o © cluster mucho más pequeño.
Si en su lugar escalamos a 1.4T tokens sobre 256 H100s (más típico de un laboratorio no-frontera): - Tiempo = \(5.88 \times 10^{22} / (256 \cdot 0.45 \cdot 989 \times 10^{12}) = 5.88 \times 10^{22} / 1.14 \times 10^{17}\) = \(5.16 \times 10^5\) s ≈ 143 h ≈ 6 días. - Coste a \(2.49/h spot × 256 × 143 = **\)91k. A \(0.04/h reserved-rate × 256 × 143 = **\)1.5k (claramente escala equivocada — $0.04 es equivalente por-segundo o un descuento de enterprise pesado).
La lección: la cifra de $1M-por-7B ampliamente citada asume sobre-entrenamiento a ~15T tokens y/o precios spot retail, no el óptimo Chinchilla de 1.4T. La aritmética exacta es:
| Escenario | Tokens | GPUs | $/h/GPU | Tiempo | Coste |
|---|---|---|---|---|---|
| 7B compute-óptimo Chinchilla, 256× H100 spot retail | 1.4T | 256 | $2.49 | 6 d | $92k |
| 7B forma-Llama-2, 1024× A100 spot retail | 2T | 1024 | $1.10 | 8 d | $216k |
| 7B forma-Llama-3, 2048× H100 spot retail | 15T | 2048 | $2.49 | 16 d | $2.0M |
| 7B Chinchilla, 1024× H100 reservado (hyperscaler) | 1.4T | 1024 | $1.00 (est.) | 36 h | $37k |
El "$1M por un 7B" es la cifra de orden-de-magnitud para un 7B moderno sobre-entrenado a precios spot retail. Los hyperscalers de capacidad reservada (un cluster interno en Anthropic / Meta / Google) son 3-10× más baratos.
Coste de ancho de banda y comunicación¶
El cómputo es la mitad de la historia. La otra mitad es mover tensores entre GPUs.
Intra-nodo (NVLink/NVSwitch): - A100 NVLink 3: 600 GB/s por GPU (300 GB/s cada dirección). - H100 NVLink 4: 900 GB/s por GPU. - B200 NVLink 5: 1800 GB/s por GPU.
Inter-nodo (Infiniband): - NDR400 IB: 400 Gb/s = 50 GB/s por puerto. Un solo puerto: ~50 GB/s. Multi-puerto: hasta 400 GB/s con topología rail-optimizada. - Ethernet (RoCE v2): hasta 400 Gb/s comparables, con peor tail latency.
El ratio de comunicación. Para un modelo con \(N\) parámetros y un grupo TP de tamaño \(T\): - All-reduce de cada paso (sync de gradientes, DDP): \(\sim 2 N\) bytes (fp16) movidos por GPU. - All-gather de cada paso (forward TP): \(\sim N/T\) bytes × num-capas por paso.
Implicación. Tensor parallel debe mantenerse dentro de un dominio NVLink (1 nodo = típicamente 8 GPUs). Pipeline parallel puede cruzar nodos porque PP solo envía activaciones de micro-batch en las capas frontera de PP. ZeRO/FSDP es más pesado en comunicación que DDP y se beneficia de NVLink.
Para Llama-2 70B sobre 1024 A100s: TP=8 (intra-nodo), PP=8 (cross-nodo), DP=16 (externo). La config "DP × TP × PP" 3D-paralelismo.
Coste de energía (a menudo olvidado)¶
TDP de A100: 400 W. TDP de H100: 700 W. Una corrida de 24h en single-GPU A100 = 9.6 kWh ≈ ~\(1 a tarifas residenciales o ~\)0.40 a tarifas de centro de datos. Para el lab 00 de X1, la energía es despreciable vs el precio del cómputo.
Para una corrida de 8-GPU H100 de 24h: 700 W × 8 × 24 = 134 kWh ≈ $13. Todavía ~5% de la factura de cómputo.
Para una corrida de 1024-GPU H100 de un mes: 700 W × 1024 × 30 × 24 = 516 MWh ≈ ~$50k a $0.10/kWh. Esto está en el orden del 5-10% de la factura de cómputo para una corrida a escala frontera, y es por lo que los hyperscalers se preocupan por el PUE y por dónde construyen centros de datos.
(Estimaciones de "huella de carbono del entrenamiento" de laboratorios frontera: GPT-3 = ~552 t CO₂, BLOOM-176B = ~50 t CO₂. Fuente: Luccioni et al. 2022. Bloom fue más bajo por la red nuclear francesa.)
Almacenamiento y egress¶
Una corrida de entrenamiento frontera lee ~10-15TB de datos tokenizados y escribe ~1-10TB de checkpoints. Costes de almacenamiento y egress:
- Almacenamiento hot S3 / GCS: $0.02/GB-mes. 10 TB-mes = $200.
- Egress al nodo GPU: típicamente gratuito dentro de la misma región/nube, $0.08/GB cross-región. Co-localiza siempre.
- Escrituras de checkpoint durante una corrida multi-día: 10 checkpoints × 100 GB = 1 TB total escrito. $20 a tarifas estándar.
Para el lab 00 de X1: 200 GB de shards tokenizados de FineWeb-Edu + 5 GB de checkpoints. Coste de almacenamiento: ~$3 sobre 24 h. Por debajo de la línea.
Qué cambia a >10B parámetros¶
A ~10B parámetros, la memoria single-GPU se agota: - 10B parámetros × 2 bytes (bf16) = 20 GB de pesos - ×2 (Adam m, v) = 60 GB de estado del optimizador en fp32 ≈ 80 GB total (el optimizador Adam en fp32 necesita 4N + 4N + 4N = 12N bytes para params/m/v en copia maestra fp32; con precisión mixta y optimizadores de 8-bit esto baja a ~6N, pero la aritmética está dominada) - Activaciones: ~5-20 GB dependiendo de batch y seq - Suma: ~100+ GB. No cabe en H100 80 GB.
En este punto, pipeline parallel se vuelve obligatorio. La configuración típica: - TP=8 intra-nodo (NVLink puede llevar el all-gather). - PP=8 a través de nodos (Infiniband maneja los envíos frontera raros). - ZeRO-1 en el exterior (shardear estado del optimizador a través de réplicas DP).
¿Por qué no ZeRO-3 + DDP solo? Porque ZeRO-3 requiere all-gather de parámetros en cada forward step. Para 70B parámetros, son 140 GB de all-gather de pesos por step por rank DP, lo cual satura incluso NVLink y mata el MFU. TP + PP mantiene la comunicación por step local (pequeños envíos de activaciones a través de fronteras PP, pequeños all-reduces dentro de grupos TP).
El punto óptimo para ≥10B: TP + PP + ZeRO-1 (paralelismo 3D), MFU ~0.4 si está afinado.
Para X1 solo corremos 50M, así que single-GPU está bien. Pero la aritmética de coste que haces en tu cabeza para 7B+ es la aritmética de arriba.
Siguiente: theory/03-data-pipelines-at-scale.md.