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 avez besoin du tag qwen3.8:27b. Au 17 octobre 2026, la bibliothèque Ollama le propose comme tag pouvant être téléchargé localement : 27.3 milliards de paramètres, quantification Q4_K_M, licence Apache 2.0, fenêtre de contexte de 256K et téléchargement de 18 GB comprenant un vision projector d’environ 0.9 GB. Ollama a ajouté la prise en charge de Qwen 3.8 27B dans la version v0.32.12, publiée le 14 août 2026. Une installation plus ancienne doit donc d’abord être mise à niveau. Au 17 octobre 2026, la dernière version stable est v0.40.5, publiée le 14 octobre 2026.

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

Les anciens tags 27B sont toujours présents dans la bibliothèque : qwen3.6:27b et qwen3.5:27b sont tous deux des builds Q4_K_M de taille similaire. Qwen3.8-27B conserve l’architecture de Qwen3.6-27B, et les fichiers de configuration officiels des deux modèles indiquent la même organisation des couches. Les calculs de mémoire ci-dessous s’appliquent donc aux deux modèles. Consultez la liste actuelle avant de copier une commande, sur la page des tags qwen3.8 d’Ollama. Les calculs présentés ici dépendent du nombre de paramètres, du nombre de bits par poids et de l’organisation de l’attention, pas du numéro de version.

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

Le téléchargement d’une balise qui n’existe pas renvoie une erreur explicite. Il est donc rapide de vérifier ce point directement sur le serveur. Une balise existante peut tout de même être impossible à exécuter 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 --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama show affiche l’architecture, le nombre de paramètres, la longueur du contexte et la quantification de la balise effectivement installée. Si la ligne des paramètres indique 27.3B et que la ligne de quantification indique Q4_K_M, vous disposez de la build utilisée par ce guide. La bibliothèque contient également qwen3.8:27b-q8_0 et qwen3.8:27b-bf16 pour les mêmes poids avec une précision supérieure, des variantes 27b-mtp, ainsi que les balises 27b-nvfp4, 27b-mxfp8, 27b-mlx et 27b-mlx-bf16 que la page des balises identifie comme MLX. Ce format cible les systèmes Apple Silicon plutôt qu’un VPS Linux. Contrairement à qwen3.6, l’entrée qwen3.8 ne possède aucune balise 35b-a3b. Ces modèles MoE (mixture of experts) restent classés sous qwen3.6 et se comportent très différemment sur CPU. 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.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

La formule tient sur une ligne. Octets des poids = paramètres × bits par poids / 8. Avec une quantification exacte sur 4 bits, 27.3 milliards de paramètres occupent 13.7 GB. Le fichier du modèle de langue dans le tag Q4_K_M fourni fait 17 GB, soit 4.98 bits par poids en pratique.

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 reçoivent davantage de bits : la liste des tenseurs du fichier qwen3.8:27b fourni par Ollama indique que la couche de sortie, les projections QKV de l’attention et certaines projections descendantes du feed-forward sont en Q6_K. Les petits tenseurs de normalisation utilisent la précision complète sur 32 bits, tandis que l’incorporation des tokens reste en Q4_K, comme la plupart du modèle. Le nom du format indique une moyenne, et cette moyenne est proche de 5. Le même effet apparaît à l’autre extrémité de l’échelle : 55 GB en BF16 correspondent à 16.1 bits par poids, et non à une valeur fixe de 16. Dans ce cas, l’incorporation des tokens est en BF16 comme le reste, et le léger dépassement vient des métadonnées du fichier, des tenseurs de normalisation conservés sur 32 bits et de l’arrondi de la taille affichée au gigaoctet le plus proche.

Prévoyez la taille de l’ensemble du tag, et pas seulement celle du fichier du modèle de langue. Chaque tag GGUF de qwen3.8:27b fournit également un projecteur de vision d’environ 0.9 GB. C’est pourquoi le tag Q4_K_M est indiqué à 18 GB.

Q5_K_M ne dispose d’aucun tag publié pour ce modèle. La ligne de 19.5 GB est donc calculée avec la valeur habituelle de 5.7 bits par poids pour ce format, et non mesurée. Q8_0 double presque la taille de Q4, pour atteindre 29 GB. Sur une machine avec CPU uniquement, ce doublement multiplie par deux le trafic mémoire par token. Il réduit donc aussi approximativement 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 comparer 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.

Le coût du cache KV lorsque 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 là que la RAM vient à manquer.

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

