Exécuter Qwen 3.8 27B sur un VPS avec Ollama

Peut-on exécuter Qwen 3.8 27B sur un VPS sans GPU ?

Pour exécuter Qwen 3.8 27B sur un VPS, vous devez d’abord disposer d’un tag de modèle existant. Or, au 4 août 2026, la bibliothèque Ollama ne contient aucune entrée qwen3.8. Le tag 27B publié le plus proche est qwen3.6:27b : 27.8 milliards de paramètres, quantification Q4_K_M et licence Apache 2.0. Toutes les commandes et toutes les valeurs ci-dessous utilisent ce tag avec Ollama v0.32.5, publié le 27 juillet 2026.

La réponse courte est oui, avec un VPS de 32 GB ou plus, mais l’exécution sera lente. Un modèle dense 27B en Q4 nécessite environ 17 GB de RAM uniquement pour les poids, avant même de stocker un seul token de contexte. Les offres de 8 GB et 16 GB sont donc totalement exclues. Sur un VPS DDR4 courant à deux canaux, le plafond est d’environ 3 tokens par seconde, soit moins que la vitesse de lecture de la plupart des utilisateurs.

D’où vient le 3.8 ? Il s’agit très probablement d’une confusion avec le nombre de paramètres. La page Ollama de qwen3.6:27b indique 27.8B paramètres, et 27.8 peut facilement être retenu plus tard comme 3.8. Il existe également un qwen3.5:27b, basé sur la même version Q4_K_M de la publication précédente. Vérifiez la liste à jour avant de copier une commande, sur la page des tags qwen3.6 d’Ollama. Si un vrai qwen3.8 est publié ultérieurement, les calculs présentés ici resteront valables, car ils dépendent du nombre de paramètres et du nombre de bits par poids, pas du numéro de version.

Quelle balise Ollama télécharger et comment la vérifier

Le téléchargement d’une balise inexistante renvoie une erreur explicite. Il est donc rapide de vérifier ce point directement sur le serveur. Une balise existante peut néanmoins être inexploitable localement. C’est ce qui pose problème avec GLM 5.2, présent dans la bibliothèque mais servi uniquement depuis le cloud Ollama.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show affiche l’architecture, le nombre de paramètres, la longueur du contexte et la quantification de la balise que vous avez réellement téléchargée. Si la ligne des paramètres contient 27.8B et que la ligne de quantification contient Q4_K_M, vous disposez de la build utilisée par ce guide. La bibliothèque propose également qwen3.6:27b-q8_0 et qwen3.6:27b-bf16 pour les mêmes poids avec une précision supérieure, ainsi qu’un ensemble de balises 35b-a3b correspondant à des modèles MoE (mixture of experts), dont le comportement sur CPU est très différent. Nous y revenons plus bas.

Nombre de paramètres multiplié par le nombre d’octets par poids

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

La formule tient en une ligne. Nombre d’octets des poids = paramètres * bits par poids / 8. Avec une largeur exacte de 4 bits, 27.8 milliards de paramètres occuperaient 13.9 GB. Le tag Q4_K_M fourni fait 17 GB, soit en pratique 4.89 bits par poids.

Cet écart n’est pas une erreur. Les formats K-quant ne stockent pas chaque tenseur avec la largeur nominale. Les tenseurs qui perdent le plus en qualité lors de la compression sont conservés sur 5 ou 6 bits. Les couches d’embedding des tokens et de sortie restent généralement en Q6_K ou Q8_0. Le nom du format indique une moyenne, qui se situe ici autour de 4.9. Le même phénomène apparaît à l’autre extrémité de l’échelle : 56 GB pour BF16 correspondent à 16.1 bits par poids, et non à une valeur fixe de 16, car le fichier contient aussi des métadonnées et une table d’embedding en pleine précision.

