Un SLM on-device, c'est un modèle de langage qui tourne directement sur votre poste, votre serveur local ou un équipement edge — sans envoyer une seule ligne de texte vers un cloud externe. Latence quasi nulle, confidentialité native, zéro coût marginal d'API après la mise en place, fonctionnement hors ligne garanti. Sur du matériel courant avec 8 à 16 Go de RAM, un modèle 1B à 4B quantifié en GGUF tourne aujourd'hui sans GPU dédié.
Ce guide vous montre concrètement comment faire tourner un LLM en local : pourquoi c'est pertinent pour une PME, quels outils choisir (Ollama, llama.cpp), quels modèles fonctionnent sur quel matériel, et surtout où s'arrêtent honnêtement les capacités de l'IA edge — pour ne pas l'appliquer là où elle ne conviendra pas.
Pourquoi exécuter un modèle IA en local plutôt que dans le cloud
La plupart des démonstrations IA se font via une API cloud. C'est pratique, rapide à prototyper — et ça masque complètement ce qui se passe côté données. Pour beaucoup de PME, ce modèle suffit. Pour d'autres, il pose trois problèmes concrets.
Confidentialité et RGPD. Dès qu'un document client, un contrat ou un email interne passe dans un appel API, il transite sur des serveurs tiers. Pour les secteurs réglementés (santé, juridique, finance, défense industrielle), c'est souvent un blocage net. En local, les données ne sortent jamais du périmètre de l'entreprise — c'est une architecture qui supprime le problème structurellement, pas un engagement contractuel.
Latence et fonctionnement hors ligne. Une inférence locale sur un bon GPU prend moins d'une seconde pour un modèle 3B. Pas d'aller-retour réseau, pas de dépendance à la disponibilité d'une API tierce. Sur un site industriel avec une connexion fragile, dans un outil embarqué sur mobile ou dans un environnement avec exigences de latence strictes — c'est souvent non-négociable.
Coût marginal zéro. Une fois le modèle installé, chaque inférence est gratuite. Pour des usages à fort volume sur des tâches simples (classification de documents, extraction de champs, reformulation courte en lot), le on-device devient économiquement imbattable face à des APIs facturées au token dès quelques dizaines de milliers d'appels par mois.
Ollama et llama.cpp : les deux outils de référence pour le LLM en local
Deux outils concentrent la quasi-totalité des déploiements on-device sérieux en 2026. Ils ne sont pas interchangeables.
llama.cpp : le moteur d'inférence bas niveau
llama.cpp, développé par Georgi Gerganov, est le moteur d'inférence open source écrit en C++ qui a rendu le on-device viable sur CPU. Il exécute les modèles au format GGUF sur x86, ARM, Apple Silicon et même WASM. Pas de dépendance Python, pas d'overhead de framework — juste du C++ optimisé avec support BLAS, CUDA et Metal.
Pour un déploiement edge en production avec des contraintes de matériel précises (Raspberry Pi, Jetson Orin, serveur ARM), ou quand on veut contrôler finement les threads CPU, les couches GPU, le contexte et les paramètres de sampling — c'est la bonne brique. La contrepartie : il faut gérer soi-même le téléchargement des modèles et les paramètres d'exécution.
Ollama : l'accès le plus rapide pour commencer
Ollama est une surcouche qui s'appuie sur llama.cpp et ajoute une couche de gestion : CLI simple, téléchargement des modèles depuis un registry, et une API REST locale compatible avec le format OpenAI. En une commande — ollama run phi4-mini — un modèle tourne et expose une API sur localhost:11434.
Cette compatibilité API OpenAI est le vrai atout : la plupart des frameworks (LangChain, LlamaIndex, LiteLLM) et des applications qui pointaient vers l'API d'OpenAI s'y connectent sans modifier le code. Pour prototyper rapidement, valider un modèle sur vos données ou mettre en place un assistant interne sans équipe DevOps dédiée, Ollama est la meilleure porte d'entrée.
LM Studio et les outils mobiles
LM Studio est une application desktop avec interface graphique pour télécharger et tester des modèles GGUF, utile pour les équipes non-techniques en phase d'évaluation. Sur mobile, llama.cpp existe en version iOS/Android, et MLC (Machine Learning Compilation) propose des runtimes optimisés pour les accélérateurs ARM des smartphones. Les usages restent limités aux modèles 1B maximum sur la plupart des appareils, mais les premières applications edge embarquées réelles tournent déjà dessus.
Quels modèles sont réalistes pour une IA on-device en entreprise ?
Soyons précis sur ce qui existe en juin 2026. Les modèles "edge" crédibles se situent tous entre 500M et 8B paramètres, utilisés au format GGUF quantifié.
En INT4 (Q4_K_M), les besoins mémoire sont les suivants : un modèle 1B pèse environ 1 Go, un 3-4B entre 2 et 4 Go, un 8B entre 5 et 6 Go. Ces chiffres déterminent ce que votre matériel peut faire tourner.
Les candidats on-device validés en 2026 :
- Llama 3.2 1B et 3B (Meta) — bonne qualité générale pour la taille, multilingue correct. Le 3B est le modèle le plus polyvalent pour les tâches de Q&A et de reformulation on-device.
- Ministral 3B (Mistral AI) — performant en français professionnel pour 3B. Notre recommandation pour les PME françaises avec des documents métier en français.
- Phi-4-mini (Microsoft, 3,8B) — performances étonnantes sur les tâches de raisonnement structuré et d'extraction JSON pour sa taille. Le meilleur candidat quand le 3B généraliste ne suffit plus.
- Gemma 3 1B et 4B (Google) — architecture optimisée pour l'inférence CPU, bonne documentation, convient bien aux environnements contraints.
- Qwen2.5 0,5B à 3B (Alibaba) — fort en multilingue dont le français, excellent sur les tâches structurées (code, JSON, SQL).
- SmolLM2 (Hugging Face, 135M à 1,7B) — ultra-léger, conçu explicitement pour le on-device. Qualité limitée mais latence minimale, parfait pour des appareils très contraints.
Pour un comparatif complet avec benchmarks et licences, voir notre article sur les meilleurs SLM en 2026 et notre présentation des SLM pour l'entreprise.
Tableau matériel → modèle réaliste
La question concrète : est-ce que ça tourne sur mon matériel ? Voici les correspondances basées sur les contraintes réelles de RAM et VRAM en quantification INT4, avec des vitesses de génération suffisantes pour un usage interactif.
| Matériel | RAM / VRAM disponible | Modèle recommandé | Format GGUF | Tokens/s approx. |
|---|---|---|---|---|
| Laptop récent, CPU seul, 8 Go RAM | ~4 Go utilisables | SmolLM2 1,7B, Llama 3.2 1B | Q4_K_M | 3–8 t/s |
| Laptop récent, CPU seul, 16 Go RAM | ~8–10 Go utilisables | Llama 3.2 3B, Phi-4-mini, Ministral 3B | Q4_K_M | 5–12 t/s |
| Mac Apple Silicon M2/M3, 16 Go RAM unifiée | ~12 Go utilisables | Llama 3.2 3B, Phi-4-mini, Gemma 3 4B | Q4_K_M | 30–60 t/s |
| PC avec GPU NVIDIA RTX 3060/4060 (12 Go VRAM) | 12 Go VRAM | Llama 3.2 8B, Mistral 7B Q4 | Q4_K_M | 40–80 t/s |
| Serveur edge (Jetson Orin, 32 Go) | ~24 Go utilisables | Llama 3.2 8B, Ministral 8B | Q4_K_M | 15–35 t/s |
| Mini-PC ARM / Raspberry Pi 5 | 4–8 Go RAM | Llama 3.2 1B, Qwen2.5 0,5B | Q4_0 | 2–6 t/s |
| Smartphone récent (ARM, 8–12 Go RAM) | ~2–3 Go utilisables | SmolLM2 135M–360M (via MLC) | Q4_0 | 3–8 t/s |
Le seuil acceptable pour un usage interactif (assistant texte) est généralement autour de 10 tokens/seconde. En dessous, c'est utilisable pour du traitement par lot (classification, extraction en différé), mais frustrant en interactif. La RAM unifiée des puces Apple Silicon est particulièrement efficace pour le on-device : le GPU et le CPU partagent la même mémoire, ce qui élimine les copies de données et explique les vitesses élevées malgré l'absence de GPU discret.
Pour les configurations qui dépassent le on-device et nécessitent un serveur GPU dédié, notre guide de déploiement LLM en production couvre les configurations datacenter — un périmètre différent de l'edge et du local traités ici.
Cas d'usage concrets : où le on-device tient vraiment ses promesses
Trois usages reviennent régulièrement sur les projets que nous accompagnons.
RAG souverain sur données confidentielles
Un cabinet juridique ou une équipe RH qui traite des données personnelles ne peut pas envoyer ces documents vers une API externe. En couplant un SLM local via Ollama avec une base vectorielle hébergée sur le même serveur interne (ChromaDB, Qdrant en mode local), on construit un assistant documentaire capable de répondre à des questions sur des fiches de poste, des évaluations ou des contrats — sans qu'une seule donnée ne sorte du réseau interne. Pour l'architecture complète d'un tel système, notre guide sur le RAG souverain avec Mistral détaille les choix techniques.
Traitement de documents en lot sur site industriel
Un bureau d'études qui extrait des entités de plans techniques ou de rapports d'inspection. Les plans sont confidentiels, le site peut être hors réseau. Un serveur local avec un modèle 7B Q4 tourne des pipelines d'extraction la nuit sur les documents de la journée. Résultat le matin, zéro octet sorti vers l'extérieur. Le modèle ne comprend pas les plans CAO complexes — mais il extrait des champs structurés depuis des rapports texte associés, et c'est déjà beaucoup.
Assistance rédactionnelle hors ligne
Ollama exposé localement avec une intégration dans VS Code ou un éditeur métier. Un développeur ou un rédacteur qui travaille sans internet conserve un assistant IA opérationnel. Un modèle 3B suffit pour la complétion de code simple, les reformulations courtes et les réponses à des questions sur la documentation locale.
Les limites réelles : ce qu'il ne faut pas attendre d'un SLM on-device
Le on-device n'est pas une solution universelle. Voici les limites structurelles à nommer avant de décider.
Qualité plafonnée sur les tâches complexes. Un Llama 3.2 3B n'est pas GPT-4o. Sur des tâches de raisonnement multi-étapes, d'analyse juridique fine, de synthèse de documents longs ou de génération créative avancée, la différence est réelle et mesurable. Le on-device est pertinent sur des tâches délimitées et répétitives — extraction, classification, reformulation courte — pas sur des requêtes ouvertes complexes. À tester impérativement sur votre cas d'usage réel avant de décider : pas les benchmarks génériques, vos données à vous.
Contexte limité en pratique. Les modèles on-device acceptent théoriquement de longues fenêtres de contexte, mais les performances chutent fortement au-delà de 8K tokens sur du matériel courant. Pour des documents longs, un pipeline RAG local avec découpage en chunks reste indispensable plutôt que de tout passer dans le contexte.
Vitesse sur CPU : acceptable pour du batch, lente en interactif. 5 à 12 tokens par seconde sur CPU avec un 3B, c'est tolérable pour de la génération en différé. Pour un chatbot interne utilisé en temps réel, c'est lent. Un GPU d'entrée de gamme (RTX 3060, 400–500 € d'occasion) change l'équation en passant à 40–80 tokens/s.
Maintenance à votre charge. Mises à jour des modèles, gestion des versions GGUF, déploiement sur plusieurs postes — rien ne se fait automatiquement. Sur 10 postes, c'est gérable avec Ollama. Sur 50, un serveur d'inférence centralisé on-premise est souvent plus rationnel qu'un déploiement distribué poste par poste. Notre comparatif des serveurs d'inférence LLM open source couvre cette alternative (vLLM, Ollama server, LMDeploy, Triton).
Pas adapté au raisonnement lourd. Les modèles de raisonnement type o1, o3 ou DeepSeek R1 nécessitent des architectures plus grandes. Les versions quantifiées qui tournent on-device perdent trop en qualité sur ces cas. Pour ces usages, un déploiement sur serveur GPU dédié reste nécessaire — les deux approches sont complémentaires.
Pour aller plus loin
- Notre service d'expert en IA générative et déploiement LLM : de l'architecture on-device à l'intégration en production sur votre infrastructure.
- Guide complet sur la quantisation LLM, GGUF et INT4 : niveaux de quantisation (Q4_K_M, Q5_K_M, Q8_0), compromis qualité/vitesse, comment choisir le bon format.
- SLM pour l'entreprise : pourquoi les petits modèles de langage sont devenus crédibles en production en 2026.
- Comparatif des meilleurs SLM en 2026 : benchmarks, licences et cas d'usage par modèle (Phi-4-mini, Ministral, Gemma 3, Qwen2.5…).
- Comparatif des serveurs d'inférence LLM open source : Ollama, vLLM, Triton, LMDeploy — quand centraliser plutôt que distribuer poste par poste.
- RAG souverain avec Mistral : combiner un SLM local avec une base documentaire interne sans aucun flux cloud.
- Déployer un LLM en production : infrastructure GPU serveur, vLLM, coûts et monitoring — quand on sort du on-device pour un datacenter.
- Ollama.com : documentation officielle, registry de modèles disponibles via
ollama pull. - llama.cpp (GitHub) : le moteur C++ de référence pour l'inférence locale sur CPU et GPU.
Vous hésitez encore ?
On regarde ensemble si le on-device tient sur votre matériel et votre cas d'usage. 30 minutes suffisent.
En résumé : le on-device pour les tâches délimitées, le cloud pour le raisonnement lourd
Le SLM on-device n'est pas un gadget de puriste de la souveraineté. C'est une architecture viable, testée en production, qui résout de vrais problèmes : confidentialité des données, latence, fonctionnement hors ligne, coût marginal nul sur du volume. Ollama et llama.cpp ont rendu le déploiement accessible. Les modèles 1B à 8B quantifiés en GGUF tournent sur du matériel qu'on a déjà dans la plupart des PME.
La règle de décision est simple : tâche délimitée, répétitive, sur données sensibles ou sans connexion fiable — on-device. Raisonnement complexe, documents longs, contexte étendu, volume qui nécessite 70B+ — serveur GPU dédié ou API cloud. Les deux s'utilisent souvent ensemble sur des architectures hybrides où le on-device traite le volume courant et le cloud prend le relais sur les cas difficiles.
Première étape concrète : identifier la tâche candidate, vérifier le tableau matériel ci-dessus, tester un modèle en 30 minutes avec Ollama. C'est ce qu'on fait avant de recommander une architecture à un client.
