llmfit : savoir quel modèle LLM tourne vraiment sur votre VPS ou serveur dédié avant de télécharger 40 Go

llmfit : confronter votre serveur à des centaines de LLM avant le premier téléchargement

llmfit est un outil open source en ligne de commande, écrit en Rust et distribué sous licence MIT, qui répond à une seule question : quels modèles de langage (LLM) à poids ouverts tournent réellement sur cette machine, avec quelle quantification et à quelle vitesse. Le projet a été créé en février 2026 sur GitHub (dépôt AlexsJones/llmfit) et compte près de 39 000 étoiles le 11 novembre 2026. La version courante, la 1.1.20, est publiée depuis le 3 novembre 2026 sur GitHub et sur crates.io, le registre des paquets Rust.

Le principe tient en deux étapes. llmfit détecte d'abord le matériel : nombre de coeurs du processeur, RAM totale et RAM disponible, GPU NVIDIA (via nvidia-smi), AMD (via rocm-smi), Intel Arc, Apple Silicon ou Ascend, avec leur VRAM. Il confronte ensuite ces ressources à sa base de modèles, qui couvre notamment les familles Llama 3.x, Qwen3, Mistral, Mixtral, Gemma 3, Phi et DeepSeek, et attribue à chaque modèle quatre notes de 0 à 100 : qualité, vitesse, ajustement à la mémoire (le « fit ») et contexte. Pour chacun, il indique la meilleure quantification GGUF qui tient en mémoire, le mode d'exécution (GPU, CPU+GPU, CPU seul, MoE), la mémoire requise et un débit estimé en tokens par seconde.

Ce tutoriel s'adresse aux administrateurs de VPS Linux et de serveurs dédiés qui veulent héberger un LLM local avec Ollama ou llama.cpp, chez eux ou chez un hébergeur, pour un bot Discord, un assistant interne ou la modération d'un serveur de jeu. Au programme : installer llmfit sur Debian ou Ubuntu (binaire précompilé ou cargo, avec un mot sur Windows, macOS et le paquet Python), lire llmfit fit et llmfit recommend --json sur un VPS 8 Go sans GPU puis sur un serveur dédié Xeon, et enchaîner sur le téléchargement du modèle retenu, sans tirer 40 Go qui finiront tués par l'OOM killer.

L'erreur classique : télécharger 43 Go avant de vérifier la RAM

Le scénario revient sans cesse sur les serveurs auto-hébergés. On lit qu'un modèle de 70 milliards de paramètres rivalise avec les API commerciales, on lance ollama pull llama3.3, et le VPS télécharge 43 Go : c'est la taille du tag par défaut de Llama 3.3 70B dans la bibliothèque Ollama, quantifié en Q4_K_M. La version Q8_0 pèse 75 Go, la version FP16 141 Go. ollama pull ne se préoccupe pas de la mémoire : le téléchargement va au bout, remplit parfois le disque, et le problème n'apparaît qu'au chargement du modèle.