Q5_K_M ne dispose pas de tag publié pour ce modèle. La ligne de 19.8 GB est donc calculée avec la valeur habituelle de 5.7 bits par poids pour ce format, et non mesurée. Q8_0 occupe presque deux fois plus d’espace que Q4, soit 30 GB. Sur une machine équipée uniquement d’un CPU, ce doublement multiplie par deux le trafic mémoire par token et réduit donc aussi environ de moitié le nombre de tokens par seconde. Pour cette seule raison, Q4_K_M est le choix par défaut approprié ici. Si vous voulez évaluer la qualité plutôt que la consommation mémoire, une comparaison plus détaillée de Q4, Q8 et fp16 montre à partir de quel niveau la sortie commence réellement à se dégrader.

Coût du cache KV quand le contexte augmente

Les poids représentent un coût fixe. Le cache KV (cache des clés et des valeurs, c’est-à-dire l’état d’attention que le modèle conserve pour chaque token déjà traité) augmente linéairement avec la longueur du contexte. C’est généralement à cet endroit que la RAM vient à manquer.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Ces chiffres partent de l’architecture utilisée récemment par Qwen pour ses modèles denses de cette catégorie : 64 couches, 8 têtes clé/valeur avec GQA (grouped-query attention) et une dimension de tête de 128. Cela représente 256 KiB par token en f16, soit 8 Go pour 32k tokens et 32 Go pour 128k. Ne vous fiez pas à mon calcul pour votre propre machine. Chargez le modèle et lisez la colonne SIZE de ollama ps. Elle indique les poids, le cache et la surcharge dans une seule valeur.

C’est pourquoi le contexte de 256K indiqué sur la fiche du modèle est surtout une caractéristique annoncée, pas un plan d’utilisation. Le remplir en f16 coûterait 64 Go de cache en plus des poids, sur une machine qui utilise déjà 17 Go pour les poids. Ollama ne vous fournit pas toute la fenêtre par défaut. Il en charge une bien plus petite, que vous pouvez augmenter délibérément avec OLLAMA_CONTEXT_LENGTH. Cette variable s’applique à l’ensemble du serveur, mais ce n’est pas le seul réglage. Définir num_ctx sur la requête individuelle permet de conserver une valeur par défaut économique pour le reste, tout en accordant une fenêtre plus grande à une tâche longue. Augmentez cette valeur progressivement et vérifiez ollama ps après chaque modification.

Deux réglages réduisent le cache de moitié ou davantage. OLLAMA_KV_CACHE_TYPE=q8_0 stocke le cache sur 8 bits au lieu de 16, ce qui fait passer 32k tokens de 8 Go à 4 Go. Ce réglage nécessite flash attention. Définissez donc également OLLAMA_FLASH_ATTENTION=1, puis vérifiez la réduction dans ollama ps au lieu de supposer qu’elle a été appliquée. OLLAMA_NUM_PARALLEL=1 est tout aussi important. Ollama peut traiter plusieurs requêtes simultanément, et chaque emplacement dispose de sa propre portion de contexte. Laisser le parallélisme à sa valeur par défaut multiplie donc discrètement le cache prévu dans vos calculs. Si plusieurs personnes utilisent cette machine, c’est à ce niveau que les problèmes commencent. Le nombre d’utilisateurs simultanés qu’un modèle auto-hébergé peut servir dépend des emplacements de cache et de la profondeur de la file d’attente bien avant de dépendre du nombre de cœurs.

Ce qui tient dans 8, 16, 32 et 64 Go de RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Lisez les deux nombres comme des milliers de tokens de contexte disponibles en plus des poids, avec un cache f16, sur un VPS Linux headless auquel il reste environ 1,5 Go pour le système d’exploitation et une petite marge. Zéro signifie que les poids eux-mêmes ne tiennent pas : rien ne peut donc être chargé.

8 Go et 16 Go ne laissent aucune marge. 17 Go de poids ne tiennent pas dans 16 Go de RAM, et aucun réglage du contexte ne peut changer cela. Ajouter du swap ne résout pas le problème. Ollama memory-map le fichier GGUF. Une fois que les pages résidentes dépassent la RAM, le kernel commence à les évincer puis à les relire. Chaque token doit alors relire des gigaoctets sur le disque. La machine reste en iowait élevé et produit nettement moins d’un token par seconde.

