Есть ли смысл использовать MLX на Mac в 2026 году: сравнение с llama.cpp на M5

Короткий ответ: MLX не устарел, но перестал быть выбором по умолчанию

MLX на Mac с Apple M5 нет смысла списывать со счетов, но и считать обязательным стеком для локальных LLM уже нельзя. Если нужная модель в GGUF работает через llama.cpp с подходящей скоростью prefill, decode и расходом памяти, одного универсального GGUF-окружения может хватить для повседневной работы.

MLX стоит оставить, когда он нужен конкретной модели, существующему workflow или даёт измеримый выигрыш в вашей нагрузке. Решение зависит от версии модели, квантования, длины контекста, конфигурации памяти Mac и того, что пользователь ждёт от системы: быстрый первый токен, высокую скорость длинной генерации или предсказуемую работу с несколькими моделями.

В доступных материалах нет прямого сопоставимого теста MLX и llama.cpp на Apple M5 с одинаковой базовой моделью, близким квантом и общими настройками. Поэтому утверждение, что любой из стеков всегда быстрее на M5, было бы предположением. Корректный ответ появляется после замеров на целевой модели и типичных для вас запросах.

Почему один чужой бенчмарк не отвечает на вопрос за всех

Результат одного запуска отражает конкретную связку: чип, объём памяти, версию macOS, версию рантайма, Metal-бэкенд, модель, способ квантизации, длину промпта и параметры генерации. Даже смена контекста с 256 на 8192 токенов может поменять практическую ценность высокой скорости prefill.

Сравнение теряет смысл, если в одном случае используется 4-bit GGUF, а в другом более агрессивный квант другой сборки. Размер файла, качество ответа, объём KV-кэша и характер вычислений будут различаться. Надпись «M5» в заголовке бенчмарка не заменяет описание конфигурации.

Проверяйте, что автор замера указал модель и revision, формат весов, тип квантизации, объём унифицированной памяти, длину входа и выхода, температуру, режим GPU и число повторов. Без этих полей фраза «MLX быстрее» или «llama.cpp быстрее» мало помогает выбрать рабочий стек.

Что именно сравнивают: prefill, генерацию и задержку первого токена

У LLM есть два главных этапа инференса. На prefill рантайм обрабатывает входной промпт и строит KV-кэш. На decode модель добавляет ответ по одному токену, используя уже подготовленный контекст. Скорость в токенах в секунду для этих этапов нельзя складывать в одну абстрактную оценку.

Пользователь видит end-to-end задержку: отправил запрос, дождался первого токена, получил весь ответ. В неё могут входить загрузка модели, прогрев, токенизация, prefill, decode и служебные действия интерфейса. Поэтому один показатель generation speed не описывает весь опыт работы.

Разница между prefill и decode особенно заметна на streaming-запуске MoE-моделей. В разборе Qwen3.8-Next на Mac M5 Air эти этапы рассматриваются раздельно, что полезнее одного усреднённого числа токенов в секунду.

Когда prefill важнее скорости генерации

Prefill определяет задержку первого ответа, когда в запрос попадает много входных токенов. Типичные примеры: системная инструкция на несколько страниц, документ для анализа, RAG-контекст из нескольких фрагментов, большой файл кода, агент с подробным состоянием задачи.

Представьте два сценария. В первом пользователь задаёт вопрос на 40 токенов и ждёт ответ на 800 токенов. Во втором он отправляет 12 000 токенов документа и просит пять коротких выводов. Во втором сценарии ускорение prefill даст более заметный эффект, даже если decode у альтернативного стека выглядит привлекательнее.

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

Когда важнее токены в секунду после первого ответа

Decode важнее в чате с короткими сообщениями, генерации кода, многошаговом рассуждении и агентных задачах, где модель долго пишет ответ. Если запрос короткий, а вывод занимает 1500-2000 токенов, несколько секунд разницы на prefill могут оказаться менее заметными, чем стабильная скорость выдачи текста.

Для кодинга оценивайте не один фрагмент ответа, а время выполнения задачи: сколько занимает первый ответ, насколько быстро модель дописывает большой файл, как ведёт себя после нескольких вызовов инструментов. У локального агента повторяются и prefill, и decode, поэтому победитель по одной фазе не гарантирует меньшего общего времени.

Фиксируйте минимум три числа: время до первого токена, скорость decode после старта и полное время до последнего токена. Если интерфейс показывает лишь tokens/s, запускайте модель через режим, который выводит отдельные метрики, либо измеряйте время внешним таймером при фиксированных длинах входа и выхода.

MLX или GGUF: выбор формата модели до выбора рантайма

MLX и GGUF относятся к разным уровням стека. MLX - фреймворк и набор инструментов для Apple Silicon. GGUF - формат файлов весов, с которым прежде всего работает llama.cpp. Практически сравнивают не «MLX против GGUF», а подготовленную модель в MLX-стеке против сборки этой же базовой модели в GGUF через Metal-бэкенд llama.cpp.

