Exécuter Qwen 3.8 avec Ollama sur un VPS Linux : variant 27B, mémoire sans GPU, API et Open WebUI

Qwen 3.8 27B : un modèle open weights à la portée d'un VPS sans GPU

Qwen3.8-27B est le modèle de langage (LLM) dense de 27 milliards de paramètres publié en open weights par l'équipe Qwen d'Alibaba en août 2026, sous licence Apache 2.0. Les poids sont disponibles sur Hugging Face (Qwen/Qwen3.8-27B) et le modèle est proposé dans la bibliothèque Ollama sous le nom qwen3.8, avec les capacités vision, tools et thinking : il lit les images, appelle des outils et raisonne avant de répondre. Le contexte natif annoncé par la fiche du modèle est de 262 144 tokens, extensible à 1 million avec YaRN.

Ce qui rend Qwen 3.8 intéressant pour un administrateur de VPS Linux, c'est son architecture hybride : sur ses 64 couches, trois couches Gated DeltaNet alternent avec une seule couche d'attention classique. Seules ces 16 couches d'attention alimentent le cache KV, celui qui grossit avec la longueur du contexte. À taille de modèle égale, la mémoire consommée par le contexte est donc bien plus faible que sur un modèle 27B entièrement en attention, et c'est précisément ce qui permet de faire tourner un modèle de cette taille sur un serveur VPS sans GPU, uniquement sur le processeur.

Ce guide part d'un serveur où Ollama tourne déjà en service systemd (installer Ollama sur un VPS Linux) et détaille ce qui est propre à Qwen 3.8 : choisir le bon variant parmi les treize tags du registre Ollama, dimensionner la RAM, régler le contexte et le mode réflexion, exposer l'API derrière NGINX et brancher Open WebUI. Pour la gestion courante des modèles (lister, supprimer, mettre à jour), voir gérer ses modèles Ollama sur un VPS Linux.

Prérequis : RAM, disque et processeur pour un modèle 27B

