# SLM on-device en 2026 : l'IA quitte le cloud pour votre machine
Pendant trois ans, le réflexe a été le même : pour faire de l'IA, on appelle une API distante - OpenAI, Anthropic, Mistral. Mais en 2026, une contre-tendance s'installe. Les SLM (Small Language Models), des modèles de 1 à 8 milliards de paramètres, tournent désormais directement sur un laptop, un téléphone, voire dans un onglet de navigateur via WebGPU. Moins puissants que les géants, mais locaux, privés, gratuits à l'usage et hors-ligne, ils redéfinissent ce qu'on peut embarquer dans une application.
En une phrase : tout n'a pas besoin de GPT-5. Une bonne partie des tâches IA réelles tient dans un modèle de 3 Go qui tourne sur la machine de l'utilisateur.
TL;DR
- Un SLM (~1 à 8 B paramètres) tient en mémoire sur du matériel grand public grâce à la quantification.
- Ollama, llama.cpp et LM Studio rendent l'exécution locale triviale, avec une API compatible OpenAI.
- WebGPU + WebLLM / Transformers.js permettent de faire tourner un modèle dans le navigateur, sans serveur.
- Avantages : vie privée, coût zéro à l'inférence, latence faible, hors-ligne.
- Limites : capacités de raisonnement plus faibles, fenêtre de contexte réduite, dépendance au matériel client.
C'est quoi un « Small » Language Model ?
Il n'y a pas de seuil officiel, mais la convention en 2026 situe les SLM entre ~1 et ~8 milliards de paramètres - contre des centaines de milliards pour les modèles frontier. Les familles les plus utilisées :
| Famille | Tailles typiques | Éditeur | Point fort |
|---|---|---|---|
| Llama 3.x | 1B / 3B / 8B | Meta | Polyvalence, écosystème |
| Qwen 2.5/3 | 0.5B à 7B | Alibaba | Multilingue, code |
| Gemma 2/3 | 2B / 9B | Qualité/taille excellente | |
| Phi-3/4 | 3.8B (mini) | Microsoft | Raisonnement « petit mais costaud » |
| Mistral / Ministral | 3B / 7B / 8B | Mistral | Performances européennes, licences claires |
Le vrai déclic n'est pas seulement la taille des modèles : c'est la quantification.
La quantification, clé de l'embarqué
Un modèle est entraîné en 16 bits par poids (FP16). Pour le faire tenir en mémoire, on réduit la précision des poids à 8, 4, voire 2 bits. Un modèle 7B passe ainsi de ~14 Go à ~4 Go en Q4, avec une perte de qualité souvent minime.
| Format | Taille (modèle 7B) | Usage |
|---|---|---|
FP16 | ~14 Go | Référence, GPU costaud |
Q8_0 | ~7,5 Go | Qualité quasi intacte |
Q4_K_M | ~4,4 Go | Le bon compromis grand public |
Q2_K | ~2,8 Go | Matériel très contraint, qualité dégradée |
Règle de poche : pour un confort correct, prévoyez de la RAM (ou VRAM) au moins égale à la taille du fichier quantifié + ~1 à 2 Go pour le contexte. Un
Q4de 7B est confortable dès 8 Go de RAM.
Ollama : l'outil qui a tout démocratisé
Ollama a fait pour les LLM locaux ce que Docker a fait pour les conteneurs : une commande, et ça tourne. Il enveloppe llama.cpp, gère le téléchargement, la quantification et expose une API HTTP compatible OpenAI.
# Installer et lancer un modèle (téléchargement auto)
ollama run llama3.2:3b
# Servir une API locale sur http://localhost:11434
ollama serveCôté code, on consomme ça comme l'API OpenAI - il suffit de changer l'URL de base :
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "http://localhost:11434/v1",
apiKey: "ollama", // ignoré, mais requis par le SDK
});
const res = await client.chat.completions.create({
model: "llama3.2:3b",
messages: [{ role: "user", content: "Résume ce texte en 3 points." }],
});
console.log(res.choices[0].message.content);L'intérêt : votre code applicatif ne change pas entre un SLM local et un modèle cloud. On peut basculer de l'un à l'autre selon le contexte (offline, données sensibles, coût).
Le reste de la boîte à outils
- llama.cpp - le moteur d'inférence C/C++ sous-jacent, portable jusque sur Raspberry Pi
- LM Studio - une interface graphique pour explorer, télécharger et tester des modèles
- vLLM / TGI - plutôt côté serveur, pour servir des SLM à plus grande échelle
- GGUF - le format de fichier standard pour les modèles quantifiés
L'IA dans le navigateur grâce à WebGPU
C'est la frontière la plus spectaculaire. WebGPU - désormais disponible dans les navigateurs modernes - donne au JavaScript un accès direct au GPU. Conséquence : on peut faire tourner un modèle entièrement côté client, sans le moindre serveur d'inférence.
Deux briques principales :
- WebLLM - exécute des modèles de chat (Llama, Phi, Qwen) dans le navigateur via WebGPU, avec une API compatible OpenAI
- Transformers.js (Hugging Face) - fait tourner des modèles ONNX (embeddings, classification, petits LLM) en WebGPU ou WASM
import { CreateMLCEngine } from "@mlc-ai/web-llm";
// Le modèle est téléchargé puis mis en cache dans le navigateur
const engine = await CreateMLCEngine("Llama-3.2-3B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
messages: [{ role: "user", content: "Bonjour !" }],
});
console.log(reply.choices[0].message.content);Ce qui devient possible :
- Confidentialité totale - les données ne quittent jamais l'appareil (santé, juridique, RH)
- Coût d'inférence nul - c'est le GPU de l'utilisateur qui travaille, pas votre facture cloud
- Hors-ligne - une PWA peut embarquer de l'IA sans connexion
- Pas de cold start serveur - une fois le modèle en cache, tout est instantané
Le revers : le premier téléchargement du modèle (1 à 4 Go) est lourd, et les performances dépendent entièrement du GPU du client. WebGPU n'est pas encore uniformément disponible sur tous les navigateurs mobiles.
Quand choisir un SLM local plutôt que le cloud ?
| Critère | SLM local | LLM cloud |
|---|---|---|
| Vie privée | Oui, données sur l'appareil | Non, transitent par un tiers |
| Coût à l'usage | Nul après téléchargement | Facturé au token |
| Hors-ligne | Oui | Non |
| Latence | Faible (local) | Dépend du réseau |
| Qualité / raisonnement | Correcte sur tâches ciblées | Supérieure |
| Contexte long | Limité | Très large |
| Matériel requis | À la charge du client | Aucun côté client |
La bonne grille de lecture n'est pas « local OU cloud » mais le bon modèle pour la bonne tâche :
- SLM local - classification, extraction, reformulation, résumé court, autocomplétion, assistants offline, traitement de données sensibles
- LLM cloud - raisonnement complexe, agents multi-étapes, très long contexte, génération de code ambitieuse
Pattern gagnant en 2026 : l'architecture hybride. Le SLM local gère le flux rapide et privé (90 % des requêtes), et on escalade vers le cloud uniquement pour les cas difficiles. Comme un cache, mais pour l'intelligence.
Limites à garder en tête
- Raisonnement plafonné - un 3B ne remplacera pas un modèle frontier sur les tâches complexes
- Fenêtre de contexte réduite - souvent 4K à 32K tokens en pratique sur du matériel grand public
- Hétérogénéité matérielle - l'expérience varie énormément entre un MacBook M-series et un PC d'entrée de gamme
- Poids de distribution - embarquer un modèle dans une app, c'est plusieurs Go à télécharger et à mettre à jour
- Maintenance - gérer les versions de modèles, les formats (
GGUF,MLC,ONNX) et la compatibilité WebGPU ajoute de la complexité
Conclusion
Les SLM on-device incarnent une bascule discrète mais profonde : après la course au plus gros modèle, voici venu le temps du plus petit modèle qui suffit. Grâce à la quantification, à Ollama et à WebGPU, l'IA devient une fonctionnalité locale, privée et gratuite à l'usage - exactement ce qui manquait pour l'intégrer partout, jusque dans une simple PWA.
Le cloud ne disparaît pas : il reste indispensable pour le raisonnement de pointe. Mais en 2026, concevoir une application IA sans se demander « est-ce que ça peut tourner en local ? » devient une occasion manquée - en coût, en confidentialité et en expérience utilisateur.


