PyTorch 2.15 activa por defecto su backend NCCL reescrito y conserva vías de reversión

PyTorch 2.15 convierte en predeterminado el backend NCCL reescrito para sus cargas de trabajo distribuidas. La decisión afecta a la capa que coordina comunicación entre procesos y GPU, un componente central cuando el entrenamiento o la inferencia se reparte entre varias tarjetas o nodos. Las notas oficiales presentan además un flight recorder capaz de generar un volcado al detectar un bloqueo, una señal pensada para mejorar el diagnóstico de una de las clases de fallos más costosas de reproducir en sistemas distribuidos.

La actualización no obliga a tratar el cambio como una sustitución ciega. PyTorch documenta dos vías de reversión: la variable TORCH_DIST_USE_NCCL2=0 y el uso de nccl-legacy. Su existencia importa porque permite plantear una migración controlada: comparar un entrenamiento representativo, conservar métricas de comunicación y estabilidad, y aislar un problema sin tener que deshacer toda la actualización del entorno. Son mecanismos de compatibilidad temporal, no una garantía de que cualquier configuración antigua y nueva produzca resultados idénticos.

La lectura de Signalia es que el valor de 2.15 está tanto en el cambio de base como en la instrumentación y el plan de vuelta atrás. Para los equipos que dependen de torch.distributed, el paso prudente es validar primero en preproducción con la misma topología, drivers, bibliotecas CUDA y patrón de carga que usarán en operación. Si aparecen bloqueos o diferencias, el registro de vuelo y las rutas de reversión dan un punto de partida verificable; después conviene revisar las notas completas de cambios incompatibles antes de extender la versión a todos los nodos.