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

Riesecuzione dei client AX Code e OpenCode: 19 September 2026

Stato: attivo Ambito: istantanea diagnostica misurata Ultima revisione: 2026-09-19 Responsabile: runtime di ax-code

Questa riesecuzione usa il sorgente di AX Code 62895cf40a39e0ebd4afec0afa21044e9871aa0b, dopo la correzione locale del prefisso (42908b46a) e l’aggiunta dei provider MTPLX/oMLX. Tutte e sei le combinazioni di client e backend usano lo stesso artefatto Qwen3.8 27B AXQ 6-bit con MTP attivo su un Apple M3 Max, 128 GiB. Le misure precedenti restano evidenza storica; i pacchetti di modello, i prompt, i limiti di token e le condizioni di cache di quelle misure sono diversi. Non è una stima controllata, prima e dopo, dell’accelerazione dovuta alla correzione del prefisso.

Velocità dell'output consegnato

Ogni cella riporta primo compito / compito ripetuto, in token/s. Sono osservazioni singole, non mediane. Il compito ripetuto avvia una nuova sessione CLI verso lo stesso processo di backend; non si assume che incontri una cache. Il caricamento e l’attesa del primo output sono esclusi da questo tasso.

La stima è (completion tokens - 1) / (last output payload time - first output payload time). La decodifica speculativa può emettere più token in un solo payload, quindi questa è una stima di consegna lato client, non il contatore nativo di decode del backend. Non misura nemmeno il throughput dell’intera richiesta.

Tempi delle richieste, carico e accettazione

NR significa che il server non ha riportato l’uso dei token in cache; non afferma che il valore sia zero. Il tempo del primo payload inizia quando il proxy locale di registrazione riceve la richiesta al modello. Il tempo di parete della CLI include anche l’avvio e il completamento del client. Il compito chiede una cache LRU generica e autonoma in TypeScript con get, set, delete e clear, senza esecuzione di strumenti né modifiche ai file.

I controlli di accettazione del codice verificano chiavi assenti, ricerca dei valori, sfratto LRU, voci conservate, aggiornamento della recenza, cancellazione di chiavi esistenti e assenti, svuotamento, identità delle chiavi oggetto e valori falsy. I file generati ricevono anche un controllo TypeScript rigoroso. Questi controlli delimitati non stabiliscono una qualità di programmazione ampia. Tutte le righe di misura conservano l’output generato e il risultato di validazione; i fallimenti non vengono sostituiti in silenzio con tentativi più veloci.

Condizioni di MTP e del runtime

• AX Engine 7.4.0: --mlx-mtp-policy required, flag del runtime locale gestito, accelerazione n-gram e impilamento n-gram disattivati. Le metriche del processo in esecuzione mostrano ax_engine_mlx_mtp_model_policy_active=1 con contatori di token di bozza e di token accettati diversi da zero. L’istantanea di AX Code segue il riscaldamento; l’istantanea di OpenCode segue il primo compito. Entrambe includono il riscaldamento e non sono totali di accettazione per singolo compito. I conteggi di bozza di AX Code per compito non sono stati conservati.
• MTPLX 2.11.3 / MLX 0.32.2: --generation-mode mtp --depth 3 esplicito; lo stato di salute in esecuzione riporta generation_mode: mtp e runtime_mode: Sustained MTP. Le riscritture dell’agente e la cache di sessione su SSD sono spente; la banca di sessione nativa in memoria resta abilitata. I riscaldamenti nativi di avvio e del kernel sono conservati ed esclusi dai tempi. Il riscaldamento di carico non correlato è terminato; lo stato del riscaldamento in background al momento dell’ammissione è conservato nei dati, senza presumere che fosse completo.
• oMLX 0.6.4 / MLX 0.32.0: Lightning MTP attivo, profondità 3, caricamento del modello solo testo, concorrenza uno. I log di ogni generazione registrano l’accettazione delle bozze e l’esecuzione per profondità, per il riscaldamento e per entrambi i compiti. L’importatore del sidecar a monte rinomina 15 tensori; dtype, forma e byte del payload restano identici al sidecar AXQuant originale. I pesi del backbone sono invariati.
• Artefatto: AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, revisione 4d36d652c21590f6813495351c3baf5fca5b3831. I metadati dell’artefatto dichiarano una profondità MTP pari a 1; la profondità ricorrente 3 di questa riesecuzione segue la policy di runtime selezionata oppure l’esperimento esplicito e non estende la certificazione dell’artefatto. Il pacchetto di modello Optimized-Speed non è usato in questa riesecuzione.
• La versione di OpenCode è 1.18.31. Tutti i backend e i client vengono eseguiti in serie. Ogni coppia client/backend avvia un processo nuovo e una cache di compito isolata, seguiti da un riscaldamento di caricamento del modello non correlato, con tetto di 64 token di output. Il caricamento del modello e quel riscaldamento sono esclusi dalla tabella; il primo compito paga comunque il prefill a freddo. Il controllo delle ventole resta al valore predefinito e i file del backbone risiedono su storage SMB.

Che cosa è allineato e che cosa resta diverso

Entrambi i client ricevono le stesse istruzioni di progetto complete e congelate, lo stesso compito dell’utente e quattro strumenti consentiti (glob, grep, read, skill). La CLI sorgente di AX Code usa gli id provider reali ax-engine, mtplx e omlx; AX Engine usa il proprio contratto verificato di collegamento in loopback, con un backend avviato a parte che porta i flag gestiti. Questa misura non cronometra l’interfaccia gestita di download e di avvio. OpenCode usa il proprio percorso di provider compatibile con OpenAI. La configurazione di progetto è disabilitata e ogni client ha impostazioni e stato isolati. I prompt nativi del client, gli schemi degli strumenti e le intestazioni di sessione restano intatti; di conseguenza i conteggi dei token renderizzati e il comportamento della cache differiscono.

Un proxy locale di registrazione allinea la temperatura a 0.55, top-p a 1, top-k e min-p a 0, la penalità di ripetizione a 1, le penalità di presence e di frequency a 0, il seed a 0, il thinking disattivato e un tetto di output di 1,024 token. Forza tool_choice: none per questo compito senza strumenti. Entrambi i client sono configurati per un contesto di 65,536 token. Ogni riga è controllata rispetto all’istantanea completa delle istruzioni, ai quattro nomi di strumento, al campionamento comune, a una sola richiesta, all’uscita riuscita della CLI, allo stop naturale e all’assenza di esecuzione di strumenti.

I prompt più lunghi di AX Code possono aumentare sia il prefill sia il lavoro di attention durante la generazione. Lunghezze di risposta, contenuti, template di runtime, kernel e policy di cache diversi impediscono di trattare queste tabelle come un benchmark di overhead del client a parità di token. MTP attivo non garantisce 30–40 token/s per un contesto di programmazione completo. Per isolare l’overhead del client o l’effetto della correzione del prefisso, riesegui a parte richieste serializzate e id di token identici, con output e condizioni di cache sotto controllo.

Questo rapporto non modifica alcun comportamento di cloud, GPU privata, provider della CLI o AX Trust. Vedi la guida alla configurazione del runtime locale per le istruzioni di connessione e i dati di misura ripuliti per i tempi esatti, i conteggi, gli hash, i risultati di validazione e l’evidenza MTP. Le istruzioni private di progetto, le risposte del modello, i percorsi locali e le intestazioni di sessione restano in locale e non sono pubblicati. Di conseguenza il carico completo con contesto privato non è riproducibile in modo indipendente a partire dal solo rapporto pubblico.