MTPLX против oMLX: тестируем MLX-серверы на MacBook Pro с M4 Max

Подробности изложены в материале первоисточника. Продолжаю тестировать локальные языковые модели и связки для разработки на Mac. В первой части я запустил кодового агента pi на модели Qwen3.8-27B через сервер MTPLX, после чего у меня возник закономерный вопрос: насколько сильно на скорость влияет многотокенное предсказание (MTP) и как в аналогичных сценариях покажет себя альтернативный MLX-сервер oMLX, который мне порекомендовал искусственный интеллект? В этом материале я проверил эту гипотезу на практике, сопоставил производительность обоих решений, а также разобрался с вопросами энергопотребления, шума вентиляторов и расхода оперативной памяти.

Совет использовать oMLX как более быстрое и качественное решение на моем железе не подтвердился. Проведенные тесты показали, что MTPLX завершает поставленную задачу в 2,8–6,4 раза быстрее, тогда как по успешности прохождения скрытых тестов обе связки продемонстрировали равный результат. Стоит сделать оговорку, что для работы использовались разные сборки модели, а каждый отдельный режим на oMLX запускался по одному разу.

Аппаратный стенд и методология тестирования

Для экспериментов я использовал знакомый по первой части ноутбук MacBook Pro на базе процессора M4 Max со 128 ГБ объединенной памяти, а также неизменную версию агента pi 0.87.1 без дополнительных расширений. Практическая задача осталась прежней: мне нужно было написать с нуля полноценный интерпретатор выражений minicalc, опираясь на заданную спецификацию. Модель имела доступ к 24 видимым тестам для самостоятельного запуска и проверялась по 30 скрытым тестам, к которым у нее не было доступа.

Важно учитывать ключевой нюанс сравнения: хотя железо и задача идентичны, используемые серверы работают с формально разными чекпоинтами. Вариант для MTPLX представляет собой ту же модель Qwen3.8-27B в 4 битах, но дополненную специальными MTP-головами и перепакованную под архитектуру рантайма. Без этих голов MTPLX функционировать не может, в то время как oMLX встроенные MTP-веса из данной сборки не задействует. Таким образом, тестирование фактически оценивает две целостные экосистемы «сервер плюс оптимизированная под него сборка весов».

Особенности конфигурации и настройки режимов мышления

Отдельного внимания заслуживает режим генерации по умолчанию. Как справедливо отметили читатели в комментариях к прошлой публикации, для модели Qwen3.8-27B базовым значением параметра выступает xhigh, а не medium. Это заложено непосредственно в системном шаблоне чата модели. Однако сам MTPLX принудительно подставляет medium, основываясь на внутренних тестах разработчиков для кодинговых задач. В свою очередь, сервер oMLX не занимается подобной подменой и передает уровень размышлений клиенту строго в том виде, в каком его прислал софт. Поскольку агент pi никаких специфических инструкций на этот счет не отправлял, «из коробки» на oMLX модель автоматически активировала родной режим xhigh.

Чтобы запустить другие варианты глубины рассуждений на oMLX, мне приходилось вручную прописывать конфигурацию в файле модели. Для принудительного переключения на средний уровень я добавлял аргументы в файл model_settings.json, прописывая параметры шаблона чата. Для тестирования сценария полного отключения внутренней логики размышлений использовался отдельный параметр деактивации мыслительного процесса.

Результаты тестов и анализ производительности

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

Совершенно неожиданным для меня оказался режим xhigh. Если MTPLX справлялся с ним за 14,5 минут, совершив 13 вызовов инструментов без единой ошибки и сгенерировав 27 тысяч токенов, то на сервере oMLX агент выполнял значительно больший объем работы. В результате общее время решения задачи на oMLX выросло до впечатляющих 92,8 минут при 41 вызове и более чем 50 тысячах токенов вывода.

Почему возникает такая разница в скорости

Заметный разрыв в скорости обработки заметен уже на начальных этапах. До генерации первого файла на MTPLX проходило около 9 минут, тогда как oMLX требовалось порядка 23 минут. В процессе генерации кода MTPLX выдавал около 34 токенов в секунду, в то время как oMLX, судя по оценкам затраченного времени и объему рассуждений, ограничивался примерно 13 токенами в секунду.

Конечно, было бы заманчиво списать весь этот прирост исключительно на технологию multi-token prediction, однако время до создания первого файла включает в себя и обработку объемного входного контекста, и внутренние размышления модели. Траектории выполнения агентных задач у серверов тоже разошлись: на oMLX модель генерировала вдвое больше токенов и делала втрое больше шагов, что не позволяет просто математически перемножить коэффициенты и объяснить ими итоговую разницу в шесть раз.

