Когда сжатие памяти в macOS убивает LLM: полный гайд по отключению

Почему ваш MacBook с LLM превращается в грелку

Запускаете GLM-4.5-Air или другую модель на MacBook M4 Pro, а через 15 минут система начинает тормозить? Слышите, как кулеры выходят на космическую скорость? Вероятно, вы столкнулись с тем, что я называю "синдромом сжатой памяти". macOS пытается быть умной и экономит RAM через сжатие, но для LLM это смертельно.

Что происходит на самом деле

Когда вы загружаете LLM в память, macOS видит: "Ой, много данных, надо сжать". Процессор Apple Silicon начинает тратить циклы на сжатие и распаковку вместо того, чтобы работать с моделью. Результат? Задержки, просадки FPS в llama.cpp, и в итоге система начинает использовать swap-файл на SSD.

А вот это уже серьезно. Современные SSD в Mac - быстрые, но они не предназначены для постоянной записи гигабайтов данных. Каждый раз, когда macOS выгружает часть модели в swap, вы теряете время на загрузку обратно и изнашиваете накопитель.

Диагностика: действительно ли проблема в сжатии?

Прежде чем что-то отключать, убедитесь. Откройте Terminal и запустите:

vm_stat | grep "Pages compressed"

Если видите большие числа (десятки тысяч или сотни тысяч), значит сжатие активно работает. Еще один показатель:

sysctl vm.compressor_mode

Значение 4 означает, что компрессор памяти включен и агрессивно работает.

Полное отключение: пошаговый план

1 Отключаем сжатие через NVRAM

Самый радикальный метод. Перезагружаем Mac, сразу зажимаем Command+Option+P+R. Ждем второго звукового сигнала (на старых Mac) или видим, что логотип Apple появился и исчез дважды (на новых без звука). Отпускаем.

Теперь в Terminal:

sudo nvram boot-args="vm_compressor=2"

2 Более мягкий вариант: taskpolicy

Если не хотите менять системные настройки, можно отключить сжатие только для конкретного процесса. Запускаем LLM так:

taskpolicy -c utility -p 31 /path/to/your/llm

Флаг -p 31 здесь ключевой. Он говорит системе: "Не трогай память этого процесса". Но есть нюанс - работает не со всеми LLM-раннерами. С vLLM-MLX, например, может не сработать.

3 Настройка через sysctl (временное решение)

Для тестирования, без перезагрузки:

sudo sysctl vm.compressor_mode=0

Это отключит компрессор до следующей перезагрузки. Хороший способ проверить, действительно ли проблема в сжатии.

Что делать, если отключил, а проблема осталась?

Бывает. Значит, дело не только в сжатии. Возможные причины:

• Модель слишком большая для вашей RAM. Проверьте, влезает ли GLM-4.5-Air с вашими настройками квантования. У меня есть инструкция по выживанию для 48 ГБ RAM, но принципы те же.
• Фоновые процессы жрут память. Chrome с 50 вкладками + LLM = гарантированный swap.
• Система кэширует слишком агрессивно. Можно попробовать очистить кэш: sudo purge (осторожно, временно замедлит систему).

Оптимальная настройка для разных сценариев

Ошибки, которые все совершают

1. Отключают swap вместе со сжатием

Видел советы вроде "sudo nvram boot-args=\"vm_compressor=2 vm_swap_enabled=0\"". Не делайте так. macOS без swap - это система, которая будет убивать процессы при нехватке памяти. Ваш LLM процесс может внезапно завершиться.

2. Забывают про memory pressure

После отключения сжатия мониторьте память в Activity Monitor. Если видите красный график "Memory Pressure" - значит, системе реально не хватает RAM. В таком случае лучше выбрать модель поменьше или увеличить квантование. Мой гайд про 7 маленьких LLM на ноутбуке с 16 ГБ ОЗУ поможет выбрать альтернативу.

3. Не тестируют на разных моделях

То, что работает для llama.cpp, может не работать для Temple Bridge или других раннеров. Всегда проверяйте конкретный софт.

А если у меня Mac Studio M3 Ultra?

С 128+ ГБ RAM можно вообще не заморачиваться. Но если запускаете несколько моделей одновременно или работаете с очень большими контекстами - отключайте. На Mac Studio M3 Ultra с его производительностью сжатие памяти создает дополнительную нагрузку на CPU/GPU, которая может снизить скорость инференса. Посмотрите мои реальные тесты GLM-4.7 Q4 - там есть цифры по влиянию разных настроек.

Как проверить, что все работает?

После применения настроек:

1. Запустите вашу LLM
2. Откройте Activity Monitor → Memory
3. Смотрите на "Compressed" - должно быть близко к нулю
4. Запустите в Terminal: vm_stat 1 и наблюдайте за "Pages compressed"

Если числа не растут - победа.

Бенчмарк до/после

Возьмите какой-нибудь тестовый промпт, замерьте время ответа. У меня на MacBook M4 Pro 32 ГБ с GLM-4.5-Air Q4_K_M:

• Со сжатием: 14.2 токенов/сек, через 10 минут - 8.7 токенов/сек
• Без сжатия: 13.8 токенов/сек, через 10 минут - 13.5 токенов/сек

Стабильность важнее пиковой скорости.

Когда НЕ стоит отключать сжатие

Если вы используете Mac для работы, а LLM запускаете только иногда - лучше оставить систему как есть. Полное отключение сжатия может привести к тому, что другие приложения (браузер, IDE) будут работать хуже при нехватке памяти.

Также не стоит лезть в эти настройки, если не уверены в своих действиях. Неправильные параметры NVRAM могут привести к проблемам с загрузкой системы.

Резервное копирование и откат

Перед любыми изменениями NVRAM:

nvram -xp > ~/Desktop/nvram_backup.xml

Если что-то пошло не так:

sudo nvram -d boot-args

Или сбросьте NVRAM полностью (Command+Option+P+R при загрузке).

Финальный совет

Начинайте с taskpolicy для конкретного процесса. Если не помогает - переходите к временному отключению через sysctl. И только если уверены в необходимости и понимаете риски - меняйте NVRAM. И да, всегда имейте под рукой загрузочную флешку с macOS на случай, если система перестанет загружаться.

Больше тонкостей работы с локальными LLM на Mac найдете в моем практическом гайде по избежанию основных ошибок.