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

Together AI a publié ParallelKernelBench (PKB) — le premier benchmark ouvert pour évaluer la capacité des modèles de langage à générer des kernels CUDA efficaces pour les environnements multi-GPU. Après avoir testé plus de 40 modèles sur 87 tâches réelles, les chercheurs ont découvert : les meilleurs modèles frontier résolvent correctement moins d'un tiers des tâches — et seule une poignée d'entre eux surpassent réellement une implémentation naïve en PyTorch.

Pourquoi Multi-GPU est Plus Complexe

Les modèles de langage ont déjà appris à écrire du code pour un seul GPU de manière raisonnablement bonne, et la plupart des benchmarks de programmation GPU existants se limitent exactement à ce scénario. Mais les vrais systèmes d'IA en production ont depuis longtemps dépassé cette limite : ils fonctionnent sur des dizaines et des centaines de GPU simultanément. Dans de telles configurations, la puissance de calcul cesse d'être le principal goulot d'étranglement — ce rôle est assumé par la communication entre les appareils.

Selon Together AI, la surcharge de transfert de données entre GPU consomme plus de 20 % de la latence d'inférence — et cet écart augmentera, car la puissance des puces continue de dépasser la bande passante de l'interconnexion entre puces.

• Explosion combinatoire des options — vous devez choisir entre parallélisme tensor, contexte, expert, données et autres types, chacun créant son propre schéma de communication
• Modèle de performance différent — au lieu d'un toit computationnel local, la principale contrainte devient la bande passante de l'interconnexion entre puces
• Nouveaux choix architecturaux — comment déplacer physiquement les données entre GPU : via un moteur de copie, TMA, SM load/store ou NVLS, et s'il faut chevaucher la transfert de données avec le calcul

Comment Fonctionne le Benchmark

PKB inclut 87 tâches provenant de bases de code réelles : Megatron-LM, DeepSpeed, DeepEP, TensorRT-LLM et NeMo-RL — ainsi que des charges de travail distribuées non standard : routage dans les réseaux de neurones de graphe, FFT distribué et Gaussian splatting. Cette sélection couvre toutes les principales approches de sharding : tensor, contexte, données, expert, séquence et FSDP/ZeRO. Chaque tâche commence par une implémentation standard en PyTorch + NCCL et une description de topologie matérielle.

Le modèle doit la remplacer par son propre kernel CUDA qui transmet les données directement entre GPU via NVLink à travers la mémoire symétrique, contournant la pile standard d'opérations collectives. L'évaluation est basée sur trois critères : exactitude du résultat, accélération wall-clock et réalisation du toit de communication — la limite théorique de la bande passante du lien.

Résultats et Victoires Inattendues

Together AI a testé plus de 40 modèles, notamment GPT-5.5, Gemini 3 Pro et Opus 4.7 — les variantes phares actuelles d'OpenAI, Google et Anthropic. Les résultats ont été également 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 surpassé l'implémentation naïve de base en PyTorch + NCCL
• Défaillances principales — dans la gestion de la communication entre GPU et le choix de la bonne méthode de transfert de données

En même temps, plusieurs solutions se sont avérées être étonnamment fortes : des kernels individuels générés ont surpassé toutes les implémentations disponibles publiquement. Particulièrement révélateur est le cas de la formation GRPO dans NVIDIA NeMo-RL — pour cette opération, aucun code public optimisé n'existait auparavant, et le modèle de langage l'a écrit avant les humains.

"Plusieurs kernels générés se sont avérés être plus rapides que tout ce qui est disponible publiquement," — du rapport technique

ParallelKernelBench.

Ce Que Cela Signifie

PKB marque la prochaine frontière de l'évolution du coding avec l'IA : la transition de GPU unique aux systèmes distribués multi-GPU. Pour l'instant, les modèles frontier ne peuvent pas gérer cela — mais de rares éclairs de succès suggèrent que le progrès est possible grâce à la collecte ciblée de données d'entraînement spécialisées. Pour les équipes optimisant l'inférence et l'entraînement sur des clusters GPU, c'est un benchmark important : l'outil mûrit, mais n'est pas encore prêt pour une adoption généralisée.