GPT-OSS-120B peut très bien tourner avec seulement 8 Go de VRAM

• En utilisant l’option --cpu-moe de llama-cpp, les couches d’experts MOE sont traitées sur le CPU, tandis que seules les couches d’attention sont déportées sur le GPU, ce qui permet d’obtenir de bonnes performances de préremplissage avec 5 à 8 Go de VRAM
• Seuls les paramètres non experts résident sur le GPU, comme le cache KV, les poids et activations d’attention, les tables de routage, LayerNorm, etc., ce qui réduit fortement l’usage mémoire
• Il est possible de faire tourner assez facilement le modèle 120B avec un GPU de niveau RTX 3060Ti et 64 à 96 Go de RAM système, avec les meilleures performances sur les GPU compatibles BF16 (RTX 3000+)
• Avec 5 Go de VRAM, les performances mesurées atteignent 8,15 ms par token (122,66 tokens/s), et avec 8 Go de VRAM elles montent jusqu’à 7,44 ms par token (134,44 tokens/s)
• L’architecture 120B est conçue pour être optimisée sur du matériel grand public, permettant une exécution rapide même dans des environnements limités en ressources GPU

---

Structure CPU-MOE et offloading GPU

• L’option --cpu-moe permet de traiter toutes les couches d’experts (MOE) sur le CPU
  • Exemple : --n-cpu-moe 36 → exécute les 36 blocs MOE sur le CPU
  • Si nécessaire, il est possible de déplacer une partie des MOE vers le GPU pour ajuster les performances
• Pour économiser la VRAM, seuls les éléments suivants restent en mémoire sur le GPU
  • cache KV (séquence)
  • poids et activations d’attention
  • tables de routage
  • LayerNorm et autres paramètres non experts
• Les poids MOE ne résident pas sur le GPU, ce qui évite la charge des gros paramètres MLP

Mémoire et prérequis matériels

• GPU : 5 à 8 Go de VRAM suffisent (ex. : RTX 3060Ti)
• Un GPU compatible BF16 est optimal (série RTX 3000 ou plus)
• RAM système : minimum 64 Go, idéalement 96 Go
  • En exploitant mmap sous Linux, les couches d’experts « chaudes » peuvent rester en mémoire même si le modèle complet n’y tient pas

Chiffres de performance

Environnement avec 5 Go de VRAM

• Traitement du prompt : 8,15 ms/token (122,66 tokens/s)
• Inférence : 55,44 ms/token (18,04 tokens/s)

Environnement avec 8 Go de VRAM (--n-cpu-moe 36, le reste sur GPU)

• Traitement du prompt : 7,44 ms/token (134,44 tokens/s)
• Inférence : 39,03 ms/token (25,62 tokens/s)

Environnement avec 22 Go de VRAM (une partie des MOE sur GPU)

• Traitement du prompt : 6,13 ms/token (163,01 tokens/s)
• Inférence : 32,45 ms/token (30,82 tokens/s)

Conclusion

• La conception de GPT-OSS-120B est optimisée pour faire tourner rapidement de grands modèles même sur du matériel grand public
• Grâce à son architecture CPU-MOE qui réduit la consommation de VRAM tout en conservant de bonnes performances, il convient particulièrement aux environnements où les ressources GPU sont limitées

---

Questions clés et réponses

Q1. Quelle est la consommation réelle de VRAM dans cette configuration ?

• Auteur original : environ 5 Go de VRAM lorsque tous les MOE tournent sur le CPU, avec uniquement les couches d’attention sur le GPU
• Précision complémentaire : seuls le cache KV, les poids et activations d’attention, les tables de routage et LayerNorm restent sur le GPU

Q2. Quelle quantité minimale de RAM est nécessaire ?

• Auteur original : 64 Go minimum, 96 Go recommandés idéalement
• Raison : mmap sous Linux garde en mémoire les couches d’experts « chaudes », ce qui permet un accès rapide sans charger le modèle complet

Q3. Déplacer une partie des couches MOE vers le GPU accélère-t-il beaucoup l’exécution ?

• Auteur original : cela peut accélérer légèrement, mais sans différence majeure
• Exemple :
  • Tous les MOE sur CPU : prompt à 134 tokens/s, inférence à 25 tokens/s
  • 8 MOE sur GPU : prompt à 163 tokens/s, inférence à 30 tokens/s
  • La consommation de VRAM monte alors à 22 Go

Q4. Quel GPU est adapté ?

• Auteur original : une RTX 3060Ti ou mieux suffit, avec prise en charge BF16 recommandée (RTX 3000+)
• Raison : toutes les couches hors MOE fonctionnent en BF16

Q5. Comment configurer la commande ?

• Auteur original : exemple fourni sur la base de la PR #15157

  ~/build/llama.cpp/build-cuda/bin/llama-server \  
      -m $LLAMA_MODEL_DIR/gpt-oss-120b-mxfp4-00001-of-00003.gguf \  
      --n-cpu-moe 36 \  
      --n-gpu-layers 999 \  
      -c 0 -fa \  
      --jinja --reasoning-format none \  
      --host 0.0.0.0 --port 8502 --api-key "dummy"  
  

[kaydash]

