Сколько унифицированной памяти Mac нужно для компиляции исходного кода Mojo в 2026 году?

Сборка Mojo запускается, но Mac начинает активно использовать swap, а локальный Agent перестаёт отвечать.

Быстрое решение: не переносите вывод о памяти для модели на компиляцию Mojo; для полного clean build начните проверку с 32 ГБ, а для одновременных Bazel-тестов и локального Agent — с 64 ГБ.

Кому нужен этот разбор

Эта инструкция предназначена тем, кто впервые собирает Mojo из исходников на Mac с Apple Silicon и хочет понять реальные границы существующей машины.

Она также пригодится AI-разработчикам, которым нужно держать рядом локальный Agent, сервис модели и инструменты разработки, а техническим руководителям — перед краткосрочной арендой Mac для воспроизводимого нагрузочного теста.

Данные о конкретном пиковом потреблении памяти нельзя считать универсальными: результат зависит от коммита Mojo, целей сборки, параметров Bazel, состояния кэша и одновременной нагрузки.

Последнее обновление — 28 августа 2026 года. Данные сверены с официальным объявлением об открытии исходного кода Mojo, репозиторием Mojo, документацией сборки и техническими характеристиками Mac mini.

Сначала определите, что именно вы собираете

Фраза «скомпилировать Mojo» описывает несколько разных операций. Они требуют разного запаса унифицированной памяти Mac.

• Предварительно собранный инструментальный пакет. Вы устанавливаете готовый компилятор и запускаете небольшой пример. Это проверка окружения, а не проверка способности Mac собрать компилятор.
• Изменение стандартной библиотеки. Объём работы больше, но часть артефактов может оставаться в кэше. Такой сценарий не равен первичной сборке репозитория.
• Сборка компилятора Mojo из исходников. Именно clean build следует использовать как базовую проверку, если вы планируете участвовать в разработке или регулярно переключаться между ветками.
• Полный набор тестов. После компиляции появляются дополнительные процессы, тестовые цели и параллельные задачи Bazel. Они меняют профиль памяти.
• Параллельный режим. Mojo собирается одновременно с локальным Agent, модельным сервером, индексатором кода и редактором. Это уже проверка рабочей станции, а не только компилятора.

Официальная документация описывает путь сборки из исходников и использование Bazel, но не устанавливает единственный порог памяти для всех целей и конфигураций. Проверяйте команды в документе Mojo по работе с исходным репозиторием, а структуру проекта — в официальном репозитории modular.

Поэтому корректная единица сравнения выглядит так: один и тот же коммит, одна и та же команда Bazel, одинаковое состояние кэша, одинаковые тесты и одинаковая нагрузка Agent.

Можно ли считать установку готового Mojo доказательством, что Mac соберёт Mojo из исходников?

Нет. Готовый пакет подтверждает совместимость установленного инструментария и вашей системы. Он не показывает пиковую нагрузку при компиляции самого репозитория, загрузке зависимостей и выполнении тестовых целей.

Пиковая память важнее сообщения «команда запустилась»

Для оценки памяти Mac фиксируйте не только момент старта. Процесс может успешно начать работу, а затем упасть на более тяжёлой цели, зависнуть из-за обмена с диском или завершить тесты с ошибками.

Минимальный набор наблюдений:

• достигнут ли clean build целиком;
• завершились ли выбранные Bazel-тесты;
• как менялось давление на память в Activity Monitor;
• увеличивался ли объём swap;
• сохранялась ли отзывчивость терминала, редактора и SSH-сессии;
• повторился ли результат после очистки кэша.

Apple рекомендует ориентироваться на показатель Memory Pressure, а не на свободную память как на единственный индикатор. Описание цветов и графика давления есть в руководстве Apple по Activity Monitor. В macOS свободная память может использоваться для кэширования, поэтому само по себе небольшое значение «free» ещё не доказывает дефицит.

Унифицированная память общая для CPU, GPU и приложений. Документация MLX о unified memory важна здесь не как источник порога для Mojo, а как объяснение конкуренции между модельным сервером и компилятором. Если Agent загрузил модель, компилятор не получает отдельный защищённый пул.

