gpt-oss-120b

L'essentiel

• MoE de 117 Md de paramètres dont 5,1 Md actifs par token : il tient dans 128 Go et génère vite parce qu'il lit peu de poids par token ¹.
• Licence Apache 2.0, complétée d'une courte « usage policy » : exploitable commercialement ¹.
• Mesures publiées sur Strix Halo : 51 à 56 t/s en génération sous llama.cpp, mais environ 30 t/s sous LM Studio ROCm. Sources contradictoires, non arbitrées.
• Le français n'est pas listé sur la fiche modèle : qualité à mesurer.
• C'est le point de départ de la Box, pas une décision définitive (voir Q-009).

Pourquoi ce modèle nous intéresse

La machine candidate a une bande passante mémoire d'environ 212 Go/s mesurés ¹¹. En génération, le débit est borné par la quantité de poids lus à chaque token. Un modèle dense de 70 Md en Q4 lit environ 42 Go par token et plafonne vers 5 t/s. gpt-oss-120b ne lit que les poids de ses experts actifs (5,1 Md, soit quelques Go) : il produit dix fois plus de tokens par seconde pour une empreinte mémoire comparable (59 Go). C'est le compromis qualité / vitesse le plus favorable identifié pour une machine à mémoire unifiée.

Il supporte nativement le function calling, les sorties structurées et un niveau de raisonnement réglable (reasoning_effort bas, moyen ou haut) ¹. Pour un RAG avec outils (recherche documentaire, citation), ce sont des prérequis.

Caractéristiques

Licence et usage commercial

Apache 2.0, assortie d'une « small complementary use policy » ¹. Pas de seuil d'utilisateurs, pas de clause géographique, pas d'obligation d'affichage. La politique d'usage complémentaire doit être relue avant intégration dans une offre commerciale ; elle n'a pas été analysée dans cette recherche.

Français

Non vérifié. La fiche modèle ne liste pas les langues supportées ¹. Aucun benchmark français publié n'a été trouvé pour ce modèle. C'est une des raisons de l'expérimentation comparer la qualité française des modèles. Pellegrini note par ailleurs un « poor tool calling » dans ses tests ⁶ : à vérifier dans nos conditions (format harmony correctement activé ou non).

Performances publiées sur Strix Halo

Sous vLLM sur Strix Halo : aucune mesure trouvée.

Mémoire et contexte

• Poids : GGUF officiel 59,02 Go ; environ 64 Go de mémoire recommandés par le guide llama.cpp ³. Les GGUF « Q8_0 » (63,4 Go) ou « Q4_K_M » (62,8 Go) ne réduisent pas la taille, car les experts restent en MXFP4 ⁴ : la quantification supplémentaire n'a pas d'intérêt.
• KV cache (estimation, formule 2 × couches × têtes KV × dim. tête × octets) : 36 × 8 × 64 × 2 × 2 = 73 728 octets par token en f16, borne haute puisque la moitié des couches utilise une fenêtre glissante de 128 tokens. Soit environ 0,6 Go pour 8k tokens, 2,4 Go pour 32k, 9,7 Go pour 128k, par slot. En q8_0, moitié moins.
• Budget indicatif (estimation) : 59 Go de poids + 4 slots × 32k en q8_0 (environ 5 Go) + système : moins de 70 Go, dans la limite GTT recommandée par AMD. Détail dans KV cache.

Limites

• Qualité du français non documentée.
• Format harmony : un runtime mal configuré dégrade les appels d'outils.
• 59 Go de poids : le modèle occupe la moitié de la mémoire ; cohabitation avec embeddings, reranker et base vectorielle à vérifier.
• Aucune mesure multi-utilisateurs certaine sur ce modèle (le chiffre « 168 t/s agrégés » n'identifie pas le modèle).

À tester

• Benchmark gpt-oss-120b à 1 utilisateur : Vulkan vs ROCm, pp512/tg128, profondeurs 0 / 4k / 32k.
• Montée en charge de 1 à 10 utilisateurs avec -np 4 puis -np 8.
• Qualité française et fidélité des citations sur un jeu de dossiers juridiques anonymisés.
• Fiabilité du function calling avec --jinja et le template harmony.