Qwen 3.5 en MacBook Pro: Comparación de ocho servidores locales para trabajo en equipo

Локальный запуск больших моделей на Mac давно перестал быть игрушкой для энтузиастов, но история с Qwen 3.5 35B показывает, что между «запускается» и «годится для командного API» лежит большая дистанция. Автор взял MacBook Pro M2 Max с 64 ГБ памяти и проверил не модель как таковую, а инфраструктуру вокруг неё: какой MLX-сервер выдерживает реальную рабочую нагрузку, не рисует красивые цифры в логах и не разваливается, как только к нему приходят два пользователя одновременно.

Для теста собрали отдельный Python-харнесс и прогнали восемь локальных серверов, которые позиционируются как быстрый способ поднять API поверх MLX-моделей на macOS. Проверка шла не на одном удобном вопросе, а на наборе из восьми промптов разного типа и длины, включая задачи уровня AIME и длинные входы до 52 тысяч токенов. Каждый сценарий запускался по пять раз, чтобы убрать случайные всплески и получить более честную картину по задержкам, скорости генерации и общему поведению под нагрузкой.

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

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

Здесь и обнаружился реальный разрыв между решениями. Четыре фреймворка из шести фактически скатывались в очередь и обслуживали запросы почти последовательно, хотя внешне продолжали выглядеть как многопоточные. Ещё один сервер сохранял параллельность только формально и проседал до коэффициента 0,85x, то есть второй запрос скорее мешал, чем помогал утилизировать железо.

Лишь один участник теста показал честное ускорение 2,17x, что уже похоже на пригодное поведение для локального командного API, где важно не просто быстро ответить одному пользователю, а держать несколько обращений без драматической просадки. По пути всплыли и проблемы, которые важнее сухих чисел в таблице. В одном месте автор наткнулся на квадратичный attention, который в 2026 году всё ещё способен резко ухудшать поведение на длинных контекстах.

В другом — на фантомные 14 000 tokens/sec, появившиеся не из-за магической оптимизации, а из-за одной строки в SSE-парсере, которая искажала замер. Отдельно упоминается зомби-процесс, оставлявший после себя около 20 ГБ занятой оперативной памяти, хотя README о таком риске предпочитают молчать. Для тех, кто планирует локальный продакшен, это не мелочи: такие баги бьют по предсказуемости сервиса, мониторингу и стоимости поддержки сильнее, чем разница в несколько процентов по сырой скорости.

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

Этот бенчмарк показывает простую вещь: локальный стек для Qwen 3.5 надо оценивать как инфраструктуру, а не как демо. Иначе можно получить систему, которая на одиночных тестах выглядит «быстрой», а в живой работе превращает мощный MacBook в дорогую очередь из запросов.