Comment exécuter GPT-OSS-120B sur des GPU NVIDIA à plus de 500 tokens par seconde

• GPT-OSS-120B, le LLM open source d'OpenAI, a été optimisé pour fonctionner avec une performance de plus de 500 tokens traités par seconde dans un environnement GPU NVIDIA.
• Des frameworks d'inférence variés tels que TensorRT-LLM, vLLM et SGLang ont été testés en parallèle, avec prise en charge des architectures Hopper et Blackwell.
• Les correctifs de compatibilité ont été appliqués, avec intégration de nouveaux formats de réponse comme Harmony, KV cache-aware routing et décodage spéculatif basé sur Eagle.
• Après avoir comparé Tensor Parallelism et Expert Parallelism, Baseten a retenu la tensor parallelism pour une plus faible latence et utilise le backend TensorRT-LLM MoE sur Blackwell.
• Des optimisations supplémentaires sont prévues, notamment l’introduction du decoding spéculatif (Speculative Decoding) utilisant de petits modèles de « draft » pour améliorer encore les performances.

---

Aperçu

• À la sortie du dernier LLM open source d’OpenAI, GPT-OSS-120B, Baseten a visé une performance de pointe.
  • Baseten est le partenaire de lancement officiel d’OpenAI.
• Les données utilisateur réelles publiées sur OpenRouter ont démontré une performance supérieure aux solutions tierces dans un environnement basé sur les GPU NVIDIA.
• Grâce au Flexible Inference Stack et à l’expertise de l’équipe d’ingénierie modèle, des patches d’optimisation ont été appliqués rapidement heure par heure.
• En l’espace de quelques heures d’écriture de l’article, l’augmentation a atteint 100 tokens/s supplémentaires tout en maintenant un uptime de 100 %.

Efforts d’optimisation des performances

• Des tests et benchmarks ont été menés sur divers frameworks d’inférence, dont TensorRT-LLM, vLLM et SGLang.
• Le support de compatibilité avec les architectures GPU Hopper et Blackwell a été assuré en parallèle.
• Baseten a intégré des composants clés comme le Flexible Inference Stack et NVIDIA Dynamo.
• Des techniques d’optimisation éprouvées ont été déployées, dont le KV cache-aware routing et le Speculative decoding (basé sur Eagle).

Voici les étapes clés pour atteindre simultanément des performances SOTA et la prise en charge d’une fenêtre de contexte complète.

Étape 1 : Exécution de l’inférence initiale

• Le point de départ est de lancer rapidement l’inférence initiale (baseline inference) quelle que soit la méthode.
• Plusieurs ingénieurs ont mené en parallèle des expériences sur vLLM, SGLang et TensorRT-LLM.
• TensorRT-LLM, qui affichait les meilleures performances, a été démarré rapidement avec succès.
• La prise en charge de TensorRT-LLM a été obtenue sur Hopper (qui compte le plus grand nombre de GPU H100) et sur Blackwell (où les B200 sont plus rapides).
• Grâce à la flexibilité du Baseten Inference Runtime, l’adaptation à de nouvelles architectures de modèle et le remplacement rapide d’outils dans la stack étaient facilités.

Étape 2 : Correction des bugs de compatibilité

• L’apparition de nouvelles architectures de modèle s’accompagne souvent de bugs fréquents lors de l’intégration aux frameworks.
• GPT OSS a introduit de nouvelles technologies, comme le nouveau format de réponse Harmony, qui ont provoqué des bugs lors de l’intégration avec les frameworks existants.
• Pour garantir vitesse et précision, des cycles répétés de correction et de tests ont été menés, et les correctifs efficaces ont été partagés en open source.
• La collaboration au sein de la communauté open source mondiale permet d’effectuer rapidement diverses optimisations et corrections de bugs.

Étape 3 : Optimisation de la composition du modèle

• OpenAI précise que GPT OSS 120B fonctionne sur une seule H100, mais dans la pratique une parallélisation sur 4 à 8 GPU est plus favorable aux performances.
• La Tensor Parallelism excelle sur la latence, tandis que l’Expert Parallelism excelle sur le throughput système.
  • L’objectif de Baseten étant l’optimisation de la latence, elle a choisi la Tensor Parallelism.
