Combien de mémoire unifiée Mac faut-il pour compiler le code source de Mojo en 2026 ?

Symptôme : votre Mac charge un modèle local, mais le clean build de Mojo ralentit, échange des données sur le disque ou s’arrête.
Solution la plus rapide : traitez séparément le modèle et la compilation ; utilisez 16 ou 24 Go pour une vérification limitée, mesurez un clean build à partir de 32 Go, puis commencez à 64 Go si l’agent local, les tests Bazel et les outils doivent rester actifs ensemble.

Cet article s’adresse aux contributeurs qui veulent compiler Mojo depuis les sources sur un Mac Apple Silicon, aux développeurs d’agents locaux qui partagent la machine avec leur chaîne de compilation, et aux responsables techniques qui souhaitent louer deux capacités voisines avant de standardiser un poste.

Dernière mise à jour : 28 août 2026. Les informations de construction ont été vérifiées dans l’annonce officielle d’ouverture du code source Mojo et dans la documentation du dépôt ; les indications matérielles ont été rapprochées des spécifications officielles du Mac mini.

Le périmètre réel de la compilation

Dire qu’un Mac « compile Mojo » ne décrit pas une seule opération. Vous devez d’abord préciser la cible observée, car chaque niveau consomme des ressources différentes.

• Outil Mojo précompilé : vous installez la chaîne existante et compilez vos propres fichiers. Cette situation mesure surtout votre projet, vos dépendances et vos outils de développement. Elle ne valide pas la construction du compilateur.
• Modification de la bibliothèque standard : le périmètre augmente. Une partie des composants doit être reconstruite, mais vous ne mesurez toujours pas nécessairement un dépôt complet.
• Construction du compilateur depuis les sources : c’est le cas pertinent pour une contribution au dépôt. La charge dépend de la révision, des dépendances déjà téléchargées, des options Bazel et du degré de parallélisme.
• Suite complète de tests : elle ajoute des processus, des artefacts et parfois des phases qui ne sont pas présentes dans une compilation simple.
• Compilation avec agent local : vous superposez le service de modèle, l’indexation du code, la mémoire du contexte et les appels d’outils au build.

Le dépôt officiel distingue le travail dans les sources et l’utilisation d’outils déjà construits. La procédure de compilation documentée passe par Bazel ; utilisez donc les commandes du dépôt concerné plutôt qu’une commande générique copiée d’un autre projet. Consultez les instructions officielles de construction dans le dépôt Mojo, puis conservez la révision exacte utilisée pour votre mesure.

Votre fiche de test doit au minimum contenir :

• le commit Mojo ;
• la cible construite ;
• les options Bazel ;
• l’état des caches ;
• le fait que les dépendances aient été téléchargées ou non ;
• la présence ou non d’un agent local ;
• le résultat final, et non le simple lancement de la commande.

L’annonce officielle d’ouverture du code source confirme le chemin de construction et le rôle du dépôt, mais elle ne donne pas un seuil universel de mémoire unifiée valable pour toutes les cibles. Il n’existe donc pas de chiffre officiel permettant d’affirmer qu’un modèle chargé sur une capacité donnée prouve qu’un compilateur complet y passera aussi.

Charge de pointe et état de réussite

La première mesure utile est un clean build. Un build incrémental avec cache chaud répond à une autre question : « cette petite modification peut-elle être reconstruite rapidement ? » Il ne répond pas à « cette machine peut-elle initialiser le projet dans des conditions réalistes ? ».

Pendant le test, ouvrez le moniteur d’activité et observez la pression mémoire, la mémoire utilisée et l’espace d’échange. Apple explique que la pression mémoire synthétise l’état de la mémoire disponible et la charge exercée par les processus ; un chiffre isolé de mémoire occupée ne suffit donc pas à qualifier la stabilité du système. La documentation Apple sur la pression mémoire décrit les indicateurs à surveiller.

Votre critère de réussite doit être composé de plusieurs conditions :

