2026 Mojo compiler: компиляция из исходного кода на Mac — не хватает памяти?

18 августа 2026 года Mojo compiler и toolchain были опубликованы под лицензией Apache 2.0 с исключениями LLVM — это подтверждает официальное объявление Modular. Но открытый исходный код не означает, что каждому нужно собирать compiler локально. Наше решение на текущей неделе такое: если требуется читать, отлаживать или менять сам compiler, запускайте build-mojo; для стандартной библиотеки, примеров и MAX выбирайте prebuilt-mojo, а при повторяющемся давлении на память переносите полную сборку на высокопамятный удалённый Mac. Надёжного официального минимума памяти именно для полной сборки на Apple Silicon Mac пока нет, поэтому решение следует принимать по журналам, пиковому потреблению и стабильности повторных запусков, а не по универсальной цифре.

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

Последняя проверка выполнена 26 августа 2026 года; команды и ограничения сверены с репозиторием modular, его инструкцией сборки и официальными требованиями Mojo. При изменении конфигураций Bazel, ограничений MAX или политики contribution этот материал потребуется перепроверить.

Точка выбора: нужен ли локальный compiler

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

• build-mojo нужен, когда требуется собрать compiler из локального исходного кода, поставить точку останова в его компонентах, проверить изменение внутреннего прохода или исследовать поведение самого toolchain;
• prebuilt-mojo загружает nightly-сборку и подходит для обычной разработки, примеров и большинства задач, где compiler менять не нужно;
• MAX-цели остаются отдельным случаем: согласно официальным указаниям, для сборки MAX kernels или models всё ещё нужен предварительно собранный compiler, поэтому локально собранный Mojo compiler не следует считать универсальной заменой prebuilt-mojo.

Иными словами, модификация стандартной библиотеки сама по себе обычно не требует пересборки compiler. Сначала стоит проверить её с готовым compiler и собрать только соответствующую часть проекта. Полный build-mojo оправдан тогда, когда изменение затрагивает compiler, tooling или взаимодействие между ними. Это особенно важно сейчас: исходники уже опубликованы, однако compiler и tooling пока не принимают внешние contributions. Официально заявлена цель открыть такую возможность до конца 2026 года, но это план, а не завершённое событие.

Для команды полезно заранее разделить рабочие каталоги и ожидания:

• исследование compiler — локальный или удалённый build-mojo;
• разработка стандартной библиотеки — сначала prebuilt-mojo;
• запуск примеров — prebuilt-mojo;
• MAX kernels и models — prebuilt-mojo в соответствии с текущей официальной схемой;
• проверка гипотезы о compiler — минимальная локальная сборка, а не полный набор тестов.

Такой выбор предотвращает типичную ошибку: несколько часов искать причину нехватки памяти, хотя задача изначально не требовала локального compiler.

Базовая проверка Apple Silicon Mac

До первого запуска Bazel мы записываем состояние среды. Это не формальность: без такой записи невозможно понять, был ли сбой вызван отсутствующим инструментом, конкретным действием Bazel или общим истощением ресурсов.

Проверьте последовательно:

• архитектуру Mac и совместимость с текущими системными требованиями Mojo;
• версию macOS;
• наличие Xcode либо Command Line Tools, если они требуются текущей инструкцией;
• состояние репозитория и точный commit, на котором выполняется сборка;
• доступность wrapper bazelw, а не случайного Bazel из другой установки;
• наличие Metal toolchain и связанных компонентов, если выбранная цель их использует.

Актуальные общие требования к Mojo собраны в официальной документации по началу работы. Однако слово «минимальные» в системных требованиях нельзя превращать в гарантию полной сборки compiler. Общая планка для разработки не является опубликованным нижним пределом для крупной Bazel-сборки исходников на Mac.

Перед запуском сохраните четыре наблюдения:

• доступную unified memory;
• свободное место на диске;
• процессы, которые уже потребляют значительный объём памяти или CPU;
• состояние memory pressure и swap в Activity Monitor.

Для проверки последнего пункта используйте описание графика памяти в Activity Monitor от Apple. Важна именно динамика: свободная память сама по себе не доказывает наличие проблемы, тогда как красная или жёлтая memory pressure вместе с растущим swap показывает, что сборка конкурирует с остальной системой.

