このページは英語版ドキュメントの翻訳です。コマンド、識別子、例はそのままです。ランタイム 7.24.5 · SDK 2.6.9。 英語版

ローカル推論の測定: 19 September 2026

ステータス: 現行

対象範囲: 測定済みの診断スナップショット

最終確認: 2026-09-19

所有者: ax-code runtime

ローカルプレフィックス修正後の、完全な 6 組み合わせのクライアント行列は、新しい AX Code / OpenCode の再試験 を参照してください。下記のクライアント速度は、元の条件のもとでの過去の観測のままです。

これらの測定は、128 GiB のユニファイドメモリを備えた Apple M3 Max 1 台での、ローカル応答遅延とデコード速度を調べたものです。ハードウェア認定でも、モデル品質の評価でも、任意のコンテキスト長で 30–40 tokens/s を約束するものでもありません。MTPLX と oMLX の接続手順は ローカルランタイムガイド にあります。

条件と計時

• AX Code のソースは v7.19.3 に基づきます。OpenCode 1.18.31、AX Engine 7.4.0、MTPLX 2.11.3、oMLX 0.6.4（1d7826185c5b5b69b38b27cbe57d7597b7551fd7、隔離されたソースインストール）です。
• 推論バックエンドは一度に 1 つです。ファン制御は既定で、最大ファンの主張はありません。モデルファイルは SMB ストレージ上にありました。MTPLX の正確な成果物の実行では、MTP サイドカーだけを SSD に置き、その SHA-256 を検証しました。
• 正確な成果物の再生は AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP、改訂 4d36d652c21590f6813495351c3baf5fca5b3831 を使いました。別の MTPLX Optimized-Speed のクライアント実行は Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed を使いました。合計ファイルサイズは似ていても、これらは異なるモデルパッケージです。その速度から、ランタイムだけの高速化を切り出すことはできません。
• 共通の再生設定は、temperature 0.55、top-p 1、top-k 0、seed 0、生成トークンは最大 256 です。AX Engine と MTPLX は、有効な MTP 深さ 3 を使いました。ランタイムのカーネルと投機的サンプラーは異なります。成果物のメタデータが宣言する深さは 1 です。ここでの深さ 3 は明示的なランタイム実験であり、成果物の認証の拡張でも、新しい既定の推奨でもありません。AX Engine は固定出力のネイティブ再生で EOS を無視しました。MTPLX と oMLX は各自の停止規則に従います。
• ネイティブデコード速度 はバックエンドのデコードカウンタを使います。配送速度 は (reported completion tokens - 1) / (last output payload time - first output payload time) です。空のイベントとキープアライブは出力に数えません。これらの境界は同一ではありません。
• 最初のペイロードまでの遅延 には、サーバー上の要求準備、キャッシュ復元とプリフィル、出力前のバッファリングが含まれます。全トークンを要求全体で割った値は、別のスループット指標です。ツール呼び出しのバーストは、最初から最後のペイロードまでのデコード見積もりには向きません。

たとえば、同じ MTPLX の 30k 入力再生は、ネイティブデコード 13.99 tokens/s でしたが、要求全体では 1.13 tokens/s だけでした。冷えたプリフィルが約 209 秒を消費したためです。要求全体の数値が低いことだけでは、デコードエンジンの失敗は確立しません。

同一重みでの AX Engine と MTPLX の再生

各組は同じ整数の入力トークン列を受け、256 トークンを出力しました。下記の値は単一の観測です。共通の seed があっても、生成されたトークンの同一性は異なり得ます。

MTPLX はこの成果物に Sustained プロファイルを使いました。30k の AX Engine 要求は温まっており、MTPLX は冷えていたため、最初のトークンまでの時間からプリフィル速度の比は確立できません。30k の入力には過去のステップ上限の指示が含まれ、診断用の文章を生みます。コーディングタスクの受け入れではありません。18,643 トークンの MTPLX 再生は、256 トークンのあと stop を報告し、length ではありませんでした。

短いプロンプトでは、デコード速度は似ています。これらの実行は、どちらかのバックエンドが普遍的に速いことや、AX Code を別のバックエンドへ切り替えると固定の高速化が保証されることを示しません。

MTPLX Optimized-Speed 上の AX Code と OpenCode

両方のクライアントは、同じユーザータスク、完全なプロジェクト指示、許可された 4 つのツールスキーマを受け取りました。タスクは、ツールを実行せずに TypeScript の LRU キャッシュを求めました。クライアント固有のプロンプトは保持されました。記録プロキシがサンプリングを揃え、思考を無効にし、要求とサーバーの上限を 1024 トークンにしました。次の応答は正常に完了しました。

これらの測定は、AX Code のローカルプレフィックス修正（42908b46a）より前のものです。AX Code はより多くの文脈を送り、異なるコードを生みました。これは等トークンのクライアントオーバーヘッド比較でも、前後の結果でもありません。別の再生で、自動走査されたディレクトリマップだけを除くと入力は 30,717 まで減りましたが、観測されたデコードの改善は約 2% だけでした。ディレクトリマップの除去は採用されませんでした。

別の AX Engine アダプター行列では、AX Code が入力 33,225 トークンで配送 9.44–11.56 t/s、OpenCode が 17,290 で 12.82–13.00 でした。プロンプト長、出力内容、キャッシュ状態、256 トークンの出力上限は、上の完全応答の表と異なります。これらを 1 つのバックエンド高速化比にまとめないでください。

oMLX の測定