Не называйте swap запасным эквивалентом оперативной памяти. SSD может принять страницы памяти, но это не заменяет физическую пропускную способность и задержки unified memory. При длительной компиляции результатом становятся не только минуты ожидания: интерфейс может перестать отвечать, а повторяемость времени сборки ухудшится.

Как Bazel меняет картину нагрузки

Bazel способен выполнять независимые действия параллельно. Конкретное число рабочих процессов зависит от параметров запуска, окружения и доступных ресурсов. Полагаться только на значение по умолчанию нельзя: оно может дать хороший результат на повторной сборке, но оказаться слишком агрессивным на первом запуске.

Сравнивайте минимум два режима:

• дефолтные параметры, с которыми вы действительно планируете работать;
• контролируемая параллельность, заданная явно для диагностики.

Меняйте только один фактор за раз. Если одновременно включить больше workers, удалить кэш и добавить тесты, вы не узнаете, что именно вызвало рост давления на память.

Отдельно учитывайте следующие состояния:

• первая сборка с загрузкой зависимостей;
• повторная сборка с полным кэшем;
• инкрементальная сборка после небольшого изменения;
• clean build после переключения коммита;
• сборка с тестами.

Кэш сокращает работу, но не отменяет пиковую потребность в памяти для отдельных действий. Быстрая инкрементальная операция не является доказательством того, что Mac выдержит чистую сборку после очистки артефактов.

Полезно сохранять команду, параметры и итоговый статус в файл. Для анализа аргументов Bazel используйте официальный справочник командной строки Bazel. В отчёте должны быть не только слова «успешно» или «неуспешно», но и состояние кэша, выбранная параллельность, время начала и причина остановки.

Что записывать при аренде Mac для проверки компиляции Mojo?

Записывайте коммит Mojo, версию macOS, модель чипа, объём unified memory, команду сборки, параметры Bazel, состояние кэша, пик Memory Pressure, изменение swap, длительность и итоговый статус. Для параллельного теста добавьте версию и параметры Agent, модель, контекст, инструменты и сценарий воспроизведения.

Не подменяйте воспроизводимость большим количеством случайных наблюдений. Один и тот же сценарий на соседних объёмах памяти полезнее, чем разные команды на одной машине.

Память Agent нельзя складывать с пиком компилятора «на глаз»

Локальный Agent создаёт несколько независимых источников нагрузки:

• модельный сервер в состоянии ожидания;
• генерация с длинным контекстом;
• вызов инструментов;
• индексация репозитория;
• редактор, терминал и фоновые процессы;
• дополнительные тестовые или CI-задачи.

Третьесторонний материал о запуске Qwen 3 27B в формате MLX показывает, что оценка памяти модели зависит от квантования, контекста и конкретной конфигурации; это описание тестового сценария 27B в MLX, а не официальный порог для Mojo. Нельзя превращать утверждение о том, что 27B в определённом 4-битном режиме занимает заметную долю памяти, в правило «для Mojo нужно столько-то гигабайт».

Разделяйте два режима проверки.

Разнесённый по времени режим. Сначала собирается Mojo, затем запускается Agent. Так можно снизить минимальный объём для личной машины, если вы готовы останавливать модельный сервис во время clean build.

Настоящий параллельный режим. Agent принимает задачу, вызывает инструмент, индексирует код, а Bazel одновременно выполняет сборку или тесты. Только этот режим подтверждает конфигурацию для команды, которая не хочет вручную освобождать память.

Сценарий из практики выглядит так: разработчик меняет код стандартной библиотеки, запускает Bazel и оставляет Agent для поиска по репозиторию. При коротком запросе Agent всё может работать нормально. После длинного контекста и вызова инструмента начинается активный swap, хотя сама сборка ещё не завершилась. Приёмочный критерий здесь — полный цикл Agent плюс успешное завершение сборки, а не удачный запуск первой команды.

Условная граница между 16, 24, 32 и 64 ГБ

Apple указывает варианты unified memory для актуальных конфигураций Mac mini на официальной странице характеристик. Эти объёмы — аппаратные классы для сравнения, но не гарантии конкретного результата Mojo.

Используйте следующую схему решений.

