Muse Glimmer atteint 230 tokens/s sur une seule RTX 5090 : le support SGLang dès le premier jour est la véritable histoire de ce lancement

Deux cent trente tokens par seconde, c'est un chiffre rapide pour n'importe quel modèle. Pour Muse Glimmer — le modèle dense de 30B à poids ouverts de Meta, issu de Meta Superintelligence Labs, sorti le 10 août 2026 sous licence Apache 2.0 — c'est le chiffre qui sépare un modèle « qui tourne sur mon GPU » d'un modèle « qui sert un vrai agent ». SGLang a annoncé un support dès le premier jour pour Muse Glimmer le jour même où les poids ont été mis en ligne, et sa mesure publiée sur une seule GeForce RTX 5090 est de 236,4 tokens par seconde par utilisateur au batch 1, avec la quantification NVFP4 et le drafter de décodage spéculatif DFlash de Meta tous deux activés.

Cette figure à elle seule raconte l'essentiel de cette version, mais il vaut la peine de s'attarder sur le reste, car l'intéressant n'est pas la vitesse affichée en titre. Ce qui est intéressant, c'est que le modèle fonctionne également immédiatement sur une RTX PRO 6000, sur un NVIDIA DGX Spark et sur Apple silicon via MLX — et que SGLang présente ce travail comme une collaboration avec Meta Superintelligence Labs plutôt que comme un ajout communautaire après coup. C'est la première fois depuis longtemps qu'un modèle Meta quasi-frontier est conçu autour de la stack de service, et non pas seulement autour des poids.

Ce que « day-0 support » signifie réellement ici

Le support Day-0 dans SGLang v0.5.17 signifie que le modèle n'a pas été ajouté après coup : le travail sur l'exécution est arrivé dans la même fenêtre de publication que les poids, avec un chemin spécialement conçu pour le matériel que Meta vise réellement. Le backend SM120 de SGLang couvre la gamme desktop et workstation Blackwell — la RTX 5090, la RTX PRO 6000 et la DGX Spark exécutent le même chemin optimisé — tandis que les puces Apple bénéficient d'un backend MLX natif plutôt que d'un port lent.

La pile logicielle optimisée par SGLang et Meta est spécifique. Le modèle fonctionne sous la forme d'un checkpoint NVFP4 de 18 Go, associé à un drafter DFlash BF16 de 5 Go — le modèle compagnon de décodage spéculatif que Meta a entraîné pour Muse Glimmer. Cette combinaison tient dans une carte de 32 Go avec de la marge, et l'ensemble du parcours de quantification mixte NVFP4-plus-MXFP8 occupe environ 19,5 Go en mémoire résidente. Côté SGLang, les notes de version citent trois mécanismes de fiabilité dans la même lignée : le décodage spéculatif DFlash, RadixAttention pour la mise en cache des préfixes, et les graphes CUDA interruptibles.

Le nombre, et ce qu'il est et n'est pas

Les chiffres publiés par SGLang pour la RTX 5090, tous avec NVFP4 et le chemin SM120, se décomposent comme suit :

• Décodage mono-utilisateur (lot 1) — 63,9 tokens/s en standard, 236,4 tokens/s avec le décodage spéculatif DFlash. Cette amélioration de 3,7x est la valeur interactive, celle qui détermine si un agent local donne l’impression d’une conversation ou d’une file d’attente.

• Débit agrégé (lot 8) — 501 tokens/s en standard, 1 452 tokens/s avec DFlash. Il s'agit du débit d'un serveur local traitant plusieurs requêtes à la fois.

À titre de comparaison, un GGUF q4_k_m sur le même GPU — la méthode que la plupart des gens utiliseront avec des runtimes de type llama.cpp — atteint 72,6 tokens/s en standard et 140,7 tokens/s avec DFlash. La voie NVFP4 est nettement en avance.

Ce sont les chiffres publiés par SGLang et Meta le jour du lancement, et non des reproductions indépendantes — l'étiquette honnête est « rapporté par le fournisseur et le framework », et la vérification par la communauté arrivera dans les semaines à venir. Mais la tendance est cohérente entre les deux piles technologiques qui ont annoncé des chiffres. Dans llama.cpp, Meta a rapporté 74,9 à 233,4 tokens/s sur une RTX 5090 avec DFlash, soit un gain de 3,1x ; le M5 Max passe de 26,6 à 50,2 ; le M4 Max de 23,7 à 37,8. Deux runtimes différents, deux styles de mesure différents, même ordre de grandeur : un modèle de 30B qui décode à plus de 200 tokens par seconde sur un GPU grand public, et DFlash qui triple environ le débit sur chaque configuration Nvidia ayant publié des chiffres.

Pourquoi « sert » compte plus que « court »

Le blog matériel de Meta fait une affirmation plus tranchée que les chiffres pour ordinateur de bureau. Sur NVIDIA Blackwell Ultra — la génération pour centre de données, pas la carte de bureau — le blog cite plus de 20 000 tokens par seconde par GPU en BF16/NVF4, avec SGLang et vLLM tous deux mentionnés comme piles open source prises en charge. C'est une tout autre catégorie, et c'est ce qui révèle ce que Meta construit réellement : les mêmes poids sont censés fonctionner partout, d'un ordinateur portable à un rack de serveurs GPU, et les frameworks de serving ont été traités comme des éléments de première classe dès le premier jour, plutôt que comme des ports à écrire plus tard.

