Scarica AX Code · GratuitoDocumentazione

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

Selezione del modello di AX Engine

Stato: attivo Ambito: stato attuale Ultima revisione: 2026-09-20 Responsabile: runtime di ax-code

AX Code offre solo questi due pacchetti di sviluppo tramite AX Engine (Local) sui Mac Apple Silicon idonei. Tiel Coder è il predefinito; Cyber-Tiel Coder è l’alternativa.

Modello Repository Hugging Face Selezione in AX Code
Tiel Coder 35B A3B MXFP4 MTP AutomatosX/AX-Tiel-Coder-35B-A3B-MLX-AXQ-MXFP4-MTP tiel-coder-35b-axq-mxfp4 (predefinito)
Cyber-Tiel Coder 35B A3B MXFP4 MTP AutomatosX/AX-Cyber-Tiel-Coder-35B-A3B-MLX-AXQ-MXFP4-MTP cyber-tiel-coder-35b-axq-mxfp4

Gli alias fissano rispettivamente le revisioni 5ab39b24bfd7f65203be9b7823b1840486f58b6d e fe05e871ec69ad9ae8eac01fd285555514ac7daf. Entrambi usano il selettore mlx, conservando il pacchetto MXFP4 dell’editore. Le schede dei modelli descrivono riquantizzazioni di sviluppo senza una certificazione di parità di qualità o una dichiarazione di velocità MTP; selezionarli non stabilisce l’esecuzione nativa né un miglioramento di velocità.

AX Code include la release firmata di AX Engine 7.5.7, che comprende la correzione del loader dello spazio dei nomi sidecar di Tiel dal commit 51137c71a6794964d52c32c95e275c0923ed8d0b. I binari Homebrew 7.4.0 più vecchi non hanno quella correzione e rifiutano questi pacchetti con MlxMtpRequiredButUnavailable. Mantieni MTP come richiesto; anche gli override espliciti del runtime devono contenere la correzione. Le misure native di prefill e decode conservano l’identità della build testata in origine e non certificano le prestazioni della release più recente.

Qwen3.8 27B, Ornith, Qwen3-Coder-Next e tutti gli altri repository sono esclusi dalla nuova selezione gestita e dai download. Ogni repository selezionato compare una sola volta. Gli alias configurati e le revisioni più vecchie in cache non aggiungono scelte dopo la scoperta. Gli altri provider e l’interfaccia di collegamento loopback configurata separatamente conservano il proprio comportamento. Per eseguire il predefinito denso proprio di AX Engine, avvia ax-engine serve qwen3.8-27b:axq e collega quell’endpoint locale; l’MTP misurato sul percorso di prodotto è 31.05 tok/s di decode su Mac mini M4 Pro 64 GB e 76.90 tok/s di decode / 795.3 tok/s di prefill su M5 Max 128 GB. Quelle cifre non sono tok/s di completamento di Tiel e non sono la velocità di sessione di AX Code. Vedi riepilogo tra pari di Tiel.

Ispeziona i modelli disponibili

ax-code providers ax-engine models --json
ax-code providers ax-engine models --refresh --json

L’aggiornamento legge i metadati di Hugging Face senza scaricare i pesi né avviare un modello. I metadati inclusi funzionano offline e integrano il repository selezionato se manca da una cache più vecchia. Le revisioni presenti non vengono sostituite in silenzio con una revisione inclusa diversa. La selezione richiede comunque metadati di sorgente validi; la restrizione del repository non stabilisce la capacità nativa.

GET /provider/ax-engine/models restituisce il catalogo della CLI in esecuzione, incluso l’ID esatto di ogni modello, il repository, la quantizzazione, lo stato locale, le stime di memoria e disco e lo stato di verifica. Una GUI esterna usa questa API di runtime. Se mostra un elenco più vecchio, controlla la CLI che avvia e la sua versione. Lo sviluppo di AX Coder può selezionare un runtime sorgente con AX_CODE_BINARY o settings.axCodeBinary.

Prepara il modello selezionato

Copia l’ID esatto del modello dal catalogo. L’alias Tiel predefinito usa mlx:

ax-code providers ax-engine prepare \
  --model tiel-coder-35b-axq-mxfp4 --quantization mlx --download --start

