2026 Mac Apple Silicon: нативный macMLX против mlx-batch-server — локальные OpenAI-совместимые API, окно батча и матрица выгрузки

Для Cursor и собственных агентов на OpenAI-совместимом localhost на Apple Silicon сосуществуют два MLX-подхода: macMLX (Swift, без Electron) и серверы уровня mlx-batch-server с явными MLX_BATCH_*. Оба отдают /v1, но параллелизм, RSS и журналы различны. Объединённая память делится с Xcode, браузером и VideoToolbox — нужно фиксировать отпечаток нагрузки. LiteLLM помогает с ключами, но не создаёт полосу Metal. Читайте вместе с OpenAI API + launchd и vllm-mlx multi-agent.

1. Боли — одна точка `/v1`, две эксплуатационные модели

1) Среда исполнения: macMLX держит Swift-ядро и интерфейс «рабочего стола»; mlx-batch-server тянет Python/mlx-lm и журналирует иначе. Перепутав их, вы получите ложные эскалации «сломанный шлюз» вместо «узкий Metal».

2) Параллелизм: координатор батча собирает HTTP в окне 50–200 мс — выше суммарный tok/s для офлайна, но опаснее TTFT/SSE для IDE, если процесс общий.

3) Объединённая память: Xcode, браузер и VideoToolbox делят бюджет с MLX; без замеров RSS кажется, что «модель испортился», хотя виноваты swap или троттлинг.

4) LiteLLM: роли ключей и провайдеров, но не дополнительная пропускная способность Metal. Переносите пики на удалённый Mac только когда минимальное окно батча уже не спасает соотношение TTFT p95/p50.

2. Сравнительная таблица — контрольный стол против потока батча

Параметр	macMLX	mlx-batch-server
Назначение	Единый Swift UX, быстрая смена весов	Многослотовые HTTP API и статистика очередей
Порты (пример)	`:8000/v1`	`:10240/v1`, настраивается
Ручки	KV-слои, закрепление моделей	`MLX_BATCH_BATCH_WINDOW_MS`, `MLX_BATCH_MAX_BATCH_SIZE`
Телеметрия	RSS и уровни KV	Гистограммы батча, глубина очереди
Сигнал к удалённому Mac	IDE остаётся локально, выносим только пики	Постоянная нагрузка выше теплового бюджета ноутбука

На практике полоса Metal не масштабируется «маршрутизатором ключей»: LiteLLM подключают после того, как известно, какой процесс отвечает за выгрузку KV и перезапуск движка. Удалённые узлы MACGPU уместны, когда демо и прод совпадают по времени и нельзя смешивать SLA кафе-Wi-Fi с боевым инференсом.

Для команд с жёстким аудитом данных локальный MLX сохраняет повторяемость квантизации; если окно батча всё равно упирается в swap, почасовая аренда Apple Silicon в ЦОДе часто дешевле бесконечного роста облачных токенов — без смены toolchain.

3. Пять шагов приёмки — окно, RSS и хвосты латентности

Шаг 1 Классы нагрузок

Стриминг (stream:true) и офлайн-батчи не смешивать в одном прогоне — иначе любая настройка «MLX_BATCH_*» не интерпретируется.

Шаг 2 Тройка чисел

Окно в миллисекундах, максимум слотов и доля RSS от физической RAM; зафиксируйте момент устойчивого swap (>512 МБ).

Шаг 3 Хвосты

Для чата — TTFT и первый байт SSE; для батча — tok/s на слот по p95, а не только суммарная скорость.

Шаг 4 Намеренная деградация

Пройдите окно 50→200 мс и выпишите точку, где UX ломается — это будущий «жёсткий потолок» в runbook.

Шаг 5 Артефакты тикета

SKU чипа, хеш MLX и переменные окружения приложите к тому же инциденту, что и графики — иначе регрессию не воспроизвести.

export MLX_BATCH_BATCH_WINDOW_MS=80\nexport MLX_BATCH_MAX_BATCH_SIZE=12

4. Матрица решений — локально / LiteLLM / удалённый Mac

Условие	Сначала	Запасной	Не делать
RSS >82 % RAM ≥10 минут	Срезать параллелизм или перенести тяжёлую модель	Выделенный удалённый узел	Ждать чуда от прокси
TTFT p95/p50 >2,8× при минимальном окне	Разделить интерактив и офлайн	Вторая инстанция только для чата	Слепо увеличивать параметры
Несколько провайдеров с аудитом	LiteLLM со списком fallback	Юридически оформленный spillover	Цепочки шлюзов без ревью
Повторные OOM/Jetsam	Анализ swap/thermal	PoC на удалённом Mac до CAPEX	Покупать технику вслепую

Три порога для внутренней базы: swap >768 МБ дольше 90 с — немедленный отказ от наращивания нагрузки; TTFT p95/p50 >2,8 после минимизации окна — архитектурное разделение; две OOM за неделю — удалённый PoC до обсуждения бюджета.

5. Кейс — команда из четырёх человек на одном MacBook Pro

Окно 180 мс гнало суммарный tok/s, но к демо неделе вентилятор шёл на максимум, а SSE дрожал. Перенос только батча на удалённый Mac mini стабилизировал поток; Cursor остался на локальном macMLX.

Корень был не в чекпойнте, а в совместном процессе для стрима и офлайна. После разделения те же веса MLX продолжили работать, но SLA стало можно озвучить финансистам: «интерактив» против «офлайн», почасовая аренда против простоя людей.

Apple Silicon остаётся лучшей платформой для мультимедиа и агентов на столе; круглосуточные батчи без запаса по охлаждению логичнее держать на стационарном или арендованном узле с предсказуемым блоком питания.

6. Вывод — LiteLLM после политики, MLX по метрикам

Нативный macMLX ускоряет прототипы; batch-серверы покупают параллельную экономику. LiteLLM ставят тогда, когда маршруты и ключи описаны — не как замену сбросу GPU-памяти. По сравнению с чистым облаком MLX на Mac сохраняет воспроизводимость квантизации; по сравнению с перегретым ноутбуком почасовая аренда удалённого Mac выравнивает затраты и реальные пики.

У MACGPU такие узлы нужны именно тогда, когда метрики Metal и журнал уже доказали: переносите нагрузку из кафе и домашнего Wi-Fi в среду с охлаждением и сетью ЦОДа — прежде чем SLA станет шуткой.

Практический признак готовности к офлоуду — когда журнал Metal или счётчики Activity Monitor показывают не случайные всплески, а устойчивые плато после нескольких циклов prefill/decode: значит узел уже «держит темп», который ноутбук физически не может поддерживать без дросселя частот. На этом этапе удалённый Mac даёт те же MLX-бинарники и переменные, но без конфликта с вашими локальными креативными задачами.

Итог: измеряйте окна батча, RSS и явные триггеры выгрузки. Если минимальное окно всё ещё даёт TTFT/Swap вне бюджета, арендуйте удалённый Mac с предсказуемым питанием — это надёжнее лишних SSH-туннелей или непрозрачных шлюзов.

7. FAQ — типичные заблуждения

Нужен ли LiteLLM уже на POC? Нет — сначала локальные базовые линии и триггеры выгрузки. LiteLLM подключают, когда появляются несколько ключей и политик доступа.

Можно ли держать один и тот же MLX-вес на ноутбуке и удалённом узле? Да, если контрольные суммы и профиль квантизации совпадают; избегайте расхождений в переменных окружения.

Когда «купить больше RAM» не помогает? Когда после минимизации окна батча swap и температуры всё ещё держат узкое место — охлаждение и БП, а не объём памяти сам по себе.