• Если вы запускаете готовый инструмент, меняете небольшую цель или собираете ограниченный набор исходников без Agent, начните с 16 или 24 ГБ. Если появляется постоянный swap либо тесты не завершаются, переходите к контролируемой параллельности или к следующему объёму.
• Если вам нужен первый полноценный clean build из исходников, начинайте проверку с 32 ГБ. Это стартовая точка для измерения, а не обещание, что любая версия и любой набор целей завершатся без давления на память.
• Если Bazel-тесты должны выполняться вместе с локальным Agent, модельным сервером и индексатором, начинайте приёмку с 64 ГБ. Только после повторяемого теста решайте, нужен ли этот объём постоянно.
• Если 32 ГБ проходят сборку только после уменьшения параллельности и остановки Agent, это рабочий компромисс для раздельного по времени режима, но не доказательство пригодности для одновременной разработки.
• Если 64 ГБ завершают один тест, но следующий повтор уходит в swap, не фиксируйте результат как стабильный. Сначала повторите тот же сценарий с теми же параметрами.

Условия выбора перед арендой или покупкой

Поставьте отметку напротив каждого утверждения и двигайтесь сверху вниз:

• [ ] Нужен только готовый Mojo или ограниченная цель без локального Agent — начните с 16–24 ГБ.
• [ ] Нужен полный clean build, но Agent и модельный сервер можно остановить — проверяйте 32 ГБ.
• [ ] Нужны Bazel-тесты после clean build — не ограничивайтесь результатом инкрементальной сборки; повторите тест после очистки кэша.
• [ ] Agent должен оставаться активным во время компиляции и выполнять реальный вызов инструмента — начинайте сравнение с 64 ГБ.
• [ ] На меньшем объёме растёт swap, система теряет отзывчивость или результат не повторяется — не принимайте эту конфигурацию, даже если команда один раз завершилась.
• [ ] Сборка проходит только при сниженной параллельности, а такое ограничение допустимо для вашей команды — можно оставить меньший объём для раздельных задач.
• [ ] Требуется стабильная ежедневная параллельная работа без ручной остановки сервисов — выбирайте только конфигурацию, прошедшую два одинаковых прогона.

Если отмечены первые два пункта, обычно достаточно исследовать 16–32 ГБ. Если отмечены пункты о параллельном Agent, тестах и повторяемости, переходите к проверке 64 ГБ. Если последний пункт не подтверждён измерениями, решение о покупке преждевременно: сначала арендуйте соседние конфигурации и сравните их на одном сценарии.

Подойдёт ли Mac с 16 ГБ для сборки Mojo из исходников?

Иногда — для ограниченной цели, предварительной проверки или последовательного запуска задач. Но 16 ГБ нельзя заранее считать надёжной рабочей станцией для clean build, полного тестового набора и постоянно работающего Agent. Приёмка должна закончиться успешной сборкой и тестами, а не только запуском Bazel.

Когда выбирать Mac с 32 ГБ, а когда сразу с 64 ГБ?

32 ГБ разумны как нижняя точка измерения для полного clean build без тяжёлой параллельной нагрузки. 64 ГБ логичнее проверять, если Agent, Bazel, индексатор и модельный сервис должны оставаться активными одновременно. Если команда использует только короткие инкрементальные сборки и запускает модель по очереди, результат может быть иным.

Пошаговая процедура повторяемого теста

Первый этап — зафиксируйте цель. Запишите, что именно считается успехом: сборка компилятора, стандартной библиотеки, выбранные тесты или полный сценарий. Не смешивайте эти критерии в одну строку.

Второй этап — закрепите исходные данные. Сохраните коммит Mojo, ветку, версию macOS, модель Apple Silicon, объём памяти и свободное место на SSD. Свободное место нужно для артефактов и swap, но оно не повышает объём unified memory.

Третий этап — подготовьте чистое состояние. Очистите только те каталоги и кэши, которые указаны официальной процедурой для вашей цели. Зафиксируйте, была ли загрузка зависимостей выполнена заранее. Иначе два одинаковых запуска будут различаться по нагрузке.