32 Go est le premier palier utilisable. Les poids occupent 17 Go et il vous reste environ 13 Go. Cette capacité permet environ 32k tokens de contexte f16, avec une marge. Les poids Q8_0 de 30 Go ne tiennent pas du tout sur ce palier.

64 Go offrent une marge confortable. Avec Q4, il reste de la place pour environ 128k tokens de contexte. Les poids Q8_0 tiennent avec environ 64k tokens disponibles derrière eux. Avant de payer 64 Go pour utiliser Q8, comprenez bien ce que vous achetez : une sortie légèrement meilleure, à la moitié de la vitesse, sur une machine déjà lente. Pour presque tout le monde, Q4 avec un contexte plus long offre un meilleur compromis.

À quelle vitesse l’inférence CPU s’exécute-t-elle sur un VPS ?

Générer un token à partir d’un modèle dense consiste à lire chaque poids depuis la mémoire une fois. Pas seulement certains d’entre eux. Tous. La limite de vitesse ne dépend donc pas du nombre de cœurs, mais de la bande passante mémoire divisée par la taille des poids. En Q4, cela représente 17 Go de trafic mémoire par token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Il s’agit de plafonds théoriques, pas de mesures. En pratique, le débit atteint environ 50 à 70 % de la valeur affichée, car la latence mémoire et le prefetching imparfait empêchent d’atteindre le maximum théorique. Un VPS DDR4-3200 à deux canaux a un plafond de 3 tokens par seconde : prévoyez donc environ 2. Une machine DDR5-4800 à deux canaux a un plafond de 4.5, soit environ 3 en pratique.

Les lignes correspondant aux gros serveurs nécessitent une mise en garde. Une plateforme EPYC à douze canaux offre 460.8 Go/s et un plafond de 27.1 tokens par seconde, mais vous ne louez pas un EPYC complet. La bande passante mémoire est une ressource partagée par tous les tenants de cette machine. Une tranche de 8 vCPU ne dispose donc pas de douze canaux de bande passante exclusifs. Les guides qui se concentrent sur les GPU ignorent complètement ce point. C’est pourquoi deux offres VPS ayant le même nombre de vCPU peuvent différer d’un facteur trois avec le même modèle.

Ajouter des vCPU cesse aussi d’être utile rapidement, pour la même raison. Dès que les cœurs demandent les données plus vite que le contrôleur mémoire ne peut les fournir, les threads supplémentaires ajoutent uniquement de la surcharge d’ordonnancement. Définissez OLLAMA_NUM_THREAD sur le nombre de vos cœurs physiques, effectuez une mesure, puis essayez la moitié de cette valeur. Sur de nombreuses offres mutualisées, la valeur la plus faible est plus rapide.

Le traitement du prompt se comporte différemment. Le prefill, c’est-à-dire le parcours de votre entrée avant l’apparition du premier token, dépend davantage du calcul que de la bande passante mémoire. Il évolue donc avec le nombre de cœurs. En pratique, la sortie commence après une longue pause pour un prompt volumineux, puis le débit stable et lent indiqué plus haut s’applique. Mesurez séparément les deux phases avec --verbose, qui affiche un prompt eval rate et un eval rate pour chaque requête.

Si le modèle dense 27B est simplement trop lent, examinez les tags qwen3.6:35b-a3b avant d’abandonner le CPU. Ils activent environ 3 milliards de paramètres par token au lieu des 27.8 milliards, ce qui réduit presque d’un ordre de grandeur le trafic mémoire par token, même si le fichier sur le disque est plus volumineux. Vous échangez une empreinte RAM plus importante contre davantage de vitesse. Le choix du runtime compte également ici, et Ollama et llama.cpp exposent des contrôles de réglage CPU différents malgré l’utilisation du même code d’inférence sous-jacent.

Quand louer une heure de GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

La même formule appliquée à la bande passante mémoire GPU annoncée donne une réponse d’une autre catégorie. Une carte grand public de 24 GB atteint au maximum 59 tokens par seconde avec ces poids. Une carte actuelle pour data centre atteint 197. Vous ne réduirez pas cet écart en ajustant le nombre de threads. La carte utilise une mémoire à 1008 GB/s, tandis que votre VPS se situe à quelques dizaines de GB/s.

