gpt-oss : Guide pour exécution

Exécutez et affinez les nouveaux modèles open-source d'OpenAI !

OpenAI publie 'gpt-oss-120b' et 'gpt-oss-20b', deux modèles linguistiques ouverts SOTA sous licence Apache 2.0. Les deux modèles 128k de contexte surpassent les modèles ouverts de taille similaire en raisonnement, utilisation d'outils et tâches agentiques. Vous pouvez désormais les exécuter et les affiner localement avec Unsloth !

Exécuter gpt-oss-20bExécuter gpt-oss-120bAffiner gpt-oss

Affiner gpt-oss-20b gratuitement avec notre notebook Colab

Entraîné avec RL, gpt-oss-120b rivalise avec o4-mini et gpt-oss-20b rivalise avec o3-mini. Les deux excellent dans l'appel de fonctions et le raisonnement CoT, surpassant o1 et GPT-4o.

Pour de meilleures performances, assurez-vous que votre mémoire totale disponible (mémoire unifiée + VRAM + RAM système) dépasse la taille du fichier de modèle quantifié que vous téléchargez. Sinon, llama.cpp peut toujours fonctionner via déchargement sur SSD/HDD, mais l'inférence sera plus lente.

gpt-oss - GGUFs Unsloth :

Comprend le corrections de modèle de chatd'Unsloth. Pour de meilleurs résultats, utilisez nos téléversements et entraînez avec Unsloth !

• 20B : gpt-oss-20B

• 120B : gpt-oss-120B

📜Corrections Unsloth pour gpt-oss

Certaines de nos corrections ont été intégrées en amont au modèle officiel d'OpenAI sur Hugging Face. Voir

OpenAI a publié une bibliothèque autonome de parsing et de tokenization appelée Harmony qui permet de tokenizer des conversations au format privilégié par OpenAI pour gpt-oss.

Les moteurs d'inférence utilisent généralement à la place le template de chat jinja et non le package Harmony, et nous avons trouvé quelques problèmes après comparaison directe avec Harmony. Si vous voyez ci-dessous, le haut est la forme correctement rendue par Harmony. Ce qui suit est ce qui est rendu par le template de chat jinja actuel. Il y a pas mal de différences !

Nous avons également créé des fonctions pour vous permettre d'utiliser directement la bibliothèque Harmony d'OpenAI sans template de chat jinja si vous le souhaitez - vous pouvez simplement parser des conversations normales comme ci-dessous :

messages = [
    {"role" : "user", "content" : "What is 1+1?"},
    {"role" : "assistant", "content" : "2"},
    {"role": "user",  "content": "Quelle est la température à San Francisco maintenant ? Et demain ? La date d'aujourd'hui est le 2024-09-30."},
    {"role": "assistant",  "content": "L'utilisateur demande : 'Quel est le temps à San Francisco ?' Nous devons utiliser l'outil get_current_temperature.", "thinking" : ""},
    {"role": "assistant", "content": "", "tool_calls": [{"name": "get_current_temperature", "arguments": '{"location": "San Francisco, California, United States", "unit": "celsius"}'}]},
    {"role": "tool", "name": "get_current_temperature", "content": '{"temperature": 19.9, "location": "San Francisco, California, United States", "unit": "celsius"}'},
]

Puis utilisez la encode_conversations_with_harmony fonction d'Unsloth :

from unsloth_zoo import encode_conversations_with_harmony

def encode_conversations_with_harmony(
    messages,
    reasoning_effort = "medium",
    add_generation_prompt = True,
    tool_calls = None,
    developer_instructions = None,
    model_identity = "You are ChatGPT, a large language model trained by OpenAI.",
)

Le format harmony inclut plusieurs éléments intéressants :

1. reasoning_effort = "medium" Vous pouvez sélectionner low, medium ou high, et cela change le budget de raisonnement de gpt-oss - en général, plus c'est élevé, meilleure est la précision du modèle.

2. developer_instructions est comme un prompt système que vous pouvez ajouter.

3. model_identity est préférable de le laisser tel quel - vous pouvez l'éditer, mais nous ne savons pas si des versions personnalisées fonctionneront.

