Qwen3.8-27B sur vLLM : Déployez-le en production sur un ou deux GPU

Oui — Qwen3.8 27B tourne en production sur vLLM aujourd'hui, et sur un seul GPU dans la plupart des cas. La version qui compte est vLLM 0.17.0 ou plus récent : elle fournit la recette officielle, les kernels d'attention hybride dont ce modèle a besoin, et un endpoint /v1 compatible O​penAI. Pour un GPU Blackwell, exécutez le quant NVFP4 — la propre recette de vLLM le mesure à 24.6 GiB de VRAM avec une taille de tensor-parallel de 1. Pour une seule carte de 48 Go, exécutez FP8. Le BF16 complet, un checkpoint de 51.7 Go, nécessite un GPU de 80 Go ou deux cartes de 48 Go en tensor-parallel. Les commandes exactes sont ci-dessous ; la première est une commande sur une seule ligne.

Tout ici a été vérifié le 15 août 2026, le troisième jour où les poids étaient en ligne. L'architecture, le contexte et la licence proviennent de la fiche du modèle Qwen3.8 27B sur Hugging Face ; la taille du checkpoint est la somme des 18 fragments safetensors du dépôt ; les commandes vLLM et le chiffre de 24.6 GiB proviennent de la page de recette de vLLM pour ce modèle. Qwen3.8 27B est le modèle multimodal dense à 27 milliards de paramètres d'Ali​baba — poids sous licence Apache 2.0, publié les 13 et 14 août — et comme les poids sont ouverts, vous pouvez le servir vous-même au lieu de louer des tokens. Ce fork est le véritable sujet de cet article.

Les faits qui comptent, avec leurs sources.

• Architecture — 27B dense (27,8B en comptant la tour de vision et le vocabulaire avec padding), 64 couches, dimension cachée 5 120, vocabulaire 248 320. Fiche officielle du modèle, vérifiée aujourd'hui.

• Attention — hybride : 16 couches à attention complète, 48 couches linéaires Gated DeltaNet selon un schéma de blocs 3:1. Seules 16 couches conservent un cache clé-valeur croissant ; les 48 autres gardent plutôt un état récurrent de taille fixe.

• Contexte — 262,144 jetons nativement, extensible à environ 1M via la mise à l'échelle RoPE YaRN. Fiche du modèle, vérifiée aujourd'hui.

• Entrée — texte, image et vidéo natifs ; sortie de texte. vLLM expose les trois via l'API standard de chat-completions, sans fichier projecteur séparé.

• Licence — Apache 2.0. C’est ce seul fait qui explique que la question « servir soi-même ou louer les tokens » existe tout court.

