Skip to content

English · Español

02 — Análisis profundo de H100 / H200 / Blackwell

🇪🇸 La H100 es el chip de la era 2023-2024; la H200 amplía la memoria; Blackwell (B100/B200) es la generación 2025. Aquí desmenuzamos qué cambia y por qué importa.

Por qué la H100 merece su propia página

La H100 es el chip sobre el que se entrenaron la mayoría de los modelos de clase GPT-4, Claude 3, Llama 3 y Gemini 1.x. Si no puedes razonar sobre una H100, no puedes razonar sobre el coste o duración del entrenamiento frontier. Esta página es el modelo mecánico.

Modelo mental del die-shot

Una H100 SXM5 contiene:

  • 132 Streaming Multiprocessors (SMs), organizados en 8 GPCs (Graphics Processing Clusters).
  • Cada SM tiene:
  • 128 cores CUDA FP32 (4 sub-particiones × 32).
  • 64 cores INT32, 64 cores FP64.
  • 4 Tensor Cores de 4.ª generación (uno por sub-partición). Aquí es donde viven los FLOPS.
  • Banco de registros de 256 KB.
  • 228 KB de memoria L1/shared unificada (división configurable).
  • 50 MB de cache L2 compartida.
  • 5 stacks HBM3 × 16 GB = 80 GB en total, en un bus de memoria de 5120 bits → 3.35 TB/s.
  • NVLink 4: 18 lanes × 50 GB/s = 900 GB/s off-chip hacia GPUs pares.

[fuente: NVIDIA H100 Tensor Core GPU Architecture Whitepaper 2022]

El resumen listo-para-entrevista: 132 SMs × 4 Tensor Cores × throughput FP8 a boost clock ≈ 1979 TF/s pico FP8 denso; 80 GB HBM3 a 3.35 TB/s; 900 GB/s NVLink hacia pares en una DGX H100.

Tensor Cores: la 4.ª generación

Un Tensor Core es, mecánicamente, una pequeña unidad de multiplicación de matrices. En la H100, cada Tensor Core puede hacer, por ciclo:

  • Un multiply-accumulate de matrices 4×8 × 8×8 en FP16 / BF16 → 256 FLOPs.
  • La misma forma en FP8 → 512 FLOPs (2× la tasa porque FP8 tiene la mitad del ancho).

Hay 4 Tensor Cores por SM × 132 SMs = 528 en total. A ~1.83 GHz boost: 528 × 512 × 1.83e9 ≈ 4.9e14 FP8 FLOP/s = 490 TF/s por "issue de instrucción". Con dual-issue y el nuevo camino del transformer engine FP8, NVIDIA publicita 1979 TF/s FP8 denso como pico. No te obsesiones con la derivación exacta; recuerda el número titular.

FP8, el transformer engine y numérica

La H100 introdujo dos formatos FP8:

Formato Signo Exponente Mantisa Rango Uso típico
E4M3 1 4 3 ±448 Activaciones forward, pesos
E5M2 1 5 2 ±57344 Gradientes backward (necesita más rango)

[fuente: Micikevicius et al. 2022, FP8 Formats for Deep Learning, arXiv:2209.05433]

El Transformer Engine es una librería de software de NVIDIA (transformer_engine) que:

  1. Mantiene factores de escala por tensor en FP32.
  2. Castea dinámicamente activaciones y pesos entre FP8 (E4M3 para fwd, E5M2 para bwd) en los lugares adecuados.
  3. Re-cuantiza entre capas para que el rango FP8 se use eficientemente.

El punto es que FP8 por sí solo es demasiado estrecho para entrenar; necesitas una política de escala. El Transformer Engine envía esa política, validada para entrenamiento de transformer. Esto es lo que te da el 2× de speedup sobre BF16 sin pérdida de calidad.

Otros formatos que debes conocer:

  • TF32 (TensorFloat-32): un formato de entrada FP32 introducido en Ampere con la precisión de FP16 (mantisa de 10 bits) y el rango de FP32. Drop-in para matmul FP32 en cuDNN. Prácticamente obsoleto en la H100 a favor de BF16/FP16/FP8.
  • BF16 (bfloat16): mismo rango que FP32, mantisa truncada a 7 bits. El formato de entrenamiento por defecto en la era Fase 17-22. Lento en H100 frente a FP8 (la mitad del throughput) pero trivialmente seguro — sin necesidad de política de escala.

Regla de decisión: - Inferencia: FP8 (o INT8 con cuidado) en H100; FP16/BF16 en A100. - Entrenamiento: BF16 con pesos maestros FP32 en A100; FP8 con el Transformer Engine en H100.

Jerarquía de memoria a escala H100

Nivel Tamaño Bandwidth Latencia (aprox.)
Banco de registros 256 KB / SM ~20 TB/s/SM 1 ciclo
L1/SMEM 228 KB / SM ~33 TB/s/SM ~30 ciclos
Cache L2 50 MB (chip entero) ~5.5 TB/s ~200 ciclos
HBM3 80 GB 3.35 TB/s ~500 ns
NVLink peer 80 GB en el peer 900 GB/s agregado ~pocos µs

[fuente: NVIDIA H100 Whitepaper; estudio de microbenchmarks Luo et al. 2023]

