El análisis roofline revela por qué ZeRO-3 falla con DeepSeek-V3 en Hopper

Los ingenieros de infraestructura que analizaron la configuración de entrenamiento de DeepSeek-V3 en clústeres H800 han utilizado el análisis roofline para determinar las estrategias de paralelismo óptimas. Publicado en octubre de 2026, este profundo análisis técnico demuestra que Fully Sharded Data Parallelism (FSDP), también conocido como ZeRO-3, crea un grave cuello de botella de comunicación al escalar esta arquitectura específica del modelo.

El análisis concluye que se requiere paralelismo de pipeline para mantener el sistema limitado por la computación y no por la comunicación. Al comparar los límites teóricos del hardware con el rendimiento real medido, los autores proporcionan un método para predecir la eficiencia del entrenamiento sin tener que construir y evaluar múltiples sistemas a escala completa.

Qué sucedió

En la segunda parte de una serie sobre el entrenamiento de DeepSeek-V3, los autores examinaron cómo las opciones de paralelismo, el checkpointing de activaciones y la aritmética de baja precisión afectan los requisitos de memoria. Identificaron una configuración que permite que el modelo se ajuste en un clúster H800 de 2048 nodos. Los autores señalan que este resultado no fue accidental; fijar la arquitectura del modelo y apuntar al hardware específico que DeepSeek utilizó conduce naturalmente a la configuración seleccionada por el equipo original.

El desafío central abordado es seleccionar una estrategia de paralelismo que maximice las operaciones de punto flotante útiles por segundo (FLOPs/sec) sin el costo prohibitivo de implementar y evaluar múltiples sistemas en un clúster de tamaño completo. Implementar el paralelismo de pipeline es significativamente más complejo que FSDP, por lo que los ingenieros necesitan una forma fiable de decidir entre ellos antes de escribir código. Los autores argumentan que, incluso si se construyeran ambos sistemas, los errores de evaluación podrían invalidar la comparación.

Para resolver esto, aplicaron el análisis roofline, una técnica clásica de modelado de rendimiento. Este método trata el total de FLOPs requeridos como fijo e identifica si el sistema está limitado por la velocidad de cómputo o por el ancho de banda de la comunicación distribuida. El análisis revela que FSDP es una mala opción para DeepSeek-V3 porque queda limitado por el ancho de banda de InfiniBand, mientras que otras estrategias pueden mantener las GPUs ocupadas con el cómputo.

Cómo funciona

El análisis roofline se basa en el concepto de rendimiento "velocidad de la luz" (SOL), que representa el límite superior estricto de lo que el hardware puede lograr. En física, nada supera la velocidad de la luz; en computación, ningún software puede superar el pico teórico del silicio subyacente. Sin embargo, usar los picos especificados en el marketing suele ser engañoso. Las cifras de TFLOP/s anunciadas por NVIDIA asumen condiciones ideales, como tensores inicializados a cero y programación perfecta de instrucciones, situaciones que rara vez ocurren en multiplicaciones de matrices reales.

El rendimiento en el mundo real diverge de las hojas de especificaciones debido a la carga de memoria, la latencia de la jerarquía de caché y los límites de potencia. Por ejemplo, ejecutar datos distintos de cero puede activar topes de potencia que reducen las velocidades de reloj, lo que significa que el rendimiento depende de los valores de los datos de entrada. Para abordar esto, los autores utilizan los FLOPs alcanzables medidos mediante microbenchmarks del Smol Training Playbook de HuggingFace. Para la precisión BF16, el H800 alcanza 758 TFLOP/s, que es el 76,6% de su pico teórico de 989 TFLOP/s. Para FP8, alcanza 1,46 PFLOP/s, o el 73,6% del pico de 1,98 PFLOP/s.

El ancho de banda de la red se trata de manera similar. Aunque las especificaciones de InfiniBand afirman 50 GB/s, cifra mayormente alcanzable, el rendimiento de NVLink en los H800 es inferior al de los H100. DeepSeek informó haber logrado solo 160 GB/s de ancho de banda unidireccional en NVLink H800, en comparación con la especificación de 200 GB/s. El análisis utiliza estos valores medidos para calcular el tiempo dedicado a la comunicación frente al cómputo.