Nous trouvons plusieurs problèmes avec les templates de chat jinja actuels (il existe plusieurs implémentations dans l'écosystème) :

1. Les appels de fonctions et d'outils sont rendus avec tojson, ce qui est correct si c'est un dict, mais si c'est une chaîne, les guillemets et autres symboles deviennent échappés.

2. Il y a quelques lignes vides supplémentaires dans le template jinja à certaines limites.

3. Les pensées d'appel d'outil du modèle devraient avoir le analysis tag et non final tag.

4. D'autres templates de chat semblent ne pas utiliser du tout <|channel|>final - on devrait utiliser ceci pour le message final de l'assistant. Vous ne devez pas l'utiliser pour des traces de réflexion ou des appels d'outils.

Nos templates de chat pour le GGUF, nos uploads BnB et BF16 et toutes les versions sont corrigés ! Par exemple, en comparant notre format et celui d'Harmony, nous n'obtenons aucun caractère différent :

🔢 Problèmes de précision

Nous avons trouvé plusieurs problèmes de précision principalement sur les Tesla T4 et machines float16 car le modèle a été entraîné en BF16, entraînant des valeurs aberrantes et des débordements. MXFP4 n'est pas réellement pris en charge sur Ampere et GPU plus anciens, donc Triton fournit tl.dot_scaled pour la multiplication de matrices MXFP4. Il upcaste les matrices en BF16 en interne à la volée.

Nous avons créé un notebook d'inférence MXFP4 également dans Colab pour Tesla T4 !

Émulation logicielle permet de cibler des architectures matérielles sans support natif d'opérations microscalées. Pour le moment, dans ce cas, les lhs/rhs microscalés sont upcastés en bf16 type d'élément au préalable pour le calcul du produit scalaire,

Nous avons constaté que si vous utilisez float16 comme type de données d'autocast de précision mixte, vous obtiendrez des infinis après un certain temps. Pour contrer cela, nous avons trouvé qu'exécuter le MoE en bfloat16, puis le laisser en bfloat16 ou float32 est efficace. Si les GPU plus anciens n'ont même pas de support bfloat16 (comme la T4), alors float32 est utilisé.

Nous changeons également toutes les précisions des opérations (comme le routeur) en float32 pour les machines float16.

🖥️ Exécution de gpt-oss

Ci-dessous figurent des guides pour les 20B et 120B variantes du modèle.

Toute quantification plus petite que F16, y compris 2 bits, entraîne une perte d'exactitude minimale, car seules certaines parties (par exemple, les couches d'attention) sont en bits inférieurs tandis que la plupart restent en pleine précision. C'est pourquoi les tailles sont proches du modèle F16 ; par exemple, la version 2 bits (11,5 Go) offre des performances presque équivalentes à la version 16 bits complète (14 Go). Une fois que llama.cpp prendra en charge une meilleure quantification pour ces modèles, nous les uploaderons dès que possible.

La gpt-oss les modèles d'OpenAI incluent une fonctionnalité qui permet aux utilisateurs d'ajuster « l'effort de raisonnement » du modèle. Cela vous donne le contrôle du compromis entre les performances du modèle et sa rapidité de réponse (latence) via la quantité de tokens que le modèle utilisera pour réfléchir.

La gpt-oss les modèles offrent trois niveaux distincts d'effort de raisonnement parmi lesquels vous pouvez choisir :

• Faible : Optimisé pour les tâches nécessitant des réponses très rapides et ne requérant pas de raisonnement complexe en plusieurs étapes.

• Moyen : Un équilibre entre performance et rapidité.

• Élevé : Offre la meilleure performance de raisonnement pour les tâches qui le nécessitent, bien que cela entraîne une latence plus élevée.

⚙️ Paramètres recommandés

OpenAI recommande ces paramètres d'inférence pour les deux modèles :

temperature=1.0, top_p=1.0, top_k=0

• Température de 1.0

• Top_K = 0 (ou essayez 100 pour éventuellement de meilleurs résultats)

• Top_P = 1.0

• Contexte minimum recommandé : 16 384

• Longueur maximale de la fenêtre de contexte : 131 072

Modèle de chat :

<|start|>system<|message|>Vous êtes ChatGPT, un grand modèle de langage entraîné par OpenAI.\nCoupure des connaissances : 2024-06\nDate actuelle : 2025-08-05\n\nRaisonnement : medium\n\n# Canaux valides : analysis, commentary, final. Le canal doit être inclus pour chaque message.<|end|><|start|>user<|message|>Bonjour<|end|><|start|>assistant<|channel|>final<|message|>Bonjour !<|end|><|start|>user<|message|>Quelle est la somme de 1+1 ?<|end|><|start|>assistant

Le token de fin de phrase/génération : EOS est <|return|>

Exécuter gpt-oss-20B

