Rédigé par Rédaction CyberSDF / 19 September 2026

LM Studio, Ollama ou llamafile : trois façons de lancer un modèle en local

Trois commandes suffisent pour charger le même GGUF sur une Debian 13 (trixie) : ollama run gemma4, lms chat et ./modele.llamafile. Ollama 0.34.2, publiée le 15 septembre 2026, écoute sur le port 11434, LM Studio 0.4.23, publiée en août 2026, sur le port 1234, et llamafile 0.10.6, publiée le 15 septembre 2026, sur le port 8080. Les trois embarquent llama.cpp, aucun ne range ses modèles au même endroit, et le dernier ne demande qu’un fichier de 1,77 Go.

Sur une Debian 13, le script d’Ollama crée un service systemd et place les poids dans /usr/share/ollama/.ollama/models, LM Studio s’installe comme application ou comme démon nommé llmster, et un llamafile préassemblé ne demande qu’un chmod +x. Les écarts portent sur des valeurs mesurables.

Trois ports par défaut, deux licences libres, une application propriétaire

Ollama écoute sur 11434, LM Studio sur 1234, llamafile sur 8080, et les trois se contentent de la boucle locale tant qu’aucune option ne les expose. Les licences divergent tout autant : Ollama est publié sous MIT, la CLI lms de LM Studio est sous MIT mais l’application reste propriétaire, gratuite y compris au travail, et llamafile est sous Apache 2.0 avec des modifications de llama.cpp sous MIT.

Le choix du modèle lui-même est traité dans choisir une IA locale, dans la rubrique IA.

Ollama 0.34.2 s’installe par script et range ses modèles hors du dossier personnel

1. Installer le binaire et le service :

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

   Le script installe le binaire et enregistre l’unité systemd ollama. systemctl status ollama doit répondre active (running).

2. Vérifier la version, puis lancer un modèle :

   ollama -v
   ollama run gemma4
   

   La première exécution télécharge les poids, la seconde ouvre l’invite de conversation.

3. Contrôler ce qui occupe la mémoire :

   ollama ps
   

   La sortie documentée prend cette forme, la colonne PROCESSOR donnant la répartition CPU/GPU :

   NAME        ID              SIZE      PROCESSOR    UNTIL
   llama3:70b  bcfb190ca3a7    42 GB     100% GPU     4 minutes from now
   

4. Lire les journaux du service :

   journalctl -e -u ollama
   

   La ligne Dynamic LLM libraries liste les moteurs détectés, par exemple cpu, cpu_avx, cpu_avx2, cuda_v11, rocm_v5. Forcer OLLAMA_LLM_LIBRARY="cpu_avx2" contourne une détection ratée.

Le service tourne sous l’utilisateur système ollama, et les modèles atterrissent donc dans /usr/share/ollama/.ollama/models. Les déplacer suppose sudo chown -R ollama:ollama /chemin et OLLAMA_MODELS dans l’unité systemd, mécanique décrite avec les services et journaux systemd. La procédure complète est dans installer Ollama.

LM Studio 0.4.23 se pilote avec lms, le démon llmster remplace la fenêtre

La version 0.4.0 de LM Studio a introduit llmster, un démon sans interface graphique qui reprend le moteur de l’application. Sur un serveur Debian sans écran, lms devient la seule interface.

1. Installer le démon :

   curl -fsSL https://lmstudio.ai/install.sh | bash
   

2. Démarrer le service :

   lms daemon up
   

   Lancé seul, lms affiche ses commandes : chat, get, load, unload, ls, ps et import pour les modèles, server et log pour le service.

3. Télécharger un modèle :

   lms get openai/gpt-oss-20b
   

   lms ls liste ensuite les modèles présents sur le disque.

4. Charger le modèle et ouvrir le port 1234 :

   lms load openai/gpt-oss-20b
   lms server start
   

   lms ps confirme le chargement. Le serveur répond sur http://localhost:1234 en API compatible OpenAI et sur /v1/messages en API compatible Anthropic, ce qui permet de pointer Claude Code vers LM Studio avec ANTHROPIC_BASE_URL=http://localhost:1234.

Un modèle appelé par l’API sans être chargé est monté à la demande, puis déchargé après 60 minutes d’inactivité ; lms load modele --ttl 3600 fixe une durée explicite et lms load modele --gpu 1.0 tente de tout déporter sur la carte graphique. Réserve documentée : l’application de bureau doit avoir été lancée une fois pour que lms réponde.

llamafile 0.10.6 : 1,77 Go, un chmod, aucun paquet installé

1. Télécharger un llamafile préassemblé :

   curl -LO https://huggingface.co/mozilla-ai/llamafile_0.10/resolve/main/Qwen3.5-0.8B-Q8_0.llamafile
   

   Le fichier fait 1,77 Go et contient le moteur et les poids.

2. Le rendre exécutable, puis le lancer :

   chmod +x Qwen3.5-0.8B-Q8_0.llamafile
   ./Qwen3.5-0.8B-Q8_0.llamafile
   

   Le mode par défaut démarre en même temps une conversation dans le terminal et un serveur sur http://localhost:8080. Ctrl-C arrête les deux.

3. Ne garder que le serveur, ou passer des poids externes :

   ./llamafile -m gpt-oss-20b-Q5_K_S.gguf --server --host 0.0.0.0 --port 8081
   

   --server supprime le chat et lance le serveur llama.cpp, --host 0.0.0.0 l’ouvre au réseau, ce qui n’est pas le cas par défaut. Sur un modèle conversationnel, --jinja active le gabarit de conversation et --ctx-size 64000 fixe la fenêtre.

