Esta página é uma tradução da documentação em inglês. Comandos, identificadores e exemplos permanecem iguais. Runtime 7.24.4 · SDK 2.6.7. Original em inglês
Configuração e diagnóstico de desempenho
Status: Ativo
Escopo: estado atual
Última revisão: 2026-09-13
Responsável: ax-code runtime
Escolher um perfil de ferramentas
Para sessões de código que não precisam de operações de infraestrutura, agendamento, geração de imagem ou análise especializada,
defina toolProfile como coding para o provedor conectado na configuração do AX Code:
{
"provider": {
"your-provider-id": {
"options": {
"toolProfile": "coding"
}
}
}
}
Substitua your-provider-id pelo ID do provedor conectado. Isso conserva inspeção e edição de arquivos, trabalho de shell e em
segundo plano, delegação, notebooks, metas, skills, memória e verificação de revisão. Ferramentas web e ferramentas opcionais continuam seguindo
as regras existentes de ativação e de permissão. Ferramentas personalizadas e de MCP conservam as regras de admissão e podem aumentar
o tamanho da solicitação.
Use full quando precisar de council ou arena, de operações, de agendamento, de geração de imagem ou de ferramentas de análise especializada. Provedores na
nuvem usam full por padrão; o AX Engine conserva o padrão menor core. coding não muda o esforço de raciocínio,
as permissões, a captura de instantâneo nem os requisitos de verificação. O efeito sobre a velocidade e o sucesso da tarefa depende do modelo
e da carga. Veja Esforço do modelo para controles explícitos de raciocínio.
Separar a preparação local do tempo de resposta do provedor
Ative o perfil local de uma execução:
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
O perfil de saída no stderr inclui session.insertReminders, session.preparePromptRequest, session.preflight,
session.resolveTools e os intervalos de instantâneo track/patch. São medições agregadas; intervalos aninhados ou sobrepostos
não devem ser somados como tempo de parede da tarefa. O próprio perfil acrescenta custo de medição.
Os eventos registrados llm.response ganham um objeto opcional timing:
| Campo | Significado |
|---|---|
boundary |
provider-adapter: observado no adaptador do modelo, antes do tratamento do resultado de ferramenta pelo SDK |
attempt |
Número da tentativa do adaptador dentro desta chamada LLM.stream; os outros campos descrevem esta tentativa |
setupMs |
Tempo da entrada em LLM.stream até este despacho do adaptador; numa nova tentativa, inclui tentativas anteriores e a espera |
firstContentMs |
Do despacho até o primeiro delta não vazio de texto, de raciocínio ou de entrada de ferramenta, ou até a chamada de ferramenta completa |
firstTextMs |
Do despacho até o primeiro delta não vazio de texto; ausente numa resposta só de ferramenta ou só de raciocínio |
streamMs |
Do despacho até o quadro de término do adaptador; ausente quando nenhum quadro de término foi observado |
Quadros de metadados e de início de fluxo não contam como conteúdo. Os tempos usam um relógio monotônico e refletem quando os trechos são
observados, inclusive qualquer contrapressão do fluxo. Não são tempos brutos de rede, tempos de inferência do servidor nem tempos de renderização
da TUI. Adaptadores de CLI podem incluir o trabalho próprio da CLI filha. O latencyMs existente conserva a cronometragem mista mais antiga do passo
e pode incluir execução de ferramenta e trabalho de instantâneo. Os campos novos de tempo contêm apenas durações e a identidade da tentativa.
Sem AX_CODE_PROFILE_NATIVE=1, o objeto adicional de tempo é omitido. O perfil usa diagnóstico local e o
registro de eventos da sessão já existente; não ativa um exportador externo de telemetria.
Para uma comparação útil, mantenha constantes a tarefa, a revisão do repositório, o endpoint do provedor, o modelo exato, o esforço de raciocínio, as permissões de ferramenta e as condições de cache. Registre o tempo até a primeira resposta visível e o tempo até um resultado verificado, inclusive testes e tentativas de reparo. Uma solicitação menor, ou um instantâneo local mais rápido, sozinho, não estabelece que a tarefa na nuvem termine mais cedo.
Use controles do harness e avaliação verificada para experimentar recuperação de contexto, descoberta de MCP, receitas somente leitura e comparações de fixture pareadas, com verificação independente.
Entender o tamanho da solicitação
Eventos novos llm.request em ax-code session replay YOUR_SESSION_ID --mode export incluem requestBytes quando a proveniência da solicitação está disponível:
| Campo | Significado |
|---|---|
encoding |
canonical-json-utf8: comprimento em bytes da representação canônica já existente da impressão digital |
system |
O array de mensagem de sistema montado à parte |
messages |
O array completo de mensagens montadas, inclusive as mensagens de sistema |
toolDefinitions |
Nomes, descrições e esquemas de entrada resolvidos das ferramentas ativas |
system já está representado dentro de messages; não os some. O enquadramento do array está incluído. Valores binários usam a representação de resumo já existente, então estes tamanhos não são tamanhos de carga de rede nem medições de memória residente. Também não são contagens de tokens: o uso de tokens do provedor e os contadores de cache continuam sendo a fonte da contabilidade de entrada do modelo. Um resumo de pacote de contexto cobre uma etapa mais estreita e não é a entrada total do modelo. Eventos legados omitem este campo; proveniência que falhou permanece explicitamente indisponível.
Este diagnóstico registra apenas tamanhos e os hashes e metadados já existentes. Nenhum corpo adicional de prompt nem credencial é salvo. Ele reutiliza a serialização canônica necessária para cada hash, em vez de tokenizar a solicitação. Compare tamanhos em turnos correspondentes ao decidir se instruções de sistema, definições de ferramenta ou um histórico crescente precisam de atenção. O perfil de código acima pode reduzir definições de ferramenta sem mudar o esforço de raciocínio; o perfil completo continua disponível para as capacidades que ele acrescenta.
Evitar exploração redundante
Para localizar um arquivo conhecido ou fazer uma contagem simples, use uma busca focada ou um comando agregado. Resolva caminhos contra o diretório atual do workspace; uma sessão iniciada dentro de um pacote já tem esse pacote como raiz de busca. O grep embutido usa a sintaxe padrão de expressão regular do ripgrep, sem lookaround nem referências anteriores.
Use um investigador para um caminho de chamada. Tarefas paralelas somente leitura devem ter entregas distintas e caminhos ou subsistemas de posse própria, com a evidência já existente fornecida nos resumos. Uma revisão independente pode revisitar a evidência para uma pergunta separada de verificação. Repetir a descoberta em vários contextos novos custa rodadas de modelo mesmo quando o cache de evidência acerta; acertos de cache não contornam a validação do conteúdo atual nem as permissões.
Os servidores de linguagem agora iniciam sob demanda, por padrão. Veja Uso de memória para a opção de pré-aquecimento especulativo e o compromisso com a latência da primeira consulta semântica. Orientação de prompt e testes locais não estabelecem uma redução específica de chamadas ao vivo do modelo nem de RAM física.