À ce moment, deux issues sont possibles. Dans le meilleur cas, Ollama compare son estimation à la mémoire disponible et refuse de charger, avec un message du type model requires more system memory (39.4 GiB) than is available (30.0 GiB) (exemple tiré du ticket GitHub ollama/ollama n° 13556). Dans le pire, le modèle se charge de justesse, puis le cache KV grossit avec la conversation, le serveur de jeu ou la base MySQL voisine réclame sa mémoire, et le noyau Linux déclenche l'OOM killer. Celui-ci tue le processus au score le plus élevé, en pratique le plus gros consommateur de RAM : votre moteur d'inférence, ou pire, le serveur de jeu (comprendre l'OOM killer sous Linux). Le swap ne sauve pas la situation : l'inférence relit l'ensemble des poids du modèle à chaque token généré, et des poids relus depuis le disque rendent la génération inutilisable. Le swap reste un filet de sécurité pour le système, pas un espace pour héberger un modèle (configurer le swap sur un VPS Linux).

llmfit fait ce calcul avant le téléchargement : poids du modèle à la quantification choisie, cache KV pour le contexte visé et 0,5 Go de surcoût d'exécution, rapportés à la mémoire réellement disponible. Quelques secondes de calcul, contre des dizaines de minutes de téléchargement et un service qui tombe en production.

Installer llmfit sur Debian ou Ubuntu : binaire précompilé ou cargo

Deux méthodes conviennent à un serveur Linux. Le binaire précompilé est la plus rapide. Le script d'installation officiel télécharge la dernière release GitHub, en version x86_64-unknown-linux-musl sur un serveur x86_64 : un binaire lié statiquement, qui ne dépend pas de la version de la glibc de votre distribution. Il exige curl et tar, vérifie la somme SHA-256 de l'archive quand le fichier .sha256 est publié, et installe dans /usr/local/bin, en passant par sudo si nécessaire, ou dans ~/.local/bin à défaut. Plutôt que de passer ce script shell directement à sh, téléchargez-le et lisez-le avant de l'exécuter :

sudo apt update
sudo apt install -y curl tar jq
curl -fsSL https://llmfit.axjns.dev/install.sh -o llmfit-install.sh
less llmfit-install.sh
sh llmfit-install.sh
llmfit system

L'option --local (sh llmfit-install.sh --local) force l'installation dans ~/.local/bin sans sudo, pratique sur un compte de service ; vérifiez alors que ce répertoire figure dans le PATH. Les droits root ne servent qu'à écrire dans /usr/local/bin : llmfit lit l'état de la machine et interroge les API locales d'Ollama ou de llama.cpp, lancez-le donc avec un compte utilisateur ordinaire. jq n'est pas requis par llmfit : il servira plus bas à exploiter la sortie JSON.

La seconde méthode passe par cargo, le gestionnaire de paquets de Rust. Le package (une « crate » dans le vocabulaire Rust) llmfit est publié sur crates.io et fournit le binaire du même nom. Il est écrit en édition Rust 2024, qui exige rustc 1.85 ou plus récent ; le compilateur fourni par les dépôts de votre distribution peut être plus ancien (Debian 12 livre rustc 1.63), d'où l'installation de la chaîne stable par rustup :

sudo apt install -y build-essential pkg-config libssl-dev curl
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
. "$HOME/.cargo/env"
cargo install llmfit
llmfit system

La compilation prend plusieurs minutes et occupe tous les vCPU ; le binaire atterrit dans ~/.cargo/bin. pkg-config et libssl-dev sont une précaution pour les dépendances qui compilent du code C. D'après la documentation du projet, llmfit ne contacte un service extérieur que lorsque vous déclenchez une fonction qui en a besoin : téléchargement de modèle, interrogation d'un fournisseur, classement communautaire. Il range ses fichiers dans deux répertoires de votre compte : ~/.config/llmfit/ (configuration, dont le jeton GitHub mis en cache si vous en utilisez un) et ~/.local/share/llmfit/ (profils matériel, mesures de llmfit bench en attente d'envoi).

Autres distributions, Windows, macOS, paquet Python et compilation depuis Git

Le binaire x86_64-unknown-linux-musl ne dépend d'aucune bibliothèque du système : il tourne tel quel sur toutes les distributions Linux, de Debian et Ubuntu à AlmaLinux, Rocky Linux ou Alpine (musl ou glibc, ce qui change). La release 1.1.20 du 3 novembre 2026 publie neuf archives au total : musl et glibc pour x86_64 et ARM64 (aarch64), glibc pour RISC-V, deux pour macOS et deux pour Windows, chacune accompagnée de sa somme SHA-256. Le script shell d'installation vise les systèmes de type Unix (Linux et macOS) ; Windows a ses propres canaux.

Sous Windows, sur un VPS Windows comme sur un poste, les commandes llmfit fit et llmfit recommend --json s'utilisent de la même façon dans PowerShell. Le système réserve plus de mémoire qu'un Linux minimal en ligne de commande : llmfit le prend en compte puisqu'il lit la RAM disponible. Le README référence aussi un projet satellite, llmfit-gui, qui ajoute une interface graphique de bureau (desktop) pour Windows, écrite en PowerShell et WinForms.

Le paquet Python. llmfit est aussi publié sur PyPI, l'index des paquets Python (Python 3.8 minimum). Sur Debian 12 et Ubuntu 24.04, pip install refuse d'écrire dans le Python du système (environnement « externally managed », PEP 668) : passez par uv, qui installe chaque outil dans son propre environnement virtuel. uvx llmfit lance l'outil sans l'installer, utile pour un essai ponctuel dans des environnements de test :

uv tool install -U llmfit
uvx llmfit system

Depuis les sources Git, avec la chaîne Rust installée plus haut, la commande suivante produit le binaire dans target/release/llmfit :

git clone https://github.com/AlexsJones/llmfit.git
cd llmfit
cargo build --release
./target/release/llmfit system

L'image Docker ghcr.io/alexsjones/llmfit complète la liste : docker run ghcr.io/alexsjones/llmfit affiche directement le JSON de llmfit recommend (installer Docker sur un VPS). Dans un conteneur limité en mémoire, comparez la RAM affichée par llmfit system à la limite du conteneur et, si elles diffèrent, fixez la bonne valeur avec --ram.

Ce que llmfit détecte sur un VPS KVM sans GPU

llmfit system affiche les caractéristiques détectées ; llmfit doctor produit un rapport plus détaillé, destiné aux signalements de bugs. Un VPS (Virtual Private Server, serveur privé virtuel) est une machine virtuelle : llmfit voit le matériel virtuel que l'hyperviseur lui présente, pas le serveur physique. C'est vrai sous KVM comme sous VMware ESXi ou toute autre plateforme de virtualisation ; un GPU n'apparaît dans une machine virtuelle que s'il lui est attribué en passthrough PCI (DirectPath I/O chez VMware), avec le pilote installé dans le système invité. Sur un VPS KVM, trois valeurs comptent :

• Les coeurs. llmfit compte les vCPU que l'hyperviseur expose. Un vCPU de VPS est un thread du processeur hôte, dont la fréquence et la charge des voisins fixent le débit réel (pourquoi tous les vCPU ne se valent pas).
• La RAM disponible, pas la RAM totale. Sur une machine sans GPU, le chemin d'exécution « CPU seul » compare les besoins du modèle à la mémoire disponible, lue par la bibliothèque sysinfo au moment du lancement. Lancez donc llmfit dans l'état où le serveur tournera en production : serveur de jeu, base MySQL ou PostgreSQL et panel démarrés. Un VPS 8 Go fraîchement installé affiche de l'ordre de 7 Go disponibles ; avec un serveur Minecraft ou FiveM lancé, il en reste beaucoup moins.
• L'absence de GPU. Sans nvidia-smi, rocm-smi ni carte Intel détectée, le backend retenu est « CPU x86 » (ou « CPU ARM » sur un serveur ARM) et tous les modèles passent en mode CPU : les poids sont chargés intégralement en RAM.

llmfit ne retranche aucune réserve pour le système : il prend la RAM disponible telle quelle. Trois options globales corrigent ou simulent la détection :

• --ram-percent=75 ne retient que 75 % de la capacité détectée, la RAM disponible étant plafonnée à cette valeur réduite. Sur un VPS 8 Go presque vide, cela réserve environ 2 Go au système ;
• --ram=16G remplace la RAM détectée et fixe la RAM disponible à 90 % de cette valeur. Utile dans un conteneur dont la limite mémoire diffère de celle de l'hôte, et pour simuler une offre avant de la commander : llmfit fit --ram=16G --cpu-cores=6 lancé sur votre VPS actuel montre ce que donnerait le palier au-dessus ;
• --cpu-cores remplace le nombre de coeurs détecté.

Comment llmfit note un modèle : quatre axes et quatre niveaux d'ajustement

Chaque modèle reçoit quatre notes de 0 à 100, combinées en un score composite dont les pondérations dépendent de l'usage visé (généraliste, code, raisonnement, chat, multimodal, embeddings) :

• Qualité : nombre de paramètres, réputation de la famille de modèles, pénalité liée à la quantification et adéquation à la tâche d'après une table de benchmarks par famille ;
• Vitesse : débit estimé en tokens par seconde, rapporté à une cible qui dépend de l'usage (40 tokens/s pour un usage généraliste, le code ou le chat, 25 pour le raisonnement) ;
• Ajustement : taux d'occupation de la mémoire. La note reste à 100 jusqu'à 70 % d'occupation, puis décroît ;
• Contexte : fenêtre de contexte du modèle rapportée à la cible de l'usage (4 096 tokens pour un usage généraliste ou le chat, 8 192 pour le code et le raisonnement).

Indépendamment du score, llmfit range chaque modèle dans un niveau d'ajustement calculé à partir du rapport entre mémoire requise et mémoire disponible :

Le point à retenir pour un VPS : en mode CPU seul, comme en mode CPU+GPU ou en déchargement d'experts MoE, llmfit plafonne le verdict à Good. Le filtre --perfect, pratique sur une machine équipée d'un GPU, ne renverra donc rien sur un VPS sans carte graphique. La quantification est choisie dans la même logique : llmfit descend la hiérarchie de Q8_0 vers Q2_K et retient la quantification de plus haute qualité dont l'occupation reste sous 98 % ; si rien ne tient au contexte complet, il réessaie avec un contexte divisé par deux. Les modèles Too Tight sont toujours classés en bas du tableau.

llmfit fit sur un VPS 8 Go sans GPU : lire le tableau

Prenons un VPS Linux Classic d'ElypseCloud : 4 vCPU Intel Xeon E5-2697 v4, 8 Go de RAM DDR4, 70 Go de SSD, sans GPU, à 9,99 €/mois. Le processeur gère AVX2, le jeu d'instructions vectorielles sur lequel s'appuie llama.cpp pour l'inférence CPU. Les commandes à lancer, de la plus simple à la plus prudente :

llmfit system
llmfit fit -n 15
llmfit fit --ram-percent=80 --max-context 4096 -n 15
llmfit fit --json -n 15 | jq .

-n 15 limite l'affichage aux quinze premiers modèles du classement. --max-context plafonne le contexte utilisé pour estimer le cache KV, sans changer le contexte maximal annoncé par chaque modèle : c'est le réglage qui fait le plus varier la mémoire requise. Le tableau classique compte treize colonnes :

Sur un VPS 8 Go sans GPU, la lecture est rapide : toutes les lignes affichent le mode CPU, aucune ne peut dépasser Good, les modèles de 1 à 4 milliards de paramètres tiennent avec de la marge, ceux de 7 à 8 milliards en Q4_K_M frôlent la limite (Good ou Marginal selon le modèle et le contexte), et au-delà de 10 milliards de paramètres rien ne tient en Q4_K_M : llmfit ne les classe en Good ou Marginal qu'avec une quantification plus agressive. Trois réflexes :

• Fiez-vous à Mem %, pas seulement au niveau. Un modèle à 84 % est classé Good, mais il laisse à peine plus d'un gigaoctet au reste du serveur ;
• Méfiez-vous des quantifications Q2_K et Q3_K. llmfit les propose quand rien de mieux ne tient. Un 14B en Q2_K perd beaucoup en qualité : un 4B en Q8_0 ou un 8B en Q4_K_M rend souvent de meilleurs services ;
• Relancez avec la charge réelle. Un VPS qui héberge aussi un serveur de jeu doit être mesuré serveur démarré, sinon llmfit compte une RAM qui ne sera pas libre en production (surveiller les ressources avec htop et btop).

Pour aller plus vite, l'interface interactive (lancez llmfit sans argument, elle fonctionne en SSH dans un terminal) filtre le tableau à la volée : f fait défiler les niveaux (tous, exécutables, Perfect, Good, Marginal), / recherche par nom, famille ou quantification, s change le tri (score, paramètres, Mem %, contexte, date), h affiche l'aide et q quitte.

Lancée ainsi, l'interface démarre aussi en arrière-plan un petit serveur web, le tableau de bord de llmfit, sur 127.0.0.1:8787, arrêté en même temps que la session. Il n'écoute que sur l'interface locale ; sur un serveur partagé entre plusieurs utilisateurs, l'option --no-dashboard permet de le désactiver. Les variables LLMFIT_DASHBOARD_HOST et LLMFIT_DASHBOARD_PORT le déplacent. Pour le consulter depuis votre poste, un tunnel SSH suffit : ssh -L 8787:127.0.0.1:8787 utilisateur@ip-du-vps, puis http://localhost:8787 dans le navigateur.

llmfit recommend --json : brancher le verdict sur vos scripts

llmfit recommend renvoie du JSON par défaut (l'option --json le rend explicite) : un objet system qui décrit la machine et un tableau models avec les meilleurs candidats, 5 par défaut (--limit). Deux options comptent sur un serveur : --use-case (par exemple coding pour un assistant de code) et --min-fit, qui vaut marginal par défaut. Sur une machine qui fait tourner autre chose qu'un LLM, passez-le à good pour écarter les modèles qui tiennent de justesse :

llmfit recommend --json --min-fit good --limit 5 > reco.json
jq '.system | {total_ram_gb, available_ram_gb, cpu_cores, has_gpu, backend}' reco.json
jq -r '.models[] | [.name, .best_quant, .fit_level, .run_mode, .memory_required_gb, .utilization_pct, .estimated_tps, .ollama_name] | @tsv' reco.json

Les champs les plus utiles de chaque entrée de models :

Ce JSON permet de verrouiller le téléchargement. Le script suivant n'autorise ollama pull que si llmfit classe le tag demandé en Good ou mieux ; un tag inconnu de llmfit est refusé par prudence :

#!/bin/sh
# pull-si-ca-tient.sh : ollama pull seulement si llmfit juge le modèle good ou mieux
set -eu
TAG="$1"
NIVEAU=$(llmfit fit --json | jq -r --arg t "$TAG" '[.models[] | select(.ollama_name == $t)][0].fit_level // "inconnu"')
case "$NIVEAU" in
  perfect|good) ollama pull "$TAG" ;;
  *) echo "llmfit : $TAG -> $NIVEAU, téléchargement annulé" >&2; exit 1 ;;
esac

Rendez-le exécutable (chmod +x pull-si-ca-tient.sh) et appelez-le avec le tag voulu, par exemple ./pull-si-ca-tient.sh qwen3:8b. Le même principe s'applique dans un playbook Ansible ou une tâche de CI qui provisionne des serveurs d'inférence, en test comme en production : chaque environnement reçoit le modèle que sa RAM supporte.

Sur un serveur dédié Xeon : de 32 à 256 Go de RAM

Les serveurs dédiés ElypseCloud existent en deux gammes, avec le même choix de 32, 64, 128 ou 256 Go de DDR4 ECC : Xeon E5 (2 x Intel Xeon E5-2620 v4, 16 coeurs et 32 threads, AVX2) et Xeon Gold (2 x Intel Xeon Gold 6230, 40 coeurs et 80 threads, AVX-512 et VNNI). Les mêmes commandes s'y lancent, complétées par la planification :

llmfit system
llmfit fit --max-context 8192 -n 20
llmfit recommend --use-case coding --min-fit good --limit 5
llmfit plan "Qwen/Qwen3-32B" --context 8192

llmfit plan prend le problème à l'envers : pour un modèle et un contexte donnés, il estime le matériel minimal et recommandé, et indique si l'exécution est faisable sur GPU, en déchargement CPU ou en CPU seul. C'est la commande à lancer avant de choisir entre 64 et 128 Go.

La différence de fond avec un VPS est le volume de RAM. À partir de 32 Go, les modèles de 30 à 32 milliards de paramètres en Q4_K_M entrent dans la zone Good ; à 64 Go, un 70B en Q4_K_M devient possible. Sur 128 Go, llmfit peut retenir la Q8_0 d'un 70B (75 Go), puisqu'il choisit la quantification de plus haute qualité qui tient. Ce n'est pas forcément le bon choix sur CPU : l'inférence y est limitée par la bande passante mémoire, et chaque token généré relit l'ensemble des poids actifs. Avec 75 Go relus à chaque token, comptez quelques tokens par seconde au mieux ; la Q4_K_M, presque deux fois plus légère, ira presque deux fois plus vite pour une perte de qualité généralement modeste. Regardez la colonne tok/s est. avant de suivre la colonne Quant.

Les modèles MoE (Mixture of Experts) changent l'équation sur CPU. Le tag qwen3:30b de la bibliothèque Ollama correspond à la variante 30B-A3B : 30 milliards de paramètres au total, environ 3 milliards activés par token. Il occupe 19 Go, presque autant que qwen3:32b (20 Go, modèle dense), mais ne lit qu'une fraction de ses poids à chaque token, ce qui le rend bien plus rapide sur le même processeur. llmfit le rappelle dans ses notes : sans GPU, le déchargement des experts est impossible (« expert offloading requires a GPU »), tout le modèle doit donc tenir en RAM.

Quel modèle pour quelle RAM : ordres de grandeur

Le tableau suivant part des tailles publiées dans la bibliothèque Ollama et applique la même logique que llmfit : poids du modèle, plus 0,5 Go de surcoût et le cache KV d'un contexte de 4 096 tokens, rapportés à la RAM moins environ 1 Go pour le système. « Tient » signifie une occupation sous 85 %, « limite » entre 85 et 98 %, « non » au-delà. Ce sont des ordres de grandeur : llmfit calcule avec la RAM réellement disponible et le cache KV propre à chaque architecture.

Sur le VPS 8 Go, qwen3:8b passe de « limite » à « non » dès qu'on ouvre le contexte à 8 192 tokens : avec ses 36 couches et 8 têtes clé-valeur, son cache KV en FP16 coûte environ 0,15 Mo par token, soit 0,6 Go de plus, et l'occupation approche ou dépasse les 98 % du Too Tight. C'est exactement le cas où un modèle se charge le premier jour puis tombe sous l'OOM killer quand les conversations s'allongent. Pour un modèle compact qui laisse de la marge, voir LFM3 avec Ollama sur un VPS Linux (1,1 Go en Q4_K_M) ; pour un modèle de 27 milliards de paramètres sur CPU, Qwen 3.8 27B avec Ollama sur un VPS sans GPU.

Télécharger le modèle retenu avec Ollama ou llama.cpp

Avec Ollama. Si Ollama tourne sur la machine (installer Ollama sur un VPS Linux), llmfit interroge son API sur http://localhost:11434 (GET /api/tags) et marque d'un ✓ les modèles déjà installés. Dans l'interface interactive, la touche d télécharge le modèle sélectionné en appelant /api/pull ; si plusieurs fournisseurs compatibles sont détectés, llmfit demande lequel utiliser. Pour une instance Ollama sur une autre machine, la variable OLLAMA_HOST pointe llmfit vers elle. En ligne de commande, le champ ollama_name de la sortie JSON donne le tag à passer à ollama pull.

Point d'attention : le contexte. llmfit estime le cache KV pour le contexte qu'on lui donne ; si --max-context n'est pas précisé, il lit la variable OLLAMA_CONTEXT_LENGTH quand elle est définie. Fixez la même valeur des deux côtés : la surcharge systemd complète est détaillée plus bas, dans la section consacrée à la configuration d'Ollama.

Gestion des tags, suppression des modèles inutiles et emplacement du stockage : gérer ses modèles Ollama. Pour une interface web de chat devant le modèle : installer Open WebUI avec Docker.

Avec llama.cpp. llmfit cherche les binaires llama-cli et llama-server (ou le binaire unique llama des versions récentes) dans le répertoire indiqué par LLAMA_CPP_PATH, puis dans le PATH, et sonde llama-server sur le port 8080 (variable LLAMA_SERVER_PORT pour un autre port). Il sait télécharger les fichiers GGUF depuis Hugging Face dans le cache de llama.cpp, et sa sortie JSON liste les dépôts GGUF connus (gguf_sources) ainsi que, pour les modèles compatibles, une commande prête à l'emploi (llamacpp_command). Côté llama.cpp, l'option -hf charge un dépôt Hugging Face au format utilisateur/modele[:quant], la quantification par défaut étant Q4_K_M :

jq -r '.models[] | .llamacpp_command // empty' reco.json
llama-server -hf utilisateur/modele-GGUF:Q4_K_M -c 4096 --host 127.0.0.1 --port 8080

Compilation avec AVX-512 sur Xeon Gold, choix du nombre de threads et service systemd : LLM sur CPU avec llama.cpp sur un serveur dédié Xeon Gold. Pour servir plusieurs utilisateurs en parallèle, la question du moteur se pose : vLLM ou Ollama, quel moteur d'inférence.

Configurer Ollama pour rester dans l'enveloppe calculée par llmfit

llmfit évalue un modèle à la fois, pour un contexte et une requête. La configuration par défaut d'Ollama, décrite dans sa FAQ officielle, peut sortir de cette enveloppe sans que llmfit le sache :

Sur Linux, ces variables se posent dans une surcharge du service systemd. La commande suivante ouvre l'éditeur ; ajoutez la section [Service], enregistrez, rechargez et redémarrez, puis relancez llmfit avec le même contexte avant de télécharger :

sudo systemctl edit ollama
# dans l'éditeur :
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=4096"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_KEEP_ALIVE=5m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
OLLAMA_CONTEXT_LENGTH=4096 llmfit fit -n 10
ollama pull qwen3:4b

Trois réflexes d'exploitation complètent ce réglage :

• Les logs. journalctl -u ollama -e affiche le journal du service : chargement des modèles, mémoire réservée, refus faute de RAM ;
• Le démarrage. Le script d'installation d'Ollama active le service au boot. Sur un serveur où le LLM n'est qu'un essai, sudo systemctl disable --now ollama le désactive et rend immédiatement la RAM au reste du système ;
• Les sauvegardes. Un modèle se retélécharge en quelques minutes : excluez le répertoire des modèles de votre backup pour ne pas copier 40 Go à chaque passage, et sauvegardez plutôt la configuration (la surcharge systemd, la liste des tags donnée par ollama list) (sauvegarder un VPS avec rsync).

Si l'API d'Ollama ou d'Open WebUI doit être joignable depuis l'extérieur, ne passez pas OLLAMA_HOST à 0.0.0.0 sans protection : placez un reverse proxy Nginx ou Apache devant, avec HTTPS et authentification, sous un nom de domaine dont l'enregistrement DNS pointe vers le serveur (reverse proxy Nginx sur un VPS Linux).

Après le chargement : vérifier la mémoire et mesurer le vrai débit

Une fois le modèle téléchargé, confrontez l'estimation à la réalité :

ollama run qwen3:4b "Réponds en une phrase : qu'est-ce qu'un VPS ?"
ollama ps
free -h
journalctl -k --since "1 hour ago" | grep -i "out of memory"
llmfit bench

• ollama ps affiche la mémoire réellement occupée par le modèle chargé et sa répartition entre CPU et GPU (100% CPU sur un VPS sans GPU) ;
• free -h montre ce qu'il reste pour le système et les autres services : la colonne available doit garder une marge confortable, conversation en cours ;
• journalctl -k filtré sur « out of memory » révèle un passage de l'OOM killer, avec le nom et le PID du processus tué ;
• llmfit bench mesure le débit réel (tokens par seconde et délai avant le premier token) en trois passes d'inférence contre le serveur qui tourne. L'option --share envoie le résultat au classement communautaire du projet sous forme de pull request GitHub ; elle n'est pas nécessaire pour une mesure locale.

Si la mémoire occupée dépasse nettement l'estimation, réduisez le contexte ou descendez d'un cran de quantification avant que le serveur ne le fasse à votre place.

Les limites de llmfit à connaître

• Le débit CPU est une estimation par formule. En mode CPU seul, llmfit part d'une constante (70 pour un processeur x86, 90 pour un ARM) divisée par le nombre de milliards de paramètres, corrigée selon la quantification, avec un bonus de 10 % à partir de 8 coeurs. Ni la fréquence, ni le nombre de canaux mémoire, ni AVX-512 n'entrent dans ce calcul : sauf mesure communautaire pour votre matériel, un bi-Xeon E5-2620 v4 et un bi-Xeon Gold 6230 reçoivent la même estimation. Les colonnes Conf et tok/s est. disent si le chiffre est estimé ou mesuré ;
• La RAM disponible est un instantané. Le verdict vaut pour l'état du serveur au moment du lancement. Un serveur de jeu qui monte en charge le soir change la donne ;
• Le surcoût d'exécution est forfaitaire. llmfit compte 0,5 Go ; Ollama et llama.cpp font leur propre calcul et peuvent conclure autrement, d'où l'intérêt de vérifier avec ollama ps ;
• La base de modèles suit les releases. Un modèle publié la veille peut manquer : vérifiez avec llmfit search "nom", mettez llmfit à jour en relançant le script d'installation ou cargo install llmfit, et consultez la documentation du projet pour déclarer un modèle personnalisé ;
• llmfit serve ouvre une API REST et une interface web qui décrivent votre matériel, par défaut sur 127.0.0.1:8787. Les exemples du projet utilisent --host 0.0.0.0, qui l'expose sur toutes les interfaces réseau : sur un serveur public, gardez l'adresse locale ou filtrez le port au pare-feu (gérer les ports avec UFW) ;
• Le verdict porte sur le matériel, pas sur la licence. Un modèle « Good » reste soumis à ses conditions d'usage : Qwen3 est publié sous licence Apache 2.0, Llama 3.3 sous la Llama 3.3 Community License. Lisez la fiche du modèle avant de le brancher sur un service commercial.

Conclusion : mesurer d'abord, télécharger ensuite

llmfit remplace une règle approximative (« un modèle de N milliards de paramètres demande environ N Go ») par un calcul qui tient compte de la quantification, du contexte et de la RAM réellement libre. Sur un VPS 8 Go sans GPU, il oriente vers les modèles de 1 à 4 milliards de paramètres et signale les 8B comme limites ; sur un serveur dédié de 64 Go ou plus, il ouvre la porte aux modèles de 30 à 70 milliards, en rappelant que la vitesse sur CPU dépend de la taille des poids lus à chaque token. Lancé avant chaque ollama pull, il évite le téléchargement de 40 Go inutiles et la nuit passée à comprendre pourquoi le serveur de jeu a été tué. Si llmfit réclame plus de RAM que votre machine n'en a, un VPS Linux de 16 à 48 Go ou un serveur dédié Xeon de 32 à 256 Go règle la question ; pour des cartes graphiques à vous, le housing GPU héberge votre propre matériel en datacenter.