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.