Quel modèle GLM exécuter sur un VPS avec Ollama ?

Pouvez-vous exécuter GLM 5.2 sur un VPS ?

Non. Il est important de le savoir avant de louer quoi que ce soit. Au 18 août 2026, GLM 5.2 dans la bibliothèque Ollama possède exactement un tag, glm-5.2:cloud. Un tag :cloud s’exécute sur les serveurs d’Ollama. Votre serveur envoie le prompt et reçoit les tokens ; les poids ne sont donc jamais écrits sur votre disque. Le modèle compte 756 milliards de paramètres. Avec 4 bits par paramètre pour 756 milliards de paramètres, les poids occupent environ 378 GB. Ce calcul ne tient pas encore compte du contexte, des activations ni du système d’exploitation. Aucun forfait VPS standard ne propose autant de mémoire.

Le modèle GLM qui tient sur un serveur que vous louez est glm-4.7-flash. Il est publié avec des poids téléchargeables dans 4 tags. Il s’agit d’un modèle mixture-of-experts : seule une petite partie du réseau s’exécute pour chaque token. Z.ai le décrit comme un modèle 30B-A3B : 30 milliards de paramètres au total, dont environ 3 milliards actifs par token. Ce guide répond donc à la question sur laquelle vous pouvez agir. Épinglez un tag, dimensionnez le serveur, mesurez votre propre vitesse et gardez l’endpoint privé.

Vérifiez le tag avant de copier une commande, y compris celles de cette page. La bibliothèque Ollama peut changer sans préavis. Ouvrez la liste des tags de glm-4.7-flash et vérifiez que le tag existe toujours. Si une version plus récente de GLM avec des poids locaux est disponible, préférez-la et notez le tag que vous avez réellement testé.

Si vous voulez malgré tout utiliser GLM 5.2, ollama run glm-5.2:cloud fonctionne après ollama signin, et se comporte comme n’importe quel autre modèle Ollama du côté client. Vous devez comprendre ce que cela implique : le prompt quitte votre serveur. Si vous vous auto-hébergez parce que les données doivent rester sur votre machine, un tag :cloud ne répond pas à cet objectif.

Quels tags GLM existent, et lequel utiliser explicitement

Trois entrées GLM officielles sont importantes ici. glm-5.2 et glm-5.1 sont disponibles uniquement dans le cloud. glm-4.7-flash est la version locale. Voici ses tags publiés, avec la taille de téléchargement indiquée par Ollama pour chacun.

[
  {
    "label": "q4_K_M",
    "download_gb": 19
  },
  {
    "label": "latest",
    "download_gb": 19
  },
  {
    "label": "q8_0",
    "download_gb": 32
  },
  {
    "label": "bf16",
    "download_gb": 60
  }
]

Ces chiffres sont publiés sur la page de la bibliothèque, et non mesurés. latest et q4_K_M sont tous deux indiqués à 19 GB, donc latest désigne actuellement la build Q4. Cela peut changer lors de n’importe quelle nouvelle publication. C’est pourquoi vous ne devez jamais écrire un ollama pull glm-4.7-flash sans précision dans un script ou un Dockerfile. Indiquez la quantisation. Le tag le plus volumineux, bf16, correspond à un téléchargement de 60 GB contenant les poids bfloat16 non quantifiés.

Une recherche dans la bibliothèque renvoie également des uploads avec un espace de noms et une barre oblique dans le nom, comme someuser/glm-5.2. Une barre oblique indique qu’un compte utilisateur l’a publié. Il s’agit donc d’une republication communautaire, et non de l’entrée officielle. Personne ne garantit quels poids elle contient. Traitez-la comme vous traiteriez n’importe quel binaire non signé trouvé en ligne.

Installer Ollama et récupérer le tag exact

L’installateur Linux d’Ollama s’exécute avec une seule commande.

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

L’installateur crée un service systemd qui s’exécute avec l’utilisateur ollama. Vérifiez qu’il a démarré avant de récupérer quoi que ce soit.

systemctl status ollama --no-pager

