Золотая клетка на 64 гигабайта
Ты купил MacBook Pro M3 Max или M4 с 64 ГБ ОЗУ. Заплатил лишнюю тысячу долларов, чтобы "летали" локальные нейросети. Скачал Qwen 3.5 35B, запустил - и получил 1-2 токена в секунду. Система начала подтормаживать, а в Activity Monitor красным светится memory pressure. Ты в ловушке.
64 ГБ ОЗУ на Apple Silicon в 2026 году - это самый коварный конфиг для локальных LLM. Достаточно для 7B-14B моделей, которые работают шустро, но слишком мало для 35B-70B, которые должны быть умнее. Результат? Мёртвая зона производительности. Модель загружается, но отвечает так медленно, что проще загуглить. Или отправить запрос в облако.
Холодная математика: почему 35B модель требует 70+ ГБ
Забудь про параметры модели. Запомни правило: для запуска LLM в FP16 (половинной точности) нужно примерно 2 байта на параметр. Qwen 3.5 35B? Это 35 миллиардов параметров. 35B * 2 байта = 70 ГБ. Просто чтобы загрузить веса. Без учёта кэша ключей-значений, контекста, системных процессов.
Квантование Q4_K_M (4-битное, среднее качество) сокращает это до 35 ГБ. Звучит отлично для 64 ГБ системы? Теория разбивается о практику.
| Модель (2026) | Тип квантования | Память модели | + Кэш (8K контекст) | Итого на Mac с 64 ГБ |
|---|---|---|---|---|
| Qwen 3.5 27B | Q4_K_M | ~27 ГБ | ~8 ГБ | 35 ГБ + система = жёсткий своп |
| Qwen 3.5 35B | Q4_K_M | ~35 ГБ | ~10 ГБ | 45 ГБ + система = смерть |
| DeepSeek 67B | Q3_K_M | ~42 ГБ | ~15 ГБ | 57 ГБ - даже не пытайся |
Кэш ключей-значений - вот скрытый убийца. Для контекста в 8 тысяч токенов он добавляет 8-15 ГБ. Системе macOS нужно минимум 8-10 ГБ для нормальной работы. Итого: 35 (модель) + 10 (кэш) + 10 (система) = 55 ГБ. Memory pressure переходит в желтую зону, начинается компрессия памяти, потом своп на диск. Скорость падает с 10-15 токенов/сек до 1-2.
Не верь цифрам из таблиц в интернете, где пишут "35B модель в Q4 работает на 64 ГБ". Работает - да. Но с контекстом в 512 токенов и без учёта системных процессов. В реальной жизни тебе нужен контекст хотя бы 4K для нормальных задач. И вот здесь начинается ад.
MLX против llama.cpp: битва за каждый мегабайт
В 2026 году у тебя два основных фреймворка для запуска LLM на Apple Silicon: родной MLX от Apple и проверенный llama.cpp. Выбор между ними определяет, останешься ты в мёртвой зоне или выберешься.
MLX: родной, но прожорливый
MLX оптимизирован под Apple Silicon. Использует Unified Memory, эффективно распределяет данные между CPU и GPU. Но у него есть фатальный недостаток для 64 ГБ систем: он не умеет эффективно управлять памятью при перегрузке. Загрузил модель на 55 ГБ? MLX будет пытаться использовать всё, что осталось, для кэша, пока система не рухнет.
Новые версии MLX 0.14 (актуально на 02.04.2026) добавили streaming-загрузку слоёв, но это не решает проблему с кэшем. Плюс, комьюнити создало меньше квантованных моделей под MLX формат по сравнению с GGUF для llama.cpp.
llama.cpp: старый, но мудрый
llama.cpp научился жить в условиях ограниченной памяти. Ключевые фичи для 64 ГБ Mac:
- --mlock: запрещает системе свопить память модели. Звучит контрпродуктивно, но иногда помогает избежать фрагментации.
- --no-mmap: загружает модель целиком в RAM. Да, требует больше памяти сразу, зато нет непредсказуемого свопа.
- Точный контроль слоёв GPU: можешь указать, сколько слоёв отправить на GPU (--ngl). Остальное останется в RAM.
Но даже llama.cpp не делает чудес. Если модель с кэшем занимает 58 ГБ из 64, система начнёт убивать процессы. Включая твою LLM.
Если хочешь глубже разобраться в выборе железа, посмотри сравнение чипов Apple Silicon - там есть цифры по реальной пропускной способности памяти.
План спасения: три шага из мёртвой зоны
1 Сбрось ожидания или долай память
Жёсткий выбор: либо опускайся до 27B моделей, либо поднимайся до 128 ГБ. Среднего не дано.
Вариант А (экономный): бери Qwen 3.5 27B в Q4_K_M. Она займёт ~27 ГБ, плюс кэш 8 ГБ, плюс система 10 ГБ = 45 ГБ. Остаётся 19 ГБ запас - достаточно для работы в фоне. Скорость: 12-18 токенов/сек на M4 Max.
Вариант Б (радикальный): продай Mac с 64 ГБ и купи с 128 ГБ. Да, дорого. Но для 35B-70B моделей это единственный способ получить нормальную производительность. 128 ГБ позволяют запускать 35B в Q4 с контекстом 16K и ещё остаётся место для системы.
2 Экстремальное квантование - твой друг и враг
Q4_K_M - это стандарт. Но для 64 ГБ системы нужно смотреть на Q3_K_M и даже Q2_K. Да, качество падает. Но скорость и возможность работать с нормальным контекстом того стоят.
Возьми Qwen 3.5 32B (есть такая версия) в Q3_K_M. Занимает ~24 ГБ. Плюс кэш 8 ГБ. Итого 32 ГБ. На 64 ГБ системе это комфортно.
Новые методы квантования на 2-3 бита, типа IQ2_XS, показывают удивительное сохранение качества при сокращении памяти на 40-50%. Но их поддержка в llama.cpp экспериментальная. Подробнее про это в гайде про GLM-4.5-Air на 2-3 битных квантованиях.
# Пример запуска 32B модели в Q3_K_M с контролем памяти
./main -m qwen3.5-32b-q3_k_m.gguf \
-c 4096 \
--mlock \
--no-mmap \
--temp 0.7 \
-ngl 35 # 35 слоёв на GPU, остальные в RAM3 Убей своп, прежде чем он убьёт тебя
macOS любит свопить. Даже когда память не исчерпана. Для LLM это смерть.
Первое - отключи memory compression. Второе - ограничь своп файл. Третье - убивай все лишние процессы перед запуском LLM.
Полная инструкция есть в статье про отключение сжатия памяти в macOS. Кратко:
# Отключить сжатие памяти (требует перезагрузки)
sudo nvram boot-args="vm_compressor=1"
# Ограничить своп (не рекомендуется для повседневного использования)
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist
sudo rm /private/var/vm/swapfile*
Отключать своп полностью - опасная игра. Если памяти не хватит, система начнёт убивать процессы без предупреждения. Делай это только если ты уверен, что не выйдешь за 55-58 ГБ потребления.
Ошибки, которые совершают все (и ты тоже)
- Запуск 35B модели в 8-битном квантовании. Требует 70 ГБ. На 64 ГБ системе это гарантированный краш или своп до 1 токена/сек.
- Использование контекста больше 4K. Каждые 1000 токенов контекста добавляют 1-2 ГБ к кэшу. 8K контекста = +8-16 ГБ. На 64 ГБ системе оставь 4K максимум.
- Запуск через веб-интерфейс типа Ollama без настройки параметров. Ollama по умолчанию старается загрузить всё в память и не контролирует кэш. Настрой вручную или используй llama.cpp напрямую.
- Игнорирование memory pressure. Жёлтая полоска в Activity Monitor - это уже приговор производительности. Красная - значит, ты теряешь 90% скорости на свопе.
Если столкнулся с галлюцинациями больших моделей на Mac, проверь статью про исправление галлюцинаций GPT-OSS-120B - многие проблемы одинаковы для 35B+ моделей.
Когда сдаваться и уходить в облако
Жёсткая правда: если тебе действительно нужны способности модели 35B-70B для продакшена, а не для экспериментов, 64 ГБ Mac - не твой выбор.
Варианты:
- Арендуй облачный GPU с 80+ ГБ памяти. Дешевле, чем апгрейд Mac. Но сложнее в настройке.
- Используй API типа OpenAI o1 или Claude 3.5 Sonnet. Дорого в долгосрочной перспективе, зато без головной боли.
- Собери PC с 128+ ГБ DDR5 и NVIDIA RTX 4090. Изначальная инвестиция больше, но зато полный контроль и скорость.
Для серьёзной работы с кодом на больших моделях смотри сравнение Qwen 122B и GPT-OSS-120B на Mac M5 128GB. Там цифры, которые показывают, почему 128 ГБ - это новый минимум для production.
Будущее: 2026 и дальше
К концу 2026 года ситуация может измениться. Apple анонсировала технологию "LLM in a Flash", которая позволяет запускать модели, в 4-5 раз превышающие объём доступной памяти. Но пока это исследовательский проект. Если хочешь поэкспериментировать, читай про метод запуска Qwen 397B на обычном железе.
Мой прогноз: к 2027 году 128 ГБ станет стандартом для Mac под локальные LLM. 64 ГБ останется для 7B-14B моделей и лёгких задач. А 35B-70B зона либо уйдёт в облако, либо потребует специального железа.
А пока что - выбирай Qwen 3.5 27B в Q4, настраивай llama.cpp с --mlock и молись, чтобы macOS не решила сделать фоновый апдейт в момент генерации.