Формат весов влияет на доступность модели, варианты квантования, размер файла, путь подготовки и набор совместимых программ. Рантайм влияет на то, как эти веса загружаются, какие ядра запускаются на GPU и как считаются prefill с decode. Выбор начинается с вопроса: есть ли нужная модель в форме, которая устраивает по качеству и памяти.

Когда GGUF и llama.cpp закрывают задачу без MLX

GGUF с llama.cpp подходит пользователю, которому нужен единый переносимый стек для локальных моделей, привычные инструменты вокруг этого формата и простой способ сравнивать разные семейства LLM на одном Mac. Такой путь разумен, когда нужные модели уже доступны в подходящих GGUF-квантах, а собственные замеры проходят по требованиям к задержке, скорости ответа и памяти.

Унификация особенно удобна, если вы регулярно меняете модели: сохраняется один способ запуска, похожая диагностика и общая логика тестов. Это преимущество эксплуатации, а не автоматическое доказательство превосходства по скорости на Apple M5.

Проверьте качество выбранного кванта на реальных задачах. Модель может уверенно проходить короткий чат, но хуже держать структуру JSON, писать код или работать с длинным русскоязычным контекстом. Сравнение форматов без проверки результата способно сэкономить память ценой качества, которое обнаружится слишком поздно.

Когда MLX стоит оставить в наборе инструментов

MLX стоит держать, если необходимая модель доступна и удобнее в этом окружении, если рабочие скрипты уже завязаны на MLX-инструменты или если он выигрывает на вашей ключевой метрике. Например, разработчику может быть важна конкретная MLX-ready сборка модели, а пользователю RAG важнее её задержка на длинном входе.

Особый случай - модели с дополнительными механизмами генерации и нестандартными вариантами квантования. Выбор кванта для Qwen3.8-27B MTP на Apple M5 Max разобран в материале о вариантах oQ3e, oQ4e, oQ6e и oQ8e. Здесь формат весов, память и скорость нельзя отделить друг от друга.

Два рантайма не создают проблему сами по себе. Для разработчика и энтузиаста разумно хранить GGUF как универсальный путь и MLX как второй вариант для моделей или задач, где он подтверждает свою пользу. Лишним MLX становится после повторяемого теста, а не после чужого скриншота.

Квантование меняет не только размер модели

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

Для честного сравнения берите одну базовую модель и одинаковый revision. Затем выбирайте максимально близкие по классу кванты, фиксируйте размер файлов и отдельно проверяйте качество на 5-10 типовых заданиях. Полного тождества между квантами из разных экосистем может не быть, поэтому вывод стоит формулировать аккуратно: быстрее или медленнее при таком-то уровне качества и таком-то объёме памяти.

Не сравнивайте 3-bit модель в одном стеке с 4-bit моделью в другом, а затем не называйте разницу заслугой фреймворка. Сначала проверьте, отвечают ли обе сборки требованиям к качеству. Потом измеряйте скорость при одинаковой длине контекста и вывода.

Почему на Apple M5 результат нельзя объяснить одним словом Metal

Metal сам по себе не отвечает на вопрос о скорости локальной LLM. MLX и llama.cpp могут использовать GPU Apple, но путь от весов до вычислительных ядер, поддерживаемые типы данных, работа с памятью и зрелость кода для конкретной модели различаются. Обновление рантайма способно изменить картину без замены Mac.

На Apple M5 особенно опасно переносить замеры с прошлых поколений Apple Silicon. Устройство, объём памяти, режим питания, температура корпуса и версия программного стека входят в условия теста. Общее название семейства чипов не делает эти условия одинаковыми.

Память задает границы до старта бенчмарка

MacBook Air 15 образца 2026 года с Apple M5 доступен в конфигурациях 10 CPU / 10 GPU и 16, 24 либо 32 ГБ памяти. Эти три варианта дают разный запас для модели, KV-кэша, macOS, приложения и параллельных процессов. До оценки tokens/s нужно убедиться, что целевой сценарий помещается в память без давления на систему.

Модель может загрузиться, но это ещё не означает комфортную работу с рабочим контекстом. Длинный вход увеличивает KV-кэш, а браузер, редактор кода, IDE и индексатор RAG забирают память одновременно с рантаймом. На 16 ГБ ограничения проявятся раньше, чем на 24 или 32 ГБ, даже при одной и той же модели.

В таблице замеров указывайте свободную память перед запуском, фактическую длину контекста и состояние остальных тяжёлых приложений. Когда система начинает сжимать память или обращаться к накопителю, результат перестаёт описывать чистую скорость выбранного бэкенда.

Ноутбук, настольный Mac и внешнее ускорение нельзя смешивать в одной таблице

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

Внешний контур ускорения - отдельный класс конфигураций. Thunderbolt 5 и внешний GPU с подачей питания до 100 Вт описывают иной путь подключения и иной набор ограничений. Такие цифры ничего не доказывают про MLX или llama.cpp на встроенном GPU Apple M5 и не должны попадать в общую таблицу без явной маркировки устройства.

