取得 AX Code · 免費文件
AX Code.
zh-TW
English繁體中文简体中文日本語한국어FrançaisDeutschBahasa IndonesiaItalianoPortuguês (Brasil)РусскийEspañolTürkçeTiếng Việt
開始使用

本頁譯自英文文件。指令、識別名稱與範例保持原樣。執行環境 7.24.5 · SDK 2.6.9。 英文原文

本機推論測量：2026 年 9 月 19 日

狀態：有效

範圍：已測量的診斷快照

上次審閱：2026-09-19

負責人：ax-code runtime

本機前綴修正之後的完整六種組合用戶端矩陣，見 新的 AX Code／OpenCode 再測。下方的用戶端速度仍是 其原始條件下的歷史觀察。

這些測量在一台 配備 128 GiB 統一記憶體的 Apple M3 Max 上，調查本機回應延遲與解碼速度。它們不是硬體資格認定、模型品質評估，也不承諾在任意上下文長度達到 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，隔離的原始碼安裝）。
  • 一次只跑一個推論後端。使用預設風扇控制；不宣稱最大風扇。模型檔放在 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 個產生的 token。 AX Engine 與 MTPLX 使用作用中的 MTP 深度 3。執行環境核心與推測取樣器不同。 成品中繼資料宣告深度 1；此處的深度 3 是明確的執行環境實驗，不是 成品認證的延伸，也不是新的預設建議。 AX Engine 在固定輸出的原生重放中忽略 EOS；MTPLX 與 oMLX 遵循自己的停止規則。
  • 原生解碼速率使用後端解碼計數器。送達速率是 (reported completion tokens - 1) / (last output payload time - first output payload time)； 空事件與 keepalive 不算輸出。這些邊界並不相同。
  • 第一個承載延遲包含伺服器上的請求準備、快取還原／prefill，以及輸出前的任何 緩衝。總 token 除以整個請求是另一種輸送量。 工具呼叫的爆發不適合用來估計從第一個到最後一個承載的解碼。

例如，同一次 MTPLX 30k 輸入重放測得 13.99 原生解碼 tokens/s，但 整個請求只有 1.13 tokens/s，因為冷的 prefill 大約用了 209 秒。 單靠偏低的整段請求數字，不能斷定解碼引擎失敗。

精確權重的 AX Engine 與 MTPLX 重放

每一對都收到相同的整數輸入 token 序列，並送出 256 個 token。下方數值是 單次觀察；即使種子相同，產生的 token 身分仍可能不同。

輸入 AX Engine 原生解碼 MTPLX 原生解碼 AX Engine 已快取輸入 MTPLX 已快取輸入
62 個 token 39.12 t/s 39.48 t/s 未回報 0
18,643 個 token 17.49 t/s 20.93 t/s 0 0
30,019 個 token 16.06 t/s 13.99 t/s 29,696 0

MTPLX 對此成品使用其 Sustained 設定檔。30k 的 AX Engine 請求是暖的，而 MTPLX 是冷的，因此它們的第一個 token 時間不能建立 prefill 速度比。30k 輸入包含一段 歷史的步驟上限指示，並產生診斷文字；它不是程式開發工作的接受條件。 18,643 個 token 的 MTPLX 重放在 256 個 token 之後回報 stop，而不是 length。

短提示顯示相近的解碼速率。這些執行並未證明任一後端 普遍更快，也未證明把 AX Code 換成另一個後端就保證固定加速。

AX Code 與 OpenCode 在 MTPLX Optimized-Speed 上

兩個用戶端都收到相同的使用者工作、完整專案指示，以及四個允許的工具結構描述。 該工作要求一個 TypeScript LRU 快取，但不執行工具。用戶端專屬提示被保留； 錄製代理對齊取樣、停用思考，並使用 1024 token 的請求／伺服器上限。 下列回應正常完成：

用戶端 輸入 token 輸出 token 送達速率 第一個承載 已快取輸入
AX Code 36,808 277 23.92 t/s 280.05 秒 2,048
OpenCode，第一次 18,703 228 26.82 t/s 122.54 秒 0
OpenCode，重複 18,703 228 30.01 t/s 0.018 秒 18,703

這些測量早於 AX Code 的本機前綴修正（42908b46a）。AX Code 送出更多上下文，並 產生不同的程式碼。這不是等 token 的用戶端額外負擔比較，也不是前後對照結果。 在另一次重放中只移除自動掃描的目錄對應，輸入降到 30,717， 但觀察到的解碼只改善約 2%；並未採用移除目錄對應。

另一個 AX Engine 介接器矩陣觀察到 AX Code 在 33,225 個輸入 token 時為 9.44–11.56 送達 t/s，OpenCode 在 17,290 時為 12.82–13.00。提示長度、輸出內容、快取狀態，以及 256 token 輸出上限都與上方的完整回應表不同；不要把它們合成 單一的後端加速比。

oMLX