Active: active (running) signifie que l’API est en écoute sur le port 11434. Si l’unité n’existe pas, l’installateur a effectué une installation binaire classique. La documentation Linux d’Ollama fournit le fichier de service à créer manuellement.

La page glm-4.7-flash indique une version minimale d’Ollama. Un binaire plus ancien ne fait pas fonctionner le modèle plus lentement : il le refuse. La commande pull échoue alors avec un message indiquant que le modèle nécessite une version plus récente d’Ollama. Réexécutez le script d’installation pour effectuer la mise à niveau. Au 18 août 2026, la version actuelle est 0.32.14, largement supérieure à cette version minimale.

Récupérez maintenant un tag par son nom.

ollama pull glm-4.7-flash:q4_K_M
ollama ls

ollama ls doit afficher glm-4.7-flash:q4_K_M avec une taille proche des 19 GB publiés. Une commande pull qui échoue en cours d’exécution ne laisse rien d’exécutable. Réexécutez donc la même commande. Sur un petit plan, un disque plein est la cause la plus fréquente d’un échec de pull, plutôt qu’un problème réseau, car le modèle est écrit dans /usr/share/ollama/.ollama/models sur le système de fichiers racine. Vérifiez avec df -h /usr/share/ollama avant de commencer.

De quelle quantité de RAM chaque quantification a-t-elle besoin ?

Commencez par prendre la taille du téléchargement comme valeur minimale, puis ajoutez le reste. Les poids doivent rester en mémoire. Le cache KV (cache key/value) s’y ajoute. Le runtime l’utilise pour mémoriser les tokens déjà présents dans la conversation. Il faut également prévoir les tampons de calcul et la mémoire utilisée par le système d’exploitation. Une machine disposant exactement de 19 Go de RAM ne pourra pas exécuter le tag de 19 Go.

Il n’existe pas de coefficient unique valable dans tous les cas. Le cache KV augmente avec la longueur de contexte autorisée, et le reste varie selon les versions du runtime. Mesurez donc la consommation au lieu de l’estimer. Chargez le modèle avec un prompt trivial, puis consultez la quantité de mémoire réservée par le serveur.

ollama run glm-4.7-flash:q4_K_M "Reply with the single word: ready"
ollama ps

ollama ps affiche le modèle chargé avec une colonne SIZE et une colonne PROCESSOR. SIZE correspond à la quantité de mémoire effectivement réservée par le runtime. C’est cette valeur qu’il faut comparer à votre prévision. PROCESSOR indique où les calculs sont effectués. 100% CPU signifie donc qu’aucun GPU n’a été utilisé.

Lorsque le modèle ne tient pas en mémoire, l’échec est silencieux et se présente sous deux formes. Si le swap est activé, le chargement semble réussir, puis la génération devient extrêmement lente, car les pages sont déplacées entre le disque et la RAM à chaque token. Sans swap, le processus est tué immédiatement, et journalctl -k | grep -i "out of memory" affiche la ligne Out of memory: Killed process du kernel, qui nomme ollama. Vérifiez les deux éléments, car aucun n’affiche de message utile dans le terminal où vous saisissiez vos commandes.

Le passage du tag Q4 de 19 Go au tag Q8 de 32 Go est le principal levier dont vous disposez sur cette valeur. Q4 réduit quelque peu la qualité des sorties. L’ampleur de cette réduction dépend de la tâche. Les sorties structurées et les longues chaînes de raisonnement sont davantage affectées qu’une conversation simple. Différences pratiques entre Q4, Q8 et FP16 mérite d’être lu avant de faire votre choix, car sur un VPS utilisant uniquement le CPU, la quantification détermine généralement si le modèle peut être exécuté ou non.

Ce qui se passe sur un VPS sans GPU

La plupart des offres VPS ne fournissent pas de GPU. Ollama exécute alors le modèle sur le CPU sans vous avertir. Le résultat peut être exploitable ou non selon la charge de travail et votre patience.