Il faut donc fixer la limite en fonction de la charge, et non d’une préférence. L’inférence sur CPU convient lorsque le traitement est asynchrone et que personne n’attend le résultat : résumé nocturne d’un ensemble de documents ou tâche de classification quotidienne exécutée pendant votre sommeil. Louez un GPU dès qu’une personne attend le résultat, ou dès que les requêtes arrivent à un rythme supérieur à une requête toutes les 30 secondes, car une machine uniquement équipée de CPU ne dispose d’aucune marge pour le batching et la file d’attente ne fait que s’allonger.

La comparaison des coûts est moins évidente qu’il n’y paraît. Un VPS de 64 GB est facturé chaque heure du mois, que le modèle soit chargé ou non, tandis qu’une instance GPU n’est facturée que pendant les heures où vous la laissez fonctionner. Si votre utilisation réelle est de deux heures par jour, le GPU loué peut être à la fois plus rapide et moins cher. Commencez par calculer votre taux d’utilisation, puis comparez les prix. Choisir un VPS avec un GPU explique les points à vérifier directement sur l’instance, et vLLM prend l’avantage sur Ollama dès que vous servez des requêtes concurrentes sur un GPU explique pourquoi : vLLM les regroupe correctement.

Il existe une troisième option souvent oubliée. Gardez le modèle 27B sur CPU pour les traitements par lots et placez un modèle d’API hébergé devant le chemin interactif. Rien ne vous oblige à utiliser un seul modèle pour les deux.

Installer Ollama et mesurer votre machine

Le script d’installation est le script officiel. Il configure un service systemd exécuté avec un utilisateur dédié ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version doit afficher 0.32.5 ou une version ultérieure. Vérifiez free -g avant de télécharger quoi que ce soit. Si la colonne total de la ligne Mem affiche une valeur inférieure à 32, arrêtez-vous ici et choisissez un modèle plus petit. Télécharger 17 GB que vous ne pouvez pas exécuter ferait perdre une heure et consommerait beaucoup d’espace disque.

Définissez les options d’exécution dans un override systemd plutôt que dans votre shell. Le modèle s’exécute dans le service. Il ne voit donc jamais votre environnement interactif.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

La sortie de --verbose contient la mesure recherchée. eval rate correspond au nombre de tokens par seconde pendant la génération. prompt eval rate correspond à la vitesse de prefill. load duration indique le temps nécessaire pour lire les weights depuis le disque. C’est pourquoi OLLAMA_KEEP_ALIVE=60m est défini : sur CPU, recharger 17 GB depuis le disque à chaque requête coûte plus cher que la requête elle-même. Le délai d’inactivité par défaut est de cinq minutes. Il est suffisamment court pour qu’une batch queue avec des intervalles entre les éléments paie ce coût de chargement à répétition. Les options permettant de garder un modèle en mémoire couvrent à la fois le champ keep_alive par requête et la persistance du réglage après un redémarrage.

Pendant que le modèle est chargé, vérifiez son empreinte mémoire depuis un second terminal.

ollama ps

La colonne SIZE indique l’empreinte mémoire réelle, cache KV compris. Elle doit être proche de la taille des weights, augmentée de la ligne correspondant à la longueur de votre contexte dans le tableau KV. Avec 8192 tokens et un cache 8-bit, prévoyez environ un gigaoctet en plus des weights, contre 2 GB si le cache restait en f16. La colonne PROCESSOR doit afficher 100% CPU. Si elle affiche autre chose, un GPU est utilisé et les chiffres de performance de ce guide ne décrivent pas votre machine.

Modes d’échec et chaînes exactes affichées

Le modèle refuse de se charger. Ollama affiche une ligne qui nomme les deux valeurs, sous la forme model requires more system memory (18.6 GiB) than is available (15.2 GiB). C’est le bon type d’échec : Ollama a effectué le contrôle avant l’allocation, au lieu de laisser le kernel gérer la situation. Réduisez la longueur du contexte, choisissez un tag plus petit ou passez à une offre supérieure.

