De combien de mémoire Mac avez-vous besoin pour faire tourner des LLM en local ?
La mémoire unifiée détermine quels modèles peuvent être chargés. La bande passante détermine leur vitesse de réponse. Voici le calcul pour chaque Mac 2026, jusqu'au Mac Studio 512 Go.
Le nouveau Mac Studio d'Apple culmine à 512GB de mémoire unifiée. La presse le présente comme la possibilité de faire tourner des modèles de pointe sur un bureau. C'est globalement vrai, et c'est aussi la réponse à une question que la plupart des acheteurs de Mac ne se posent pas.
La question qu'ils se posent est plus étroite et plus utile : compte tenu de ce que je veux faire tourner, de combien de mémoire ai-je réellement besoin à l'achat ? La mémoire unifiée est soudée au package de la puce. Vous n'avez qu'une seule chance de répondre à cette question, au moment du paiement, pour toute la durée de vie de la machine.
La bonne nouvelle, c'est qu'il s'agit d'un calcul, pas d'une question d'opinion. Cet article fait ce calcul.
Points clés
- Deux chiffres décident de tout. La capacité mémoire détermine si un modèle peut être chargé, tout simplement. La bande passante mémoire détermine la vitesse à laquelle il génère du texte. Ces deux facteurs sont indépendants, et une machine peut être excellente sur l'un et faible sur l'autre.
- Estimez les poids comme paramètres × octets par paramètre. En quantification 4 bits, cela représente environ 0.55 octet par paramètre, donc un modèle 70B nécessite environ 38GB avant même de compter le contexte.
- macOS ne laisse pas le GPU utiliser toute votre RAM. Il existe un plafond non documenté contrôlé par
iogpu.wired_limit_mb. Sur un Mac de 32GB, vous n'obtenez pas 32GB pour le modèle. - Les chiffres phares d'Apple sur l'IA décrivent le traitement des prompts, pas la génération de texte. Ces deux phases ont des goulots d'étranglement différents. Lisez le libellé attentivement.
- La capacité du M5 Ultra n'a rien de nouveau. Le M3 Ultra proposait déjà 512GB en 2025. Ce qui a changé, c'est la bande passante : de 819GB/s à 1.2TB/s.
Les deux chiffres qui comptent
Presque toutes les mauvaises décisions d'achat d'un Mac pour l'IA viennent du fait de confondre ces deux notions en une seule.
La capacité est un mur. Si le modèle et son contexte ne tiennent pas en mémoire, il ne tourne pas. Il n'y a pas de dégradation progressive sur silicium Apple comme avec un GPU discret qui peut déborder vers la RAM système — sur un Mac, la mémoire unifiée est la RAM système, et une fois que vous dépassez ce que macOS accorde au GPU, soit le chargement échoue, soit vous retombez sur quelque chose de bien plus lent.
La bande passante est une limite de vitesse. Pour générer un seul token, un modèle dense doit lire l'intégralité de ses poids en mémoire. À chaque token. Cela signifie que le plafond théorique de la vitesse de génération est la bande passante mémoire divisée par la taille du modèle, et aucun nombre de cœurs GPU n'y change quoi que ce soit.
C'est pourquoi une machine peut contenir un modèle de 200GB et rester malgré tout inutilisable, et pourquoi un petit modèle sur une machine modeste peut sembler instantané.
Capacité : ce qui tient en mémoire
Les poids représentent le coût dominant, et ils sont prévisibles :
memory for weights ≈ parameters × bytes per parameter
Le nombre d'octets par paramètre dépend de la quantification :
| Précision | Octets par paramètre | Usage typique |
|---|---|---|
| FP16 / BF16 | 2.0 | Entraînement, fidélité maximale |
| 8 bits (Q8) | ~1.0 | Inférence quasi sans perte |
| 4 bits (Q4_K_M) | ~0.55 | Le choix pratique par défaut |
| 3 bits | ~0.42 | Perte de qualité perceptible |
Les K-quants 4 bits représentent en moyenne un peu plus de 4 bits une fois les métadonnées d'échelle incluses, ce qui explique pourquoi 0.55 est le chiffre honnête plutôt que 0.50. En l'appliquant :
| Taille du modèle | 4 bits | 8 bits | FP16 |
|---|---|---|---|
| 8B | 4.4 GB | 8 GB | 16 GB |
| 14B | 7.7 GB | 14 GB | 28 GB |
| 32B | 17.6 GB | 32 GB | 64 GB |
| 70B | 38.5 GB | 70 GB | 140 GB |
| 120B | 66 GB | 120 GB | 240 GB |
| 235B | 129 GB | 235 GB | — |
| 400B | 220 GB | 400 GB | — |
| 671B | 369 GB | 671 GB | — |
Ajoutez ensuite le contexte
Le cache KV conserve les clés et valeurs d'attention pour chaque token de la conversation, et il croît linéairement avec la longueur du contexte. Sa taille par token varie beaucoup selon l'architecture — les modèles utilisant la grouped-query attention sont bien plus économes ici que les conceptions plus anciennes — mais une fourchette réaliste se situe entre 0.1 MB et 0.5 MB par token.
Pour un contexte de 32,000 tokens, cela représente environ 3GB à 16GB en plus des poids. À 128,000 tokens, cela peut dépasser la taille du modèle lui-même.
C'est la raison la plus fréquente pour laquelle un modèle qui « devrait tenir » ne tient pas. Si vous prévoyez de lui fournir de longs documents ou de tenir de longues conversations, budgétez ce poste explicitement plutôt que de dimensionner sur les seuls poids en espérant que ça passe.
La règle pratique
memory you need ≈ (weights) + (KV cache for your context) + 2–3 GB overhead
Et ensuite, comparez ce résultat à ce que macOS vous accorde réellement, ce qui n'est pas le chiffre inscrit sur la boîte.
Le plafond dont personne ne parle
macOS réserve une partie de la mémoire unifiée pour le système et plafonne la quantité que le GPU peut « wire » (verrouiller en mémoire physique). Le réglage se fait via un sysctl :
$ sysctl iogpu.wired_limit_mb
iogpu.wired_limit_mb: 0
Zéro signifie automatique. Apple ne documente pas vers quoi ce mode automatique converge, et je ne vais pas inventer de formule — mais les mesures de la communauté situent systématiquement ce plafond autour de 65–75% de la mémoire totale, les machines plus grandes bénéficiant d'une part plus importante.
La conséquence pratique, sur les machines que vous pourriez acheter :
| Mémoire installée | Approximativement disponible pour le GPU |
|---|---|
| 16 GB | ~10–12 GB |
| 32 GB | ~21–24 GB |
| 64 GB | ~42–48 GB |
| 128 GB | ~85–96 GB |
| 512 GB | ~340–384 GB |
Vous pouvez l'augmenter. Le changement prend effet immédiatement et ne survit pas à un redémarrage :
# Allow the GPU to wire 28GB on a 32GB Mac
sudo sysctl iogpu.wired_limit_mb=28672
# Back to automatic
sudo sysctl iogpu.wired_limit_mb=0
Soyez prudent avec ce réglage. Tout ce que vous prenez, vous le prenez au système d'exploitation et à toutes les autres applications. Si vous poussez trop près de votre total, vous déclencherez du swap, des beachballs, ou un kill pour manque de mémoire — et sur un Mac avec un SSD rapide, le swap sous pression mémoire représente aussi une charge d'écriture soutenue. Si vous avez déjà vu la boîte de dialogue System has run out of application memory, voici l'une des façons d'y arriver.
Un plafond raisonnable est la mémoire totale moins 6–8GB pour macOS et vos autres applications. Réglez-le, lancez votre modèle, et surveillez la pression mémoire dans le Moniteur d'activité. Si vous constatez des pics de pression de façon générale, notre guide de gestion de la mémoire Mac couvre le diagnostic.

