Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Mejoras en la inicialización de la comunicación colectiva
NCCL y Gloo son bibliotecas de comunicación fundamentales que permiten las operaciones colectivas (como la reducción total y la transmisión) en todos los procesos de formación distribuidos. Sin embargo, la inicialización tradicional de NCCL y Gloo puede crear cuellos de botella durante la recuperación de errores.
El proceso de recuperación estándar requiere que todos los procesos se conecten a un proceso centralizado TCPStore y se coordinen a través de un proceso raíz, lo que supone una costosa sobrecarga que se vuelve especialmente problemática durante los reinicios. Este diseño centralizado genera tres problemas críticos: la sobrecarga de coordinación debido a TCPStore las conexiones obligatorias, los retrasos en la recuperación, ya que cada reinicio debe repetir toda la secuencia de inicialización, y un único punto de fallo en el propio proceso raíz. Esto impone unos pasos de coordinación costosos y centralizados cada vez que se inicia o se reinicia el entrenamiento.
HyperPod La formación sin control elimina estos obstáculos en la coordinación, lo que permite una recuperación más rápida en caso de averías, al hacer que la inicialización sea «desarraigada» y «». TCPStoreless
Configuraciones sin raíz
Para habilitar Rootless, basta con exponer las siguientes variables de entorno.
export HPCT_USE_ROOTLESS=1 && \ sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
HPCT_USE_ROOTLESS: 0 ó 1. Se usa para activar y desactivar rootless
sysctl -w net.ipv4.ip_local_port_range="20000 65535": establece el rango de puertos del sistema
Consulte el ejemplo para habilitar Rootless
Rootless
HyperPod El entrenamiento sin puntos de control ofrece métodos de inicialización novedosos, como Rootless y TCPStoreless, para los grupos de procesos de NCCL y Gloo.
La implementación de estas optimizaciones implica modificar NCCL, Gloo y: PyTorch
Ampliar la biblioteca de terceros APIs para permitir las optimizaciones de NCCL y Gloo con Rootless y Storeless y, al mismo tiempo, mantener la compatibilidad con versiones anteriores
Actualización de los backends de los grupos de procesos para utilizar rutas optimizadas de forma condicional y gestionar los problemas de recuperación durante el proceso
Evita TCPStore la costosa creación en la capa PyTorch distribuida y, al mismo tiempo, mantiene patrones de direcciones simétricos mediante contadores de grupos globales
El siguiente gráfico muestra la arquitectura de las bibliotecas de formación distribuidas y los cambios realizados en la formación sin puntos de control.
NCCL y Gloo
Se trata de paquetes independientes que desempeñan la funcionalidad principal de las comunicaciones colectivas. Proporcionan la clave APIs, como ncclCommInit Rank, para inicializar las redes de comunicación, gestionar los recursos subyacentes y realizar comunicaciones colectivas. Tras realizar cambios personalizados en NCCL y Gloo, Rootless y Storeless optimizan la inicialización de la red de comunicación (por ejemplo, evitan conectarse a ella). TCPStore Puede cambiar entre utilizar las rutas de código originales o las rutas de código optimizadas de forma flexible.
PyTorch backend del grupo de procesos
Los backends del grupo de procesos, específicamente ProcessGroup NCCL ProcessGroupGloo, los implementan ProcessGroup APIs invocando sus bibliotecas subyacentes correspondientes APIs . Dado que ampliamos las bibliotecas de terceros APIs, debemos invocarlas correctamente y realizar cambios en la ruta del código en función de las configuraciones de los clientes.
Además de optimizar las rutas de código, también cambiamos el backend del grupo de procesos para facilitar la recuperación durante el proceso.