Важно: не фиксируйте в командной документации фразу «для compiler достаточно столько-то гигабайт». Официальный проект не публикует надёжный минимум для полной сборки на Apple Silicon Mac, а конкретный пик зависит от commit, цели, кэша и параллелизма Bazel.

Первый проход через минимальную цель

Первый запуск должен отвечать на узкий вопрос: может ли текущая среда собрать минимальную цель KGEN:mojo. Не начинайте с полного тестового набора и не смешивайте диагностику compiler с проверкой всей инфраструктуры.

Действуйте так:

• перейдите в заранее зафиксированный commit репозитория;
• убедитесь, что wrapper запускается из корня проекта;
• выполните официальную команду для цели KGEN:mojo с конфигурацией build-mojo, сверяясь с разделом сборки репозитория;
• если текущая инструкция репозитория использует указанную цель напрямую, начните с ./bazelw run --config=build-mojo //KGEN:mojo;
• одновременно откройте Activity Monitor и сохраните момент максимальной memory pressure;
• после завершения запишите код выхода, последнюю фазу Bazel, объём swap и сообщения об остановленном процессе;
• не запускайте сразу полный набор тестов: сначала повторите минимальную цель, чтобы понять, воспроизводится ли результат.

Для сравнения готового пути применяйте соответствующую конфигурацию prebuilt-mojo, но только после того, как исходный сценарий и путь к бинарному файлу записаны отдельно. Названия целей и параметры следует сверять с текущей версией bazelw: репозиторий может изменить команду, и устаревшая строка из статьи не должна считаться источником истины.

В логах следует различать «compiler не собрался» и «система остановила отдельное действие». Формулировки вроде killed, memory pressure, аварийное завершение процесса или внезапный обрыв без диагностической ошибки указывают на ресурсную проблему, но сами по себе ещё не доказывают, что причина именно в объёме unified memory. Отдельное действие может завершиться из-за ошибки инструмента, повреждённого кэша или нехватки места.

После успешной сборки выполните минимальный Mojo-файл. Важно не просто увидеть рабочий результат, а проверить происхождение compiler. Очистите или изолируйте путь к ранее установленному nightly, явно укажите бинарный путь, созданный локальной сборкой, и сохраните команду запуска. Иначе переменная PATH может незаметно направить пример к prebuilt-mojo, создав ложное впечатление, что build-mojo завершился успешно.

Для этой проверки полезно записать:

• commit исходников;
• путь к исполняемому файлу;
• использованную Bazel-конфигурацию;
• вывод версии compiler;
• результат минимального Mojo-примера.

Так появляется воспроизводимая граница между «Bazel построил локальный compiler» и «в окружении уже был готовый compiler».

Причины остановки Bazel и порядок реакции

Когда Mac начинает активно использовать swap или система завершает Bazel, не стоит сразу увеличивать виртуальную память и повторять ту же команду. Сначала разделите проблему на четыре ветви.

Системное давление на память. Если memory pressure ухудшается одновременно с ростом swap и остановкой нескольких тяжёлых процессов, освободите среду: закройте параллельные сборки, симуляторы, виртуальные машины и другие задачи, которые не нужны для эксперимента. Затем повторите только минимальную цель.

Избыточная параллельность Bazel. Если память резко расходуется на множество одновременных действий, ограничьте локальный параллелизм Bazel или скорректируйте объявленные ресурсы. Точные флаги и допустимые значения нужно брать из текущего справочника командной строки Bazel, а не переносить из старого сообщения на форуме. После изменения параметров сохраните их в журнале, иначе команда не сможет сравнить результаты.

Недостаток места на диске. Большие кэши и промежуточные артефакты могут привести к сбою, который внешне похож на нехватку памяти. Проверьте свободное место, сообщения файловой системы и размер Bazel-кэша. Удалять кэш следует только после фиксации commit и параметров: иначе исчезнет возможность сравнить холодную и последующую сборку.