Bande passante : la vitesse de réponse
Voici l'estimation qui compte, et voici exactement ce qu'elle est :
tokens per second ≈ (memory bandwidth × efficiency) ÷ weight size in bytes
L'efficacité rend compte de l'écart entre la bande passante théorique maximale et ce qu'un moteur d'inférence obtient réellement — sur silicium Apple avec un runtime bien optimisé, cela se situe environ entre 0.6 et 0.8. J'utilise 0.7 ci-dessous.
Il s'agit d'estimations calculées à partir de chiffres de bande passante publiés, et non de benchmarks que j'ai réalisés moi-même. Considérez-les comme le bon ordre de grandeur et le bon classement relatif, pas comme des mesures. Les chiffres réels varient selon le runtime, la quantification, la longueur du contexte et le comportement thermique.
Vitesse de génération pour un modèle dense en 4 bits :
| M6 (170GB/s) | M5 Pro (307GB/s) | M5 Max (614GB/s) | M5 Ultra (1.2TB/s) | |
|---|---|---|---|---|
| 8B (4.4GB) | ~27 tok/s | ~49 tok/s | ~98 tok/s | ~190 tok/s |
| 32B (17.6GB) | ~7 tok/s | ~12 tok/s | ~24 tok/s | ~48 tok/s |
| 70B (38.5GB) | ne tient pas | ~6 tok/s | ~11 tok/s | ~22 tok/s |
| 120B (66GB) | ne tient pas | ne tient pas | ~7 tok/s | ~13 tok/s |
Pour référence : une vitesse de lecture confortable se situe autour de 10 tokens par seconde. En dessous d'environ 5, la plupart des gens arrêtent d'utiliser l'outil.
Regardez la ligne du 32B. C'est un seul et même modèle, qui passe de tout juste tolérable à véritablement rapide sur toute la gamme — sans que sa capacité à tenir en mémoire change. C'est la bande passante, pas la capacité, et c'est l'axe que les gens oublient quand ils achètent la machine la moins chère qui contient techniquement le modèle.
Pourquoi les modèles MoE changent la donne
Les modèles à mélange d'experts (mixture-of-experts, MoE) brisent la règle ci-dessus, et c'est bien pour cette raison qu'une machine à 512GB est intéressante.
Un modèle MoE stocke de nombreux sous-réseaux experts mais n'en active que quelques-uns par token. Un modèle 235B avec 22B de paramètres actifs doit contenir l'équivalent de 235B de poids, mais ne lit que l'équivalent d'environ 22B pour produire chaque token.
Donc :
- La capacité est régie par le nombre total de paramètres — 129GB en 4 bits.
- La vitesse est régie par les paramètres actifs — comme un modèle dense de 22B, soit environ 40 tok/s sur un M5 Ultra plutôt que les ~9 tok/s qu'obtiendrait un modèle dense 235B.
C'est cette asymétrie qui rend les grands modèles MoE utilisables sur silicium Apple d'une façon qu'ils ne le sont pas sur un GPU grand public : vous avez besoin de la capacité, qu'Apple vend d'une manière que personne d'autre ne propose à ce prix, et vous obtenez une vitesse proportionnelle à un modèle bien plus petit.
C'est aussi pourquoi affirmer que « 512GB fait tourner des modèles de pointe » est vrai mais incomplet. Cela fait tourner des modèles de pointe sparse à une vitesse utilisable. Un hypothétique modèle dense 400B en 4 bits occuperait 220GB et générerait environ 4 tokens par seconde sur un M5 Ultra. Il tient en mémoire. Vous n'apprécieriez pas l'expérience.
Le traitement des prompts est un problème différent
Lisez précisément les annonces d'Apple pour le nouveau Mac mini :
Jusqu'à 4.8x plus rapide pour le traitement des prompts LLM par rapport au M4 Jusqu'à 13.5x plus rapide pour le traitement des prompts LLM par rapport au M1
Le traitement des prompts — le prefill — est la phase où le modèle ingère ce que vous lui avez fourni. Chaque token de votre entrée est traité en parallèle, ce qui rend cette phase limitée par le calcul (compute-bound) : elle s'améliore avec le débit du GPU, avec les Neural Accelerators désormais intégrés à chaque cœur GPU, et sur le M6 avec le premier double Neural Engine qu'Apple ait jamais livré.
La génération de tokens — le decode — se fait un token à la fois, chacun nécessitant un passage complet sur les poids. Cette phase est limitée par la bande passante (bandwidth-bound), et aucune quantité de calcul supplémentaire n'y remédie.
Apple a choisi de mettre en avant la moitié limitée par le calcul. Ce n'est pas trompeur ; c'est réellement la moitié qui s'est le plus améliorée cette génération. Mais cela signifie que les chiffres marketing décrivent la vitesse à laquelle la machine lit votre document de 50 pages, pas la vitesse à laquelle elle en rédige le résumé.
Celui qui compte pour vous dépend de votre usage :
- Entrées longues, sorties courtes — résumer des documents, classifier, extraire des informations d'une base de code — est dominé par le prefill. Les chiffres d'Apple s'appliquent.
- Entrées courtes, sorties longues — rédaction, chat, génération de code — est dominé par le decode. La bande passante est votre chiffre de référence.
- Entrées longues et sorties longues — workflows agentiques sur un large contexte — nécessite les deux, et nécessite en plus de la capacité pour le cache KV.
Ce qui a vraiment changé avec le M5 Ultra
Une partie de la couverture médiatique du lancement a laissé entendre que faire tenir un modèle de pointe sur un ordinateur de bureau était une nouveauté. Ce n'est pas le cas, et bien comprendre cela change la décision de mise à niveau pour quiconque possède déjà un Mac Studio.
| M3 Ultra (2025) | M5 Ultra (2026) | |
|---|---|---|
| Mémoire unifiée maximale | 512GB | 512GB |
| Bande passante mémoire | 819GB/s | 1.2TB/s |
| Cœurs GPU | jusqu'à 80 | jusqu'à 80 |
| Cœurs CPU | 32 | jusqu'à 36 |
La capacité n'a pas changé. Le nombre de cœurs GPU n'a pas changé. La bande passante a augmenté d'environ 1.47x, et le CPU a gagné quatre cœurs.
Cela correspond exactement aux propres comparaisons d'Apple face au M3 Ultra — « jusqu'à 1.3x de performance multithread supérieure » et « jusqu'à 1.8x de performance graphique supérieure » sont des chiffres modestes, et la grande annonce d'Apple, « jusqu'à 4.3x la performance de calcul IA maximale », provient des Neural Accelerators désormais intégrés à chaque cœur GPU plutôt que de cœurs plus nombreux ou plus puissants.
Donc, pour l'inférence locale spécifiquement :
- La vitesse de génération s'améliore à peu près proportionnellement à la bande passante — disons environ 1.4x sur le même modèle.
- Le traitement des prompts s'améliore bien davantage, en ligne avec ce chiffre de 4.3x de calcul IA.
- Ce que vous pouvez charger reste inchangé.
Si vous possédez un Mac Studio M3 Ultra avec 512GB et que votre contrainte porte sur les modèles qui tiennent en mémoire, cette génération ne résout aucun problème que vous ayez réellement. Si votre contrainte est le temps d'attente pour le traitement de longs prompts, elle y répond directement. Notre guide de performance Mac Studio M4 Max et M3 Ultra couvre la génération précédente en détail.
Une dernière précision de calendrier à connaître avant de commander : la configuration 512GB n'est pas livrée le 22 septembre en même temps que le reste. Apple annonce son arrivée fin octobre.

