Mac 2026 : 32 Go ou 64 Go, comment choisir pour un Agent local et Mojo ?

32 Go remportent le choix pour un Agent local à modèle unique, contexte court et compilation Mojo décalée ; 64 Go deviennent le choix à tester en priorité dès que le modèle, les outils et la compilation doivent fonctionner ensemble. En cas d’hésitation, il vaut mieux louer les deux capacités avec un flux identique que choisir à partir de la seule taille du fichier de modèle.

Profils concernés par ce choix

Cet article s’adresse au développeur individuel qui veut vérifier qu’un Agent local termine réellement ses tâches, et pas seulement qu’un modèle démarre.

Il concerne aussi le développeur Mojo ou le contributeur open source qui doit compiler et tester sans arrêter un service d’inférence, ainsi que le responsable technique qui compare la capacité livrée, le risque d’échec et le coût d’une machine inutilisée.

Le point commun est la mémoire unifiée du Mac : le modèle, le système, l’éditeur, les outils d’automatisation et le compilateur puisent dans le même espace. Apple décrit cette architecture comme une mémoire partagée entre les composants de la machine, ce qui évite de raisonner comme avec une mémoire système et une mémoire graphique totalement séparées dans la documentation Apple sur la mémoire unifiée.

32 Go pour le prototype contrôlé

Pour un développeur qui construit un premier Agent local, 32 Go peuvent constituer un point de départ rationnel. La condition est stricte : un modèle quantifié, une seule session active, un nombre limité d’outils et une longueur de contexte volontairement maîtrisée.

La première erreur consiste à confondre trois niveaux de réussite :

• Le chargement : les poids sont placés en mémoire et le service répond à une requête simple.
• La réponse isolée : le modèle produit une sortie après un prompt court, sans historique important ni appel d’outil.
• Le flux complet : l’Agent lit des fichiers, appelle un outil, conserve son état, récupère des documents, génère une réponse et termine sans pression mémoire excessive.

Un Mac de 32 Go peut réussir les deux premiers niveaux et échouer au troisième. Une démonstration réussie dans une interface vide ne valide donc pas un usage de développement.

MLX-LM prend en charge la quantification et l’exécution de modèles sur les puces Apple ; son dépôt officiel expose également les interfaces de génération et les paramètres liés au cache dans la documentation du projet MLX-LM. La quantification réduit l’espace occupé par les poids, mais elle ne supprime pas les autres postes : cache d’attention, contexte courant, bibliothèques chargées, système et applications.

Pour un prototype, 32 Go sont donc à retenir si les conditions suivantes sont réunies :

• le modèle est chargé seul ;
• le contexte reste limité et testé avec sa longueur réelle ;
• l’Agent n’ouvre pas simultanément plusieurs navigateurs, conteneurs ou indexeurs ;
• la compilation Mojo est planifiée avant ou après les sessions d’inférence ;
• l’échec d’une tâche peut être reproduit et analysé.

Cette capacité convient particulièrement à un projet de preuve de concept, à une expérimentation audio ou vidéo avec traitement par étapes, ou à une petite interface de design qui délègue une tâche précise à l’Agent. Elle devient moins confortable lorsque l’Agent doit garder plusieurs sources ouvertes et modifier un dépôt complet.

Contexte long et récupération documentaire

Le fichier de poids est seulement le premier poste à considérer. Dans un Agent qui lit un dépôt, récupère des passages ou conserve une conversation, la mémoire évolue pendant l’exécution.

Le cache KV conserve des informations nécessaires à la poursuite de la génération. MLX-LM fournit une implémentation de cache et des mécanismes de cache de prompt dans le code officiel de gestion du cache ainsi que des outils de mise en cache des prompts dans la documentation dédiée. Ces fonctions peuvent éviter de recalculer certaines parties, mais elles ne transforment pas un contexte long en charge gratuite.

Le développeur doit séparer plusieurs situations :