Ces chiffres proviennent du fichier de configuration du modèle. Qwen3.8-27B, comme Qwen3.6-27B, est un modèle à attention hybride. Seules 16 de ses 64 couches utilisent l’attention complète et conservent un cache qui augmente avec chaque token. Ces couches disposent de 4 têtes de clés/valeurs avec GQA (grouped-query attention) et d’une dimension de tête de 256. Les 48 autres couches utilisent l’attention linéaire (Gated DeltaNet) et conservent à la place un état de taille fixe qui, d’après mes calculs, représente environ 150 MB par slot de conversation, quelle que soit la longueur du contexte. Cela correspond à 64 KiB par token en f16, soit 2 GB pour 32k tokens et 8 GB pour 128k. Ne vous fiez pas à mes calculs pour votre propre machine. Chargez le modèle et consultez la colonne SIZE de ollama ps, qui indique les poids, le cache et la surcharge dans une valeur unique.

Le contexte de 256K indiqué sur la fiche du modèle est accessible avec cette architecture, mais il n’est pas gratuit. Le remplir en f16 nécessite environ 16 GB de cache en plus des poids, sur une machine qui utilise déjà 17 GB pour les poids. Ollama ne vous attribue pas la fenêtre complète par défaut. Il en charge une bien plus petite, que la FAQ d’Ollama indique comme étant de 4096 tokens, et vous l’augmentez volontairement 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 peu coûteuse pour toutes les autres requêtes, tandis qu’un traitement long utilise une fenêtre plus grande. Augmentez cette valeur progressivement et vérifiez ollama ps après chaque modification.

Deux réglages permettent de réduire la taille du cache. OLLAMA_KV_CACHE_TYPE=q8_0 stocke le cache sur 8 bits au lieu de 16, ce qui fait passer le cache pour 32k tokens de 2 GB à 1 GB. Ce réglage nécessite flash attention. Définissez donc également OLLAMA_FLASH_ATTENTION=1 et 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 slot reçoit sa propre portion du contexte. Augmenter le parallélisme multiplie donc discrètement la taille de cache à prévoir. La valeur par défaut actuelle est déjà 1, et la surcharge ci-dessous la fixe à cette valeur. Si plusieurs personnes doivent utiliser cette machine, c’est cette multiplication qui provoque les problèmes. Le nombre d’utilisateurs simultanés qu’un modèle auto-hébergé peut servir dépend des slots 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": 128,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room for long context. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

Lisez les deux nombres comme les milliers de tokens de contexte disponibles en plus des poids et du vision projector, 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 supplémentaire. Un 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 mappe le fichier GGUF en mémoire. Dès que le nombre de pages résidentes dépasse la RAM, le kernel commence à les évincer puis à les relire. Chaque token doit alors récupérer plusieurs 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 prennent 17 Go, le vision projector ajoute environ 0.9 Go et il reste environ 12.5 Go. Cela permet environ 128k tokens de contexte f16 avec une marge. Les poids Q8_0 de 29 Go ne tiennent pas du tout dans ce palier.

64 Go offre une marge confortable. En Q4, il reste assez de mémoire pour la fenêtre complète de 256k tokens. Les poids Q8_0 tiennent également avec la fenêtre complète de 256k tokens. Avant de payer 64 Go pour utiliser Q8, déterminez clairement ce que vous achetez : une sortie légèrement meilleure, à la moitié de la vitesse, sur une machine déjà lente. Q4 atteint déjà 128k tokens avec une configuration de 32 Go, ce qui constitue le meilleur compromis pour presque tout le monde.

À quelle vitesse s’effectue l’inférence CPU sur un VPS ?

Générer un token avec un modèle dense implique de lire chaque poids en mémoire une fois. Pas seulement certains poids. 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 équipé de deux canaux DDR4-3200 a un plafond de 3 tokens par seconde : prévoyez donc environ 2. Une machine équipée de deux canaux DDR5-4800 a un plafond de 4.5, soit environ 3 en pratique.

Les lignes correspondant aux gros serveurs doivent être interprétées avec prudence. Une plate-forme EPYC à douze canaux dispose de 460.8 Go/s et d’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 instance de 8 vCPU ne bénéficie donc pas de douze canaux de bande passante exclusifs. Les guides consacrés aux GPU ignorent entièrement ce point. C’est pourquoi deux offres VPS avec le même nombre de vCPU peuvent avoir un débit trois fois différent avec le même modèle.

Ajouter des vCPU cesse d’être utile assez rapidement pour la même raison. Lorsque 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. Ollama ne possède pas de variable d’environnement globale pour le nombre de threads. Définissez donc num_thread dans la requête options sur le nombre de cœurs physiques, mesurez le résultat, puis essayez la moitié de cette valeur. Sur de nombreuses offres mutualisées, la valeur inférieure est plus rapide.