• la cible demandée est entièrement construite ;
• le processus ne quitte pas avec une erreur de mémoire ou une erreur secondaire liée au système ;
• la machine reste utilisable pour les actions prévues ;
• l’échange ne progresse pas continuellement pendant toute la phase critique ;
• une seconde exécution comparable aboutit avec un comportement proche.

« La commande a démarré » n’est pas un résultat. Un Mac peut accepter le lancement, télécharger les dépendances, puis atteindre sa limite lorsque plusieurs actions de compilation s’exécutent simultanément. De même, un build qui finit après une longue période de ralentissement n’est pas automatiquement adapté à une journée de contribution.

Le stockage interne peut accueillir des fichiers temporaires et des données d’échange, mais il ne remplace pas la mémoire unifiée. Un disque plus grand ne donne pas aux processus davantage de mémoire vive à faible latence. Si l’échange augmente, vous mesurez une capacité de secours, pas une capacité de travail équivalente.

Pour rendre le résultat exploitable, répétez le même objectif avec le même commit et les mêmes options. Ne changez pas simultanément la cible, le nombre d’actions et l’état du cache. Sinon, vous ne saurez pas quelle modification a amélioré ou dégradé le résultat.

Parallélisme Bazel et coût des caches

Bazel peut lancer plusieurs actions en parallèle. Ce comportement raccourcit parfois le temps total, mais il augmente aussi le nombre de compilateurs, de liens et de fichiers temporaires présents au même moment. La référence officielle des options de ligne de commande Bazel doit servir de base pour documenter le réglage choisi.

Comparez deux profils simples :

Profil par défaut

• conservez les paramètres prescrits par la documentation du dépôt ;
• notez le temps total ;
• relevez le pic de mémoire et l’évolution de la pression ;
• conservez le résultat, y compris l’échec éventuel.

Profil à parallélisme contrôlé

• ne réduisez que le nombre d’actions simultanées ;
• gardez le même commit et la même cible ;
• mesurez à nouveau la durée, le pic et la réussite ;
• indiquez clairement si le résultat est devenu stable au prix d’un temps plus long.

Cette comparaison répond à une question de décision. Si un réglage moins parallèle permet au clean build de terminer sans échange persistant, vous avez peut-être une solution de développement ponctuelle. Vous n’avez pas encore démontré qu’elle convient à une équipe qui lance des tests, un indexeur et un agent en même temps.

Les caches introduisent un autre piège. Un premier build doit télécharger des dépendances et remplir des répertoires ; un second réutilise une partie de ce travail. Mesurez donc au moins un scénario sans cache utile et un scénario incrémental, en les nommant explicitement. Ne présentez jamais le meilleur temps d’un cache chaud comme le besoin durable de la machine.

Rappel de terrain : si vous louez un Mac pour une décision d’achat, demandez que le commit, les options Bazel et la procédure de nettoyage soient conservés dans un script. Une mesure impossible à rejouer n’a presque aucune valeur comparative.

Mémoire unifiée Mac et concurrence avec un agent

La mémoire unifiée Mac est partagée entre le processeur, le processeur graphique et les applications. Un service de modèle local peut donc réduire la marge disponible pour Bazel, même si le modèle semble ne rien faire. La documentation MLX sur la mémoire unifiée explique ce partage et les mécanismes d’observation propres à cet environnement.

Séparez quatre états d’agent :

• service démarré mais sans requête ;
• conversation avec contexte long ;
• appel d’outil, exécution de commande ou lecture de fichiers ;
• indexation du dépôt et recherche dans le code.

Un test avec agent au repos ne valide pas un poste de développement agentique. Pour un vrai test concurrent, lancez le clean build pendant une tâche qui reproduit votre usage : analyse de fichiers, génération de code, appel d’outil, puis vérification du résultat. Le build et l’agent doivent terminer tous les deux. Si vous les exécutez l’un après l’autre, vous mesurez une stratégie d’alternance, pas un besoin de mémoire simultané.

Les essais de modèles locaux peuvent aider à préparer le scénario, mais ils ne fixent pas un seuil Mojo. Par exemple, un test tiers d’un modèle de l’ordre de 27 milliards de paramètres en quantification quatre bits dépend de la bibliothèque, du contexte et des réglages retenus ; consultez les conditions du test MLX du modèle 27B sans transformer son résultat en exigence officielle de compilation.

