リマッチは1日早く到着しました。 昨日の M1 Ultra tuning article は予測で締めくくられた：MLX リリースがコンパイルされたデコードグラフを持ってリリースされたとき、20.3 tok/s レーンに対するリマッチは午後と 1 ダウンロードを要するだろう。 今朝、私は新しいランタイム MTPLX を発見した。これは将来を完成品として約束している――ネイティブマルチトークン予測スペキュレーティブデコーディングを Apple Silicon 上で、あなたの特定のマシンを測定するオートチューナー、OpenAI と Anthropic 互換のサーバー、実際に使用するエージェントハーネスの 1 クリック起動、そして Qwen3.8-27B を旗艦コーディングモデルとして備えている。 彼らのサイトは「あなたのお気に入りツール、速度が倍になる」と述べている。 私はそれを Kimi K3、前日に調整冒険の共同研究者に持ち込み、私たちは一緒に条件を設定した：Studio にクリーンにインストールし、独自のチューナーに最善のケースを作らせ、次にサーバーが実際に提供するものを測定する。 Kimi はリモート作業とカウンターを実行し、私はハウスルールを守り、呼び出しを行った。 これが実際にその日が進んだ方法だ。

MTPLX は私たちが一緒に構築したレーンの製品バージョンです

アーキテクチャは最初から称賛に値します、なぜならそれは正しいアイデアを真剣に実行したからです。 MTPLX はモデル自身の MTP ヘッドでドラフトを作成します — 私たちのレーンが使用するのと同じメカニズム — そして正確な拒否サンプリングを通じてドラフトを受け入れます。したがって、温度 0.6 でサンプリングすると、通常のデコードと同じ分布を生成しますが、より高速です。 別のドラフトモデルがメモリを消費することはなく、ドラフト深度は機械ごとに自己回帰ベースラインに対して調整され、プロジェクトは未検証の MTP サイドカーを任意の重みに添付することを拒否します。 その最後のポリシーは、私たちが前日に手動で適用しなければならなかった規律です。Qwen3.8 の落ちた MTP テンソルをその幹部と再ペアリングしたときです。 パートワンのレーンは明らかな測定基準でした：同じ Studio、同じモデルファミリー、同じ方法で測定されました。

インストールは重みを触る前に 2 除菌チェックに合格しました

最初のチェックは私のものでした。 3 月に、私の自律的な改良ラボで、隔離された Python 環境が Apple の加速ライブラリへのアクセスを静かに失い、数値が遅く戻る罠に遭遇しました。 Kimi がさらに進む前に、罠が適用されなかったことを証明してもらいました。 3 行のプローブでそれが解決しました — ネイティブ arm64 インタープリタ、Metal が利用可能、GPU がデフォルトデバイス。 Apple の Metal パスは mlx-metal ウィール自体に組み込まれているため、インタープリタの起源は GPU アクセスに関係なく、パートワンのレーンは同じ隔離形状を通じて GPU ネイティブスループットをすでに証明していました。 MTPLX の独自のインスペクタも同意し、両方の Qwen3.8-27B ビルドがすべての 15 MTP テンソルを持つ検証済みネイティブであると評価しました。
2 番目のチェックは Kimi のもので、ダウンロード中。 MTPLX の pull コマンドは通常の Hugging Face キャッシュ環境変数を無視し、最初の試みは 20 GB のモデルを Studio のホームディレクトリに書き込もうとしました。これは家のルールで保護されるデータボリュームではありませんでした。 Kimi はプルを中止し、作成したものだけを削除し、明示的なキャッシュディレクトリで再起動しました。 ファンは一日中 Apple の曲線に沿って動き続けました。これはフライトシミュレータとしても機能するマシンでは重要です。

その朝、最も大きな音を出した機械は実験を実行していたものではありませんでした