Четвёртый этап — выполните clean build без Agent. Запустите официальную команду из документации Mojo, сохраните полный вывод и не меняйте параллельность во время теста. Одновременно наблюдайте Memory Pressure, swap и отзывчивость системы.

Пятый этап — повторите сборку с контролируемой параллельностью. Измените только параметр, отвечающий за число одновременных действий Bazel. Сохраните как успешный, так и неуспешный результат. Более длинная, но завершившаяся сборка полезнее быстрой, которая закончилась нехваткой памяти.

Шестой этап — добавьте тесты. Используйте тот же коммит и тот же режим кэша. Отдельно отметьте, завершилась ли компиляция, завершились ли тесты и не было ли остановки из-за внешнего процесса.

Седьмой этап — запустите Agent в холостом режиме. Зафиксируйте его модель, настройки контекста и активные инструменты. Затем выполните заранее подготовленный запрос с поиском по репозиторию и вызовом инструмента.

Восьмой этап — запустите сборку и Agent одновременно. Не заменяйте полный цикл коротким запросом. Агент должен выполнить обычную задачу, а Bazel — закончить выбранную сборочную или тестовую цель.

Девятый этап — повторите параллельный прогон. Сравните пик давления, изменение swap, время, ошибки и субъективную отзывчивость. Два одинаковых успешных прогона дают более надёжную основу, чем единичный удачный запуск.

Для командного процесса сохраните результаты в консоли MacHTML, если тест выполняется в предоставленной среде, а правила доступа и возврата окружения заранее проверьте в справочном центре MacHTML.

Как отличить оптимизацию от необходимости большего объёма

Уменьшение параллельности может быть полезным инженерным решением. Оно позволяет понять, какую цену вы платите за экономию памяти: большее время сборки, меньшую отзывчивость или невозможность запускать Agent параллельно.

Сначала оптимизируйте, если:

• clean build завершается;
• swap не растёт непрерывно;
• Memory Pressure возвращается к нормальному уровню после пика;
• Agent можно временно остановить;
• повторный запуск даёт сопоставимый результат.

Переходите на больший объём, если:

• сборка завершается только после ручного убийства процессов;
• система долго остаётся неотзывчивой;
• один и тот же сценарий то проходит, то падает;
• тесты конфликтуют с модельным сервером;
• уменьшение параллельности нарушает приемлемый рабочий процесс;
• вам приходится регулярно выбирать между Agent и компиляцией.

Не используйте свободное место на SSD как аргумент в пользу меньшего Mac. Оно помогает пережить обмен страницами, но не делает swap эквивалентом памяти. Для длительной разработки важна устойчивость серии сборок, а не возможность один раз дождаться окончания команды.

Что выгоднее: собственный Mac или короткая проверка

Покупка оправдана, если вы ежедневно выполняете одинаковые сборки, не зависите от физического USB-оборудования и уже подтвердили нагрузку на конкретном коммите. В этом случае сравнивайте не только объём памяти, но и срок использования, стоимость простоя, время повторной настройки и необходимость держать машину включённой.

Аренда Mac полезнее перед таким решением: вы можете прогнать один сценарий на соседних объёмах памяти, не принимая рекламную границу за технический факт. Это особенно важно, когда состав Agent меняется, модель обновляется, а Bazel-кэш скрывает реальную цену clean build.

Текущая машина с 16 или 24 ГБ может быть удобной для редактирования кода, но у неё есть три заметных ограничения: недостаточный запас для одновременной модели и компилятора, чувствительность к параллельности Bazel и риск длительного swap. Облачная Linux-среда решает часть задач, однако меняет окружение Apple Silicon, локальные инструменты и профиль unified memory. Покупка 64 ГБ без предварительной записи пиков тоже может оказаться избыточной.

Поэтому для Mojo разумнее сначала воспроизвести ваш скрипт на двух соседних конфигурациях, сохранив коммит, параметры, нагрузку Agent и результаты повторов. Если вам нужен именно такой временный стенд для проверки, аренда MacHTML даст более честное сравнение: вы измерите завершение задач и давление на память, а не выберете объём по тому, что модель однажды загрузилась. Для расчёта длительного сценария используйте варианты аренды MacHTML только после того, как определите требуемую конфигурацию и длительность теста.