I modelli esclusi fanno fallire le nuove richieste di preparazione, download e attivazione gestita prima di iniziare il lavoro. I record di modello esistenti restano disponibili per stato e pulizia; gli ID rimossi di Qwen3.8, Ornith e Qwen3-Coder-Next non vengono mai reindirizzati a uno dei due artefatti Tiel. Rimuovere un’opzione non cancella i pesi né arresta un server esistente.

Verifica di memoria e runtime

Entrambi gli alias selezionati usano un contesto di 65,536 token, un limite di output di 8,192 token, un requisito di memoria stimato di 64 GiB e un budget disco di download di 32 GiB. Sono limiti di servizio di AX Code, non il contesto massimo upstream. (Aumentato da un contesto iniziale di 32,768 token: restavano solo 24,576 token di input utilizzabili dopo la riserva di output, meno di quanto richiedono il prompt di sistema fisso dell’agente AX Code e gli schemi degli strumenti, quindi una sessione appena creata non poteva mai inviare un primo turno.)

Ogni stima di memoria include pesi, sidecar, cache KV, buffer e riserva dell’host. Usa il risultato di adattamento del catalogo live per la macchina corrente. Queste stime non sono una certificazione dell’hardware né della qualità del modello.

La cifra di 64 GiB è un budget di pianificazione conservativo a contesto pieno (64K), non un minimo rigido. Per una macchina di inferenza locale gestita comoda, raccomandiamo un Apple Silicon M4 Pro con 48 GB di memoria unificata o più (per esempio un Mac Mini M4 Pro 48 GB); i Mac Apple Silicon più piccoli possono comunque eseguire AX Code stesso da 8 GB con modelli cloud/API o runtime locali più leggeri.

Prima dell’attivazione gestita, AX Code controlla il contratto di testo e di strumenti strutturati del modello AX Engine attivo. Uno stato verification-required significa che la preparazione è completa ma quel contratto live non è stato stabilito. I nomi dei repository o i sidecar MTP da soli non provano ragionamento, visione, accelerazione MTP o qualità di programmazione su più turni.

La compattazione della sessione usa i budget di contesto e output del modello attivo e riserva margine di input. La variante selezionata mantiene il proprio budget di catalogo; il contesto massimo del modello sorgente non è una garanzia di memoria gestita.

Vedi Architettura del motore locale per i dettagli di ciclo di vita e trasporto.

Policy MTP gestita

AX Engine gestito usa per impostazione predefinita required, in linea con l’artefatto MTP selezionato. Un drafter non disponibile fa fallire l’avvio invece di ripiegare in silenzio sulla decodifica diretta. I pesi MTP e l’impostazione di puro stacking non stabiliscono un’accelerazione attiva. Il pacchetto Tiel Coder predefinito usa il profilo di speculazione auto così AX Engine seleziona il gate di bozza del modello invece dell’override 0.80 del profilo generico agentic. Questo è separato dalla policy di attivazione MTP: la messa a punto auto usa ancora MTP required. Il vecchio ambiente sperimentale specifico del denso Qwen3.8 non viene applicato a questi pacchetti MoE. Vedi il confronto dei profili per i guadagni misurati. Cyber-Tiel conserva agentic; le sonde di compiti di lettura gestiti sono fallite con entrambi i profili, quindi l’affidabilità dei suoi compiti resta irrisolta. La policy di attivazione resta required; il motore deve ammettere il drafter effettivo. Per selezionare esplicitamente una policy, imposta provider.ax-engine.options.mtpPolicy in ax-code.json:

{
  "provider": {
    "ax-engine": {
      "options": {
        "mtpPolicy": "required"
      }
    }
  }
}
Policy Comportamento
disabled Usa la decodifica diretta; non richiedere un drafter del modello.
auto Lascia che AX Engine decida se il modello e la route ammettono MTP. Questo non garantisce l’attivazione.
required (predefinito) Richiedi un drafter MTP ammesso; AX Engine rifiuta un drafter non disponibile invece di ripiegare in silenzio.