• un prompt court envoyé une fois ;
• une conversation qui accumule les échanges ;
• un dépôt dont le code est injecté par grandes portions ;
• une base documentaire RAG qui ajoute des passages à chaque étape ;
• une tâche où l’Agent relit ses propres sorties et conserve plusieurs résultats intermédiaires.

Sur 32 Go, la première réponse consiste souvent à réduire le contexte, limiter le nombre de documents injectés ou configurer un cache plus contrôlé. Cette solution peut maintenir le service en fonctionnement, mais elle peut aussi dégrader la qualité : moins de code visible, moins de références disponibles et davantage de découpage manuel.

La deuxième solution consiste à réduire la taille de la tâche. Un Agent peut traiter un seul dossier au lieu d’un dépôt complet, ou réaliser les appels d’outils en plusieurs sessions. La stabilité s’améliore, mais l’autonomie diminue.

La troisième solution est de passer à 64 Go. Cette capacité ne garantit ni une vitesse fixe ni une qualité supérieure du modèle. Elle donne surtout davantage de place au flux complet : poids, cache, système, applications et opérations annexes peuvent cohabiter avec moins de risque de basculer vers l’échange disque.

Pour une base de connaissances, un assistant de documentation ou un outil de génération vidéo piloté par scripts, 64 Go se justifient donc lorsque le contexte réel fait partie du produit. Si le contexte est artificiellement raccourci uniquement pour faire entrer la démonstration dans 32 Go, le test ne représente plus le futur usage.

Mojo 1.0 et compilation concurrente

Mojo change le profil de charge. Le compilateur ne se contente pas d’ajouter une commande ponctuelle : une construction complète peut impliquer la résolution des dépendances, la compilation de plusieurs composants, l’exécution de tests et parfois plusieurs relances après correction.

Le calendrier officiel indique la publication de Mojo 1.0 le 11 août 2026 dans l’archive de version officielle. Modular a ensuite confirmé l’ouverture du projet le 18 août 2026 dans son annonce officielle. Ces éléments confirment le cadre logiciel à tester ; ils ne fournissent pas une valeur universelle de mémoire pour chaque dépôt. La taille d’un projet, les dépendances et le mode de construction restent déterminants.

Un contributeur qui peut arrêter le service local avant de lancer une compilation dispose de trois leviers :

• compiler pendant une période où aucun Agent ne tourne ;
• limiter le parallélisme de construction ;
• séparer l’inférence et les tests dans deux environnements.

Dans ce cas, 32 Go peuvent être évalués sérieusement, surtout pour un dépôt de taille maîtrisée et une utilisation intermittente.

Le raisonnement change lorsque le flux exige de servir l’Agent pendant la compilation. Le modèle conserve alors sa mémoire, l’historique et éventuellement son cache, tandis que le compilateur et les tests réclament leurs propres ressources. Même sans chiffre de pic généralisable, le risque est concret : ralentissement, espace d’échange qui augmente, tests interrompus ou reprise manuelle après échec.

Pour Mojo 1.0, 64 Go doivent être testés en priorité si le poste sert à la fois de laboratoire d’inférence et de machine de contribution. La capacité supérieure ne remplace pas une bonne organisation des tâches, mais elle évite de faire dépendre chaque compilation d’un arrêt complet du service.

Agents, navigateurs et outils actifs

Le nombre d’Agents ne se traduit pas mécaniquement par une multiplication de la mémoire du modèle. Deux Agents peuvent parfois partager un service d’inférence. À l’inverse, un seul Agent peut lancer plusieurs processus lourds.

Le cumul réel peut comprendre :

• le modèle et son cache ;
• l’éditeur et l’indexation du code ;
• un navigateur piloté pour des tests ;
• un processus de capture ou de traitement audio ;
• un outil de montage ou de prévisualisation vidéo ;
• des conteneurs ;
• une base vectorielle locale ;
• une compilation Mojo ;
• des journaux et artefacts de test.

Cette combinaison explique pourquoi un Mac de 32 Go semble confortable au repos puis devient instable après plusieurs actions. L’état vide ne mesure pas le pic de la tâche.

