2026 Mac: 32 ГБ или 64 ГБ — что выбрать для локального Agent и Mojo?

Модель запускается, но полный вызов инструментов завершается ошибкой памяти, а параллельная сборка Mojo вытесняет локальный Agent.

Быстрое решение: если нужен один квантованный экземпляр, короткий контекст и компиляция в другое время, сначала тестируйте Mac с 32 ГБ; для длинного контекста, нескольких инструментов, одновременной сборки Mojo и командного доступа приоритетом должен стать Mac с 64 ГБ.

Эта статья рассчитана на три группы:

• личных разработчиков, которым важно завершить прототип локального Agent, а не только загрузить модель;
• разработчиков Mojo и участников открытых проектов, совмещающих модельный сервис со сборкой и тестами;
• технических руководителей, которым нужно сравнить реальную поставку на 32 ГБ и 64 ГБ до покупки.

2026 Mac 32 ГБ или 64 ГБ: решение по типу нагрузки

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

Единая память означает, что модель, графический процессор, приложение, IDE и система используют общий пул. В документации разработчика это описывается через механизм unified memory, а не как отдельная видеопамять: описание единой памяти устройства. Поэтому свободное место после загрузки модели не равно безопасному запасу для рабочего процесса.

Условие для 32 ГБ

Mac с 32 ГБ разумно выбирать для личного прототипа, если одновременно выполняются следующие условия:

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

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

Условие для 64 ГБ

Mac с 64 ГБ получает преимущество, когда память должна одновременно обслуживать несколько независимых потребителей:

• локальный Agent с длинной историей;
• документы из репозитория или RAG-контекст;
• кодовый индекс;
• браузерную автоматизацию;
• IDE и контейнеры;
• Mojo-компиляцию, тестирование и фоновые процессы.

64 ГБ не превращают конкретную модель в более быструю и не гарантируют фиксированную скорость. Ценность этой конфигурации — в запасе для полного сценария. Она дольше сохраняет предсказуемость, когда задача выходит за пределы «запустил модель — получил один ответ».

Опытный ориентир: если команда не может заранее определить, в какой момент остановит модельный сервис ради компиляции, 32 ГБ следует рассматривать как тестовый вариант, а не как окончательное рабочее решение.

Личный разработчик: что означает «достаточно» для локального Agent

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

MLX-LM поддерживает квантизацию и работу с крупными моделями на чипах Mac; это подтверждается описанием проекта MLX-LM. Однако квантизация уменьшает размер весов, а не отменяет остальные расходы. Нужны память под рабочие тензоры, состояние генерации, KV Cache, сам процесс сервера и операционную систему.

В реализации кэша MLX-LM предусмотрены разные варианты хранения состояния, включая кэш фиксированного размера: исходный код механизмов KV Cache. Для разработчика это означает следующее:

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

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

Для автоматического продолжения диалога важна и подсказочная кэшировка. Инструмент кэширования промптов в MLX-LM показывает, что повторное использование префикса — отдельная оптимизация, а не бесплатное исчезновение расходов. Кэш нужно учитывать в общей картине, особенно если параллельно открыты несколько сессий.

Достаточно ли Mac с 32 ГБ для локального Agent?

Да, если речь идёт о контролируемом прототипе. В таком режиме разработчик принимает ограничения заранее:

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

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

Какие потери возникают при экономии памяти

У ограничения KV Cache есть цена. Сессия может хуже сохранять ранние детали. При сокращении RAG-документов Agent получает меньше исходных данных. При уменьшении количества параллельных задач падает пропускная способность команды. При остановке модели перед компиляцией исчезает непрерывность рабочего процесса.

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

Длинный контекст против запаса памяти: где 64 ГБ дают реальную пользу

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

В MLX-LM параметры генерации и состояние кэша задаются через интерфейс генерации; это видно в документации функции generate. Из этого следует важный критерий сравнения: одинаковая модель при разном контексте — не одинаковая нагрузка.

Сценарий проверки	32 ГБ	64 ГБ	Что считать приемлемым
Один квантованный экземпляр, короткий диалог	Обычно подходит для первичной проверки	Даёт дополнительный запас	Полный ответ без вытеснения и ошибок
Agent с файлами и несколькими вызовами инструментов	Подходит при ограничении контекста	Надёжнее при растущей сессии	Завершение цепочки, а не только первого шага
Длинная история и RAG-документы	Требует строгой политики кэша	Предпочтительный вариант для экспериментов	Стабильность при повторных запусках
Модель и компиляция Mojo одновременно	Только при малом пике и проверенном сценарии	Основной кандидат	Сборка и Agent не срывают друг друга
Несколько пользователей или сервисов	Риск непредсказуемого давления	Лучше сохраняет запас	Стабильность при смене нагрузки

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

