Lancer un premier modèle local

Lancer un modèle local consiste à réunir trois éléments : un fichier de poids, un runtime compatible et une machine suffisamment dimensionnée. L'interface de chat vient ensuite. Cette séparation aide à diagnostiquer les problèmes au lieu de réinstaller tout le système.

Choisir un premier modèle

Pour apprendre, un modèle instruction de 7B à 9B paramètres quantifié en 4 bits constitue souvent un bon départ. Vérifiez la langue française, la licence, le format distribué et la quantité de mémoire recommandée.

Le rôle du runtime

Le runtime lit les poids, prépare le calcul et expose une commande ou une API. llama.cpp privilégie la portabilité et le contrôle. Ollama simplifie la gestion des modèles. LM Studio propose une interface de bureau. vLLM vise davantage le service concurrent sur GPU.

Ces outils se recouvrent sans être interchangeables. Commencez avec celui qui supporte votre matériel et votre objectif immédiat.

Premier lancement avec Ollama

Ollama est le chemin le plus court pour une première inférence : il télécharge les poids, choisit une configuration adaptée à votre matériel et expose une API locale. Sous Windows et macOS, installez-le depuis le site officiel ollama.com. Sous Linux, le script officiel fait l'installation :

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

Si vous préférez lire un script avant de l'exécuter, téléchargez-le d'abord avec curl -fsSL https://ollama.com/install.sh -o install.sh, ouvrez-le, puis lancez sh install.sh.

Téléchargez ensuite un modèle, puis ouvrez une conversation dans le terminal :

ollama pull qwen3:8b
ollama run qwen3:8b

Le nom qwen3:8b est un exemple de modèle de 8 milliards de paramètres, distribué par défaut en 4 bits. La bibliothèque évolue vite : choisissez sur ollama.com/library un modèle de taille comparable qui annonce un bon niveau en français. Tapez /bye pour quitter la conversation.

Deux commandes servent à vérifier l'état du système :

ollama list   # modèles présents sur le disque, avec leur taille
ollama ps     # modèles chargés en mémoire, et sur quel processeur

Dans la sortie de ollama ps, la colonne PROCESSOR indique 100% GPU quand le modèle tient entièrement en VRAM. Une répartition comme 30%/70% CPU/GPU signifie qu'une partie déborde en RAM : la génération sera nettement plus lente. Libérez la mémoire avec ollama stop qwen3:8b.

Variante : llama.cpp

llama.cpp donne un contrôle direct sur chaque paramètre. Il lit un fichier GGUF que vous avez téléchargé vous-même, par exemple depuis la page du modèle sur Hugging Face. Les binaires précompilés sont publiés sur la page GitHub du projet.

llama-cli -m ./modeles/qwen3-8b-q4_k_m.gguf -ngl 99 -c 4096 \
  -p "Explique la différence entre RAM et VRAM en cinq phrases."

-m désigne le fichier de poids, -ngl 99 place toutes les couches possibles sur le GPU et -c 4096 fixe la longueur de contexte. Pour obtenir une API et une petite interface web, lancez le serveur :

llama-server -m ./modeles/qwen3-8b-q4_k_m.gguf -ngl 99 -c 4096 --host 127.0.0.1 --port 8080

Ouvrez ensuite http://127.0.0.1:8080 dans le navigateur de la même machine.

Télécharger avec méthode

Relevez le nom exact du modèle, sa version, sa quantization et sa source. Comparez la somme de contrôle si elle est fournie. Les fichiers de poids sont volumineux et peuvent être remplacés ou renommés.

Le format GGUF est courant avec llama.cpp et ses dérivés. D'autres runtimes utilisent des formats ou des structures différents. Le nom du modèle seul ne suffit pas à déterminer la compatibilité.

Vérifier le premier lancement

Utilisez une question courte dont vous connaissez la réponse. Observez :

• Le modèle est-il chargé sans erreur ?
• Quelle RAM et quelle VRAM sont utilisées ?
• Le premier token arrive-t-il dans un délai acceptable ?
• Le texte est-il lisible en français ?
• Le processus reste-t-il local selon les journaux réseau ?

Paramètres de génération

La température et les paramètres d'échantillonnage modifient la diversité. Pour un premier diagnostic, utilisez les valeurs recommandées par la fiche du modèle. Une configuration extrême peut faire paraître un bon modèle incohérent.

Fixez aussi une longueur de contexte raisonnable. Réserver la valeur maximale dès le départ peut augmenter fortement la mémoire sans bénéfice pour une question courte.

Ajouter une interface

Une interface comme Open WebUI peut se connecter à un backend local. Vérifiez l'adresse de l'API et l'exposition réseau. Une écoute sur 127.0.0.1 limite le service à la machine. Une écoute sur toutes les interfaces le rend potentiellement accessible sur le réseau.

Avec Docker installé, cette commande lance Open WebUI et le relie à l'Ollama de la machine. Le préfixe 127.0.0.1: limite l'interface à l'ordinateur lui-même :

docker run -d --name open-webui --restart always \
  -p 127.0.0.1:3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  ghcr.io/open-webui/open-webui:main

Ouvrez http://localhost:3000 et créez le compte administrateur local. Pour vérifier sur quelles adresses les services écoutent :

ss -tlnp | grep -E '11434|3000'

Get-NetTCPConnection -State Listen -LocalPort 11434, 3000

La première commande s'utilise sous Linux, la seconde dans PowerShell sous Windows. Une adresse locale 127.0.0.1 est rassurante. Une adresse 0.0.0.0 signifie que le service accepte les connexions venues du réseau.

Diagnostiquer par couches

Si le lancement échoue, séparez les causes : fichier incomplet, format incompatible, mémoire insuffisante, pilote absent, runtime mal configuré ou port déjà utilisé. Testez d'abord le runtime en ligne de commande, puis l'API, puis l'interface.