Le traitement du prompt se comporte différemment. Le prefill, c’est-à-dire le passage sur votre entrée avant l’apparition du premier token, dépend surtout du calcul et non de la bande passante. Il évolue donc avec le nombre de cœurs. En pratique, un long délai précède l’apparition du texte avec un prompt volumineux, puis le débit reste stable et lent comme indiqué plus haut. Mesurez séparément ces deux phases avec --verbose. Cette commande 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 de renoncer au CPU. Ceux-ci activent environ 3 milliards de paramètres par token au lieu des 27.3 milliards, ce qui réduit presque d’un ordre de grandeur le trafic mémoire par token, même si le fichier sur disque est plus volumineux. Vous échangez ainsi 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 pour le 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 publiée conduit à une conclusion différente. Une carte grand public de 24 GB atteint au maximum 59 tokens par seconde avec ces poids. Une carte actuelle pour centre de données atteint 197. Cet écart ne se résout pas en ajustant le nombre de threads. La carte exploite une bande passante mémoire de 1008 GB/s, alors que votre VPS se situe à quelques dizaines de GB/s.

Il faut donc faire la distinction selon la charge, et non selon les préférences. 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 exécutée chaque nuit pendant votre sommeil. Louez un GPU dès qu’une personne attend la réponse ou que les requêtes arrivent plus vite que votre machine ne peut les traiter. Les runtimes CPU ne sont pas limités à une seule requête à la fois : la documentation du serveur llama.cpp décrit le décodage parallèle et le continuous batching sur CPU comme sur GPU, et Ollama peut également traiter des requêtes en parallèle, au prix d’une consommation de cache plus élevée. Le critère décisif est le débit de traitement mesuré par rapport au débit d’arrivée des requêtes. Mesurez donc le temps nécessaire pour traiter un lot réaliste sur votre propre machine. Dès que les requêtes arrivent plus vite que ce débit, la file d’attente s’allonge.

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ù elle reste active. 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 tarifs. Choisir un VPS avec un GPU présente les points à vérifier sur l’instance elle-même, tandis que vLLM prend l’avantage sur Ollama dès que vous traitez des requêtes simultanées sur un GPU explique pourquoi vLLM les regroupe correctement.

Il existe une troisième option souvent oubliée. Conservez 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 usages.

Installer Ollama et mesurer votre propre machine

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

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

ollama --version doit afficher 0.32.12 ou une version ultérieure, c’est-à-dire la première version compatible avec Qwen 3.8 27B. Vérifiez free -g avant de télécharger quoi que ce soit. Si la colonne total de la ligne Mem indique une valeur inférieure à 32, arrêtez-vous ici et choisissez un modèle plus petit. Télécharger 18 GB pour un modèle 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.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

La sortie de --verbose est la mesure recherchée. eval rate correspond à votre nombre de tokens par seconde pendant la génération. prompt eval rate correspond à votre vitesse de prefill. load duration indique le temps nécessaire pour lire les poids 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 assez court pour qu’une file de traitement par lots avec des intervalles entre les éléments paie ce coût de chargement encore et encore. les options permettant de garder un modèle résident couvrent à la fois le champ keep_alive par requête et la conservation du réglage après un redémarrage.

Pendant que le modèle est chargé, vérifiez son empreinte 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 poids, à laquelle s’ajoutent le projecteur de vision et la ligne correspondant à la longueur de contexte utilisée dans le tableau KV. Avec 8192 tokens et un cache 8-bit, la partie croissante du cache ne représente qu’environ un quart de gigaoctet, contre 0.5 GB si elle restait en f16, avec l’état fixe de l’attention linéaire en plus. La colonne PROCESSOR doit afficher 100% CPU. Si elle affiche autre chose, un GPU est utilisé par un composant et les chiffres de vitesse 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 indique 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, car Ollama effectue le contrôle avant l’allocation, au lieu de laisser le kernel gérer la situation. Réduisez la longueur du contexte, utilisez un tag plus petit ou passez à une offre disposant de davantage de ressources.

Le processus disparaît au milieu d’une réponse. Le client n’affiche rien d’utile et journalctl -u ollama -n 50 montre 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. Un numéro de version qui n’a pas été publié produit exactement ce message, tout comme une faute de frappe dans le tag. qwen3.8:27b existe bien. Si ce tag précis échoue, recherchez d’abord une faute de frappe. Vérifiez le tag sur la page de la bibliothèque avant d’incriminer votre réseau. Si un tag valide est téléchargé mais ne s’exécute pas, vérifiez ollama --version par rapport à 0.32.12.

Tout fonctionne, mais c’est insupportablement lent. Moins d’un token par seconde sur une machine disposant de suffisamment de RAM indique un problème de paging plutôt qu’un manque de puissance de calcul. Exécutez vmstat 1 pendant la génération. Une colonne si ou so non nulle signifie que le kernel utilise le swap. La solution consiste à réduire le contexte ou le nombre de modèles chargés. Une valeur wa élevée et stable, 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 sortie s’accélère. C’est le prefill, et c’est normal. Un long system prompt doit être traité pour chaque requête qui ne bénéficie pas du cache. Raccourcissez donc le system prompt avant de modifier d’autres paramètres.

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