Idea clave: el bandwidth es el cuello de botella para inferencia, el cómputo para entrenamiento.

  • Inferencia, batch=1, decode: relees todos los pesos desde HBM por cada token. Un modelo de 70B en FP8 son 70 GB; 70 GB / 3.35 TB/s ≈ 20 ms/token ⇒ techo de ~50 tok/s en una sola H100. Estás limitado por bandwidth; los FLOPS están en su mayoría ociosos.
  • Entrenamiento, batch grande: cada peso se reutiliza sobre miles de tokens por microbatch; la intensidad aritmética supera los 295 FLOP/byte; pasas a estar limitado por cómputo y los FLOPS FP8 importan.

Por esto el batching importa tanto al servir — convierte un workload limitado por bandwidth en uno limitado por cómputo.

Una sola H100 tiene 18 lanes NVLink 4 × 50 GB/s = 900 GB/s de bandwidth off-chip, distinto de PCIe.

NVSwitch es el fabric en placa que conecta 8 H100s en un servidor DGX H100 de modo que cada GPU ve los 900 GB/s completos a cada otra GPU (vs. el NVSwitch de la A100, que daba 600 GB/s/peer). Esto significa que un AllReduce de 8 GPUs sobre 1 GB tarda (ver §03 para la matemática):

\[ T_{\text{AllReduce}} = \frac{2(N-1)}{N} \cdot \frac{D}{\text{BW}} = \frac{2 \cdot 7}{8} \cdot \frac{1\,\text{GB}}{900\,\text{GB/s}} \approx 1.94 \text{ ms}. \]

Una DGX H100 tiene 8 GPUs, 4 NVSwitches, y puertos externos NVLink-Network que conectan con otras cajas DGX vía el NVLink Switch System — extendiendo el dominio de 900 GB/s a 32 o 256 GPUs.

MIG — Multi-Instance GPU

MIG te permite particionar una sola H100 en hasta 7 instancias aisladas, cada una con su porción de SMs, L2 y HBM. Usado para:

  • Multi-tenancy en serving (cada cliente obtiene una porción garantizada).
  • Aislamiento de fallos (un kernel descontrolado no puede asfixiar a los vecinos).
  • Workloads de inferencia que no llenan una H100 entera.

Cada instancia recibe ~10 GB de HBM y ~18 SMs. No se usa en entrenamiento (el entrenamiento quiere el chip completo).

H200 — mismo cómputo, mucha más memoria

La H200 (envíos a mediados de 2024) es eléctricamente idéntica a la H100 en cómputo. Lo que cambia:

  • 141 GB HBM3e (vs. 80 GB HBM3 en H100). 76% más.
  • 4.8 TB/s de bandwidth (vs. 3.35 TB/s). 43% más alto.
  • Mismo NVLink 4, mismo TDP (700 W), mismo factor de forma (reemplazo drop-in para H100 SXM5).

[fuente: NVIDIA H200 Datasheet 2024]

Por qué importa:

  • Un modelo de 70B FP8 cabe en una sola H200 con espacio para activaciones y KV cache. En una H100, necesitabas paralelismo de modelo. Esto colapsa dramáticamente la complejidad del serving.
  • Los workloads de inferencia limitados por KV-cache (contexto largo, batch grande) escalan aproximadamente con el bandwidth HBM → ~43% más tokens/sec.

La H200 es un producto de bandwidth de memoria, no un producto de cómputo. Los vendors que poseen flotas de H100 a menudo actualizan a H200 específicamente para serving.

B100 / B200 / GB200 (Blackwell) — vista previa

Anunciado en GTC 2024, envíos finales de 2024 / 2025.

  • B200 es un chip de dos dies (dos dies a límite reticular fusionados con un link die-to-die de 10 TB/s, NV-HBI). Cuenta como una sola GPU.
  • ~2.25 PF FP16 denso / ~4.5 PF FP8 / ~9 PF FP4 (Blackwell introduce FP4 con un Transformer Engine de 2.ª generación).
  • 192 GB HBM3e a 8 TB/s.
  • NVLink 5: 18 lanes × 100 GB/s = 1.8 TB/s por chip.
  • TDP: 1000 W por B200. Refrigeración líquida efectivamente obligatoria a escala de rack.
  • GB200: un módulo CPU Grace + 2× GPU B200. NVL72: 36 módulos GB200 (72 GPUs) en un rack, conectados por NVLink Switch como un único dominio NVLink de 130 TB/s. La arquitectura de "el rack es la unidad".

[fuente: NVIDIA Blackwell Architecture Whitepaper 2024; keynote GTC 2024]

Titular para la entrevista: Blackwell hace del rack — no del servidor — la unidad de cómputo, e introduce FP4 para volver a doblar los FLOPS efectivos.

Enlaces cruzados

Referencias

  • NVIDIA H100 Tensor Core GPU Architecture Whitepaper, 2022 (rev. 2024).
  • NVIDIA H200 Tensor Core GPU Datasheet, 2024.
  • NVIDIA Blackwell Architecture Technical Brief, 2024.
  • Micikevicius et al. 2022, FP8 Formats for Deep Learning, arXiv:2209.05433.
  • Luo et al. 2023, Dissecting the NVIDIA Hopper Architecture through Microbenchmarks, arXiv:2402.13499.
  • Dao T. et al. 2022, FlashAttention, NeurIPS — el artículo canónico de "convierte este kernel en limitado por cómputo, no por bandwidth".