Esta página é uma tradução da documentação em inglês. Comandos, identificadores e exemplos permanecem iguais. Runtime 7.24.5 · SDK 2.6.9. Original em inglês

Reteste de clientes AX Code e OpenCode: 19 de setembro de 2026

Status: Ativo Escopo: instantâneo diagnóstico medido Última revisão: 2026-09-19 Responsável: runtime do ax-code

Este reteste usa o código-fonte do AX Code 62895cf40a39e0ebd4afec0afa21044e9871aa0b, depois da correção local de prefixo (42908b46a) e das adições de provedor MTPLX/oMLX. Todas as seis combinações de cliente e backend usam o mesmo artefato Qwen3.8 27B AXQ de 6 bits com MTP ativado em um Apple M3 Max, 128 GiB. As medições anteriores permanecem evidência histórica; os pacotes de modelo, os prompts, os limites de token e as condições de cache diferem. Isto não é uma estimativa controlada de antes e depois da aceleração da correção de prefixo.

Velocidade da saída entregue

Cada célula é primeira tarefa / tarefa repetida, em tokens/s. São observações únicas, não medianas. A tarefa repetida inicia uma nova sessão de CLI contra o mesmo processo de backend; não se assume que ela acerte um cache. A carga e a espera pela primeira saída ficam fora desta taxa.

A estimativa é (completion tokens - 1) / (last output payload time - first output payload time). A decodificação especulativa pode emitir vários tokens em uma carga, então isto é uma estimativa de entrega do cliente, não o contador nativo de decode do backend. Também não mede a vazão do pedido completo.

Tempo de pedido, carga e aceitação

NR significa que o servidor não relatou uso de tokens em cache; não afirma zero. O tempo da primeira carga começa quando o proxy local de gravação recebe o pedido do modelo. O tempo de parede da CLI também inclui a inicialização e a conclusão do cliente. A tarefa pede um cache LRU genérico e independente em TypeScript com get, set, delete e clear, sem execução de ferramenta nem edições de arquivo.

As verificações de aceitação de código cobrem chaves ausentes, busca de valor, despejo LRU, entradas retidas, atualização de recência, exclusão de chaves existentes e ausentes, limpeza, identidade de chave de objeto e valores falsos. Os arquivos gerados também recebem verificação estrita de TypeScript. Estas verificações limitadas não estabelecem qualidade ampla de programação. Todas as linhas de medição retêm a saída gerada e o resultado de validação; falhas não são substituídas em silêncio por novas tentativas mais rápidas.

Condições de MTP e de runtime

• AX Engine 7.4.0: --mlx-mtp-policy required, indicadores do runtime local administrado, aceleração n-gram e empilhamento n-gram desativados. As métricas do processo ao vivo mostram ax_engine_mlx_mtp_model_policy_active=1 com contadores de tokens de rascunho e aceitos diferentes de zero. O instantâneo do AX Code segue o aquecimento; o instantâneo do OpenCode segue a primeira tarefa. Ambos incluem o aquecimento e não são totais de aceitação por tarefa. As contagens de rascunho por tarefa do AX Code não foram retidas.
• MTPLX 2.11.3 / MLX 0.32.2: --generation-mode mtp --depth 3 explícito; a saúde ao vivo relata generation_mode: mtp e runtime_mode: Sustained MTP. Reescritas de agente e o cache de sessão em SSD estão desligados; o banco de sessão nativo em memória permanece ativado. Aquecimentos nativos de inicialização e de kernel são retidos e ficam fora do tempo. O aquecimento de carga não relacionado concluiu; o status do aquecimento em segundo plano na admissão fica retido nos dados, em vez de ser assumido como concluído.
• oMLX 0.6.4 / MLX 0.32.0: Lightning MTP ativado, profundidade 3, carga de modelo somente texto, concorrência um. Os logs por geração registram aceitação de rascunho e execução por profundidade para o aquecimento e as duas tarefas. O importador de sidecar a montante renomeia 15 tensores; o dtype, a forma e os bytes de carga permanecem idênticos ao sidecar AXQuant original. Os pesos do backbone permanecem sem alteração.
• Artefato: AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, revisão 4d36d652c21590f6813495351c3baf5fca5b3831. Os metadados do artefato declaram profundidade MTP 1; a profundidade recorrente 3 aqui segue a política de runtime selecionada ou o experimento explícito e não estende a certificação do artefato. O pacote de modelo Optimized-Speed não é usado neste reteste.
• A versão do OpenCode é 1.18.31. Todos os backends e clientes rodam em série. Cada par de cliente e backend inicia um processo novo e um cache de tarefa isolado, seguido de um aquecimento de carga de modelo não relacionado, limitado a 64 tokens de saída. A carga do modelo e esse aquecimento ficam fora da tabela; a primeira tarefa ainda paga o prefill frio. O controle do ventilador permanece no padrão, e os arquivos do backbone residem em armazenamento SMB.

O que está alinhado e o que permanece diferente

Os dois clientes recebem as mesmas instruções completas e congeladas do projeto, a mesma tarefa do usuário e quatro ferramentas permitidas (glob, grep, read, skill). A CLI de código-fonte do AX Code usa os IDs reais de provedor ax-engine, mtplx e omlx; o AX Engine usa o contrato verificado de anexação em loopback, com um backend iniciado à parte que carrega indicadores administrados. Isto não mede o tempo da interface administrada de download e inicialização. O OpenCode usa o caminho de provedor compatível com OpenAI. A configuração de projeto fica desativada e cada cliente tem ajustes e estado isolados. Prompts nativos do cliente, esquemas de ferramenta e cabeçalhos de sessão permanecem intactos; portanto as contagens de tokens renderizados e o comportamento de cache diferem.

Um proxy local de gravação alinha temperature 0.55, top-p 1, top-k/min-p 0, penalidade de repetição 1, penalidades de presença e de frequência 0, seed 0, thinking desligado e um teto de saída de 1,024 tokens. Ele força tool_choice: none para esta tarefa sem ferramenta. Os dois clientes estão configurados para um contexto de 65,536 tokens. Cada linha é conferida quanto ao instantâneo completo de instruções, aos quatro nomes de ferramenta, à amostragem comum, a um pedido, à saída bem-sucedida da CLI, à parada natural e à ausência de execução de ferramenta.

Os prompts mais longos do AX Code podem aumentar tanto o prefill quanto o trabalho de atenção durante a geração. Comprimentos de resposta, conteúdo, templates de runtime, kernels e políticas de cache diferentes impedem tratar estas tabelas como um benchmark de sobrecarga de cliente com tokens iguais. MTP ativo não garante 30–40 tokens/s para um contexto completo de programação. Para isolar a sobrecarga do cliente ou o efeito da correção de prefixo, reproduza à parte pedidos serializados e IDs de token idênticos, com saída e condições de cache controladas.

Este relatório não altera comportamento de nuvem, de GPU privada, de provedor de CLI nem do AX Trust. Veja o guia de configuração do runtime local para as instruções de conexão e os dados de medição higienizados para tempos exatos, contagens, hashes, resultados de validação e evidência de MTP. Instruções privadas do projeto, respostas do modelo, caminhos locais e cabeçalhos de sessão ficam retidos localmente e não são publicados. Em consequência, a carga completa de contexto privado não é reproduzível de forma independente apenas a partir do relatório público.