Указывайте точную модель Mac, объём памяти, режим питания и длительность прогона. Для ноутбука полезно записать, был ли он подключён к сети и запускался ли тест после долгой генерации. Иначе короткий удачный запуск легко выдать за характеристику всей системы.

Как честно сравнить MLX и llama.cpp на своем Mac

Рабочий протокол начинается с фиксации среды. Обновите или закрепите версии MLX и llama.cpp, закройте лишние тяжёлые программы, перезапустите оба рантайма в одинаковом состоянии и не меняйте настройки между прогонами. Сначала определите задачу, потом выберите метрики.

Берите одну базовую модель с одним tokenizer и фиксируйте её revision. Подготовьте сопоставимые MLX- и GGUF-сборки, запишите квантование и размер файлов. Если уровни квантов отличаются, добавьте короткую проверку качества, чтобы результат по скорости не сравнивал разные по полезности варианты.

Для температуры используйте 0, если задача допускает детерминированную генерацию. Зафиксируйте seed, top-p, top-k, максимальное число выходных токенов и шаблон чата. Убедитесь, что оба запуска реально используют GPU и не переходят частично на CPU без отметки в журнале.

Минимальный набор сценариев для локальных LLM на Mac

Короткий искусственный промпт не показывает поведение системы в работе. Используйте хотя бы три сценария, каждый с одним и тем же текстом во всех рантаймах.

1. Короткий чат: вход примерно 128 токенов, вывод 128 токенов. Он показывает задержку интерфейса и скорость ранней генерации.
2. Длинный документ или RAG-контекст: вход примерно 8192 токена, вывод 128 токенов. Здесь сравнивайте prefill, время до первого токена и потребление памяти.
3. Длинная генерация: вход примерно 512 токенов, вывод 2048 токенов. Этот сценарий лучше показывает устойчивую скорость decode и полное время выполнения.

Эти длины служат стартовыми точками. Если ваш RAG обычно подаёт 20 000 токенов, тест на 8192 не заменит реальную нагрузку. Если агент делает десятки коротких вызовов, добавьте серию последовательных запросов с тем же системным промптом.

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

Что записать в таблицу, чтобы сравнение можно было повторить

Сохраняйте параметры рядом с цифрами. Набор полей ниже позволяет через месяц повторить тест после обновления рантайма и понять, что именно изменилось.

Для MLX-сценариев с MTP и draft-механизмами отдельно фиксируйте их состояние. Материал о MTPLX на Apple Silicon полезен именно как напоминание: дополнительные способы ускорения меняют профиль prefill и decode, поэтому их нельзя смешивать с базовым запуском в одной строке таблицы.

Практический выбор в 2026 году: один стек или два

Выбирайте стек по узкому месту. Если задержка длинных промптов мешает работе, смотрите прежде всего на prefill и время до первого токена. Если модель долго пишет код или развёрнутые ответы, смотрите на decode и полное время. Если проблема в памяти, сначала меняйте модель, квант или длину контекста, а потом оценивайте разницу рантаймов.

Раз в несколько месяцев повторяйте ключевой тест после обновления модели, квантов или Metal-поддержки. Решение, принятое на старой версии рантайма, не обязано оставаться лучшим после изменения кода. Держать второй инструмент имеет смысл, пока он закрывает сценарий, который первый не закрывает.

Выбирайте llama.cpp и GGUF, если важны универсальность и проверенный сценарий

Остановитесь на llama.cpp и GGUF, когда нужные модели доступны в подходящем кванте, качество ответов вас устраивает, а собственные измерения проходят требования по prefill, decode и памяти. Это удобный путь для одного понятного локального окружения, где легко переключаться между моделями и повторять сравнения.

Такой выбор особенно практичен для пользователя, который не хочет поддерживать несколько способов подготовки весов и запуска. Перед удалением MLX проверьте три привычные нагрузки: короткий чат, длинный документ и длительную генерацию. Один удачный тест на коротком вопросе не покрывает остальные случаи.

Оставляйте MLX, если он выигрывает в вашей модели и вашей нагрузке

Сохраняйте MLX, когда он даёт измеримую пользу на нужной модели: меньшую задержку первого токена в RAG, более высокую скорость длинного ответа, удобную поддержку необходимой сборки или совместимость с уже работающим скриптом. Привычка к инструменту сама по себе слабый аргумент, но проверенный workflow с предсказуемым результатом - вполне практичный.

Для владельца Mac с Apple M5 разумная базовая позиция звучит так: GGUF и llama.cpp могут закрыть весь повседневный локальный инференс, если это подтверждают ваши задачи. MLX остаётся полезным вторым стеком для отдельных моделей и случаев, где его преимущество подтверждается повторяемыми замерами. Выбирать нужно по модели, кванту, контексту и метрике, а не по названию фреймворка.

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