Pour un flux créatif, le contraste est particulièrement visible. Un Agent qui prépare des plans de montage, classe des prises audio et interroge un dossier de scripts peut rester léger si chaque opération est séquentielle. Le même flux, avec prévisualisation vidéo, navigateur d’administration, indexation du projet et génération locale simultanée, réclame une marge différente.

Le choix doit donc être fait sur le pic :

• 32 Go : un Agent principal, outils ouverts au besoin, indexation limitée, conteneurs arrêtés pendant la compilation ;
• 64 Go : plusieurs outils actifs, navigation automatisée, dépôt volumineux, contexte durable, génération et compilation rapprochées ;
• capacité séparée : service d’inférence permanent et compilations fréquentes qui ne peuvent pas être planifiées.

Le fait d’ajouter un Agent ne suffit pas à imposer 64 Go. En revanche, chaque processus qui reste vivant pendant l’appel d’outil réduit la marge disponible pour le cache et le compilateur.

Partage d’équipe et risque d’inactivité

Pour une équipe, la décision ne se limite pas à la charge d’un développeur. Il faut observer le moment où les tâches arrivent.

Un Mac de 32 Go peut convenir à une équipe qui impose une file d’attente claire : une personne lance l’inférence, puis libère la machine avant la compilation ; les tests automatisés sont regroupés dans une plage dédiée ; les gros dépôts ne sont pas indexés en permanence.

Un Mac de 64 Go est plus cohérent lorsque les utilisateurs se succèdent sans coordination stricte, lorsqu’un service doit rester disponible ou lorsque plusieurs processus doivent être conservés pour réduire les temps de remise en route. La capacité supplémentaire achète alors une marge opérationnelle, pas une promesse de performance uniforme.

Le responsable technique doit examiner les traces disponibles :

• fréquence des tâches échouées ou relancées ;
• évolution de la pression mémoire pendant un flux complet ;
• apparition et croissance de l’espace d’échange ;
• temps passé à fermer puis rouvrir les outils ;
• périodes où la machine reste inutilisée ;
• possibilité réelle de faire patienter une tâche.

Si les journaux montrent un seul pic rare, la location ponctuelle d’une capacité supérieure peut être préférable à un achat permanent. Si les pics sont fréquents et imprévisibles, l’achat ou la location régulière de 64 Go devient plus facile à défendre.

Le suivi peut être réalisé avec le Moniteur d’activité. Apple explique notamment comment observer la pression mémoire et l’utilisation de l’espace d’échange dans son guide officiel du Moniteur d’activité. Une capture de mémoire libre prise avant le test n’a pas la même valeur qu’un enregistrement pendant la compilation et les appels d’outils.

Décision conditionnelle à cocher

Cette liste sert à trancher avant de réserver ou d’acheter. Chaque case doit être cochée uniquement si elle décrit le flux réellement prévu, et non une démonstration simplifiée.

• [ ] Si le modèle est quantifié, l’Agent est unique, le contexte est court et la compilation Mojo peut être décalée, alors la première configuration à tester est celle de 32 Go.
• [ ] Si le flux complet lit un dépôt, injecte des documents et conserve une conversation longue, alors la configuration de 64 Go doit être testée avant tout achat.
• [ ] Si l’inférence et la compilation doivent tourner ensemble, alors 32 Go doivent être considérés comme une hypothèse à valider, et non comme le choix par défaut.
• [ ] Si plusieurs navigateurs, conteneurs, indexeurs ou applications audio et vidéo restent actifs, alors la priorité doit aller à un essai en 64 Go.
• [ ] Si les tâches peuvent être mises en file et que l’utilisation est faible, alors il ne faut pas financer une capacité supérieure uniquement pour un pic occasionnel.
• [ ] Si les résultats sont contradictoires, alors les deux configurations doivent exécuter exactement le même scénario.
• [ ] Si l’espace d’échange augmente à chaque répétition ou si le flux échoue avant la fin, alors la configuration doit être rejetée, même si le modèle se charge correctement.
• [ ] Si 64 Go terminent le flux, mais que la machine reste inutilisée la majorité du temps, alors la location ponctuelle ou la séparation des environnements peut être plus rationnelle qu’un achat.