Quelle machine, selon ce que vous faites réellement
16GB — pas fait pour ça
Vous disposez d'environ 10–12GB accessibles au GPU. Cela permet de faire tourner des modèles 8B en 4 bits avec un contexte modeste, et rien de plus grand. C'est correct pour des modèles de type autocomplétion et de petits assistants locaux, et cela vous frustrera pour tout le reste. En 2026, 16GB est une machine qui fait bien d'autres choses et qui fait tourner des LLM de manière accessoire.
32GB (M6 Mac mini, config maximale — $1,299) — le point d'entrée
Environ 21–24GB disponibles. Cela fait tourner confortablement des modèles 8B et 14B, ainsi qu'un modèle 32B en 4 bits avec un contexte court, à environ 7 tokens par seconde. Ce dernier chiffre est la limite honnête : ça tient en mémoire, mais à la limite de l'agréable.
Adapté pour : assistants de codage locaux, travail privé sur des documents, apprentissage des outils. La mise à niveau de $400 par rapport aux 16GB n'est pas optionnelle si les modèles locaux font partie de vos raisons d'achat de la machine.
64GB (M5 Pro Mac mini — $1,699+) — le point idéal pour la plupart des gens
Environ 42–48GB disponibles, et 307GB/s. Un modèle 70B en 4 bits tient en mémoire avec de la marge pour un vrai contexte, générant environ 6 tokens par seconde — utilisable pour du traitement par lots, lent pour un chat interactif. Un modèle 32B tourne à environ 12 tokens par seconde, ce qui est confortable.
C'est là que se situe la plupart des usages sérieux de modèles locaux, et c'est la configuration vers laquelle j'orienterais la plupart des gens. Elle apporte aussi Thunderbolt 5, absent du M6 mini.
128GB (M5 Max Mac Studio — $2,499+) — le palier professionnel
Environ 85–96GB disponibles à 614GB/s. Le 70B en 4 bits tourne à environ 11 tokens par seconde, confortablement interactif. Les modèles de classe 120B tiennent en mémoire. Les modèles MoE de taille moyenne deviennent utilisables.
C'est la configuration pour quelqu'un dont le travail dépend quotidiennement de l'inférence locale — la bande passante double à peu près la vitesse de génération du M5 Pro sur le même modèle.
512GB (M5 Ultra Mac Studio — $5,499+, plus de $18,000 en configuration maximale) — une capacité introuvable ailleurs
Environ 340–384GB disponibles à 1.2TB/s. Cela permet de contenir des modèles MoE de classe 400B en 4 bits et de générer à la vitesse de leur nombre de paramètres actifs, ce qu'aucun autre ordinateur de bureau ne fait précisément à ce prix.
Achetez cette configuration si vous êtes limité par la capacité d'une façon que rien d'autre ne résout. Si vos modèles tiennent dans 128GB, l'Ultra vous achète une vitesse que vous pourriez obtenir moins cher.
Si vous n'achetez pas de nouveau Mac
Un Mac M1/M2/M3/M4 existant avec une mémoire suffisante fait très bien tourner des modèles locaux — la bande passante des paliers Pro et Max est bonne depuis plusieurs générations. Vérifiez vos propres chiffres :
# Total memory in GB
echo "$(( $(sysctl -n hw.memsize) / 1073741824 )) GB"
# Chip and current GPU wired limit
sysctl -n machdep.cpu.brand_string
sysctl iogpu.wired_limit_mb
Appliquez ensuite les tableaux ci-dessus. Un M1 Max avec 64GB à 400GB/s est une excellente machine pour l'inférence locale, et l'a toujours été.
Un exemple chiffré
Des tableaux abstraits sont faciles à approuver du regard et difficiles à mettre en pratique. Voici le raisonnement appliqué à un cas concret.
Le besoin : un assistant de codage privé qui lit une base de code de taille moyenne, maintient un contexte de 32,000 tokens, et répond de manière interactive. Vous voulez un modèle de classe 32B parce que les plus petits sont nettement moins bons en code.
Étape 1 — les poids. 32B en 4 bits : 32 × 0.55 = 17.6GB.
Étape 2 — le contexte. 32,000 tokens à environ 0.2 MB par token pour un modèle moderne à grouped-query attention : environ 6.4GB. C'est le terme que les gens oublient, et ici il représente plus d'un tiers de la taille des poids.
Étape 3 — la surcharge. Runtime, buffers Metal, tokenizer : 2–3GB.
Total : environ 26–27GB devant être verrouillés (wired) pour le GPU.
Étape 4 — traduire en mémoire installée. Avec un plafond automatique d'environ 70%, 27GB verrouillés nécessitent environ 38GB installés. Un Mac de 32GB vous donne automatiquement 21–24GB — pas assez. Vous pourriez relever iogpu.wired_limit_mb à 27GB sur une machine de 32GB, ce qui laisse 5GB pour macOS et tout le reste. Cela fonctionnera tant que rien d'autre ne tourne, et s'effondrera dès que vous ouvrirez un navigateur.
Conclusion : 64GB installés. Ce qui vous amène au M5 Pro Mac mini, pas au M6.
Étape 5 — vérifier la vitesse. 307GB/s × 0.7 ÷ 17.6GB ≈ 12 tokens par seconde. Confortable pour un usage interactif.
Maintenant, changez une seule variable. Gardez tout le reste identique et demandez un contexte de 128,000 tokens : le cache KV passe à environ 25GB, la demande totale à environ 45GB, et la mémoire installée requise à 64GB au minimum avec le plafond relevé — ou 128GB pour être confortable. Un seul réglage a fait passer la réponse à un palier de produit entier au-dessus.
C'est toute la méthode. Poids, contexte, surcharge, diviser par le plafond, puis vérifier la bande passante par rapport à la taille des poids.
Les runtimes ne se comportent pas tous de la même façon
Le calcul ci-dessus décrit le matériel. Ce que vous observez réellement dépend du logiciel, et les différences sont assez importantes pour changer une décision d'achat.
MLX est le framework de calcul matriciel propre à Apple, conçu pour la mémoire unifiée. Il ne copie pas entre « mémoire CPU » et « mémoire GPU » car cette distinction n'existe pas sur silicium Apple, et c'est généralement l'option la plus économe en mémoire sur un Mac. Si vous achetez du matériel spécifiquement pour l'inférence locale, ce sont les outils basés sur MLX qui mettent le matériel en valeur.
llama.cpp, et les outils qui s'appuient dessus, est l'option la plus portable et bénéficie d'un excellent support de Metal. Ses formats de quantification — la famille Q4_K_M supposée dans les tableaux ci-dessus — font figure de standard de fait, et son comportement mémoire est prévisible et bien documenté.
Ollama enrobe llama.cpp avec une gestion des modèles. Pratique, et ce qu'il faut savoir, c'est qu'il garde les modèles résidents en mémoire après usage pendant une durée configurable. Si vous êtes proche de votre plafond, un modèle que vous avez fini d'utiliser il y a une heure peut encore occuper de la mémoire. C'est une cause fréquente du « ça marchait hier ».
LM Studio est l'option graphique et se montre honnête sur la mémoire, en vous indiquant avant chargement ce qui tiendra ou non. C'est un bon moyen de développer une intuition de ces chiffres sans faire de calcul.
Deux comportements comptent quel que soit le runtime que vous utilisez :
- La préallocation ou non du cache KV. Certains runtimes réservent toute la fenêtre de contexte au chargement ; d'autres la font croître au fil de la conversation. La préallocation fait qu'un modèle qui tournerait en pratique échoue au chargement. Si un modèle refuse de charger à 128K mais charge à 8K, voilà pourquoi — et réduire le contexte configuré est la solution, pas un modèle plus petit.
- Le déchargement ou non des modèles inutilisés. Vérifiez le réglage de keep-alive de votre runtime avant de conclure que votre machine est trop petite.
Gagner de la marge sans acheter de mémoire
Avant de dépenser $400 pour un palier de mémoire supérieur, plusieurs techniques changent le calcul.
Quantifiez plus fort. Passer de 8 bits à 4 bits divise par deux votre besoin en mémoire pour une perte de qualité modeste. C'est presque toujours un meilleur compromis que de passer à un modèle plus petit en plus haute précision — un modèle 32B en 4 bits bat généralement un modèle 14B en 8 bits, à mémoire équivalente.
Quantifiez le cache KV. La plupart des runtimes peuvent stocker le cache KV en 8 bits ou moins. Sur de longs contextes, où le cache rivalise avec les poids, c'est de loin la plus grande économie disponible, et le coût en qualité est faible.
Dimensionnez correctement le contexte. Une fenêtre de contexte de 128K dont vous n'utilisez que 4,000 tokens coûte quand même le plein prix sur les runtimes qui préallouent. Configurez le contexte que vous utilisez réellement.
Préférez les modèles MoE. Comme vu plus haut, un modèle à mélange d'experts vous donne la qualité d'un grand modèle à la vitesse de génération d'un petit. Le coût est la capacité, ce qui est précisément ce dont un Mac dispose davantage que les alternatives.
Utilisez le speculative decoding. Un petit modèle brouillon propose plusieurs tokens et le grand modèle les vérifie en une seule passe. La vérification étant parallèle, cette technique attaque directement le goulot d'étranglement de la bande passante et peut sensiblement augmenter les tokens par seconde — au prix de conserver un second petit modèle en mémoire. Sur une machine limitée par la bande passante mais disposant de capacité en réserve, c'est un bon compromis.
Fermez des applications. Évident, et pourtant la réponse étonnamment souvent. Les navigateurs avec de nombreux onglets, les machines virtuelles et les logiciels de montage vidéo se disputent tous le même pool de mémoire. Il n'y a pas de VRAM séparée sur laquelle se replier.
Dépannage des problèmes courants
Le modèle charge mais la génération est extrêmement lente
Problème : vous avez dépassé ce que macOS accorde au GPU, et le travail déborde vers le swap. Les symptômes sont un premier token qui met de longues secondes à arriver et une génération saccadée plutôt qu'un flux régulier.
Solution : vérifiez la pression mémoire dans le Moniteur d'activité pendant la génération. Si elle est jaune ou rouge, utilisez une quantification plus légère, réduisez votre fenêtre de contexte, ou relevez iogpu.wired_limit_mb — en laissant au moins 6–8GB pour le système. Si la pression est verte et que c'est quand même lent, vous êtes simplement limité par la bande passante, et la solution est un modèle plus petit.
« System has run out of application memory »
Problème : généralement un plafond wired réglé de façon trop agressive, ou un contexte volumineux qui a grossi au cours d'une longue session.
Solution : réinitialisez avec sudo sysctl iogpu.wired_limit_mb=0 et relancez le processus d'inférence. Redémarrez si le système reste instable — le réglage n'est pas persistant, donc un redémarrage l'efface de toute façon. Les causes connexes sont couvertes dans notre guide de dépannage des fuites mémoire.
Ça tient sur le papier mais le chargement échoue
Problème : vous avez dimensionné pour les poids et oublié le cache KV, ou le runtime alloue tout le contexte d'un coup au lieu de le faire croître progressivement.
Solution : réduisez la longueur du contexte dans les réglages de votre runtime et réessayez. Si un contexte de 32K charge et que 128K ne charge pas, cela confirme le diagnostic, et le calcul de la section capacité vous indique de combien vous avez besoin pour le contexte que vous voulez.
Le Mac chauffe et ralentit sur une longue session
Problème : une inférence soutenue représente une charge soutenue à la fois sur le GPU et sur la mémoire. Les portables throttlent. Les ordinateurs de bureau, la plupart du temps, non.
Solution : c'est l'un des vrais arguments en faveur d'un Mac mini ou d'un Mac Studio plutôt qu'un MacBook pour ce type de charge — une marge thermique soutenue. Sur un portable, consultez notre guide sur le throttling thermique du MacBook Pro M5.
Traitement des prompts rapide, génération lente
Problème : rien ne cloche. C'est le comportement attendu du matériel.
Solution : reportez-vous à la section prefill contre decode plus haut. Si c'est la vitesse de génération qu'il vous faut, la solution est un modèle plus petit, une quantification plus agressive, un modèle MoE avec un faible nombre de paramètres actifs, ou davantage de bande passante — dans cet ordre de coût.
FAQ
De combien de RAM ai-je besoin pour faire tourner un modèle 70B ?
En quantification 4 bits, les poids représentent environ 38.5GB. En ajoutant le contexte et la surcharge, vous voulez 64GB installés comme minimum réaliste, car macOS n'accordera au GPU qu'environ 42–48GB de cette mémoire. 48GB installés sont trop justes dès que vous incluez un contexte significatif.
16GB suffisent-ils pour l'IA locale en 2026 ?
Pour des modèles 8B en 4 bits avec un contexte court, oui. Pour tout ce qui est plus grand, non. Si les modèles locaux font partie de vos raisons d'achat de la machine, considérez 32GB comme le plancher et 64GB comme l'objectif.
Le Neural Engine accélère-t-il les LLM locaux ?
Il contribue au traitement des prompts, d'où provient le chiffre d'Apple « 4.8x plus rapide pour le traitement des prompts LLM », et le double Neural Engine 16 cœurs du M6 représente une réelle avancée. Il ne change en rien la limite de bande passante sur la génération de tokens. La plupart des runtimes d'inférence locale populaires sur Mac s'appuient principalement sur le GPU via Metal.
Devrais-je acheter le Mac Studio 512GB ?
Uniquement si vous êtes limité par la capacité. Si les modèles que vous faites réellement tourner tiennent dans 128GB, un Mac Studio M5 Max fait le même travail pour un tiers du prix. Notez aussi que l'option 512GB n'est livrée que fin octobre, et que la machine en configuration complète atteint $18,299.
Puis-je ajouter de la mémoire plus tard ?
Non. La mémoire unifiée fait partie du package de la puce sur tout Mac à silicium Apple. C'est la caractéristique qui mérite le plus qu'on la surdimensionne à l'achat, car c'est la seule que vous ne pourrez jamais revoir par la suite.
Un Mac est-il meilleur qu'un PC avec GPU discret pour cet usage ?
Des compromis différents. Un GPU discret a une bande passante mémoire bien plus élevée mais beaucoup moins de mémoire — les cartes grand public plafonnent bien en dessous de ce qu'offre un Mac Studio. Un Mac l'emporte nettement sur la capacité par dollar et sur la consommation électrique, et perd sur le débit brut pour les modèles suffisamment petits pour tenir en VRAM. Si vos modèles sont volumineux, le Mac est souvent la seule option en une seule machine. S'ils sont petits, un GPU est plus rapide.
La quantification nuit-elle à la qualité ?
Le 8 bits est proche de l'absence de perte pour la plupart des usages. Les K-quants 4 bits sont le choix pratique par défaut, et la dégradation reste modeste pour la plupart des tâches. En dessous de 4 bits, la qualité chute nettement. Compte tenu des tableaux de mémoire ci-dessus, passer de 8 bits à 4 bits divise à peu près par deux votre besoin en mémoire — généralement un meilleur compromis que de passer à un modèle plus petit.
Conclusion
Le chiffre choc des 512GB est réel, et pour un petit nombre de personnes, il est décisif. Pour tous les autres, la version utile de cet article tient en trois lignes de calcul : les poids sont les paramètres multipliés par les octets par paramètre, le contexte ajoute 0.1–0.5 MB par token par-dessus, et macOS n'accorde au GPU qu'environ 65–75% de ce que vous avez acheté.
Appliquez ces chiffres aux modèles que vous comptez réellement utiliser, et la réponse tombe généralement sur 64GB. Vérifiez ensuite le second chiffre — la bande passante — car c'est lui qui détermine si le modèle qui tient en mémoire est un modèle que vous continuerez à utiliser. L'écart entre un modèle 32B à 7 tokens par seconde et le même modèle à 24 tokens par seconde est l'écart entre une démonstration et un outil, et aucune quantité de capacité ne le comble.
Et quel que soit votre choix, choisissez-le avec soin. C'est soudé.
À lire aussi : Mac mini M6 et Mac Studio M5 Ultra : ce qui a vraiment changé, applications d'IA locale sur Mac et ce qu'elles font de vos données, et les prix de la RAM Mac augmentent en 2026.
