Tester des LLM en local sur Linux

L’idée de départ est simple : vérifier s’il est encore réaliste d’exécuter des modèles de langage localement sur des machines qui ne sont plus de première jeunesse.

Dans mon cas, je veux bâtir une méthode de test propre pour deux systèmes Linux :

• un laptop Lenovo ThinkPad avec 32 Go de RAM
• un desktop avec 16 Go de RAM et une AMD Radeon RX 580 8 Go

L’objectif n’est pas de battre des records. Je cherche surtout à répondre à des questions très concrètes :

• quels modèles valent la peine d’être testés en premier ;
• quelle machine est la plus adaptée selon le type d’inférence ;
• quels outils simplifient réellement les essais ;
• et jusqu’où on peut aller sans dépendre d’un service cloud.

Le constat de départ est encourageant : oui, il est réaliste de faire tourner des petits et moyens LLM en local, à condition de choisir les bons outils, les bons formats de modèles et d’accepter des compromis sur la vitesse.

Pourquoi faire tourner des LLM en local

Exécuter un modèle en local présente plusieurs avantages immédiats :

• les prompts et documents restent sur la machine ;
• le coût d’usage est plus prévisible ;
• il devient possible de tester différents modèles sans dépendre d’une API externe ;
• et l’on comprend beaucoup mieux les contraintes réelles de la mémoire, du CPU, du GPU et de la quantification.

C’est aussi une bonne manière de construire un petit laboratoire personnel autour des LLM open weight.

Les outils utiles pour démarrer

Avant de parler matériel, il faut clarifier le rôle des outils. Dans l’écosystème local, plusieurs noms reviennent souvent, mais ils n’occupent pas tous la même place.

Ollama

Ollama est le point d’entrée le plus simple pour lancer rapidement un modèle local.

Il permet de :

• télécharger un modèle ;
• l’exécuter depuis le terminal ;
• exposer une API locale ;
• et éviter une bonne partie de la configuration manuelle.

Exemple :

ollama pull llama3.1:8b
ollama run llama3.1:8b

Pour des essais rapides, c’est souvent le meilleur choix.

llama.cpp

llama.cpp est un moteur d’inférence très important dans l’écosystème local.

Il est particulièrement intéressant parce qu’il peut faire tourner des modèles quantifiés sur CPU, et parfois exploiter aussi le GPU selon le backend disponible. C’est souvent le moteur qui rend possible l’exécution locale sur du matériel modeste.

text-generation-webui

text-generation-webui est une interface web orientée expérimentation.

Elle permet notamment de :

• charger des modèles locaux ;
• discuter avec eux dans une interface graphique ;
• comparer différents réglages ;
• tester plusieurs backends.

Ce n’est pas seulement une “jolie interface” : c’est surtout un environnement pratique pour manipuler plusieurs modèles sans rester uniquement dans le terminal.

Open WebUI

Open WebUI remplit un rôle différent. Là où text-generation-webui est très orienté tests et réglages, Open WebUI met davantage l’accent sur une expérience utilisateur proche d’un assistant conversationnel classique.

Pour un usage quotidien, il peut être plus agréable. Pour une campagne de tests, Ollama seul ou text-generation-webui restent souvent plus directs.

Comprendre la pile locale

Un environnement LLM local se lit bien comme une pile de composants :

1. l’utilisateur envoie un prompt ;
2. une interface ou une CLI transmet la requête ;
3. un runtime ou un backend charge le modèle ;
4. le moteur d’inférence calcule les tokens ;
5. le matériel local exécute le tout.

On peut résumer cela ainsi :

Utilisateur
   ↓
Terminal / WebUI / API locale
   ↓
Ollama ou autre runtime
   ↓
llama.cpp / backend d’inférence
   ↓
Modèle quantifié
   ↓
CPU / RAM / GPU / VRAM

Comprendre cette séparation aide à éviter une confusion fréquente : Ollama n’est pas le modèle, l’interface web n’est pas le moteur, et le moteur n’est pas le matériel.

