Tirer le max d'un Mac Apple Silicon

#Optimiser un LLM sur Apple Silicon : les quatre leviers

Pour tirer le maximum d'un Mac Apple Silicon, quatre leviers comptent, dans cet ordre : la limite de mémoire que macOS laisse au GPU, la taille et la quantification du modèle, le cache KV et l'attention flash pour les longs contextes, et le choix du moteur (Ollama, llama.cpp, MLX ou LM Studio). Tout part d'un fait : la mémoire unifiée est partagée entre CPU et GPU, donc la RAM totale sert de VRAM, mais macOS plafonne la part que le GPU peut câbler. Relever ce plafond ouvre des modèles plus gros ; les autres leviers évitent de saturer la mémoire ou de ralentir la génération. Aucun ne rend la machine plus rapide que sa bande passante ne le permet.

Mémoire unifiée

Le CPU et le GPU lisent les mêmes données sans copie. MLX le résume ainsi : les tableaux vivent dans une mémoire partagée. Un Mac de 64 Go peut donc charger un modèle qu'aucune carte graphique grand public de 24 ou 32 Go ne contient.

Efficacité

Un Mac consomme beaucoup moins qu'un PC équipé d'une carte haut de gamme, dont la puissance dépasse 500 W chez NVIDIA pour la RTX 5090 : le Mac reste silencieux et peu gourmand sur des usages légers.

Écosystème

Le dépôt llama.cpp décrit Apple silicon comme un citoyen de première classe, optimisé via ARM NEON, Accelerate et Metal. Ollama, LM Studio et MLX exploitent aussi Metal.

Limites

