2025-05-10 · Mis à jour 2026-07-15

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

Exécution locale LLMs sous macOS : Ollama, LM Studio, llama.cpp, MLX et Apple Silicon

De nombreux outils du quotidien prompts n’ont pas besoin d’un API distant. Apple Silicon permet d’exécuter des modèles de langage utiles en local, car le CPU et le GPU partagent un pool mémoire unifié, même si le fichier du modèle ne représente qu’une partie du budget mémoire disponible.

Le choix principal dans ce guide concerne l’outil qui accompagne le modèle. Ollama, LM Studio, llama.cpp et MLX-LM présentent des fonctionnalités similaires, mais ils offrent des niveaux de contrôle différents : un service local géré, une interface de développement desktop, une exécution directe GGUF, ou bien l’utilisation du Python natif d’Apple. Optez d’abord pour le modèle en fonction de la qualité attendue du résultat, puis choisissez l’outil en fonction de l’interface et des formats de sortie nécessaires.

En résumé. Utilisez Ollama pour obtenir un service local géré, LM Studio pour explorer les modèles sur poste de travail ainsi que son APIs, llama.cpp afin d’exercer un contrôle direct sur l’exécution de GGUF, et MLX-LM pour effectuer des expérimentations en Python adaptées aux systèmes Apple. Aucun de ces outils n’est systématiquement le plus rapide, en fonction du Benchmark précis du modèle, de la quantification, du contexte, de la charge de travail et de la marge mémoire disponible.

Commencer par une enveloppe mémoire

La taille des poids quantisés bruts ne représente que le premier terme :

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

La longueur du contexte, le type de mémoire de cache, le nombre de requêtes en parallèle ainsi que l’architecture du modèle influencent les résultats. Un modèle 7B ou 8B à quatre bits, bien qu’il soit considéré comme « nominal », peut encore poser des problèmes sur un Mac équipé de 8 Go de mémoire, car le système d’exploitation n’est pas en mesure de fournir à runtime toute la mémoire installée.

Utilisez le Activity Monitor ou les métriques propres au runtime lors des tests. Préservez suffisamment de marge pour éviter toute pression sur la mémoire ainsi que tout recours au swap ; un modèle qui se charge mais force le système à utiliser constamment le swap n’est pas adapté à un usage interactif.

Il convient également de distinguer l’inférence locale de l’exécution hors ligne. Prompts peut rester sur la machine tandis que l’application continue d’accéder au réseau afin de télécharger des modèles, de recevoir des mises à jour ou d’utiliser des fonctionnalités optionnelles. Téléchargez d’abord les artefacts nécessaires, déconnectez-vous du réseau, puis validez le flux de travail si une exécution hors ligne est requise.

Ces quatre outils résolvent des problématiques de flux de travail distinctes

Il s’agit d’un tableau des responsabilités, et non d’un classement par vitesse. Plusieurs outils peuvent utiliser des noyaux ou des formats similaires, et les performances varient en fonction du support des modèles ainsi que des versions mises à disposition.

Ollama : service local géré

Ollama Il gère les téléchargements de modèles, les templates, le cycle de vie des processus, ainsi qu’un serveur local API. Il s’avère utile lorsque le code d’une application doit faire appel à un service local stable plutôt qu’à ses propres paramètres d’inférence.

ollama pull <model>
ollama run <model>

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

Vérifiez le manifeste du modèle ainsi que la configuration du contexte, plutôt que de supposer qu’un nom de bibliothèque court correspond à un checkpoint immuable. Identifiez ou enregistrez l’artefact exact afin de pouvoir effectuer des évaluations.

Ollama sacrifie une certaine visibilité au niveau bas pour offrir plus de simplicité dans la gestion du cycle de vie des applications. Recourez à llama.cpp ou à un autre runtime lorsque vous devez gérer directement un fichier GGUF, un modèle de chat, une configuration de cache, ou une nouvelle fonctionnalité backend.

LM Studio : exploration en environnement de bureau et APIs local

LM Studio Il s’avère particulièrement utile lorsque la découverte de modèles, la charge des configurations, l’inspection des conversations ainsi que l’évaluation humaine côte à côte doivent faire partie d’un même flux de travail desktop. Son serveur prend en charge les SDKs natifs ainsi que des points d’entrée de compatibilité.

L’utilisation actuelle de Python SDK se présente comme suit :

import lmstudio as lms


with lms.Client() as client:
    model = client.llm.model("<downloaded-model-key>")
    response = model.respond("Write one sentence about local inference.")
    print(response)