• Poids — le checkpoint BF16 totalise 51,7 Go répartis sur 18 fragments safetensors (Hugging Face, vérifié aujourd'hui). Qwen publie également des checkpoints FP8 et NVFP4 conçus pour vLLM.

• Prérequis vLLM — 0.17.0 ou plus récent, avec transformers ≥ 5.8.0. Page de recettes de vLLM, vérifiée aujourd'hui. « N'importe quel vLLM » n'est pas une instruction sûre ; les kernels de couche récurrente sont ce que la nouvelle version ajoute.

• Prédiction multi-tokens — une tête de décodage spéculatif (draft head) est incluse dans le checkpoint, vous n’avez donc pas besoin d’un modèle draft distinct. vLLM documente le flag ; aucune mesure de vitesse indépendante n’existe pour le moment.

L'échelle GPU — quel quant sur quelle carte

Trois formats de service couvrent la gamme pratique. Choisissez selon la VRAM dont vous disposez réellement, pas selon le « meilleur quant ».

• NVFP4 — 24,6 GiB au total (poids plus un cache KV FP8), selon la recette de vLLM à TP1. Tient sur une seule carte de classe Blackwell — en pratique une RTX 5090 de 32 Go ou une B200. C'est le chemin à la latence la plus faible et celui qui conserve le plus de contexte par carte : la recette de vLLM indique une capacité de 6,6 M de tokens KV, même avec l'extension de contexte à 1 M.

• FP8 — environ 26 Go de poids. Une carte de 48 Go (L40S, RTX A6000, RTX 6000 Ada) suffit pour le faire tourner avec de la marge pour le contexte ; deux cartes de 48 Go en tensor-parallel vous donnent de la marge pour un contexte plus long ou une concurrence plus élevée. La recette maison de vLLM exécute FP8 en TP4 sur un plateau GB300 à quatre GPU lorsque vous voulez le cache KV le plus grand possible.

• BF16 — 51,7 Go de poids, donc un seul GPU de 80 Go (H100, A100 80GB, B200, GB300) ou deux cartes de 48 Go en TP2. C'est l'option de précision de référence, et c'est celle qu'utilise réellement la commande d'extension de contexte 1M ci-dessous.

• MXFP4 — ne pas utiliser sur NVIDIA. Le chemin MXFP4 de vLLM ne prend actuellement pas en charge la méthode linéaire ; les mêmes poids sont publiés au format NVFP4, qui est le format que la recette NVIDIA utilise réellement.

Exécutez-le — les commandes vLLM

La configuration par défaut à faible latence sur une seule GPU ({{KEEP}}NVFP4, one Blackwell GPU{{/KEEP}}), mot pour mot de la recette de vLLM :

vllm serve Inferact/Qwen3.8-27B-NVFP4 --tensor-parallel-size 1 --max-model-len 262144 --kv-cache-dtype fp8 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder

La commande FP8 de la même recette (TP4, un plateau GB300, plus grand cache KV) :

vllm serve Qwen/Qwen3.8-27B-FP8 --tensor-parallel-size 4 --max-model-len 262144 --kv-cache-dtype fp8 --reasoning-parser qwen3

Pour deux cartes de 48 Go, gardez la commande FP8 et définissez --tensor-parallel-size 2 au lieu de 4.

Ajoutez ceci à l'une ou l'autre commande pour activer le décodage spéculatif MTP :

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

L'extension de contexte 1M (également issue de la recette de vLLM) :

vllm serve Qwen/Qwen3.8-27B --max-model-len 1010000 --hf-overrides '{"text_config": {"max_position_embeddings": 1010000}}'

Point any O​penAI client at http://localhost:8000/v1 — the endpoint is a drop-in replacement. Two runtime details matter once it is up: thinking is on by default at reasoning_effort xhigh, so turn it off per request with chat_template_kwargs {"enable_thinking": false} or drop it to {"reasoning_effort": "low"} for faster answers. And the checkpoint ships temperature 1.0, top_p 0.95, top_k 20 in its generation config — pass those unless your app already overrides sampling.

Ce que les propres pages de vLLM promettent et ne promettent pas.

• Pas encore de chiffres de débit pour le 27B. Au 15 août, la page de recettes de vLLM ne publie aucun benchmark de débit ou de latence pour Qwen3.8 27B. Le chiffre de « 4 000+ tokens par seconde par GPU » qui circule appartient au Qwen3.8 2.4T-A95B sur un rack GB300 NVL72 à 72 GPU, est rapporté par le fournisseur, et ne concerne pas ce modèle. Les chiffres de tokens par seconde de la communauté que vous verrez circuler pour GGUF sous llama.cpp ou Ollama — un runtime et une charge de travail différents de ceux du service vLLM.

• L'affirmation concernant un cache KV économique dépend du runtime. La fiche du modèle indique que seules 16 des 64 couches conservent un cache, mais cela n'est utile que si le moteur de service implémente réellement les couches Gated DeltaNet. C'est vLLM 0.17+ qui le fait ; c'est pourquoi l'épinglage de version est la première chose dans cet article plutôt qu'une note de bas de page.

• MTP est intégré, mais non mesuré ici. La tête de draft est dans le checkpoint et vLLM documente le flag, mais personne n’a encore publié de chiffre de vitesse indépendant pour ce 27B sur vLLM. Prévoyez de le mesurer sur votre propre trafic.

• NVIDIA est la voie testée. La recette de vLLM est conçue pour les GPU NVIDIA (NVFP4 et FP8). Les déploiements sur AMD Instinct ou Intel Gaudi de ce modèle à attention hybride restent encore très expérimentaux, et cet article ne prétend pas le contraire.

Servez-le vous-même, ou louez les jetons

C'est là qu'Apache 2.0 fait son travail. Il n'y a pas de frais de licence par jeton sur Qwen3.8 27B, donc la seule vraie question est de savoir si vous possédez le matériel ou si vous louez les jetons.

• Auto-hébergement (cet article) — vous payez le GPU une fois, et chaque token ensuite est gratuit. Un RTX 5090 que vous possédez déjà fait de la commande NVFP4 un endpoint à coût marginal nul, sans qu’aucune donnée ne sorte de la machine. Si vous devez louer le GPU, un 5090 en cloud ou une paire d’A6000 constitue la ligne budgétaire, et tout l’argument ne tient que si vous avez déjà la carte ou un volume soutenu.

• Louer les jetons — parce que les poids sont ouverts, plusieurs hébergeurs le font tourner, et le prix plancher correspond au coût du matériel. Qwen3.8 27B est disponible sur OrcaRouter dès aujourd'hui à $0.33 par million de jetons d'entrée et $2.40 par million de sortie — aucune marge fournisseur à répercuter, puisque OrcaRouter exécute les poids ouverts sur sa propre infrastructure — et ces mêmes poids ouverts financent un niveau gratuit limité en débit qui facture $0 par requête et renvoie HTTP 429 lorsque vous dépassez son plafond. Un mois représentatif de 10 millions de jetons avec 70 % d'entrée revient à environ $9.51 sur l'offre payante.

• La règle de décision — si vous possédez déjà le GPU, auto-hébergez. Si vous deviez en acheter ou en louer un, l’API devient rapidement rentable aux volumes d’un projet secondaire, et le même client compatible O​penAI pointe vers l’un ou l’autre endpoint, donc le code ne change pas lorsque vous migrez.

Quand vLLM est la mauvaise réponse

• Vous êtes une seule personne sur un ordinateur portable — vLLM est un moteur de service, pas une application de bureau. Pour une exécution locale mono-utilisateur, llama.cpp ou Ollama avec un Q4 GGUF est plus simple et nécessite une carte de 24 Go, pas un GPU Blackwell ; notre guide how-to-run-Qwen3.8-27B-locally vous accompagne de bout en bout sur ce chemin.

• Vous avez besoin d'un débit garanti avec zéro opération — l'auto-hébergement signifie que vous gérez vous-même la pagination, la file d'attente et le basculement. Si « l'API est en panne » n'est pas une phrase que vous voulez dans votre vocabulaire, louez plutôt les jetons et laissez quelqu'un d'autre gérer la flotte.

• Vous avez réellement besoin du contexte complet d'environ 1M à une qualité de pointe — c'est le rôle du Qwen3.8 2.4T-A95B, servi par vLLM ou SGLang sur un rack GB300 NVL72 de 72 GPU. Le Qwen3.8 27B sur un ou deux GPU ne pourra pas l'égaler ; notre article sur le serving du 2.4T explique pourquoi ce modèle est une classe de problèmes différente.

• Vous êtes sur une carte 24GB plus ancienne — NVFP4 est un format Blackwell ; sur les cartes 24GB Ampere (RTX 3090) ou Ada (RTX 4090), la voie FP8 est l'option vLLM, et au-delà, une quantification GGUF sous llama.cpp est la solution pragmatique. Le même modèle sur une carte 24GB est une autre histoire.

• Vous devez prendre en charge une concurrence maximale sur une seule carte — les valeurs par défaut ci-dessus pour une seule carte GPU sont le point de départ, pas la configuration de production. Ajustez --max-num-seqs, le cache KV et la configuration MTP en fonction de votre propre mix de requêtes avant de considérer que c'est terminé.

En résumé

Qwen3.8 27B est le rare modèle dense 27B que vLLM fait tourner sur un seul GPU en production. Mettez à jour vers vLLM 0.17.0+, récupérez la quantification NVFP4 pour une carte Blackwell 32GB à 24.6 GiB, la quantification FP8 pour une carte 48GB ou deux en tensor-parallel, et réservez le BF16 pour un GPU 80GB. Les commandes tiennent en une ligne, l'endpoint est compatible O​penAI, et comme les poids sont sous licence Apache 2.0, vous pouvez le servir vous-même ou le louer à 0,33 $/2,40 $ par million de jetons avec un niveau gratuit — le même code client dans les deux cas. La seule chose que personne n'a encore, c'est un chiffre de débit indépendant pour le 27B sur vLLM ; prévoyez donc une heure de benchmarking après l'avoir démarré avant de promettre un chiffre de latence à qui que ce soit.