SGLang ajoute la prise en charge de gpt-oss-120b sur les GPU Hopper et Blackwell

Quand OpenAI publie un modèle ouvert, la première question des ingénieurs ne porte pas sur la qualité des réponses. Elle est ailleurs : sur quel matériel le faire tourner, et combien coûtera un million de tokens ? Tant qu’un moteur d’inférence ne le prend pas correctement en charge, le modèle reste une belle promesse dans un communiqué de presse. L’annonce de LMSYS Org paraît donc modeste, mais elle compte pour les équipes sur le terrain : SGLang prend désormais en charge gpt-oss-120b sur les GPU Nvidia des générations Hopper et Blackwell.

Ce qui a été annoncé

L’équipe LMSYS, qui développe SGLang, a annoncé la prise en charge de gpt-oss-120b sur deux architectures à la fois : Hopper (H100, H200) et Blackwell (famille B200). Eigen AI Labs, Nvidia, les développeurs de SGLang et la communauté open source ont participé aux travaux. Le message précise aussi que cette prise en charge est arrivée quelques jours après la sortie du modèle, mais le chiffre exact est tronqué dans le texte disponible : nous ne le reprenons donc pas.

Voici le contexte. gpt-oss-120b repose sur une architecture Mixture of Experts : seule une petite partie des paramètres est activée pour chaque token. Selon OpenAI, le modèle compte environ 117 milliards de paramètres au total, dont environ 5 milliards actifs. Ses poids sont distribués sous licence Apache 2.0 et quantifiés au format MXFP4, ce qui permet de le faire tenir sur une seule carte de 80 Go. Ces modèles sont particulièrement sensibles à la qualité du moteur : la manière dont celui-ci répartit les experts et exploite les kernels de calcul en basse précision détermine à la fois la vitesse et le coût.

Pourquoi cela compte en pratique

Imaginez une situation classique. Vous développez un assistant interne pour les développeurs, ou un agent qui parcourt la documentation et appelle des outils. Vous préférez éviter d’envoyer du code et des données internes à une API externe. Vous disposez de vos propres GPU ou en louez auprès d’un fournisseur cloud. Il reste à choisir le moteur qui servira le modèle : vLLM, TensorRT-LLM, SGLang ou une autre solution.

La prise en charge dans SGLang ajoute une option opérationnelle à cette liste. SGLang est réputé pour réutiliser efficacement les préfixes des requêtes, un avantage précieux pour les agents dont chaque requête reprend un long prompt système et l’historique de la conversation. C’est précisément un profil de charge courant pour gpt-oss-120b, présenté comme un modèle destiné au raisonnement et à l’utilisation d’outils.

Blackwell mérite aussi une attention particulière. La prise en charge logicielle du nouveau matériel arrive souvent avec du retard, et les propriétaires de B200 tout juste acquis attendent parfois des mois pour disposer de kernels optimisés. Lorsque la prise en charge est annoncée simultanément pour Hopper et Blackwell, les équipes n’ont pas besoin de maintenir deux piles logicielles distinctes pour leurs anciennes et leurs nouvelles cartes.

Ce que le message ne dit pas

Il faut préciser les limites de cette annonce. Elle ne fournit aucun chiffre : ni débit en tokens par seconde, ni latence, ni comparaison avec d’autres moteurs. Elle ne donne pas non plus de données sur le comportement du modèle avec un contexte long et de nombreuses requêtes simultanées. Il s’agit d’une annonce de prise en charge, pas d’un benchmark : elle ne suffit donc pas, à elle seule, pour décider d’une migration.

De même, « pris en charge » ne signifie pas « optimal ». Les premières versions d’une intégration fonctionnent généralement correctement, mais n’exploitent pas toujours tout le potentiel du matériel. Les gains de vitesse arrivent dans les versions suivantes : mieux vaut donc suivre les mises à jour de SGLang que rester indéfiniment sur la première version.

Que faire ?

Si vous hébergez déjà vos propres LLM, faites un petit essai. Prenez un flux réel de requêtes ou un enregistrement de ce flux, déployez gpt-oss-120b dans SGLang et dans votre moteur actuel, puis comparez trois indicateurs : le délai avant le premier token, le débit en tokens par seconde sous charge et le coût des heures GPU rapporté à mille requêtes. Vérifiez séparément les appels d’outils et les sorties structurées, car c’est là que les différences entre moteurs apparaissent le plus souvent.

Même sans matériel à vous, cette nouvelle reste utile : plus les moteurs capables de servir un modèle ouvert sont nombreux, plus la concurrence entre fournisseurs d’inférence s’intensifie et plus le prix par token baisse. Choisir des poids ouverts cesse d’être un pari risqué lorsqu’il existe plusieurs solutions éprouvées pour exécuter le modèle.