• Sur Blackwell, l’adoption du TensorRT-LLM MoE Backend améliore les performances du noyau CUDA par rapport à l’ancien backend Triton.
• Des réglages optimisés pour chaque environnement Hopper et Blackwell ont été publiés, et le Model API a retenu une configuration basée sur Blackwell.

Optimisation des performances additionnelle

• La première phase d’optimisation a déjà permis d’atteindre des niveaux SOTA en throughput et latence, mais il reste une marge de progression.
• Les prochaines mises à jour prévues incluent l’introduction du Speculative Decoding :
  • Cette méthode génère des tokens prédictifs avec un modèle « draft » plus rapide, puis le modèle principal les vérifie.
  • Baseten recommande Eagle 3, mais exploite de manière flexible plus de 10 algorithmes différents selon les cas d’usage au sein de sa stack d’inférence.
• Le speculative decoding permet d’effectuer l’inférence de plusieurs tokens en une seule fois pour une amélioration de vitesse efficace

[jjw951215]

J’aimerais bien qu’on me donne aussi un petit et mignon H100.

[GN⁺]

Avis sur Hacker News

• widely-available H100 GPUs

  J’ai lu ça et j’ai fouillé le tiroir des composants chez moi, mais même en cherchant partout je ne trouvais pas pourquoi il n’y a pas de GPU H100 à 25 000 $.

  • J’ai vérifié sur la page produit NVIDIA que le H100 est bien classé comme GPU. Je pense qu’il faut un terme qui distingue plus clairement le matériel grand public orienté gaming, qui ne permet qu’une inférence LLM très limitée, du matériel professionnel business dont l’objectif principal est le training IA et l’inférence LLM.
  • J’ai testé un modèle 20B avec Ollama sur 8 cartes Titan X (de 2015) : Ollama a réparti uniformément les 15 Go de VRAM sur les 8 cartes, et la vitesse en tokens était même supérieure à la vitesse de lecture.
  • Ces GPU-là, on peut vraiment les louer facilement. Si l’on ne doit pas faire tourner un GPU 24/7 longtemps, louer du hosting est bien plus économique que d’acheter. Pour un usage personnel, je n’ai généralement pas besoin d’utiliser les dernières cartes datacenter ; dans ce cas, un Mac Studio ou un Strix Halo suffit, même si c’est un peu plus lent.
  • Ce commentaire m’a vraiment fait passer une bonne journée. C’est clairement un point de vue de datacenter, et la machine la plus puissante que j’ai dans mon tiroir est probablement un ancien iPhone 8.
  • Dire « je n’ai pas de GPU à 25 000 $ chez moi » signifie justement que c’est possible de pouvoir acheter ce type de GPU. Ça veut dire qu’il y a du stock et qu’on peut en « trouver un », pas forcément qu’on a les moyens de l’acheter.

• J’ai testé GPT-OSS-120B sur un MacBook Pro (M4, 128 Go de RAM) pendant un vol transatlantique.
  Il est rapide seulement quand la fenêtre de contexte est petite et que le nombre total de tokens reste bas. Dès qu’on dépasse 10 000 tokens, presque tout prend du temps et part dans une file d’attente.
  Les MCPs, la recherche web, le patch d’URL, etc., sont déjà devenus très importants dans l’expérience d’utilisation d’un LLM. Sans ces fonctionnalités, l’utilité d’un LLM diminue beaucoup.
  Les outils de coding CLI/TUI préconfigurés pour le offline (opencode, etc.) ne fonctionnaient pas de manière fiable avec le modèle.
  Une autre particularité des modèles OSS, en plus de ce qui a déjà beaucoup été mentionné dans les commentaires précédents, c’est aussi ceci :

  • On pouvait déjà enregistrer d’anciennes versions de Wikipédia localement, donc je pense qu’on exposera bientôt beaucoup de données via MCP pour que les IA les recherchent localement comme une recherche web. Or, 99 % des recherches web se font en pratique sur les mêmes 100 à 1000 sites. En bref, quelques Go suffisent pour tout couvrir, ce qui laisse des questions de droits d’auteur.
  • Je suis curieux de savoir si vous utilisez Ollama, LMStudio ou llama.cpp (tweet de ggerganov)
  • Je me demande aussi comment vous avez réglé iogpu.wired_limit_mb. Avec la valeur par défaut, seul ~70 % de la RAM, soit environ 90 Go, semble disponible pour le GPU. Il faut changer le réglage pour mieux l’utiliser.
  • J’ai fait ça avec un processeur M2 Max. Les conversations courtes affichaient plus de 60 tokens/s, mais ça descendait à 30 quand elles devenaient longues. Je me demande ce qui provoque ce ralentissement, ça ne semblait pas être un problème thermique.
  • Je pense que c’est dû à la différence entre le préremplissage compute-bound (où le ratio bande passante/compute du CPU est élevé) et le décodage. Même avec 10 000 tokens de contexte, le premier token arrivait en moins de 0,5 s.

