L’apprentissage par renforcement MoE sur Amazon EKS atteint 40 % de débit supplémentaire, mais le benchmark présente des limites
Amazon affirme que l’apprentissage par renforcement MoE sur Amazon EKS a généré 40 % de débit global de rollouts supplémentaire après que ses ingénieurs ont activé DeepEP via Elastic Fabric Adapter. Le test portait sur 48 instances P5en, dont 16 affectées à l’entraînement de la politique et 32 à la génération de rollouts d’inférence. Il s’agit d’un résultat notable pour une étape coûteuse du post-entraînement des grands modèles.
Le changement important ne se résume pas à une nouvelle configuration GPU plus rapide. Amazon a adapté le chemin de communication entre experts de DeepEP pour utiliser libfabric, offrant à DeepEP v2 une prise en charge native des réseaux AWS. Cette intégration cible le schéma de trafic irrégulier créé lorsqu’un modèle Mixture-of-Experts achemine des tokens entre des experts répartis sur différents GPU.
Le résultat doit aussi être replacé dans son contexte. AWS a communiqué un gain relatif de débit pour une charge de travail MoE super-sparse, et non un benchmark universel pour tous les modèles, clusters ou frameworks d’apprentissage par renforcement. Des travaux indépendants de recherche sur les systèmes ont documenté la difficulté de faire circuler les communications parallèles entre experts à travers différentes architectures GPU et réseau.
Ce qu’Amazon a modifié dans sa pile d’apprentissage par renforcement MoE
Le gain annoncé par Amazon provient d’un changement dans la manière dont les tokens routés circulent entre les experts, et non de l’ajout de machines au cluster mesuré.
L’architecture AWS divise une tâche d’apprentissage par renforcement en plusieurs groupes de workers. Les nœuds GPU gèrent l’entraînement de la politique, l’inférence du modèle de récompense et la génération de rollouts. Les nœuds CPU exécutent les environnements et le prétraitement, tandis que les nœuds optimisés pour la mémoire hébergent les tampons d’expérience et les caches de checkpoints.
Amazon EKS sert de couche d’orchestration. Il place les conteneurs, gère des groupes de nœuds séparés, coordonne les défaillances et permet aux opérateurs de faire évoluer indépendamment chaque partie de la charge de travail. Amazon S3 stocke les jeux de données, les checkpoints, les poids finaux et d’autres artefacts durables en dehors du chemin d’exécution sensible à la latence.
Cette séparation est importante, car l’apprentissage par renforcement n’est pas un calcul uniforme. Lors de la génération de rollouts, un worker d’inférence utilise la politique actuelle pour interagir avec un environnement et produire des réponses ou trajectoires candidates. Un système de récompense évalue ces échantillons, puis les workers d’entraînement de la politique consomment l’expérience ainsi obtenue.
Les poids mis à jour retournent ensuite vers la flotte de rollouts, lançant une nouvelle itération de politique. Cette boucle apparaît dans le Reinforcement Learning from Human Feedback, ou RLHF, qui utilise des signaux de préférence pour améliorer un modèle. Elle apparaît aussi dans le Group Relative Policy Optimization, ou GRPO, qui évalue les sorties par rapport à d’autres échantillons d’un groupe.
Chaque étape sollicite l’infrastructure différemment. La génération de rollouts ressemble à l’inférence distribuée et peut souvent répartir le travail entre des workers indépendants. L’entraînement de la politique exige une synchronisation plus étroite, car les GPU participants doivent achever des opérations coordonnées avant de pouvoir passer à l’étape suivante.
L’architecture sépare donc 32 instances d’inférence de 16 instances d’entraînement dans le test communiqué. Sur ces 48 systèmes P5en, Amazon indique que DeepEP via EFA a augmenté de 40 % le débit global de rollouts par rapport à la configuration sans DeepEP.
Les instances P5en utilisent des GPU NVIDIA H200 et le réseau AWS à haut débit. Un déploiement complet de 48 instances représente des centaines d’accélérateurs, bien qu’AWS indique que son architecture plus large peut s’étendre jusqu’à environ mille accélérateurs. Le pourcentage publié décrit la comparaison à 48 instances, et non toutes les tailles de cluster possibles.
Le modèle lui-même est décrit uniquement comme un modèle MoE super-sparse. Un modèle Mixture-of-Experts contient plusieurs blocs feed-forward spécialisés, mais n’en active qu’un sous-ensemble pour chaque token. La sparsité réduit le calcul par token, mais crée un problème de routage exigeant lorsque les experts résident sur différents GPU.
Les opérations collectives standard fonctionnent bien lorsque chaque rang échange des blocs prévisibles de taille similaire. Le routage MoE est différent. Les tokens choisissent dynamiquement les experts, de sorte que le trafic peut être sparse, inégal et composé de nombreux petits transferts.
Cette différence explique pourquoi l’infrastructure compte autant. Une capacité théorique de modèle plus élevée ne se traduit pas automatiquement par davantage de tokens utiles par seconde. Si la répartition vers les experts et la collecte des résultats saturent le réseau, les coûteux GPU attendent les activations au lieu de les traiter.
Pourquoi l’apprentissage par renforcement MoE sur Amazon EKS se heurte à une limite réseau
Le calcul sparse économise des opérations arithmétiques, mais le parallélisme entre experts peut réintroduire ce coût sous forme de délai de communication.
Le parallélisme entre experts répartit les experts d’un modèle sur plusieurs GPU. Lorsqu’un routeur sélectionne des experts distants, le système doit envoyer l’activation de chaque token vers l’appareil approprié. Une fois l’expert traité, une opération de combinaison renvoie la sortie vers son chemin d’exécution d’origine.
Ces échanges se produisent de façon répétée dans tout le modèle. Leurs destinations dépendent de décisions de routage prises à l’exécution, et différents experts peuvent recevoir des nombres différents de tokens. Le réseau doit donc gérer de nombreux transferts à granularité fine sans laisser quelques destinations très sollicitées bloquer tous les participants.
DeepEP a été créé pour ce schéma. Le projet DeepEP fournit des kernels spécialisés de dispatch et de combine pour les charges de travail parallèles entre experts. Il utilise NVLink pour la communication au sein d’un serveur et un transport compatible RDMA entre serveurs.
L’accès direct à la mémoire à distance, ou RDMA, permet à une machine de transférer des données directement vers la mémoire d’une autre machine avec une moindre intervention du CPU. Ce chemin plus court peut réduire la surcharge logicielle et mieux exploiter le matériel réseau à haut débit.
Elastic Fabric Adapter, ou EFA, est l’interface réseau AWS à faible latence pour le calcul étroitement couplé. La documentation EFA décrit un chemin de contournement du système d’exploitation fondé sur AWS Scalable Reliable Datagram. EKS peut exposer des périphériques EFA aux pods exécutant des applications d’apprentissage automatique distribuées.
À l’intérieur de chaque instance P5en, NVLink et NVSwitch transportent le trafic GPU à travers la structure locale d’accélérateurs. Pour les transferts entre instances, EFA devient le chemin pertinent. L’intégration d’Amazon utilise libfabric, une interface permettant aux applications d’accéder à différents fournisseurs de réseaux haute performance via une API commune.
Amazon indique que ses ingénieurs ont contribué à des fonctionnalités qui ont fait migrer les primitives de communication DeepEP d’un backend RDMA spécifique à CUDA vers libfabric. Grâce à ce travail, DeepEP v2 peut envoyer des données inter-nœuds via EFA tout en conservant des kernels spécialisés pour le dispatch et le combine entre experts.
La distinction entre opérations spécialisées pour experts et collectives denses est au cœur du résultat. NCCL demeure utile pour les opérations régulières telles que all-reduce, all-gather et reduce-scatter. DeepEP cible les échanges sparse de type all-to-all autour des couches MoE.
Des recherches récentes reflètent cette séparation. Les auteurs de NCCL EP décrivent des modes distincts à faible latence et à haut débit pour la communication entre experts. Leur conception à haut débit agrège les données au sein des domaines NVLink avant de les transmettre à travers des connexions RDMA inter-nœuds.
Cette hiérarchie réduit la quantité de trafic à granularité fine qui franchit la frontière plus lente entre les machines. Elle reconnaît également qu’un cluster n’est pas un réseau uniforme. La communication au sein d’un serveur présente des caractéristiques de bande passante et de latence différentes de la communication entre serveurs.
L’implémentation AWS suit le même principe général. Le trafic local reste sur NVLink, tandis que libfabric transporte le trafic DeepEP inter-nœuds via EFA. Ce chemin conscient de la topologie remplace un traitement générique de chaque transfert de token.
L’augmentation de 40 % obtenue concerne la production globale de rollouts, et non un simple microbenchmark de communication. Cette mesure de bout en bout est précieuse, car un kernel plus rapide n’accélère pas toujours l’ensemble de la boucle d’apprentissage par renforcement. Le gain suggère que la communication entre experts était suffisamment importante pour affecter le travail de rollout achevé.
Toutefois, le débit des rollouts ne constitue encore qu’une couche du système. Le temps d’itération de politique dépend aussi de l’exécution de l’environnement, de l’évaluation des récompenses, du stockage tampon des échantillons, de la publication des checkpoints, du calcul d’entraînement et de la synchronisation des poids. L’optimisation d’une étape peut révéler un goulot d’étranglement ailleurs.
Le véritable enjeu oppose le routage spécialisé aux collectives génériques
Le principal enjeu est l’opposition entre une communication conçue pour le routage dynamique entre experts et des opérations collectives conçues pour des mouvements de données réguliers.
Les collectives génériques sont attrayantes, car elles sont matures, largement prises en charge et plus faciles à intégrer. Elles fonctionnent avec de nombreux frameworks d’entraînement et configurations matérielles. Les opérateurs peuvent également les tester avec des outils connus et analyser leur comportement de synchronisation.
Le trafic MoE enfreint plusieurs hypothèses qui rendent ces collectives efficaces. Chaque token peut sélectionner un ensemble d’experts différent. Certains experts deviennent temporairement populaires, les tailles de messages restent faibles, et le système effectue des opérations de dispatch et de combine à chaque couche MoE.
Une implémentation conventionnelle peut empaqueter ce trafic dans des opérations all-to-all. Cette approche reste fonctionnelle, mais la surcharge de synchronisation et de gestion des messages augmente à mesure que le parallélisme entre experts s’étend sur davantage de nœuds. Ajouter des GPU crée alors plus de relations de communication plutôt que proportionnellement plus de calcul utile.
DeepEP s’attaque à ce problème avec des kernels conçus autour de la sémantique du routage entre experts. Le kernel de dispatch envoie les activations de tokens aux experts sélectionnés. Le kernel de combine renvoie les activations traitées, tout en évitant le travail qu’une collective générale pourrait effectuer pour des destinations non utilisées.
Cette conception cherche également à chevaucher communication et calcul. Si un GPU peut poursuivre des opérations matricielles utiles pendant l’avancement des transferts, une partie du temps réseau disparaît du chemin critique. Ce chevauchement devient plus difficile lorsque la communication exige une coordination CPU répétée ou une synchronisation globale stricte.
La migration vers libfabric menée par Amazon est importante, car l’optimisation initiale était étroitement associée aux GPU NVIDIA et aux réseaux de type InfiniBand. Une bibliothèque de communication performante sur une structure réseau ne conserve pas automatiquement son comportement sur une autre. Les garanties d’ordre, l’initialisation des messages et les interfaces des appareils varient.
L’intégration représente donc davantage qu’un changement d’adresse réseau. Les hypothèses de DeepEP doivent correspondre à la sémantique de transport d’EFA, et l’implémentation doit préserver la bonne livraison des tokens. Elle doit également éviter d’introduire une surcharge logicielle suffisante pour annuler les avantages du routage spécialisé.
Amazon affirme que les systèmes P5 et P6 pris en charge peuvent utiliser GPUDirect RDMA avec EFA. GPUDirect RDMA permet aux transferts réseau de lire et d’écrire dans la mémoire GPU sans faire transiter chaque charge utile par la mémoire hôte ordinaire. Le système d’exploitation reste en dehors du chemin principal des données.
Cette conception met sous pression les déploiements MoE génériques qui s’appuient uniquement sur des collectives standard. Les équipes d’infrastructure qui utilisent de grands modèles parallèles entre experts disposent désormais d’éléments indiquant qu’un chemin spécialisé peut améliorer une charge de travail d’apprentissage par renforcement pertinente en production.
Le résultat exerce aussi une pression sur les mainteneurs de frameworks. La prise en charge de DeepEP doit atteindre les moteurs de serving, les systèmes d’apprentissage par renforcement, les images de conteneurs, les ordonnanceurs et les outils d’observabilité. Un transport rapide exigeant une compilation personnalisée fragile peut perdre son avantage lors du déploiement ou de la reprise après incident.
NCCL 2.31 ajoute un autre élément au tableau. AWS indique que cette version comprend de nouvelles optimisations EFA pour les communications collectives denses. Une pile d’entraînement MoE réaliste utilise donc des mécanismes différents selon les catégories de trafic, plutôt que de désigner un vainqueur universel.
DeepEP gère la répartition irrégulière entre experts et l’agrégation. NCCL continue de gérer la synchronisation dense autour des couches d’attention, du parallélisme tensoriel, du parallélisme de données et de l’état de l’optimiseur. EFA transporte ces deux catégories entre les machines via des chemins optimisés pour leurs schémas respectifs.
Cette répartition constitue la principale leçon architecturale. La montée en charge des MoE dépend de l’identification des communications selon leur forme et leur objectif. Considérer chaque transfert comme interchangeable laisse des performances inexploitées.
Ce que l’affirmation d’un gain de débit de 40 % avec DeepEP ne démontre pas
Le benchmark étaye une décision architecturale précise, mais il ne démontre pas un gain universel de 40 % de DeepEP par rapport à EFA.
Amazon indique l’allocation d’instances, l’amélioration relative et le profil global de parcimonie du modèle. L’entreprise ne publie ni le nombre de paramètres du modèle, ni le nombre d’experts, ni la distribution de routage, ni les longueurs de séquence, ni les tailles de lot, ni la configuration complète de référence.
Ces détails influencent directement la communication entre experts. Un modèle activant davantage d’experts par token peut générer plus de trafic. Des lots plus importants peuvent agréger les messages plus efficacement, tandis que de petits lots de décodage peuvent amplifier la latence fixe.
L’expression « débit agrégé de rollout » nécessite également du contexte. AWS ne fournit pas, dans sa publication publique, le nombre absolu de tokens de sortie, de trajectoires ou de requêtes terminées par seconde. Les lecteurs ne peuvent ni calculer l’utilisation totale du cluster ni la comparer directement à celle d’un autre fournisseur.
La référence compte tout autant. « Sans DeepEP » peut désigner une implémentation standard de NCCL all-to-all avec des choix de réglage spécifiques. Une agrégation différente des messages, un autre placement des experts, une autre concurrence ou d’autres politiques de routage pourraient réduire ou accroître l’écart mesuré.
Amazon présente un résultat contrôlé issu de sa propre charge de travail interne. L’entreprise ne prétend pas que le benchmark a fait l’objet d’un audit indépendant, et les éléments publics n’incluent pas la variance de mesures répétées. La formulation correcte est donc qu’AWS affirme que le débit a augmenté de 40 %.
La question de la portabilité se pose également. Des travaux antérieurs sur UCCL-EP soutenaient que les systèmes de communication entre experts étroitement liés aux interfaces GPU et réseau imposent un travail d’intégration conséquent. L’article examinait précisément la manière dont des sémantiques d’ordonnancement différentes compliquent la prise en charge d’EFA et d’autres réseaux non InfiniBand.
Ces travaux sont antérieurs au nouveau fonctionnement natif d’EFA décrit par Amazon. Ils restent pertinents, car ils expliquent l’obstacle technique qu’AWS affirme désormais avoir surmonté grâce à ses contributions à libfabric. Les deux récits décrivent des étapes différentes dans une histoire d’implémentation qui évolue rapidement.
UCCL-EP emprunte une autre voie. Il conserve les décisions de routage sur les GPU, mais délègue l’exécution réseau à des proxys CPU multithreadés, en utilisant un canal de contrôle pour combler les différences matérielles. Ses auteurs rapportent des gains sur des systèmes NVIDIA plus EFA, mais ces tests impliquent leurs propres modèles, frameworks et configurations.
Aucun de ces résultats n’invalide l’autre. Ils montrent que la conception du transport peut modifier le résultat, et que la « prise en charge d’EFA » ne désigne pas un chemin d’exécution unique et fixe. Les opérateurs doivent savoir si une compilation utilise des transferts initiés par GPU, des proxys CPU, une agrégation de messages ou une autre couche de compatibilité.
Les exigences publiées et les résultats de performance de DeepEP ont également évolué. La documentation actuelle du projet fait état d’une forte bande passante sur les configurations RDMA prises en charge, tout en encourageant les utilisateurs à benchmarker directement des déploiements de parallélisme entre experts de plus grande ampleur. Ce conseil est particulièrement important sur des fabrics cloud dont la topologie et le comportement en matière de congestion diffèrent.
L’échelle du cluster ajoute une incertitude supplémentaire. Le test rapporté utilisait 48 instances P5en, tandis qu’AWS évoque l’extension de l’architecture globale vers environ mille accélérateurs. Une conception performante sur 48 nœuds ne conserve pas nécessairement la même efficacité à toutes les échelles supérieures.
La contention réseau peut apparaître lorsque plusieurs groupes de workers partagent l’infrastructure. Le routage des tokens peut devenir plus déséquilibré à mesure que le comportement du modèle ou de la charge de travail évolue. Un seul rang lent peut également retarder des opérations d’entraînement étroitement synchronisées.
L’apprentissage par renforcement ajoute sa propre source de variation. Les longueurs de prompts, les longueurs de réponses, la latence de l’environnement, les paramètres d’échantillonnage et la complexité du modèle de récompense influencent tous le temps que les workers de rollout consacrent à communiquer. Un gain de 40 % sur une charge de travail intensive en communication peut diminuer lorsque la génération ou l’exécution de l’environnement domine.
Le résultat en dit encore moins sur le serving en ligne. L’inférence de production utilise souvent des lots plus petits et des objectifs stricts de latence par requête. Un kernel à haut débit optimisé pour la génération de rollouts ne réduit pas automatiquement le délai avant le premier token ni le temps par token de sortie pour les utilisateurs interactifs.
Le coût reste non précisé en valeur absolue. Un débit supérieur sur le même cluster améliore généralement la quantité de travail utile par heure d’accélérateur, mais la publication ne fournit aucune facture totale d’entraînement. Elle ne compare pas non plus la configuration optimisée avec d’autres types d’instances ou bibliothèques réseau.
Ces omissions ne rendent pas le résultat sans importance. Elles définissent le cadre dans lequel il est utile. Le benchmark montre que l’intégration de DeepEP par AWS peut éliminer un goulot d’étranglement significatif dans un pipeline d’apprentissage par renforcement MoE de grande taille.
EKS et la capacité Spot transforment le reste du système RL
Le gain de communication ne devient opérationnellement utile que si l’ordonnanceur, le buffer, le stockage et le modèle de défaillance continuent d’alimenter la flotte de rollouts plus rapide.
Amazon EKS permet à l’architecture d’affecter différents types de nœuds à des tâches distinctes. Les groupes de nœuds GPU peuvent évoluer en fonction de la demande d’entraînement et d’inférence. Les groupes CPU peuvent s’étendre pour les workers d’environnement, tandis que les systèmes orientés mémoire absorbent les données d’expérience éphémères.
Cette hétérogénéité est particulièrement pertinente pour GRPO et RLHF. Les workers de rollout peuvent générer de grandes quantités de données temporaires, mais les entraîneurs de politiques les consomment par lots synchronisés. Si les taux de production et de consommation divergent, un côté attend tandis que l’autre accumule une file d’attente.
Un buffer d’expérience partagé en mémoire découple ces cadences sur de courtes périodes. Les workers de rollout publient les échantillons terminés, et les entraîneurs récupèrent des lots lorsqu’ils sont prêts. Les caches de checkpoints facilitent la distribution des poids mis à jour sans imposer à chaque transfert de passer par un stockage objet persistant.
Amazon S3 joue un rôle différent. Il conserve les jeux de données, les checkpoints récupérables, les artefacts de modèle terminés et les poids finaux. Maintenir ce chemin durable en dehors des échanges d’échantillons les plus fréquents évite que la latence du stockage objet ne contrôle chaque étape d’entraînement.
Cette séparation clarifie également la valeur d’EKS. Kubernetes n’accélère ni la multiplication matricielle ni les kernels d’experts. Il coordonne l’ensemble des services nécessaires pour maintenir la productivité des accélérateurs.
EKS gère le placement, les redémarrages, les politiques de mise à l’échelle et les limites entre groupes de nœuds. Il peut planifier séparément une capacité stable d’entraînement de politiques et des workers de rollout plus élastiques. Cette séparation prend en charge la seconde optimisation d’Amazon : l’utilisation d’EC2 Spot Instances pour une partie de la génération de rollouts.
La capacité Spot peut être interrompue lorsqu’AWS doit récupérer les instances sous-jacentes. Ce risque est difficile à gérer pour l’entraînement de politiques étroitement synchronisé, car la perte d’un worker peut bloquer ou redémarrer une tâche coordonnée. Les tâches de rollout sont plus faciles à partitionner et à relancer.
Amazon recommande d’attribuer aux workers de rollout des unités de travail bornées et de publier fréquemment les échantillons. Lorsqu’un avis d’interruption arrive, un worker peut terminer les requêtes actives et renvoyer les tâches inachevées vers une file d’attente. Les autres workers continuent sans redémarrer l’ensemble du groupe d’entraînement de politiques.
Cette stratégie ne rend pas les interruptions gratuites. Les générations partielles perdues gaspillent une partie du calcul, et les nœuds de remplacement ont besoin de conteneurs, de poids de modèle et de bibliothèques de communication. Les décisions d’autoscaling doivent également tenir compte de la profondeur de la file d’attente, du temps de chargement du modèle et de la capacité Spot disponible.
La topologie isole néanmoins deux domaines de défaillance. Les entraîneurs de politiques restent sur une capacité stable, tandis que la génération de rollouts utilise un pool moins coûteux mais moins prévisible. Cette conception correspond aux exigences de synchronisation différentes des deux étapes.
L’augmentation de 40 % du débit de DeepEP peut modifier cet équilibre. Des workers d’inférence plus rapides peuvent fournir de l’expérience plus vite que les entraîneurs ne la consomment. Les opérateurs doivent alors redimensionner les groupes de nœuds, ajuster la planification des lots ou réduire la capacité d’inférence afin d’éviter de payer pour une production inactive.
L’inverse peut se produire après une mise à jour de politique. La distribution des poids et le temps de redémarrage des workers peuvent temporairement affamer le buffer d’expérience. Un tableau de bord de production utile doit donc suivre l’itération de politique de bout en bout, et pas seulement les tokens générés par seconde.
Les équipes ont également besoin d’informations de build reproductibles. DeepEP, NCCL, CUDA, libfabric, les pilotes EFA, les versions de frameworks et l’architecture GPU influencent tous le chemin de données. Modifier un composant peut sélectionner silencieusement une solution de repli plus lente.
Ces éléments opérationnels doivent accompagner les enregistrements de modèles et d’expériences. Les équipes d’ingénierie peuvent conserver les décisions de configuration, les notes de benchmark et les rapports de défaillance dans une base de connaissances technique consultable. Cette pratique devient précieuse lorsqu’une reconstruction ultérieure d’image modifie le débit sans changer le modèle.
Trois signaux montreront si le gain se généralise
Le prochain test porte sur la reproductibilité entre modèles, tailles de cluster et itérations complètes de politiques.
Le premier signal est un package de benchmark public avec un débit absolu. Des résultats utiles incluraient les tokens ou trajectoires par seconde, les distributions de latence, le déséquilibre de charge des experts, l’utilisation du réseau et la variance entre exécutions répétées.
Ce package devrait préciser la collective de référence, toutes les versions logicielles pertinentes et le chemin de transport DeepEP exact. Il devrait également divulguer les dimensions du modèle, le nombre d’experts actifs par token, les tailles de lots, les longueurs de prompts, les longueurs de réponses et le degré de parallélisme entre experts.
Si des équipes indépendantes reproduisent un gain similaire, l’affirmation d’AWS devient plus solide. Si les résultats varient fortement, l’intégration reste utile mais spécifique à la charge de travail. Dans les deux cas, cela aiderait les opérateurs à déterminer quand sa complexité supplémentaire est justifiée.
Le deuxième signal est l’efficacité de mise à l’échelle au-delà de la configuration publiée de 48 instances. Des résultats obtenus à plusieurs tailles de cluster montreraient si le débit croît proportionnellement ou s’il perd du terrain face à la synchronisation, la congestion et le déséquilibre entre experts.
Une étude de mise à l’échelle significative devrait maintenir constante la définition de la charge de travail tout en augmentant les ressources. Elle devrait rapporter à la fois la production agrégée et l’efficacité par accélérateur. Le débit agrégé peut augmenter alors même que chaque GPU ajouté fournit moins de travail utile.
Une forte efficacité jusqu’à environ mille accélérateurs appuierait l’affirmation architecturale plus large d’AWS. Un déclin marqué indiquerait que DeepEP a supprimé un goulot d’étranglement, tandis qu’un autre est apparu à plus grande échelle.
Le troisième signal est le temps d’itération de politique de bout en bout en présence de défaillances réelles. Le débit de rollout compte parce que les workers d’entraînement ont besoin d’expérience récente, et non parce que générer des tokens isolés constitue l’objectif final.
Les futures mesures devraient inclure l’exécution de l’environnement, l’évaluation des récompenses, les délais du buffer, les mises à jour de politique, la publication des checkpoints et la redistribution des poids. Elles devraient également montrer comment les interruptions Spot affectent les échantillons terminés et le temps de récupération.
Une itération complète plus courte confirmerait que l’optimisation des communications améliore les progrès de l’apprentissage par renforcement au lieu de déplacer le temps d’inactivité ailleurs. Si le temps d’itération change à peine, les équipes devraient examiner l’entraînement, le stockage ou la synchronisation avant d’ajouter davantage de capacité de rollout.
L’apprentissage par renforcement MoE sur Amazon EKS dispose désormais d’une voie crédible pour combiner l’orchestration Kubernetes, le réseau EFA et une communication spécialisée entre experts. L’augmentation rapportée de 40 % rend cette approche digne d’être testée, mais elle reste une mesure initiale plutôt qu’une constante généralisable. Les équipes d’infrastructure devraient reproduire la comparaison avec leur propre modèle, leur profil de routage et leur boucle RL avant de standardiser la pile.
La question pratique n’est pas de savoir si DeepEP peut produire un graphique plus rapide. Il s’agit de déterminer si le même cluster réalise davantage de mises à jour de politique validées, avec une fiabilité et un coût acceptables, une fois chaque composant du système pris en compte.
