MLX vs GGUF на Mac M4: итоги битвы форматов для запуска Qwen3.5 122B

Ты купил Mac M4 Max за 15 тысяч долларов. Теперь вопрос: как выжать из него максимум для Qwen3.5 122B?

Первый запуск 122-миллиардной модели на ноутбуке - это как первый полет в космос. Восторг, предвкушение, и тут же холодный душ реальности. Модель загружается 5 минут, первый ответ появляется через полчаса, а память утекает в своп как вода в песок. Знакомо?

К марту 2026 года ситуация с локальными LLM на Apple Silicon стала интереснее, но запутаннее. Появилось два лагеря: традиционный GGUF через llama.cpp и нативный MLX от Apple. Оба формата претендуют на звание "оптимального" для Mac. Но когда речь о 122 миллиардах параметров, компромиссы становятся слишком дорогими.

Я потратил неделю на тесты, сжег несколько киловатт-часов и собрал данные, которые перевернут ваше представление о том, как запускать большие модели на Mac.

1 Почему 122 миллиарда - это особая история

После работы с MiniMax-M2.5 230B я думал, что привык к масштабам. Но Qwen3.5 122B - это другая физика. Не MoE, а плотная модель. Каждый параметр участвует в каждом вычислении. И вот здесь начинается магия или кошмар - в зависимости от выбранного формата.

Размеры файлов на старте:

Цифры в таблице - это обещания. Реальность измеряется в минутах ожидания и гигабайтах свопа.

2 Тестовая установка: M4 Max против физики

MacBook Pro M4 Max (128GB unified memory). macOS Sequoia 15.4. Температура в помещении 22°C. Все тесты с контекстом 4096 токенов, генерацией 512 токенов. Система чистая - только нужные фреймворки.

3 GGUF: проверенный ветеран с багажом

llama.cpp 0.18.0 с поддержкой ANE (Apple Neural Engine) - это не та же самая утилита, что была год назад. Но фундаментальные проблемы остались.

Команда для теста Q4_K_M:

./llama-cli -m qwen3.5-122b-Q4_K_M.gguf \
  -n 512 \
  -c 4096 \
  -t 10 \
  -ngl 99 \
  --mlock \
  --no-mmap

Флаг -ngl 99 пытается засунуть все слои в GPU. На 122 миллиардах это самоубийство. Реальность: 78 слоев уходят в GPU, остальные 44 - в RAM. Обмен данными между памятью становится бутылочным горлышком.

4 MLX: нативная магия или маркетинг?

MLX 1.0.3 обещает "бесшовную работу с unified memory". На практике это означает, что фреймворк сам решает, где размещать данные. Звучит идеально, пока не увидишь, как он это делает.

Код запуска выглядит элегантнее:

import mlx.core as mx
from mlx_llm import load, generate

model, tokenizer = load("qwen3.5-122b-4bit-mlx")
mx.metal.set_cache_limit(100 * 1024 * 1024 * 1024)  # 100GB кэша
response = generate(model, tokenizer, prompt="...", max_tokens=512)

Но под капотом происходит черная магия с кэшированием и перемещением данных между CPU и GPU. Иногда это работает быстрее. Иногда - просто зависает на 30 секунд, пока система перераспределяет память.

Цифры не врут: итоги бенчмарка

Я провел 25 прогонов каждого формата. Средние результаты:

Разница в 22 гигабайта памяти - это не погрешность. Это принципиально разный подход к работе с unified memory. MLX агрессивно использует shared memory архитектуру, в то время как GGUF все еще мыслит категориями "GPU vs RAM".

Когда MLX проигрывает (да, такое есть)

Не все так радужно. MLX 1.0.3 все еще сыроват в трех сценариях:

1. Длинный контекст (32K+ токенов): GGUF с --no-mmap и --mlock держит стабильную скорость. MLX начинает деградировать после 16K токенов.
2. Пакетная обработка: Если вам нужно обрабатывать 10-20 запросов параллельно, llama.cpp с его mature threading model выигрывает.
3. Экзотические квантования: Хотите Unsloth Dynamic 2.0 или Q6_K? В GGUF это уже работает. В MLX - только базовые 4-bit и 8-bit.

5 Практическое решение: гибридный подход

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

• Для диалога и быстрых ответов: MLX 4-bit. Быстрая загрузка, низкий TTFT, меньше нагрева.
• Для обработки документов с длинным контекстом: GGUF Q4_K_M с правильно настроенным -ngl (в моем случае 78).
• Для максимального качества: GGUF Q8_0, если готовы ждать и у вас есть SSD на 2TB для свопа.

Конкретные настройки для GGUF на M4 Max 128GB:

# Оптимально для Qwen3.5 122B Q4_K_M
./llama-cli -m qwen3.5-122b-Q4_K_M.gguf \
  -c 4096 \
  -t 12 \
  -ngl 78 \
  -b 512 \
  --mlock \
  --no-mmap \
  --gpu-layers-draft 8 \
  --parallel 4

Память - это новая нефть

Самое интересное наблюдение: MLX не просто использует меньше памяти. Он использует ее умнее. Вместо статического распределения слоев между CPU и GPU, MLX динамически перемещает данные туда, где они нужны прямо сейчас.

Это напоминает оптимизации Qwen3 Next в llama.cpp, но на системном уровне. Результат - меньше свопа, ниже температура, дольше автономная работа.

Что будет дальше?

К концу 2026 года я ожидаю слияния подходов. Уже сейчас в development branch llama.cpp тестируют динамическое распределение слоев, похожее на MLX. С другой стороны, MLX обещает поддержку более сложных квантований.

Мой прогноз: к Apple M5 мы получим единый формат, который объединит скорость MLX с гибкостью GGUF. А пока - используйте гибридный подход и не верьте маркетингу.

Частые ошибки и как их избежать

• Ошибка: Запуск MLX без установки mx.metal.set_cache_limit(). Результат - падение через 10 минут работы.
• Решение: Всегда устанавливайте лимит кэша в 80-90% от доступной памяти.
• Ошибка: Использование GGUF с -ngl 999 на больших моделях.
• Решение: Рассчитайте реальное количество слоев: (GPU_memory - 4GB) / memory_per_layer. Для Qwen3.5 122B Q4_K_M это примерно 78 слоев на M4 Max.
• Ошибка: Забыть про --mlock в GGUF. Без этого флага система будет постоянно выгружать модель в своп.
• Решение: Всегда используйте --mlock --no-mmap для моделей больше 64GB.

Если после всего этого вы все еще сомневаетесь - посмотрите практический гайд по выбору LLM для Mac M4. Там разобраны более мелкие модели, но принципы те же.

Подписаться на канал