• Plusieurs ingénieurs ont testé vLLM, SGLang et TensorRT-LLM en parallèle. On dit que TensorRT-LLM est le plus rapide, mais c’est en général le plus difficile à configurer, il intègre mal les architectures récentes, et il faut compiler le modèle directement avec la même stack hardware-driver-librairie qu’en production, ce qui est vraiment fastidieux. Le multimodal était quasiment impossible pendant un moment, même les principaux modèles multimodaux de Llama ne marchaient pas correctement. Je me demande si ça vaut vraiment le coup. Par exemple, avec GPT-OSS-120B sur H100 via vLLM, ça tourne sans souci avec un rythme stable de 130 à 140 t/s. Quand on lit le titre, on peut penser qu’on atteint 500 t/s sur un seul GPU, mais en réalité c’est du tensor parallel. Le fait d’emballer séparément TRT-LLM pour gpt-oss est aussi un peu drôle. TRT-LLM est déjà un outil assez déroutant en soi.

  • Quand on expérimente TRT-LLM, il y a pas mal de défis côté DX. Pour le multimodal, on continue souvent d’utiliser vLLM. Mais dans des environnements de trafic massif et à faible latence, comme celui que nous servons, les benchmarks ont montré que TRT-LLM était systématiquement meilleur, donc on a beaucoup investi dans cet outillage.

• GPT-OSS 20B est vraiment simple à installer. Grâce à Llama, je l’ai fait tourner sur mon Mac en 5 minutes.

  • Avec des ressources CPU suffisantes, le 120B tourne sans souci. À la maison, il a suffi de télécharger le fichier GGUF pour mon serveur d’inférence LLM, de faire un git pull, puis de rebâtir llama-server, et c’était prêt. J’ai eu 40 t/s sans modification et environ 50 t/s avec un peu de tuning. Dommage qu’il existe déjà de bien meilleurs modèles : le 120B n’est plus vraiment indispensable. Le travail de ggerganov et de l’équipe llama.cpp pour rendre les LLM accessibles en environnement perso est vraiment impressionnant.
  • On dit que la configuration d’un LLM est difficile ; pourquoi ne pas lui faire configurer lui-même la configuration ? Si une tâche aussi simple n’est pas possible, à quoi sert un LLM ?
  • Je l’ai testé hier : dans toutes les sessions, des informations factuellement incorrectes continuaient d’apparaître. La vitesse et la commodité étaient bonnes, mais sans précision, c’est sans intérêt.
  • Si la mémoire est suffisante, le 120B tourne vraiment facilement.

• J’ai appris en lisant que, pour que le modèle fonctionne correctement, il faut en réalité d’énormes travaux de prétraitement et de tuning. Je pensais naïvement que les réglages par défaut suffisaient.

  • Selon moi, il serait bien que les grands groupes coopèrent activement avec les développeurs de moteurs d’inférence populaires pour inclure la prise en charge de leurs LLM avant la sortie. C’est encore expérimental, sans doute, mais les équipes déploient déjà un vrai effort pour que les développeurs puissent monter des LLM même sur du matériel à bas coût.

