Exécuter GLM sur un VPS avec Ollama : quel modèle ?

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

Non, et il est utile de connaître la raison avant de louer quoi que ce soit. Au 18 août 2026, GLM 5.2 dans la bibliothèque Ollama porte 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 Go. Il s’agit d’un calcul brut, avant de tenir compte du contexte, des activations ou 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. Ses poids téléchargeables sont publiés 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 que vous pouvez réellement mettre en pratique. Épinglez un tag, dimensionnez le serveur, mesurez votre propre débit et gardez l’endpoint privé.

Vérifiez le tag avant de copier une commande, y compris celles de ce guide. 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 est disponible avec des poids locaux, préférez-la et notez le tag que vous avez réellement testé.

Si vous voulez malgré tout utiliser GLM 5.2 lui-même, ollama run glm-5.2:cloud fonctionne après ollama signin et se comporte, côté client, comme n’importe quel autre modèle Ollama. 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 à cette exigence.

Quels tags GLM existent et lequel épingler

Trois entrées GLM officielles sont pertinentes ici. glm-5.2 et glm-5.1 sont uniquement disponibles 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 ceux publiés sur la page de la bibliothèque, et non des mesures. latest et q4_K_M sont tous les deux indiqués à 19 GB. latest pointe donc actuellement vers le build Q4. Cela peut changer lors de toute 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 a publié l’élément. 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 télécharger 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 sous l’utilisateur ollama. Vérifiez qu’il a démarré avant de télécharger quoi que ce soit.

systemctl status ollama --no-pager

Active: active (running) signifie que l’API écoute sur le port 11434. Si l’unité n’existe pas, l’installateur s’est rabattu sur une installation du binaire seul. 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 n’exécute pas le modèle plus lentement : il le refuse. Le téléchargement échoue alors avec un message indiquant que le modèle nécessite une version plus récente d’Ollama. Relancez le script d’installation pour effectuer la mise à niveau. Au 18 août 2026, la version actuelle est 0.32.14, bien supérieure à cette version minimale.

Téléchargez 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 indiqués. Un téléchargement interrompu ne laisse aucun modèle exécutable. Relancez donc la même commande. Sur une petite offre, un téléchargement échoue le plus souvent parce que le disque est plein, et non à cause du 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 combien de RAM chaque quantification a-t-elle besoin ?

Commencez par la taille du téléchargement, qui constitue le minimum, 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 compter les buffers de calcul et la mémoire utilisée par le système d’exploitation. Une machine avec exactement 19 Go de RAM ne pourra pas exécuter le tag de 19 Go.

Il n’existe pas de multiplicateur unique valable pour tout le monde. Le cache KV augmente avec la longueur de contexte autorisée, et le reste varie selon les versions du runtime. Mesurez donc au lieu d’estimer. Chargez le modèle avec un prompt minimal, puis consultez la 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 mémoire effectivement réservée par le runtime. C’est ce nombre qu’il faut comparer à votre plan. PROCESSOR indique où le traitement est effectué. 100% CPU signifie qu’aucun GPU n’a été utilisé.

Lorsque le modèle ne tient pas en mémoire, l’échec est silencieux et prend 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, car aucun des deux ne fournit 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 ce chiffre. Q4 réduit quelque peu la qualité des sorties. L’impact dépend de la tâche. Les sorties structurées et les longues chaînes de raisonnement sont davantage affectées qu’une conversation ordinaire. Différences pratiques entre Q4, Q8 et FP16 mérite d’être consulté avant de vous décider, car sur un VPS limité au CPU, le choix de la quantification détermine généralement si le modèle peut s’exécuter 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 en 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. Seuls environ 3 milliards des 30 milliards de paramètres sont utilisés pour chaque token. Les calculs nécessaires pour chaque token sont donc bien moins importants que ceux d’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 d’entre eux pour le token suivant. Un serveur sans GPU a donc toujours besoin de la totalité des 19 Go ou davantage 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 ayant le même nombre de cœurs et la même quantité de RAM peuvent générer du texte à des vitesses sensiblement différentes, car leurs sous-systèmes mémoire ne sont pas identiques. Une offre mutualisée ajoute une seconde variable : le temps CPU volé par un voisin bruyant se traduit par un nombre de tokens par seconde qui varie d’une heure à l’autre. C’est pourquoi aucun chiffre publié par un autre utilisateur ne permet de prédire le vôtre, 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

