SLM locaux : guide pratique et réglages avec Ollama

Exécuter un modèle linguistique sur sa propre machine n'est plus une curiosité technique. Entre gains de confidentialité, coûts prévisibles et latence réduite, les SLMs locaux s'imposent pour des usages concrets — à condition de bien choisir, tester et configurer. Voici comment valider un modèle, l'insérer dans des architectures efficaces et le faire tourner avec Ollama en respectant les contraintes matérielles et de paramétrage.

Valider d’abord : 20 à 50 exemples et focus sur les échecs

Avant toute intégration, la priorité consiste à vérifier qu’un modèle candidat répond au niveau d’exigence de la tâche visée. Constituer tôt un petit jeu d’évaluation, composé de 20 à 50 exemples représentatifs avec les sorties attendues, permet de trancher. Il n’a pas besoin d’être formel : exécuter chaque modèle sur ce jeu et procéder à une revue manuelle contre vos critères spécifiques informe mieux que des classements génériques. L’attention doit porter d’abord sur les modes d’échec plutôt que sur une moyenne flatteuse. Un modèle qui réussit 90 % des cas mais échoue gravement sur 10 % peut se révéler moins adapté qu’un autre légèrement moins performant mais aux erreurs plus contrôlées. Identifier où un modèle se brise avant de bâtir dessus évite des impasses. Les tests doivent enfin refléter les longueurs de contexte réelles : un modèle à l’aise sur des requêtes courtes peut se dégrader nettement quand l’entrée s’allonge.

Intégrer localement : RAG, assistants de code, agents et pipelines

Plusieurs architectures tirent particulièrement bien parti d’un SLM local. La réponse à des questions sur des documents personnels est un point de départ efficace : en combinant un modèle local à un système de récupération, un pipeline de type RAG synthétise des réponses à partir de fichiers, PDF, notes ou documentation interne sans que ces données ne quittent la machine. Les assistants de codage locaux profitent aussi de la faible latence : des modèles ajustés pour le code tournent vite sur un matériel modeste, s’intègrent en plugins d’éditeur ou en outils en ligne de commande, et peuvent accéder au système de fichiers et au contexte complet du projet, sans appel à une API. Pour des usages plus avancés, des flux agentiques où un agent décide quels outils appeler et dans quel ordre fonctionnent bien avec des modèles compacts, souvent spécialisés, qui gardent l’ensemble rapide et modulaire. En local, ces chaînes d’agents opèrent hors ligne et sans dépendances externes. Enfin, des pipelines d’extraction, de classification et de transformation structurées entrent dans le champ d’un modèle à 7 milliards de paramètres, avec l’avantage de traiter des données sensibles sans les exposer.

Exécuter en local avec Ollama sur macOS, Linux et Windows

Côté outillage, Ollama s’impose comme point d’entrée pour exécuter des modèles en local. L’outil gère le téléchargement des modèles, l’accélération GPU et expose une API locale, le tout via une interface en ligne de commande. Il fonctionne sur macOS, Linux et Windows et, une fois installé, permet de tirer et lancer un modèle en une seule commande. Par défaut, Ollama sert le modèle via une API REST locale sur le port 11434, ce qui autorise un dialogue applicatif avec les mêmes schémas qu’une API HTTP classique. Des bibliothèques comme LangChain et LlamaIndex disposent d’intégrations natives, facilitant l’insertion du modèle dans une architecture existante. La bibliothèque de modèles proposée est soignée, mais elle n’est pas limitative : il est possible d’importer des modèles au format GGUF depuis Hugging Face et de les exécuter via Ollama, ouvrant l’accès à des ajustements communautaires et à des variantes spécialisées — utile quand un modèle généraliste ne cadre pas exactement avec le besoin.

Sélectionner le modèle : 1–3B, 7B, 13B et quantification GGUF

Le choix d’un modèle dépend autant de la tâche que du matériel disponible. En règle générale, des modèles de 1 à 3 milliards de paramètres tournent sur presque toute machine moderne avec 8 Go de RAM ; les modèles de 7 milliards forment la catégorie la plus populaire sur du matériel grand public ; ceux de 13 milliards approchent la limite de ce qu’un seul GPU haut de gamme ou une machine très dotée en RAM peut gérer efficacement. La spécialisation compte : pour le code, des modèles comme Code Llama ou Qwen-Coder sont ajustés ; d’autres conviennent mieux au suivi d’instructions, à la synthèse ou au chat. Plutôt que de viser le plus grand modèle exécutable, il est préférable d’apparier le modèle à la tâche, puis de valider sur cas réels. Les benchmarks restent utiles, mais la mesure décisive reste la qualité des sorties sur votre usage. Le format de quantification pèse sur la taille et la vitesse. La plupart des modèles locaux sont diffusés en GGUF, qui autorise des quantifications 4 ou 8 bits, réduisant la mémoire avec un compromis de qualité modeste. Pour beaucoup d’applications, Q4 ou Q5 constitue un réglage par défaut pertinent. Côté familles, Llama 3, Mistral, Gemma 2, Phi-3 et Qwen 2.5 méritent une évaluation, chacune ayant ses forces propres.

Mesurer les gains locaux : confidentialité, coûts, latence et limites

L’exécution locale change la donne sur trois axes : confidentialité, coûts et latence. Les requêtes et réponses ne sortent pas de l’environnement, un atout clé pour les documents sensibles, les données propriétaires ou personnelles ; passer par une API cloud introduit de toute façon un tiers dans la chaîne d’inférence. Côté coûts, l’API se facture à l’usage alors que le local repose sur un coût matériel fixe sans facturation au jeton, ce qui libère le prototypage et la montée en charge d’outils internes. Sur la latence, éliminer le trajet réseau améliore la réactivité perçue, y compris sur un matériel modeste. Ces gains s’accompagnent de contraintes : fenêtres de contexte en général plus petites, capacité brute moindre sur des tâches complexes, besoin d’une mise en place initiale et d’un matériel adapté. À titre d’ordre de grandeur, un modèle de 7 milliards de paramètres requiert environ 8 Go de VRAM ou de RAM pour des vitesses jugées raisonnables en 4 bits. Dans ce paysage où la logique « plus grand = mieux » n’est plus la règle, clarifier ces compromis en amont oriente le choix ; pour élargir la perspective, cinq ressources dédiées aux SLMs proposent un panorama utile de l’écosystème.

Optimiser : Modelfiles, contexte 4K–32K, température et prompts

Au-delà de l’exécution, la configuration fait la différence. Ollama s’appuie sur des Modelfiles — proches dans l’esprit d’un Dockerfile — pour définir le comportement : prompt système, longueur de contexte, température et paramètres d’échantillonnage, arrêts ou contraintes de formatage peuvent y être précisés. De nombreux modèles offrent des fenêtres de contexte de 4K à 32K tokens ; plus le contexte est grand, plus la mémoire grimpe. Réduire la fenêtre accélère les échanges et allège l’empreinte quand l’application traite des requêtes courtes ; pour un assistant documentaire ou un outil de synthèse, il faut équilibrer la taille du contexte avec les ressources disponibles. La température règle la randomisation des sorties : des valeurs basses, autour de 0,1 à 0,3, favorisent le déterminisme pour la génération de code ou l’extraction de données ; des valeurs plus hautes, de 0,7 à 1,0, diversifient les réponses pour des tâches créatives. Enfin, une large part de la qualité provient du prompt système lui‑même : définir clairement le rôle, le format attendu et les contraintes rapproche un modèle généraliste d’un outil spécialisé. Mieux vaut affiner ce prompt avant d’envisager un modèle plus grand.