L’architecture mixture-of-experts améliore la vitesse. Environ 3 milliards des 30 milliards de paramètres sont utilisés pour chaque token. Les calculs nécessaires par token sont donc bien moins nombreux qu’avec un modèle dense de 30B. En revanche, la mémoire nécessaire ne diminue pas. Chaque expert doit rester en mémoire, car le routeur peut sélectionner n’importe lequel pour le token suivant. Un serveur sans GPU a donc toujours besoin d’au moins 19 Go pour le tag Q4. Son débit dépend principalement de la bande passante mémoire, et non de la fréquence d’horloge.

Cela a une conséquence pratique : deux offres avec le même nombre de cœurs et la même quantité de RAM peuvent générer des tokens à des vitesses sensiblement différentes, car leurs sous-systèmes mémoire ne sont pas identiques. Une offre mutualisée ajoute une deuxième variable : le temps de steal CPU causé par un voisin bruyant apparaît sous la forme d’un débit en tokens par seconde qui varie d’une heure à l’autre. C’est pourquoi les chiffres publiés par d’autres utilisateurs ne permettent pas de prévoir les vôtres, et pourquoi la section suivante propose une méthode de mesure plutôt qu’un tableau de résultats.

Mesurez votre propre nombre de tokens par seconde

L’endpoint generate d’Ollama renvoie des champs de durée dans son objet JSON final. Divisez le nombre de tokens générés par la durée de génération pour obtenir votre résultat, avec votre offre et votre prompt.

sudo apt install -y jq
curl -s http://localhost:11434/api/generate -d '{
  "model": "glm-4.7-flash:q4_K_M",
  "prompt": "Write a 200 word explanation of how TCP congestion control works.",
  "stream": false,
  "options": {"num_ctx": 8192}
}' | jq '{
  tokens: .eval_count,
  tokens_per_second: (.eval_count / .eval_duration * 1e9),
  prompt_seconds: (.prompt_eval_duration / 1e9),
  load_seconds: (.load_duration / 1e9)
}'

eval_count correspond au nombre de tokens générés et eval_duration au nombre de nanosecondes consacrées à leur génération. eval_count / eval_duration * 1e9 correspond donc au nombre de tokens par seconde. prompt_eval_duration couvre la lecture de votre prompt, c’est-à-dire le délai perçu avant l’apparition du premier token. load_duration correspond au temps nécessaire au chargement du modèle depuis le disque. Cette valeur est donc élevée lors du premier appel après un redémarrage et presque nulle lors du suivant.

Exécutez la commande trois fois et conservez les deuxième et troisième résultats, car le premier inclut le chargement du modèle. Recommencez ensuite avec un prompt beaucoup plus long, car le traitement du prompt dépend de la longueur de l’entrée, contrairement à la vitesse de génération. Notez les valeurs à côté du nom de votre offre et de votre quantification. Cette mesure est plus utile que n’importe quel benchmark que vous pourriez consulter, car elle a été effectuée sur le matériel que vous payez.

Comment la longueur du contexte multiplie la mémoire

Ollama utilise par défaut un contexte de 4096 tokens. Le modèle annonce une capacité bien supérieure, 198K tokens pour glm-4.7-flash, mais cette capacité n’est pas utilisée par défaut et son activation a un coût.

Le cache KV contient un vecteur de clés et un vecteur de valeurs pour chaque token, dans chaque couche. Sa taille augmente linéairement avec le nombre de tokens autorisés. Passer de 4096 à 32768 tokens multiplie le contexte par huit, et donc le cache KV approximativement par huit. Sur une machine dimensionnée au plus juste pour contenir les poids, cette allocation supplémentaire suffit à déclencher le swap. C’est pourquoi une machine qui répondait correctement aux requêtes courtes devient soudain très lente lorsqu’un utilisateur colle un long document.

Définissez cette valeur pour chaque requête avec num_ctx dans l’objet d’options, comme dans la commande curl précédente, ou modifiez la valeur par défaut du serveur.

sudo install -d -m 755 /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_CONTEXT_LENGTH=16384"\n' \
  | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

