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

Medições de inferência local: 19 de setembro de 2026

Status: Ativo

Escopo: instantâneo diagnóstico medido

Última revisão: 2026-09-19

Responsável: ax-code runtime

Para a matriz completa de cliente com seis combinações, depois da correção de prefixo local, veja o novo reteste de AX Code e OpenCode. As velocidades de cliente abaixo continuam observações históricas, nas condições originais delas.

Estas medições investigam a latência de resposta local e a velocidade de decodificação num Apple M3 Max com 128 GiB de memória unificada. Não são uma qualificação de hardware, uma avaliação de qualidade de modelo nem uma promessa de 30–40 tokens/s em comprimentos arbitrários de contexto. As instruções de conexão de MTPLX e oMLX estão no guia de runtime local.

Condições e cronometragem

• Código-fonte do AX Code baseado na v7.19.3; OpenCode 1.18.31; AX Engine 7.4.0; MTPLX 2.11.3; oMLX 0.6.4 (1d7826185c5b5b69b38b27cbe57d7597b7551fd7, instalação isolada a partir do código).
• Um backend de inferência por vez. Controle padrão da ventoinha; sem afirmação de ventoinha no máximo. Os arquivos de modelo estavam em armazenamento SMB. A execução de artefato exato do MTPLX preparou só o sidecar MTP em SSD, com o SHA-256 verificado.
• As reproduções de artefato exato usaram AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, revisão 4d36d652c21590f6813495351c3baf5fca5b3831. As execuções separadas de cliente MTPLX Optimized-Speed usaram Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. São pacotes de modelo diferentes, embora os tamanhos totais de arquivo sejam parecidos; as taxas deles não isolam uma aceleração só do runtime.
• Ajustes comuns de reprodução: temperatura 0.55, top-p 1, top-k 0, semente 0, até 256 tokens gerados. AX Engine e MTPLX usaram MTP ativo com profundidade 3. Os kernels de runtime e os amostradores especulativos diferem. Os metadados do artefato declaram profundidade 1; a profundidade 3 aqui é um experimento explícito de runtime, não uma extensão da certificação do artefato nem uma recomendação nova de padrão. O AX Engine ignorou o EOS na reprodução nativa de saída fixa; MTPLX e oMLX seguem as próprias regras de parada.
• A taxa nativa de decodificação usa contadores de decodificação do backend. A taxa entregue é (reported completion tokens - 1) / (last output payload time - first output payload time); eventos vazios e keepalives não contam como saída. Essas fronteiras não são idênticas.
• A latência do primeiro payload inclui a preparação da solicitação no servidor, a restauração ou o prefill do cache e qualquer armazenamento em buffer antes da saída. O total de tokens dividido pela solicitação inteira é outra medida de vazão. Rajadas de chamada de ferramenta não servem para estimativas de decodificação do primeiro ao último payload.

Por exemplo, a mesma reprodução MTPLX de entrada de 30k mediu 13.99 tokens/s de decodificação nativa, mas apenas 1.13 tokens/s na solicitação completa, porque o prefill a frio consumiu cerca de 209 segundos. Um número baixo da solicitação inteira, sozinho, não estabelece uma falha do motor de decodificação.

Reprodução de AX Engine e MTPLX com pesos exatos

Cada par recebeu a mesma sequência inteira de tokens de entrada e emitiu 256 tokens. Os valores abaixo são observações únicas; as identidades dos tokens gerados podem diferir apesar de uma semente comum.

O MTPLX usou o perfil Sustained para este artefato. A solicitação de 30k do AX Engine estava aquecida, enquanto o MTPLX estava frio, então os tempos do primeiro token não estabelecem uma razão de velocidade de prefill. A entrada de 30k inclui uma instrução histórica de limite de passos e produz prosa de diagnóstico; não é aceitação de tarefa de código. A reprodução MTPLX de 18,643 tokens informou stop depois de 256 tokens, em vez de length.

O prompt curto mostra taxas de decodificação parecidas. Estas execuções não demonstram que um dos backends seja universalmente mais rápido, nem que trocar o AX Code para outro backend garanta uma aceleração fixa.

AX Code e OpenCode no MTPLX Optimized-Speed

Os dois clientes receberam a mesma tarefa do usuário, as instruções completas do projeto e quatro esquemas de ferramenta permitidos. A tarefa pedia um cache LRU em TypeScript, sem executar ferramentas. Os prompts específicos do cliente foram conservados; um proxy de gravação alinhou a amostragem, desativou o raciocínio e usou um teto de 1024 tokens de solicitação e de servidor. As respostas seguintes concluíram de forma normal:

Estas medições precedem a correção de prefixo local do AX Code (42908b46a). O AX Code enviou mais contexto e produziu código diferente. Isto não é uma comparação de custo de cliente com o mesmo número de tokens, nem um resultado de antes e depois. Remover só o mapa de diretório varrido de forma automática, numa reprodução separada, reduziu a entrada para 30,717, mas melhorou a decodificação observada em apenas cerca de 2%; a remoção do mapa de diretório não foi adotada.

Uma matriz separada do adaptador do AX Engine observou o AX Code em 9.44–11.56 t/s entregues, com 33,225 tokens de entrada, e o OpenCode em 12.82–13.00, com 17,290. Os comprimentos de prompt, o conteúdo da saída, o estado do cache e o teto de saída de 256 tokens diferem da tabela de resposta completa acima; não junte isso num único razão de aceleração de backend.

oMLX

