L'inférence des modèles open source souffre d'un problème structurel discret : le code GPU qui fait réellement tourner les calculs n'est presque jamais calibré pour chaque configuration matérielle. Les bibliothèques de référence — vLLM, SGLang, FlashAttention — sont remarquablement bien écrites, mais elles sont conçues pour fonctionner sur un large spectre de GPU, pas pour en extraire le maximum sur une architecture précise. Résultat : il reste toujours une marge de performance inexploitée entre le matériel et ce que le logiciel en tire réellement.
Together AI, l'un des principaux fournisseurs de cloud dédié aux modèles open source (Llama, Mistral, DeepSeek, Qwen…), a annoncé le 4 novembre 2026 Together Compiler : un système qui envoie des équipes d'agents IA réécrire en continu les GPU kernels — le code bas niveau qui orchestre les opérations matricielles sur GPU — pour chaque modèle qu'il héberge. Le tout sans interruption de service, sans qu'un ingénieur humain n'ait à diriger chaque expérience.
Les gains annoncés vont de 1,3× à 3× de tokens par seconde selon le modèle. Together appelle cette initiative Polymorphic Inference et la présente comme le premier projet d'un programme plus large d'optimisation continue. C'est l'un des premiers exemples concrets où des agents IA prennent en charge un travail d'optimisation GPU qui relevait jusqu'ici d'ingénieurs hautement spécialisés.
Pour les équipes qui consomment des modèles open source via API, le signal est direct : les coûts d'inférence vont continuer à baisser et les débits à augmenter, non plus seulement grâce aux mises à jour des modèles, mais grâce à l'optimisation continue du code qui les fait tourner. Pour les équipes qui hébergent elles-mêmes leurs modèles, la situation est différente — et il y a une restriction importante à comprendre.
Comment Together Compiler fonctionne
Un GPU kernel est un programme écrit en CUDA ou Triton qui s'exécute directement sur les cœurs du GPU. Les opérations les plus coûteuses de l'inférence — attention multi-tête, GEMM, flashattention — sont chacune portées par un ou plusieurs kernels. L'enjeu n'est pas de changer le modèle : les poids restent identiques. L'enjeu est d'exécuter les mêmes calculs en utilisant mieux le matériel disponible.
Le pipeline d'agents
Together Compiler repose sur une architecture multi-agents qui fonctionne en continu en arrière-plan :
- Génération : des agents proposent des variantes de kernels — changements de tiling, fusion d'opérations, utilisation différente des mémoires SRAM/HBM.
- Test automatisé : chaque variante est compilée et évaluée sur les GPU de production, avec vérification de la correction numérique (les résultats doivent correspondre au kernel de référence).
- Validation humaine : Before deployment to production, a human engineer validates the best candidates — Together has maintained a human-in-the-loop step at this stage.
- Déploiement à chaud : les nouveaux kernels sont chargés sans redémarrer le serveur d'inférence. Together annonce avoir réduit le temps d'initialisation de 467 secondes à 9 secondes, ce qui rend le déploiement continu de kernels mis à jour opérationnellement viable.
Throughput d'expériences
Together revendique un débit d'expérimentations 252 fois supérieur à celui de systèmes comparables — une comparaison avec le système d'Apple qui reste contestée dans les détails, mais qui donne la mesure de l'intensité du processus. L'idée directrice : là où un ingénieur humain conduirait quelques dizaines d'expériences par semaine, les agents en testent des milliers en continu, sans coût marginal additionnel par expérience.
Gains mesurés et modèles concernés
Les chiffres annoncés par Together et par les médias techniques qui ont couvert le lancement distinguent deux types de mesures : les gains globaux sur les benchmarks de débit, et les gains modèle par modèle observés lors des premiers déploiements.
Gains globaux
- De 1,3× à 3× de tokens par seconde versus les baselines open source hautement optimisées, obtenus en moins de 24 heures de compilation continue.
- Plus de 2 100 tokens par seconde atteints sur certains modèles.
- Jusqu'à 1,7× la vitesse des mégakernels écrits à la main sur Llama 1B.
Gains par modèle (premiers déploiements)
- +15 % sur GLM 5.3 Flash
- +20 % sur GLM 5.3
- +12 % sur DeepSeek V4.1 Flash
Ces chiffres sont plus modestes que le maximum annoncé de 3×, ce qui est cohérent : les modèles les plus récents bénéficient déjà d'une attention plus soutenue de la communauté sur l'optimisation des kernels, laissant moins de marge. Les modèles moins optimisés nativement offrent davantage de potentiel de gain.
Pourquoi le débit de tokens par seconde est-il important ?
En inférence, le débit (tokens/s) détermine directement deux paramètres critiques pour une organisation : la latence perçue par l'utilisateur final (un débit plus élevé = des réponses plus rapides ou plus longues dans le même temps), et le coût par token (le même GPU traite plus de requêtes dans le même créneau). Pour les projets IA à fort volume — traitement documentaire, support client automatisé, pipeline de génération — une amélioration de 20 % à 30 % du débit se traduit directement en réduction du coût d'exploitation ou en capacité supplémentaire sans investissement matériel.
La restriction pour les équipes self-hosted
Together Compiler est un service qui tourne sur l'infrastructure de Together AI. Les équipes qui hébergent leurs propres modèles sur vLLM, SGLang ou un autre moteur d'inférence open source ne peuvent pas installer Together Compiler ni importer les kernels qu'il génère.
Cette restriction est importante à comprendre avant d'intégrer Together Compiler dans une évaluation d'architecture. Les cas d'usage où elle pose problème sont précisément ceux qui sont les plus fréquents dans les organisations françaises et européennes soumises à des contraintes de souveraineté des données :
- Modèles hébergés on-premise pour des données sensibles (santé, finance, juridique, R&D)
- Déploiements dans des environnements air-gapped ou sans accès aux API d'un fournisseur tiers
- Architectures où le contrat de traitement des données interdit l'envoi de tokens vers un service externe
Ce qui pourrait changer à moyen terme
Together a indiqué que Together Compiler est le premier projet d'une initiative plus large appelée Polymorphic Inference. L'ouverture des kernels générés à la communauté n'a pas été annoncée au moment du lancement, mais deux signaux suggèrent que des outils similaires pourraient émerger pour le self-hosting :
- Un paper académique de NVIDIA et Carnegie Mellon (CAKE: Compiler-Agent Co-Design for Frontier Kernel Evolution) décrit une approche similaire de co-conception compilateur-agent pour les kernels GPU — avec une orientation explicitement orientée open source.
- Des frameworks d'optimisation de kernels comme Triton (maintenu par OpenAI) et Liger Kernel offrent déjà des primitives sur lesquelles des agents pourraient s'appuyer pour des expérimentations automatisées en self-hosted.
Pour l'instant, si votre contrainte principale est la souveraineté des données, Together Compiler ne résout pas directement votre problème d'optimisation des coûts d'inférence. Mais il illustre une trajectoire : les GPU kernels vont être de mieux en mieux optimisés, que ce soit par des services cloud ou par des outils open source qui suivront.
Ce que ça change pour vos choix d'infrastructure IA
Pour les organisations qui consomment des modèles open source via l'API de Together AI ou d'autres fournisseurs susceptibles d'adopter des approches similaires, Together Compiler fonctionne de manière transparente : les modèles deviennent plus rapides et moins chers à débit constant, sans aucun changement côté client. C'est l'un des arguments les plus concrets en faveur de l'utilisation d'un fournisseur cloud dédié plutôt que d'un déploiement self-hosted pour les cas d'usage où les données peuvent transiter.
Trois signaux pour vos décisions de stack
- L'inférence open source va continuer à se rapprocher de l'inférence propriétaire sur le plan des performances. L'écart entre les modèles open source (Llama, Mistral, Qwen, DeepSeek) et les modèles propriétaires (GPT-6, Claude 5) se réduit à la fois sur les benchmarks et sur l'efficacité d'exécution. Together Compiler accélère cette tendance du côté runtime.
- L'optimisation GPU devient une tâche déléguée aux agents. C'est un signal clair que des tâches d'ingénierie système hautement spécialisées — écrire des CUDA kernels optimisés — entrent dans le périmètre de ce que les agents IA peuvent prendre en charge. Cette tendance va s'étendre à d'autres couches de l'infrastructure.
- Pour le self-hosted, la vigilance reste de mise. Si vous hébergez vos modèles pour des raisons de conformité RGPD ou de souveraineté, les bénéfices de Together Compiler ne vous sont pas directement accessibles aujourd'hui. L'enjeu est d'identifier les frameworks open source qui pourraient apporter des capacités similaires dans votre périmètre.
Si vous êtes en train d'évaluer votre architecture IA — cloud vs. self-hosted, modèles propriétaires vs. open source, inférence managée vs. déploiement maison — les annonces comme Together Compiler sont des signaux pertinents pour calibrer vos hypothèses de coûts à 12-18 mois. Nous accompagnons des équipes sur ces arbitrages dans le cadre de nos missions de développement sur mesure et d'outils internes IA — la question du choix de couche d'inférence revient systématiquement dans les phases de cadrage. Contactez-nous pour en discuter.
FAQ — Together Compiler : des agents IA réécrivent les GPU kernels en continu pour l'inférence open source — 1,3× à 3× de gain selon le modèle, restriction majeure pour le self-hosted
Qu'est-ce qu'un GPU kernel dans le contexte de l'inférence IA ?
Un GPU kernel est un programme qui s'exécute directement sur les cœurs d'un GPU. Dans l'inférence LLM, les opérations les plus lourdes — calcul de l'attention, multiplications matricielles — sont portées par des kernels spécifiques. Optimiser ces kernels pour une architecture GPU donnée peut apporter des gains de débit significatifs sans changer le modèle ou ses poids.
Together Compiler est-il accessible si j'héberge moi-même mes modèles ?
Non, au moment du lancement (4 novembre 2026). Together Compiler est un service interne à l'infrastructure de Together AI. Les équipes qui utilisent vLLM, SGLang ou un autre moteur d'inférence en self-hosted ne peuvent pas en bénéficier directement. Des outils open source aux approches similaires (Triton, CAKE de NVIDIA/CMU) existent, mais ne proposent pas encore un pipeline automatisé équivalent.
Quels gains peut-on attendre concrètement sur les modèles que je connais ?
Les gains varient selon le modèle et son état d'optimisation actuel. Sur les premiers déploiements de Together Compiler, on observe +12 % à +20 % sur des modèles comme DeepSeek V4.1 Flash et GLM 5.3. Les gains maximum annoncés (jusqu'à 3×) concernent des modèles moins optimisés nativement. Ces chiffres sont des mesures de débit (tokens/s), qui se traduisent directement en coût d'inférence par token.
Une validation humaine reste-t-elle en place avant le déploiement des nouveaux kernels ?
Oui, selon les informations disponibles au lancement. Les agents génèrent et testent des variantes de kernels en autonomie, mais un ingénieur humain valide les meilleurs candidats avant qu'ils ne passent en production. This human-in-the-loop step is a deliberate design decision by Together AI.
Quel est l'impact de ce type d'optimisation sur les coûts d'inférence pour mon organisation ?
Un gain de débit de 20 % signifie que le même GPU traite 20 % de requêtes supplémentaires dans le même temps, ce qui se répercute directement sur le coût par token. Pour des workloads IA à fort volume (traitement documentaire, pipelines automatisés, agents conversationnels), une amélioration de cet ordre peut représenter une réduction de coût substantielle sans changer de fournisseur ni de modèle.