La dernière commande doit afficher votre valeur OLLAMA_CONTEXT_LENGTH. Si elle affiche un Environment= vide, le fichier de surcharge se trouve dans le mauvais répertoire ou le rechargement a été ignoré. Après le prochain chargement du modèle, ollama ps doit afficher une valeur SIZE nettement supérieure à celle observée avec 4096. Augmentez la valeur par étapes et surveillez ce nombre à chaque fois. Définir la longueur du contexte d’Ollama avec num_ctx explique aussi l’interaction avec keep-alive et les requêtes parallèles, qui multiplient toutes deux le même coût.

Quand l’API coûte moins cher que le serveur

L’auto-hébergement n’est pas automatiquement moins cher. Pour cette famille de modèles, les prix catalogue publiés le montrent particulièrement clairement.

[
  {
    "label": "GLM-5.2 input",
    "usd_per_million_tokens": 1.4
  },
  {
    "label": "GLM-5.2 output",
    "usd_per_million_tokens": 4.4
  },
  {
    "label": "GLM-4.7-Flash input",
    "usd_per_million_tokens": 0
  },
  {
    "label": "GLM-4.7-Flash output",
    "usd_per_million_tokens": 0
  }
]

Au 18 août 2026, Z.ai affiche GLM-5.2 à $1.4 par million de tokens d’entrée et à $4.4 par million de tokens de sortie. GLM-4.7-Flash, le modèle exécuté localement dans ce guide, est affiché à $0 dans les deux sens. Ces prix sont publics et peuvent évoluer. Consultez donc la page actuelle avant de prévoir un budget sur cette base.

L’argument financier en faveur de l’auto-hébergement glm-4.7-flash est donc faible pour le moment. Un VPS disposant de suffisamment de RAM coûte réellement de l’argent chaque mois, tandis que l’éditeur fournit le même modèle gratuitement. En l’exécutant vous-même, vous achetez autre chose : vos prompts restent sur une machine que vous contrôlez, et la version du modèle ne change jamais, sauf si vous la changez vous-même. Ce sont de bonnes raisons de choisir l’auto-hébergement. Pour ce modèle et à ces prix, le coût n’en est pas une.

Le calcul change lorsque le modèle souhaité n’est pas gratuit ou lorsque vos données ne peuvent légalement pas sortir de votre propre réseau. Le seuil de rentabilité entre un VPS GPU et des tokens d’API détaille ce calcul en nommant chaque variable. Si vous choisissez encore la machine, ce qu’un VPS coûte réellement par mois représente l’autre partie de la somme.

Conserver le endpoint sur localhost

C’est l’étape que l’on oublie le plus souvent, alors que c’est la plus importante.

Ollama se lie par défaut à 127.0.0.1 sur le port 11434. Il est donc accessible uniquement depuis le serveur lui-même. Vérifiez ce point sur votre serveur au lieu de le supposer.

ss -ltnp | grep 11434

Vous devez voir 127.0.0.1:11434. Si vous voyez 0.0.0.0:11434 ou *:11434, l’API écoute sur toutes les interfaces, y compris l’interface publique.

C’est important, car l’API d’Ollama n’utilise aucune authentification. Il n’y a ni mot de passe, ni token, ni allowlist. Toute personne pouvant atteindre le port 11434 peut lister vos modèles, lancer des générations sur le matériel que vous payez, télécharger de nouveaux modèles jusqu’à remplir votre disque et supprimer ceux que vous avez déjà. Le port 11434 est fixe et bien connu. Les scanners repèrent donc rapidement les ports ouverts.

Ne définissez pas OLLAMA_HOST=0.0.0.0. De nombreux tutoriels le recommandent lorsque le client de votre laptop ne peut pas se connecter. C’est la mauvaise solution. Utilisez plutôt une redirection de port.

ssh -N -L 11434:127.0.0.1:11434 you@your-server

