Faire tourner une inférence LLM locale sur un Mac mini cloud : mémoire et quantification

La semaine dernière, un lecteur qui expérimente l'IA embarquée m'a posé une question : il voulait faire tourner Llama 3 8B et un modèle de code 13B, sa machine locale n'avait pas assez de mémoire, mais acheter un Mac Studio lui semblait risqué s'il ne l'exploitait pas pleinement — pouvait-il d'abord louer une instance cloud pour tester le bon calibre. C'est en réalité un scénario assez classique : cet article suit ce fil pour dérouler tout le processus de planification mémoire, de mise en place de l'environnement et de choix de la quantification pour faire tourner une inférence LLM locale sur un Mac mini cloud.

Pourquoi déduire le calibre du modèle à partir de la bande passante mémoire unifiée

Sur Apple Silicon, le CPU, le GPU et le Neural Engine partagent le même pool de mémoire unifiée : il n'y a aucun surcoût lié aux allers-retours entre VRAM et RAM, ce qui constitue un avantage naturel pour l'inférence. Mais cela signifie aussi que la capacité mémoire fixe directement le plafond de taille de modèle exécutable. Règle de conversion approximative : un modèle entraîné à l'origine en FP16 occupe, après quantification 4 bits, environ 0,55 à 0,6 fois son nombre de paramètres en Go, à quoi il faut ajouter le cache de contexte (KV cache) et le surcoût système.

Ce tableau n'est qu'un point de départ — la taille réellement exécutable dépend de si Xcode, un navigateur, etc. tournent en parallèle et consomment de la mémoire. Surveillez avec top la mémoire libre restante avant que le processus d'inférence ne plante, plutôt que d'enquêter seulement après un OOM.

Mise en place de l'environnement : llama.cpp ou MLX

Les deux voies ne s'excluent pas : on peut installer les deux sur la même machine et basculer selon la tâche.

llama.cpp : priorité à la polyvalence

brew install cmake
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_METAL=ON
cmake --build build --config Release -j
./build/bin/llama-cli -m models/llama-3-8b-q4_k_m.gguf \
  -p "Écris un exemple de code expliquant la récursivité" -n 256 --ctx-size 4096

-DGGML_METAL=ON est déterminant : c'est l'activation du backend Metal qui permet d'exploiter pleinement la puissance du GPU. Sans ce paramètre, on retombe sur une inférence purement CPU, plusieurs fois plus lente.

MLX : le framework natif d'Apple

python3 -m venv mlx-env
source mlx-env/bin/activate
pip install mlx-lm
mlx_lm.generate --model mlx-community/Llama-3-8B-Instruct-4bit \
  --prompt "Explique le rôle du KV cache" --max-tokens 256

Les modèles MLX hébergent directement les poids quantifiés sous l'espace de noms mlx-community : pas besoin de convertir soi-même le format, la prise en main est plus rapide qu'avec llama.cpp. En revanche, l'écosystème et la documentation communautaire restent pour l'instant plus riches côté llama.cpp.

Comment choisir le format de quantification

Plus bas n'est pas forcément meilleur — le choix dépend du type de tâche :

• Q4_K_M : suffisant pour les questions-réponses courantes et la complétion de code, c'est l'option qui économise le plus de mémoire et le choix par défaut dans la majorité des cas.
• Q5_K_M : pour les chaînes de raisonnement longues et les décisions logiques à plusieurs étapes, il vaut mieux monter à ce niveau, la stabilité des sorties est nettement meilleure.
• Q8_0 : proche de la précision d'origine, adapté aux scénarios d'évaluation exigeants en précision, mais l'occupation mémoire double — à envisager seulement si la mémoire est abondante (24 Go et plus).

Le critère est simple : testez d'abord avec Q4 sur un lot de questions réelles, vérifiez manuellement la qualité des réponses, et ne montez d'un niveau que si vous constatez des sauts logiques ou des erreurs numériques manifestes — inutile de partir directement sur la précision maximale et de saturer la mémoire.

Espace disque et gestion des snapshots

Les fichiers de modèles pèsent de quelques Go à plusieurs dizaines de Go — il faut anticiper le nettoyage avant la fin de la période de location :

1. Placez tous les modèles téléchargés dans ~/models/ pour pouvoir nettoyer ou migrer par dossier entier.
2. Vérifiez régulièrement l'occupation avec du -sh ~/models/* et supprimez rapidement les anciennes versions quantifiées pour éviter de saturer le disque système et de dégrader la vitesse d'inférence.
3. Si vous souhaitez conserver la configuration de l'environnement d'expérimentation (environnement virtuel, liste des poids téléchargés), compressez-la dans une archive tar et téléchargez-la en local avant l'expiration de la location — le disque système ne conserve aucune donnée après la fin du contrat.

du -sh ~/models/* | sort -rh | head -5
tar czf mlx-env-backup.tar.gz mlx-env models/*.json

Déroulé des tests et supervision

Pendant l'inférence, gardez une fenêtre de terminal ouverte pour surveiller l'utilisation des ressources — cela permet de détecter une pression mémoire à l'avance :

sudo powermetrics --samplers gpu_power -i 1000 -n 5

Observez le taux d'utilisation du GPU et la courbe de consommation : si elle reste élevée longtemps tout en restant lente à répondre, c'est généralement que la bande passante mémoire est saturée par le cache de contexte. Il faut alors soit réduire --ctx-size, soit passer à un palier de quantification plus léger, plutôt que d'augmenter aveuglément la taille du batch.

Questions fréquentes