Together AI : GPT-5.5, Gemini et Opus ne savent pas écrire de noyaux multi-GPU rapides

Together AI a publié ParallelKernelBench (PKB), le premier benchmark ouvert destiné à mesurer la capacité des modèles de langage à générer des noyaux CUDA efficaces pour des environnements multi-GPU. Après avoir testé plus de 40 modèles sur 87 tâches réelles, les chercheurs constatent que les meilleurs modèles de pointe résolvent correctement moins d'un tiers des tâches, et que seules quelques-unes de ces solutions battent réellement une implémentation PyTorch naïve.

Pourquoi le multi-GPU est plus difficile

Les modèles de langage écrivent désormais du code correct pour un seul GPU, et la plupart des benchmarks de programmation GPU existants se limitent à ce scénario. Mais les systèmes d'IA en production ont dépassé cette limite depuis longtemps : ils tournent sur des dizaines, voire des centaines de GPU simultanément. Dans ces configurations, la puissance de calcul cesse d'être le principal goulot d'étranglement ; c'est la communication entre les appareils qui prend sa place.

Selon Together AI, le surcoût du transfert de données entre GPU absorbe plus de 20% de la latence à l'inférence, et cet écart va continuer de se creuser, car la puissance des puces progresse plus vite que la bande passante de l'interconnexion entre puces.

La génération multi-GPU diffère fondamentalement de celle pour un seul GPU, pour trois raisons :

• Explosion combinatoire des options : il faut choisir entre parallélisme tensoriel, de contexte, d'experts, de données et d'autres types, chacun créant son propre schéma de communication
• Un autre modèle de performance : au lieu du roofline de calcul local, c'est la bande passante de l'interconnexion entre puces qui devient la principale limite
• Un nouveau choix d'architecture : comment déplacer physiquement les données entre GPU (via copy engine, TMA, SM load/store ou NVLS) et faut-il superposer le transfert de données au calcul

Comment fonctionne le benchmark

PKB comprend 87 tâches issues de bases de code réelles (Megatron-LM, DeepSpeed, DeepEP, TensorRT-LLM et NeMo-RL), ainsi que de charges distribuées atypiques : routage dans les réseaux de neurones de graphes, FFT distribuée et Gaussian splatting. Cette sélection couvre tous les grands modes de sharding : tensoriel, de contexte, de données, d'experts, séquentiel et FSDP/ZeRO.

Chaque tâche part d'une implémentation standard en PyTorch + NCCL et d'une description de la topologie matérielle. Le modèle doit la remplacer par son propre noyau CUDA, qui transfère les données directement entre GPU via NVLink grâce à la mémoire symétrique, sans passer par la pile standard d'opérations collectives.

L'évaluation repose sur trois critères : l'exactitude du résultat, l'accélération en temps réel (wall-clock) et l'atteinte du communication roofline, la limite théorique de bande passante de l'interconnexion.

Résultats et victoires inattendues

Together AI a testé plus de 40 modèles, dont GPT-5.5, Gemini 3 Pro et Opus 4.7, les modèles phares actuels d'OpenAI, de Google et d'Anthropic. Les résultats sont tout aussi décevants pour tous :

• Le meilleur modèle a résolu correctement moins d'un tiers des 87 tâches
• Moins d'un quart des solutions correctes ont battu l'implémentation de référence naïve en PyTorch + NCCL
• Les principaux échecs concernent la gestion de la communication entre GPU et le choix de la bonne méthode de transfert de données

Pourtant, quelques solutions se sont révélées étonnamment solides : certains noyaux générés ont dépassé toutes les implémentations publiquement disponibles. Le cas le plus frappant est l'entraînement GRPO dans NVIDIA NeMo-RL : jusqu'ici, il n'existait pas de code public optimisé pour cette opération, et un modèle de langage l'a écrit avant les humains.

«

Plusieurs noyaux générés se sont révélés plus rapides que tout ce qui existe en accès libre », extrait du rapport technique de ParallelKernelBench.

Ce que cela signifie

PKB désigne la prochaine frontière du code assisté par IA : le passage d'un GPU isolé à des systèmes distribués multi-GPU. Pour l'instant, les modèles de pointe n'y arrivent pas, mais de rares éclairs de réussite laissent penser qu'un progrès est possible avec une collecte ciblée de données d'entraînement spécialisées.

Pour les équipes qui optimisent l'inférence et l'entraînement sur des clusters de GPU, c'est un repère important : l'outil gagne en maturité, mais n'est pas encore prêt pour un usage généralisé.