Аномальное отдельное действие. Если memory pressure остаётся умеренным, но один шаг завершается с ошибкой, ищите конкретный action в логе. Причиной могут быть Metal-компонент, несовместимая версия инструмента, ошибка генерации или повреждённый промежуточный файл. В этом случае переход на Mac с большей памятью не устранит первопричину.

Решающее дерево для следующего действия

Отметьте пункты, которые уже подтверждены наблюдениями. Выбор делается по первому подходящему условию, а не по субъективному ощущению, что сборка «просто слишком тяжёлая».

• [ ] Наблюдается жёлтая или красная memory pressure, swap растёт, процесс завершён системой. Сначала закройте фоновые нагрузки, уменьшите параллельность Bazel и повторите минимальную цель.
• [ ] Memory pressure остаётся нормальной, но лог указывает на Metal, SDK или другой отсутствующий компонент. Исправьте toolchain и повторите проверку; увеличение памяти здесь не является первым решением.
• [ ] Системные показатели стабильны, но завершается одно конкретное действие Bazel. Изолируйте action, проверьте кэш, версии инструментов и последнюю диагностическую строку.
• [ ] Минимальная цель проходит, но не удаётся сборка MAX kernels или models локальным compiler. Вернитесь к prebuilt-mojo: это ограничение рабочего пути, а не доказательство нехватки памяти.
• [ ] Изменяется только стандартная библиотека или запускаются примеры. Не пересобирайте compiler без необходимости; используйте prebuilt-mojo и проверяйте именно изменённый компонент.
• [ ] Требуется точка останова, изменение или исследование compiler. Оставьте build-mojo, но начните с минимальной цели и подтвердите путь к локальному бинарному файлу.
• [ ] После снижения параллельности и устранения фоновой нагрузки две холодные сборки снова завершаются по памяти. Перенесите полную сборку на удалённый Mac с большим объёмом unified memory.
• [ ] Два холодных запуска дают разные результаты без изменения commit и параметров. Не объявляйте среду готовой: сохраните логи и выясните причину нестабильности.

Этот список одновременно отвечает на пять практических вопросов: сколько памяти нужно для сборки из исходников, как выбирать между build-mojo и prebuilt-mojo, как разбирать системное завершение Bazel, требуется ли пересборка compiler для стандартной библиотеки и когда локальный Mac стоит заменить удалённым. Он не подменяет отсутствующие официальные данные выдуманным порогом памяти.

Metal toolchain, MAX и раздельная проверка конфигураций

Ошибка Metal toolchain — это не синоним ошибки памяти. Если сборка останавливается на поиске Metal-компонента, отсутствующем SDK или несовместимом инструменте, сначала исправьте toolchain. Базовые сведения о компонентах и направлении разработки собраны в официальной документации Metal.

Разделяйте доказательства по цепочке:

• memory pressure, swap и системное завершение процесса — признаки ресурсного сбоя;
• сообщение о missing toolchain, SDK или action — признак среды сборки;
• ошибка конкретной MAX-цели — повод проверить правило о необходимости prebuilt-mojo;
• ошибка только при запуске примера — возможная проблема пути к бинарному файлу или runtime.

Нельзя проверять всё одной командой. Создайте два отдельных сценария:

• сценарий build-mojo: минимальная цель compiler и минимальный Mojo-файл, запускаемый с локальным бинарным файлом;
• сценарий prebuilt-mojo: тот же минимальный пример, но с nightly compiler, загруженным официальной конфигурацией.

Сравнение должно выполняться на одном исходном примере и с явно указанными путями. Если результат отличается, проверьте PATH, Bazel-кэш и переменные окружения. Кэш способен скрыть отсутствие полноценной сборки, а смешанные пути — показать успех готового compiler как успех локального.

MAX нужно тестировать отдельно. Даже если build-mojo успешно собрал compiler, это не означает, что он поддерживает сборку MAX kernels или models. Для такой задачи возвращайтесь к prebuilt-mojo, пока официальная документация не изменит это ограничение.

Пять шагов к командной воспроизводимости

После первого успешного запуска не переходите сразу к свободному экспериментированию. Зафиксируйте процесс как короткий регламент.

