Пересмотр пришёл 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 вместо него, поэтому путь командной строки никогда не видит быстрых ядер, если вы не попросите.
При закреплении Turbo, глубине 2, и отключении рассуждений, сборка FP16 поднялась до 16.5 ток/с по реальному времени — лучшая MTPLX работала весь день. Сборка 4‑бит Optimized-Speed, которую проект рекомендует для кодирования, обслуживала 15.5. Обе сборки занимают 20.4 ГБ на диске по сравнению с нашими полосами 15 ГБ, и на машине с ограниченной пропускной способностью каждый токен платит за поток этих дополнительных 5 ГБ.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)
Chart data
tokens per second
our lane (part one)20.3
MTPLX tune claim (D2)25.1
MTPLX FP16 turbo D216.5
MTPLX 4-bit turbo D215.5
MTPLX defaults14.7

Тюнер и сервер измеряют 2 разные машины

Самое полезное открытие дня объясняет разрыв между 25.1 и 16.5. Логи собственного сервера MTPLX показывают лестницу разогрева при запуске, и эта лестница сообщает 20‑24 ток/с от движка — внутри того же процесса, который затем обслуживает 16,5 на HTTP. Движок быстрый, а транспорт нагружен. Между циклом декодирования и клиентом находятся слой HTTP, учёт банков сессий на запрос (запись снимка 160 МБ появилась в статистике первого запроса), и механизм рассуждения, и каждый токен пересекает эту границу. На чипах M4 и M5, где опубликованы показатели 1.6‑2.24x, более быстрый CPU и ткань поглощают пересечение. Движок M1 Ultra держит темп; его путь обслуживания не.
Diagram source
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:2px
Это урок первой части, одетый в новый костюм. Сообщения сообщества llama.cpp о 25‑32 ток/с не выжили при контакте с этим чипом, и 25.1 тюнера MTPLX не выжили на своём собственном сервере. Долговечное правило уточняется: скорость обслуживания измеряется на границе HTTP с видимыми настройками производства, никогда не внутри тюнера. Это benchmark-driven development применено на один уровень выше в стеке.

Претендент ушёл на 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 послеобеденный день уверенности, и уверенность дешевле, когда байты уходят по расписанию.
Удовлетворяющая симметрия пары в том, что первая часть закончилась очередью этого же эксперимента, а эксперимент пришёл упакованным как продукт с настоящим мастерством — точная выборка, настройка на машину, честная проверка. Мастерство было реальным, и потеря была реальной, и оба вывода пришли из того же дня измерений, CPU‑шторм и всё. Приключение с таблицей результатов – лучший вид, и это имело Кими K3, читающий каждый счётчик рядом со мной — тот же сложный доход, который я получаю от обращения локальных AI gains как инфраструктуры. Полоса сохраняет своё место, диск тонкий, контрольный список длиннее, и следующий претендент уже готов попробовать.