NVIDIA propose un collectif Reshard pour le refit des poids en apprentissage par renforcement : ses propres mesures réduisent la latence du refit de 2,7x à 5,7x, mais elles ne portent que sur le refit et non sur l’entraînement de bout en bout, et la fonction de NeMo RL est expérimentale et exige le backend Megatron

Le 6 novembre 2026, des ingénieurs de NVIDIA ont publié un article technique sur le collectif Reshard, un appel de communication destiné à accélérer une étape du post-entraînement par apprentissage par renforcement (RL) : la copie des nouveaux poids du modèle des GPU d’entraînement vers les GPU d’inférence. Les auteurs appellent cette étape le refit. L’article présente aussi NCCL M2N Reshard, une implémentation de référence open source dans le dépôt NVIDIA/nccl-extensions, et sa voie d’intégration dans le framework NeMo RL. Tous les temps sont ceux de NVIDIA, mesurés sur ses propres systèmes.

Le problème est la taille. Dans une configuration RL désagrégée, l’entraînement et l’inférence tournent sur des GPU séparés, et le côté inférence doit recevoir souvent la politique mise à jour. Les deux côtés découpent le modèle différemment, avec des parallélismes de données, de tenseurs, d’experts et de pipeline différents. La méthode habituelle est « rassembler puis diffuser » : les GPU d’entraînement rassemblent chaque paramètre complet, le diffusent, et chaque GPU d’inférence ne garde que le fragment dont il a besoin. NVIDIA estime que cela déplace environ deux fois la taille des poids du modèle. Pour des poids BF16, elle donne 5,6 To pour Kimi K3 (2,8 billions de paramètres) et 4,8 To pour Qwen 3.8 2.4T A95B, soit environ 11,2 To et 9,6 To de trafic logique, qui doivent selon l’article avoir lieu à chaque pas d’entraînement.

L’idée est de décrire les deux dispositions comme des DTensors PyTorch, un maillage d’appareils plus des placements, et de traiter le refit comme le redécoupage d’un DTensor en un autre. Reshard n’envoie alors que les parties qui se recouvrent entre fragments source et destination. NCCL M2N Reshard regroupe aussi les réplicas de destination par domaine NVLink : dans l’exemple où les quatre GPU de destination sont dans un même domaine NVLink, chaque fragment traverse le réseau une fois et les GPU récepteurs échangent le reste par NVLink ; entre plusieurs domaines, une copie doit être transférée à chaque domaine, les deux étapes étant exécutées en pipeline. Dans NeMo RL, NVIDIA applique une conception hybride. Les poids de projection feed-forward, qui représenteraient environ 95 % des paramètres des modèles récents, passent par Reshard, tandis que les poids plus petits, comme la projection QKV ou les poids Mamba, gardent le « rassembler puis diffuser » pour que la couverture reste complète.

Les résultats rapportés sont quatre latences de refit mesurées dans NeMo RL. Sur NVIDIA DGX H100, Qwen 3 235B passe de 6,4 s à 1,9 s, et DeepSeek v3 671B de 14,9 s à 2,6 s. Sur NVIDIA DGX GB200, DeepSeek v3 671B passe de 6,1 s à 2,3 s, et Nemotron Ultra v3 de 8,2 s à 2,3 s. L’article annonce une accélération de 2,7x à 5,7x, et le tableau est cohérent avec cette plage. Un micro-benchmark distinct, limité au refit, a déplacé le modèle Qwen3.8 2.4T en BF16 en 4,3 secondes, mais l’article ne donne aucun temps « rassembler puis diffuser » pour ce modèle, donc aucun rapport. Les dispositions entraînement→inférence du tableau sont : H100 NVL8 Qwen 3 235B TP4×PP8×EP16→TP8×DP16 (6,4→1,9 s) ; H100 NVL8 DeepSeek v3 PP16×EP16→TP32×DP8 (14,9→2,6 s) ; GB200 NVL72 DeepSeek v3 avec la même disposition (6,1→2,3 s) ; GB200 NVL72 Nemotron Ultra v3 TP8×EP32×PP2→TP8×DP8 (8,2→2,3 s).

Il faut lire les chiffres pour ce qu’ils mesurent. Ce sont des latences de refit, pas un débit d’entraînement ni un temps pour atteindre une récompense cible, et l’article ne dit pas quelle part de chaque pas RL le refit occupe ; nous ne pouvons donc pas convertir 2,7x à 5,7x en accélération de bout en bout. La comparaison se fait avec la voie classique de NVIDIA, pas avec d’autres méthodes de refit dans d’autres frameworks. Quatre configurations sur deux systèmes NVIDIA forment un petit ensemble, l’article ne rapporte pas de dispersion entre exécutions, et nous n’avons rien reproduit.

La documentation de NeMo RL ajoute les limites. Elle qualifie `nccl_reshard_refit` d’expérimental. Le réglage est `refit_transport: nccl_reshard` avec `policy.generation.colocated.enabled` à false, car il ne fonctionne qu’en configuration non colocalisée. Il exige le backend d’entraînement Megatron et un backend de génération vLLM ou Megatron, et indique que SGLang et TRTLLM ne sont pas encore pris en charge. Une destination vLLM exige encore une taille de parallélisme de tenseurs d’experts égale à 1. L’article ajoute que lorsque des nœuds rejoignent ou quittent le système pendant une reprise après panne, NeMo RL détruit et recrée actuellement le groupe de communication, l’usage des API shrink et grow de NCCL étant prévu plus tard.

Notre lecture : c’est une idée d’ingénierie crédible, avec de vrais chiffres, et l’abstraction est utile parce que le coût du refit grandit avec la taille du modèle. Les équipes qui entraînent de très grands modèles à mélange d’experts avec Megatron et vLLM, avec des ressources d’entraînement et de génération non colocalisées, pourraient l’essayer en partant de l’option expérimentale. Les autres devraient attendre une prise en charge plus large des backends, mesurer la part du refit dans leur temps de pas et considérer l’accélération de tête comme un indice de meilleur cas, pas comme une garantie.