OpenAI GPT-OSS : comment l'exécuter localement ou l'auto-héberger sur le cloud, configuration matérielle requise

GPT-OSS est exceptionnellement bien conçu pour l'accessibilité : le gpt-oss-20B La variante est conçue pour fonctionner sur un seul GPU grand public (~ 16 Go de VRAM) ou sur des ordinateurs portables haut de gamme récents utilisant des versions GGUF quantifiées, tandis que gpt-oss-120BMalgré ses 117 milliards de paramètres, le modèle est livré avec des astuces MoE/paramètres actifs et une quantification MXFP4 permettant son exécution sur des GPU H100 uniques (environ 80 Go) ou sur des configurations multi-GPU. Le déploiement d'un modèle open source de type GPT (souvent appelé « GPT OSS »), qu'il s'agisse d'un modèle compact de 6 à 7 milliards de bits pour les applications locales ou d'un modèle de plus de 70 milliards de bits pour les services de production, soulève la même question fondamentale : comment exécuter GPT-OSS localement ou en auto-hébergement sur le cloud ? Configuration matérielle requise.

Que sont les modèles GPT-OSS et quelles sont leurs exigences matérielles ?

Qu'est-ce que GPT-OSS ?

GPT-OSS est la famille de modèles de langages volumineux, récemment publiée par OpenAI (deux variantes phares au moment de la sortie : versions à environ 20 B et environ 120 B paramètres). Ils sont livrés avec des options optimisées (mélange d'experts, quantification native MXFP4 dans la distribution OpenAI, innovations de densité/fardeau) qui permettent d'exécuter ces nombres de paramètres relativement importants avec une mémoire nettement inférieure à celle requise par les versions naïves FP32/FP16. Cette version visait explicitement à rendre les modèles puissants plus largement exécutables et personnalisables, en dehors des hyperscalers.

Informations clés sur le produit (porteur) :

gpt-oss-20B est destiné à fonctionner sur un seul GPU grand public avec environ 16 Go de VRAM (et peut être utilisé sur des ordinateurs de bureau/portables avec des quantifications GGUF).
gpt-oss-120B (≈117B paramètres, ~5.1B infection (les paramètres dans la conception MoE d'OpenAI) sont conçus de manière à ce que le modèle puisse tenir dans un seul H100 / A100 de 80 Go lors de l'utilisation de MXFP4 et d'un support d'exécution spécifique, ou sur des configurations multi-GPU.

Facteurs matériels qui déterminent les exigences

Taille et architecture du modèle – Les MoE et les couches clairsemées/denses peuvent modifier l'activation et la mémoire de travail. (GPT-OSS utilise des composants de type « mix d'experts ».)
Précision et quantification – FP32, FP16, BF16, 8 bits, 4 bits (GPTQ/AWQ/MXFP4). Une précision plus faible réduit la mémoire, mais peut affecter la latence et la fidélité numérique. OpenAI fournit des pondérations quantifiées MXFP4 pour GPT-OSS.
Longueur du contexte (longueur de la séquence) – les contextes plus longs augmentent proportionnellement l'utilisation du cache d'activation ; GPT-OSS prend en charge les contextes extrêmement longs (jusqu'à de très grandes fenêtres de jetons dans leur conception), ce qui multiplie les besoins en mémoire.
Taille du lot et concurrence – Servir plusieurs utilisateurs simultanément multiplie la mémoire pour les activations et le cache. Des frameworks comme vLLM, DeepSpeed et Triton tentent de regrouper et de partager efficacement les activations entre les requêtes.
Frais généraux du cadre de service – différents serveurs d’inférence (vLLM, text-generation-inference, llama.cpp, ONNX Runtime) ajoutent des frais généraux et des optimisations différents.

Où « se loge » : règles de mémoire approximatives

Deux concepts sont importants pour la planification du matériel :

Nombre total de paramètres — une limite supérieure sur la taille du modèle (117 B contre 21 B).
Ensemble activé/fonctionnel — dans MoE ou certains paramètres de précision, la mémoire active nécessaire à l'inférence peut être beaucoup plus petite que les octets de paramètres bruts.

Règles pratiques empiriques :

GPU/ordinateurs portables Edge de classe 16 Go → possible pour gpt-oss-20b si vous utilisez la configuration efficace en mémoire fournie par le modèle (ou quantifiez de manière agressive à 4 bits/NF4/AWQ).
80 Go H100 / A100 80 Go → hébergement mono-GPU pour gpt-oss-120b Dans leur configuration recommandée. Pour un débit de production optimal, vous pouvez toujours avoir besoin de plusieurs GPU pour le traitement par lots, la redondance ou une latence plus faible en cas de concurrence.
Grandes configurations multi-GPU (clusters A100/H100) → requis si vous souhaitez exécuter plusieurs utilisateurs simultanément avec une faible latence ou effectuer des réglages/entraînements approfondis. DeepSpeed/ZeRO et le parallélisme automatique des tenseurs permettent de répartir les grands modèles sur plusieurs GPU.

En résumé : pour l'expérimentation et une utilisation locale légère, prévoyez un GPU de 16 à 24 Go (ou un CPU avec quantification lourde). Pour l'inférence mono-GPU en production du modèle gpt-oss volumineux, ciblez un H100 de 80 Go ; sinon, utilisez un partitionnement multi-GPU.

Quelle puissance de calcul est nécessaire pour le déploiement de GPT-OSS dans la pratique ?

Inférence vs formation : des budgets très différents

InférenceLe coût principal est la mémoire GPU (VRAM) et les noyaux optimisés. Grâce à des temps d'exécution optimisés (vLLM, TensorRT, DeepSpeed-Inference) et à la quantification, l'inférence sur gpt-oss-20b est réalisable sur un GPU grand public de 16 Go ; le modèle 120 MoE est conçu pour un H100 de 80 Go.
Mise au point / formation complète: des ordres de grandeur supérieurs — vous aurez besoin de nombreux GPU ou d'instances d'entraînement spécialisées (clusters H100/A100 multi-nœuds, budget DFLOP et E/S de stockage). Cet article se concentre principalement sur l'inférence/l'auto-hébergement et les recettes de réglage fin léger (QLoRA/LoRA), et non sur un pré-entraînement de plusieurs semaines.

CPU vs GPU vs accélérateurs spécialisés

CPU uniquement: Possible avec GGUF/llama.cpp et des builds quantifiés de petite taille, en échangeant la latence contre un coût moindre. Exécuter 20 B sur le processeur sans quantification est peu pratique. Utilisez le processeur lorsque la confidentialité ou le fonctionnement local hors ligne sont essentiels et que vos besoins en débit sont faibles.
GPU: privilégié pour la latence et le débit. Les GPU ML modernes (A100/H100/4090/4080) diffèrent considérablement en termes de HBM/VRAM et de structure inter-GPU. La documentation gpt-oss recommande la classe H100 pour la variante 120B.
TPU / AMD MI300X: pris en charge par certains environnements d'exécution (versions vLLM/ROCm) et peut être rentable dans certains clouds — consultez la documentation du fournisseur lors du choix du matériel.

Comment exécuter GPT-OSS localement avec un budget limité ? (code + étape par étape)

Voici deux approches pratiques : (A) Ordinateur portable/de bureau GPU avec ~16–24 Go de VRAM utilisant une quantification 4 bits, et (B) Processeur/GPU faible (hors ligne) utilisant llama.cpp (GGUF) ou de petites compilations quantifiées. Ces deux méthodes sont largement utilisées par les praticiens lorsque le budget et la puissance sont limités.

Remarque : ces instructions supposent que vous disposez d'un environnement Python fonctionnel (Linux est recommandé pour une meilleure prise en charge de CUDA). Sous Windows, utilisez WSL2 pour une compatibilité optimale avec les chaînes d'outils GPU.

A. Route GPU (recommandée pour une latence optimale avec un budget limité) — quantifier + charger avec bitsandbytes (4 bits)

Ce chemin a pour but de courir openai/gpt-oss-20b Sur un seul GPU grand public (par exemple, 24 Go 4090 ou 16 Go 4080). Il utilise la quantification 4 bits de BitsandBytes et la technologie Hugging Face. transformers appareil-map/accélérer.

Étape 1 — Installer les bases

# Linux + CUDA (example); pick the correct torch CUDA wheel for your driver

python -m pip install -U pip
pip install torch --index-url https://download.pytorch.org/whl/cu121  # pick your CUDA version

pip install -U transformers accelerate bitsandbytes safetensors

(Si vous utilisez conda, créez un environnement et installez la roue de torche compatible CUDA pour votre plate-forme.)

Étape 2 — (Facultatif) Connectez-vous à Hugging Face pour télécharger des fichiers volumineux

huggingface-cli login

Étape 3 — Exemple Python (chargement d'un modèle quantifié 4 bits)

# save as run_gptoss_4bit.py

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig

model_id = "openai/gpt-oss-20b"

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type="nf4"   # or "fp4"/"nf4" depending on support

)

tokenizer = AutoTokenizer.from_pretrained(model_id, use_fast=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map="auto",                 # let transformers pick GPU + CPU offload if needed

    quantization_config=bnb_config,
    torch_dtype=torch.float16,
    trust_remote_code=True
)

prompt = "Write a concise summary of quantization for LLMs."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(out, skip_special_tokens=True))

Notes et conseils

Utilisez le device_map="auto" so transformers utilise automatiquement le déchargement CPU/GPU. Si vous n'avez qu'un seul GPU, device_map="auto" mettra généralement tout sur le GPU et déchargera ce qui doit être sur le CPU.
Si vous manquez de VRAM, ajoutez --offload_folder ./offload (ou ensemble offload_folder in from_pretrained) pour décharger les tenseurs vers NVMe.
L'approche Hugging Face + bitsandbytes est largement documentée ; consultez le guide des transformateurs 4 bits pour plus de détails.

B. CPU / itinéraire à petit budget (llama.cpp / GGUF)

Si vous n'avez pas de GPU ou un très petit GPU, llama.cpp / Les builds GGUF (et les fichiers quantifiés AWQ/GPTQ) vous permettent d'exécuter des modèles sur le processeur avec une latence acceptable pour les utilisateurs uniques.

Étape 1 — Installer llama.cpp / les liaisons Python

# Download and build (Linux)

git clone --recursive https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
make
# Python bindings (optional)

pip install llama-cpp-python

Étape 2 — Convertir safetensors → GGUF (si des scripts de conversion sont disponibles pour gpt-oss)
OpenAI/Hugging Face fournit des safetensors ; des convertisseurs communautaires (ou des scripts dans llama.cpp) convertir en GGUF. La commande exacte dépend du courant llama.cpp outils ; consultez le fichier README du dépôt pour convert.py/convert-safetensors-to-gguf. (Les fils de discussion de la communauté discutent de la conversion pour les nouveaux modèles.)

Étape 3 — Exécutez le modèle avec llama.cpp

# basic inference (example)

./main -m ./gpt-oss-20b.gguf -p "Explain GGUF and quantization in one paragraph." -n 256

Notes et compromis

Les exécutions CPU sont beaucoup plus lentes. Utilisez cette méthode pour les tests, la confidentialité ou les agents locaux à très faible concurrence.
Générer de longues sorties ou servir de nombreux utilisateurs simultanés sur le processeur n'est pas pratique ; passez à un GPU pour la production.

Constructions quantifiées sur disque (GPTQ/AWQ)

Si vous devez intégrer un grand modèle dans un petit GPU (par exemple, 8 à 12 Go), les résultats de la communauté montrent que la quantification de style GPTQ/AWQ peut faire fonctionner certains modèles 20B sur des GPU à faible VRAM — mais la conversion nécessite souvent plus CPU, RAM et un GPU intermédiaire pendant la conversion. Outils : GPTQ-for-LLaMa, AutoGPTQ (archivé), AWQet QLLM.

Conseils pratiques pour budget limité

Préférez les points de contrôle quantifiés 4 bits (GPTQ/AWQ/MXFP4) — souvent la différence entre « s'exécute en 12 Go » et « nécessite 80 Go ».
Limiter la longueur du contexte Pour l'inférence budgétaire : les contextes longs épuisent le cache d'activation. Si vous devez stocker des contextes longs, envisagez des stratégies de déchargement.
Utilisez la mémoire unifiée / le déchargement NVMEM avec précaution — les frameworks peuvent offrir un déchargement CPU/NVMe (DeepSpeed ZeRO-Offload / ZeRO-Infinity), mais cela augmente la latence.

Comment auto-héberger GPT-OSS sur des fournisseurs de cloud (guide pratique et indications de coûts) ?

Quel matériel cloud choisir ?

H100 80 Go à GPU uniqueIdéal pour héberger gpt-oss-120b pour un trafic faible à moyen. En termes AWS, les instances P5 fournissent du matériel H100 ; les variantes mono-GPU (annoncées en 2025) permettent un dimensionnement plus économique pour l'inférence. Utilisez la famille P5/ND H100 selon le fournisseur.
**Multi-GPU (8× H100)**Pour un débit élevé et une redondance optimale, utilisez un cluster p5.48x, p5dn ou comparable. L'utilisation de NVidia NVLink/NVSwitch dans la même instance réduit la charge de communication entre GPU.
Nuages alternatifsCoreWeave, Lambda Labs, Paperspace, Runpod — des locations de GPU souvent moins chères, ponctuelles ou à la demande, pour des inférences rapides. Utilisez-les pour le développement avant de vous engager dans une infrastructure à long terme.
Production de pointe / lourde: AWS p5 (H100) (8 × H100 80 Go par instance) — pour un débit maximal par nœud et des besoins en GPU unique de plus de 80 Go, ou pour 120 B+ avec moins de fractionnement. P5 fournit des H100 et un stockage local NVMe important.

rmers, conteneurs de génération de texte-inférence (TGI)/NVIDIA TGI ou configurer l'inférence DeepSpeed.

Provisionnement rapide de NVMe local Si vous prévoyez de décharger des états d'activation importants (ZeRO-Infinity), les nœuds P4/P5 disposent souvent d'un NVMe local et d'une bande passante réseau très élevée. ()
Sécurité et réseau — placez les points de terminaison d'inférence derrière les équilibreurs de charge, utilisez des groupes de mise à l'échelle automatique pour les interfaces frontales et séparez les préoccupations (diffusion de modèles par rapport au routage des requêtes).
Suivi et objectifs de niveau de service — suivre l'utilisation du GPU, la mémoire, le jeton/sec, la latence p95 et les erreurs ; utiliser Prometheus + Grafana pour les métriques.

Exemple de flux de travail d'auto-hébergement cloud (AWS P4/P5)

Choisir une instance (p4d/p5) selon les besoins mémoire du modèle. Pour gpt-oss-20B, une seule instance de 16 à 32 Go suffit ; pour gpt-oss-120B, choisissez une instance HBM de 80 Go ou un système multi-GPU.
Préparer l'AMI / l'image — utilisez une AMI de fournisseur qui regroupe CUDA, cuDNN et PyTorch optimisé (ou des images de fournisseur avec des pilotes NVIDIA).
Installer la pile de service: vLLM, transformateurs, conteneurs de génération de texte-inférence (TGI)/NVIDIA TGI, ou configurer l'inférence DeepSpeed.
Provisionnement rapide de NVMe local Si vous prévoyez de décharger des états d'activation importants (ZeRO-Infinity), les nœuds P4/P5 disposent souvent d'un NVMe local et d'une bande passante réseau très élevée.
Sécurité et réseau — placez les points de terminaison d'inférence derrière les équilibreurs de charge, utilisez des groupes de mise à l'échelle automatique pour les interfaces frontales et séparez les préoccupations (diffusion de modèles par rapport au routage des requêtes).
Suivi et objectifs de niveau de service — suivre l'utilisation du GPU, la mémoire, le jeton/sec, la latence p95 et les erreurs ; utiliser Prometheus + Grafana pour les métriques.

Exemple de plan d'auto-hébergement (gpt-oss-20b, production à petite échelle)

Objectif: servir environ 20 utilisateurs simultanés, objectif de réponse de 1 à 2 s, sensible aux coûts.

Instance: 1× A10G / 1× GPU 24 Go (par exemple, G5 / A10G / RTX 6000) pour le modèle + 1× petit serveur de démarrage CPU.
Runtime: vLLM comme serveur de modèles (traitement par lots continu) + passerelle CometAPI.
Échelle automatique: utiliser un groupe de mise à l'échelle automatique avec GPU AMI et un ALB + mise à l'échelle automatique horizontale par métriques CPU/GPU.
Rangements: NVMe local pour la mise en cache du modèle ; magasin d'objets (S3) pour le stockage du modèle à froid.
Le Monitoring: Prometheus + Grafana, suivez l'utilisation du GPU, la latence, la longueur de la file d'attente.
Sécurité: VPC, sous-réseaux privés, rôles IAM pour le stockage de modèles, certificats TLS.

Exemple de plan d'auto-hébergement (gpt-oss-120b, production)

Objectif: faible latence pour de nombreux utilisateurs simultanés / entreprise.

Instance1 × H100 80 Go (mono-GPU) pour la base de référence ; mise à l'échelle horizontale ou utilisation d'instances p5 multi-GPU pour le débit. Pour un débit élevé, répliquez le service mono-GPU (données parallèles) ou fragmentez le modèle sur plusieurs GPU à l'aide de DeepSpeed (tenseur/pipeline).
Runtime: DeepSpeed-Inference avec TP automatique ou NVIDIA TensorRT (si disponible). La prise en charge de vLLM pour MoE/Multi-GPU et les noyaux optimisés peut également être utile.
Kubernetes: utilisez K8s avec les plugins d'appareils et NVMe local ; utilisez les tests du chaos pour la disponibilité.
Optimisation des coûts: instances réservées pour une charge prévisible ; instances ponctuelles pour les charges de travail par lots.

Exemple : démarrer un conteneur de service vLLM pour gpt-oss-20b

# assume vllm is installed and CUDA is set up

vllm serve --model openai/gpt-oss-20b --port 8000 --num-gpus 1

Ensuite, pointez votre front-end vers http://<host>:8000/v1/chat/completions (vLLM prend en charge l'API compatible OpenAI).

Conseils d'optimisation des coûts

Machines virtuelles ponctuelles/préemptives sont 50 à 80 % moins chers mais nécessitent des points de contrôle ou des stratégies de réapparition rapide.
Quantification du modèle réduit les besoins en termes de type d'instance (par exemple, un 120B quantifié peut être servi sur moins de GPU si les moteurs prennent en charge la déquantification à la volée).
Utiliser des familles d'instances optimisées uniquement pour l'inférence (P5/P4/A2 Ultra) avec NVLink/NVSwitch élevé lors du parallélisme de modèle multi-GPU ; la bande passante du réseau est importante pour le partitionnement inter-GPU.

Comment équilibrer le coût, la latence et la qualité du modèle

Quantification : vitesse vs qualité

Quantification agressive (2-4 bits, AWQ/GPTQ) → Économies de mémoire importantes et perte de qualité souvent modeste pour de nombreuses tâches. Utilisez AWQ/GPTQ en production si vous évaluez la charge de travail spécifique. La conversion peut nécessiter une mémoire CPU importante lors de la quantification.

Optimisations mixtes de précision et de noyau

Utilisez le fp16, bf16 Lorsque pris en charge ; combiner avec des noyaux CUDA spécialisés (FasterTransformer, TensorRT) pour un débit maximal. Nvidia/TensorRT offre un décodage spéculatif et des noyaux optimisés pour de nombreux transformateurs (Nvidia fournit des adaptateurs GPT-OSS optimisés).

Sécurité et observabilité

Les modèles Open-weight vous permettent de surveiller les abus, les fuites et les dérives de données. Implémentez la journalisation des requêtes, les filtres de contenu, la limitation du débit et la modération par intervention humaine. Les notes de version et la fiche modèle d'OpenAI mettent l'accent sur leurs tests internes et leurs évaluations externes, mais l'auto-hébergement vous confère le périmètre de sécurité.

Réflexions finales

GPT-OSS fait bouger les choses : les modèles qui nécessitaient auparavant une infrastructure sur mesure massive sont désormais plus accessibles grâce à des choix d'architecture judicieux et à des distributions quantifiées. le déploiement reste une disciplineLe dimensionnement du matériel doit tenir compte de la précision du modèle, de la longueur du contexte et du profil de concurrence de votre application. Utilisez de petits bancs d'essai (quantifiés à 20 B) pour mesurer les jetons/s et la latence p95, puis multipliez-les pour estimer le calcul cloud et le coût de production.

Comment accéder à l'API GPT-OSS

CometAPI est une plateforme d'API unifiée qui regroupe plus de 500 modèles d'IA provenant de fournisseurs leaders, tels que la série GPT d'OpenAI, Gemini de Google, Claude d'Anthropic, Midjourney, Suno, etc., au sein d'une interface unique et conviviale pour les développeurs. En offrant une authentification, un formatage des requêtes et une gestion des réponses cohérents, CometAPI simplifie considérablement l'intégration des fonctionnalités d'IA dans vos applications. Que vous développiez des chatbots, des générateurs d'images, des compositeurs de musique ou des pipelines d'analyse pilotés par les données, CometAPI vous permet d'itérer plus rapidement, de maîtriser les coûts et de rester indépendant des fournisseurs, tout en exploitant les dernières avancées de l'écosystème de l'IA.

Les développeurs peuvent accéder GPT-OSS-20B et GPT-OSS-120B à travers API CometLes dernières versions des modèles répertoriés sont celles en vigueur à la date de publication de l'article. Pour commencer, explorez les fonctionnalités du modèle dans la section cour de récréation et consultez le Guide de l'API Pour des instructions détaillées, veuillez vous connecter à CometAPI et obtenir la clé API avant d'y accéder. API Comet proposer un prix bien inférieur au prix officiel pour vous aider à vous intégrer.