Je l’ai réellement essayé, mais c’est beaucoup trop lent.
Le GPU utilise à peine sa fréquence d’horloge,
remplit entièrement les 8 Go de mémoire dédiée du GPU ainsi que les 64 Go de mémoire physique,
et n’utilise que la moitié des 16 vCore.
Il faut simplement considérer qu’il tourne, ce n’était pas une configuration qui exploitait toutes les ressources.
Une seule requête prenait entre 6 et 8 minutes.

[cronex]

Je vais essayer ça aussi, dans le même esprit.

[crawler]

Je pensais que 32 Go suffiraient...

[cnaa97]

Pour l’instant, ça ne tourne pas sur LM Studio avec un M4 Max 64 Go, snif snif.

[jinucho]

Comme ça fait 65 Go... c’est dommage snif snif

[GN⁺]

Avis Hacker News

• Je me demande si faire tourner le modèle directement sur son propre matériel permet de désactiver les garde-fous
  • Pour contourner les garde-fous, il faudrait trouver un « abliterated finetune » qui trace puis supprime les voies neuronales déclenchant les refus
  • D’après un article lu récemment, GPT-OSS a été entraîné uniquement sur des données artificielles/générées, donc il ne contient pas tant que ça de « connaissances interdites » au départ
    Article connexe
  • On peut le contourner avec des prompts de jailbreak ; c’est un peu contraignant, mais ça fonctionne bien
  • Les versions dont une partie des garde-fous a été retirée perdent énormément en performances, donc à mon avis on y perd au change
  • Fondamentalement, c’est intégré au modèle, mais il existe des communautés qui le crackent et le modifient
• Sur une config 5950x + 128GB RAM + GPU 3060 12GB, la génération de tokens est rapide, mais dès que le contexte grossit un peu, la vitesse de traitement chute fortement
  Du coup, j’utilise surtout d’autres modèles comme qwen, mistral ou gemma
  • Plutôt que des formulations subjectives comme « rapide » ou « lent », j’aimerais connaître des chiffres concrets en tokens
  • Je me demande ce que vous cherchez à faire avec ce modèle, au-delà du simple chat ou de la manipulation de texte
• Avec 32GB RAM + 16GB VRAM, on peut charger entièrement un modèle 20B en VRAM, mais si on pousse la fenêtre de contexte au-delà de 8k tokens, la VRAM ne suffit plus
  D’autres font tourner un modèle 120B avec moins de VRAM ; c’est peut-être lié à l’absence de prise en charge de ROCm et à l’utilisation de Vulkan
  Cela dit, c’est amusant de pousser le matériel jusqu’à ses limites
  • Plus la taille du contexte augmente, plus il faut déporter de couches vers la RAM système
    llama.cpp permet de régler directement le nombre de couches calculées sur GPU, alors qu’ollama ajuste ça automatiquement
    Ce serait bien de pouvoir ajuster dynamiquement le ratio RAM/VRAM en fonction de la longueur de session
• C’est drôle d’appeler 64GB RAM + 8GB VRAM « juste suffisant » ; pour moi, c’est une config à plusieurs milliers de dollars
  • Environ 300 CAD pour la RAM et 400 CAD pour le GPU, donc en desktop ça reste abordable
  • On est sur le milieu/entrée de gamme d’un PC gaming ; avec quelques centaines de dollars d’upgrade, on peut faire tourner ça directement chez soi
  • Il existe même des produits en précommande pas trop chers autour de 1599 à 1999 $
  • Il est possible d’assembler une machine neuve pour moins de 1000 $ US ; en occasion, c’est encore moins cher et le GPU peut même être meilleur
  • 64GB de DDR5 tournent autour de 150 $, et une 3060 12GB autour de 300 $, avec parfois moins cher sur eBay
• Je me demande si quelqu’un a essayé de faire tourner un modèle 20B sur un MacBook Air M4 ou une RTX 3060
• Je manque de RAM donc je ne peux pas utiliser de gros modèles, mais le modèle 20B est rapide sur MacBook et suffit à mon usage
  En revanche, le function calling est encore cassé dans llama.cpp
  • Ce bug a été corrigé dans cette PR
  • Heureusement, c’est un bug et non une limite de RAM ; même sur un MacBook Air 16GB RAM, plusieurs modèles tournent bien
    Je prévois d’héberger un chatbot IA dans ma chambre sur un mini PC à 149 $, et le modèle Qwen3 4B a l’air prometteur
    Plan connexe
• Je me demande si on peut optimiser les réglages avec cette configuration dans OpenWebUI ou une autre GUI ; j’ai l’impression qu’un modèle 20B serait plus adapté
• Je débute avec les LLM, donc je me demande si cette optimisation s’applique à tous les modèles MoE
  • Comme cela fonctionne en appliquant une regex aux noms de couches, ça peut aussi marcher sur d’autres modèles si leur nommage est similaire
    Par exemple, cela fonctionnait aussi avec Qwen 3, et on peut définir soi-même la regex pour envoyer certaines couches vers un appareil précis
• Je me demande si la version optimisée mlx tournerait sur un Mac 64GB
  • D’après l’estimation de LM Studio, avec une quantification 3-bit (~50GB), cela devrait passer sans problème