Pourquoi les LLM peuvent sembler lents en local

La lenteur des LLM locaux n’est pas un bug. Elle vient du mode de génération lui-même.

Une requête passe en gros par deux phases :

• une phase de lecture du prompt ;
• puis une génération token par token.

Le modèle ne produit pas sa réponse d’un bloc. Il prédit un token, puis un autre, puis un autre. À chaque étape, il faut recalculer une partie importante du réseau.

En pratique, trois variables dominent l’expérience :

• la taille du modèle ;
• la quantité de RAM ou de VRAM disponible ;
• et la quantification du fichier de poids.

C’est pour cela qu’un modèle 7B quantifié peut être parfaitement acceptable sur une machine modeste, alors qu’un modèle plus gros devient immédiatement lourd, voire pénible à utiliser.

Pourquoi la quantification change tout

Pour du local, la quantification est souvent la vraie clé.

Un même modèle peut exister en plusieurs formats compressés. Les variantes de type Q4 ou Q5 réduisent la taille mémoire et rendent l’inférence possible là où la version pleine précision serait impraticable.

Le compromis est généralement très acceptable pour des tests de chat, de résumé, de raisonnement simple ou d’assistance au code.

En pratique :

• un modèle plus petit ou quantifié charge plus facilement ;
• il utilise moins de RAM ou de VRAM ;
• et il démarre plus vite.

C’est ce point qui rend crédible l’usage de LLM locaux sur des machines plus anciennes.

Ma stratégie générale de test

Plutôt que de tout installer partout, j’ai intérêt à utiliser chaque machine pour ce qu’elle fait le mieux.

Règle simple

• Laptop 32 Go : très bon pour les essais CPU, les comparaisons de modèles, et les tests où la RAM compte davantage que l’accélération graphique.
• Desktop RX 580 8 Go : très bon pour commencer les essais interactifs et voir jusqu’où un modèle 7B ou 8B quantifié peut être accéléré localement.

Le plus intéressant n’est pas de choisir une seule machine, mais de comparer leur comportement avec les mêmes prompts.

Stratégie pour le laptop : ThinkPad avec 32 Go de RAM

Le laptop ne dépend pas d’un gros GPU dédié. Ici, la ressource la plus précieuse est la RAM système.

Ce qui est réaliste

Sur cette machine, la zone réaliste de confort se situe autour de :

• modèles très légers : 1B à 4B ;
• modèles intermédiaires : 7B à 8B quantifiés ;
• modèles plus gros : parfois possibles, mais rapidement plus lents et moins agréables.

Autrement dit, le laptop est très bien adapté à une logique de tests méthodiques sur CPU.

Modèles à essayer en premier

Je commencerais par cette séquence :

1. phi3
2. gemma:3b
3. mistral
4. llama3.1:8b
5. qwen2.5:7b

Cela permet de monter progressivement en qualité et en charge mémoire.

Ce que j’attends du laptop

Le laptop est le bon endroit pour :

• comparer la qualité des réponses à taille de modèle comparable ;
• mesurer l’impact du contexte et de la longueur de sortie ;
• vérifier ce qui reste acceptable sans GPU ;
• préparer une base de comparaison propre avec le desktop.

Plan d’essai concret

1. Préparer le système

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git python3 python3-venv python3-pip htop

2. Installer Ollama

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

3. Télécharger les premiers modèles

ollama pull phi3
ollama pull gemma:3b
ollama pull mistral
ollama pull llama3.1:8b
ollama pull qwen2.5:7b

4. Lancer les tests de base

ollama run phi3
ollama run gemma:3b
ollama run mistral
ollama run llama3.1:8b
ollama run qwen2.5:7b

5. Observer la charge système

htop
ollama ps

Ce que je veux mesurer

Pour chaque modèle sur le laptop :

• temps de chargement initial ;
• sensation de fluidité ;
• mémoire occupée ;
• qualité de réponse sur un prompt identique ;
• intérêt réel pour un usage quotidien.

Stratégie pour le desktop : 16 Go RAM + Radeon RX 580 8 Go