O teste do oMLX usa o artefato AXQ exato e uma instalação isolada com MLX 0.32.0. Todas as cinco checagens de importação de kernel nativo, inclusive qwen35_prefill e decode_fast, passaram. O carregamento só de texto é selecionado de forma explícita, a janela de contexto é 65,536 e a concorrência é um.

A tentativa inicial de Lightning MTP devolveu HTTP 409 porque o teste pulou o passo exigido do oMLX, Importar sidecar MTP. Foi um erro de configuração, não falta de suporte a AXQuant. O AXQuant já fornecia o contrato canônico qwen3-next-mtp; a revisão atual do Hub b0784088d4026ca569c5653e6e6243c501ef5fa9 também inclui a listagem axquant_omlx_compat.json de 15 tensores MTP. O instantâneo original da reprodução é anterior a essa anotação.

A linha de base com MTP desligado concluiu com o artefato original:

Estes são resultados com MTP desligado e não devem ser comparados com runtimes de MTP ligado como evidência de uma diferença inerente de velocidade de backend. As idas e voltas do tokenizador e as contagens de prompt do servidor casaram com as entradas inteiras usadas pelos outros backends de reprodução.

A execução MTP corrigida usa o importador próprio do oMLX numa cópia gravável separada. Os fragmentos da espinha não mudam. O importador acrescenta language_model. aos 15 nomes de tensor do sidecar; o dtype, a forma e o hash da carga de cada tensor foram verificados iguais antes e depois da importação. O hash do arquivo importado, portanto, difere porque o cabeçalho mudou. Os metadados originais e o instantâneo compartilhado do modelo permanecem intactos. A profundidade 3 de MTP é selecionada de forma explícita, e os contadores de rascunho e de aceitação por profundidade confirmam a execução real.

O resultado curto confirma que este pacote AXQuant funciona com o Lightning MTP do oMLX depois da importação. A decodificação de contexto longo continua mais lenta apesar do MTP ativo. Texto gerado diferente, versões de runtime, kernels e políticas especulativas impedem atribuir todas as diferenças entre runtimes ao AX Code.

Aceitação do fluxo de código e exclusões

Depois da correção de prefixo local, o AX Code concluiu uma tarefa isolada e somente leitura tanto no AX Engine quanto no MTPLX: ler um diretório e dois arquivos TypeScript, explicar a exceção de fila cheia, identificar a capacidade 7 e devolver um marcador disponível só no segundo arquivo. Os dois saíram com sucesso e preservaram os bytes do fixture. Chamadas seguintes do AX Engine reutilizaram 11,264 tokens de entrada; o MTPLX reutilizou 11,264–12,032. Os corpos da primeira solicitação eram idênticos, mas os modelos de runtime produziram contagens diferentes de tokens. Isto verifica o fluxo de ferramenta e a reutilização observada de cache, não uma aceleração fixa vinda do patch.

Os IDs novos de provedor também passaram na aceitação ao vivo a partir da CLI do código-fonte: omlx com o pacote AXQ importado e tool_call: true explícito, e mtplx com o pacote Optimized-Speed e sem entradas de modelo configuradas. O MTPLX descobriu o modelo de chat e a capacidade de ferramenta a partir da listagem nativa de modelos. As duas execuções concluíram duas leituras bem-sucedidas de arquivo e devolveram a exceção esperada, a capacidade e o marcador só do arquivo, sem alterar os bytes do fixture. O prefixo inicial de sistema e de usuário permaneceu idêntico nas três solicitações de cada execução. O oMLX reutilizou 8,192 tokens; o MTPLX reutilizou 11,829 e 12,047 tokens. São checagens funcionais, não execuções pareadas de desempenho; não se afirma aceleração de tempo de parede entre runtimes.

Respostas anteriores do AX Code com teto de 256 tokens foram truncadas e entraram em recuperação; as taxas de saída repetida, em torno de 51–58 t/s, ficam de fora das afirmações de geração nova. Execuções iniciais com instruções de projeto desiguais ou permissões de ferramenta desiguais também ficam de fora. Ollama e LM Studio foram inspecionados só quanto à construção da solicitação; nenhum resultado de taxa de geração é afirmado para eles.

O prompt genérico de 62 tokens é público como uma solicitação exata de completação do oMLX. A partir da raiz do checkout, depois de importar o sidecar, ativar o MTP e aquecer o modelo, ele pode ser enviado com:

curl --no-buffer http://localhost:8000/v1/completions \
  -H 'Content-Type: application/json' \
  --data-binary @docs/data/local-inference-short-request.json

Mude o ID de modelo da solicitação para o ID exposto pelo seu servidor. O arquivo inclui o modelo renderizado; use o endpoint de completações para que um modelo de chat não seja aplicado uma segunda vez. Confirme 62 tokens de prompt e conserve o evento final de uso. O carregamento a frio do modelo e o aquecimento precisam ser informados à parte.

Instruções privadas de projeto, prompts de sessão, caminhos locais e detalhes de autenticação não são publicados. Os dados sanitizados de medição contêm contagens, tempos, identidade de runtime e hashes de entrada, e não texto de prompt. A reprodução completa de contexto privado, portanto, não é uma carga reproduzível de forma pública e isolada. Para uma comparação nova, use a mesma revisão de modelo, o mesmo tokenizador e modelo, os mesmos IDs de entrada, as mesmas regras de saída e de parada, a mesma amostragem, o mesmo modo MTP, o mesmo estado de cache, o mesmo hardware e a mesma execução em série; informe à parte o sucesso da tarefa completa.

Contratos de origem: guia de servidor e de modelo do MTPLX, oMLX 0.6.4. Os benchmarks publicados deles usam outro hardware e outras cargas, e não substituem as medições daqui.