Fondez vos attentes sur les chiffres, pas sur vos espoirs. À deux à quatre tokens par seconde, une réponse de 500 tokens prend entre deux et quatre minutes. C’est inutilisable pour un 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 masqués sont générés à la même vitesse lente que la réponse. Adapter le niveau d’effort de raisonnement à la tâche est donc l’un des rares leviers permettant de raccourcir une réponse sans changer de modèle. La synthèse de documents, l’étiquetage en masse, l’extraction de champs dans 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 codage se situe exactement à cette limite. Pointer un agent de codage vers un modèle que vous hébergez est donc utile pour des tâches en arrière-plan comme les messages de commit et la génération de structures de tests, mais pas pour les suggestions inline que vous attendez devant l’écran.

L’argument de la confidentialité est le véritable avantage. 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 frontier nécessite un ordre de grandeur matériel supplémentaire. Un modèle 27B sur CPU est le point le moins coûteux de cette courbe où les sorties restent suffisamment utiles pour être lues.

Pour évaluer tout cela, vous avez besoin d’une entrée structurée réelle. La plupart des API de données publiques exigent un compte avant même de permettre de mesurer le débit. Le endpoint de démonstration de Strasmore (que nous exécutons) accepte des requêtes SQL en lecture seule sur des données d’actions et d’options américaines, 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 de la démonstration sont de 500 lignes et 20 secondes par appel, avec un historique disponible depuis le 1 janvier 2025. Cela dépasse largement ce qu’un serveur à deux tokens par seconde peut traiter. La liste complète des colonnes se trouve à https://ai.strasmore.com/api/demo/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 de pare-feu que ce guide suppose déjà en place. N’exposez pas le port 11434 sur Internet. Ollama ne fournit aucune authentification native. Tout hôte 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 ?

Oui. Au 17 octobre 2026, la bibliothèque Ollama contient une entrée qwen3.8, et qwen3.8:27b (également étiqueté latest) est une version Q4_K_M de 18 GB d’un modèle dense de 27.3 milliards de paramètres, avec un projecteur de vision et une fenêtre de contexte de 256K. Il s’exécute localement et nécessite Ollama v0.32.12 ou une version ultérieure. Les anciens tags qwen3.6:27b et qwen3.5:27b sont toujours listés. Consultez https://ollama.com/library/qwen3.8/tags pour obtenir la liste actuelle. Un tag inexistant échoue avec Error: pull model manifest: file does not exist.

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

32 GB est le minimum pratique pour Q4_K_M. Les poids font 17 GB, le projecteur de vision ajoute environ 0.9 GB, le système d’exploitation nécessite environ 1.5 GB et le cache KV ajoute environ 1 GB par tranche de 16,000 tokens de contexte en f16, car seules 16 des 64 couches du modèle conservent un cache qui augmente. Une offre de 16 GB ne peut pas contenir les poids, et 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 assez de mémoire pour la fenêtre complète de 256K, même avec des poids Q8_0 de 29 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 prenez 50 à 70 % de cette valeur. Un VPS DDR4-3200 à deux canaux atteint un plafond proche de 3 tokens par seconde et en fournit environ 2. Une machine DDR5-4800 à deux canaux atteint un plafond proche de 4.5 et en fournit environ 3. Les plateformes serveur dotées de davantage de canaux semblent bien meilleures sur le papier, mais la bande passante mémoire est partagée entre tous les tenants de l’hôte. Mesurez donc les performances de votre propre machine avec ollama run qwen3.8:27b --verbose et lisez la ligne eval rate.

Dois-je utiliser Q4 ou Q8 sur un VPS limité au CPU ?

Q4_K_M, dans presque tous les cas. Q8_0 fait 29 GB contre 17 GB pour Q4_K_M. 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 sur un modèle 27B est faible pour la plupart des tâches. Utilisez plutôt la RAM pour une fenêtre de contexte plus longue, car cela modifie ce que le modèle peut faire, et non la manière dont il formule ses réponses.

Quand la location d’un GPU est-elle moins chère qu’un VPS avec beaucoup de RAM ?

Lorsque le taux d’utilisation est faible ou qu’une personne attend. 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, et il est facturé uniquement pendant les heures où il fonctionne. Un VPS de 64 GB est facturé tout le mois, que le modèle soit chargé ou non. Calculez pendant combien d’heures par jour vous générez réellement des tokens. En dessous de deux ou trois heures, la location horaire d’un GPU est généralement gagnante à la fois en vitesse et en coût. Les traitements batch continus à faible priorité sont le cas où le VPS toujours actif est avantageux.