ダウンロード中、私自身のワークステーションが急激にスパイクし始めました — ロード平均が 50 を超え、私たちは実験を停止し、より重要な質問に答えました：これは私たちのせいだったのか？ そうではありませんでした。 私たちの作業は Studio 上で短命の SSH セッションで実行されました；ローカルのフットプリントは数個の完了した curl と ssh プロセスでした。 嵐は Apple デーモン波でした — つまづいたアセットダウンロード、インデックス作成、そして仮想化プロセスからのバーストが、所有者を名付ける前に消えてしまいました — さらに「謎の再生成ノードプロセス」を殺していたのが、サーバーを再起動して仕事を正確に行っていた 3 人の開発監督だったことが判明しました。 私たちはそれをすべてマシンガードのハンドオフに書き込み、清い良心で実験に戻りました。 この一時停止はこの物語に属します。なぜなら、規律はベンチマークが走るのと同じであるからです：機械を非難する前に自分のフットプリントを知ること。

オートチューナーは2.20倍のブローアウトを測定しました

MTPLXのチューニング儀式は正直なエンジニアリングです：それは各ドラフト深度で実際のモデルをあなたのハードウェア上で実行し、自己回帰デコーディングをベースラインとして保持し、そのベースラインを上回った場合にのみ深度を保存します。 M1 UltraではAR 11.4、深度 1 は 9.2、深度 2 は 25.1、深度 3 は 20.7 tok/s で生成されました — 深度 2 が 2.20倍で勝者に選ばれ、すべての将来の起動のために保存されました。
その25.1は実際のエンジンの実測値であり、24%は私たちのレーンの20.3サービスレートを上回っています。 サーバーがそれを再現していれば、この記事は移行ガイドになっていたでしょう。

サーバーは 16.5 を提供し、デフォルトは目に見えないトークンを消費していました

サービングベンチは同じプロンプト、温度 0、およびレーンのベースライン と同じウォールクロック計算を使用しました。 最初の実行は 14.7 tok/s で戻り、レスポンスメタデータは測定に対して機能している 2 デフォルトを浮き上がらせました：
  • 推論モードはオンにデフォルトで、Qwen3.8 は回答前に考えます。 10 まで数える単純なプロンプトでは、44 の 64 生成トークンのうち、クライアントが表示しない推論が隠されていました。 実際のワークロードはそれらのトークンに対して支払うため、ウォールレートにはすでにそれらが含まれています — しかしチューナーのプロンプトにはそのような税金はありませんでした。
  • Turbo ランタイムプロファイルは、コンパイルされた検証カーネルを備えており、ネイティブ Mac アプリの起動ルールです。ターミナル mtplx serve は Sustained プロファイルに解決されるため、コマンドラインパスは高速カーネルを見ません（要求しない限り）。
Turbo を固定し、深度 2、推論をオフにすると FP16 ビルドは 16.5 tok/s ウォールに上昇しました — MTPLX が一日中最高を出しました。 4-ビット最適化スピードビルドは、プロジェクトがコーディングに推奨するもので、15.5 を提供しました。 両ビルドはディスク上で 20.4 GB で、私たちのレーンの 15 GB と同じです。帯域幅制限のあるマシンでは、すべてのトークンが追加の 5 GB をストリームするために支払われます。
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 tok/s を報告します — 同じプロセス内で 16.5 を HTTP で提供します。エンジンは高速で、トランスポートは課税されます。 デコードループとクライアントの間には HTTP レイヤー、リクエストごとのセッションバンク簿記（最初のリクエストの統計に 160 MB スナップショット書き込みが表示されました）、推論機構があり、各トークンはその境界を横断します。 M4 と M5 チップでは、プロジェクトの公開された 1.6-2.24x 数値が測定され、より高速な CPU とファブリックが横断を吸収します。 M1 Ultra のエンジンは追いつきます；そのサービングパスはそうではありません。
Diagram source
graph LR
    subgraph チューナーパス
        A[実際のモデル] --> B[下書き深度 D1-D3]
        B --> C[デコードのみタイマー  
25.1 tok/s]
    end
    subgraph サービングパス
        D[HTTP リクエスト] --> E[セッションバンク  
+ 推論デフォルト]
        E --> F[同じエンジン  
ラダーは 20-24 を示します]
        F --> G[トークン境界  
16.5 tok/s 壁]
    end

    style C fill:transparent,stroke:#10B981,stroke-width:2px
    style G fill:transparent,stroke:#F59E0B,stroke-width:2px
