На сколько модели MLX работают быстрее GGUF на MacBook с 24GB RAM?
На Хабре есть несколько статей от счастливчиков, которые используют довольно хорошее железо в виде MacBook Pro с 48-64GB RAM, и я полностью согласен, что у разработчика должно быть что-то подобное. Но часто бывает, что такое железо не по карману, а хочется понимать, на сколько реален профит от использования оптимизации MLX на чипах Apple Silicon. В статьях обычно указывается средняя разница в 10-30% между GGUF и MLX версиями моделей. Почему, собственно, возникла такая идея? Потому что не для всех моделей есть MLX версия, и стоит ли выбирать модель, где она есть, если у схожей модели, которая вам больше нравится, MLX версии нет.
Этот пост не тянет на серьезное исследование или статью, а представляет собой результаты небольшого эксперимента. Было желание сравнить скорость работы по критерию eval rate для условно "легких", "средних" и "тяжелых" моделей в двух версиях GGUF и MLX.
Для эксперимента я воспользовался MacBook Air M4 24 GB (да, это был не Pro, но хотелось проверить модели > 30b, а Pro вариантов с подходящей памятью не нашлось), LM Studio 0.4.21 (по причине того, что Ollama v. 0.33.0 для больших моделей установила минимальное ограничение 32GB RAM, и если оно ниже, то принудительно использует движок GGUF). Я выбрал такие модели, допустимые для запуска на этой конфигурации:
- "легкая" модель qwen2.5-coder:1.5b (вариант для автозаполнения)
- "средняя" модель qwen2.5-coder:14b (вариант для генерации скриптов)
- "тяжелая" модель qwen2.5-coder:32b (вариант для выбора архитектурных решений и подходов к реализации).
Для чистоты эксперимента каждый тест делался в новой сессии, никакие иные приложения не запускались, чтобы минимизировать использование памяти.
Небольшое допущение: модели MLX я брал из репозитория mlx-community, но с таким же уровнем квантования, как и GGUF модели. Для тестов я использовал 3 промта соответствующего уровню модели сложности, в результатах приведены усредненные значения eval rate.
"Легкие" модели qwen2.5-coder:1.5b на промтах, подходящих для автозаполнения, показали такие результаты:
- GGUF 76.93 tokens/s
- MLX: 81.92 tokens/s
Разница в пользу MLX 6,5%. Пока явного выигрыша нет.
"Средние" модели qwen2.5-coder:14b на промтах по написанию классов/скриптов:
- GGUF: 15.05 tokens/s
- MLX: 17.59 tokens/s
Разница в пользу MLX 16.8%. Это уже похоже на распространенное мнение, что MLX модели на 10-30% быстрее GGUF.
"Тяжелые" модели qwen2.5-coder:32b на промтах по выбору архитектурных решений и реализации:
- GGUF: 2.51 tokens/s
- MLX: 5.73 tokens/s
Разница в пользу MLX в 2.28 раза. Опущу здесь момент, что скорость ниже 10 токенов в секунду уже считается слабой. Очевидно, что использовать такие модели для получения ответов в реальном времени будет некомфортно, но здесь речь идет о том, что выбор архитектурного решения или оптимальных технологий для вашего проекта всё же должно быть взвешенным, и здесь у вас есть время подождать экспертный ответ. Но факт в том, что от MLX моделей вы сможете получать его в 2 раза быстрее.
В итоге:
- для легких моделей разница в производительности практически не будет для вас заметна, и вы можете выбирать, например, для автозаполнения ту, которая вас больше устраивает, не обращая внимание на формат GGUF или MLX и не гнаться за оптимизацией
- для средних задач профит MLX уже ощутим, и вы с большой вероятностью получите прирост скорости в 10-30%, выбрав оптимизацию, если только модель, которая её не имеет действительно не сильно лучше.
- а вот в тяжелых задачах выбор в сторону MLX однозначно стоит делать, поэтому внимательно проверяйте, какую версию модели вы скачали и запустили, чтобы ошибочно не использовать GGUF.
Надеюсь, что этот эксперимент позволил вам получить более простую и понятную картину о профите использования оптимизации MLX в ваших задачах.
