Medir y escalar

5.1Modelo roofline

Todo kernel tiene una intensidad aritmética (IA): FLOPs realizados por byte movido desde memoria. El roofline dice:

FLOP/s alcanzables = min( FLOP/s máximos ,  IA × ancho de banda de memoria )

En ejes log-log obtienes un "techo de memoria" inclinado que se une con un "techo de cómputo" plano en el punto de inflexión (ridge point). Para una H100 en BF16 es ~989 TFLOP/s ÷ 3.35 TB/s ≈ 295 FLOPs/byte.

• Las operaciones elemento a elemento (suma, GELU, layer norm) tienen IA cercana a 1. Están irremediablemente limitadas por memoria, así que fusiónalas.
• Las matmul grandes tienen IA de miles. Están limitadas por cómputo, y ahí brillan los tensor cores.
• La atención sin fusionar está limitada por memoria. FlashAttention la reorganiza para quedarse en el chip.

La guía GPGPU de PRACE usa el mismo razonamiento para kernels de HPC: primero decide bajo qué techo estás y luego optimiza ese recurso.

5.2MFU (Model FLOPs Utilization)

Para transformers densos, entrenar cuesta unos 6 × parámetros × tokens FLOPs (2 en el forward + 4 en el backward). El MFU compara lo que lograste con el máximo teórico:

MFU = (6 · N · tokens_por_segundo) / (núm_GPUs · FLOP/s_máximos)

Ignora deliberadamente la recomputación del checkpointing de activaciones (eso es HFU, hardware FLOPs utilization), así que solo premia el trabajo útil.

¿Qué es bueno? Entre 35 y 55% es típico para entrenamiento bien afinado de modelos grandes en clústeres tipo H100. Más de 60% es excelente.

Qué lo hunde: micro-batches pequeños, comunicación expuesta (sin solapamiento), burbujas de pipeline, esperas del dataloader, Stragglers (rezagados), relojes limitados y FP32 simple. La misión Feed the Beast los recorre en orden.

5.3All-reduce (anillo y árbol)

El all-reduce en anillo ordena n rangos en un anillo y ejecuta dos fases (reduce-scatter y luego all-gather) de n−1 pasos cada una. Cada rango envía y recibe ~2(n−1)/n × el tamaño del buffer:

T_anillo ≈ 2(n−1)/n · S/B  +  2(n−1) · α

donde S son los bytes, B el ancho de banda por enlace y α la latencia por paso. El término de ancho de banda casi no crece con n. El de latencia sí, y eso castiga a los mensajes pequeños a gran escala.

Los algoritmos de árbol (el doble árbol binario de NCCL) reducen el término de latencia a ~log₂(n) pasos y ganan con mensajes pequeños y muchísimos rangos.

El bus bandwidth, el número que reporta nccl-tests, elimina el factor 2(n−1)/n para que puedas compararlo directamente con la velocidad del enlace. Un nodo NVLink sano muestra cientos de GB/s. Uno con un enlace degradado muestra cifras de PCIe.

Usa el widget para ver cómo se relacionan el tamaño, el número de rangos y el ancho de banda.

5.4Eficiencia de escalado

Ley de Amdahl: si una fracción s del trabajo es serial, la aceleración con n trabajadores es como máximo 1 / (s + (1−s)/n). Incluso un 5% serial te limita a 20× de aceleración.

El entrenamiento distribuido agrega comunicación que crece con la escala: términos de latencia de las colectivas, saltos entre racks y una probabilidad creciente de que alguna GPU sea lenta (ver Stragglers (rezagados)).

Escalado débil vs. fuerte

• Escalado fuerte: mismo problema, más GPUs. La eficiencia cae a medida que el trabajo por GPU se achica.
• Escalado débil: el batch crece con el número de GPUs. Es mucho más amable, y por eso existe el entrenamiento con batches grandes, dentro de lo que todavía converge.

Cómo medirlo: eficiencia de escalado = (rendimiento con n) / (n × rendimiento con 1). Repórtala junto con el MFU. Un trabajo puede escalar perfecto y aun así ser ineficiente por GPU.

5.5Pipeline de entrada

Cuando las cuentas del modelo ya son rápidas, el lado de la CPU suele ser el límite: leer shards del almacenamiento, descomprimir, tokenizar, mezclar y armar batches.

Síntomas: la utilización de GPU sube y baja en dientes de sierra, el tiempo por paso no mejora al optimizar el modelo y los logs muestran tiempo esperando el siguiente batch.

Arreglos

• Más workers del dataloader (procesos) por rango y memoria pinned.
• Precarga: prepara el batch k+1 mientras entrena el batch k (ver CUDA streams y ejecución asíncrona).
• Tokeniza por adelantado y guarda shards binarios empaquetados. Es la mayor ganancia para el preentrenamiento de LLM.
• Asegúrate de que el sistema de archivos paralelo o el almacenamiento de objetos entregue el ancho de banda agregado: GPUs × tokens/s × bytes por token, más el tráfico de checkpoints.

La misión Feed the Beast muestra cómo el cuello de botella pasa a la carga de datos en cuanto se arregla la comunicación.

[rank0] step 120 | loss 3.112 | 1.02 s/step | 128.4k tok/s | MFU 32.5% | dataloader wait

5.6Limitación de potencia

Cerca del extremo superior de la curva voltaje/frecuencia, la potencia crece mucho más rápido que el rendimiento: la potencia dinámica ∝ f·V², y el voltaje debe subir con la frecuencia. Por eso limitar la potencia cuesta proporcionalmente menos rendimiento del que ahorra.

En el entrenamiento, solo la parte limitada por cómputo de cada paso se frena. La comunicación, la carga de datos y las burbujas de pipeline no dependen de los relojes del SM, así que el impacto real en el rendimiento es aún menor.

Cómo

sudo nvidia-smi -pl 550            # todas las GPUs de este nodo
sudo nvidia-smi -pl 550 -i 3       # solo la GPU 3

Los límites se pierden al reiniciar salvo que los gestione tu aprovisionamiento o las políticas de DCGM.

Advertencias: limita todas las GPUs de un trabajo. Limitar una crea un straggler. Y mide tokens por joule, no solo tokens por segundo.

5.7Energía y carbono

Un clúster de GPUs es cliente de una central eléctrica. Una contabilidad aproximada:

energía de la instalación (kWh) = energía de TI (GPUs + hosts + red) × PUE
emisiones (kg CO₂e)             = energía de la instalación × intensidad de carbono de la red

• El PUE (Power Usage Effectiveness) captura el costo extra de refrigeración y distribución eléctrica: ~1.1 en los mejores sitios con refrigeración líquida, 1.3–1.6 en los típicos.
• La intensidad de carbono varía más de 10× entre regiones y según la hora del día. Dónde y cuándo entrenas puede importar tanto como cómo.

Palancas que controlas

• Primero la eficiencia: mayor MFU significa menos horas de GPU para el mismo modelo.
• Los límites de potencia cambian un poco de velocidad por mucha energía.
• Ajusta el tamaño: no dejes asignaciones ociosas corriendo. Los planificadores pueden recuperarlas.
• Reporta kWh y CO₂e por ejecución, junto al costo y la precisión, para que los compromisos sean visibles.

Cada ejecución de LazyLab muestra su energía, costo y carbono en el encabezado.