Les agents de Together AI accélèrent des LLM ouverts jusqu'à 2,6 fois en tokens par seconde en une journée

Together AI, qui sert des trillions de tokens par jour, présente Together Compiler (TKCC). Dans ce système, des agents IA cherchent en continu les optimisations pour exécuter les modèles (l'inférence) en fonction du modèle, des GPU et du trafic du moment. Le problème : le travail manuel ne suffit plus.

Les architectures de modèles diffèrent, le matériel aussi, et la charge change chaque jour. Prenons l'exemple d'une simple modification du noyau d'attention. Pour la tester, il faut généralement redémarrer un moteur comme vLLM, SGLang ou TRT-LLM, et un démarrage complet prend 467 secondes, soit près de 8 minutes.

TKCC lance le moteur une seule fois et remplace le code à chaud : le test démarre en 9 secondes. Résultat : en moins de 24 heures, le système a obtenu jusqu'à 2,6 fois plus de tokens par seconde (TPS, la principale métrique de vitesse d'inférence) sur les modèles ouverts Kimi K3, GLM 5.3, MiniMax M3.

1-Flash et DeepSeek v4.1-Flash. Or les tokens par GPU déterminent directement le coût de revient d'un service.

Pourquoi le trafic ne reste pas stable

L'équipe s'appuie sur des observations issues de la production. Les heures de bureau d'un pays produisent des prompts plus longs que celles d'un autre : 97 mille tokens contre 70 mille, soit 1,4 fois plus. Après la sortie d'un nouveau modèle, les utilisateurs commencent par discuter avec lui dans un chat pour l'évaluer. Environ deux semaines plus tard, la longueur des prompts augmente de 80 % : ils passent à des scénarios agentiques. Il y a aussi des pics : les prompts doublent soudainement, tandis que le taux de succès du cache chute.

Chacun de ces décalages modifie l'optimisation gagnante. Pour les modèles MoE, la répartition inégale de la charge entre experts compte. Pour l'attention éparse, ce sont les données réelles en entrée. Les heuristiques figées et les compilateurs ML classiques s'en accommodent mal. Parmi les dix LLM ouverts les plus populaires sur OpenRouter, il n'y en a pas deux avec la même architecture, et le matériel va du H100 et du B200 au B300, au NVL72 et à Groq.

Comment fonctionne Together Compiler

En entrée, le système reçoit le profil de trafic, le modèle et le matériel. Plusieurs agents génèrent des variantes d'optimisation pour le moteur d'inférence et échangent leurs idées via un « tableau de messages » commun.

Première idée : les « moteurs persistants ». Le goulot d'étranglement des anciens systèmes d'agents est la vitesse d'expérimentation, et le tableau de Together montre pourquoi : le chargement des poids, le préchauffage des noyaux JIT et l'autotuning engloutissent des minutes à chaque essai. Un moteur persistant démarre une seule fois et remplace à chaud le candidat dans la passe avant du modèle. Au final, 252 fois plus d'expériences aboutissent que avec les systèmes d'agents de référence.

Deuxième idée : un équilibre entre vitesse et précision des mesures. Tester des noyaux isolés sur des données aléatoires est rapide mais trompeur : pour les MoE et l'attention éparse, le gagnant dépend de la distribution réelle des entrées. Les moteurs sont donc à deux niveaux. Les moteurs « rapides » chargent quelques couches et conviennent à des mesures fréquentes avec peu de bruit. Les moteurs « lents » chargent de nombreuses couches et vérifient que le gain se maintient sur des données réelles.

Troisième composant : un modèle de coût maison pour choisir le parallélisme (TP, EP, DCP et autres schémas de découpage du modèle entre les GPU). Il combine les caractéristiques officielles du matériel, des microbenchmarks et des mesures de passes avant réelles, et écarte vite les configurations faibles. D'après les graphiques des auteurs, un choix fondé sur les spécifications fait moins bien qu'une répartition mesurée, et la meilleure répartition dépend du nombre de requêtes simultanées.

Ce que disent les chiffres

• Jusqu'à 2,6 fois plus de tokens par seconde par rapport aux meilleures configurations publiées dans le benchmark SemiAnalysis InferenceX (AgentX).
• Records de faible latence avec un batch de 1 : 1111 tokens/s sur MiniMax M3.1-Flash et 1205 sur DeepSeek v4.1-Flash. La configuration de parallélisme a été choisie par le modèle de coût maison, et non par la recommandation d'InferenceX.
• Sur le test canonique des mégakernels, Llama 1B avec un batch de 1, TKCC est 1,7 fois plus rapide que les mégakernels ouverts et conserve son avantage quand la longueur de séquence augmente (sur H100 et B200).
• Hors LLM : sur des bases de code ouvertes pour la prévision météo, les équations différentielles, les séries temporelles et la biologie, TKCC a trouvé un gain plus important que Claude Code avec la commande /goal sur trois modèles sur quatre.

Ce que cela signifie pour les praticiens

Pour ceux qui gèrent leur propre inférence, le signal est clair : l'optimisation n'est pas un réglage de configuration ponctuel, mais une recompilation permanente face à la dérive du trafic. Plus de tokens sur la même carte signifie soit un parc de GPU plus petit, soit une marge plus grande face à la charge.

Il y a des réserves. Les chiffres proviennent de Together elle-même, sur ses propres tâches, et aucune vérification indépendante n'existe pour l'instant. Pour Trainium2, l'équipe a utilisé un jeu de données synthétique multitour, car l'implémentation ne prend pas encore en charge une forte concurrence avec une mémoire HBM limitée. On ignore si TKCC deviendra un produit accessible. Mais deux principes sont applicables dès maintenant : ne redémarrez pas le moteur à chaque test, et validez les optimisations sur des données réelles plutôt qu'aléatoires.