Pas de CUDA, donc les bibliothèques qui l'exigent ne tournent pas ; la bande passante d'un Mac (jusqu'à 546 Go/s sur un M4 Max) reste en dessous de celle d'une carte graphique haut de gamme ; le fine-tuning est possible mais plus lent.

#VRAM d'un Mac : la limite de mémoire GPU et iogpu.wired_limit_mb

Sur un Mac, il n'y a pas de VRAM séparée : la « VRAM » est une part de la mémoire unifiée que macOS accepte de câbler pour le GPU. Cette part est inférieure à la RAM totale. Les sources publiques ne s'accordent pas sur la fraction par défaut, entre deux tiers et trois quarts selon les cas ; ne la présumez pas, lisez-la sur votre machine. MLX expose la valeur retenue par le système via device_info(), champ max_recommended_working_set_size, et la documentation MLX indique qu'on peut relever cette limite système avec sudo sysctl iogpu.wired_limit_mb suivi de la taille en mégaoctets.

Le dépôt mlx-lm donne la règle de prudence : la valeur doit dépasser la taille du modèle en mégaoctets, mais rester inférieure à la mémoire de la machine. Apple ne documente pas ce réglage comme un paramètre grand public : traitez-le comme une modification système à risque.

La formule est simple : valeur en Mo = mémoire visée en Go × 1 024. La réserve est un choix de prudence de ce guide, pas une donnée d'Apple : elle dépend des applications que vous laissez ouvertes. Si la machine ralentit, écrit sur le disque ou devient instable, réduisez la valeur.

Pour lire la limite que macOS retient réellement, une ligne de Python suffit si le paquet mlx est installé. La sortie contient le champ max_recommended_working_set_size, exprimé en octets : divisez par 1 073 741 824 pour obtenir des gigaoctets. Comparez ce chiffre à la taille de votre modèle avant de toucher au moindre réglage : si le modèle tient déjà dessous, relever la limite n'apporte rien.

python3 -c "import mlx.core as mx; print(mx.device_info())"

1. 01
   Lire la valeur actuelle

   Dans le Terminal, la commande sysctl iogpu.wired_limit_mb affiche la valeur. Un zéro signale généralement que macOS applique son plafond par défaut.
2. 02
   Calculer la nouvelle valeur

   Prenez la taille du modèle plus son cache KV, ajoutez de la marge, puis laissez au système une réserve d'au moins 5 Go. Convertissez en mégaoctets.
3. 03
   Appliquer le réglage

   Lancez sudo sysctl iogpu.wired_limit_mb avec la valeur voulue. Il agit sans redémarrage, d'après les guides publiés.
4. 04
   Vérifier

   Relancez le modèle : les journaux d'Ollama ou de llama.cpp indiquent la mémoire de travail recommandée ; avec MLX, relisez device_info(). Surveillez la pression mémoire dans le Moniteur d'activité.
5. 05
   Revenir en arrière

   Remettez la valeur à 0 pour rendre la main au système, ou redémarrez : le réglage ne survit pas forcément à un redémarrage, contrôlez-le avec sysctl.

# Lire la valeur actuelle (0 = plafond par défaut du système)
sysctl iogpu.wired_limit_mb

# Exemple : 24 Go au GPU sur un Mac de 32 Go (24 x 1024)
sudo sysctl iogpu.wired_limit_mb=24576

# Retour au comportement par défaut
sudo sysctl iogpu.wired_limit_mb=0

#Quels modèles selon la mémoire du Mac

Le poids d'un modèle en Q4 suit les repères du site : 3B environ 2 Go, 7-8B environ 5 Go, 14B environ 9 Go, 32B environ 19 à 20 Go, 70B environ 40 Go. À ce poids s'ajoutent le cache KV et la marge du système. Le tableau croise ces repères avec la mémoire du Mac, avant et après relèvement de la limite GPU.

La vitesse maximale se calcule avec la bande passante de la puce : bande passante divisée par le poids en gigaoctets. Elle est indiquée dans la fiche de chaque machine : voir les guides MacBook Air, MacBook Pro, Mac mini et Mac Studio, qui possèdent chacun les chiffres de leur puce.

Cas concret : sur un Mac de 32 Go, un modèle de 32 milliards de paramètres en Q4 pèse environ 19 à 20 Go. Avec un contexte de 8 000 tokens et un cache KV en f16, il faut compter quelques gigaoctets de plus, soit environ 23 à 24 Go. Si le plafond GPU par défaut est plus bas, une partie du modèle bascule sur le CPU et la vitesse chute : relever la limite à 24 ou 26 Go règle le problème, à condition de laisser au système de quoi respirer. Si la pression mémoire passe au rouge, choisissez plutôt un modèle de 24 milliards.

#Quantification : pourquoi Q4 reste le bon défaut sur Mac

Sur un Mac, la génération est limitée par la bande passante mémoire : un modèle plus petit se lit plus vite. Q4_K_M reste donc le choix par défaut, avec le meilleur rapport entre taille, vitesse et qualité. Q5_K_M et Q6_K coûtent quelques pourcents de vitesse pour un gain de qualité modeste ; Q8_0 double presque le poids de Q4 et donc divise à peu près par deux le plafond de vitesse. Les formats MLX 4 bits jouent le même rôle dans l'écosystème MLX. Le guide sur la quantification détaille le compromis, sans qu'il faille en répéter les chiffres ici.

#Metal et attention flash

Les moteurs courants exploitent le GPU du Mac via Metal, sans réglage. Avec Ollama, la commande ollama ps indique si le modèle est chargé sur le GPU. L'attention flash réduit la mémoire prise par les longs contextes : Ollama l'active automatiquement quand le moteur et le matériel le permettent, et la variable OLLAMA_FLASH_ATTENTION=1 la force. Dans llama.cpp, l'option -fa accepte on, off ou auto, avec auto comme valeur par défaut ; l'option -ngl fixe le nombre de couches placées sur le GPU.

# Ollama : forcer l'attention flash
export OLLAMA_FLASH_ATTENTION=1
ollama serve

# llama.cpp : toutes les couches sur le GPU, attention flash active
llama-server -m modele.gguf -ngl all -fa on -c 16384

#Cache KV : la part de mémoire qu'on oublie

Le cache KV stocke, pour chaque token du contexte, des vecteurs de chaque couche. Sa taille est deux fois le nombre de couches, fois le nombre de têtes KV, fois leur dimension, fois le contexte, fois les octets par valeur. Exemple purement arithmétique, avec une architecture type de 32 couches, 8 têtes KV de dimension 128 et un contexte de 32 000 tokens en f16 : 2 × 32 × 8 × 128 × 32 000 × 2 octets, soit environ 4,2 Go, en plus des poids. En q8_0, ce cache tombe à peu près à la moitié ; en q4_0 à peu près au quart, avec une légère perte de précision.

Ollama quantifie le cache avec la variable OLLAMA_KV_CACHE_TYPE (f16 par défaut) ; llama.cpp le fait avec l'option -ctk pour les clés et -ctv pour les valeurs. Sur un Mac de 32 Go qui alloue 24 Go au GPU, quelques gigaoctets de cache économisés séparent un contexte qui ne rentre pas d'un contexte confortable. Ollama choisit aussi le contexte par défaut selon la mémoire : 4 000 tokens sous 24 Gio.

# Ollama
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve

# llama.cpp
llama-server -m modele.gguf -ngl all -fa on -ctk q8_0 -ctv q8_0 -c 32768

#Ollama, LM Studio, llama.cpp ou MLX

Le dépôt mlx-lm présente le paquet comme un outil de génération de texte et de fine-tuning de modèles sur Apple silicon, avec prise en charge des modèles quantifiés. Pour la comparaison des vitesses entre MLX et llama.cpp, le guide dédié fait référence ; cette page se limite aux réglages communs.

#Batterie et mode économie d'énergie

Sur un MacBook, une génération continue sollicite le GPU en permanence : l'autonomie tombe bien en dessous de celle de la navigation web annoncée par Apple. Cette page ne donne pas de durée précise, faute de source ; elle dépend du modèle et de la charge. Le mode économie d'énergie de macOS réduit les performances : réservez-le aux déplacements où l'autonomie prime sur la vitesse, et branchez la machine pour toute session longue.

• MLX contre llama.cpp : comparatif des vitesses
• MacBook Pro M4 Pro et Max
• Mac Studio : jusqu'à 512 Go
• Compiler llama.cpp avec Metal
• Quantifier le cache KV
• Calculateur VRAM du site

• Source : dépôt mlx-lm (limite de mémoire câblée)
• Source : documentation MLX, set_wired_limit
• Source : FAQ Ollama, attention flash et cache KV
• Source : dépôt llama.cpp

#Questions fréquentes