Petits modèles de langage sur hardware modeste : fais tourner des LLM sur ton laptop sans GPU

Y a pas longtemps, j’ai eu besoin de résumer une cinquantaine de documents internes pour un projet. Des specs, des ADR, des notes de réunion — le genre de truc qu’on envoie à GPT-4 avec un prompt bien foutu. Sauf que ces docs, c’étaient des données sensibles. Des architecture decisions, des noms de services, des IPs internes. Et là, le malaise. Tu envoies ça à OpenAI, tu sais exactement où ça finit : dans un dataset d’entraînement. Tu payes $0.01 pour 1K tokens. Et t’attends 200ms pour un truc qui devrait tourner sur ta machine.

Putain. On en est où en 2026 ?

Pendant ce temps, mon laptop de 8GB de RAM faisait tourner un modèle de 3 milliards de paramètres à 30 tokens par seconde. Sur le CPU. Sans GPU. Sans cloud. Sans que mes données quittent ma machine.

J’ai tout déchiré. J’ai viré les API cloud. Et voilà pourquoi.

Lexique

C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.

• SLM (Small Language Model): Un modèle de langage “petit” — typiquement 1 à 8 milliards de paramètres. Pas besoin d’un cluster GPU pour le faire tourner.
• Quantification: Le fait de réduire la précision des poids du modèle. Au lieu de 32 bits flottants, on passe à 4 bits. Résultat : le modèle fait 8x moins lourd avec quasi la même qualité.
• Q4_K_M: Le format de quantification standard. 4 bits, quality “medium”. C’est le sweet spot. 98% de la qualité du modèle original pour 25% de la taille.
• GGUF: Le format de fichier pour les modèles quantifiés. Un seul fichier, auto-portable, compatible avec tous les runtimes.
• Ollama: Le Docker des LLM. Tu fais ollama pull, ça télécharge. Tu fais ollama run, ça tourne. Zéro config.
• llama.cpp: Le moteur d’inférence C++ derrière Ollama. Le truc qui fait que ton CPU peut faire du matrix multiply à des vitesses acceptables.
• mmap: Memory-mapped files. Le OS map le fichier du modèle en mémoire et ne charge que les pages dont tu as besoin. Résultat : un modèle de 40GB tourne sur 16GB de RAM.
• SIMD: Single Instruction Multiple Data. Les instructions vectorielles du CPU (AVX2 sur x86, NEON sur ARM) qui permettent de calculer plusieurs opérations en même temps.
• Token/s: Tokens par seconde. La vitesse de génération. 30 tok/s, c’est plus rapide que tu ne lis. 5 tok/s, c’est lent mais utilisable.

Pourquoi tu t’en fous des gros modèles

Regarde les benchmarks. GPT-4 score 90% sur MMLU. Llama 3.3 8B score 72%. La différence ? GPT-4 te coûte $30/mois pour un usage modéré et envoie tes données chez OpenAI. Llama 3.3 tourne sur ton laptop pour $0.

Fais le calcul :

• API OpenAI : $0.01/1K tokens × 100 requêtes/jour × 500 tokens moyen × 30 jours = $150/mois
• Local : $0. Tu as déjà le hardware.

Et c’est pas juste une histoire de sous. C’est une histoire de souveraineté data.

Tes documents internes. Tes prompts business. Tes specs techniques. Tu envoies tout ça à une API tierce, et tu fais confiance au Terms of Service pour pas qu’ils l’utilisent. Spoiler : ils l’utilisent. Pas forcément pour entraîner, mais pour “améliorer les services”. Ce qui veut dire la même chose.

Avec un modèle local, rien ne sort de ta machine. Point. Pas de Telemetry. Pas de logging côté serveur. Pas de surprise au CT.

Et la latence ? Sur une API cloud, t’as 100-300ms de latence réseau avant même que le modèle commence à générer. En local, c’est 0ms. Le modèle est là. Il tourne. Il génère. C’est comme ça.

Le bestiaire des SLM

Bon, quels modèles tu peux tourner sur du hardware modeste ? Voici le top 5 en 2026.

Llama 3.2 3B — Le point de départ

C’est le modèle que je recommande si tu démarres. 2GB de download, 2.5GB de RAM, 128K de contexte. Il fait tout correctement : résumé, Q&A, code simple. C’est pas le plus intelligent, mais c’est le plus rapide et le plus facile à faire tourner.

Sur un CPU 8-core, tu t’en sors à 25-45 tokens par seconde. C’est plus rapide que la plupart des gens lisent. Tu poses une question, la réponse arrive avant que t’aies fini de boire ton café.

Phi-4 Mini 3.8B — Le petit génie

