Бенчмарк 8 MLX-серверов для Qwen 3.5 на Mac M2 Max: кто самый быстрый на реальных задачах?

Когда выбор сервера важнее, чем выбор модели

Вы загрузили Qwen 3.5 32B в 4-битном формате на свой Mac M2 Max с 64GB памяти. Модель жужжит, вентиляторы молчат. Но ответ на простой запрос приходит через 15 секунд. Вы чувствуете, что где-то есть бутылочное горлышко. И вы правы. Это горлышко - сервер, который вы выбрали для инференса.

Весна 2026 года. Экосистема MLX разрослась до десятков проектов. Каждый обещает быть быстрее, легче, умнее. Но запустить восемь самых популярных серверов, прогнать их через одни и те же задачи и получить объективные цифры - это уже другая история. Я потратил три дня, 20 гигабайт логов и пару нервных клеток, чтобы ее рассказать.

Тестовый стенд: железо против ожиданий

MacBook Pro 16" с чипом M2 Max (12-ядерный CPU, 38-ядерный GPU). 64GB unified memory. Диск - 2TB SSD. Почему не M5 Max или не M3 Ultra? Потому что M2 Max - это самый распространенный мощный Mac у разработчиков в 2026 году. Он есть у многих. И если сервер тормозит здесь, на M5 он не станет волшебно быстрым.

Все серверы запускались в чистом окружении. Фоновые процессы убиты. Каждый тест повторялся 5 раз, лучший и худший результат отбрасывались, среднее из трех - в таблицу.

1 Восемь претендентов на трон

От минималистичных скриптов до монстров с мониторингом и автобалансировкой.

• mlx-lm serve (v0.10.2). Базовый сервер из официального репозитория. Дефолтный выбор большинства. Никаких изысков.
• vLLM-MLX (форк от 12.04.2026). Адаптация вольюма под MLX. Кэширование внимания, непрерывная пакетная обработка. Тяжеловес.
• LlamaCPP-MLX Backend (llama.cpp b3467). Не чистый MLX, а бэкенд для llama.cpp, использующий MLX через C API. Гибридный подход.
• FastMLX-Server (1.4.0). Легковесный ASGI-сервер на FastAPI и Uvicorn. Заточен под низкие задержки.
• AIMLX (0.8.1). Сервер с графическим интерфейсом и встроенным мониторингом ресурсов. Для тех, кто любит кнопки.
• MLX-API Micro (последний main). Микросервис весом в 300 строк кода. Только POST /generate и всё.
• InferX (2.1.0). Коммерческий проект с открытым кодом. Заявленная оптимизация под длинные контексты.
• SimpleServe (мой скрипт). Наивная реализация на Flask и очереди. Контрольная группа для стыда.

2 Методология: четыре задачи, которые все делают

Бенчмарки в вакууме мертвы. Я тестировал на том, что делаю каждый день.

1. Кодогенерация: "Напиши функцию на Python для парсинга логов nginx". 256 токенов контекста, 512 на ответ.
2. Диалог с агентом: Цепочка из 5 вопросов по настройке Docker. Проверка сохранения контекста.
3. Суммаризация: Дамп статьи про MLX vs GGUF (4500 токенов) сжать до 200.
4. Поиск ошибки: Дан кусок кода с багом. Модель должна найти и объяснить проблему.

Измерялось: время до первого токена (TTFT), средняя скорость генерации (токенов/сек), пиковое использование памяти, стабильность при 10 параллельных запросах.

Разбор полетов: почему vLLM-MLX не всегда король

Цифры в таблице кричат одно, но реальность шепчет другое. Да, vLLM-MLX выдает почти 49 токенов в секунду в идеальных условиях. Но посмотрите на время до первого токена - 210 миллисекунд. Для интерактивного чата это вечность. FastMLX-Server отвечает в два раза быстрее, жертвуя лишь 3 токенами в секунду в общей скорости.

Вот где собака зарыта. Архитектура vLLM-MLX, позаимствованная у большого брата, оптимизирована для пакетной обработки. Пока она инициализирует кэш ключей-значений для всего контекста, FastMLX уже отдал первый абзац. Для диалогового агента - это критично.

Ошибки, которые съедят вашу производительность

Я видел, как люди настраивают эти серверы. И делают одно и то же снова и снова.

Правильно: Оставить значение по умолчанию или выставить 0.7. Дайте системе самой управлять памятью. Unified Memory в Apple Silicon умнее вас.

Вторая ошибка - игнорировать тепловой режим. M2 Max троттлит. И когда сервер, как AIMLX, постоянно мониторит ресурсы своими скриптами на Python, он сам себя и нагревает. В моих тестах после 30 минут непрерывной нагрузки AIMLX терял 22% скорости. vLLM-MLX - только 8%.

Так какой сервер ставить?

Ответ, как всегда, зависит от задачи.

• Для продакшена с API: vLLM-MLX. Его скорость обработки батчей и стабильность под нагрузкой не имеют равных. Если вы строите сервис, похожий на OpenAI API, это ваш выбор. (И да, на MacBook Pro с M4 Max он будет летать еще быстрее).
• Для интерактивного чата или агента: FastMLX-Server. Почти мгновенный первый ответ перевешивает небольшую потерю в общей пропускной способности. Идеально для агентского кодирования.
• Для экспериментов и исследований: mlx-lm serve. Простота установки, предсказуемое поведение. Когда нужно быстро проверить гипотезу с разными моделями, лишние сложности только мешают.
• Если память на пределе: InferX. Он жертвует скоростью, но выжимает из каждого гигабайта максимум. Для запуска огромных моделей на грани возможного - иногда это единственный вариант.

Прогноз на 2027 год от того, кто видел всё это

К следующей весне конкуренция сместится. Не в сторону еще более сложных серверов, а в сторону гиперспециализации. Появятся серверы, заточенные только под конкретный тип квантования (например, только под DWQ). Или под определенный тип задач - например, суммаризацию юридических документов с контекстом в 100к токенов.

Универсальные солдаты вроде mlx-lm serve останутся, но их доля упадет. Потому что когда вы запускаете 3-битную модель для конкретной цели, вам нужен сервер, который знает про все подводные камни этого формата. Не советую сейчас вкладываться в кастомизацию сложных серверов под свои нужды. Через полгода появится что-то, что сделает вашу работу бессмысленной.

Лучшая инвестиция сейчас - научиться быстро мигрировать между серверами. Написать обертку, которая абстрагирует API. И держать под рукой скрипт, который за час протестирует новый хайповый сервер и скажет, стоит ли он вашего времени. Потому что в 2026 году скорость технологий убивает.

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