Pour atteindre des vitesses d'inférence de plus de 6 tokens par seconde pour notre quantification Dynamic 4-bit, disposez d'au moins 14Go de mémoire unifiée (VRAM et RAM combinées) ou 14Go de RAM système seulement. Comme règle générale, votre mémoire disponible doit correspondre ou dépasser la taille du modèle que vous utilisez. Lien GGUF : unsloth/gpt-oss-20b-GGUF

REMARQUE : Le modèle peut fonctionner avec moins de mémoire que sa taille totale, mais cela ralentira l'inférence. La mémoire maximale n'est nécessaire que pour les vitesses les plus rapides.

Suivez les bonnes pratiques ci-dessus. Elles sont les mêmes que pour le modèle 120B.

Vous pouvez exécuter le modèle sur Google Colab, Docker, LM Studio ou llama.cpp pour l'instant. Voir ci-dessous :

Vous pouvez exécuter gpt-oss-20b gratuitement avec notre notebook Google Colab

🐋 Docker : Tutoriel Exécuter gpt-oss-20b

Si vous avez déjà Docker Desktop, il vous suffit d'exécuter la commande ci-dessous et c'est fini :

docker model run hf.co/unsloth/gpt-oss-20b-GGUF:F16

✨ Llama.cpp : Tutoriel Exécuter gpt-oss-20b

1. Obtenez la dernière llama.cpp sur GitHub ici. Vous pouvez aussi suivre les instructions de compilation ci-dessous. Changez -DGGML_CUDA=ON en -DGGML_CUDA=OFF si vous n'avez pas de GPU ou si vous voulez simplement de l'inférence CPU. Pour les appareils Apple Mac / Metal, définissez -DGGML_CUDA=OFF puis continuez comme d'habitude - le support Metal est activé par défaut.

apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp

1. Vous pouvez le récupérer directement depuis Hugging Face via :

   ./llama.cpp/llama-cli \
       -hf unsloth/gpt-oss-20b-GGUF:F16 \
       --jinja -ngl 99 --ctx-size 16384 \
       --temp 1.0 --top-p 1.0 --top-k 0

2. Téléchargez le modèle via (après avoir installé pip install huggingface_hub hf_transfer ). Si les téléchargements sont bloqués, voir Hugging Face Hub, débogage XET

# !pip install huggingface_hub hf_transfer
import os
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
from huggingface_hub import snapshot_download
snapshot_download(
    repo_id = "unsloth/gpt-oss-20b-GGUF",
    local_dir = "unsloth/gpt-oss-20b-GGUF",
    allow_patterns = ["*F16*"],
)

Exécuter gpt-oss-120b :

Pour atteindre des vitesses d'inférence de plus de 6 tokens par seconde pour notre quantification 1-bit, nous recommandons au moins 66Go de mémoire unifiée (VRAM et RAM combinées) ou 66Go de RAM système seulement. Comme règle générale, votre mémoire disponible doit correspondre ou dépasser la taille du modèle que vous utilisez. Lien GGUF : unsloth/gpt-oss-120b-GGUF

REMARQUE : Le modèle peut fonctionner avec moins de mémoire que sa taille totale, mais cela ralentira l'inférence. La mémoire maximale n'est nécessaire que pour les vitesses les plus rapides.

Suivez les bonnes pratiques ci-dessus. Elles sont les mêmes que pour le modèle 20B.

📖 Llama.cpp : Tutoriel Exécuter gpt-oss-120b

Pour gpt-oss-120b, nous utiliserons spécifiquement Llama.cpp pour l'inférence optimisée.

Si vous voulez une version non quantifiée en pleine précision, utilisez nos versions F16 !

1. Obtenez la dernière llama.cpp sur GitHub ici. Vous pouvez aussi suivre les instructions de compilation ci-dessous. Changez -DGGML_CUDA=ON en -DGGML_CUDA=OFF si vous n'avez pas de GPU ou si vous voulez simplement de l'inférence CPU.

   apt-get update
   apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
   git clone https://github.com/ggml-org/llama.cpp
   cmake llama.cpp -B llama.cpp/build \
       -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
   cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-gguf-split
   cp llama.cpp/build/bin/llama-* llama.cpp

2. Vous pouvez utiliser directement llama.cpp pour télécharger le modèle mais je suggère normalement d'utiliser huggingface_hub Pour utiliser llama.cpp directement, faites :

   ./llama.cpp/llama-cli \
       -hf unsloth/gpt-oss-120b-GGUF:F16 \
       --ctx-size 16384 \
       --n-gpu-layers 99 \
       -ot ".ffn_.*_exps.=CPU" \
       --temp 1.0 \
       --min-p 0.0 \
       --top-p 1.0 \
       --top-k 0.0 \