• Dans le AI Action Plan des États-Unis, “encourager l’open source et les IA open-weight” arrive juste après “protéger la liberté d’expression et les valeurs américaines”. Ce n’est pas très logique, mais lire les modèles OSS d’OpenAI à ce stade est un peu glaçant. Cela dit, c’est agréable de voir les équipes OSS parler du hardware ; la barrière d’entrée pour la plupart des développeurs, c’est le matériel, donc c’est bienvenu d’avoir ces discussions.

  • L’item “assurons-nous que la frontier AI protège la liberté et les valeurs américaines” était aussi mentionné, mais je suis encore en train de clarifier ma pensée, merci pour votre indulgence. Les modèles IA portent forcément une vision du monde, et je préfère une vision occidentale. Il existe déjà beaucoup de précédents où cela a produit une meilleure société. Au minimum, pourvu que le modèle documente sa propre vision et reste cohérent avec elle, sans tenter en douce de modifier subrepticement la manière de penser des utilisateurs par de la manipulation sociale.

• Je me demande s’il existe un site qui indique clairement quel modèle LLM fonctionne bien selon l’OS et le GPU. La formule empirique la plus fiable pour estimer la VRAM était : paramètres × (precision/8) × 1,2 (référence)

  • J’ai voulu créer une calculatrice similaire, mais en pratique il y a trop de variables (trafic concurrent, etc.). Cette formule est à peu près correcte, mais quand le trafic simultané est élevé, il vaut mieux multiplier par 2 pour être en sécurité.
  • Sur Hugging Face, si vous renseignez les specs hardware/software, il existe une fonctionnalité qui indique la disponibilité sur chaque page modèle (paramètres Hugging Face).
  • Moi, comme j’ai une bonne connexion, la méthode la plus rapide est de télécharger le fichier de poids du modèle et de le faire tourner directement avec plusieurs runners (llama.cpp, LM Studio, vLLM, SGLang, etc.). Il y a trop de variables — runner, implémentation, matériel — pour qu’une calculatrice corresponde parfaitement à l’expérience réelle. La méthode, c’est simplement d’exécuter des tests.
  • Merci pour vos retours. Si la prédiction est difficile, peut-être serait-il utile de créer un site communautaire où chacun partagerait ses expériences d’un runner, d’un matériel, d’un modèle, de paramètres, de quantification, de fonctionnement, de tokens/s, etc. Ce serait vraiment pratique si on pouvait filtrer directement par combinaison matérielle/runner.

• Je veux souligner qu’il est surprenant de ne pas trouver facilement des chiffres précis sur la taille effective des buffers d’un modèle GPT-OSS-120B. Si c’était un langage à type statique, on pourrait estimer la taille des tableaux d’un coup d’œil ; j’aimerais mieux comprendre comment les données réelles (hors poids) circulent et quelle est l’ampleur du flux de sortie. Je me demandais jusqu’à quel débit maximal de “sortie de tokens” en t/s on peut aller en Gigabit Ethernet, et j’ai cherché dans le dépôt GitHub gpt-oss mais je ne trouve pas facilement.

  • Je me demande aussi quels sont les cas d’usage d’applications qui streament les logits pour chaque token successif (tout en respectant les protocoles pour le token sampling). Il faut aussi garder à l’esprit qu’en général, pour préserver la syntaxe, il faut préparer les logits et les tokens avant de les renvoyer pour pouvoir passer à l’inférence suivante.
  • Sur la configuration du modèle Hugging Face, il y a 2880 valeurs (produit de dtype).

• GPT-OSS est plus rapide sur les puces Blackwell avec le support fp4. Je suis en train de développer des moteurs d’entraînement et d’inférence en Rust en ajoutant la prise en charge fp8 et fp4 dans cudarc et candle. Je suis en train de travailler là-dessus pour les supporter dans le moteur Mixlayer (PR cudarc, PR candle, Mixlayer).

  • Je suis utilisateur d’une RTX Pro 6000 ; je me demande si l’inférence gpt-oss-120b est possible maintenant. Les PR semblent déjà mergées, mais j’aimerais savoir si ça tourne réellement.