Первый шаг — зафиксировать исходную точку. Сохраните commit репозитория, состояние ветки, версии macOS, Xcode или Command Line Tools, а также версию wrapper Bazel.

Второй шаг — разделить цели. В отдельные команды вынесите минимальную сборку compiler, запуск Mojo-примера, проверку стандартной библиотеки и MAX-сценарий. Это не позволит ошибке одного слоя маскировать другую.

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

Четвёртый шаг — повторить сборку. Успешный единичный запуск недостаточен. Повторите ту же цель после очистки или изолирования кэша и затем выполните ещё один запуск с теми же параметрами. Если результаты расходятся, среда пока не является надёжным build node.

Пятый шаг — определить маршрут отката. Для обычной разработки заранее укажите команду prebuilt-mojo; для тяжёлой полной сборки — удалённый Mac; для ошибок инструментов — процедуру проверки Metal и системных требований. Откат должен быть частью процесса, а не импровизацией после ночного зависания.

Такой журнал особенно полезен при смене устройств. Он показывает, что именно изменилось: commit, параметры Bazel, фоновые процессы, toolchain или сам Mac. Без него команда часто ошибочно связывает любой медленный запуск с памятью.

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

Опыт эксплуатации: если после ограничения параллельности и устранения фоновых задач холодная сборка всё ещё нестабильна, не объявляйте swap способом «добавить памяти». Для диагностики он допустим как наблюдаемый симптом, но не как надёжная основа постоянного compiler-build процесса.

Когда аренда удалённого Mac оправдана

Аренда удалённого Mac через JexMac может быть практичнее для временного исследования, проверки конкретного commit или командного build node, когда покупать отдельное устройство рано. При этом не стоит арендовать среду для постоянной стабильной нагрузки без расчёта общей стоимости и требований к физическим интерфейсам. Перед заказом сравните срок задачи, необходимость доступа к локальному железу, требования к приватности исходников и возможность сохранить окружение между сессиями; варианты условий можно посмотреть на странице аренды Mac у JexMac.

Текущая локальная схема имеет несколько недостатков: сборка конкурирует с редактором и другими процессами, время обратной связи становится непредсказуемым при swap, а команда может получить разные результаты на устройствах с неодинаковым окружением. Удалённый Mac не устраняет ошибку Metal, неправильный commit или повреждённый кэш, но при подтверждённом ресурсном ограничении даёт отдельный, контролируемый узел для полной сборки. Поэтому он оправдан не как безусловно более быстрый вариант, а как способ разделить интерактивную работу и тяжёлую воспроизводимую задачу.

Финальная проверка перед переносом должна быть предметной:

• [ ] локальный запуск останавливается по памяти, а не из-за Metal или повреждённого кэша;
• [ ] build-mojo действительно нужен, потому что меняется compiler;
• [ ] commit и toolchain можно воспроизвести на удалённом узле;
• [ ] удалённый доступ, хранение исходников и передача артефактов соответствуют требованиям команды;
• [ ] для повседневной работы сохранён быстрый путь через prebuilt-mojo;
• [ ] после переноса на удалённый Mac повторены минимальная цель, пример и проверка результата;
• [ ] в журнале указаны commit, параметры Bazel, окружение, пиковые ресурсы и код выхода.

Если отмечены только пункты о временном ресурсном ограничении и необходимости полной сборки, удалённая среда может быть оправдана. Если отмечен только пункт о MAX или стандартной библиотеке, сначала оставайтесь на prebuilt-mojo. Если не подтверждена сама причина сбоя, более мощный Mac лишь перенесёт проблему.

Текущий локальный вариант проигрывает при постоянной конкуренции за unified memory, длительном swap, непредсказуемых холодных сборках и различиях между рабочими станциями. При подтверждённом ресурсном барьере аренда Mac через JexMac даёт более управляемый временный build node без немедленной покупки отдельного устройства. Но для постоянной стабильной нагрузки, требующей гарантированного физического доступа к интерфейсам или особого режима хранения исходников, сначала следует сравнить аренду с покупкой собственного Mac и другими допустимыми средами. Решение должно вытекать из зафиксированных логов, а не из одного неудачного запуска.