Le point d’accès 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 invite.

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 à la durée, en nanosecondes, nécessaire pour les générer. eval_count / eval_duration * 1e9 correspond donc au nombre de tokens par seconde. prompt_eval_duration couvre la lecture de votre invite, c’est-à-dire le délai que vous percevez avant l’apparition du premier token. load_duration correspond au temps nécessaire pour charger le 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 ce chargement. Exécutez-la ensuite avec une invite beaucoup plus longue, car le traitement de l’invite évolue avec la longueur de l’entrée, tandis que la vitesse de génération ne change pas. 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é réalisé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 en annonce bien davantage, 198K tokens pour glm-4.7-flash, mais cette capacité n’est pas active par défaut et son activation a un coût.

Le cache KV contient un vecteur de clé et un vecteur de valeur 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 environ par huit. Sur une machine dimensionnée pour contenir tout juste les poids, cette allocation supplémentaire suffit à provoquer l’utilisation du swap. C’est pourquoi une machine qui répondait correctement aux requêtes courtes peut soudainement devenir très lente lorsqu’un utilisateur colle un long document.

Définissez cette valeur pour chaque requête avec num_ctx dans l’objet options, comme dans la commande curl ci-dessus, 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 n’a pas été effectué. Après le prochain chargement du modèle, ollama ps doit afficher un SIZE nettement supérieur à celui obtenu 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 les interactions avec keep-alive et les requêtes parallèles, qui multiplient toutes deux le même coût. Si plusieurs clients utilisent le serveur, définissez les limites de concurrence en même temps que le contexte, car chaque emplacement parallèle possède son propre cache KV et le paramètre de file d’attente détermine si une deuxième requête attend ou est refusée immédiatement.

Quand l’API coûte moins cher que la machine

L’auto-hébergement n’est pas automatiquement moins cher, et les prix catalogue publiés pour cette famille de modèles 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. Le site affiche GLM-4.7-Flash, le modèle exécuté localement dans ce guide, à $0 dans les deux sens. Ces prix sont publiés et peuvent changer. Consultez donc la page actuelle avant d’établir un budget sur cette base.

L’argument financier en faveur de l’auto-hébergement glm-4.7-flash est donc faible actuellement. Un VPS disposant de suffisamment de RAM coûte réellement de l’argent chaque mois, tandis que l’éditeur propose gratuitement le même modèle. En l’exécutant vous-même, vous obtenez 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 modifiez. Ce sont de bonnes raisons de pratiquer 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 quitter votre propre réseau. Le seuil de rentabilité entre un VPS GPU et les tokens d’API détaille ce calcul en nommant chaque variable. Si vous choisissez encore la machine, ce que coûte réellement un VPS par mois correspond à l’autre moitié de la somme.

Conserver le point de terminaison sur localhost

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

Par défaut, Ollama se lie à 127.0.0.1 sur le port 11434. Il n’est donc accessible que 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 liste d’autorisation. 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 ordinateur portable ne peut pas se connecter. C’est une mauvaise solution. Transférez plutôt le port.

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

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

Vérifiez le résultat depuis une autre machine que le serveur. Depuis votre ordinateur portable, 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 la liste JSON de vos modèles, le port est ouvert sur Internet et vous devez corriger le problème immédiatement. Le pare-feu réseau de votre fournisseur est distinct de celui exécuté sur le serveur. Vérifiez donc les deux. La question plus générale de la sécurité d’un hébergement VPS couvre les autres mesures de base pour une machine que vous laissez fonctionner en permanence.

Si glm-4.7-flash reste trop volumineux

Lorsque le tag Q4 ne tient pas dans votre offre, il faut choisir 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, tandis que 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, figez le tag, mesurez les performances sur votre propre offre et laissez le endpoint en écoute sur 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 d’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 occupent à eux seuls plusieurs centaines de gigaoctets, bien au-delà de ce qu’offre 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 de la marge pour le cache KV et le système d’exploitation. Ollama indique 19 Go pour le tag Q4, 32 Go pour Q8 et 60 Go pour le tag bfloat16. Aucun coefficient fixe ne convient à tout le monde, car la taille du cache KV 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 serveur.

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 correspond à eval_count / eval_duration * 1e9, car eval_duration est exprimé en nanosecondes. Ignorez la première exécution, car load_duration inclut alors la lecture des poids depuis le disque. Répétez également le test 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 ?

L’API d’Ollama n’utilise aucune authentification. La lier à 0.0.0.0 expose donc un endpoint non authentifié sur Internet. Toute personne pouvant atteindre le port 11434 peut générer du contenu sur votre matériel et modifier les 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.