La moitié de l'histoire qui concerne la fiabilité compte tout autant que la vitesse. Un agent local qui meurt en pleine tâche parce que la couche de service a bafouillé n'est pas vraiment meilleur qu'un agent cloud qui a été limité en débit. Les mécanismes de la pile jour-0 — décodage spéculatif interruptible, mise en cache de préfixes qui rend les contextes d'agents longs économiques à reprendre, et un drafter ajusté au modèle de base — sont précisément les éléments qui rendent les agents locaux toujours actifs survivables. C'est ce « vitesse et fiabilité » que le lancement visait, et c'est une véritable position d'ingénierie, pas une formule marketing.

Ce que vous pouvez réellement en faire

Muse Glimmer est un modèle dense multimodal de 30B — entrée texte et image via un encodeur de perception figé, sortie texte — entraîné sur plus de 100 langues, avec une fenêtre de contexte de 131 072 jetons et une date limite de connaissances au 4 janvier 2026. Sa mission est le travail d’agent sans glamour : appels de fonction, utilisation d’outils, gestion de calendrier et de fichiers, évaluation LLM-as-a-judge, et tâches en plusieurs étapes avec récupération après échec — lorsqu’un appel d’outil échoue, le modèle est entraîné à diagnostiquer et à réessayer plutôt que de s’arrêter. Il expose des niveaux d’effort de raisonnement (de low à xhigh) que vous définissez dans le prompt système, ce qui permet d’échanger la latence contre la profondeur sur les mêmes poids.

Le chiffre de 230 tokens par seconde est ce qui rend tout cela utilisable sur une seule machine. En dessous d’environ 50 tokens/s, un agent interactif donne l’impression d’une session de débogage à distance ; au-delà de 200, il donne l’impression d’un outil local. C’est tout l’argument du modèle en un seul chiffre, et c’est la raison pour laquelle la liste de matériel — RTX 5090, RTX PRO 6000, DGX Spark, Macs MLX — se lit comme un guide d’achat pour l’ère des agents locaux plutôt que comme une note de compatibilité en bas de page.

Ce que ça coûte

Muse Glimmer lui-même est gratuit — des poids sous licence Apache 2.0 sur Hugging Face à meta-models/Muse-Glimmer-30B, avec des quantifications GGUF déjà publiées pour les environnements d’exécution de type llama.cpp et aucune API Meta publique. Le coût réel réside dans le matériel sous-jacent : un checkpoint NVFP4 de 18 Go plus le drafter de 5 Go signifient qu’il vous faut une carte de 24 Go ou 32 Go, ou un Mac haut de gamme de la série M. Si vous possédez déjà cela, le coût marginal d’un agent local toujours actif est l’électricité. Si ce n’est pas le cas, le GPU est le poste de dépense, et c’est la façon honnête de comparer un « modèle gratuit » à une API hébergée.

Lorsque vous faites cette comparaison, chiffrez les deux côtés honnêtement. Chez OrcaRouter, le prix que vous voyez pour chacun des plus de 200 modèles hébergés est le prix catalogue du fournisseur répercuté sans marge, à 0 % de majoration. Ainsi, une baisse de prix du fournisseur est répercutée ici le jour même — ce qui rend le calcul local-vs-hébergé honnête. Muse Glimmer lui-même n'est pas sur OrcaRouter aujourd'hui, car aucun fournisseur d'inférence ne le propose encore ; il est distribué en téléchargement. Dès qu'un fournisseur commencera à le proposer, la même clé qui donne accès au reste du catalogue y donnera accès, et le basculement automatique est le mécanisme qui permet de diriger en toute sécurité le trafic de production vers un modèle tout nouveau, annoncé par le fournisseur, avant même qu'il n'ait un historique indépendant.

L'histoire plus importante derrière la vitesse.

Lisez le travail SGLang du jour 0 comme un signal, et la sortie cesse d'être un simple modèle. Muse Glimmer est une version distillée du fleuron propriétaire de Meta, Muse Spark 1.2, et Meta a déclaré que les poids du modèle enseignant arriveront « dans les semaines à venir ». Un agent local de 30B avec une pile de service optimisée, un modèle enseignant sur le point d'être ouvert, et un fonds communautaire d'un milliard de dollars annoncé en parallèle — ce n'est pas une mise à jour mineure. C'est l'amorce d'une gamme open-weight résolument destinée au marché des agents locaux, et le support des frameworks dès le premier jour montre que Meta veut que les gens l'exécutent réellement, et pas seulement le téléchargent.

La réserve à garder en tête : tous les chiffres de vitesse et de benchmark associés à ce lancement jusqu'ici proviennent des fournisseurs ou des frameworks. Les chiffres de débit sont cohérents entre deux stacks indépendants, ce qui est rassurant, mais des benchmarks indépendants, une entrée Artificial Analysis et des reproductions dans le monde réel sont ce qui confirmera l'histoire des 230 tokens par seconde — et ils arrivent généralement en quelques semaines après une sortie de ce type.

Ce qu’il faut surveiller, par ordre approximatif de rapidité : la publication des poids ouverts de Muse Spark 1.2 (la lecture stratégique de « Meta is back » en dépend) ; les premières reproductions indépendantes du débit sur du matériel non-Nvidia, où le chemin MLX est celui à suivre ; et le premier fournisseur d’inférence qui met en place un endpoint Glimmer — c’est le moment où les arguments « modèle local gratuit » et « API hébergée » cessent d’être hypothétiques et deviennent un choix que l’on peut faire d’une seule touche.