Exécuter des grands modèles de langage sur votre propre matériel est passé d'une activité de niche à une compétence pratique que chaque développeur et professionnel de la sécurité devrait maîtriser. Que vous construisiez des pipelines IA hors ligne, que vous gardiez des données sensibles hors des serveurs tiers, ou que vous soyez simplement fatigué de payer des coûts d'API par token, l'écosystème d'inférence locale a suffisamment mûri pour offrir de vrais résultats. Ce guide parcourt l'ensemble du flux de travail — du choix d'un format de modèle et d'un niveau de quantification, à l'exécution de l'inférence avec le bon outil, en passant par le benchmarking de tout pour prendre des décisions éclairées sur ce qui fonctionne réellement sur votre matériel.
Pourquoi exécuter des modèles localement ?
L'argument en faveur de l'inférence locale va au-delà du simple fait que « c'est gratuit ». Il existe des raisons architecturales et opérationnelles légitimes de garder vos modèles proches de votre capacité de calcul.
La souveraineté des données est la raison la plus évidente. Si vous traitez du code propriétaire, des données clients, des dossiers médicaux ou des informations classifiées, les envoyer à une API externe introduit un risque de conformité qu'aucune clause contractuelle ne peut entièrement éliminer. L'inférence locale signifie que vos données ne quittent jamais le périmètre de votre réseau.
La prévisibilité de la latence compte quand vous intégrez l'IA dans des outils interactifs. Les appels API aux fournisseurs cloud introduisent une variabilité réseau — parfois les réponses reviennent en 200 ms, parfois en 2 secondes. L'inférence locale vous donne des performances déterministes limitées uniquement par votre matériel. Pour des applications comme la complétion de code dans un IDE, l'analyse de journaux en temps réel ou les interfaces de chat interactives, cette constance vaut l'investissement en infrastructure.
Le coût à grande échelle devient significatif rapidement. Une équipe de développement de 10 ingénieurs effectuant chacun 50 appels API par jour à un coût moyen de 0,03 $ par requête dépense plus de 450 $ par mois. Un GPU de milieu de gamme qui coûte 1 000 $ une fois peut gérer cette charge de travail indéfiniment. Le seuil de rentabilité arrive plus vite que la plupart des équipes ne s'y attendent.
La vélocité d'expérimentation s'améliore quand vous n'avez pas de limites de débit ou de préoccupations de facturation. Vous pouvez exécuter 10 000 évaluations pendant la nuit sans vous soucier d'une facture surprise. Les expériences de fine-tuning, les itérations de prompt engineering et les pipelines de tests automatisés bénéficient tous d'un débit local illimité.
Comprendre GGUF : le format de modèle local
GGUF (GPT-Generated Unified Format) est devenu le format de fichier standard pour exécuter des modèles quantifiés localement. Il a remplacé l'ancien format GGML en 2023 et a résolu plusieurs problèmes pratiques qui rendaient l'inférence locale frustrante.
Ce que contient réellement un fichier GGUF
Un fichier GGUF est un binaire autonome qui contient tout le nécessaire pour charger et exécuter un modèle : la définition de l'architecture (nombre de couches, têtes d'attention, taille du vocabulaire), les poids quantifiés, le tokenizer, et des métadonnées comme la longueur de contexte d'entraînement original et les paramètres d'inférence recommandés. Avant GGUF, vous aviez besoin de fichiers séparés pour les poids du modèle, la configuration du tokenizer et les détails de l'architecture — une configuration fragile qui cassait facilement lorsque les fichiers étaient mal assortis.
Le format utilise un système de métadonnées clé-valeur que les moteurs d'inférence lisent au chargement. Cela signifie qu'un seul fichier .gguf indique à llama.cpp (ou à tout moteur compatible) exactement comment configurer le modèle sans fichiers de configuration supplémentaires.
Les niveaux de quantification expliqués
La quantification est le processus de réduction de la précision des poids du modèle de leur représentation originale en virgule flottante 16 bits ou 32 bits vers des types de données plus petits. Le compromis est toujours entre la taille du modèle, la vitesse d'inférence et la qualité de la sortie.
Voici ce que signifient réellement les labels de quantification courants :
Q2_K utilise une quantification à 2 bits avec optimisation k-quant. Les fichiers font environ 25-30 % de la taille FP16 originale. La qualité se dégrade notablement — attendez-vous à des sorties incohérentes sur les tâches de raisonnement complexe. Utile uniquement lorsque votre matériel est sévèrement limité et que vous avez besoin de quelque chose qui fonctionne tout simplement.
Q3_K_S, Q3_K_M, Q3_K_L sont les variantes à 3 bits. Les suffixes S/M/L contrôlent quelles couches reçoivent une précision légèrement supérieure : Small applique un surcoût minimal, Medium augmente les couches d'attention, et Large ajoute de la précision à plus de composants. Q3_K_M est le compromis idéal pour les configurations extrêmement contraintes où Q4 ne tient pas en mémoire.
Q4_K_S et Q4_K_M atteignent le seuil de qualité pratique pour la plupart des cas d'utilisation. À environ 40-45 % de la taille FP16, Q4_K_M offre une qualité de sortie difficile à distinguer du modèle complet sur les tâches courantes comme le résumé, la génération de code et la réponse aux questions. C'est le niveau de quantification le plus populaire dans la communauté pour de bonnes raisons.
Q5_K_S et Q5_K_M ajoutent environ 15 % de taille de fichier supplémentaire par rapport à Q4 mais récupèrent une qualité mesurable sur les tâches nécessitant un raisonnement nuancé, l'écriture créative et la logique multi-étapes. Si votre matériel peut gérer la mémoire supplémentaire, Q5_K_M est le choix pragmatique pour l'inférence locale polyvalente.
Q6_K se situe à environ 65 % de la taille FP16. Les rendements décroissants commencent ici — l'amélioration de qualité par rapport à Q5 est réelle mais faible. Ça vaut le coup si vous avez la VRAM disponible et que vous vous souciez des cas limites de qualité de sortie.
Q8_0 est effectivement le modèle pleine précision en format quantifié. À environ 75-80 % de la taille FP16, la perte de qualité est essentiellement non mesurable. Utilisez ceci quand vous avez un GPU performant et que vous voulez la meilleure sortie possible.
F16 est le modèle non quantifié en demi-précision. C'est votre référence pour les comparaisons de qualité. La plupart des modèles 7B nécessitent environ 14 Go de VRAM ; les modèles 13B nécessitent 26 Go ; les modèles 70B nécessitent 140 Go. À moins d'avoir un GPU d'entreprise ou plusieurs GPU grand public, vous travaillerez avec des versions quantifiées.
Choisir la bonne quantification
La matrice de décision est simple :
| VRAM disponible | Quantification recommandée | Cas d'utilisation |
|---|---|---|
| 4-6 Go | Q3_K_M ou Q4_K_S | Chat basique, tâches de code simples |
| 8 Go | Q4_K_M | Usage polyvalent, qualité équilibrée |
| 12-16 Go | Q5_K_M | Charges de travail de production, meilleur raisonnement |
| 24+ Go | Q6_K ou Q8_0 | Qualité maximale, benchmarking |
| 48+ Go | F16 | Recherche, fine-tuning, comparaisons de référence |
Pour la plupart des développeurs, Q4_K_M d'un modèle de 7-8 milliards de paramètres tournant sur un GPU avec 8 Go de VRAM offre le meilleur retour sur investissement. Si vous exécutez un modèle 13B, vous aurez probablement besoin de Q4_K_S pour tenir dans 12 Go de VRAM avec de la marge pour le contexte.
La pile d'inférence : outils et quand utiliser chacun
llama.cpp — La fondation
llama.cpp est le moteur d'inférence C/C++ qui a lancé le mouvement des LLM locaux. Il reste l'option la plus compatible matériellement, fonctionnant sur CPU, GPU NVIDIA (CUDA), GPU AMD (ROCm), Apple Silicon (Metal) et même les appareils mobiles.
Points forts : large support matériel, développement actif, support natif GGUF, et un mode serveur (llama-server) qui expose un point d'accès API compatible OpenAI. Cela signifie que vous pouvez pointer n'importe quel outil qui parle le format API OpenAI vers votre serveur llama.cpp local.
Quand l'utiliser : lorsque vous avez besoin d'un contrôle maximal sur les paramètres d'inférence, que vous ciblez du matériel inhabituel (GPU anciens, processeurs ARM, configurations multi-GPU), ou que vous voulez intégrer l'inférence directement dans une application C/C++.
Le processus de compilation intègre automatiquement les optimisations spécifiques au matériel :
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON # For NVIDIA GPUs
cmake --build build --config Release
Pour Apple Silicon, remplacez -DGGML_CUDA=ON par -DGGML_METAL=ON. Pour CPU uniquement, omettez les deux options.
Ollama — La couche d'expérience développeur
Ollama enveloppe llama.cpp (et d'autres backends) dans une expérience similaire à Docker : ollama pull, ollama run, ollama serve. Il gère les téléchargements de modèles, la gestion de la VRAM et le service d'API sans aucune configuration.
Points forts : mise en place très simple, détection automatique du GPU, bibliothèque de modèles intégrée avec téléchargements en une commande, système Modelfile pour la personnalisation, et API native compatible OpenAI.
Quand l'utiliser : pour le prototypage rapide, quand vous voulez un modèle fonctionnel en moins d'une minute, ou quand vous construisez des applications nécessitant un point d'accès API local fiable sans gestion d'infrastructure.
# Install and run
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2
ollama run llama3.2
# Serve as API
ollama serve # Exposes http://localhost:11434
Le système Modelfile d'Ollama vous permet de créer des configurations de modèle personnalisées :
FROM llama3.2
PARAMETER temperature 0.7
PARAMETER num_ctx 8192
SYSTEM "You are a senior security analyst specializing in penetration testing."
vLLM — Le moteur de débit
vLLM est un moteur d'inférence basé sur Python optimisé pour le service à haut débit. Son innovation clé est PagedAttention, qui gère la mémoire du cache KV comme un système de mémoire virtuelle — améliorant considérablement le débit lors du service de multiples requêtes concurrentes.
Points forts : meilleur débit pour l'inférence par lots, gestion efficace de la mémoire, parallélisme de tenseurs sur plusieurs GPU, et service de qualité production avec batching continu.
Quand l'utiliser : lorsque vous devez servir plusieurs utilisateurs simultanément, exécuter de gros travaux de traitement par lots, ou maximiser l'utilisation du GPU dans un déploiement de production.
pip install vllm
vllm serve meta-llama/Llama-3.2-8B --dtype auto --max-model-len 4096
vLLM nécessite généralement plus de VRAM que llama.cpp pour le même modèle car il pré-alloue de la mémoire pour son système de pagination. Prévoyez environ 20-30 % de VRAM en plus que la taille brute du modèle.
Comparaison des outils
| Fonctionnalité | llama.cpp | Ollama | vLLM |
|---|---|---|---|
| Complexité de mise en place | Moyenne | Faible | Moyenne |
| Support GGUF | Natif | Natif | Via conversion |
| Support GPU | CUDA, ROCm, Metal | CUDA, ROCm, Metal | CUDA principalement |
| Multi-GPU | Oui | Limité | Oui (parallélisme de tenseurs) |
| Débit (lots) | Modéré | Modéré | Le plus élevé |
| Efficacité mémoire | Meilleure | Bonne | Bonne (PagedAttention) |
| Compatibilité API | Compatible OpenAI | Compatible OpenAI | Compatible OpenAI |
| Bibliothèque de modèles | Téléchargement manuel | Catalogue intégré | HuggingFace Hub |
| Idéal pour | Contrôle, déploiement edge | Expérience dev, prototypage | Service en production |
Benchmarking : mesurer ce qui compte
Le benchmarking des modèles locaux est là où la plupart des gens trébuchent. Ils se concentrent sur les tokens par seconde sans considérer ce que ce chiffre signifie réellement pour leur cas d'utilisation.
Les métriques qui comptent
Tokens par seconde (t/s) est la métrique phare, mais vous devez distinguer entre la vitesse de traitement du prompt (la rapidité avec laquelle le modèle ingère votre entrée) et la vitesse de génération (la rapidité avec laquelle il produit la sortie). Le traitement du prompt est généralement 5-20x plus rapide que la génération car il peut être parallélisé sur la séquence d'entrée.
Temps jusqu'au premier token (TTFT) mesure combien de temps s'écoule entre l'envoi d'une requête et la réception du premier token de sortie. Pour les applications interactives, un TTFT inférieur à 500 ms paraît réactif ; au-dessus de 2 secondes, ça semble lent.
Le débit sous charge est ce qui intéresse les déploiements en production. Un serveur peut générer 40 t/s pour une seule requête mais seulement 15 t/s par requête quand il sert 10 utilisateurs concurrents. Le benchmarking à des niveaux de concurrence réalistes évite les surprises.
L'utilisation mémoire inclut à la fois les poids du modèle et le cache KV pour le contexte. Un modèle qui tient en VRAM avec un contexte de 2K peut déborder à 8K de contexte, causant un effondrement des performances lorsque le système bascule vers la RAM système.
Exécuter des benchmarks avec llama.cpp
llama.cpp inclut un outil de benchmarking intégré :
./llama-bench -m model.gguf -n 256 -p 512 -r 5
Cela génère 256 tokens avec un prompt de 512 tokens, répété 5 fois. La sortie rapporte la vitesse d'évaluation du prompt, la vitesse de génération et le temps total.
Pour un benchmark plus complet à travers différentes configurations :
# Compare quantizations
for q in Q4_K_M Q5_K_M Q6_K Q8_0; do
echo "=== $q ==="
./llama-bench -m "model-$\{q}.gguf" -n 256 -p 512 -r 3
done
Benchmarking avec Ollama
Ollama n'a pas de commande de benchmark dédiée, mais vous pouvez mesurer les performances en utilisant son API :
# Time a generation
time curl -s http://localhost:11434/api/generate \
-d '{"model":"llama3.2","prompt":"Explain TCP/IP in detail","stream":false}' \
| jq '.eval_count, .eval_duration'
La réponse inclut eval_count (tokens générés) et eval_duration (nanosecondes), que vous pouvez utiliser pour calculer les tokens par seconde.
À quoi ressemblent de bons chiffres
Pour un modèle de 7-8 milliards de paramètres avec quantification Q4_K_M :
| Matériel | Prompt (t/s) | Génération (t/s) | TTFT |
|---|---|---|---|
| M1 MacBook Pro (16 Go) | 80-120 | 15-25 | 200-400 ms |
| M2 Max (32 Go) | 150-250 | 30-50 | 100-200 ms |
| M3 Max (48 Go) | 200-350 | 40-65 | 80-150 ms |
| RTX 3060 (12 Go) | 200-400 | 30-50 | 100-250 ms |
| RTX 4070 (12 Go) | 400-700 | 50-80 | 50-150 ms |
| RTX 4090 (24 Go) | 800-1500 | 80-130 | 30-80 ms |
| A100 (80 Go) | 2000+ | 150-200 | 20-50 ms |
Pour les modèles 13B, attendez-vous à environ 40-50 % de ces chiffres. Pour les modèles 70B, attendez-vous à 10-15 % (et vous aurez besoin de plusieurs GPU ou d'une très grande VRAM).
Benchmarking de la qualité
La vitesse est insignifiante si les sorties sont inutilisables. Les benchmarks de qualité vous aident à trouver le point où la quantification commence à dégrader votre cas d'utilisation spécifique.
Créez un jeu de test de 50 à 100 prompts représentatifs de votre charge de travail réelle. Exécutez chaque prompt à travers le modèle quantifié et une référence fiable (le modèle FP16 ou un modèle API). Notez les sorties sur la correction, la complétude et la cohérence.
Pour les tâches de génération de code, exécutez les sorties à travers une suite de tests. Pour le résumé, utilisez les scores ROUGE contre des résumés de référence. Pour la classification, mesurez la précision par rapport aux données étiquetées. Le niveau de quantification où vos métriques de qualité tombent en dessous de votre seuil est votre plancher pratique.
Construire un pipeline IA local
Voici comment les pièces s'assemblent pour un flux de travail IA local pratique :
Pipeline de développement
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Télécharger │────▶│ Benchmarker │────▶│ Déployer │
│ modèle GGUF │ │ les quants │ │ via Ollama │
└──────────────┘ └──────────────┘ └──────────────┘
│ │ │
HuggingFace llama-bench ollama serve
ou URL directe ou eval custom port 11434
Étape 1 : Sélection et téléchargement du modèle
Trouvez des modèles sur HuggingFace, filtrés par le tag GGUF. Recherchez les uploads de quantificateurs connus (TheBloke, bartowski, mradermacher) qui fournissent une qualité constante à travers les niveaux de quantification.
# Download via HuggingFace CLI
huggingface-cli download TheBloke/Llama-3.2-8B-GGUF \
llama-3.2-8b.Q4_K_M.gguf --local-dir ./models/
# Or via Ollama
ollama pull llama3.2:8b-q4_K_M
Étape 2 : Valider et benchmarker
Avant de construire quoi que ce soit au-dessus d'un modèle, vérifiez qu'il fonctionne correctement et benchmarkez-le sur votre matériel :
# Quick sanity check
ollama run llama3.2 "What is 2+2? Answer with just the number."
# Benchmark multiple quantization levels
for model in llama3.2:8b-q4_K_M llama3.2:8b-q5_K_M llama3.2:8b-q8_0; do
echo "Testing: $model"
time ollama run $model "Write a Python function that implements binary search" --verbose
done
Étape 3 : Construire votre application
Avec un modèle validé, connectez votre application. Les trois outils majeurs exposent des API compatibles OpenAI :
from openai import OpenAI
# Point at your local server
client = OpenAI(
base_url="http://localhost:11434/v1", # Ollama
api_key="not-needed"
)
response = client.chat.completions.create(
model="llama3.2",
messages=[
{"role": "system", "content": "You are a security analyst."},
{"role": "user", "content": "Analyze this log entry for suspicious activity."}
],
temperature=0.3,
max_tokens=1024
)
Étape 4 : Surveiller et optimiser
Suivez les performances d'inférence au fil du temps. Surveillez la pression VRAM (qui cause des échanges mémoire et des ralentissements dramatiques), l'augmentation progressive de la longueur de contexte (les conversations plus longues utilisent plus de cache KV), et la dérive du modèle si vous faites du fine-tuning.
# Monitor GPU utilization
nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total \
--format=csv -l 5
# Apple Silicon monitoring
sudo powermetrics --samplers gpu_power -i 5000
Pièges courants et comment les éviter
Surestimer la VRAM. La taille d'un fichier modèle sur disque n'est pas la même que son besoin en VRAM. Le modèle a besoin de mémoire supplémentaire pour le cache KV (qui évolue avec la longueur du contexte) et pour la mémoire de travail du moteur d'inférence. Prévoyez 20-40 % de VRAM en plus que la taille du fichier modèle.
Ignorer la longueur de contexte. Un modèle qui fonctionne bien avec un contexte de 2K peut planter ou devenir insupportablement lent avec un contexte de 32K. Le besoin en mémoire du cache KV évolue linéairement avec la longueur du contexte. Si vous avez besoin de longs contextes, benchmarkez à votre longueur cible, pas à la longueur par défaut.
Benchmarker à froid. La première inférence après le chargement d'un modèle est toujours plus lente car les poids sont en cours de chargement dans la VRAM/le cache. Exécutez 2-3 inférences de chauffe avant de collecter les données de benchmark.
Utiliser la mauvaise quantification pour la tâche. La génération de code et la sortie structurée (JSON, XML) sont plus sensibles à la quantification que le chat conversationnel. Si votre modèle Q4_K_M produit du JSON malformé, essayez Q5_K_M ou Q6_K avant de supposer que le modèle lui-même est le problème.
Ne pas tester les cas limites. Les modèles locaux échouent différemment des modèles API. Ils peuvent gérer parfaitement l'anglais mais se dégrader sur les entrées multilingues. Ils peuvent fonctionner sur des prompts courts mais halluciner sur de longs contextes. Testez avec vos vrais prompts de production, pas seulement des exemples de démonstration.
Ignorer le surcoût du prompt système. Les grands prompts système consomment des tokens de contexte et du temps de traitement à chaque requête. Un prompt système de 500 tokens signifie que chaque inférence commence par le traitement de ces 500 tokens. Gardez les prompts système concis pour les applications sensibles à la latence.
L'état actuel de l'IA locale en 2026
L'écosystème d'inférence locale s'est consolidé autour de quelques patterns clés. GGUF est le format de modèle dominant pour le matériel grand public. Ollama est devenu l'outil de développement par défaut, tout comme Docker est devenu la référence pour les conteneurs. llama.cpp reste le backend critique pour les performances. Et vLLM domine le service en production où le débit compte plus que la simplicité.
La qualité des modèles de petite taille continue de s'améliorer. Les derniers modèles à 8 milliards de paramètres égalent ce que les modèles 70B pouvaient faire il y a deux ans sur la plupart des benchmarks. Les techniques de quantification ont progressé au point où les sorties Q4_K_M sont presque indiscernables de FP16 sur les tâches standard.
L'histoire du matériel est tout aussi convaincante. Apple Silicon avec sa mémoire unifiée gère élégamment les modèles 7-13B. Les GPU NVIDIA grand public (RTX 4070 et au-dessus) offrent de sérieuses performances d'inférence. Et l'écart entre le matériel grand public et d'entreprise continue de se réduire à mesure que les moteurs d'inférence deviennent plus efficaces.
Pour quiconque construit des outils alimentés par l'IA — qu'il s'agisse d'automatisation de la sécurité, d'analyse de code, de traitement de documents ou d'assistants interactifs — l'option locale n'est plus un compromis. C'est un choix architectural légitime avec des avantages clairs en matière de confidentialité, de coût et de latence. Les outils sont matures, les modèles sont capables et la communauté est active. La seule question est quelle combinaison de modèle, quantification et moteur d'inférence correspond à votre cas d'utilisation spécifique.
Commencez avec Ollama, téléchargez un modèle Q4_K_M, benchmarkez-le sur votre charge de travail réelle et itérez à partir de là. La mise en place complète prend moins de cinq minutes, et vous aurez une image claire de ce que l'inférence locale peut faire pour votre flux de travail.