Exécuter des LLMs locaux — Qwen3-Coder, DeepSeek, MLX et Apple Silicon
Un guide pratique pour exécuter des modèles de langage puissants localement sur Apple Silicon — sélection de modèles, MLX vs Ollama, compromis de quantification et quand le local bat le cloud.
Exécuter des LLMs locaux sur Apple Silicon
La capacité d’exécuter des modèles de langage performants en local a atteint un point d’inflexion. Avec l’architecture de mémoire unifiée d’Apple Silicon et des frameworks comme MLX et Ollama, des modèles qui auraient nécessité un data center il y a cinq ans tournent maintenant sur un laptop. Voici ma configuration, ce que j’ai appris, et des conseils pratiques pour démarrer.
Pourquoi le local ?
Il y a trois raisons convaincantes d’exécuter des modèles localement plutôt qu’exclusivement via des API cloud :
Confidentialité : Traitez du code sensible, des documents propriétaires et des données clients sans rien envoyer hors de votre machine. Ce n’est pas théorique — si vous travaillez avec des données réglementées, du code client ou de la logique métier interne, l’inférence locale élimine complètement la question du traitement des données.
Latence et disponibilité : Pas de dépendance réseau, pas de limites de débit, des réponses instantanées même dans un avion. Les modèles locaux répondent en millisecondes pour l’autocomplétion et en secondes pour la génération plus longue. Pas de file d’attente, pas de panne d’API et pas de “vous avez dépassé votre limite de débit” à 2h du matin.
Coût : Après l’investissement matériel, l’inférence est essentiellement gratuite. Si vous exécutez des centaines de requêtes par jour pour l’autocomplétion, l’explication de code et des tâches rapides, les coûts d’API cloud s’accumulent. L’inférence locale s’amortit à presque zéro dans le temps.
Le compromis est clair : les modèles locaux sont plus petits et moins performants que les modèles frontière cloud. Vous échangez de l’intelligence brute contre la confidentialité, la vitesse et le coût. L’art est de savoir quelles requêtes nécessitent une capacité frontière et lesquelles sont bien servies par un modèle local de 14B ou 32B paramètres.
Ma configuration matérielle
Mac Studio M2 Ultra (192 Go de mémoire unifiée) : Ma machine d’inférence locale principale. L’énorme mémoire unifiée est la clé — elle permet d’exécuter des modèles de plus de 70B paramètres en pleine qualité, ou plusieurs modèles plus petits simultanément. La bande passante mémoire du M2 Ultra (~800 Go/s) détermine directement la vitesse de génération de tokens pour les LLMs.
MacBook Pro M4 Pro (48 Go) : Ma configuration portable. Exécute confortablement des modèles 14B, des modèles 32B en quantification Q4. Suffisant pour l’autocomplétion de code et les requêtes rapides en déplacement.
Pourquoi Apple Silicon : L’architecture de mémoire unifiée signifie que GPU et CPU partagent le même pool de mémoire. Un modèle 70B en Q4 nécessite environ 40 Go de mémoire — sur une configuration GPU discrète, il faudrait plusieurs cartes NVIDIA. Sur un Mac Studio avec 192 Go de mémoire unifiée, ça fonctionne simplement. La bande passante mémoire est inférieure à celle des GPU dédiés, mais la capacité totale et la facilité d’utilisation sont inégalées pour l’inférence locale.
Stack logiciel
MLX (framework ML d’Apple)
MLX est le framework de machine learning d’Apple, conçu spécifiquement pour Apple Silicon. C’est devenu le moyen le plus rapide d’exécuter des modèles localement sur Mac.
# Installer MLX et le module LM
pip install mlx mlx-lm
# Exécuter un modèle directement
mlx_lm.generate --model mlx-community/Qwen3-Coder-8B-4bit \
--prompt "Write a Python function that validates an email address"
# Démarrer un serveur local (API compatible OpenAI)
mlx_lm.server --model mlx-community/Qwen3-Coder-8B-4bit --port 8080Avantages clés : Optimisation native Apple Silicon, évaluation paresseuse (ne calcule que ce qui est nécessaire), la mlx-community sur Hugging Face fournit des poids de modèles pré-convertis pour éviter la conversion.
Ollama
Ollama est le moyen le plus simple de démarrer avec les modèles locaux. Point final.
# Installation
brew install ollama
# Exécuter un modèle (téléchargement automatique au premier usage)
ollama run qwen3-coder
ollama run deepseek-r1:14b
ollama run llama4-scout
# Accès API (compatible OpenAI)
curl http://localhost:11434/v1/chat/completions \
-d '{"model": "qwen3-coder", "messages": [{"role": "user", "content": "Hello"}]}'Avantages clés : Configuration ultra-simple, gestion automatique des modèles, API compatible OpenAI intégrée, fonctionne avec la plupart des outils IA (Cursor, Continue.dev, Cline) prêt à l’emploi.
llama.cpp
Le moteur d’inférence fondamental qui a rendu la révolution des LLMs locaux possible. La plupart des autres outils (y compris Ollama) s’appuient dessus. L’utilisation directe vous donne le plus de contrôle :
# Build depuis les sources pour la performance maximale
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j
# Exécuter un modèle GGUF
./llama-cli -m ~/models/qwen3-coder-14b-q5_k_m.gguf \
-p "Explain the three-tier AI architecture pattern" \
-n 512 --temp 0.7Quand utiliser llama.cpp directement : Quand vous avez besoin du contrôle maximum sur les paramètres d’inférence, pour du benchmarking, ou pour construire des pipelines d’inférence personnalisés.
Guide de sélection de modèles
Pour les tâches de code
| Modèle | Paramètres | Mémoire (Q4) | Vitesse | Qualité | Notes |
|---|---|---|---|---|---|
| Qwen3-Coder 8B | 8B | ~5 Go | Rapide | Bon | Mon défaut pour l’autocomplétion. Assez rapide pour les suggestions inline. |
| Qwen3-Coder 14B | 14B | ~9 Go | Bon | Très bon | Sweet spot pour la génération de code sur machines 48 Go. |
| Qwen3-Coder 32B | 32B | ~20 Go | Modéré | Excellent | Forte compréhension du code, tourne bien sur 48 Go+. |
| DeepSeek-Coder V3 16B | 16B | ~10 Go | Bon | Très bon | Excellent pour le raisonnement complexe sur du code. |
| Codestral 22B | 22B | ~14 Go | Bon | Très bon | Modèle de code de Mistral, fort support multilingue. |
Pour les tâches générales
| Modèle | Paramètres | Mémoire (Q4) | Vitesse | Qualité | Notes |
|---|---|---|---|---|---|
| Llama 4 Scout | 17B actif (MoE) | ~12 Go | Bon | Très bon | Le dernier de Meta, forte capacité générale. |
| Qwen3 14B | 14B | ~9 Go | Bon | Très bon | Excellent multilingue (y compris l’allemand). |
| DeepSeek R1 14B | 14B | ~9 Go | Modéré | Excellent | Modèle de raisonnement — réfléchit avant de répondre. Plus lent mais bien plus performant pour les tâches complexes. |
| Gemma 3 12B | 12B | ~8 Go | Rapide | Bon | Modèle ouvert de Google, bon pour les tâches générales. |
| Mistral Small 24B | 24B | ~15 Go | Modéré | Très bon | Fort support des langues européennes. |
Pour le raisonnement
| Modèle | Paramètres | Mémoire (Q4) | Notes |
|---|---|---|---|
| DeepSeek R1 14B | 14B | ~9 Go | Meilleur modèle de raisonnement à cette taille. La chaîne de pensée est intégrée. |
| DeepSeek R1 32B | 32B | ~20 Go | Raisonnement significativement plus fort. Vaut la mémoire si vous en avez. |
| QwQ 32B | 32B | ~20 Go | Modèle de raisonnement d’Alibaba. Compétitif avec R1 sur beaucoup de benchmarks. |
Comprendre la quantification
La quantification réduit la précision du modèle pour tenir dans moins de mémoire. Le compromis est qualité vs. utilisation mémoire :
| Quantification | Perte de qualité | Réduction mémoire | Quand l’utiliser |
|---|---|---|---|
| Q8 | Négligeable | ~50% du FP16 | Quand vous avez beaucoup de mémoire. Plus proche de la qualité originale. |
| Q6_K | Minimale | ~40% du FP16 | Bon équilibre pour machines à grande mémoire. |
| Q5_K_M | Faible | ~35% du FP16 | Mon défaut. Meilleur ratio qualité/mémoire. |
| Q4_K_M | Notable sur les tâches complexes | ~25% du FP16 | Quand la mémoire est limitée. Encore très utilisable. |
| Q3_K | Significative | ~20% du FP16 | Uniquement quand vous devez faire tenir un modèle plus grand. |
Règle empirique : Utilisez le niveau de quantification le plus élevé qui tient dans votre mémoire disponible avec environ 5 Go de marge pour l’OS et les autres applications.
Intégration avec les outils de développement
Cursor
Cursor supporte les modèles locaux via ses paramètres d’API compatible OpenAI :
- Démarrez Ollama :
ollama serve - Dans Cursor Settings > Models > OpenAI API Base :
http://localhost:11434/v1 - Ajoutez le nom du modèle :
qwen3-coder - Utilisez pour l’autocomplétion ; gardez les modèles cloud pour les tâches agent complexes
Continue.dev
Continue.dev a un support Ollama de première classe :
// ~/.continue/config.json
{
"models": [
{
"title": "Qwen3-Coder (Local)",
"provider": "ollama",
"model": "qwen3-coder"
}
],
"tabAutocompleteModel": {
"title": "Qwen3-Coder 8B",
"provider": "ollama",
"model": "qwen3-coder:8b"
}
}Cline
Cline supporte les modèles Ollama comme backend. Configurez dans les paramètres de l’extension avec l’endpoint de l’API Ollama. Fonctionne bien pour les petites tâches ; pour les éditions multi-fichiers complexes, les modèles cloud (Claude) sont toujours plus performants.
Optimisation des performances
Gestion de la mémoire
# Vérifier la mémoire disponible
sysctl hw.memsize
# Surveiller pendant l'inférence
# Activity Monitor > Memory tab > Memory Pressure (doit rester vert)
# Pour Ollama : contrôler combien de modèles restent chargés
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4Longueur de contexte vs. vitesse
Des fenêtres de contexte plus longues utilisent plus de mémoire et ralentissent l’inférence. Pour les modèles locaux :
- Contexte 4K : Rapide, bon pour l’autocomplétion et les requêtes courtes
- Contexte 8K : Standard, bon équilibre pour la plupart des tâches
- Contexte 16K-32K : Lent sur le matériel local, à utiliser uniquement quand vous devez traiter des documents plus longs
- Contexte 128K+ : Impraticable localement sauf sur des machines à très grande mémoire. Utilisez les modèles cloud.
Traitement par lots
Pour des tâches comme le traitement de multiples fichiers ou la génération de documentation à travers une codebase, envoyez des requêtes par lots à l’API locale plutôt qu’une par une :
import mlx_lm
# Charger le modèle une fois, exécuter de nombreuses inférences
model, tokenizer = mlx_lm.load("mlx-community/Qwen3-Coder-14B-4bit")
for file_content in files:
result = mlx_lm.generate(
model, tokenizer,
prompt=f"Add docstrings to this code:\n{file_content}",
max_tokens=2048
)Quand le local bat le cloud
| Cas d’usage | Local | Cloud | Gagnant |
|---|---|---|---|
| Autocomplétion de code | Rapide, gratuit, privé | Légère latence, coût par token | Local |
| Explications de code rapides | Instantané, hors ligne | Meilleure qualité | Local |
| Refactoring multi-fichiers complexe | Limité par la taille du modèle | Les modèles frontière excellent | Cloud |
| Traitement de code sensible | Aucune donnée ne quitte la machine | Données envoyées au fournisseur | Local |
| Développement hors ligne (voyage, avion) | Toujours disponible | Nécessite internet | Local |
| Traitement par lots en volume | Gratuit après le matériel | $$$$ à grande échelle | Local |
| Décisions d’architecture nouvelles | Raisonnement plus faible | Raisonnement frontière | Cloud |
| Analyse de long contexte (>32K tokens) | Très lent, gourmand en mémoire | Gère nativement | Cloud |
L’approche hybride
La meilleure configuration utilise les deux. Mon routage :
- Local (Qwen3-Coder via Ollama/MLX) : Autocomplétion, questions rapides, explications de code, refactoring simple, génération de documentation, travail hors ligne, code sensible
- Cloud (Claude Opus via Claude Code) : Implémentation de fonctionnalités complexes, décisions d’architecture, refactors multi-fichiers, tout ce qui nécessite un raisonnement profond ou un long contexte
- Cloud (Claude Sonnet via Cursor) : Tâches de complexité moyenne, revue de code, implémentation de composants UI
Les économies de coûts sont réelles. J’estime que l’inférence locale gère 60-70% de mes requêtes IA quotidiennes en volume, et celles-ci coûteraient 50-100 $/mois en frais d’API. Le Mac Studio s’est rentabilisé dès la première année rien qu’en coûts d’API économisés — et c’est sans compter les avantages de confidentialité et de disponibilité.
Pour démarrer
Si vous êtes nouveau avec les LLMs locaux, voici le chemin le plus rapide :
- Installez Ollama :
brew install ollama - Téléchargez un modèle :
ollama pull qwen3-coder(ouollama pull deepseek-r1:14bpour le raisonnement) - Essayez :
ollama run qwen3-coder - Intégrez : Pointez votre IDE (Cursor, Continue.dev) vers
http://localhost:11434/v1 - Expérimentez : Essayez différents modèles et tailles pour vos cas d’usage spécifiques
Temps total jusqu’à la première inférence locale : environ 5 minutes plus le temps de téléchargement du modèle. Il n’y a jamais eu de barrière plus basse pour exécuter de l’IA puissante localement.