Tester des LLM localement sous Linux : attentes réalistes et plans d’exécution

3 min de lecture
Tester des LLM localement sous Linux : attentes réalistes et plans d’exécution

Introduction

Tester des LLM (Large Language Models) en local est aujourd’hui accessible sans infrastructure cloud. Mais il est essentiel d’avoir des attentes réalistes selon le matériel disponible.

Dans cet article, nous détaillons deux plans concrets :

  • 💻 Un laptop Linux avec 32 Go de RAM (CPU uniquement)
  • 🖥 Un desktop Linux avec 16 Go de RAM + AMD RX 580 (8 Go VRAM)

Objectif : installer, lancer et comparer des modèles quantifiés en comprenant les limites réelles de chaque configuration.


Principes importants avant de commencer

1. La quantification est indispensable

Les modèles doivent être utilisés en version GGUF quantifiée (Q4, Q5, Q6).

Sans quantification :

  • consommation mémoire trop élevée
  • performances inutilisables

Avec quantification :

  • division par 2 à 4 de la mémoire requise
  • vitesse acceptable même sans GPU

2. Taille réaliste des modèles

Taille modèle Usage réaliste CPU Usage réaliste GPU 8 Go
3B Très fluide Très fluide
7–8B Correct Fluide
13B Lent Possible avec offloading
>13B Très lent Non recommandé

Préparation commune (Linux)

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

Plan A — Laptop 32 Go RAM (CPU uniquement)

Attentes réalistes

  • 3B → très confortable
  • 7B → utilisable mais plus lent
  • 13B quantifié → possible mais lent
  • 13B → non pertinent sans GPU

Ce setup est parfait pour :

  • expérimentation
  • chat local
  • résumé de texte
  • aide au code légère

Étape 1 — Installer Ollama

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

Étape 2 — Télécharger des modèles recommandés

ollama pull llama3.1:8b
ollama pull mistral:7b-instruct
ollama pull gemma:3b

Étape 3 — Tester l’inférence

ollama run llama3.1:8b

Comparer :

  • temps de première réponse
  • tokens par seconde (ressenti)
  • consommation RAM (htop)

Option avancée — Interface Web

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/portable/requirements.txt
python server.py --listen

Puis ouvrir :

http://localhost:7860

Plan B — Desktop 16 Go RAM + RX 580 8 Go VRAM

Attentes réalistes

La VRAM devient le facteur limitant.

  • 7B Q4 → idéal
  • 8B Q4 → très bon compromis
  • 13B → possible mais serré
  • 13B → déconseillé

La RX 580 peut ne pas bénéficier d’une accélération aussi simple que CUDA. Prévoir fallback CPU possible.


Étape 1 — Installer text-generation-webui

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/portable/requirements.txt

Créer le dossier modèles :

mkdir -p user_data/models

Étape 2 — Télécharger des modèles GGUF

Exemples recommandés :

  • LLaMA 3 8B Q4
  • Mistral 7B Q4
  • Orca Mini 7B Q4

Télécharger via huggingface-cli ou dépôt GGUF.

TODO: Ajouter liens directs spécifiques selon version choisie.


Étape 3 — Lancer le serveur

python server.py --listen --api

Ouvrir :

http://localhost:7860

Activer si disponible :

  • GPU
  • offloading VRAM ↔ RAM

Comparaison des deux machines

Critère Laptop 32 Go Desktop RX 580
Installation Très simple Simple
Vitesse 7B Moyenne Bonne
Modèles >8B Lents Limité VRAM
Meilleur usage Exploration Usage quotidien

Bonnes pratiques

  • Toujours privilégier Q4_K_M ou équivalent
  • Surveiller RAM et VRAM pendant tests
  • Stocker les modèles sur SSD
  • Tester plusieurs modèles avant de choisir un “définitif”

Conclusion

Oui, il est réaliste d’exécuter des LLM localement sur du matériel non professionnel.

La clé est d’adapter :

  • la taille du modèle
  • la quantification
  • les attentes en termes de latence

Avec 32 Go RAM CPU ou 8 Go VRAM GPU, le sweet spot reste les modèles 7–8B quantifiés.

Au-delà, on entre dans une zone d’expérimentation plus lente et moins confortable.


Prochaine étape possible : benchmark chiffré (tokens/sec, RAM utilisée, temps de chargement) pour chaque modèle testé.