oMLX 測試使用精確的 AXQ 成品，以及帶有 MLX 0.32.0 的隔離安裝。全部五項 原生核心匯入檢查，包括 qwen35_prefill 與 decode_fast，都已通過。明確選擇純文字載入， 上下文視窗是 65,536，並行度是一。

最初的 Lightning MTP 嘗試回傳 HTTP 409，因為測試略過了 oMLX 必要的 匯入 MTP 附屬檔步驟。這是設定錯誤，不是缺少 AXQuant 支援。AXQuant 已經 提供標準的 qwen3-next-mtp 契約；目前的 Hub 修訂 b0784088d4026ca569c5653e6e6243c501ef5fa9 也包含 axquant_omlx_compat.json，列出 15 個 MTP 張量。原始重放快照早於該註記。

關閉 MTP 的基準以原始成品完成：

輸入 token 輸出 token 原生解碼 送達估計 已快取輸入
62 256 18.97 t/s 18.90 t/s 0
18,643 256 13.02 t/s 12.97 t/s 0
30,019 256 12.15 t/s 12.10 t/s 0

這些是關閉 MTP 的結果，不得拿來與開啟 MTP 的執行環境比較，當作 後端本質速度差異的證據。分詞器來回與伺服器提示計數，符合 其他重放後端使用的整數輸入。

修正後的 MTP 執行使用 oMLX 自己的匯入器，作用在另一份可寫複本上。主幹分片 沒有改變。匯入器把 language_model. 加到 15 個附屬張量名稱；每個張量的 dtype、 形狀與承載雜湊在匯入前後都已驗證相等。因此匯入檔的雜湊 不同，是因為標頭變了。原始中繼資料與共用模型快照保持完整。 明確選擇 MTP 深度 3，而且逐深度的草稿／接受計數確認確實執行了。

輸入 token 輸出 token MTP 原生解碼 送達估計 草稿接受 已快取輸入
62 256 31.12 t/s 31.02 t/s 179/195（91.8%） 0
18,643 256 17.18 t/s 17.13 t/s 177/192（92.2%） 0
30,019 256 15.19 t/s 15.15 t/s 170/199（85.4%） 0

短結果確認這個 AXQuant 套件在匯入後可與 oMLX Lightning MTP 一起運作。 儘管 MTP 作用中，長上下文解碼仍然較慢。不同的產生文字、執行環境版本、 核心與推測原則，使人無法把所有跨執行環境差異都歸因於 AX Code。

程式開發流程的接受與排除

本機前綴修正之後，AX Code 在 AX Engine 與 MTPLX 上都完成了隔離的唯讀工作： 讀取一個目錄與兩個 TypeScript 檔，解釋佇列已滿例外，指出容量 7， 並回傳只存在於第二個檔案的標記。兩者都成功結束並保留 測試素材位元組。後續 AX Engine 呼叫重用 11,264 個輸入 token；MTPLX 重用 11,264–12,032。 第一個請求主體相同，但執行環境範本產生了不同的 token 數。 這驗證工具流程與觀察到的快取重用，而不是該修補帶來的固定加速。

新的供應商 ID 也通過了來自原始碼 CLI 的即時接受：omlx 搭配已匯入的 AXQ 套件與明確的 tool_call: true，以及 mtplx 搭配 Optimized-Speed 套件且沒有設定模型 項目。MTPLX 從原生模型清單發現其聊天模型與工具能力。兩次執行 都完成兩次成功的檔案讀取，並回傳預期的例外、容量與僅存在於檔案的標記， 且沒有改變測試素材位元組。每次執行的三個請求中，最初的系統／使用者前綴保持相同。 oMLX 重用 8,192 個 token；MTPLX 重用 11,829 與 12,047 個 token。這些是功能 檢查，不是配對的效能執行；不宣稱跨執行環境的實際耗時加速。

較早被 256 token 上限截斷的 AX Code 回應進入了復原；它們大約 51–58 t/s 的重複輸出 速率排除在新生成的宣稱之外。專案指示或工具權限不相等的最初執行也排除。Ollama 與 LM Studio 只檢查了請求 建構；不對它們宣稱生成速率結果。

通用的 62 token 提示已公開為精確的 oMLX completion 請求。 從檢出根目錄，在匯入附屬檔、啟用 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。該檔包含已呈現的範本； 請使用 completions 端點，以免聊天範本被套用第二次。確認 62 個提示 token， 並保留最終的用量事件。冷的模型載入與暖機必須分開回報。

私人專案指示、工作階段提示、本機路徑與驗證細節不會公開。 已清理的測量資料包含計數、計時、執行環境身分與輸入雜湊，而不是 提示文字。因此完整的私人上下文重放不是可獨立公開重現的工作負載。 若要做新的比較，請使用相同的模型修訂、分詞器／範本、輸入 ID、輸出／停止規則、 取樣、MTP 模式、快取狀態、硬體與序列執行；並分開回報完整工作是否成功。

上游契約：MTPLX 伺服器與模型指南、 oMLX 0.6.4。它們公布的基準使用其他 硬體與工作負載，不能代替此處的測量。