LLMs locaux sur macOS : Ollama, LM Studio, MLX, llama.cpp

Viacheslav Dubrov

2025-05-10 · Mis à jour 2026-08-10 · 7 min · Ingénierie des modèles · Outils de développement

Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Les ingénieurs qui exécutent des modèles en local sur un Mac Apple Silicon doivent dimensionner la charge complète, et pas seulement choisir un modèle qui se télécharge. Apple Silicon peut traiter les prompts courants sans API distante, car le CPU et le GPU partagent un pool de mémoire unifié, mais les poids du modèle doivent y cohabiter avec le KV cache, l’espace de travail du runtime et macOS.

Une fois le modèle visé, le contexte et la marge mémoire validés, choisissez l’interface de contrôle adaptée au workflow : Ollama pour un service local géré, LM Studio pour l’inspection depuis une application de bureau, llama.cpp pour l’exécution directe de GGUF, ou MLX-LM pour du Python natif sur Apple. Vous séparez ainsi l’évaluation de la qualité du modèle du choix de l’outil et obtenez un benchmark équitable, tenant compte de la mémoire, pour la stack que vous exécuterez.

TL;DR. Utilisez Ollama pour un service local géré, LM Studio pour explorer les modèles depuis une application de bureau et accéder à ses APIs locales, llama.cpp pour contrôler directement l’exécution de GGUF, et MLX-LM pour expérimenter en Python natif sur Apple. Aucun n’est systématiquement le plus rapide. Évaluez le modèle, la quantification, le contexte et la charge exacts, avec une marge mémoire suffisante.

Consultez le tableau de décision synthétique : Outils LLM locaux sur macOS en 2026.

Commencez par une enveloppe mémoire

La taille brute des poids quantifiés n’est que le premier terme :

peak memory ≈ model weights
            + KV cache
            + runtime workspace
            + multimodal components
            + application and OS memory

La longueur du contexte, le type du cache, le nombre de requêtes parallèles et l’architecture du modèle modifient le résultat. Un modèle 7B ou 8B nominalement en quatre bits peut rester difficile à utiliser sur un Mac doté de 8 Go, car le système d’exploitation ne peut pas allouer toute la mémoire installée au runtime.

Utilisez Moniteur d’activité ou les métriques propres au runtime pendant vos tests. Apple définit la pression mémoire à partir de la mémoire libre, du débit du swap, de la mémoire câblée et des fichiers en cache. Gardez une marge suffisante pour éviter un swap prolongé : un modèle qui se charge mais pousse le système en pression mémoire n’est pas adapté à une utilisation interactive.

Distinguez également l’inférence locale du fonctionnement hors ligne. Les prompts peuvent rester sur la machine alors que l’application accède encore au réseau pour télécharger des modèles, effectuer des mises à jour ou activer des fonctionnalités optionnelles. Ollama documente séparément l’exécution locale, le téléchargement des modèles et les fonctionnalités cloud optionnelles dans sa FAQ. Considérez le fonctionnement hors ligne comme une exigence de workflow à vérifier pour chaque application : téléchargez d’abord les artefacts, déconnectez le réseau, puis testez l’ensemble du workflow.

Les quatre outils répondent à des problèmes de workflow différents

Il s’agit d’un tableau des responsabilités, pas d’un classement des performances. Plusieurs outils peuvent utiliser des kernels ou des formats apparentés, et les performances varient selon la prise en charge du modèle et la version.

Ollama : un service local géré

Ollama gère les téléchargements de modèles, les templates, le cycle de vie des processus et une API localhost. Il est utile lorsque le code applicatif doit cibler un service local stable plutôt que gérer lui-même les flags d’inférence.

MODEL=llama3.2
ollama pull "$MODEL"
ollama run "$MODEL" "Explain unified memory."

curl http://localhost:11434/api/chat \
    -H 'Content-Type: application/json' \
    -d '{
      "model": "'"$MODEL"'",
      "messages": [{"role": "user", "content": "Explain unified memory."}],
      "stream": false
    }'

Inspectez le manifeste du modèle et la configuration du contexte au lieu de supposer qu’un nom court de bibliothèque identifie un checkpoint immuable. Épinglez ou consignez l’artefact exact utilisé pour les évaluations.

Ollama sacrifie une partie de la visibilité bas niveau au profit de la simplicité de gestion du cycle de vie. Passez à llama.cpp ou à un autre runtime lorsque vous devez contrôler directement un fichier GGUF, un chat template, un paramètre de cache ou une nouvelle fonctionnalité de backend.

LM Studio : exploration depuis une application de bureau et APIs locales

LM Studio est utile lorsque la découverte des modèles, la configuration du chargement, l’inspection des conversations et l’évaluation humaine côte à côte doivent faire partie d’un même workflow. Il expose désormais des SDKs natifs Python et TypeScript, des endpoints compatibles avec OpenAI, des structured outputs, le tool use et un daemon headless : ce n’est donc plus seulement une interface graphique de bureau.

Le SDK Python actuel se connecte à un modèle que vous avez déjà téléchargé :

import lmstudio as lms

MODEL_KEY = "ibm/granite-4-micro"

with lms.Client() as client:
    model = client.llm.model(MODEL_KEY)
    response = model.respond("Write one sentence about local inference.")
    print(response)

Démarrez l’API locale depuis l’onglet Developer ou avec :