Третий вариант — не покупать большую память сразу, а уменьшить масштаб задачи. Например, можно ограничить число одновременно индексируемых документов, отключить вторую Agent-сессию или вынести компиляцию на отдельное время. Но это уже изменение продукта. Если такие ограничения ломают сценарий, 64 ГБ становятся не роскошью, а способом сохранить исходную постановку задачи.

Напоминание: сторонний материал о запуске Qwen3.8 27B в MLX может быть полезен как пример нагрузки, но его нельзя превращать в правило «24 ГБ — универсальный минимум». Описание теста Qwen3.8 27B нужно читать вместе с его квантизацией, контекстом и условиями запуска.

Разработчик Mojo: модель и компиляция на одной машине

Mojo 1.0 был выпущен официально 11 августа 2026 года; это зафиксировано в архиве релиза Mojo 1.0. Подтверждение открытого исходного кода появилось 18 августа 2026 года в официальном объявлении об открытии Mojo. Эти даты важны для планирования окружения, но сами по себе не дают универсального требования к объёму памяти.

При сборке проекта нагрузка складывается из нескольких частей:

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

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

Может ли инференс и сборка Mojo идти одновременно?

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

32 ГБ подходят для такого режима только при умеренной модели, контролируемом контексте и невысокой параллельности сборки. Для вклада в открытый проект, где нужно регулярно менять код, запускать тесты и держать Agent активным, 64 ГБ дают более безопасную основу.

Особенно рискованны такие сочетания:

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

Поэтому разработчику, который может остановить Agent и компилировать в отдельное окно, не обязательно сразу переходить на 64 ГБ. Разработчику, которому нужна непрерывная связка «Agent предложил изменение — Mojo собрался — тест прошёл», стоит начинать сравнение с 64 ГБ.

Многоинструментальный Agent: сравнение не по простоям, а по пику

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

Для оценки полезно разделить нагрузку на слои:

1. модель и её состояние генерации;
2. история и кэш текущего диалога;
3. документы, индекс и результаты поиска;
4. инструменты — браузер, терминал, контейнеры;
5. IDE, компилятор и тесты;
6. система и удалённый доступ.

Пока сравнивается только простой ответ, Mac с 32 ГБ может выглядеть достаточно. Когда запускается пик — индексирование, вызов браузера, компиляция и новый запрос — запас исчезает. Поэтому многозадачность нужно проверять в момент максимального наложения процессов.

Для наблюдения следует использовать системный мониторинг. Руководство по контролю памяти и Memory Pressure помогает смотреть давление на память, использование swap и состояние системы. Эти показатели важнее ощущения «интерфейс пока не тормозит».

Наблюдение	Что оно показывает	Как влияет на выбор
Память растёт после каждого шага Agent	Кэш или история не освобождаются	Нужна политика сокращения либо больший объём
Давление повышается при старте сборки	Компилятор конкурирует с моделью	Для общего рабочего режима предпочтительнее 64 ГБ
Swap появляется только при редком пике	Сценарий можно ограничить расписанием	32 ГБ могут подойти при строгом разделении задач
Swap сохраняется в обычной сессии	Запаса недостаточно постоянно	Следует тестировать 64 ГБ или разделять сервисы
После завершения инструмента память не возвращается	Процесс или кэш удерживает ресурсы	Нужно искать причину, а не сразу покупать более крупную конфигурацию

Командная среда: вместимость против простоя

Для одного пользователя Mac с 64 ГБ может простаивать значительную часть дня. В этом случае покупка оправдана только тогда, когда 32 ГБ действительно срывают задачи или требуют постоянного ручного контроля.

В общей среде ситуация другая. Один пользователь может запускать Agent, второй — подключаться к IDE, а фоновая задача CI — начинать сборку. Даже если эти процессы не стартуют одновременно каждый раз, непредсказуемое наложение увеличивает риск.