Cette méthode répond à la question « Mac 2026 : 32 Go ou 64 Go » avec le contexte réel du projet, et non avec une règle fondée sur le nom du modèle.

Protocole de location avant achat

Une location de test doit reproduire le futur poste. Le but n’est pas de mesurer une génération idéale, mais la capacité à livrer une tâche complète.

Commencez par figer la version du modèle, sa quantification et le mode de lancement. Notez également la longueur de contexte utilisée, le nombre de documents injectés et les paramètres de génération ; les interfaces de génération de MLX-LM sont décrites dans le fichier officiel des paramètres de génération.

Préparez ensuite un scénario reproductible :

• ouverture du dépôt et indexation ;
• démarrage du modèle ;
• première demande courte ;
• appel d’un outil ou d’un navigateur ;
• lecture de documents ou de fichiers source ;
• poursuite de la conversation ;
• compilation Mojo ;
• exécution des tests ;
• seconde tâche Agent pendant ou après la construction.

Lancez ce scénario sur 32 Go, puis sur 64 Go, sans modifier les autres variables. Une machine plus rapide mais configurée avec un contexte plus court ne constitue pas une comparaison valable.

Pendant chaque essai, consignez la pression mémoire, l’espace d’échange, l’heure de début et de fin, les interruptions et la reprise après fermeture d’un outil. Le Moniteur d’activité peut fournir une partie de ces observations ; les journaux du projet doivent compléter les données.

Répétez les étapes à plusieurs moments : après un démarrage propre, après une conversation prolongée et après une compilation. Une seule exécution favorable peut masquer une accumulation de cache ou un processus oublié.

Terminez par une décision opérationnelle :

• acheter ou louer 32 Go si le flux complet réussit de façon répétée et si la compilation décalée reste acceptable ;
• retenir 64 Go si la tâche échoue, échange sur disque ou exige trop de fermetures manuelles en 32 Go ;
• séparer l’inférence et la compilation si aucune capacité unique ne reste stable ;
• continuer à louer si la charge varie fortement et si l’achat laisserait la machine inutilisée une grande partie du temps.

Pour préparer la connexion et l’accès distant, la console ProxyMac peut servir de point de départ. Les conditions de location doivent être vérifiées dans les conditions de service ProxyMac, notamment avant de planifier une campagne de tests répétée.

FAQ technique

Mac de 32 Go et Agent local

Oui, pour un prototype limité à un modèle, un Agent et un contexte maîtrisé. La validation doit cependant inclure les appels d’outils, les documents et l’historique réels. Le simple démarrage du modèle ne permet pas de conclure.

Modèle et compilation Mojo

La coexistence est possible, mais elle dépend du pic de compilation et de la mémoire déjà retenue par le modèle et ses caches. Un décalage des tâches peut rendre 32 Go acceptables. Un service continu avec compilation et tests simultanés mérite un essai prioritaire en 64 Go.

Passage de 32 Go à 64 Go

Le passage devient pertinent pour les contextes longs, les bases documentaires, les navigateurs automatisés, les conteneurs, l’indexation de code et les équipes qui partagent la machine. La décision doit reposer sur les échecs et la pression mémoire observés.

Mesures pendant une location

Conservez exactement la même charge et relevez pression mémoire, espace d’échange, durée du flux, erreurs et capacité de reprise. Comparez des exécutions complètes, pas uniquement la vitesse de génération d’une réponse isolée.

Le poste actuel reste souvent moins adapté qu’il n’y paraît : un Mac de 32 Go oblige à fermer les outils avant une compilation, un environnement séparé augmente les manipulations et une machine achetée pour un pic d’activité peut rester inutilisée ensuite. Pour ce type de validation, louer chez ProxyMac un Mac à mémoire unifiée permet de reproduire le même Agent et les mêmes étapes Mojo en 32 Go puis en 64 Go, avant de décider s’il faut poursuivre la location ou acheter une configuration durable.