Обещали ракету, а получили телегу
Вы скачали свежую 4-битную версию Llama-3.4 12B в формате AWQ, загрузили её в mlx-lm, запустили на своём MacBook Pro M4 – и он начал думать. Не генерировать текст, а именно медленно, мучительно думать. Токены выплёвываются со скоростью два в секунду, вентиляторы молчат, а вы смотрите на прогресс-бар и чувствуете, как стареете.
Это не ваше железо виновато. И даже не модель. Виноват баг в самом фреймворке MLX, который уже несколько месяцев незаметно саботирует работу с самыми популярными форматами квантования – AWQ и GPTQ. Ирония в том, что эти методы призваны ускорить всё в разы.
Коротко о главном: В MLX (актуальная версия на 16.03.2026) операции деквантования INT4 весов для инференса выполняются не на GPU, а на CPU. Каждый слой, каждый токен – лишняя синхронизация и копирование данных. Результат – падение скорости в 3-5 раз по сравнению с FP16, хотя должно быть наоборот.
Что сломалось под капотом? Разбираем кости
Всё началось с переходом на более унифицированный движок вычислений в MLX 26.x. Инженеры переписывали ядро для лучшей поддержки распределёнки (вспомните нашу статью про MLX 26.2 и RDMA). В погоне за абстракцией для кластеров из Mac они слегка потеряли фокус на базовых операциях для одного чипа.
Конкретно в графе вычислений для квантованных моделей операция dequantize перестала быть «сплавленной» (fused) с матричным умножением. Вместо того чтобы потоково считывать и сразу умножать сжатые 4-битные веса на Neural Engine, система сначала раскладывает их в 16-битный формат в оперативной памяти, а потом уже передаёт на вычисления.
Проблема подтверждена в нескольких открытых issue на GitHub. Самый подробный – #847, где разработчики признали, что «производительность sub-8-bit квантований в текущей реализации неоптимальна». Звучит мягко, но на деле это значит «практически бесполезно».
Что делать сейчас? Три обходных манёвра
Ждать фикса от Apple можно долго. Пока они решают головоломки с распределённым обучением, ваши локальные модели должны работать. Вот что реально помогает ускориться.
1Перейти на llama.cpp с Metal backend
Да, это шаг назад в плане экосистемы, но гигантский скачок в скорости. Llama.cpp (актуальная ветка на 16.03.2026) давно оптимизировала работу с INT4 для Apple Silicon. Здесь операции деквантования жёстко зашиты в ядра Metal, и веса не покидают память GPU. Разница – до 7 раз быстрее для той же модели. Если вы сталкивались с багом EOS у GLM-4.5-Air, то уже знаете, что тонкая настройка llama.cpp иногда необходима.
2Использовать квантования с группировкой (grouped) вместо AWQ/GPTQ
Не все квантования одинаково провальны в MLX. Форматы вроде «q4_1» или «q4_k_m» из сообщества llama.cpp, которые переконвертированы для MLX, часто работают чуть лучше. Их алгоритм проще, и MLX меньше путается. Попробуйте модели, изначально подготовленные для этой среды, как Minimax m2.1 DWQ.
Проверка: Запустите модель и откройте «Мониторинг активности». Если вы видите, что процесс «Python» грузит CPU на 150-200%, а GPU (Apple GPU) простаивает на 20% – это явный признак бага. При здоровой работе GPU должен быть загружен под 70-90%.
3Вернуться к FP16 и купить больше памяти
Циничный, но рабочий совет. Если ваш Mac позволяет, забудьте про 4-битные танцы с бубном. Запускайте модели в полной точности. Это даст максимальную скорость и качество ответов. Правда, нужна хорошая память. Для моделей размером 12-20B уже желательно иметь 48 ГБ унифицированной памяти, как в топовом MacBook Pro 16 2024 M4 Pro 48Gb. Это дорого, но зато вы не зависите от костылей.
А что там с другими моделями и фреймворками?
Баг системный, поэтому он бьёт по всем моделям, конвертированным в AWQ/GPTQ для MLX. Неважно, Qwen3.5 9B, GLM-4.5-Air или Mistral 12B – все будут тормозить одинаково печально. Причём в других средах, например в LM Studio (который использует свой бэкенд), этой проблемы может и не быть. Как мы писали в материале про Qwen на M4 Max, иногда смена инструмента – лучшее решение.
Любопытно, что с 8-битным квантованием (INT8) проблема менее выражена. Видимо, для этого формата оптимизационный путь в MLX был прописан верно. Но смысл в 8 битах на Apple Silicon, где память щедрая, теряется.
Когда ждать исправления и стоит ли?
Вопрос на миллион. Активность в репозитории MLX показывает, что команда сосредоточена на больших фичах: распределённом обучении, поддержке ещё более крупных моделей, глубокой интеграции с новой версией macOS. Базовый инференс для квантованных моделей, видимо, попадёт в список приоритетов, только когда на него начнут массово жаловаться корпоративные пользователи.
Мой прогноз – точечный фикс может выйти в одном из минорных обновлений MLX 26.3 или 26.4, но не раньше лета 2026. Пока же сообществу остаётся или форкать фреймворк и чинить своими силами, или искать альтернативы. Кстати, если вы экспериментируете с несколькими моделями, взгляните на наш обзор лучших LLM для программирования на M5 Pro – там есть сравнение производительности в разных средах.
А самый главный совет на сегодня: перед долгой настройкой MLX для новой квантованной модели проверьте, нет ли готовой версии для llama.cpp. Скорее всего, она не только запустится, но и полетит. И сохранит ваши нервы.