Le processus disparaît au milieu d’une réponse. Le client n’affiche rien d’utile et journalctl -u ollama -n 50 indique que le service redémarre. Exécutez dmesg -T | tail. Une ligne contenant Out of memory: Killed process ... (ollama) signifie que l’OOM killer du kernel a arrêté le processus. Cela se produit lorsque le contrôle préalable réussit, mais que le cache dépasse l’estimation pendant une longue conversation. Réduisez la longueur du contexte.

Le pull échoue immédiatement. Error: pull model manifest: file does not exist signifie que le tag n’existe pas dans la bibliothèque. La commande qwen3.8:27b produit exactement ce résultat, comme toute faute de frappe dans le numéro de version. Vérifiez le tag sur la page de la bibliothèque avant d’accuser le réseau.

Tout fonctionne, mais les performances sont insupportablement faibles. Un débit inférieur à un token par seconde sur une machine disposant de suffisamment de RAM indique une pagination mémoire plutôt qu’un manque de puissance de calcul. Exécutez vmstat 1 pendant la génération. Une valeur non nulle dans la colonne si ou so signifie que le kernel utilise le swap. Réduisez alors le contexte ou le nombre de modèles chargés. Une valeur élevée et constante dans wa, sans activité de swap, signifie que les poids memory-mapped sont relus depuis le disque. Ils ne tiennent donc pas réellement en mémoire.

Le premier token prend 30 secondes, puis la génération accélère. C’est le prefill et c’est normal. Un long system prompt doit être traité à chaque requête qui ne bénéficie pas du cache. Réduisez donc d’abord le system prompt, avant d’ajuster autre chose.

À quoi sert réellement un modèle 27B sur CPU uniquement

Définissez vos attentes à partir des chiffres, pas de vos espoirs. À deux à quatre tokens par seconde, une réponse de 500 tokens prend entre deux et quatre minutes. C’est inutilisable pour le chat, mais parfaitement adapté à une file de traitement. Un modèle qui réfléchit avant de répondre aggrave ce calcul, car les tokens de raisonnement cachés sont générés à la même vitesse lente que la réponse. Ainsi, adapter le niveau d’effort de raisonnement à la tâche est l’un des rares leviers permettant de raccourcir une réponse sans changer de modèle. La synthèse de documents, l’ajout d’étiquettes en masse, l’extraction de champs depuis une file de fichiers et la revue de code sans supervision tolèrent cette latence, car rien n’attend la réponse. L’assistance au développement se situe exactement à cette limite. Utiliser un agent de développement avec un modèle que vous hébergez est donc utile pour des tâches en arrière-plan comme les messages de commit et le code de base des tests, mais pas pour les suggestions inline que vous attendez devant votre écran.

L’argument de la confidentialité est le plus important. Le modèle s’exécute sur du matériel que vous louez et contrôlez. Aucune requête ne quitte le serveur et vous ne payez pas chaque token. Cela a beaucoup de valeur pour les données réglementées, même à trois tokens par seconde. Comparez honnêtement cette solution à l’alternative : l’auto-hébergement d’un modèle de taille comparable aux modèles de pointe demande un ordre de grandeur de matériel supplémentaire. Un modèle 27B sur CPU est le point le moins coûteux de cette courbe où la sortie reste suffisamment utile pour être lue.

Pour mesurer ces performances, vous avez besoin de données structurées réelles. La plupart des API de données publiques exigent la création d’un compte avant même de permettre une mesure du débit. L’endpoint de démonstration de Strasmore, que nous exécutons, accepte les requêtes SQL en lecture seule sur 22 années de données du marché américain, sans clé ni inscription. Une requête GET vers https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 renvoie du JSON que vous pouvez transmettre directement à une boucle de prompts, avec la requête SQL exacte qui l’a produit. Le modèle dispose ainsi d’un contenu à résumer que vous pouvez vérifier indépendamment. Les limites sont de 500 lignes et 20 secondes par appel, soit largement plus que ce qu’une machine à deux tokens par seconde peut consommer. La liste complète des colonnes se trouve à https://api.strasmore.com/v1/schema.