Организация работы	Предпочтительный подход	Причина
Один разработчик, задачи выполняются по очереди	Сначала проверить 32 ГБ	Пик можно перенести по времени
Один разработчик, Agent и компиляция нужны постоянно	Сначала проверить 64 ГБ	Нельзя рассчитывать на ручное освобождение памяти
Небольшая команда с очередью задач	Сравнить стоимость очереди и большего Mac	Ожидание может быть дешевле простоя, но это нужно измерить
Несколько удалённых пользователей	64 ГБ обычно логичнее тестировать первой	Нагрузка менее предсказуема
CI и локальная разработка разделены	Рассмотреть отдельные окружения	Разделение часто надёжнее, чем один перегруженный Mac

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

Аренда перед покупкой: воспроизводимый тест вместо догадки

Для сравнения 32 ГБ и 64 ГБ нельзя менять всё одновременно. Иначе непонятно, повлияла ли память или другая версия модели, квантизация, контекст и параметры Agent.

Шаг 1. Зафиксировать рабочий профиль

В тестовый документ нужно записать:

• версию модели;
• способ квантизации;
• целевой размер контекста;
• системную инструкцию;
• набор документов;
• перечень инструментов;
• версию MLX-LM;
• версию Mojo;
• команды сборки и тестирования.

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

Шаг 2. Подготовить одинаковое окружение

На обоих Mac должны совпадать код, модельные файлы, переменные окружения и сценарии запуска. Не следует на одной машине оставлять открытый браузер или контейнер, а на другой — нет. Иначе сравнение покажет не разницу между 32 ГБ и 64 ГБ, а разницу в фоне.

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

Шаг 3. Прогнать Agent от начала до конца

Тест должен включать не только генерацию. Последовательность может быть такой:

1. загрузить модель;
2. отправить короткий запрос;
3. добавить файл из репозитория;
4. выполнить поиск по документам;
5. вызвать терминал или другой инструмент;
6. вернуть результат в диалог;
7. повторить задачу с накопленной историей;
8. завершить сессию и проверить, освободилась ли память.

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

Шаг 4. Добавить Mojo-сборку

Сначала сборка запускается отдельно. Затем — при работающем Agent. После этого добавляются тесты и индексирование IDE. Так становится видно, на каком сочетании возникает пик.

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

Шаг 5. Записать показатели

Минимальный журнал должен содержать:

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

Показатель скорости одного ответа не заменяет стабильность. Быстрый ответ на короткий запрос ничего не говорит о работе с длинным контекстом и компиляцией.

Шаг 6. Повторить сценарий в нескольких режимах

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

Операционные детали, включая управление сессиями и биллинг, следует сверять через раздел оплаты ProxyMac, а не смешивать с результатами производительного теста.

Результат испытания	Решение
Все этапы проходят, swap не появляется в обычном режиме, контекст контролируется	Можно рассматривать 32 ГБ для личного проекта
Agent отдельно стабилен, но сборка требует остановки сервиса	32 ГБ подходят только при разнесении задач по времени
Полный сценарий стабилен на 64 ГБ, а на 32 ГБ появляются срывы	Для этой нагрузки выбирать 64 ГБ
Обе конфигурации срываются на одинаковом этапе	Увеличивать память недостаточно: нужно менять модель, квантизацию или архитектуру
Команда редко использует пик и может ставить задачи в очередь	Сравнить аренду, очередность и раздельные окружения до покупки

Если 32 ГБ или 64 ГБ не закрывают задачу

Не каждый сбой решается добавлением памяти. Если проблема вызвана неподходящей квантизацией, ошибкой в инструменте, утечкой процесса или чрезмерным размером документов, Mac с 64 ГБ лишь отложит отказ.

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

• подтвердить, что используется нужная модель и версия;
• проверить, растёт ли KV Cache вместе с диалогом;
• исключить зависший процесс после завершения инструмента;
• повторить задачу без браузера и контейнеров;
• сравнить короткий и длинный контекст;
• отдельно выполнить Mojo-сборку;
• только после этого сопоставлять 32 ГБ и 64 ГБ.

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

Текущая машина или Mac через ProxyMac

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

Для временной разработки, проверки длинного контекста или сравнения совместной работы Agent и Mojo аренда Mac через ProxyMac практичнее, чем немедленная покупка. Сначала стоит подготовить воспроизводимый сценарий, прогнать его на 32 ГБ и 64 ГБ, записать давление на память и swap, а затем решить, нужна ли постоянная аренда, собственный Mac или разделение inference и компиляции на разные окружения. Такой подход снижает риск переплатить за редкий пик и одновременно не оставляет команду с конфигурацией, которая работает только в демонстрационном режиме.