lms server start

LM Studio peut servir des modèles sur localhost ou sur un réseau local et prend en charge les API tokens dans ses paramètres d’authentification API. Laissez-le lié à l’interface loopback, sauf si l’accès distant est intentionnel. Si vous l’exposez sur un LAN, imposez l’option d’API-token documentée, appliquez une règle de pare-feu sur l’hôte et vérifiez les accès aux outils et aux intégrations.

llama.cpp : exécution directe de GGUF

llama.cpp est la voie de référence lorsque l’artefact est au format GGUF et que vous voulez observer directement la frontière du runtime. Il prend en charge Apple Metal ainsi que le CPU et d’autres backends matériels.

brew install llama.cpp

# Download through the Hugging Face integration and select a quantization.
MODEL_REPO=ggml-org/gemma-3-1b-it-GGUF
QUANT=Q4_K_M
llama-cli -hf "$MODEL_REPO:$QUANT"

# Or start an OpenAI-compatible local server.
llama-server -hf "$MODEL_REPO:$QUANT"

Le chemin -hf actuel du dépôt peut télécharger un projecteur multimodal correspondant lorsqu’il est disponible. La prise en charge des modèles, les templates et les flags CLI évoluent rapidement : épinglez donc une version connue et conservez la commande de lancement avec les résultats de l’évaluation.

Choisissez llama.cpp lorsque votre objectif est le contrôle direct, et non parce que « bas niveau » signifie automatiquement plus rapide. Un outil géré peut sélectionner de bons paramètres par défaut ; des flags directs peuvent également dégrader les performances.

MLX-LM : développement en Python natif sur Apple

MLX-LM s’appuie sur le framework de tableaux MLX d’Apple. Il prend en charge la génération, le chat, la conversion, la quantification et le fine-tuning efficace en paramètres pour les modèles compatibles.

MODEL=mlx-community/Llama-3.2-3B-Instruct-4bit
uv add mlx-lm
uv run mlx_lm.generate \
    --model "$MODEL" \
    --prompt "Explain Metal acceleration in one paragraph."

Python expose directement le modèle et le tokenizer :

from mlx_lm import generate, load

MODEL = "mlx-community/Llama-3.2-3B-Instruct-4bit"

model, tokenizer = load(MODEL)
messages = [{"role": "user", "content": "Give one local-LLM benchmark rule."}]
prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)
print(generate(model, tokenizer, prompt=prompt, max_tokens=80))

Le serveur HTTP de MLX-LM est documenté comme un serveur de développement doté de contrôles de sécurité élémentaires, et non comme un service de production. Utilisez-le pour l’expérimentation locale ou placez devant lui une boundary applicative examinée.

Un benchmark équitable demande moins de temps qu’un mauvais téléchargement

Testez la même famille de checkpoints et une quantification comparable lorsque les formats le permettent. Utilisez un petit ensemble de prompts comprenant :

• un prompt interactif court
• un prompt long proche du contexte visé
• des structured outputs ou des tool calls si l’application en a besoin
• une longueur de génération représentative
• une requête répétée pour distinguer le chargement à froid de l’inférence à chaud

Consignez :

Ne comparez pas le modèle en 4 bits d’un outil avec le modèle en pleine précision d’un autre outil en attribuant la différence au runtime.

Liste de contrôle sécurité et confidentialité

1. Liez les APIs à l’interface loopback, sauf si l’accès réseau est nécessaire.
2. Si l’accès LAN est nécessaire, utilisez un pare-feu sur l’hôte ainsi que l’authentification documentée par l’outil ou un reverse proxy authentifié devant le service. La prise en charge des API tokens dépend de l’outil : LM Studio documente les API tokens, tandis que le chemin d’exposition documenté d’Ollama utilise la liaison de l’hôte et le proxying.
3. Traitez les fichiers de modèles comme des artefacts tiers ; consignez leur source, leur révision, leur licence et leur hash.
4. Évitez d’exécuter du code personnalisé non vérifié provenant des modèles.
5. Vérifiez si les fonctionnalités optionnelles liées aux documents, aux outils, aux mises à jour ou à l’analytics effectuent des appels réseau.
6. Ne supposez pas que la génération locale rend sûrs les documents récupérés, les logs ou les effets de bord des outils.

Points clés à retenir

1. Choisissez d’abord la frontière du workflow : service géré, développement desktop et headless, contrôle direct de GGUF ou Python natif sur Apple.
2. Ollama et LM Studio exposent tous deux des APIs locales. Comparez le contrôle du cycle de vie, les SDKs, les structured outputs, les outils et la visibilité du runtime.
3. Les poids du modèle ne représentent qu’une partie du budget mémoire. Incluez le KV cache, l’espace de travail, les composants multimodaux, l’application et la marge nécessaire à macOS.
4. L’inférence locale n’est pas automatiquement hors ligne ni privée. Vérifiez les appels réseau, la liaison, l’authentification, les artefacts, les logs et les effets de bord des outils.
5. Évaluez la même tâche, la même famille de checkpoints, le même contexte et une quantification comparable avant d’attribuer un résultat au runtime.

Références

• Documentation et code source d’Ollama
• Documentation développeur de LM Studio et SDK Python
• Documentation et code source de llama.cpp
• Documentation et code source de MLX-LM
• Documentation MLX d’Apple