Le desktop a moins de RAM que le laptop, mais il possède un atout important : une RX 580 avec 8 Go de VRAM.

Cela en fait une machine logique pour tester des modèles quantifiés de taille intermédiaire, à condition de rester réaliste sur les limites de la carte.

Ce qui est réaliste

Le cœur de cible ici, ce sont surtout :

• les modèles 7B quantifiés ;
• certains 8B quantifiés ;
• et éventuellement des essais plus ambitieux avec offloading, selon l’outil et le backend.

La RX 580 n’est pas une carte récente, mais elle reste pertinente pour explorer l’inférence locale légère ou intermédiaire.

Premier retour pratique

J’ai déjà validé un point important :

ollama run llama3.1:8b

Sur le desktop, cette commande semble bien fonctionner. Ce n’était donc pas une erreur de commencer par cette machine. Au contraire, c’était un bon test initial.

Fallait-il réserver ce modèle au laptop ?

Non.

Le desktop est même une très bonne machine pour démarrer avec un 8B quantifié, parce qu’il permet de voir immédiatement si le runtime arrive à tirer parti du GPU, ou s’il retombe sur CPU/RAM.

Ensuite, le laptop servira surtout de point de comparaison : même modèle, même prompt, autre profil matériel.

Modèles à essayer en premier

Sur le desktop, je garderais cette séquence :

1. llama3.1:8b
2. mistral
3. qwen2.5:7b
4. phi3

Le but n’est pas d’accumuler des dizaines de modèles, mais d’obtenir une base de comparaison propre avec quatre profils utiles :

• un généraliste solide ;
• un modèle réputé efficace pour sa taille ;
• un modèle intéressant pour le code et le raisonnement ;
• un modèle très léger servant de témoin rapide.

Plan d’essai concret

1. Préparer le système

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git python3 python3-venv python3-pip htop

2. Installer Ollama

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

3. Installer un outil de surveillance GPU

sudo apt install -y radeontop

4. Télécharger les modèles recommandés

ollama pull llama3.1:8b
ollama pull mistral
ollama pull qwen2.5:7b
ollama pull phi3

5. Lancer les tests

ollama run llama3.1:8b
ollama run mistral
ollama run qwen2.5:7b
ollama run phi3

6. Vérifier l’activité et l’allocation

ollama ps
radeontop
htop

Ce que je veux vérifier sur le desktop

Sur cette machine, les questions sont un peu différentes :

• le GPU est-il réellement utilisé ;
• le ressenti est-il meilleur que sur le laptop ;
• le 8B reste-t-il confortable ;
• et jusqu’où la RX 580 reste-t-elle utile dans un usage réel.

Quand utiliser une interface web

Pour les premiers tests, la ligne de commande suffit largement. Ollama est parfait pour cela.

Mais une interface web devient intéressante quand je veux :

• enchaîner des comparaisons plus visuelles ;
• garder plusieurs conversations de test ;
• modifier facilement des paramètres ;
• ou préparer des captures d’écran pour un article technique.

Installer text-generation-webui

Voici une base de départ sous Linux :

git clone https://github.com/oobabooga/text-generation-webui
cd text-generation-webui
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python server.py --listen

L’interface est ensuite disponible en local sur le port exposé par l’application.

À quoi sert vraiment text-generation-webui

Il faut être précis : text-generation-webui n’est pas seulement “une interface qui installe des modèles”.

C’est plutôt un environnement de test qui permet de :

• charger ou importer des modèles ;
• lancer l’inférence dans une interface de type chat ;
• comparer plusieurs backends ;
• ajuster température, contexte et autres paramètres ;
• observer plus facilement le comportement du modèle.

Pour un article technique, cette distinction est utile, car elle évite de confondre gestionnaire, backend et interface utilisateur.

Quels modèles tester en premier

Pour un laboratoire personnel, il est plus utile de choisir peu de modèles mais de bien les observer.

Modèles généralistes

Llama 3.1 8B

ollama run llama3.1:8b