• Ollama à jour sur Ubuntu 22.04/24.04 LTS ou Debian 12. Le tag qwen3.8 utilise l'architecture qwen35 côté Ollama : relancez le script d'installation officiel (curl -fsSL https://ollama.com/install.sh | sh) avant de télécharger le modèle, un binaire trop ancien ne saura pas le charger ;
• 32 Go de RAM minimum pour la quantisation Q4_K_M (fichier de 18 Go), 48 Go pour la Q8_0 (30 Go). Le modèle doit tenir entièrement en mémoire vive : un modèle qui déborde sur le swap devient inutilisable, le disque étant des dizaines de fois plus lent que la RAM ;
• 25 à 40 Go d'espace disque SSD libres, selon le variant, plus la place pour un second modèle si vous comparez deux quantisations ;
• Le plus de vCPU possible : en inférence CPU, chaque token généré oblige le processeur à relire l'intégralité des poids du modèle. Le débit dépend d'abord de la bande passante mémoire, puis du nombre de coeurs (pourquoi tous les vCPU ne se valent pas) ;
• Un accès SSH avec sudo (sécuriser SSH sur un VPS Linux).

Chez ElypseCloud, le palier VPS Linux Space (8 vCPU, 32 Go DDR4, 150 Go SSD) est le premier qui accueille Qwen 3.8 en Q4_K_M avec une marge pour le système et le contexte. Le palier Nova (12 vCPU, 48 Go DDR4, 250 Go SSD) permet la Q8_0 ou un contexte beaucoup plus long en Q4. En dessous de 32 Go, restez sur un modèle plus petit : le tableau des modèles par taille de RAM se trouve dans notre guide d'installation d'Ollama.

Quel variant de Qwen 3.8 télécharger : les tags Ollama

Le registre Ollama liste treize tags pour qwen3.8, tous en 27B. Le tag par défaut (qwen3.8, alias qwen3.8:27b) correspond à la quantisation Q4_K_M du modèle, avec un projecteur vision en BF16, pour 18 Go au total. Sur un VPS Linux x86-64 sans GPU, seuls les tags GGUF classiques vous concernent :

Pas de Q5 ni de Q6 sur le registre officiel. Si vous voulez un compromis entre la Q4_K_M et la Q8_0, la communauté publie des GGUF de Qwen3.8-27B sur Hugging Face, par exemple le dépôt unsloth/Qwen3.8-27B-GGUF avec une UD-Q5_K_M de 19,8 Go et une UD-Q6_K de 22 Go. Ollama les télécharge directement depuis Hugging Face :

ollama run hf.co/unsloth/Qwen3.8-27B-GGUF:UD-Q5_K_M

Ces quantisations ne sont pas produites par l'équipe Ollama : vérifiez avec ollama show que le modèle se charge et que les capacités attendues (thinking, tools) sont bien détectées avant de le mettre en production. Pour la plupart des usages sur VPS, la Q4_K_M officielle reste le meilleur rapport qualité, RAM et débit.

Règle de dimensionnement : RAM nécessaire = taille du fichier + cache KV du contexte + environ 2 Go pour le système. La section sur la mémoire ci-dessous chiffre le cache KV.

Télécharger Qwen 3.8 et mesurer le débit réel

Téléchargez le variant choisi avec son tag explicite, puis vérifiez ses métadonnées (architecture, nombre de paramètres, quantisation, taille de contexte, capacités) :

ollama pull qwen3.8:27b-q4_K_M
ollama show qwen3.8:27b-q4_K_M

Le téléchargement de 18 Go prend quelques minutes sur une connexion 1 Gbit/s. Lancez ensuite une première génération avec l'option --verbose, qui affiche les temps de chargement et le débit en tokens par seconde à la fin de la réponse :

ollama run qwen3.8:27b-q4_K_M --verbose "Explique en trois phrases ce qu'est un cache KV."

Deux lignes comptent dans le résumé affiché : prompt eval rate (vitesse de lecture du prompt) et eval rate (vitesse de génération). Sur un VPS sans GPU, le second chiffre se compte en tokens par seconde, pas en dizaines : à chaque token, le processeur relit les 18 Go de poids. Avec une bande passante mémoire effective de 20 Go/s, le plafond théorique est d'environ un token par seconde ; à 60 Go/s, environ trois. C'est ce chiffre, mesuré sur votre serveur, qui décide si Qwen 3.8 convient à votre usage ou s'il faut un modèle plus petit.

Pendant la génération, ouvrez un second terminal SSH et vérifiez l'empreinte mémoire réelle du modèle chargé :

ollama ps

La colonne SIZE indique la mémoire occupée (poids + cache KV), la colonne PROCESSOR affiche 100% CPU sur un VPS sans carte graphique. Complétez avec htop ou btop pour surveiller la RAM libre du système pendant une requête longue.

Configurer les limites mémoire et le contexte sur un VPS sans GPU

Ollama ouvre chaque modèle avec une fenêtre de contexte de 4 096 tokens par défaut, quelle que soit la limite du modèle. C'est trop court pour analyser un fichier de logs ou un dépôt de code, mais chaque token de contexte supplémentaire coûte de la RAM. Pour Qwen 3.8, le calcul se fait à partir de la fiche du modèle : 16 couches d'attention, 4 têtes KV, dimension de tête 256, soit 64 Ko par token en précision f16 pour le cache KV. Les couches Gated DeltaNet ajoutent un état de taille fixe, indépendant de la longueur :

Sur un VPS 32 Go, un contexte de 32 768 tokens en Q4_K_M laisse de la marge ; 131 072 tokens passent encore mais réclament 48 Go pour rester confortable. Ces valeurs sont des estimations calculées : la seule mesure qui fait foi est la colonne SIZE de ollama ps après une requête qui remplit réellement le contexte.

Les limites se fixent dans une surcharge systemd, sans toucher au fichier d'unité installé par le script (comprendre les unités systemd) :

sudo systemctl edit ollama.service

Contenu de la section [Service] pour un VPS 32 Go dédié à Qwen 3.8 :

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_CONTEXT_LENGTH=16384"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_KEEP_ALIVE=15m"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Rôle de chaque variable, d'après la documentation Ollama :

• OLLAMA_CONTEXT_LENGTH : fenêtre de contexte par défaut pour tous les modèles (4 096 si absente). Une requête peut la dépasser ponctuellement avec l'option num_ctx de l'API ;
• OLLAMA_NUM_PARALLEL : nombre de requêtes traitées en parallèle par modèle. La RAM du cache KV est multipliée par cette valeur : sur un VPS sans GPU, gardez 1 ;
• OLLAMA_MAX_LOADED_MODELS : nombre de modèles chargés simultanément. Par défaut 3 en inférence CPU, ce qui autorise Ollama à charger deux autres modèles à côté de Qwen 3.8 si la mémoire le permet. Avec un seul modèle de 18 Go, limitez à 1 pour garder une marge prévisible ;
• OLLAMA_KEEP_ALIVE : durée pendant laquelle le modèle reste chargé après la dernière requête (5 minutes par défaut). Recharger 18 Go depuis le SSD prend du temps : allongez la valeur si le serveur ne sert que Qwen 3.8, mettez -1 pour ne jamais décharger ;
• OLLAMA_FLASH_ATTENTION et OLLAMA_KV_CACHE_TYPE : la quantisation du cache KV en q8_0 divise sa taille par deux environ par rapport au f16, et q4_0 par quatre ; elle exige Flash Attention et s'applique à tous les modèles du serveur.

Appliquez et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -n 30

Gardez un swap de quelques gigaoctets comme filet de sécurité, pas comme extension de RAM (configurer le swap sur un VPS Linux). Si la mémoire sature malgré tout, le noyau tue le processus ollama et la requête échoue sans message côté client : les traces se lisent dans journalctl -k (comprendre l'OOM Killer). Réduisez alors OLLAMA_CONTEXT_LENGTH avant de changer de variant.

Maîtriser le mode réflexion : le vrai coût CPU de Qwen 3.8

Qwen 3.8 réfléchit par défaut : avant la réponse, il génère un bloc de raisonnement (thinking) qui peut représenter des centaines, voire des milliers de tokens. Sur un GPU, ce surcoût passe inaperçu. Sur un VPS à deux ou trois tokens par seconde, il transforme une réponse de dix secondes en plusieurs minutes d'attente. La règle sur CPU : désactivez la réflexion pour les tâches simples (classification, résumé, extraction, reformulation), gardez-la pour le code et les tâches agentiques où elle fait la différence.

En ligne de commande, le drapeau --think accepte true, false ou un niveau (low, medium, high) pour les modèles qui le supportent ; --hidethinking masque le raisonnement sans l'empêcher :

ollama run qwen3.8:27b-q4_K_M --think=false "Classe ce ticket : urgent, normal ou faible ?"

Dans l'API, le champ think se passe au niveau de la requête, sur /api/chat comme sur /api/generate. Les valeurs acceptées par un modèle donné se lisent dans l'objet thinking renvoyé par /api/show :

curl http://localhost:11434/api/show -d '{"model": "qwen3.8:27b-q4_K_M"}'

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3.8:27b-q4_K_M",
  "messages": [{"role": "user", "content": "Résume ce journal systemd en cinq points."}],
  "think": false,
  "stream": false,
  "options": {"num_ctx": 16384, "temperature": 0.7, "top_p": 0.8, "top_k": 20}
}'

Les valeurs d'échantillonnage ci-dessus sont celles que la fiche du modèle recommande en mode sans réflexion (température 0,7, top_p 0,8, top_k 20). En mode réflexion, la fiche conseille température 1,0, top_p 0,95 et top_k 20. Avec "think": true, la réponse JSON sépare le raisonnement (message.thinking) du contenu (message.content), ce qui permet à une application de n'afficher que le second.

Exposer l'API Ollama : NGINX, TLS et délais adaptés à un 27B

Laissez Ollama sur 127.0.0.1:11434 et placez NGINX devant, avec une authentification HTTP Basic et un certificat Let's Encrypt. La configuration complète (fichier htpasswd, bloc server, en-têtes) est détaillée dans la section reverse proxy de notre guide Ollama et dans NGINX en reverse proxy sur VPS Linux. Un point change avec Qwen 3.8 en inférence CPU : les délais. Une réponse de 800 tokens avec réflexion peut dépasser cinq minutes, donc les 300 secondes du guide générique ne suffisent plus :

    location / {
        auth_basic "Ollama API";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 900s;
        proxy_send_timeout 900s;
    }

proxy_buffering off est indispensable pour que le streaming token par token arrive au client au fil de la génération : sans lui, NGINX accumule la réponse et l'envoie d'un bloc à la fin. Rechargez NGINX après sudo nginx -t, puis obtenez le certificat avec Certbot et Let's Encrypt. Côté pare-feu, seuls les ports 22, 80 et 443 doivent être ouverts, jamais le 11434 (configurer UFW sur un VPS Linux).

Depuis un poste distant, l'endpoint compatible OpenAI permet d'utiliser n'importe quel SDK ou outil en changeant seulement l'URL de base et le nom du modèle :

curl -u ollama-user:VOTRE_MOT_DE_PASSE https://ollama.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3.8:27b-q4_K_M", "messages": [{"role": "user", "content": "Bonjour"}]}'

Pour les agents de code, Ollama documente aussi la commande ollama launch, qui configure une application externe pour utiliser un modèle local, par exemple ollama launch claude --model qwen3.8. Les intégrations listées sont OpenCode, Claude Code, Codex, VS Code et Droid. Sur un VPS, gardez en tête que ces outils enchaînent des dizaines d'appels avec réflexion : c'est l'usage le plus exigeant pour une inférence CPU.

Connecter Open WebUI à Qwen 3.8

Open WebUI donne une interface de chat à votre modèle, avec comptes utilisateurs, historique et envoi d'images, que Qwen 3.8 sait lire. Le piège classique sur un VPS : le conteneur Docker d'Open WebUI ne joint pas un Ollama qui n'écoute que sur 127.0.0.1. La documentation Open WebUI propose deux solutions. La première conserve Ollama sur l'adresse locale et branche le conteneur directement sur le réseau de l'hôte :

docker run -d --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -e WEBUI_SECRET_KEY=votre-cle-secrete-generee-avec-openssl \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Avec --network=host, l'interface écoute sur le port 8080 du VPS (et non 3000) : bloquez ce port dans UFW et servez-la en HTTPS derrière NGINX, comme décrit dans installer Open WebUI avec Docker sur un VPS Linux. La seconde solution consiste à faire écouter Ollama sur 0.0.0.0 (OLLAMA_HOST=0.0.0.0:11434 dans la surcharge systemd) et à laisser le conteneur passer par host.docker.internal ; elle impose de filtrer le port 11434 au pare-feu, l'API Ollama n'ayant aucune authentification propre.

Une fois connecté, qwen3.8:27b-q4_K_M apparaît dans le sélecteur de modèles. Deux réglages comptent pour un 27B sur CPU : le délai du reverse proxy devant Open WebUI (le guide utilise 1 800 secondes, gardez-le) et la réflexion, que vous pouvez laisser aux utilisateurs ou désactiver par défaut selon votre débit mesuré. Pour mémoire, Open WebUI seul consomme quelques centaines de Mo : c'est bien le modèle qui dimensionne le VPS.

VPS CPU ou serveur GPU : où s'arrête Qwen 3.8 sans carte graphique

Un VPS 32 ou 48 Go fait tourner Qwen 3.8 pour un utilisateur à la fois, des traitements par lots (classification de tickets, résumé de logs, extraction de données la nuit) et pour valider le modèle avant d'investir dans du matériel. Il ne tient pas plusieurs utilisateurs simultanés : avec OLLAMA_NUM_PARALLEL=1, les requêtes font la queue, et chaque réponse longue bloque les suivantes pendant des minutes.

Pour arbitrer entre les deux moteurs quand le GPU arrive, lisez notre comparatif vLLM vs Ollama sur serveur dédié. Si vous restez sur CPU mais voulez plus de bande passante mémoire et de coeurs physiques, le retour d'expérience LLM sur CPU avec llama.cpp sur un serveur dédié Xeon Gold montre ce qu'apporte un serveur physique sans virtualisation (serveur dédié bare metal vs VPS).

Conclusion

Qwen 3.8 27B se déploie sur un VPS Linux sans GPU en quatre décisions : le tag qwen3.8:27b-q4_K_M (18 Go) sur un serveur de 32 Go de RAM, ou la Q8_0 (30 Go) sur 48 Go ; un contexte fixé par OLLAMA_CONTEXT_LENGTH en fonction de la RAM restante, avec OLLAMA_NUM_PARALLEL=1 et un seul modèle chargé ; le mode réflexion désactivé pour les tâches simples et réservé au code ; une API laissée sur l'adresse locale, exposée par NGINX avec des délais longs et une authentification. Mesurez le débit avec --verbose et la mémoire avec ollama ps avant de brancher Open WebUI ou vos scripts : ce sont ces deux chiffres, pas les benchmarks publiés, qui disent si le modèle tient sur votre VPS.