Pour une équipe audio, vidéo ou design, ajoutez aussi l’application de production et les fichiers réellement ouverts. Une session de montage, une bibliothèque sonore ou un outil de rendu peut changer la marge disponible avant même le lancement de Bazel. Le bon test n’est pas un poste « propre » si votre journée de travail ne l’est jamais.

FAQ de décision

16 Go : validation ciblée, pas promesse de clean build

Un Mac de 16 Go peut servir à vérifier une cible limitée, à modifier un fichier ou à tester un outil précompilé, surtout si vous évitez la concurrence. La conclusion devient fragile dès que vous ajoutez une construction complète, une suite de tests ou un agent local avec indexation. Si l’échange s’installe ou si la commande échoue, ne compensez pas automatiquement par davantage d’espace disque : réduisez la cible ou testez une capacité supérieure.

24 Go : marge intermédiaire à documenter

La capacité de 24 Go peut convenir à un contributeur qui alterne les tâches et contrôle le parallélisme, mais elle ne doit pas être présentée comme une garantie pour tous les dépôts et toutes les révisions. Utilisez-la comme palier de comparaison entre une vérification limitée et un clean build plus ambitieux. La décision dépend du résultat complet, de la pression mémoire et de la répétabilité, pas du seul chargement initial du projet.

32 Go ou 64 Go : le choix dépend de la simultanéité

Pour compiler Mojo avec un objectif complet mais sans charge locale importante, commencez la mesure à 32 Go. Pour conserver un service de modèle, un agent actif, un indexeur et les tests Bazel pendant la compilation, commencez l’acceptation à 64 Go. Si votre équipe travaille principalement en alternance, une capacité inférieure peut rester rationnelle ; si la simultanéité est une exigence, elle doit être testée sans compromis.

Capacité, durée et coût de l’erreur

Les paliers de mémoire ne sont pas quatre fiches produit indépendantes. Ils correspondent à des niveaux de risque opérationnel.

Choisissez 16 Go si :

• votre objectif est une cible limitée ou un outil précompilé ;
• vous acceptez d’exécuter l’agent et la compilation à des moments différents ;
• vous avez un script de reproduction et une solution de repli ;
• vous vérifiez que la pression mémoire revient à un niveau normal après le test.

Choisissez 24 Go si :

• votre projet est plus large qu’une simple vérification ;
• vous pouvez limiter Bazel et fermer les charges graphiques ou d’indexation ;
• vous cherchez un palier intermédiaire avant de financer une machine plus grande ;
• vous acceptez qu’un clean build complet doive encore être confirmé.

Passez à 32 Go pour l’essai de référence si :

• vous devez construire le compilateur depuis les sources ;
• vous voulez comparer clean build et build incrémental ;
• vous exécutez des tests Bazel, mais l’agent local n’est pas constamment sollicité ;
• la réussite complète compte davantage que le meilleur temps obtenu.

Commencez à 64 Go si :

• le service de modèle doit rester actif pendant la compilation ;
• l’agent lance réellement des appels d’outils et une indexation ;
• plusieurs actions Bazel doivent fonctionner en parallèle ;
• un ralentissement prolongé ferait perdre plus de temps que le coût d’un environnement de test plus grand.

Cette logique rejoint les options matérielles publiées pour le Mac mini par Apple, mais les spécifications du constructeur ne constituent pas une validation de Mojo. Utilisez la page officielle des caractéristiques du Mac mini pour confirmer les capacités proposées au moment de votre achat ou de votre location, puis validez votre propre charge.

La location est pertinente lorsque le coût principal est l’incertitude : vous ne connaissez pas encore le commit final, le niveau de parallélisme acceptable ou la charge réelle de l’agent. Dans ce cas, préparez deux scripts : un clean build reproductible et un scénario concurrent. Comparez deux capacités voisines dans la même période, avec la même procédure. Le centre d’aide MacHTML peut servir de point de départ pour organiser la préparation et la collecte des informations de session.

