Halaman ini diterjemahkan dari dokumentasi bahasa Inggris. Perintah, pengenal, dan contoh tidak diubah. Runtime 7.24.5 · SDK 2.6.9. Sumber bahasa Inggris

Pengukuran inferensi lokal: 19 September 2026

Status: Aktif

Cakupan: cuplikan diagnostik yang diukur

Terakhir ditinjau: 2026-09-19

Pemilik: ax-code runtime

Untuk matriks klien enam kombinasi yang lengkap setelah perbaikan prefiks lokal, lihat uji ulang AX Code/OpenCode yang baru. Kecepatan klien di bawah tetap pengamatan historis pada kondisi aslinya.

Pengukuran ini meneliti latensi respons lokal dan kecepatan decode pada satu Apple M3 Max dengan memori terpadu 128 GiB. Ini bukan kualifikasi perangkat keras, evaluasi kualitas model, atau janji 30–40 token/s pada panjang konteks sembarang. Instruksi koneksi MTPLX dan oMLX ada di panduan runtime lokal.

Kondisi dan waktu

• Sumber AX Code berbasis v7.19.3; OpenCode 1.18.31; AX Engine 7.4.0; MTPLX 2.11.3; oMLX 0.6.4 (1d7826185c5b5b69b38b27cbe57d7597b7551fd7, pemasangan sumber yang terisolasi).
• Satu backend inferensi pada satu waktu. Kontrol kipas bawaan; tidak ada klaim kipas maksimum. Berkas model berada di penyimpanan SMB. Eksekusi artefak persis MTPLX hanya menaruh sidecar MTP di SSD, dengan SHA-256 yang diverifikasi.
• Pemutaran ulang artefak persis memakai AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, revisi 4d36d652c21590f6813495351c3baf5fca5b3831. Eksekusi klien MTPLX Optimized-Speed yang terpisah memakai Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. Itu paket model yang berbeda, meskipun ukuran berkas totalnya mirip; lajunya tidak dapat mengisolasi percepatan yang hanya berasal dari runtime.
• Pengaturan pemutaran ulang yang sama: temperature 0.55, top-p 1, top-k 0, seed 0, hingga 256 token yang dihasilkan. AX Engine dan MTPLX memakai kedalaman MTP aktif 3. Kernel runtime dan sampler spekulatif berbeda. Metadata artefak menyatakan kedalaman 1; kedalaman 3 di sini adalah eksperimen runtime yang eksplisit, bukan perluasan sertifikasi artefak atau rekomendasi bawaan yang baru. AX Engine mengabaikan EOS untuk pemutaran ulang native dengan keluaran tetap; MTPLX dan oMLX mengikuti aturan berhenti mereka sendiri.
• Laju decode native memakai penghitung decode backend. Laju yang terkirim adalah (reported completion tokens - 1) / (last output payload time - first output payload time); peristiwa kosong dan keepalive tidak dihitung sebagai keluaran. Batas ini tidak identik.
• Latensi muatan pertama mencakup persiapan permintaan di server, pemulihan cache atau prefill, dan penyanggaan apa pun sebelum keluaran. Total token dibagi seluruh permintaan adalah ukuran throughput yang berbeda. Semburan panggilan alat tidak cocok untuk perkiraan decode dari muatan pertama sampai terakhir.

Misalnya, pemutaran ulang masukan 30k MTPLX yang sama mengukur 13.99 token/s decode native tetapi hanya 1.13 token/s sepanjang permintaan utuh, karena prefill dingin menghabiskan sekitar 209 detik. Angka permintaan utuh yang rendah sendiri tidak menetapkan kegagalan mesin decode.

Pemutaran ulang bobot persis AX Engine dan MTPLX

Setiap pasangan menerima urutan token masukan bilangan bulat yang sama dan mengeluarkan 256 token. Nilai di bawah adalah pengamatan tunggal; identitas token yang dihasilkan dapat berbeda meskipun seed sama.

