Quel VPS pour exécuter Muse Glimmer 30B ?

Ce dont Muse Glimmer a besoin sur un VPS

Muse Glimmer fonctionne sur un VPS Linux standard, sans GPU. Le tag que vous téléchargez détermine s’il tient en mémoire. Meta Superintelligence Labs a publié le modèle le 10 August 2026 sous licence Apache 2.0 : 30 billion parameters, une fenêtre de contexte de 128K et un encodeur de perception dédié de 1.8B parameter, qui lui permet de lire des images en plus du texte. Meta le destine à des agents locaux toujours actifs plutôt qu’au chat, avec un niveau de raisonnement défini pour chaque requête.

Les tags Ollama publiés, consultés le 16 August 2026, vont de 17 GB à 59 GB. Cette plage constitue tout le problème de dimensionnement. Le tag par défaut est indiqué à environ 18 GB. Le plus petit serveur raisonnable doit donc disposer de nettement plus de 18 GB de RAM libre. L’espace disque nécessaire au téléchargement et la mémoire requise par la fenêtre de contexte s’ajoutent à cela.

Quelle balise muse-glimmer devez-vous télécharger ?

[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama répertorie 11 balises pour ce modèle qui ne sont pas des builds Apple. Elles contiennent les mêmes 30 milliards de poids, stockés avec différentes précisions numériques. La taille affichée correspond à ce que vous téléchargez. Elle correspond aussi approximativement à la mémoire nécessaire avant l’ajout du contexte.

Les deux builds 4 bits sont les plus petits : 30b-nvfp4 à 17 GB et 30b-q4_K_M à 18 GB. La balise par défaut 30b est affichée avec la même taille que le build q4_K_M. Les builds 8 bits, 30b-q8_0 et 30b-mxfp8, approchent 31 GB. 30b-bf16 est la release 16 bits non quantifiée, à 57 GB. Cela représente davantage de RAM que n’en proposent la plupart des serveurs loués à un prix raisonnable pour un projet secondaire.

Les balises -dflash correspondent aux mêmes builds avec la prise en charge de DFlash. Chacune est affichée avec une taille supérieure à celle de son équivalent standard. Ollama présente DFlash comme une fonctionnalité d’accélération et la montre sur Apple Silicon et sur des GPU desktop. Sur un VPS limité au CPU, vous paieriez cette taille supplémentaire en mémoire réelle pour une fonctionnalité mesurée sur un autre matériel. Commencez donc avec la balise standard et ne modifiez qu’un seul paramètre à la fois.

Commencez par le 4 bits, sauf raison précise de faire autrement. Passer de 4 bits à 8 bits double approximativement le nombre d’octets que le CPU doit lire pour chaque token généré. Le débit diminue donc, tandis que l’utilisation mémoire augmente. Ce compromis est expliqué dans ce que les quantifications q4, q8 et fp16 vous coûtent réellement. Sur un serveur CPU, la réponse courte est que le build 4 bits est le seul point de départ pertinent.

Pourquoi les tags MLX ne servent à rien sur un serveur Linux

MLX est le framework de tableaux d’Apple, et le moteur MLX d’Ollama est son backend pour Apple Silicon. Tout tag dont le nom contient mlx est conçu pour ce moteur et ce matériel. Sur un VPS Linux x86, il s’agit de dizaines de gigaoctets de téléchargement que vous ne pouvez pas exécuter. Ces fichiers resteront sur votre disque sans être utilisés. Les chiffres de vitesse de l’annonce, mesurés sur un Mac, concernent ces tags. Ils ne décrivent donc pas les performances de votre serveur. Lorsque vous consultez la liste des tags sur la page du modèle, excluez d’abord tous les noms mlx. Dimensionnez ensuite le serveur à partir des tags restants.

De quelle quantité de RAM et d’espace disque a-t-il réellement besoin ?

Deux éléments consomment de la mémoire, et un seul dépend de la taille du tag. Les poids sont déterminés par le tag que vous téléchargez. Le cache KV, c’est-à-dire l’état que le modèle conserve pour la conversation à chaque token, augmente avec la longueur du contexte que vous configurez. La documentation d’Ollama précise que le traitement de requêtes en parallèle multiplie le contexte par le nombre de requêtes en cours. Une machine qui répond simultanément à deux agents a donc besoin de plus de mémoire que la même machine lorsqu’elle n’en traite qu’une.

Ne vous fiez pas à une valeur de RAM indiquée dans un guide, y compris celui-ci. Téléchargez le tag, envoyez-lui un prompt, puis exécutez ces deux commandes pendant que le modèle est toujours chargé en mémoire.

ollama ps
free -h

ollama ps indique ce qui est actuellement chargé et la répartition du traitement entre le CPU et le GPU. free -h indique la mémoire restante. Ces deux sorties obtenues sur votre propre machine sont plus fiables que n’importe quel tableau publié, car elles tiennent déjà compte de votre configuration du contexte, de votre quantification et du reste des services exécutés sur le serveur.

La question du disque est plus simple. Sous Linux, Ollama stocke les modèles dans /usr/share/ollama/.ollama/models, qui se trouve sur le système de fichiers racine dans la plupart des images VPS. Un volume racine de 40GB ne contiendra pas le build bf16 de 57 GB. Il ne contiendra pas non plus deux tags 8-bit côte à côte. Déplacez le store vers un volume monté avant de télécharger quoi que ce soit.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/mnt/models"

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

L’utilisateur ollama doit être propriétaire de ce répertoire, car le service s’exécute sous ollama et y écrit lui-même ses blobs. Si un téléchargement échoue à cause des permissions, journalctl -u ollama -n 50 indique la raison.

Pour le swap, retenez ceci : le swap ne permet pas d’exécuter un tag plus volumineux. La génération accède aux poids pour chaque token produit. Les poids stockés dans le swap sont donc relus sur le disque encore et encore, vmstat 1 affiche des colonnes si et so très sollicitées, et la génération ralentit jusqu’à plusieurs secondes par token. Conservez un petit fichier swap pour limiter le risque d’intervention de l’out of memory killer. Dimensionnez la RAM selon le tag que vous souhaitez réellement utiliser.

Installer Ollama et figer un tag nommé

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

Le script d’installation configure un service systemd. Le serveur redémarre donc automatiquement après un reboot. Si vous préférez ne pas l’exécuter comme un service système géré par root, exécuter Ollama sans privilèges root avec Podman couvre cette méthode. Téléchargez ensuite un tag explicite.

ollama pull muse-glimmer:30b
ollama list

Lisez vous-même la colonne de taille dans ollama list et comparez-la à la liste actuelle des tags sur la page du modèle. Les tags publiés sont ajoutés, renommés et supprimés. La taille indiquée dans un guide correspond à un instant donné.

N’écrivez jamais ollama pull muse-glimmer sur un serveur dont vous dépendez. Un nom de modèle seul se résout vers le tag latest, et latest est un pointeur que l’éditeur peut déplacer vers un autre build. Un pull courant remplace alors le modèle utilisé par votre agent, avec des besoins en mémoire et un comportement différents, sans qu’aucun message ne l’indique dans vos journaux. Écrivez le tag dans vos scripts, vos fichiers d’unité et la configuration de votre agent. Auto-héberger un LLM avec Ollama sur un VPS couvre le reste de la configuration du serveur.

Pouvez-vous exécuter Muse Glimmer sans GPU ?

Oui, mais il faut être clair sur ses limites. Générer un token consiste à lire les poids du modèle depuis la mémoire. La vitesse dépend donc de la bande passante mémoire, et non du nombre de vCPU annoncé par l’offre. Au-delà de quelques cœurs, ajouter des cœurs apporte très peu. Sur un VPS partagé, cette bande passante est partagée avec tous les autres tenants de l’hôte. Un modèle 30B en 4-bit ne produit donc que quelques tokens par seconde.

Ne prenez le chiffre de personne pour argent comptant, pas même le mien. Mesurez le nombre de tokens par seconde sur votre propre serveur et décidez en fonction du résultat.

Le modèle devient réellement différent selon l’usage. Le chat interactif est pénible, car vous lisez plus vite que le serveur n’écrit et chaque réponse commence par une longue pause. Les tâches d’agent exécutées en arrière-plan conviennent bien, car une tâche qui s’exécute sans surveillance pendant dix minutes n’est pas gênée par sa lenteur. C’est précisément l’usage que Meta décrit pour ce modèle.

Si vous avez besoin d’une vitesse interactive, les deux réponses honnêtes sont un GPU ou une API hébergée. Calculez le seuil de rentabilité entre un GPU VPS et des tokens d’API avant de louer quoi que ce soit, et ce qu’un GPU VPS vous apporte réellement décrit ce que vous achetez. Pour déterminer quels modèles une machine donnée peut héberger, commencez par les modèles que vous pouvez auto-héberger, puis consultez exécuter un modèle Qwen de taille similaire sur un VPS, qui constitue la comparaison la plus proche dans cette catégorie de taille.

Pourquoi oublie-t-il des éléments bien avant 128K tokens ?

Parce que la fenêtre de contexte par défaut d’Ollama est de 4096 tokens, quelle que soit la capacité du modèle. Cette valeur par défaut figure dans la FAQ d’Ollama en août 2026. Le tag annonce 128K, mais le serveur transmet au modèle une fenêtre de 4096 tokens tant que vous ne demandez pas autre chose. Une longue transcription d’agent perd donc ses premiers échanges, et le modèle semble avoir des problèmes de mémoire.

Augmentez cette valeur côté serveur pour chaque requête :

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Dans une session interactive, /set parameter num_ctx 32768 modifie cette valeur pour la session en cours uniquement. Avec l’API, envoyez num_ctx dans les options de la requête.

Chaque token de contexte supplémentaire consomme de la mémoire en plus des poids du modèle. Si vous demandez les 128K complets sur une machine dimensionnée uniquement pour les poids, le chargement échouera ou basculera vers un mode plus lent. Augmentez la valeur par étapes et exécutez ollama ps après chaque étape. Fonctionnement de num_ctx et de la longueur du contexte dans Ollama détaille le calcul.

Niveau de raisonnement : low, medium, high et xhigh

Meta documente quatre niveaux de raisonnement pour Muse Glimmer, de low à xhigh, et recommande les deux niveaux supérieurs pour les tâches complexes de programmation et d’agent. Dans Ollama, ce réglage passe par le paramètre think. Utilisez --think= sur la ligne de commande ou envoyez think dans le corps de la requête API.

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

Dans une session interactive, /set think et /set nothink permettent de l’activer ou de le désactiver. La documentation d’Ollama indique que la plupart des modèles acceptent une valeur booléenne ou un niveau comme low, medium ou high, et que certains acceptent max pour le niveau maximal disponible. Les chaînes exactes acceptées par ce modèle sont indiquées sur sa page. Consultez-la au lieu de les deviner et testez d’abord une valeur manuellement avant de l’intégrer à un agent.

Sur une machine équipée uniquement d’un CPU, ce réglage a un effet important. Un niveau plus élevé génère davantage de tokens de raisonnement avant l’affichage du premier mot de la réponse, et chaque token de raisonnement consomme autant de temps d’horloge qu’un token de réponse. Laissez les tâches courantes sur le niveau low.

Garder le modèle chargé pour un agent toujours actif

Par défaut, Ollama décharge un modèle inactif après cinq minutes. Pour un agent qui s’exécute toutes les dix minutes, cela impose de recharger entièrement 18 Go depuis le disque à chaque exécution. Sur un VPS avec un stockage attaché au réseau, ce chargement n’est pas rapide. Gardez plutôt le modèle en mémoire.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Une valeur négative conserve le modèle en mémoire jusqu’à ce qu’un autre processus le décharge, et keep_alive dans une requête d’API remplace la valeur par défaut du serveur pour cet appel uniquement. Le coût est réel : la RAM reste occupée lorsqu’aucune tâche ne s’exécute. Ce réglage convient donc à une machine dédiée à l’agent. Garder un modèle Ollama chargé présente les différentes variantes.

Pointer un agent de développement vers Ollama

Ollama fournit une API compatible avec OpenAI à l’adresse http://127.0.0.1:11434/v1. La plupart des outils d’agents se connectent avec une URL de base et n’importe quelle clé API non vide. La page Muse Glimmer d’Ollama documente également un raccourci de lancement qui connecte un agent pris en charge à un modèle local en une seule commande. Vous devez aussi y fixer le tag.

ollama launch claude --model muse-glimmer:30b

Les agents envoient des prompts volumineux. Le contenu des fichiers, la sortie des outils et la transcription qui s’allonge arrivent tous sous forme de tokens d’entrée. Sur une machine équipée d’un CPU, le traitement du prompt est la partie la plus lente, avant même le début de la génération. Définissez le contexte à la taille minimale compatible avec la tâche. Connecter un agent de développement à Ollama couvre la configuration côté client, exécuter un agent de développement sur un VPS couvre la machine qui l’héberge et maîtriser les coûts d’un agent sur un VPS couvre ce qui se passe lorsqu’il fonctionne toute la journée.

L’entrée image fonctionne de la même manière. L’API Ollama accepte les images dans le champ images d’un message. Un client limité au texte n’en enverra donc jamais, quelle que soit la capacité de l’encodeur de perception.

N’ouvrez pas le port 11434

L’API Ollama ne fournit aucune authentification. Définir OLLAMA_HOST=0.0.0.0:11434 pour y accéder depuis votre ordinateur portable expose sur Internet un model runner sans authentification. Toute personne qui le découvre peut charger des modèles sur votre disque et lire tout ce que votre agent lui transmet. Laissez-le lié à localhost et utilisez plutôt un tunnel.

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

Sécuriser le endpoint de l’API Ollama présente les options appropriées, notamment un reverse proxy qui demande des identifiants.

Ce qui peut échouer et ce que vous verrez

Le téléchargement s’arrête en cours de route. Le disque est plein. Exécutez df -h dans le répertoire du modèle. Un build bf16 de 57 GB ne tient pas sur un volume root de 40GB. Deux tags 8-bit côte à côte ne tiennent pas non plus.

Le modèle se charge, puis le processus s’arrête. La mémoire est insuffisante. dmesg -T indique que l’out-of-memory killer du kernel a sélectionné un processus, et journalctl -u ollama -n 100 affiche le même événement du côté du service. La solution consiste à utiliser un tag plus petit ou un num_ctx plus petit. Ajouter du swap ne résout pas le problème.

Le modèle s’exécute à raison de plusieurs secondes par token. Exécutez vmstat 1 et surveillez les colonnes si et so. Une activité swap continue indique que les poids ne tiennent pas dans la RAM et que la machine les relit depuis le disque pendant l’exécution.

Un tag qui fonctionnait la semaine dernière a disparu. Les listes de tags changent. Consultez à nouveau la page du modèle, épinglez la version actuelle et notez le nom du tag à un endroit où vous pourrez le retrouver.

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

FAQ

De quelle quantité de RAM Muse Glimmer a-t-il besoin sur un VPS ?

Commencez par la taille du tag et ajoutez la fenêtre de contexte. Le tag par défaut est indiqué à environ 18 Go au 16 août 2026. Une machine de 16 Go ne peut donc pas le charger, tandis qu’une machine de 24 Go le charge avec peu de mémoire restante pour le contexte. Considérez cette valeur comme un point de départ, pas comme une réponse définitive. Téléchargez le tag, chargez-le une fois, puis exécutez ollama ps et free -h sur votre propre machine pour relever vos propres valeurs. Une fenêtre de contexte plus longue et les requêtes parallèles consomment également de la mémoire en plus des poids du modèle.

Puis-je exécuter Muse Glimmer sans GPU ?

Oui. Le modèle se charge et répond uniquement sur le CPU d’un VPS. La vitesse de génération dépend davantage de la bande passante mémoire que du nombre de cœurs. Sur un hébergement mutualisé, cette bande passante est partagée. Attendez-vous donc à un petit nombre de tokens par seconde en 4 bits. C’est utilisable pour un agent exécuté en arrière-plan sans intervention. Pour du chat interactif, les performances seront mauvaises. Exécutez ollama ps pendant une requête et consultez la colonne du processeur pour confirmer où le traitement s’exécute.

Les tags MLX sont-ils utiles sur un VPS Linux ?

Non. Tous les tags dont le nom contient mlx sont conçus pour le moteur MLX d’Ollama, qui constitue son backend pour Apple Silicon. Sur un serveur Linux x86, ces tags représentent un téléchargement volumineux que vous ne pouvez pas exécuter. Utilisez le tag 30b sans suffixe, ou un autre tag qui n’est pas MLX. Ignorez les benchmarks réalisés sur le matériel Apple avec les versions MLX.

Pourquoi le modèle oublie-t-il des informations bien avant 128K tokens ?

Parce que la fenêtre de contexte par défaut d’Ollama est de 4096 tokens, quelle que soit la fenêtre prise en charge par le modèle. Le serveur tronque donc les conversations longues avant même que le modèle ne les reçoive. Définissez OLLAMA_CONTEXT_LENGTH sur le serveur, ou /set parameter num_ctx pour une session, ou envoyez num_ctx dans les options de la requête API. La consommation mémoire augmente avec cette valeur. Augmentez-la donc par étapes et vérifiez ollama ps à chaque fois.

Dois-je épingler le tag ou utiliser simplement latest ?

Épinglez-le. muse-glimmer sans tag se résout vers latest. Il s’agit d’un pointeur que l’éditeur peut faire correspondre à une autre build à tout moment. Un pull habituel peut donc modifier le modèle exécuté par votre agent. Écrivez muse-glimmer:30b dans les scripts, les unit files et la configuration de l’agent. Consultez la liste des tags sur la page du modèle avant de l’épingler, car les tags publiés peuvent changer.