AX_ENGINE_MTP_POLICY fornisce gli stessi tre valori quando non è impostata un’opzione del provider. La selezione automatica del runtime richiede AX Engine 7.5.7 o successivo per applicare queste policy, inclusa la policy predefinita required. Le impostazioni esplicite disabled e auto scavalcano comunque il predefinito. I binari più vecchi o sconosciuti rifiutano la selezione della policy prima di sostituire un motore in esecuzione; aggiorna prima di usare i controlli della policy gestita. I file di stato storici senza una policy registrata riportano la policy avviata come sconosciuta e vengono sostituiti al successivo avvio gestito. Cambiare policy ha effetto al successivo avvio gestito o alla successiva richiesta di modello e sostituisce un processo esistente con una policy diversa. Non cambia la selezione del modello né l’archiviazione.

ax-code providers ax-engine start --mtp-policy disabled scavalca la policy solo per quell’avvio. Imposta l’opzione persistente del provider se le richieste di programmazione successive devono usare lo stesso override. I corpi HTTP di prepare/start accettano anche mtpPolicy. Queste impostazioni gestite non riconfigurano gli endpoint collegati separatamente. Dopo aver aggiornato il sorgente, riavvia pnpm run dev per caricare il nuovo predefinito; un backend di sviluppo già in esecuzione conserva il codice caricato finché non viene riavviato.

ax-code providers ax-engine status (o --json) separa la policy richiesta, la policy avviata e lo stato osservato active/inactive/unknown. L’osservazione usa la metrica più recente di route del modello del motore, non i metadati del modello né i conteggi storici di bozza. I campioni mancanti del modello esatto restano sconosciuti, anche prima del primo passo osservato del motore; gli aggregati di tutto il server non stabiliscono l’attivazione. Il required configurato non viene mostrato come prova di attività. I conteggi di bozza e accettati, quando disponibili, sono cumulativi per il motore residente. Un cambiamento di policy in attesa viene segnalato senza riavviarlo durante l’ispezione dello stato. L’attivazione MTP non è una promessa di una particolare velocità in token.

Interpretare la velocità di risposta locale

AX Engine gestito non impone un tetto di token al secondo. Una misura come 50 tok/s non è né un obiettivo configurato né un limite superiore: hardware più veloce può produrre token più in fretta. La dimensione del contesto, i budget di output e i limiti di concorrenza delle richieste controllano la capacità, non una velocità fissa di generazione dei token.

L’istantanea pubblica corrente di Tiel rispetto a MTPLX è la campagna di API nativa del 20 September 2026 riassunta in riepilogo tra pari di Tiel. Su M5 Max 128 GiB il pacchetto Tiel predefinito gestito ha completato a 194.88 tok/s incluso TTFT (decode 217.85). Il picco di decode di Cyber-Tiel 249.01 tok/s è il pacchetto alternativo, non il predefinito. Quelle cifre non sono la velocità di sessione di AX Code.

Confronta le misure alla stessa lunghezza di input, allo stesso budget di output, alle stesse impostazioni di campionamento e allo stesso stato di cache. Le misure di decode su prompt brevi non stabiliscono una velocità minima per una sessione di programmazione con decine di migliaia di token di contesto. Riutilizzare un prefisso riduce l’elaborazione del prompt; la decodifica successiva continua a prestare attenzione a quel contesto. L’attivazione MTP da sola non stabilisce un’accettazione utile delle bozze né un’accelerazione fissa.

Separa avvio e preparazione, tempo fino al primo contenuto e generazione sostenuta quando indaghi un turno lento. La metrica ax_runtime_decode_tok_per_sec del motore è una media pesata in modo esponenziale tra le richieste, non la velocità della risposta corrente. Usa i tempi della richiesta e i conteggi di token per quella risposta, e i delta dei contatori per la sua accettazione MTP. I blocchi in streaming possono contenere più token; contare i blocchi come token dà una velocità errata.

AX Code riusa le sonde riuscite della versione dell’eseguibile fino a cinque minuti. Controlla la disponibilità dell’eseguibile a ogni risoluzione e invalida le versioni in cache quando cambia l’identità del file del launcher o del server nativo. Le sonde fallite restano ritentabili. Questo riduce il lavoro di preparazione ripetuto; non cambia la velocità di decode del modello. Un backend di sviluppo deve essere riavviato per caricare le modifiche del sorgente.