これはパート1のレッスンで、新しい衣装を着ています。 llama.cpp のコミュニティの 25-32 tok/s の主張は、このチップとの接触で生き残らず、MTPLX のチューナー 25.1 は自分のサーバー で生き残りません。 耐久ルールは鋭くなる：サービングレートは HTTP 境界で測定され、プロダクションデフォルトが可視化され、チューナー内では決して測定されない。 それは benchmark-driven development がスタックの1層上で適用されたものです。

チャレンジャーは 38 GB 軽くなり、ウォッチドッグは後ろに残りました

実験開始前に Kimi に 1 を非交渉可能にしました：その Studio 上で動作するものはアイドル時に自分自身を停止しなければならず、マシンの夕方ジョブはフライトシミュレータ です。 MTPLX はチャットサーバーにアイドルタイムアウトを提供しないため、Kimi は小さなラッパースクリプトにウォッチドッグを組み込みました — ループバックのみのバインディング、Apple のポリシーでファンをオン、10 分間クライアントがいないとサーバーを停止する接続ウォッチャー。 それはライブファイヤードリルに合格し、60 秒のマークでテストインスタンスを破壊し、ポートをきれいに解放しました。 ラッパーと仮想環境はマシン上に残るため、再テストは MTPLX リリースが M1 世代のサービスパスを動作させるか、または 15 GB に近いマッチド-MTP アーティファクトを出荷するときに 1 ダウンロード離れです。
重み自体は残りませんでした。 判決が明確になったら、私たちはクリーンアップを慎重に行いました — MTPLX モデルディレクトリの両方、FP16 と 4 ビットビルドで 38 GB、プロセスが保持していないことを確認後に削除し、ボリュームを実験前の正確な空き領域に戻しました。 削除はワークフローの一部として残ります：負けたチャレンジャーは同じ日にディスクを離れ、次の実験を正直に保ちます。

リマッチがチェックリストに追加したもの

パートワンのレーンは動かなかった。 それは朝に20.3 tok/sでサービスし、夕方に20.3 tok/sでサービスし、今では3 チャレンジャーに対して自分のスロットを保持している、2 ではなく — まだ実験的なレーン、次のリマッチまで1 ダウンロード離れた。 パートワンのチェックリストは3 エントリを増やす：
  • チューナーの番号はエンジンの天井であり、サービスパスはそれをどれだけ保持するかを決定する。 境界でクライアントが実際に横断するものを測定する。
  • デフォルトはベンチマークの一部である。 推論モード、ランタイムプロファイル、セッションキャッシュはすべてトークンまたは時間を費やし、公正な戦いはそれらを両側に明示的に固定する。
  • ディスクは仮説予算である。 2 チャレンジャーは20.4 GBで構築され、各購入は1 確実性の午後であり、確実性はバイトが予定通りに離れるときに安価になる。
ペアの満足できる対称性は、パートワンがこの正確な実験をキューに入れて終了し、実験が本物のクラフトを備えた製品としてパッケージ化されたことだ — 正確なサンプリング、機械ごとのチューニング、正直な検証。 クラフトは本物で損失も本物であり、両方の発見は同じ測定日、CPUストームとすべてから出た。 スコアボード付きの冒険が最高の種類であり、今回のものはキミK3が私の隣のすべてのカウンタを読み取っていた — 私がlocal AI gains as infrastructureを扱うときに得るのと同じ複利リターン。 レーンは自分のスロットを保持し、ディスクはスリムで、チェックリストは長く、次のチャレンジャーはすでに試すことを歓迎されている。