Cette commande redirige le port 11434 de votre laptop vers l’adresse loopback du serveur via SSH. Tout client configuré pour http://localhost:11434 fonctionne donc sans modification et aucune nouvelle interface n’est exposée. Pour plusieurs personnes ou plusieurs machines, placez le serveur sur un réseau de tunnel privé et liez Ollama à l’adresse du tunnel, jamais à 0.0.0.0.

Vérifiez le résultat depuis un autre système que le serveur. Depuis votre laptop, avec le tunnel SSH fermé :

curl -m 5 http://your-server-ip:11434/api/tags

curl: (28) Connection timed out ou curl: (7) Failed to connect est le résultat attendu. Si vous obtenez une liste JSON de vos modèles, le port est ouvert sur Internet et vous devez corriger le problème immédiatement. Le firewall réseau de votre fournisseur est un contrôle distinct de celui qui s’exécute sur le serveur. Vérifiez donc les deux. La question plus générale de la sécurité de l’hébergement VPS couvre le reste des mesures de base pour une machine que vous laissez en fonctionnement.

Si glm-4.7-flash reste trop volumineux

Lorsque le tag Q4 ne tient pas dans votre offre, la solution consiste à utiliser un modèle plus petit, pas à réduire le contexte. Réduire le contexte pour faire tenir le modèle donne un modèle qui se charge, puis échoue dès la première invite longue. Qwen 3 en 8B et 27B sur un VPS suit la même procédure d’installation avec des tailles adaptées aux serveurs modestes, et le guide général pour auto-héberger un LLM avec Ollama sur un VPS couvre les éléments qui restent identiques, quel que soit le modèle choisi. Quel que soit votre choix, verrouillez le tag, mesurez les performances sur votre propre offre et laissez l’endpoint lié à la loopback.

FAQ

GLM 5.2 peut-il fonctionner localement sur un VPS ?

Non. Au 18 août 2026, GLM 5.2 existe dans la bibliothèque Ollama uniquement sous la forme de glm-5.2:cloud, un tag qui s’exécute sur l’infrastructure d’Ollama et nécessite ollama signin avant de fonctionner. Le modèle compte 756 milliards de paramètres. Même avec 4 bits par paramètre, les poids seuls occupent des centaines de gigaoctets, soit bien plus que ce que propose un forfait VPS standard. Le modèle GLM dont les poids sont téléchargeables et qui tient sur un serveur loué est glm-4.7-flash.

De combien de RAM glm-4.7-flash a-t-il besoin ?

Considérez la taille du téléchargement du tag comme un minimum, puis ajoutez l’espace nécessaire au KV cache et au système d’exploitation. Ollama indique 19 Go pour le tag Q4, 32 Go pour le tag Q8 et 60 Go pour le tag bfloat16. Aucun multiplicateur fixe ne convient à tous les cas, car la taille du KV cache augmente avec la longueur de contexte configurée. Chargez le modèle, exécutez ollama ps, puis consultez la colonne SIZE pour connaître la valeur réelle sur votre machine.

Comment mesurer le nombre de tokens par seconde sur mon propre VPS ?

Envoyez une requête à http://localhost:11434/api/generate avec "stream": false, puis lisez eval_count et eval_duration dans la réponse. Le nombre de tokens par seconde est eval_count / eval_duration * 1e9, car eval_duration est indiqué en nanosecondes. Ignorez la première exécution, car load_duration inclut alors la lecture des poids depuis le disque. Recommencez également avec un prompt long, car prompt_eval_duration augmente avec la longueur de l’entrée, contrairement à la vitesse de génération.

Pourquoi ne faut-il pas définir OLLAMA_HOST sur 0.0.0.0 ?

Parce que l’API Ollama ne propose aucune authentification. La liaison sur 0.0.0.0 expose donc un endpoint sans authentification sur Internet. Toute personne pouvant atteindre le port 11434 peut générer du contenu sur votre matériel et modifier la liste des modèles installés. Conservez la liaison par défaut sur 127.0.0.1, vérifiez-la avec ss -ltnp | grep 11434, puis accédez à l’API depuis votre ordinateur portable via un tunnel SSH tel que ssh -N -L 11434:127.0.0.1:11434 you@your-server.