oMLX の試験は、正確な AXQ 成果物と、MLX 0.32.0 を含む隔離インストールを使います。qwen35_prefill と decode_fast を含む、ネイティブカーネルのインポート検査 5 件はすべて合格しました。テキストのみの読み込みが明示的に選ばれ、コンテキストウィンドウは 65,536、並行度は 1 です。

最初の Lightning MTP の試行は HTTP 409 を返しました。試験が、oMLX の必須手順である MTP サイドカーをインポート を飛ばしたためです。これはセットアップの誤りであり、AXQuant サポートの欠落ではありません。AXQuant はすでに正規の qwen3-next-mtp 契約を提供していました。現在の Hub 改訂 b0784088d4026ca569c5653e6e6243c501ef5fa9 には、15 個の MTP テンソルを列挙する axquant_omlx_compat.json も含まれます。元の再生スナップショットは、その注釈より前のものです。

MTP オフの基準線は、元の成果物で完了しました。

これらは MTP オフ の結果であり、バックエンド固有の速度差の証拠として、MTP オンのランタイムと比べてはいけません。トークナイザーの往復とサーバーのプロンプト数は、他の再生バックエンドが使った整数入力と一致しました。

修正された MTP 実行は、別の書き込み可能なコピーに対する oMLX 自身のインポーターを使います。バックボーンのシャードは変わりません。インポーターは 15 個のサイドカーテンソル名へ language_model. を追加します。各テンソルの dtype、形状、ペイロードハッシュは、インポート前後で等しいことを検証しました。したがってインポート後のファイルハッシュが異なるのは、ヘッダーが変わったためです。元のメタデータと共有モデルスナップショットはそのままです。MTP 深さ 3 は明示的に選ばれ、深さごとのドラフトと受理のカウンタが実際の実行を確認します。

短い結果は、この AXQuant パックがインポート後に oMLX Lightning MTP で動くことを確認します。長いコンテキストのデコードは、MTP が有効でも遅いままです。生成テキスト、ランタイムの版、カーネル、投機方針が異なるため、ランタイム間の差のすべてを AX Code に帰することはできません。

コーディングフローの受け入れと除外

ローカルプレフィックス修正のあと、AX Code は AX Engine と MTPLX の両方で、隔離された読み取り専用タスクを完了しました。ディレクトリと 2 つの TypeScript ファイルを読み、キュー満杯の例外を説明し、容量 7 を特定し、2 番目のファイルにしかないマーカーを返します。どちらも成功して終了し、フィクスチャのバイトを保ちました。その後の AX Engine 呼び出しは入力トークン 11,264 を再利用し、MTPLX は 11,264–12,032 を再利用しました。最初の要求本文は同一でしたが、ランタイムのテンプレートが異なるトークン数を生みました。これはツールフローと観測されたキャッシュ再利用を検証するものであり、パッチによる固定の高速化ではありません。

新しいプロバイダー ID も、ソース CLI からのライブ受け入れに合格しました。omlx はインポート済み AXQ パックと明示的な tool_call: true を使い、mtplx は Optimized-Speed パックを使い、設定済みモデル項目はありません。MTPLX は、ネイティブのモデル一覧からチャットモデルとツール能力を検出しました。どちらの実行も、成功したファイル読み取りを 2 回完了し、期待された例外、容量、ファイルにしかないマーカーを、フィクスチャのバイトを変えずに返しました。最初のシステムとユーザーのプレフィックスは、各実行の 3 要求を通じて同一のままでした。oMLX は 8,192 トークンを再利用し、MTPLX は 11,829 と 12,047 トークンを再利用しました。これらは機能検査であり、条件を揃えた性能実行ではありません。ランタイムを横断する壁時計の高速化は主張しません。

より前の、256 トークンで上限を設けた AX Code の応答は切り詰められて回復に入りました。繰り返し出力でおよそ 51–58 t/s だった速度は、新規生成の主張から除外します。プロジェクト指示やツール権限が揃っていなかった初期実行も除外します。Ollama と LM Studio は要求の組み立てだけを検査しました。それらの生成速度の結果は主張しません。

一般的な 62 トークンのプロンプトは、正確な oMLX 補完要求 として公開されています。チェックアウトのルートから、サイドカーをインポートし、MTP を有効にし、モデルを温めたあと、次で送れます。

curl --no-buffer http://localhost:8000/v1/completions \
  -H 'Content-Type: application/json' \
  --data-binary @docs/data/local-inference-short-request.json

要求のモデル ID を、サーバーが公開する ID に変えてください。ファイルには描画済みテンプレートが含まれます。チャットテンプレートが二度適用されないよう、補完エンドポイントを使います。プロンプトトークンが 62 であることを確認し、最後の使用量イベントを保持してください。冷えたモデルの読み込みとウォームアップは、別に報告しなければなりません。

非公開のプロジェクト指示、セッションプロンプト、ローカルパス、認証の詳細は公開しません。サニタイズされた測定データ には、件数、計時、ランタイムの同一性、入力ハッシュが含まれ、プロンプト本文は含まれません。したがって、完全な非公開文脈の再生は、単独で公開再現できる作業負荷ではありません。新しい比較では、同じモデル改訂、トークナイザーとテンプレート、入力 ID、出力と停止の規則、サンプリング、MTP モード、キャッシュ状態、ハードウェア、逐次実行を使ってください。タスク全体の成功は別に報告します。

上流の契約は、MTPLX のサーバーとモデルガイド と oMLX 0.6.4 です。公開されているベンチマークは別のハードウェアと作業負荷を使い、ここでの測定の代わりにはなりません。