MTPLX memakai profil Sustained untuk artefak ini. Permintaan 30k AX Engine sudah hangat sementara MTPLX dingin, jadi waktu token pertama mereka tidak dapat menetapkan rasio kecepatan prefill. Masukan 30k mencakup instruksi batas langkah historis dan menghasilkan prosa diagnostik; ini bukan penerimaan tugas pengodean. Pemutaran ulang MTPLX 18,643 token melaporkan stop setelah 256 token, bukan length.

Prompt pendek menunjukkan laju decode yang mirip. Eksekusi ini tidak menunjukkan bahwa salah satu backend secara universal lebih cepat, atau bahwa mengganti AX Code ke backend lain menjamin percepatan tetap.

AX Code dan OpenCode pada MTPLX Optimized-Speed

Kedua klien menerima tugas pengguna yang sama, instruksi proyek penuh, dan empat skema alat yang diizinkan. Tugas meminta cache LRU TypeScript tanpa mengeksekusi alat. Prompt khusus klien dipertahankan; proksi perekam menyelaraskan sampling, menonaktifkan penalaran, dan memakai langit-langit permintaan/server 1024 token. Respons berikut selesai secara normal:

Pengukuran ini mendahului perbaikan prefiks lokal AX Code (42908b46a). AX Code mengirim lebih banyak konteks dan menghasilkan kode yang berbeda. Ini bukan perbandingan overhead klien dengan token setara atau hasil sebelum/sesudah. Menghapus hanya peta direktori yang dipindai otomatis pada pemutaran ulang terpisah mengurangi masukan menjadi 30,717 tetapi hanya meningkatkan decode yang diamati sekitar 2%; penghapusan peta direktori tidak diadopsi.

Matriks adaptor AX Engine yang terpisah mengamati AX Code pada 9.44–11.56 t/s terkirim dengan 33,225 token masukan dan OpenCode pada 12.82–13.00 dengan 17,290. Panjang prompt, isi keluaran, keadaan cache, dan langit-langit keluaran 256 token berbeda dari tabel respons lengkap di atas; jangan menggabungkan ini menjadi satu rasio percepatan backend.

oMLX

Uji oMLX memakai artefak AXQ yang persis dan pemasangan terisolasi dengan MLX 0.32.0. Kelima pemeriksaan impor kernel native, termasuk qwen35_prefill dan decode_fast, lulus. Pemuatan hanya-teks dipilih secara eksplisit, jendela konteks 65,536, dan konkurensi satu.

Percobaan Lightning MTP awal mengembalikan HTTP 409 karena uji melewatkan langkah wajib oMLX Import MTP side-car. Ini kesalahan penyiapan, bukan dukungan AXQuant yang hilang. AXQuant sudah menyediakan kontrak kanonik qwen3-next-mtp; revisi Hub saat ini b0784088d4026ca569c5653e6e6243c501ef5fa9 juga mencakup daftar axquant_omlx_compat.json 15 tensor MTP. Cuplikan pemutaran ulang asli mendahului anotasi itu.

Garis dasar dengan MTP mati selesai dengan artefak asli:

Ini hasil MTP mati dan tidak boleh dibandingkan dengan runtime MTP nyala sebagai bukti perbedaan kecepatan backend yang melekat. Perjalanan pulang-pergi tokenizer dan jumlah prompt server cocok dengan masukan bilangan bulat yang dipakai backend pemutaran ulang lain.

Eksekusi MTP yang diperbaiki memakai pengimpor milik oMLX pada salinan terpisah yang dapat ditulis. Pecahan tulang punggung tidak berubah. Pengimpor menambahkan language_model. ke 15 nama tensor sidecar; dtype, bentuk, dan hash muatan setiap tensor diverifikasi sama sebelum dan sesudah impor. Hash berkas yang diimpor karenanya berbeda karena headernya berubah. Metadata asli dan cuplikan model bersama tetap utuh. Kedalaman MTP 3 dipilih secara eksplisit, dan penghitung draf/terima per kedalaman mengonfirmasi eksekusi sungguhan.