Démarrer le API local depuis l’onglet Développeur ou avec :

lms server start

LM Studio peut fonctionner sur localhost ou au sein d’un réseau local et prend en charge les tokens API. Il convient de le faire fonctionner en mode loopback sauf si l’accès distant est expressément requis ; en effet, le bind réseau transforme un modèle destiné à un usage local en un service qui nécessite une authentification, des règles de pare-feu ainsi qu’une configuration adéquate des outils.

llama.cpp : exécution directe de GGUF

llama.cpp Il s’agit du chemin de référence lorsque l’artefact est GGUF et que l’on souhaite visualiser directement la frontière runtime. Il prend en charge Apple Metal ainsi que CPU et d’autres backends matériels.

brew install llama.cpp

# Download through the Hugging Face integration and select a quantization.
llama-cli -hf <publisher>/<gguf-repository>:Q4_K_M

# Or start an OpenAI-compatible local server.
llama-server -hf <publisher>/<gguf-repository>:Q4_K_M

l’état actuel du répertoire -hf Le chemin peut télécharger un projecteur multimodal correspondant lorsqu’il est disponible. La compatibilité des modèles, les templates ainsi que les paramètres de la ligne de commande évoluent rapidement ; il est donc recommandé de fixer une version connue et de conserver la commande de lancement accompagnée du fichier de suivi d’évaluation.

Choisissez llama.cpp lorsque le contrôle direct est l’objectif, et non parce que le niveau « inférieur » implique automatiquement une plus grande vitesse. Un outil géré peut proposer de bons paramètres par défaut ; en revanche, l’utilisation de flags directs peut également entraîner une dégradation des performances.

MLX-LM : Développement en Python natif d’Apple

MLX-LM Il s’appuie sur le tableau MLX d’Apple framework. Il prend en charge la génération, les conversations, la conversion, la quantification, ainsi que des méthodes de fine-tuning efficaces en termes de paramètres pour les modèles compatibles.

uv add mlx-lm
uv run mlx_lm.generate \
    --model mlx-community/<compatible-model> \
    --prompt "Explain Metal acceleration in one paragraph."

Python expose directement le modèle et le tokenizer :

from mlx_lm import generate, load


model, tokenizer = load("mlx-community/<compatible-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 décrit comme un serveur de développement disposant de vérifications de sécurité de base, et non comme un service en production. Utilisez-le pour des expérimentations locales ou placez une couche de contrôle d’accès validée devant lui.

Un téléchargement équitable benchmark prend moins de temps qu’un téléchargement défectueux

Testez la même famille checkpoint ainsi que des méthodes de quantification comparables, dans la mesure où les formats le permettent. Utilisez un petit ensemble prompt comprenant :

• un prompt interactif de courte durée
• un prompt de longue durée situé à proximité du contexte cible
• structured output ou tool calls si l’application en a besoin
• une longueur de génération représentative
• une demande répétée afin de distinguer la charge initiale de l’inférence en mode chaud

Enregistrement :

Il ne faut pas comparer un modèle à 4 bits d’une outil avec un modèle à précision pleine d’un autre outil, et attribuer cette différence au runtime.

Checklist de sécurité et de confidentialité

1. Associez APIs à un routage boucle locale sauf si un accès réseau est requis.
2. Ajoutez une authentification avant de rendre le réseau local accessible.
3. Traitez les fichiers de modèle comme des artefacts provenant de tiers ; enregistrez l’origine, la version, la licence ainsi que l’hash correspondant.
4. Évitez d’exécuter du code de modèle personnalisé non examiné.
5. Vérifiez si les fonctionnalités optionnelles liées aux documents, outils, mises à jour ou analyses effectuent des appels réseau.
6. Ne supposez pas que la génération locale rend les documents récupérés, les journaux ou les effets secondaires des outils sûrs.

Conclusion

Le choix pertinent n’est pas l’« meilleure application Mac LLM », mais plutôt la pile la plus légère capable de fournir l’interface de contrôle requise par votre flux de travail. Ollama gère un service, LM Studio gère un cycle d’exploration en environnement de bureau, llama.cpp permet l’exécution de GGUF, tandis que MLX-LM offre un interpréteur Python natif d’Apple.

Attribuez à chaque candidat la même tâche, le même contexte ainsi que le même volume de mémoire alloué. Ce procédé produit des résultats plus fiables que les croyances populaires liées au matériel ou une table de notation statique, et il est facile de y revenir lorsque les outils évoluent.

Références

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