C’est une excellente base de comparaison pour :

• conversation générale ;
• reformulation ;
• explications techniques ;
• rédaction.

Mistral

ollama run mistral

Très intéressant pour mesurer le rapport vitesse / qualité.

Modèles orientés code et logique

Qwen 2.5 7B

ollama run qwen2.5:7b

À essayer pour :

• génération de scripts ;
• raisonnement structuré ;
• prompts techniques.

Modèles légers

Phi-3

ollama run phi3

Très utile comme point de référence rapide, notamment pour juger si un petit modèle suffit déjà à certains usages.

Protocole de test recommandé

Pour éviter les impressions vagues, il faut répéter le même protocole sur les deux machines.

Prompt de base

Je recommande de reprendre toujours les mêmes catégories de prompts :

1. explication générale :

   Explique simplement ce qu’est un LLM et comment il génère une réponse.

2. résumé technique :

   Résume en cinq points les avantages et les limites de l’inférence locale.

3. code léger :

   Écris un script Bash qui affiche l’usage mémoire toutes les deux secondes.

4. comparaison :

   Compare CPU et GPU pour l’inférence locale d’un modèle 7B quantifié.

Ce qu’il faut noter à chaque test

Pour chaque exécution :

• nom du modèle ;
• machine utilisée ;
• ressenti de latence ;
• usage CPU ;
• usage GPU si pertinent ;
• qualité perçue ;
• stabilité générale.

Tableau de benchmark à compléter

Le plus utile pour l’article final sera probablement un tableau simple rempli au fil des essais.

Ce que j’attends comme résultat global

À ce stade, mon hypothèse de travail est la suivante :

• le desktop sera probablement ma meilleure machine de départ pour les tests interactifs avec des modèles 7B et 8B ;
• le laptop sera probablement plus polyvalent pour des comparaisons CPU, des modèles légers et des essais où la RAM système compte davantage ;
• et dans les deux cas, la quantification restera le facteur déterminant.

Autrement dit, je ne cherche pas une machine “gagnante” dans l’absolu. Je cherche plutôt à attribuer à chaque machine un rôle cohérent.

Recommandation simple pour la suite

Mon ordre de travail le plus logique est désormais le suivant :

1. continuer les tests sur le desktop avec llama3.1:8b, mistral, qwen2.5:7b et phi3 ;
2. répéter ensuite les mêmes prompts sur le laptop ;
3. remplir le tableau de benchmark ;
4. puis décider quels modèles méritent une installation plus permanente.

Conclusion

Faire tourner des LLM en local sur Linux n’est plus réservé à des machines récentes ou très coûteuses.

Avec un bon choix d’outils, des modèles quantifiés et une méthode de test disciplinée, il est tout à fait possible de construire un laboratoire personnel crédible sur du matériel relativement ancien.

Dans mon cas, les deux machines ont un rôle clair :

• le desktop RX 580 pour les premiers essais interactifs et la comparaison CPU/GPU ;
• le ThinkPad 32 Go pour les tests CPU plus larges et la comparaison de modèles.

La suite logique sera de documenter les résultats réels : temps de réponse, confort d’usage, qualité perçue et limites concrètes de chaque configuration.

Annexe : mini check-list par machine

Laptop 32 Go

[ ] Installer Ollama
[ ] Télécharger phi3
[ ] Télécharger gemma:3b
[ ] Télécharger mistral
[ ] Télécharger llama3.1:8b
[ ] Télécharger qwen2.5:7b
[ ] Lancer les mêmes prompts de test
[ ] Observer avec htop et ollama ps
[ ] Remplir le tableau de benchmark

Desktop RX 580

[ ] Installer Ollama
[ ] Installer radeontop
[ ] Télécharger llama3.1:8b
[ ] Télécharger mistral
[ ] Télécharger qwen2.5:7b
[ ] Télécharger phi3
[ ] Lancer les mêmes prompts de test
[ ] Observer avec radeontop, htop et ollama ps
[ ] Remplir le tableau de benchmark