3. Ou, téléchargez le modèle via (après avoir installé pip install huggingface_hub hf_transfer Nous suivons des étapes similaires à celles ci‑dessus, cependant cette fois nous devrons également effectuer des étapes supplémentaires car le modèle est si volumineux.

   # !pip install huggingface_hub hf_transfer
   import os
   os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "0" # Peut parfois limiter le débit, donc mettez à 0 pour désactiver
   from huggingface_hub import snapshot_download
   snapshot_download(
       repo_id = "unsloth/gpt-oss-120b-GGUF",
       local_dir = "unsloth/gpt-oss-120b-GGUF",
       allow_patterns = ["*F16*"],
   )

4. Exécutez le modèle en mode conversation et essayez n'importe quelle invite.

5. Modifier --threads -1 pour le nombre de threads CPU, --ctx-size 262114 pour la longueur de contexte, --n-gpu-layers 99 pour le déchargement sur GPU du nombre de couches. Essayez de l'ajuster si votre GPU manque de mémoire. Supprimez-le également si vous avez uniquement une inférence CPU.

Utilisez -ot ".ffn_.*_exps.=CPU" pour décharger toutes les couches MoE sur le CPU ! Cela vous permet effectivement d'adapter toutes les couches non-MoE sur 1 GPU, améliorant les vitesses de génération. Vous pouvez personnaliser l'expression regex pour adapter plus de couches si vous avez plus de capacité GPU. Plus d'options discutées ici.

./llama.cpp/llama-cli \
    --model unsloth/gpt-oss-120b-GGUF/gpt-oss-120b-F16.gguf \
    --ctx-size 16384 \
    --n-gpu-layers 99 \
    -ot ".ffn_.*_exps.=CPU" \
    --temp 1.0 \
    --min-p 0.0 \
    --top-p 1.0 \
    --top-k 0.0 \

🛠️ Amélioration de la vitesse de génération

Si vous avez plus de VRAM, vous pouvez essayer de décharger plus de couches MoE, ou de décharger des couches entières elles-mêmes.

Normalement, -ot ".ffn_.*_exps.=CPU" décharge toutes les couches MoE sur le CPU ! Cela vous permet effectivement de placer toutes les couches non-MoE sur 1 GPU, améliorant les vitesses de génération. Vous pouvez personnaliser l'expression regex pour décharger plus de couches si vous avez plus de capacité GPU.

Si vous avez un peu plus de mémoire GPU, essayez -ot ".ffn_(up|down)_exps.=CPU" Cela décharge les couches MoE de projection up et down.

Essayez -ot ".ffn_(up)_exps.=CPU" si vous avez encore plus de mémoire GPU. Cela ne décharge que les couches MoE de projection up.

Vous pouvez aussi personnaliser la regex, par exemple -ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU" signifie décharger les couches MoE gate, up et down mais uniquement à partir de la 6e couche.

La dernière version de llama.cpp introduit aussi un mode haut débit. Utilisez llama-parallel. Lisez-en plus à ce sujet ici. Vous pouvez aussi quantifier le cache KV en 4 bits par exemple pour réduire les mouvements VRAM / RAM, ce qui peut aussi accélérer le processus de génération.

🦥 Affinage de gpt-oss avec Unsloth

Mise à jour du 28 août: Vous pouvez désormais exporter/enregistrer votre modèle gpt-oss affiné en QLoRA vers llama.cpp, vLLM, HF, etc.

Nous avons également introduit Unsloth Flex Attention qui permet >8× longueurs de contexte plus longues, >50% de réduction de l'utilisation de la VRAM et >1.5× entraînement plus rapide par rapport à toutes les implémentations. Lire la suite ici

L'affinage gpt-oss d'Unsloth est 1,5x plus rapide, utilise 70% de VRAM en moins et prend en charge des longueurs de contexte 10x plus longues. L'entraînement QLoRA de gpt-oss-20b tient sur 14Go de VRAM, et gpt-oss-120b fonctionne sur 65Go de VRAM.

• Exigences QLoRA : gpt-oss-20b = 14Go VRAM • gpt-oss-120b = 65Go VRAM.

• Exigences LoRA BF16 : gpt-oss-20b = 44Go VRAM • gpt-oss-120b = 210Go VRAM.

Lisez notre tutoriel pas à pas pour l'affinage de gpt-oss :

Tutoriel : Comment affiner gpt-oss

Vous pouvez désormais exporter/enregistrer votre modèle gpt-oss affiné en QLoRA vers llama.cpp, vLLM, HF, etc.

Notebooks Unsloth gratuits pour affiner gpt-oss :

• gpt-oss-20b Notebook Raisonnement + Conversation

Apprentissage par renforcement (GRPO)

Unsloth prend désormais en charge le RL pour gpt-oss ! Nous avons créé deux notebooks, pour plus de détails, lisez notre blog spécifique sur le RL pour gpt-oss : gpt-oss RL

notebook 2048 (Exemple officiel OpenAI)	Notebook de génération de kernel

💾NOUVEAU : Sauvegarde en GGUF, vLLM après l'entraînement de gpt-oss

Vous pouvez désormais affiner gpt-oss en QLoRA et directement enregistrer, exporter ou fusionner le modèle vers llama.cpp, vLLM, ou HF - pas seulement Unsloth. Nous publierons bientôt un notebook gratuit, nous l'espérons.

Auparavant, tout modèle gpt-oss affiné en QLoRA était restreint à l'exécution dans Unsloth. Nous avons supprimé cette limitation en introduisant la déquantification à la demande de MXFP4 des modèles de base (comme gpt-oss) pendant le processus de fusion LoRA. Cela rend possible exporter votre modèle affiné en format bf16.

Après l'affinage de votre modèle gpt-oss, vous pouvez désormais le fusionner en format 16 bits avec une unique commande:

model.save_pretrained_merged(save_directory, tokenizer)

Si vous préférez fusionner le modèle et le pousser directement vers le hub hugging-face, vous pouvez le faire en utilisant :

model.push_to_hub_merged(repo_name, tokenizer=tokenizer, token=hf_token)

💡Rendre l'affinage efficace de gpt-oss opérationnel

Nous avons constaté que bien que MXFP4 soit très efficace, il ne prend pas en charge nativement l'entraînement avec gpt-oss. Pour surmonter cette limitation, nous avons implémenté des fonctions d'entraînement personnalisées spécifiquement pour les couches MXFP4 en les mimant via Bitsandbytes quantification NF4.

Nous avons utilisé directement la bibliothèque Triton Kernels d'OpenAI pour permettre l'inférence MXFP4. Pour l'affinage/entraînement cependant, les kernels MXFP4 ne prennent pas encore en charge l'entraînement, car la passe arrière n'est pas encore implémentée. Nous travaillons activement à son implémentation dans Triton ! Il existe un flag appelé W_TRANSPOSE comme mentionné ici, qui devrait être implémenté. La dérivée peut être calculée par la transposée des matrices de poids, et nous devons donc implémenter l'opération de transposition.

Si vous voulez entraîner gpt-oss avec une bibliothèque autre qu'Unsloth, vous devrez upcaster les poids en bf16 avant l'entraînement. Cette approche, cependant, augmente considérablement à la fois l'utilisation de la VRAM et le temps d'entraînement jusqu'à 300% d'utilisation mémoire en plus! TOUTES les autres méthodes d'entraînement nécessiteront un minimum de 65Go de VRAM pour entraîner le modèle 20b tandis qu'Unsloth ne nécessite que 14Go de VRAM (-80%).

Comme les deux modèles utilisent une architecture MoE, le modèle 20B sélectionne 4 experts sur 32, tandis que le modèle 120B sélectionne 4 sur 128 par token. Pendant l'entraînement et la publication, les poids sont stockés au format MXFP4 en tant que nn.Parameter objets, et non en tant que nn.Linear couches, ce qui complique la quantification, d'autant plus que les experts MoE/MLP représentent environ 19B des 20B paramètres.

Pour permettre BitsandBytes la quantification et l'affinage mémoire-efficace, nous avons converti ces paramètres en nn.Linear couches. Bien que cela ralentisse légèrement les opérations, cela permet l'affinage sur des GPU à mémoire limitée, un compromis valable.

Guide d'affinage des jeux de données

Bien que gpt-oss ne prenne en charge que le raisonnement, vous pouvez tout de même l'affiner avec un jeu de données, mais cela peut affecter sa capacité de raisonnement. Si vous souhaitez conserver ses capacités de raisonnement (optionnel), vous pouvez utiliser un mélange de réponses directes et d'exemples de chain-of-thought. Utilisez au moins 75 % de raisonnement et 25 % sans raisonnement dans votre jeu de données pour faire en sorte que le modèle conserve ses capacités de raisonnement.

Notre notebook conversationnel gpt-oss-20b utilise l'exemple d'OpenAI qui est le jeu de données Multilingual-Thinking de Hugging Face. Le but d'utiliser ce jeu de données est de permettre au modèle d'apprendre et de développer des capacités de raisonnement dans ces quatre langues distinctes.