S’il s’agit de votre première installation d’Ollama, le guide complet pour exécuter Ollama sur un VPS couvre la configuration du service, l’API HTTP et les règles du pare-feu que ce guide suppose déjà en place. N’exposez pas le port 11434 à Internet. Ollama ne fournit aucune authentification native. Toute personne pouvant atteindre ce port peut donc utiliser votre modèle et lire vos prompts.

FAQ

Existe-t-il un modèle Qwen 3.8 27B sur Ollama ?

Non. Au 4 août 2026, la bibliothèque Ollama ne contient aucun namespace qwen3.8. Les tags 27B existants sont qwen3.5:27b et qwen3.6:27b. Il s’agit dans les deux cas de builds Q4_K_M d’un modèle dense de 27.8 milliards de paramètres. Le 3.8 du terme recherché correspond presque certainement au nombre de paramètres 27.8B, mémorisé comme un numéro de version. Consultez https://ollama.com/library/qwen3.6/tags pour obtenir la liste actuelle. Utilisez qwen3.6:27b si vous voulez la version 27B publiée la plus récente. Un tag qui n’existe pas échoue avec Error: pull model manifest: file does not exist.

De quelle quantité de RAM ai-je besoin pour exécuter un modèle Qwen 27B sur un VPS ?

32 GB constituent le minimum pratique pour Q4_K_M. Les poids occupent 17 GB. Le système d’exploitation a besoin d’environ 1.5 GB. Le KV cache ajoute environ 1 GB pour chaque tranche de 4000 tokens de contexte en f16. Une offre de 16 GB ne peut pas contenir les poids. Le swap n’aide pas, car le fichier est mappé en mémoire et le kernel le relit simplement depuis le disque à chaque token. 64 GB vous laissent de la marge pour un contexte long ou pour des poids Q8_0 de 30 GB.

Combien de tokens par seconde un modèle 27B fournira-t-il sur CPU ?

Divisez la bande passante mémoire par la taille des poids, puis retenez 50 à 70 % de cette valeur. Un VPS DDR4-3200 à deux canaux a un plafond proche de 3 tokens par seconde et fournit environ 2. Un serveur DDR5-4800 à deux canaux a un plafond proche de 4.5 et fournit environ 3. Les plateformes serveur avec davantage de canaux semblent nettement meilleures sur le papier. Mais la bande passante mémoire est partagée entre tous les tenants de l’hôte. Mesurez donc vos performances avec ollama run qwen3.6:27b --verbose et lisez la ligne eval rate.

Dois-je utiliser Q4 ou Q8 sur un VPS avec CPU uniquement ?

Q4_K_M, dans presque tous les cas. Q8_0 occupe 30 GB contre 17 GB. Il nécessite donc une offre de 64 GB et déplace presque deux fois plus de mémoire par token, ce qui réduit environ de moitié le nombre de tokens par seconde. La différence de qualité entre Q4_K_M et Q8_0 est faible pour la plupart des tâches avec un modèle 27B. Utilisez plutôt la RAM pour augmenter la longueur du contexte. Cela modifie les capacités du modèle, et pas seulement sa formulation.

Quand la location d’un GPU coûte-t-elle moins cher qu’un VPS avec beaucoup de RAM ?

Lorsque le taux d’utilisation est faible ou qu’une personne attend le résultat. Un GPU doté de 24 GB de mémoire atteint environ 59 tokens par seconde avec ces poids, contre 2 ou 3 sur un VPS classique. Il n’est facturé que pendant les heures où il fonctionne. Un VPS de 64 GB est facturé pendant tout le mois, que le modèle soit chargé ou non. Calculez le nombre réel d’heures par jour pendant lesquelles vous générez des tokens. En dessous de deux ou trois heures, la location horaire d’un GPU est généralement plus rapide et moins coûteuse. Le VPS toujours actif est avantageux pour les traitements par lots continus et à faible priorité.