4. Vérifier l’API :

   curl http://localhost:8080/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "LLaMA_CPP", "messages": [{"role": "user", "content": "Bonjour"}]}'
   

   La réponse contient un objet JSON avec les jetons produits et un bloc timings.

Le piège GPU de llamafile : « version `GLIBCXX_3.4.32′ not found »

Une bibliothèque CUDA précompilée plus récente que la libstdc++ de la distribution fait échouer le chargement avant la première question. Le message est littéral, cité comme bogue corrigé par la note de version 0.10.1 :

cuda: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found

Un llamafile 0.10.0 affiche cette ligne sur une Debian dont la libstdc++ est plus ancienne que celle des greffons ; le correctif tient dans la mise à jour de l’exécutable. À défaut, llamafile-thin ne contient aucune bibliothèque GPU précompilée et laisse construire ggml-cuda avec la boîte à outils locale.

Second piège, plus discret : llamafile retombe en silence sur le processeur quand aucun backend ne se charge, et rien à l’écran ne le signale. Passer --gpu nvidia, --gpu amd ou --gpu vulkan transforme ce repli muet en erreur explicite au démarrage. Sur une machine AMD, le message hipcc: Permission denied signifie que ROCm est détecté mais que la boîte à outils n’est pas exécutable par l’utilisateur. Dernière limite du paquet publié : la bibliothèque CUDA est allégée et laisse les couches quantifiées en IQ sur le processeur, sans fausser le résultat.

Ollama 0.34.2 répond sur 4096 jetons, quelle que soit la fenêtre du modèle

La FAQ d’Ollama fixe la valeur par défaut du contexte à 4096 jetons. Un modèle entraîné sur 131 072 jetons se fait donc couper sans message dès que la conversation dépasse cette taille, et la mémoire réservée grandit avec le produit OLLAMA_NUM_PARALLEL multiplié par OLLAMA_CONTEXT_LENGTH.

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Dans une session ollama run, la commande interne /set parameter num_ctx 8192 fait la même chose pour la session en cours. Par l’API OpenAI, ce réglage n’existe pas : il faut un Modelfile contenant PARAMETER num_ctx 8192, puis ollama create. Un modèle chargé reste cinq minutes en mémoire après la dernière requête, durée réglable par OLLAMA_KEEP_ALIVE ; ollama stop gemma4 libère immédiatement la place.

Entre llamafile 0.9 et 0.10, le moteur change et des fonctions disparaissent

llamafile 0.10.0, publiée le 19 mars 2026, remplace le système de compilation pour suivre llama.cpp de plus près. Les fichiers préassemblés indiquent la version du serveur qu’ils embarquent, 0.9 ou 0.10, et deux fichiers du même modèle peuvent donc se comporter différemment. Au moment de la 0.10.0, la liste des fonctions absentes publiée par le projet comprenait la génération d’images Stable Diffusion, l’outil de mesure localscore, le bac à sable pledge/SECCOMP et la prise en charge GPU sous Windows, revenue depuis.

La limite qui reste est celle de Windows : un exécutable de plus de 4 Go ne s’y lance pas, ce qui exclut les llamafiles embarquant un gros modèle. La parade documentée consiste à télécharger le binaire llamafile seul et à lui passer un GGUF externe avec -m, ou à travailler sous WSL. Côté GPU, la série 0.10 reste annoncée comme non testée sur toutes les plateformes, avec un support AMD et Windows qualifié de meilleur effort.

Questions fréquentes

Peut-on faire tourner les trois en même temps ?

Oui, les ports ne se chevauchent pas : 11434 pour Ollama, 1234 pour LM Studio, 8080 pour llamafile. La contrainte est la mémoire : chaque moteur charge sa propre copie des poids.

Les GGUF sont-ils interchangeables entre les trois ?

Le format est le même, les dossiers non. La documentation de llamafile donne les chemins : les modèles de LM Studio se trouvent sous ~/.cache/lm-studio/models/lmstudio-community/, et ceux d’Ollama sous ~/.ollama/models/blobs/, où chaque fichier porte le nom de son empreinte sha256. Un llamafile peut charger ces fichiers avec -m, avec une réserve : les GGUF produits par Ollama ne fonctionnent pas toujours avec llama.cpp.

Lequel choisir pour un serveur sans écran ?

Les trois tournent sans interface graphique : Ollama s’installe en service systemd, LM Studio fournit le démon llmster installé par script, llamafile s’exécute avec --server depuis n’importe quel dossier. Le critère décisif est ailleurs : Ollama gère une bibliothèque de modèles et ses mises à jour, llamafile ne laisse aucun fichier derrière lui.

Comment savoir si la carte graphique travaille ?

Ollama l’affiche dans la colonne PROCESSOR de ollama ps, avec des valeurs comme 100% GPU ou 48%/52% CPU/GPU. LM Studio répond avec lms ps. Pour llamafile, il faut forcer le backend avec --gpu nvidia ou lire les journaux de démarrage, puisque le repli sur le processeur ne produit aucun message.

Un GPU est-il obligatoire ?

Non. Les trois projets prévoient le calcul sur processeur : Ollama embarque les bibliothèques cpu, cpu_avx et cpu_avx2, llamafile refuse de démarrer sur un AMD64 sans AVX mais fonctionne sans carte graphique, et LM Studio exige AVX2 sur Windows x64. Pour un modèle 8B en Q4_K_M, comptez environ 5 Go de mémoire disponible.

Pour savoir lequel des trois écoute déjà sur la machine :

ss -tlnp | grep -E ':(11434|1234|8080)'