Восемь MLX-серверов для Qwen 3.5 35B на Mac: кто быстрее при параллельных запросах

Запустить большую языковую модель локально на MacBook — задача, которая ещё два года назад звучала экзотично. Сегодня Qwen 3.5 35B в 4-битном квантовании умещается в 20 ГБ unified memory чипа M2 Max и отвечает быстрее ряда облачных API — просто потому что нет сетевого раунд-трипа. Разработчик из России опубликовал на Habr подробный разбор бенчмарка восьми MLX-серверов, написав автоматический харнесс на Python и прогнав пять итераций на восьми реальных промтах.

MLX — фреймворк Apple для машинного обучения, который компилируется напрямую в Metal (GPU API чипов M-series). Ключевое отличие от связки CUDA + PyTorch: на NVIDIA у вас раздельные пулы VRAM и RAM, и веса модели нужно копировать между ними. На Apple Silicon CPU и GPU делят единый пул памяти, поэтому 35B-модель лежит один раз и одинаково доступна обоим. Именно это делает локальный инференс на Mac практически осмысленным: M2 Max обеспечивает около 400 ГБ/с пропускной способности памяти, что даёт 50–80 токенов в секунду на 35B-модели. На CPU той же машины скорость была бы в 10–20 раз ниже. По сравнению с llama.cpp MLX стабильно быстрее на 10–30% на Apple Silicon и поддерживает continuous batching из коробки без промежуточной конвертации в формат GGUF.

Из восьми серверов шесть попали в бенчмарк. Два отключены: Higgs написан на Rust и распространяется как single binary без Python, mlx-serve — на Zig. Оба не вписались в автоматический харнесс, который запускает сервер как subprocess и ждёт healthcheck на /v1/models. Среди участников — mlx-openai-server с настоящим continuous batching и speculative decoding, mlx-omni-server с двойным API (OpenAI и Anthropic на одном порту), Rapid-MLX с философией «одна команда — готово» и 1900+ тестами в репозитории, vllm-mlx с paged KV cache и поддержкой мультимодальных входов, omlx с двухуровневым KV-кешем (горячая часть в RAM, холодная — на SSD), а также mlx-vlm — изначально библиотека для vision-моделей с серверным режимом.

В одиночном режиме три лидера расходятся менее чем на 2% — разница статистически незначимая. Картина меняется при двух параллельных запросах: mlx-openai-server, единственный с реальным continuous batching, показывает прирост в 2,17× относительно одиночного запроса. Четыре других сервера уходят в очередь и обрабатывают запросы последовательно. Один деградирует до 0,85× от одиночной скорости — пока не добавить флаг --workers 2.

Отдельного внимания заслуживают два технических курьёза. vllm-mlx в какой-то момент показал 14 000 токенов в секунду — цифра, физически невозможная для данного железа. Причина оказалась в одной строке SSE-парсера: сервер некорректно считал токены при стриминге, и харнесс фиксировал фантомные значения. omlx предлагает интересную архитектуру с тиерингом KV-кеша на SSD, веб-дашборд и поддержку MCP, но имеет hardcoded лимит контекста в 32 768 токенов — промты длиннее получают HTTP 400 без объяснений. Ещё один сюрприз: после завершения бенчмарка один из серверов оставлял зомби-процесс, удерживающий 20 ГБ RAM, — ни в одном README об этом не сказано.

Практический мотив для всей затеи — три сценария, где локальная модель выигрывает у облака. Первый: конфиденциальные документы — договоры, ТЗ, переписка с клиентами — которые нельзя отправлять во внешние сервисы. Второй: агентные системы, которые гоняют задачи в цикле по несколько часов; при подписочных тарифах токены быстро превращаются в значимые суммы, тогда как локальная модель работает на уже оплаченном железе. Третий: отсутствие rate-limit и сетевой задержки — для интерактивной разработки это ощутимо. Все современные open-source инструменты для ИИ-кодинга — OpenCode, Aider, Claude Code — поддерживают OpenAI-совместимый endpoint, так что переключение сводится к одной строке конфига: base_url: http://mac.local:8000/v1.