Поведение режимов размышлений на медленном сервере

На быстром MTPLX разница между средним и максимальным уровнем размышлений практически тонула в погрешности измерений. На oMLX картина оказалась совершенно иной: средний уровень завершил работу за 37,5 минут, в то время как максимальный xhigh потребовал более полутора часов, а низкий режим low занял 72 минуты.

Таким образом, на более медленном сервере medium оказался быстрее родного xhigh в 2,5 раза при абсолютно идентичном качестве финального результата на тестах. Ожидаемой экономии времени от режима low снова получить не удалось — он проиграл среднему режиму на обоих типах серверов. Вероятно, модель тратила меньше времени на первичные размышления, но затем дольше и сложнее исправляла допущенные в коде ошибки.

Тестирование работы без размышлений

Сценарий с полностью отключенными размышлениями ни на одном из серверов не привел к успешному завершению задачи. Попытки запустить модель в таком режиме обернулись системными сбоями.

На MTPLX уже через 8,5 минут сгенерированный код содержал ошибки импорта и неработоспособные конструкции. На oMLX процесс затянулся почти на 70 минут, после чего завис в бесконечном цикле выполнения тестов. Поскольку инструмент bash в используемом агенте не имеет жесткого ограничения по таймауту, этот неудачный прогон пришлось прерывать принудительно вручную.

Оценка шума и нагрева компонентов

Отвечая на вопросы читателей о том, насколько сильно шумит ноутбук под нагрузкой и можно ли снизить обороты вентиляторов ценой потери скорости, я провел пятиминутную непрерывную генерацию, фиксируя показатели датчиков через утилиту thermalforge. При стандартном профиле турбо и умном управлении вентиляторами MTPLX моментально выкручивал крыльчатки на максимум до 7850 оборотов в минуту, удерживая скорость генерации на уровне 35 токенов в секунду при пиковой температуре 107 градусов.

Если передать управление охлаждением штатной macOS, скорость вращения вентиляторов под нагрузкой падала примерно на треть, а производительность генерации проседала на 30%, при этом температура чипа возрастала до 116 градусов. Дополнительный профиль sustained никаких преимуществ не показал: обороты оставались на том же уровне, что и под управлением macOS, но генерация замедлялась еще на пятую часть.

Расход системной памяти

Сложная агентная задача нагружала контекст весьма ощутимо: один запрос вместе с системными промптами pi, описанием инструментов, спецификацией и выводом тестов набирал от 26 до 40 тысяч токенов. При общем окне в 262 тысячи токенов это заполняло доступный буфер примерно на 10-15 процентов.

Архитектура внимания у используемой модели гибридная, поэтому полный KV-кеш выделяется лишь для шестнадцати слоев из шести4. Расчеты показывают, что под память контекста уходит от 2,6 до 16 гигабайт. В ходе замеров oMLX в процессе работы занимал от 18 до 21 ГБ оперативной памяти. Для MTPLX расчетный объем с учетом весов, буферов и динамического кеша составлял около 26 ГБ. На ноутбуках Apple Silicon с 24 ГБ объединенной памяти запустить такую плотную конфигурацию вместе с полным контекстом уже не получится, владельцам более скробных машин придется присматриваться к квантованным 9B-моделям.

Технические нюансы и подводные камни

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

• Ограничение контекста по умолчанию. Сервер oMLX «из коробки» ограничивает размер контекстного окна тридцатью двумя тысячами токенов, поэтому параметр max_context_window в конфигурации приходится увеличивать вручную.
• Авторизация API. Для oMLX требуется ключ доступа, который удобно передавать через специальную команду в настройках агента, чтобы он подтягивался автоматически без дублирования в файлах конфигурации.
• Конфликт портов. Оба сервера по умолчанию запускаются на восьмисотом порту, поэтому при одновременном использовании одному из них обязательно нужно менять сетевой порт.
• Накопление кеша на диске. Функция сохранения промптов на SSD по умолчанию включена в oMLX и за пару дней разрастается на гигабайты, хотя реального ускорения на подобных коротких задачах это не приносит.

Итоги тестирования MLX-серверов

Проведенное тестирование подтвердило, что многотокенное предсказание в связке MTPLX обеспечивает ощутимый прирост скорости генерации, опережая альтернативный сервер oMLX в несколько раз. Тем не менее, полностью списывать всю разницу только на архитектурные особенности MTP нельзя из-за расхождения агентских траекторий. Совет использовать oMLX в качестве безусловного фаворита на мощном железе не оправдался: качество финального кода оказалось одинаково высоким, но по скорости oMLX заметно проиграл.