Microsoft a fait un boulot de ouf avec Phi. 3.8B de paramètres mais il se comporte comme un 7B sur certaines tâches. 68% sur MMLU, 70% sur HumanEval. Pour du code et du raisonnement structuré, c’est le meilleur rapport qualité/taille du marché.

Et il tourne à 30-50 tok/s sur CPU. C’est même pas lent. C’est fluide.

Gemma 3 2B — Le sprinter

Google a sorti Gemma 3 avec un contexte de 128K (contre 8K sur Gemma 2). Et surtout, il est blazing fast. 40-60 tok/s sur CPU. C’est le modèle le plus rapide que tu puisses faire tourner. Si t’as 4GB de RAM ou moins, c’est ton modèle.

Llama 3.3 8B — Le gros discret

Quand t’as besoin de qualité et que t’as 16GB de RAM, c’est celui-là. 72% sur HumanEval, 128K de contexte. Il est 2-3x plus lent que le 3B sur CPU (10-18 tok/s), mais la qualité de sortie est nettement meilleure pour les tâches complexes.

Qwen3 8B — Le multilingue

Si tu travailles en français, en chinois, en arabe — Qwen gère. Le contexte est plus court (32K, 131K avec YaRN), mais la qualité multilingue est imbattable. Et il fait aussi du code correctement.

Le hardware qu’il te faut

Règle du pouce : 0.5 à 1 GB de RAM par milliard de paramètres en quantification Q4. Plus le modèle est grand, plus tu as besoin de RAM.

Apple Silicon : le cas à part

Si t’as un MacBook avec une puce M1/M2/M3/M4, t’as un avantage de ouf. La unified memory fait que le CPU et le GPU partagent le même pool de RAM. Résultat : un modèle 8B tourne à 15-25 tok/s sur ton MacBook Air. C’est presque aussi rapide qu’un GPU dedicé.

C’est la beauté de l’architecture ARM. Pas de copie mémoire entre CPU et GPU. Le modèle est là, les deux l’utilisent, point.

CPU-only : c’est quoi la vitesse ?

Sur un CPU x86 moderne (Intel i7/Ryzen 7) avec AVX2 :

• 1B : 40-60 tok/s — instantané
• 3B : 25-45 tok/s — plus rapide que la lecture
• 7-8B : 10-18 tok/s — utilisable, pas interactif
• 13B : 5-8 tok/s — lent, faut attendre
• 70B : 1-3 tok/s — tu poses la question, tu vas te faire un café

La limite, c’est pas la capacité. C’est la vitesse. Un 7B sur CPU produit le même résultat que sur GPU. C’est juste plus lent.

Installation en 5 minutes

Étape 1 : Installer Ollama

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

C’est tout. Un script. Pas de dépendance Python, pas de Node.js, pas de Docker. Un binaire unique qui tourne partout.

Sur macOS, tu peux aussi installer via Homebrew :

0$ brew install ollama

Étape 2 : Télécharger un modèle

0$ ollama pull llama3.2:3b

Ça télécharge environ 2GB. Sur une connexion correcte, c’est 2-3 minutes. Le modèle est caché après le premier téléchargement — les prochains démarrent en quelques secondes.

Étape 3 : Lancer

0$ ollama run llama3.2:3b

Tu as un prompt interactif. Tu poses des questions, le modèle répond. C’est aussi simple que ça.

Étape 4 : Tester l’API

Ollama expose une API REST-compatible OpenAI. Tu peux l’utiliser avec n’importe quel client.

0$ curl http://localhost:11434/api/generate -d '{
1  "model": "llama3.2:3b",
2  "prompt": "Explique-moi ce qu'est le mTLS en 3 lignes",
3  "stream": false
4}'

Tu récupères le JSON avec la réponse. Et c’est là que ça devient puissant : tu peux brancher ça sur n’importe quel script, n’importe quelle pipeline, n’importe quel outil.

Étape 5 : Utiliser avec Python

0import requests
1
2response = requests.post("http://localhost:11434/api/generate", json={
3    "model": "llama3.2:3b",
4    "prompt": "Résume cette réunion en 5 bullet points",
5    "stream": False
6})
7
8print(response.json()["response"])

Ou avec le client officiel :

0from ollama import chat
1
2response = chat(model='llama3.2:3b', messages=[
3    {'role': 'user', 'content': 'Résume cette réunion en 5 bullet points'}
4])
5
6print(response['message']['content'])

Configuration avancée

Forcer le mode CPU

Si t’as un système hybride (GPU + CPU) et que tu veux forcer le CPU pour des raisons de test ou de Debug :

0$ CUDA_VISIBLE_DEVICES=-1 ollama serve

Optimiser les threads

Le nombre de threads est critique. Mets-le au nombre de cores physiques — pas logiques (hyperthreading).

0$ OLLAMA_NUM_THREADS=8 ollama run llama3.2:3b

