Deux articles publiés sur Hugging Face Daily Papers (22-23 juillet 2026) s’attaquent au même goulot d’étranglement sous deux angles. SLAI T-Rex documente l’entraînement complet de DeepSeek-V4, un MoE de plusieurs trilliards de paramètres, sur un cluster Ascend NPU SuperPOD : pression mémoire sévère, communication non-chevauchée, kernels inefficaces. « Where Should Optimizer State Live? » quantifie le problème à la racine : dans un MoE de 6,78 milliards de paramètres, AdamW accumule 50,6 GB d’état d’optimiseur pour mettre à jour 12,6 GB de poids. L’état de l’optimiseur est le poste le plus volumineux du budget mémoire.

Pourquoi ça vous concerne : comme nous l’avons rapporté le 22 juillet, AMD a investi 5 milliards et 2 GW de GPU chez Anthropic. C’est le côté technique de cet investissement. Entraîner des modèles à l’échelle du trilliard demande plus que d’acheter des puces : la mémoire que l’algorithme d’entraînement demande pour suivre les gradients croît plus vite que les paramètres eux-mêmes. SkewAdam, l’optimiseur du second article, assigne des précisions différentes aux trois composantes d’un MoE (backbone dense, experts, routeur) en fonction de leurs statistiques de gradient. Cela réduit de 97,4% l’état de l’optimiseur : de 50,6 GB à 1,29 GB. La mémoire de pointe descend de 81,4 GB à 31,3 GB, rendant l’entraînement de MoE de milliards de paramètres compatible avec une GPU de 40 GB. Pour qui construit des modèles ou évalue les contraintes infrastucturelles, c’est le détail qui fait la différence entre un cluster qui tourne et un cluster arrêté.

En détail

Le problème de l’état de l’optimiseur explique pourquoi entraîner de grands modèles coûte si cher. Quand vous entraînez un modèle avec AdamW (l’optimiseur standard pour les LLM), l’algorithme ne conserve pas seulement les poids : il garde aussi une copie des gradients passés (premier moment) et une estimation de leur variance (deuxième moment). Pour chaque paramètre il faut deux valeurs supplémentaires en mémoire, plus le paramètre lui-même. Sur un modèle dense cela double ou triple la mémoire requise. Sur un MoE le problème est plus subtil.

Un MoE a trois populations de paramètres avec des caractéristiques très différentes : le backbone dense (petit mais mis à jour à chaque pas), les experts (larges mais activés rarement) et le routeur (minuscule mais critique pour le routage). AdamW les traite tous de la même façon, assignant à chacun la même quantité d’état. L’article « Where Should Optimizer State Live? » part d’une observation : les statistiques des gradients de ces trois populations sont tellement différentes que les traiter uniformément est un gaspillage.

SkewAdam assigne des précisions différentes aux trois composantes. Le backbone dense reçoit l’état en pleine précision, les experts reçoivent l’état en précision réduite, le routeur reçoit un traitement intermédiaire. Le résultat, mesuré sur un MoE de 6,78 milliards de paramètres : l’état de l’optimiseur passe de 50,6 GB à 1,29 GB, une réduction de 97,4%. La mémoire de pointe totale descend de 81,4 GB à 31,3 GB, rendant l’entraînement compatible avec une GPU de 40 GB sans perte mesurable de perplexité de validation.

L’article de SLAI T-Rex s’attaque au problème par l’autre bout : non l’optimiseur, mais l’infrastucture. L’entraînement complet de DeepSeek-V4 sur un cluster Ascend NPU SuperPOD nécessite de gérer la pression mémoire, l’overhead de communication et les kernels inefficaces. L’article documente l’optimisation end-to-end sur du hardware non-NVIDIA, un détail qui compte car le marché du compute s’élargit au-delà de CUDA.

Les deux articles convergent sur un point : à l’échelle du trilliard de paramètres, la mémoire est le goulot d’étranglement principal, plus que la puissance de calcul brute. L’état de l’optimiseur est le poste le plus volumineux du budget, et le distribuer correctement (avec précision différenciée ou avec des architectures système redessinées) est ce qui fait fonctionner un cluster au lieu de l’arrêter.

Ce qui reste ouvert. SkewAdam est testé sur un MoE de 6,78 milliards de paramètres, pas des trilliards. La scalabilité de la précision réduite à l’échelle réelle est une question ouverte. L’article de SLAI T-Rex est une étude d’ingénierie documentée sur du hardware spécifique (Ascend), pas un résultat généralisable à n’importe quel cluster. Les deux articles sont des preprints sur Hugging Face, sans relecture par les pairs au 23 juillet 2026.