MTPLX на M1 Ultra: Те 25 ток/с Настройка, которая обслуживала 16.5
Пересмотр в прямом столкновении: нативный MTP‑runtime MTPLX против ручной настройки mlx‑vlm lane из первой части, на M128 GB M1 Ultra. Автотюнер обещал 2.20x. Путь обслуживания имел другие планы — измерено с Kimi K3 в 1 день.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
Пересмотр пришёл 1 день раньше. Вчерашний M1 Ultra статья о тюнинге закрылось с прогнозом: когда релиз MLX появится с скомпилированными графами декодирования, повторная попытка против полосы 20.3 ток/с заняла бы послеобеденное время и 1 загрузку. Утром я заметил новый runtime под названием MTPLX, обещающий это будущее как готовый продукт — нативное многотокеновое предсказательное спекулятивное декодирование на Apple Silicon, автотюнер, измеряющий вашу конкретную машину, сервер совместимый с OpenAI и Anthropic, запуск в один клик для агентских harnesses, которые мы действительно используем, и Qwen3.8-27B как его флагманский модель кода. Их сайт говорит: "ваши любимые инструменты, в два раза быстрее." Я привёл его к Kimi K3, моему коллеге по приключению настройки на день раньше, и мы вместе договорились: установить чисто на Studio, дать своему тюнеру сделать лучший кейс, затем измерить, что сервер действительно обслуживает. Kimi проводил удалённую работу и счётчики; я держал правила дома и делал вызовы. Так действительно прошёл день.MTPLX — это версия продукта полосы, которую мы построили вместе#
Архитектура заслуживает признания сразу, потому что это правильная идея, выполненная серьёзно. MTPLX создаёт черновики с собственными MTP‑головками модели — той же механикой, которую использует наша полоса — и принимает черновики через точную выборку с отклонением, так что выборка при температуре 0.6 даёт идентичное распределение, как обычное декодирование, только быстрее. Нет отдельной модели черновика, потребляющей память, глубина черновика настраивается для каждой машины относительно автогрессивной базы, и проект отказывается прикреплять непроверенные MTP‑сайдкары к произвольным весам. Эта последняя политика была дисциплиной, которую Кими и я пришлось применить вручную за день до этого, когда мы повторно соединили отвалившиеся MTP‑тенсоры Qwen3.8 с их стволом. Полоса из первой части была очевидной мерой: тот же Studio, та же семейство моделей, измерено одинаково.Установка прошла проверки карантина 2 до того, как коснулась веса#
Первая проверка была моей. В марте, в моей автономной лаборатории доработки, мы столкнулись с ловушкой, где изолированная Python среда тихо потеряла доступ к ускоренным библиотекам Apple, и цифры возвращались только медленно. Прежде чем Кими продолжил, я попросил доказательства того, что ловушка не применима. Пробник 3-линии разъяснил ситуацию — нативный arm64 интерпретатор, Metal доступен, GPU как устройство по умолчанию. Путь Metal Apple поставляется внутри самого колесаmlx-metal, поэтому происхождение интерпретатора не имеет значения для доступа к GPU, а дорожка из первой части уже доказала пропускную способность GPU-native через ту же изоляционную форму. Собственный инспектор MTPLX согласился, оценив обе его сборки Qwen3.8-27B как проверенные нативными с всеми 15 MTP тензорами присутствующими.Второй контроль был от Кими, во время загрузки. Команда pull MTPLX игнорирует обычные переменные окружения кэша Hugging Face, и первая попытка записала 20 ГБ модели в домашний каталог Studio вместо тома данных, который защищают правила дома. Кими остановил загрузку, удалил только то, что создал, и перезапустил с явным каталогом кэша. Фанаты оставались на кривой Apple весь день, что важно для машины, которая также служит симулятором полёта.Самый громкий аппарат того утра не был тем, который запускал эксперимент#
Во время загрузки моя собственная рабочая станция начала резко нагреваться — средняя нагрузка поднималась выше 50 — и мы остановили эксперимент, чтобы ответить на более важный вопрос: было ли это нашим делом? Это не было. Наша работа велась на Studio в коротких сессиях SSH; локальный след был всего несколькими завершёнными процессами curl и ssh. Шторм был волной демонов Apple — зависшая загрузка ассета, индексация и всплеск от процесса виртуализации, который исчез, прежде чем мы смогли назвать его владельца — плюс открытие того, что «тайные процессы, которые я убивал, перезапускающиеся» были 3 руководителями разработки, которые делали ровно свою работу, перезапуская свои серверы. Мы записали всё это в передачу защиты машины и вернулись к эксперименту с чистой совестью. Пауза принадлежит этой истории, потому что дисциплина та же, что и у бенчмарков: знать свой собственный след, прежде чем обвинять машину.Автотюнер измерил 2.20x разрыв#
Ритуал настройки MTPLX — честная инженерия: он запускает реальную модель на вашем оборудовании на каждом уровне черновика, сохраняет авто-регрессионное декодирование как базовую линию, и сохраняет глубину только если она превосходит эту базовую линию. На M1 Ultra он получил AR 11.4, глубину 1 при 9.2, глубину 2 при 25.1, глубину 3 при 20.7 ток/с — глубина 2 была коронована победителем при 2.20x, сохранена для всех будущих запусков.Это 25.1 — реальная измеряемая величина реального двигателя, 24% выше нашей полосы 20.3 скорости обслуживания. Если бы сервер воспроизвел это, эта статья была бы руководством по миграции.Сервер обслужил 16.5, и настройки по умолчанию тратили токены незаметно#
Рабочая станция обслуживания использовала те же запросы, температуру 0 и учёт по реальному времени, как базовая линия полосы. Первый запуск вернулся с 14.7 ток/с, и метаданные ответа показали 2 настройки по умолчанию, работающие против измерения:- Режим рассуждения по умолчанию включён, и Qwen3.8 думает, прежде чем отвечать. При простом запросе «считай до 10», 44 из сгенерированных токенов 64 были скрыты в рассуждениях, которые клиент никогда не отображает. Реальные нагрузки платят за эти токены, поэтому скорость по реальному времени уже их включает — но запросы тюнера не облагаются таким налогом.
- Профиль выполнения Turbo, с его скомпилированными проверочными ядрами, является правилом запуска нативного приложения Mac. Терминал
mtplx serveразрешает профиль Sustained вместо него, поэтому путь командной строки никогда не видит быстрых ядер, если вы не попросите.
| tokens per second | |
|---|---|
| our lane (part one) | 20.3 |
| MTPLX tune claim (D2) | 25.1 |
| MTPLX FP16 turbo D2 | 16.5 |
| MTPLX 4-bit turbo D2 | 15.5 |
| MTPLX defaults | 14.7 |
Тюнер и сервер измеряют 2 разные машины#
Самое полезное открытие дня объясняет разрыв между 25.1 и 16.5. Логи собственного сервера MTPLX показывают лестницу разогрева при запуске, и эта лестница сообщает 20‑24 ток/с от движка — внутри того же процесса, который затем обслуживает 16,5 на HTTP. Движок быстрый, а транспорт нагружен. Между циклом декодирования и клиентом находятся слой HTTP, учёт банков сессий на запрос (запись снимка 160 МБ появилась в статистике первого запроса), и механизм рассуждения, и каждый токен пересекает эту границу. На чипах M4 и M5, где опубликованы показатели 1.6‑2.24x, более быстрый CPU и ткань поглощают пересечение. Движок M1 Ultra держит темп; его путь обслуживания не.graph LR
subgraph Путь тюнера
A[Реальная модель] --> B[Глубины черновика D1‑D3]
B --> C[Таймер только декодирования
25.1 ток/с]
end
subgraph Путь обслуживания
D[Запрос HTTP] --> E[Банк сессий
+ по умолчанию рассуждения]
E --> F[Тот же движок
лестница показывает 20‑24]
F --> G[Граница на токен
16.5 ток/с по стенке]
end
style C fill:transparent,stroke:#10B981,stroke-width:2px
style G fill:transparent,stroke:#F59E0B,stroke-width:2pxCopy sourceПретендент ушёл на 38 ГБ легче, а сторож остался позади#
Я дал Кими 1 непременным условием до начала эксперимента: всё, что работает в том Студии, должно остановиться при простое, потому что вечерняя работа машины — это симулятор полёта. MTPLX не предоставляет таймаут простоя для своего чат‑сервера, поэтому Кими встроил сторож в небольшой обёрточный скрипт — привязка только к loopback, вентиляторы по политике Apple, и наблюдатель соединений, который останавливает сервер после 10 минут без клиентов. Он прошёл живой огневой учёт, разрушив тестовый экземпляр на отметке 60‑секунды и чисто освободив порт. Обёртка и виртуальная среда остаются на машине, поэтому повторный тест находится на 1 скачивание, когда выпуск MTPLX работает путь обслуживания M1‑гена или выпускает совпадающий MTP‑артефакт ближе к 15 ГБ.Само весы не остались. Как только вердикт был ясен, мы тщательно прошли очистку — обе директории модели MTPLX, 38 ГБ по FP16 и 4‑битовые сборки, удалённые после подтверждения, что ни один процесс их не держал, возвращая объём к точно его пред‑экспериментальному свободному пространству. Удаление остаётся частью рабочего процесса: каждый претендент, который проигрывает, оставляет диск в тот же день, что сохраняет честность следующего эксперимента.Что добавил повтор к контрольному списку#
Полоса из первой части так и не переместилась. Она обслуживала утро на 20.3 ток/с, вечер на 20.3 ток/с, и теперь держит своё место против 3 претендентов вместо 2 — всё ещё экспериментальная полоса, 1 скачок от её следующего повторного испытания. Контрольный список из первой части получает 3 записей:- Номер тюнера – это потолок двигателя, а путь обслуживания решает, сколько из него вы сохраняете. Измеряйте на границе, через которую действительно проходят ваши клиенты.
- По умолчанию часть от benchmark. Режимы рассуждений, профили выполнения и кэши сессий тратят токены или время, а справедливая битва явно закрепляет их обеих сторон.
- Диск – это бюджет гипотез. 2 претендент строит на 20.4 ГБ каждый купленный 1 послеобеденный день уверенности, и уверенность дешевле, когда байты уходят по расписанию.