El compilador Piper permite el entrenamiento estilo DeepSeek a escala de miles de GPU

Piper, un compilador de entrenamiento distribuido de la Universidad de Washington, simplifica la composición compleja de paralelismo al tratarlo como un problema de compilación en lugar de una tarea manual de ingeniería de sistemas. El sistema está diseñado para el preentrenamiento de modelos de fundación, capaz de escalar a cientos o miles de aceleradores. Piper afirma la paridad de rendimiento con las implementaciones existentes de ZeRO en estrategias estándar y permite la programación conjunta de cómputo y comunicación en estrategias estrechamente compuestas como DualPipe de DeepSeek-V3.

La arquitectura de Piper separa la estrategia de paralelismo de alto nivel de los planes de ejecución por dispositivo de bajo nivel. Los usuarios adjuntan anotaciones de modelo y directivas de programación a la representación intermedia de Piper, un DAG global de entrenamiento unificado que representa explícitamente cada operador de cómputo y comunicación en todo el clúster. Piper compila este IR en planes de ejecución por dispositivo y los envía a través de un tiempo de ejecución distribuido que permanece agnóstico con respecto a la estrategia utilizada, ya sea un paralelismo de datos puro, un esquema de fragmentación de ZeRO-3 o una híbrido de tubería-experto personalizado. Esto contrasta con Megatron, DeepSpeed y TorchTitan, que ofrecen controles para cada dimensión de paralelismo pero los manejan como si las dimensiones fueran independientes, y con JAX/XLA, que expone la colocación genérica de tensores pero no puede soportar fácilmente programas de tubería arbitrarios o controlar recursos de dispositivo de granularidad fina, como la partición de streaming-multiprocessor.

El programa DualPipe de DeepSeek-V3 destaca las limitaciones de los marcos existentes. DualPipe comparte un GPU entre dos microlotes de tubería, dividiendo los streaming multiprocessors entre núcleos de cómputo hacia adelante y hacia atrás y comunicaciones de experto paralelas de todo a todo para ocultar la latencia. Los marcos de propósito general asumen que un microlote posee el dispositivo completo, por lo que esto requiere que expertos humanos ingenieren manualmente tanto el plan de fragmentación de alto nivel como las máscaras de asignación de SM de bajo nivel para ese modelo y clúster específicos. Piper simplifica esto al tratar DualPipe como un conjunto de transformaciones IR en el DAG global; el compilador deriva el plan de ejecución por dispositivo, incluido el entrelazado de núcleos y la partición de SM, sin requerir código de orquestación escrito a mano.

El artículo presenta un sistema prototipo con comparaciones de diseño; la evaluación se centra en el diseño del sistema y las comparaciones relativas en lugar de latencias de paso absolutas, curvas de eficiencia de escalado o mediciones de horas de GPU en topologías de hardware nombradas. Si bien los autores afirman la paridad de rendimiento con ZeRO en estrategias comunes y citan ganancias de memoria y rendimiento en programas compuestos, no proporcionan latencias de paso medidas, curvas de eficiencia de escalado, ahorros de horas de GPU o cifras de consumo de memoria en topologías de hardware específicas. Piper también es explícitamente controlable por el usuario en lugar de auto-sintonización: el arquitecto selecciona la estrategia de paralelismo y el marco solo reduce el costo de implementación en lugar de buscar en el espacio combinatorial de estrategias.

El artículo no aborda la brecha completa de producción. No cuantifica el overhead de compilación para DAGs de parámetros de billones, ni describe el comportamiento de tolerancia a fallos, la semántica de puntos de control o la visibilidad de depuración a escala de miles de GPU. Como Piper se posiciona como un reemplazo para las pilas existentes en lugar de un complemento, la adopción requeriría migrar las definiciones de modelos de Megatron, DeepSpeed o TorchTitan y revalidar la corrección numérica en un nuevo tiempo de ejecución completamente nuevo. La interfaz también deja la selección de estrategia como un problema abierto; Piper hace que una estrategia elegida sea ejecutable pero no ofrece ninguna guía sobre si FSDP combinado con paralelismo de tensor y tubería, o una variante personalizada de DualPipe, es la llamada óptima para una carga de trabajo y topología de clúster dada.

No hay evidencia de producción aún; traten a Piper como una señal de investigación de que los IR globales compilados para el entrenamiento distribuido están llegando, pero no asignen presupuesto de migración hasta que el código fuente y las mediciones de grandes clústers estén disponibles. Lo que se debe robar ahora es el desacoplamiento a nivel IR en sí: si su equipo de plataforma todavía está ajustando manualmente etapas de tubería y máscaras SM, comiencen a abstraer su gráfico de entrenamiento en un DAG global transformable antes de que su próxima reimpresión de pila los obligue a hacerlo.