Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.5 · SDK 2.6.9. Testo inglese

Misure di inferenza locale: 19 settembre 2026

Stato: Attivo

Ambito: istantanea diagnostica misurata

Ultima revisione: 2026-09-19

Responsabile: runtime di ax-code

Per la matrice completa di sei combinazioni di client dopo la correzione del prefisso locale, vedi il nuovo ritest AX Code/OpenCode. Le velocità dei client sotto restano osservazioni storiche nelle loro condizioni originali.

Queste misure indagano la latenza di risposta locale e la velocità di decodifica su un Apple M3 Max con 128 GiB di memoria unificata. Non sono una qualificazione hardware, una valutazione della qualità del modello, né una promessa di 30–40 token/s a lunghezze di contesto arbitrarie. Le istruzioni di collegamento di MTPLX e oMLX sono nella guida del runtime locale.

Condizioni e tempi

• Sorgenti di AX Code basate su v7.19.3; OpenCode 1.18.31; AX Engine 7.4.0; MTPLX 2.11.3; oMLX 0.6.4 (1d7826185c5b5b69b38b27cbe57d7597b7551fd7, installazione isolata dai sorgenti).
• Un backend di inferenza alla volta. Controllo delle ventole predefinito; nessuna pretesa di ventola al massimo. I file dei modelli risiedevano su storage SMB. L’esecuzione ad artefatto esatto di MTPLX ha preparato solo il sidecar MTP su SSD, con SHA-256 verificato.
• I replay ad artefatto esatto hanno usato AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, revisione 4d36d652c21590f6813495351c3baf5fca5b3831. Le esecuzioni separate del client MTPLX Optimized-Speed hanno usato Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. Sono pacchetti di modello diversi, anche se le dimensioni totali dei file sono simili; le loro velocità non possono isolare un’accelerazione dovuta solo al runtime.
• Impostazioni di replay comuni: temperatura 0.55, top-p 1, top-k 0, seed 0, fino a 256 token generati. AX Engine e MTPLX hanno usato MTP attivo di profondità 3. I kernel di runtime e i campionatori speculativi differiscono. I metadati dell’artefatto dichiarano profondità 1; la profondità 3 qui è un esperimento esplicito di runtime, non un’ estensione della certificazione dell’artefatto né una nuova raccomandazione predefinita. AX Engine ha ignorato EOS per il suo replay nativo a output fisso; MTPLX e oMLX seguono le proprie regole di stop.
• La velocità di decodifica nativa usa i contatori di decodifica del backend. La velocità consegnata è (reported completion tokens - 1) / (last output payload time - first output payload time); gli eventi vuoti e i keepalive non contano come output. Questi confini non sono identici.
• La latenza del primo payload include la preparazione della richiesta sul server, il ripristino o il prefill della cache e qualsiasi buffer prima dell’output. I token totali divisi per l’intera richiesta sono una misura di throughput diversa. Le raffiche di chiamate di strumenti non sono adatte alle stime di decodifica dal primo all’ultimo payload.

Per esempio, lo stesso replay MTPLX con input da 30k ha misurato 13.99 token/s di decodifica nativa ma solo 1.13 token/s sull’intera richiesta, perché il prefill a freddo ha consumato circa 209 secondi. Un numero basso sull’intera richiesta, da solo, non dimostra un fallimento del motore di decodifica.

Replay ad pesi esatti di AX Engine e MTPLX

Ogni coppia ha ricevuto la stessa sequenza intera di token di input e ha emesso 256 token. I valori sotto sono osservazioni singole; le identità dei token generati possono differire nonostante un seed comune.

MTPLX ha usato il profilo Sustained per questo artefatto. La richiesta da 30k di AX Engine era calda mentre MTPLX era freddo, quindi i loro tempi del primo token non possono stabilire un rapporto di velocità di prefill. L’input da 30k include un’ istruzione storica di limite di passi e produce prosa diagnostica; non è l’accettazione di un compito di programmazione. Il replay MTPLX da 18,643 token ha riportato stop dopo 256 token, anziché length.

Il prompt breve mostra velocità di decodifica simili. Queste esecuzioni non dimostrano che uno dei due backend sia universalmente più veloce, né che passare AX Code a un altro backend garantisca un’accelerazione fissa.

AX Code e OpenCode su MTPLX Optimized-Speed

Entrambi i client hanno ricevuto lo stesso compito utente, le istruzioni complete del progetto e quattro schemi di strumenti consentiti. Il compito chiedeva una cache LRU in TypeScript senza eseguire strumenti. I prompt specifici del client sono stati conservati; un proxy di registrazione ha allineato il campionamento, disattivato il pensiero e usato un tetto di richiesta e server di 1024 token. Le risposte seguenti si sono completate normalmente:

Queste misure precedono la correzione del prefisso locale di AX Code (42908b46a). AX Code ha inviato più contesto e ha prodotto codice diverso. Non è un confronto di overhead del client a token uguali, né un risultato prima/dopo. Rimuovere solo la mappa di directory scandita in automatico, in un replay separato, ha ridotto l’input a 30,717 ma ha migliorato la decodifica osservata solo di circa il 2%; la rimozione della mappa di directory non è stata adottata.

Una matrice separata dell’adattatore di AX Engine ha osservato AX Code a 9.44–11.56 t/s consegnati con 33,225 token di input e OpenCode a 12.82–13.00 con 17,290. Lunghezze dei prompt, contenuto dell’output, stato della cache e il tetto di output di 256 token differiscono dalla tabella delle risposte complete sopra; non combinare questi dati in un unico rapporto di accelerazione del backend.