Hasil pendek mengonfirmasi bahwa paket AXQuant ini bekerja dengan oMLX Lightning MTP setelah impor. Decode konteks panjang tetap lebih lambat meskipun MTP aktif. Teks yang dihasilkan berbeda, versi runtime, kernel, dan kebijakan spekulatif mencegah mengatribusikan semua perbedaan lintas runtime ke AX Code.

Penerimaan alur pengodean dan pengecualian

Setelah perbaikan prefiks lokal, AX Code menyelesaikan tugas hanya-baca yang terisolasi pada AX Engine dan MTPLX: membaca direktori dan dua berkas TypeScript, menjelaskan pengecualian antrean penuh, mengidentifikasi kapasitas 7, dan mengembalikan penanda yang hanya ada di berkas kedua. Keduanya keluar dengan sukses dan mempertahankan byte fixture. Panggilan AX Engine berikutnya memakai ulang 11,264 token masukan; MTPLX memakai ulang 11,264–12,032. Isi permintaan pertama identik, tetapi templat runtime menghasilkan jumlah token yang berbeda. Ini memverifikasi alur alat dan pemakaian ulang cache yang diamati, bukan percepatan tetap dari patch.

ID penyedia baru juga lulus penerimaan langsung dari CLI sumber: omlx dengan paket AXQ yang diimpor dan tool_call: true yang eksplisit, serta mtplx dengan paket Optimized-Speed dan tanpa entri model yang dikonfigurasi. MTPLX menemukan model chat dan kapabilitas alat dari daftar model native. Kedua eksekusi menyelesaikan dua pembacaan berkas yang berhasil dan mengembalikan pengecualian, kapasitas, serta penanda hanya-berkas yang diharapkan tanpa mengubah byte fixture. Prefiks sistem/pengguna awal tetap identik pada tiga permintaan setiap eksekusi. oMLX memakai ulang 8,192 token; MTPLX memakai ulang 11,829 dan 12,047 token. Ini pemeriksaan fungsional, bukan eksekusi kinerja yang disetarakan; tidak ada klaim percepatan waktu dinding lintas runtime.

Respons AX Code sebelumnya yang dibatasi 256 token terpotong dan masuk pemulihan; laju keluaran berulang sekitar 51–58 t/s dikecualikan dari klaim generasi baru. Eksekusi awal dengan instruksi proyek atau izin alat yang tidak setara juga dikecualikan. Ollama dan LM Studio hanya diperiksa untuk konstruksi permintaan; tidak ada hasil laju generasi yang diklaim untuk mereka.

Prompt generik 62 token dipublikasikan sebagai permintaan penyelesaian oMLX yang persis. Dari akar checkout, setelah mengimpor sidecar, mengaktifkan MTP, dan memanaskan model, ia dapat dikirim dengan:

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

Ubah ID model permintaan ke ID yang diekspos server Anda. Berkas itu mencakup templat yang sudah dirender; pakai titik akhir completions agar templat chat tidak diterapkan kedua kali. Konfirmasi 62 token prompt dan simpan peristiwa pemakaian akhir. Pemuatan model dingin dan pemanasan harus dilaporkan secara terpisah.

Instruksi proyek privat, prompt sesi, jalur lokal, dan rincian autentikasi tidak dipublikasikan. Data pengukuran yang disanitasi berisi jumlah, waktu, identitas runtime, dan hash masukan, bukan teks prompt. Pemutaran ulang konteks privat yang penuh karenanya bukan beban kerja yang dapat direproduksi secara publik dan mandiri. Untuk perbandingan baru, gunakan revisi model, tokenizer/templat, ID masukan, aturan keluaran/berhenti, sampling, mode MTP, keadaan cache, perangkat keras, dan eksekusi serial yang sama; laporkan keberhasilan tugas lengkap secara terpisah.

Kontrak hulu: panduan server dan model MTPLX, oMLX 0.6.4. Tolok ukur yang mereka publikasikan memakai perangkat keras dan beban kerja lain dan tidak menggantikan pengukuran di sini.