Outils LLM locaux sur macOS en 2026 : Ollama ou LM Studio
Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.
Les outils LLM locaux sur macOS répondent à quatre besoins distincts : exécuter une API, explorer des modèles, contrôler les paramètres d’inférence et expérimenter directement sur Apple Silicon. Ollama et LM Studio exposent désormais tous deux des API locales : le choix ne se résume donc plus à « API ou interface graphique ». Comparez le niveau de contrôle requis sur le cycle de vie, les modèles et le runtime pour chaque workflow.
Une configuration pratique utilise Ollama pour un petit service géré, ou LM Studio lorsque l’exploration des modèles, les SDKs, les structured outputs et un daemon headless doivent être réunis dans un même produit. Choisissez llama.cpp si vous avez besoin d’un contrôle direct sur l’exécution de GGUF. Choisissez MLX-LM pour les expérimentations Python natives sur Apple Silicon et le fine-tuning.
Dernière vérification : 2026-08-10. Critères de sélection : interface, format des artefacts, contrôle du runtime, automatisation, marge mémoire et exposition réseau.
Tableau de recommandations
| Outil | Idéal pour | À utiliser quand | Principal compromis |
|---|---|---|---|
| Ollama | Service local géré et cycle de vie des modèles | Vous voulez rapidement un endpoint léger et scriptable | Moins de contrôle bas niveau que llama.cpp. |
| LM Studio | Découverte de modèles, SDKs, daemon et workflows de serveur local | Vous voulez un environnement de développement desktop et headless unique | Son abstraction masque encore certains détails du runtime. |
| llama.cpp | Inférence GGUF, quantification, flags serveur et contrôle de Metal | Vous devez contrôler le contexte, le batch, la quantification et le comportement du runtime | Davantage de configuration et de flags. |
| MLX-LM | Génération et fine-tuning natifs sur Apple Silicon | Vous voulez expérimenter au niveau Python sur des Mac équipés de puces M | Écosystème de serving plus restreint qu’avec Ollama ou llama.cpp. |
Lequel installer en premier ?
Installez Ollama en premier si vous développez un logiciel. De nombreuses applications savent communiquer avec lui, et l’API locale suffit pour les prototypes, les tests et les petits outils internes. C’est le chemin le plus court entre « j’ai besoin d’un modèle local » et « mon application peut appeler un modèle local ».
Installez LM Studio en premier si vous choisissez un modèle ou si vous voulez utiliser ses SDKs Python et TypeScript, ses API locales, ses structured outputs, son tool use et son daemon headless. Vous pouvez passer de la comparaison interactive à un service scripté sans changer de produit.
Installez llama.cpp en premier si vous vous intéressez aux mécanismes de l’inférence. La longueur du contexte, la quantification, les flags Metal, le traitement du prompt, les tailles de batch et le comportement du serveur sont plus faciles à inspecter lorsque vous êtes plus proche du runtime.
Utilisez MLX-LM lorsque votre objectif dépasse le simple serving d’un modèle de chat. Il convient aux expérimentations de modèles natives sur Apple Silicon, à la conversion, au fine-tuning et aux workflows Python dans lesquels la mémoire unifiée fait partie de la conception.
Matrice des workflows
| Workflow | Choix par défaut | Pourquoi |
|---|---|---|
| API locale pour une application | Ollama | Ergonomie stable pour les développeurs et intégrations nombreuses. |
| Comparaison manuelle de modèles | LM Studio | La GUI accélère la comparaison des prompts et des modèles. |
| Diagnostic des performances | llama.cpp | Vous pouvez observer et contrôler les paramètres du runtime. |
| Serving de modèles GGUF quantifiés | llama.cpp ou Ollama | Utilisez llama.cpp pour le contrôle et Ollama pour la simplicité. |
| Expérimentations sur Apple Silicon | MLX-LM | Outils natifs pour les modèles sur les Mac équipés de puces M. |
| Démonstration à un interlocuteur non technique | LM Studio | Facile à présenter et à ajuster de manière interactive. |
| Configuration d’ingénierie reproductible | Ollama avec une liste de modèles épinglée | Plus facile à scripter qu’un workflow uniquement basé sur une GUI. |
Remarques matérielles
La mémoire unifiée est la véritable contrainte sur Apple Silicon. Un modèle qui tient sur un MacBook Pro de 64 Go peut être inutilisable sur un MacBook Air de 8 Go. La quantification aide, mais la longueur du contexte peut rapidement devenir le principal facteur de consommation mémoire. Évaluez la forme réelle des prompts plutôt que le seul nom du modèle.
Pour les petits outils locaux, un modèle de classe 7B ou 8B est souvent plus utile qu’un modèle plus grand saturé par la charge. Pour le code, un contexte long et l’intégration des outils peuvent compter davantage que le rang dans les benchmarks. Pour la QA documentaire, la qualité de la retrieval domine généralement le choix du modèle local.
À éviter
Ne transformez pas la configuration d’un LLM local en projet de benchmark permanent, sauf si les performances constituent le produit. Commencez avec Ollama ou LM Studio. Vérifiez que l’inférence locale apporte une réelle valeur. Passez ensuite à llama.cpp ou MLX lorsque vous avez une raison concrète de le faire.
Ne comparez pas les modèles uniquement dans une interface de chat si la charge réelle concerne l’extraction structurée, l’édition de code ou la synthèse de réponses RAG. Écrivez un petit script d’évaluation avec des prompts représentatifs.
Pour aller plus loin
- LLMs locaux sur macOS présente la configuration pratique.
- Variantes de LLMs à poids ouverts explique GGUF, GPTQ, AWQ, les modèles de base et les modèles instruct.
- Configuration d’un MacBook pour l’ingénierie AI couvre la configuration plus générale du poste de travail.