L’achat devient plus cohérent lorsque le workload est stable, exécuté fréquemment et conservé pendant une longue période. Il reste toutefois nécessaire de distinguer une machine de contribution personnelle, un poste d’intégration partagé et un environnement de validation temporaire. Une configuration confortable pour un développeur qui alterne les tâches peut devenir insuffisante pour une équipe qui lance simultanément compilation, tests, agent et outils créatifs.

Procédure de mesure reproductible

Suivez cette séquence avant de conclure qu’un palier est suffisant.

Préparez le périmètre. Écrivez la cible exacte, le commit, les options Bazel, le profil d’agent et la définition de réussite. Indiquez si vous testez le compilateur, la bibliothèque standard ou une suite complète.

Préparez l’environnement. Installez la version de la chaîne prévue par la documentation officielle. Notez les outils actifs, les répertoires de cache et les dépendances déjà présentes. Ne comparez pas une machine fraîche avec une autre déjà préparée sans le signaler.

Lancez le clean build. Supprimez uniquement les caches que votre protocole demande de supprimer. Enregistrez l’heure de début, le temps total, la cible et le code de sortie. Une capture du début de commande n’est pas une preuve de réussite.

Surveillez le système. Observez la pression mémoire, l’échange, la réactivité et le comportement des processus. Notez le pic, mais aussi la durée de la saturation. Une pointe brève et un échange continu n’ont pas la même conséquence.

Répétez avec un seul changement. Réduisez le parallélisme ou désactivez l’agent, mais pas les deux à la fois. Conservez le reste identique afin d’identifier la cause de l’amélioration.

Ajoutez la charge locale. Rejouez le service au repos, puis le contexte long, les appels d’outils et l’indexation. Le scénario final doit faire fonctionner l’agent et la construction ensemble si c’est votre besoin réel.

Classez la décision. Notez la réussite, la marge observée, l’échange, la répétabilité et le temps acceptable. Classez ensuite le résultat comme « vérification limitée », « clean build seul », « tests avec marge » ou « concurrence validée ».

Vous pouvez conserver les journaux dans la console MacHTML si votre procédure de test repose sur une session distante. L’objectif n’est pas d’obtenir un joli chiffre, mais de pouvoir refaire le même essai après une mise à jour du dépôt ou du modèle.

Décision conditionnelle

• Si la cible limitée termine sur 16 ou 24 Go, sans échange durable, alors gardez ce palier pour l’exploration ou l’alternance ; sinon, revenez à un objectif plus étroit ou louez une capacité supérieure.
• Si le clean build complet termine deux fois avec des paramètres identiques sur 32 Go, alors considérez 32 Go comme un point de départ mesuré ; sinon, ne le qualifiez pas de capacité suffisante.
• Si l’agent et la compilation terminent ensemble, avec les tests prévus et une machine encore réactive, alors la capacité testée entre dans votre shortlist ; sinon, démarrez la comparaison suivante à 64 Go.
• Si votre équipe répète ce workload chaque semaine et connaît sa charge, alors l’achat peut être justifié ; si le besoin change selon les contributions, les modèles ou les branches, alors une location de courte durée réduit le risque de mauvais dimensionnement.
• Si le budget est limité mais que la concurrence n’est pas indispensable, alors planifiez une alternance contrôlée ; si la compilation et l’agent doivent rester actifs simultanément, alors ne sacrifiez pas la validation pour conserver un palier moins cher.

Un Mac déjà disponible peut sembler économique, mais il présente trois défauts fréquents : sa capacité est imposée, son historique de caches rend les comparaisons incertaines et son ralentissement bloque votre poste de travail quotidien. Un environnement distant ou une machine louée ajoute une étape de préparation, mais vous permet de tester une capacité voisine sans immobiliser votre ordinateur principal. Pour ce type de décision, louer un Mac auprès de MacHTML offre surtout un environnement réinitialisable et une comparaison mesurable, avant de vous engager dans un achat durable ; commencez par définir votre script Mojo et demandez une session adaptée depuis la page française de MacHTML.