En el entrenamiento distribuido, el cuello de botella se desplaza de la memoria de alto ancho de banda (HBM) al ancho de banda entre nodos. El total de FLOPs requeridos para un paso de entrenamiento permanece constante independientemente del paralelismo, al igual que cortar una pizza no cambia su tamaño total. Sin embargo, la sobrecarga de comunicación varía drásticamente. Si el tiempo de comunicación excede el tiempo de cómputo, el sistema está limitado por la comunicación y las GPUs permanecen inactivas esperando datos. El objetivo es garantizar que el cómputo tome más tiempo que la comunicación, permitiendo al entrenador superponer estas operaciones y ocultar la latencia.

Detalles clave

• Objetivo de hardware: El análisis se centra en un clúster de 2048 nodos de GPUs NVIDIA H800.
• Cómputo alcanzable: El rendimiento BF16 medido es de 758 TFLOP/s (76,6% del pico), y FP8 es de 1,46 PFLOP/s (73,6% del pico).
• Restricciones de red: Se asume un ancho de banda de InfiniBand de 50 GB/s por GPU, mientras que NVLink está limitado a 160 GB/s según los informes de DeepSeek.
• Veredicto de paralelismo: Se rechaza FSDP (ZeRO-3) porque queda limitado por el ancho de banda de InfiniBand para este tamaño de modelo.
• Metodología: El enfoque compara los tiempos calculados de "velocidad de la luz" para FLOPs y transferencias de bytes para determinar si un paso está limitado por el cómputo o por la comunicación.
• Simplificación: La Predicción Multi-Token (MTP) se omite en este análisis específico para mantener la claridad.

Por qué importa

Para los equipos de infraestructura de aprendizaje automático, este análisis proporciona un marco riguroso para tomar decisiones arquitectónicas críticas sin una inversión inicial masiva. Construir y evaluar múltiples estrategias de paralelismo en miles de GPUs es prohibitivamente costoso y consume mucho tiempo. El análisis roofline ofrece una alternativa basada en hojas de cálculo que puede predecir cuellos de botella de rendimiento con razonable precisión. Evita que los equipos persigan rutas de implementación, como configuraciones complejas de paralelismo de pipeline, solo para descubrir más tarde que un enfoque más simple como FSDP habría fallado debido a los límites de la red.

Además, la distinción entre las especificaciones de marketing y el rendimiento alcanzable es crítica para una planificación precisa de la capacidad. Confiar en los picos teóricos puede llevar a una sobreestimación significativa del throughput de entrenamiento. Al utilizar microbenchmarks medidos, los ingenieros pueden crear cronogramas realistas y expectativas presupuestarias. Esto es especialmente importante a medida que los modelos crecen y la precisión disminuye, lo que acelera el cómputo pero no reduce el volumen de comunicación, potencialmente exacerbando los cuellos de botella de ancho de banda.

Qué puedes hacer

• Evalúa el rendimiento GEMM de tu propio hardware utilizando bibliotecas como cuBLAS para determinar los FLOP/s alcanzables en lugar de depender de las hojas de especificaciones.
• Mide el ancho de banda real de NVLink e InfiniBand en tu entorno de clúster, ya que la topología real y los topes de potencia pueden reducir el throughput.
• Utiliza el análisis roofline para comparar estrategias de paralelismo antes de la implementación, enfocándote en si el tiempo de comunicación excede el tiempo de cómputo.
• Ten en cuenta los límites de potencia en tus modelos, reconociendo que las entradas de datos distintos de cero pueden limitar las velocidades de reloj de la GPU durante el entrenamiento.
• Prioriza configuraciones limitadas por el cómputo cuando sea posible, asegurando que la sobrecarga de comunicación pueda superponerse con el cálculo.
• Reevalúa las suposiciones al cambiar los niveles de precisión, ya que una menor precisión aumenta la velocidad de cómputo pero puede desplazar el cuello de botella hacia el ancho de banda de la red.