Pourquoi pas les cores logiques ? Parce que l’hyperthreading partage les ressources entre deux threads. Pour du calcul intensif comme l’inférence, ça dégrade les performances. Le thread context switching te coûte plus qu’il ne t’apporte.

La magie du mmap

Quand tu charges un modèle avec Ollama ou llama.cpp, le fichier GGUF est memory-mapped. Le OS ne charge pas tout le modèle en RAM d’un coup. Il map le fichier en mémoire virtuelle et ne charge que les pages dont tu as besoin au moment où tu en as besoin.

Résultat : un modèle de 40GB peut tourner sur 16GB de RAM. Le modèle vit sur le disque, les pages actives vivent en RAM, et le working set courant vit dans le cache CPU.

C’est une hiérarchie à trois niveaux :

Disque (modèle complet) → RAM (pages actives) → Cache CPU (working set)

Les lectures sont séquentielles et grandes (bon pour le throughput), et le OS gère tout automatiquement. Tu n’as rien à configurer.

Comparaison des runtimes

Pour démarrer : Ollama. C’est le plus simple. Pour le contrôle total : llama.cpp. Tout est configurable. Pour la GUI : LM Studio. Le plus joli.

Cas d’usage concrets

Résumé de documents sensibles

Tu as 50 pages de specs internes. Tu veux un résumé en 10 bullet points. Au lieu d’envoyer ça à ChatGPT, tu fais :

0$ cat specs_internes.md | ollama run llama3.2:3b "Résume ce document en 10 bullet points"

Tes données restent sur ta machine. Personne sait que t’as des specs internes. Personne sait que t’as un projet secret.

Génération de code assistée

Phi-4 Mini est imbattable pour ça. 70% sur HumanEval, c’est better que beaucoup de Code Assistants cloud.

0$ ollama run phi4-mini "Écris une fonction Python qui valide une adresse email avec regex"

Chatbot interne pour l’équipe

Déploie Ollama sur un serveur interne, expose l’API, et branches ton Slack dessus. L’équipe pose des questions, le modèle répond. Zéro coût, zéro data leak.

Pipeline de traduction

Avec un modèle multilingue comme Qwen3, tu peux traduire des documents d’un bloc. Pas besoin d’API Google Translate qui envoie tout chez Google.

Test de prompts

Avant d’envoyer un prompt en production sur une API payante, testes-le en local. Si ça marche à 80% sur un 3B, ça marchera à 95% sur GPT-4. Et tu auras économisé quelques centimes.

Les pièges à connaître

CPU inference est 5-10x plus lent que GPU. C’est un fait. C’est acceptable pour du chat, pour du batch processing, pour des tâches asynchrones. C’est pas acceptable pour du temps réel interactif au-delà de 7B.

Au-delà de 13B, ça ralentit trop sur CPU pur. Un 13B à 5-8 tok/s, c’est utilisable mais tu attends. Un 70B à 1-3 tok/s, c’est du batch processing déguisé. Si tu veux du gros modèle, faut un GPU.

La qualité chute avec Q2_K. La quantification 2 bits, c’est trop. Tu perds en cohérence, en raisonnement, en qualité de code. Reste à Q4_K_M. C’est le sweet spot. 98% de la qualité pour 25% de la taille.

Le KV cache mange de la RAM. Pour un modèle 8B avec 16K de contexte en FP16, le KV cache seul prend ~1.5GB. Tu peux le réduire en quantifiant le cache aussi :

0$ ollama run llama3.3:8b --num-ctx 16384 --cache-type-k q8_0

Ne lance pas un 70B sur 16GB de RAM. Le modèle fait 40GB en Q4. Ça charge pas. Ça swap. Ça thrash. Et tu conclus à tort que “CPU c’est de la merde”. Non. T’as juste choisi le mauvais modèle pour ton hardware.

Mot de la fin

On vit dans un monde où les gens paient $30/mois pour envoyer leurs données à une API et attendre 200ms pour une réponse. Pendant ce temps, leur laptop fait tourner le même type de modèle en local, sans internet, sans facture, sans risque.

Les SLM en 2026, c’est plus de la expérimentation. C’est de la production. Phi-4 Mini à 70% HumanEval sur un laptop de $500, c’est pas un gadget. C’est un outil de travail.

Installe Ollama. Pull un 3B. Teste sur ton vrai use case.

Et si t’as un Apple Silicon, t’as même pas d’excuse. Le hardware est fait pour ça.

Tu veux de la souveraineté data ? Commence par là. Tu veux réduire tes coûts ? Commence par là. Tu veux de la latence minimale ? Commence par là.

Et souviens-toi : le meilleur modèle, c’est celui qui tourne sur ton hardware, pas celui qui score le mieux sur un benchmark.

See ya space-cowboy!