oMLX

Il test oMLX usa l’artefatto AXQ esatto e un’installazione isolata con MLX 0.32.0. Tutti e cinque i controlli di import dei kernel nativi, inclusi qwen35_prefill e decode_fast, sono stati superati. Il caricamento solo testo è selezionato in modo esplicito, la finestra di contesto è 65,536 e la concorrenza è uno.

Il tentativo iniziale di Lightning MTP ha restituito HTTP 409 perché il test ha saltato il passo obbligatorio di oMLX Import MTP side-car. È stato un errore di configurazione, non un supporto AXQuant mancante. AXQuant forniva già il contratto canonico qwen3-next-mtp; la revisione Hub attuale b0784088d4026ca569c5653e6e6243c501ef5fa9 include anche l’elenco axquant_omlx_compat.json di 15 tensori MTP. L’istantanea di replay originale precede quell’annotazione.

La linea di base con MTP spento si è completata con l’artefatto originale:

Questi sono risultati con MTP spento e non vanno confrontati con i runtime a MTP acceso come evidenza di una differenza di velocità intrinseca del backend. I viaggi di andata e ritorno del tokenizer e i conteggi di prompt del server hanno corrisposto agli input interi usati dagli altri backend di replay.

L’esecuzione MTP corretta usa l’importatore proprio di oMLX su una copia scrivibile separata. Gli shard della dorsale sono invariati. L’importatore aggiunge language_model. ai 15 nomi di tensori del sidecar; dtype, forma e hash del payload di ogni tensore sono stati verificati uguali prima e dopo l’import. L’hash del file importato quindi differisce perché l’intestazione è cambiata. I metadati originali e l’istantanea condivisa del modello restano intatti. La profondità MTP 3 è selezionata in modo esplicito, e i contatori di bozza e accettazione per profondità confermano l’esecuzione reale.

Il risultato breve conferma che questo pacchetto AXQuant funziona con oMLX Lightning MTP dopo l’import. La decodifica a contesto lungo resta più lenta nonostante l’MTP attivo. Testo generato diverso, versioni di runtime, kernel e policy speculative impediscono di attribuire tutte le differenze tra runtime ad AX Code.

Accettazione del flusso di programmazione ed esclusioni

Dopo la correzione del prefisso locale, AX Code ha completato un compito isolato di sola lettura sia su AX Engine sia su MTPLX: leggere una directory e due file TypeScript, spiegare l’eccezione di coda piena, identificare la capacità 7 e restituire un marcatore disponibile solo nel secondo file. Entrambi sono usciti con successo e hanno preservato i byte del fixture. Le chiamate successive di AX Engine hanno riusato 11,264 token di input; MTPLX ne ha riusati 11,264–12,032. I corpi della prima richiesta erano identici, ma i template di runtime hanno prodotto conteggi di token diversi. Questo verifica il flusso degli strumenti e il riuso di cache osservato, non un’accelerazione fissa dovuta alla patch.

Anche i nuovi ID di provider hanno superato l’accettazione viva dalla CLI dei sorgenti: omlx con il pacchetto AXQ importato e tool_call: true esplicito, e mtplx con il pacchetto Optimized-Speed e nessuna voce di modello configurata. MTPLX ha scoperto il proprio modello di chat e la capacità di strumenti dall’elenco nativo dei modelli. Entrambe le esecuzioni hanno completato due letture di file riuscite e hanno restituito l’eccezione attesa, la capacità e il marcatore solo nel file, senza cambiare i byte del fixture. Il prefisso iniziale di sistema e utente è rimasto identico nelle tre richieste di ogni esecuzione. oMLX ha riusato 8,192 token; MTPLX ne ha riusati 11,829 e 12,047. Sono controlli funzionali, non esecuzioni di prestazioni abbinate; non si afferma alcuna accelerazione di tempo di orologio tra runtime.

Le risposte precedenti di AX Code con tetto di 256 token erano troncate ed sono entrate in recupero; le loro velocità di output ripetuto intorno a 51–58 t/s sono escluse dalle affermazioni di generazione fresca. Sono escluse anche le esecuzioni iniziali con istruzioni di progetto o autorizzazioni degli strumenti non uguali. Ollama e LM Studio sono stati ispezionati solo per la costruzione delle richieste; per loro non si afferma alcun risultato di velocità di generazione.

Il prompt generico da 62 token è pubblico come richiesta di completamento oMLX esatta. Dalla radice del checkout, dopo aver importato il sidecar, attivato MTP e riscaldato il modello, si può inviare con:

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

Cambia l’ID di modello della richiesta nell’ID esposto dal tuo server. Il file include il template reso; usa l’endpoint di completions così un template di chat non viene applicato una seconda volta. Conferma 62 token di prompt e conserva l’evento finale di utilizzo. Il caricamento a freddo del modello e il riscaldamento vanno riportati separatamente.

Istruzioni di progetto private, prompt di sessione, percorsi locali e dettagli di autenticazione non sono pubblicati. I dati di misura ripuliti contengono conteggi, tempi, identità di runtime e hash di input, anziché testo dei prompt. Il replay completo a contesto privato non è quindi un carico riproducibile in pubblico da solo. Per un confronto nuovo, usa la stessa revisione del modello, tokenizer e template, ID di input, regole di output e di stop, campionamento, modalità MTP, stato della cache, hardware ed esecuzione seriale; riporta separatamente il successo del compito completo.

Contratti a monte: guida al server e ai modelli di MTPLX, oMLX 0.6.4. I loro benchmark pubblicati usano altro hardware e altri carichi, e non sostituiscono le misure qui.