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

Configurazione e diagnostica delle prestazioni

Stato: Attivo

Ambito: stato attuale

Ultima revisione: 2026-09-13

Responsabile: runtime di ax-code

Scegliere un profilo di strumenti

Per le sessioni di programmazione che non hanno bisogno di operazioni di infrastruttura, pianificazione, generazione di immagini o analisi specializzata, imposta toolProfile su coding per il provider collegato nella configurazione di AX Code:

{
  "provider": {
    "your-provider-id": {
      "options": {
        "toolProfile": "coding"
      }
    }
  }
}

Sostituisci your-provider-id con l’ID del provider collegato. Questo conserva ispezione e modifica dei file, lavoro di shell e in background, delega, notebook, obiettivi, skill, memoria e verifica di revisione. Gli strumenti web e quelli facoltativi seguono comunque le regole esistenti di attivazione e di autorizzazione. Gli strumenti personalizzati e MCP conservano le regole di ammissione esistenti e possono aumentare la dimensione della richiesta.

Usa full quando ti servono council/arena, operazioni, pianificazione, generazione di immagini o strumenti di analisi specializzata. I provider cloud usano per impostazione predefinita full; AX Engine conserva il predefinito più piccolo core. coding non cambia lo sforzo di ragionamento, le autorizzazioni, la cattura delle istantanee o i requisiti di verifica. Il suo effetto su velocità e successo del compito dipende dal modello e dal carico. Vedi Sforzo del modello per i controlli espliciti di ragionamento.

Separare la preparazione locale dal tempo di risposta del provider

Attiva la profilazione locale per un’esecuzione:

AX_CODE_PROFILE_NATIVE=1 ax-code run --model your-provider-id/your-model "Your task"
ax-code session replay YOUR_SESSION_ID --mode export

Il profilo di uscita su stderr include gli intervalli session.insertReminders, session.preparePromptRequest, session.preflight, session.resolveTools e di istantanea track/patch. Sono misure aggregate; gli intervalli annidati o sovrapposti non vanno sommati come tempo di orologio del compito. La profilazione stessa aggiunge un costo di misura.

Gli eventi llm.response registrati guadagnano un oggetto facoltativo timing:

Campo Significato
boundary provider-adapter: osservato nell’adattatore del modello, prima della gestione dei risultati degli strumenti da parte dell’SDK
attempt Numero del tentativo dell’adattatore dentro questa chiamata LLM.stream; gli altri campi descrivono questo tentativo
setupMs Tempo dall’ingresso in LLM.stream fino a questo invio dell’adattatore; in caso di tentativo include i tentativi precedenti e il backoff
firstContentMs Dall’invio al primo delta non vuoto di testo, ragionamento o input di strumento, oppure alla chiamata di strumento completa
firstTextMs Dall’invio al primo delta di testo non vuoto; assente per una risposta solo di strumento o solo di ragionamento
streamMs Dall’invio al frame di fine dell’adattatore; assente quando non è stato osservato alcun frame di fine

I frame di metadati e di inizio flusso non contano come contenuto. I tempi usano un orologio monotonico e riflettono quando i blocchi vengono osservati, inclusa l’eventuale contropressione del flusso. Non sono tempi di rete grezzi, tempi di inferenza del server né tempi di rendering della TUI. Gli adattatori CLI possono includere il lavoro proprio della CLI figlia. Il latencyMs esistente conserva la sua vecchia misura mista del passo e può includere l’esecuzione degli strumenti e il lavoro di istantanea. I nuovi campi di tempo contengono solo durate e identità del tentativo.

Senza AX_CODE_PROFILE_NATIVE=1, l’oggetto di tempo aggiuntivo viene omesso. La profilazione usa diagnostica locale e il registro eventi di sessione esistente; non attiva un esportatore di telemetria esterno.

Per un confronto utile, tieni costanti il compito, la revisione del repository, l’endpoint del provider, il modello esatto, lo sforzo di ragionamento, le autorizzazioni degli strumenti e le condizioni di cache. Registra il tempo della prima risposta visibile e il tempo fino a un risultato verificato, inclusi test e tentativi di riparazione. Una richiesta più piccola o un’istantanea locale più veloce, da sole, non dimostrano un completamento più rapido del compito cloud.

Usa controlli del harness e valutazione verificata per provare il recupero del contesto, la scoperta MCP, le ricette di sola lettura e i confronti su fixture abbinate, con verifica indipendente.

Capire la dimensione della richiesta

I nuovi eventi llm.request in ax-code session replay YOUR_SESSION_ID --mode export includono requestBytes quando la provenienza della richiesta è disponibile:

Campo Significato
encoding canonical-json-utf8: lunghezza in byte della rappresentazione canonica di impronta esistente
system L’array dei messaggi di sistema assemblato separatamente
messages L’array completo dei messaggi assemblati, inclusi i messaggi di sistema
toolDefinitions Nomi degli strumenti attivi, descrizioni e schemi di input risolti

system è già rappresentato dentro messages; non sommarli. La cornice degli array è inclusa. I valori binari usano la rappresentazione di digest esistente, quindi queste dimensioni non sono né dimensioni del payload di rete né misure di memoria residente. Non sono conteggi di token: l’uso di token del provider e i contatori di cache restano la fonte per la contabilità dell’input del modello. Un riepilogo del pacchetto di contesto copre una fase più stretta e non è l’input totale del modello. Gli eventi legacy omettono questo campo; una provenienza fallita resta esplicitamente non disponibile.

Questa diagnostica registra solo dimensioni e gli hash e i metadati esistenti. Non vengono salvati altri corpi di prompt né credenziali. Riutilizza la serializzazione canonica necessaria per ogni hash, invece di tokenizzare la richiesta. Confronta le dimensioni a turni corrispondenti quando decidi se istruzioni di sistema, definizioni di strumenti o una cronologia in crescita richiedono attenzione. Il profilo di programmazione sopra può ridurre le definizioni degli strumenti senza cambiare lo sforzo di ragionamento; full resta disponibile per le capacità che aggiunge.

Evitare l'esplorazione ridondante

Per una ricerca di un file noto o un conteggio semplice, usa una ricerca mirata o un solo comando aggregato. Risolvi i percorsi rispetto alla directory del workspace corrente; una sessione avviata dentro un pacchetto ha già quel pacchetto come radice di ricerca. Il grep integrato usa la sintassi di espressioni regolari predefinita di ripgrep, senza lookaround né backreference.

Usa un solo investigatore per un solo percorso di chiamata. I compiti paralleli di sola lettura devono avere risultati distinti e percorsi o sottosistemi di proprietà, con l’evidenza esistente fornita nei loro brief. Una revisione indipendente può rivisitare l’evidenza per una domanda di verifica separata. Ripetere la scoperta in più contesti nuovi costa turni di modello anche quando la cache dell’evidenza colpisce; i colpi di cache non aggirano la validazione del contenuto corrente né le autorizzazioni.

I language server ora partono su richiesta per impostazione predefinita. Vedi Uso della memoria per l’adesione al preriscaldamento speculativo e il compromesso con la latenza della prima interrogazione semantica. La guida dei prompt e i test locali non dimostrano una particolare riduzione delle chiamate vive al modello o della RAM fisica.