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
Seleção de modelos do AX Engine
Status: Ativo Escopo: estado atual Última revisão: 2026-09-20 Responsável: runtime do ax-code
O AX Code oferece apenas estes dois pacotes de desenvolvimento por meio de AX Engine (Local) em Macs Apple Silicon elegíveis. O Tiel Coder é o padrão; o Cyber-Tiel Coder é a alternativa.
| Modelo | Repositório no Hugging Face | Seleção no AX Code |
|---|---|---|
| Tiel Coder 35B A3B MXFP4 MTP | pacote Tiel Coder | tiel-coder-35b-axq-mxfp4 (padrão) |
| Cyber-Tiel Coder 35B A3B MXFP4 MTP | pacote Cyber-Tiel Coder | cyber-tiel-coder-35b-axq-mxfp4 |
Os aliases fixam as revisões 5ab39b24bfd7f65203be9b7823b1840486f58b6d e fe05e871ec69ad9ae8eac01fd285555514ac7daf, respectivamente. Os dois usam o seletor mlx e preservam o pacote MXFP4 do publicador. As fichas dos modelos descrevem requantizações de desenvolvimento, sem alegação certificada de paridade de qualidade nem de velocidade MTP; selecioná-los não estabelece execução nativa nem ganho de velocidade.
O AX Code inclui a versão assinada AX Engine 7.5.7, que traz a correção do carregador de namespace do sidecar do Tiel, do commit 51137c71a6794964d52c32c95e275c0923ed8d0b. Binários mais antigos do Homebrew 7.4.0 não têm essa correção e rejeitam estes pacotes com MlxMtpRequiredButUnavailable. Mantenha o MTP obrigatório; substituições explícitas do runtime também precisam conter a correção. As medições nativas de prefill e de decode conservam a identidade da compilação que foi testada e não certificam o desempenho da versão mais nova.
Qwen3.8 27B, Ornith, Qwen3-Coder-Next e todos os outros repositórios ficam de fora de novas seleções administradas e de novos downloads. Cada repositório selecionado aparece uma vez. Aliases configurados e revisões mais antigas em cache não acrescentam opções depois da descoberta. Os demais provedores e a interface de conexão loopback, configurada à parte, conservam o próprio comportamento. Para executar o padrão denso do próprio AX Engine, inicie ax-engine serve qwen3.8-27b:axq e conecte esse endpoint local; o MTP medido no caminho do produto é 31.05 tok/s de decode no Mac mini M4 Pro de 64 GB e 76.90 tok/s de decode / 795.3 tok/s de prefill no M5 Max de 128 GB. Esses números não são tok/s de conclusão do Tiel nem a velocidade de uma sessão do AX Code. Veja o resumo comparativo do Tiel.
Inspecionar os modelos disponíveis
ax-code providers ax-engine models --json
ax-code providers ax-engine models --refresh --json
A atualização lê metadados do Hugging Face sem baixar pesos nem iniciar um modelo. Os metadados incluídos funcionam offline e completam o repositório selecionado quando ele falta em um cache mais antigo. Revisões já presentes não são trocadas em silêncio por outra revisão incluída. A seleção ainda exige metadados de origem válidos; a restrição de repositório não estabelece capacidade nativa.
GET /provider/ax-engine/models devolve o catálogo da CLI em execução, inclusive o ID exato de cada modelo, o repositório, a quantização, o estado local, as estimativas de memória e de disco e o status de verificação. Uma interface gráfica externa usa esta API do runtime. Se ela mostrar uma lista mais antiga, confira a CLI que ela inicia e a versão correspondente. O desenvolvimento do AX Coder pode selecionar um runtime de código-fonte com AX_CODE_BINARY ou settings.axCodeBinary.
Preparar o modelo selecionado
Copie o ID exato do modelo a partir do catálogo. O alias padrão do Tiel usa mlx:
ax-code providers ax-engine prepare \
--model tiel-coder-35b-axq-mxfp4 --quantization mlx --download --start
Modelos excluídos fazem falhar pedidos novos de preparação, de download e de ativação administrada antes de o trabalho começar. Registros de modelo já existentes continuam disponíveis para status e limpeza; IDs removidos de Qwen3.8, Ornith e Qwen3-Coder-Next nunca são redirecionados para nenhum dos artefatos Tiel. Remover uma opção não apaga os pesos dela nem interrompe um servidor já existente.
Memória e verificação do runtime
Os dois aliases selecionados usam contexto de 65,536 tokens, limite de saída de 8,192 tokens, exigência estimada de 64 GiB de memória e orçamento de disco de 32 GiB para o download. São limites de atendimento do AX Code, não o contexto máximo upstream. (O valor foi elevado a partir de um contexto inicial de 32,768 tokens: restavam apenas 24,576 tokens de entrada utilizáveis depois da reserva de saída, menos do que exigem o prompt de sistema fixo do agente do AX Code e os esquemas de ferramenta, de modo que uma sessão recém-criada nunca conseguiria enviar o primeiro turno.)
Cada estimativa de memória inclui pesos, sidecars, cache KV, buffers e reserva do host. Use o resultado de encaixe do catálogo ao vivo para a máquina atual. Essas estimativas não certificam hardware nem qualidade do modelo.
O número de 64 GiB é um orçamento conservador de planejamento para o contexto completo (64K), não um piso rígido. Para uma máquina confortável de inferência local administrada, recomendamos um Apple Silicon M4 Pro com 48 GB de memória unificada ou mais (por exemplo, um Mac Mini M4 Pro de 48 GB); Macs Apple Silicon menores ainda podem executar o próprio AX Code a partir de 8 GB, com modelos de nuvem ou de API, ou com runtimes locais mais leves.
Antes da ativação administrada, o AX Code verifica o contrato de texto e de ferramenta estruturada do modelo ativo do AX Engine. O estado verification-required significa que a preparação terminou, mas esse contrato ao vivo ainda não foi estabelecido. Nomes de repositório ou sidecars MTP, sozinhos, não provam raciocínio, visão, aceleração MTP nem qualidade de programação em vários turnos.
A compactação da sessão usa os orçamentos de contexto e de saída do modelo ativo e reserva margem de entrada. A variante selecionada conserva o próprio orçamento de catálogo; o contexto máximo do modelo de origem não é garantia de memória administrada.
Veja Arquitetura do engine local para detalhes de ciclo de vida e de transporte.
Política de MTP administrada
O AX Engine administrado usa required por padrão, em conformidade com o artefato MTP selecionado. Um drafter indisponível faz a inicialização falhar, em vez de passar em silêncio para a decodificação direta. Pesos MTP e a opção de empilhamento puro não estabelecem aceleração ativa. O pacote padrão Tiel Coder usa o perfil de especulação auto, para que o AX Engine escolha o gate de rascunho do modelo em vez da substituição 0.80 do perfil genérico agentic. Isso é independente da política de ativação do MTP: o ajuste de auto continua usando MTP de required. O ambiente experimental antigo, específico do Qwen3.8 denso, não se aplica a estes pacotes MoE. Veja a comparação de perfis para os ganhos medidos. O Cyber-Tiel conserva agentic; sondagens administradas de tarefa de leitura falharam com os dois perfis, então a confiabilidade dele nessas tarefas continua sem conclusão. A política de ativação permanece required; o engine precisa admitir o drafter real. Para escolher uma política de forma explícita, defina provider.ax-engine.options.mtpPolicy em ax-code.json:
{
"provider": {
"ax-engine": {
"options": {
"mtpPolicy": "required"
}
}
}
}
| Política | Comportamento |
|---|---|
disabled |
Usa decodificação direta; não solicita um drafter do modelo. |
auto |
Deixa o AX Engine decidir se o modelo e a rota admitem MTP. Isso não garante a ativação. |
required (padrão) |
Exige um drafter MTP admitido; o AX Engine rejeita um drafter indisponível, em vez de passar em silêncio para a decodificação direta. |
AX_ENGINE_MTP_POLICY oferece os mesmos três valores quando nenhuma opção de provedor está definida. A seleção automática do runtime exige o AX Engine 7.5.7 ou mais recente para impor estas políticas, inclusive a política padrão required. Configurações explícitas de disabled e de auto ainda prevalecem sobre o padrão. Binários mais antigos ou desconhecidos rejeitam a seleção de política antes de substituir um engine em execução; atualize antes de usar os controles de política administrada. Arquivos históricos de estado sem política registrada informam a política iniciada como desconhecida e são substituídos na próxima inicialização administrada. A mudança de política passa a valer na próxima inicialização administrada ou na próxima requisição de modelo e substitui um processo existente que use outra política. Ela não altera a seleção do modelo nem o armazenamento.
ax-code providers ax-engine start --mtp-policy disabled substitui a política apenas nessa inicialização. Defina a opção persistente do provedor se as requisições seguintes de programação devem usar a mesma substituição. Os corpos HTTP de preparação e de início também aceitam mtpPolicy. Estas configurações administradas não reconfiguram endpoints conectados à parte. Depois de atualizar o código-fonte, reinicie pnpm run dev para carregar o padrão novo; um backend de desenvolvimento que já esteja em execução conserva o código carregado até ser reiniciado.
ax-code providers ax-engine status (ou --json) separa a política solicitada, a política iniciada e o estado observado de active/inactive/unknown. A observação usa a métrica mais recente de rota do modelo no engine, não os metadados do modelo nem contagens históricas de rascunho. Amostras ausentes do modelo exato continuam desconhecidas, inclusive antes do primeiro passo observado do engine; agregados de todo o servidor não estabelecem a ativação. O required configurado não é mostrado como prova de atividade. As contagens de rascunho e de aceitos, quando existem, são cumulativas para o engine residente. Uma mudança de política pendente é informada sem reiniciar o processo durante a inspeção de status. A ativação do MTP não promete uma taxa determinada de tokens.
Interpretar a velocidade local de resposta
O AX Engine administrado não impõe um teto de tokens por segundo. Uma medição como 50 tok/s não é meta configurada nem limite superior: hardware mais rápido pode produzir tokens mais depressa. O tamanho do contexto, os orçamentos de saída e os limites de concorrência das requisições controlam a capacidade, não uma taxa fixa de geração de tokens.
O retrato público atual de Tiel em comparação com MTPLX é a campanha de API nativa de 20 de setembro de 2026, resumida no resumo comparativo do Tiel. No M5 Max de 128 GiB, o pacote Tiel padrão administrado concluiu a 194.88 tok/s, incluindo TTFT (decode 217.85). O pico de decode do Cyber-Tiel, 249.01 tok/s, é o pacote alternativo, não o padrão. Esses números não são a velocidade de uma sessão do AX Code.
Compare medições com o mesmo comprimento de entrada, o mesmo orçamento de saída, as mesmas configurações de amostragem e o mesmo estado de cache. Medições de decode com prompt curto não estabelecem uma taxa mínima para uma sessão de programação com dezenas de milhares de tokens de contexto. Reutilizar um prefixo reduz o processamento do prompt; a decodificação seguinte ainda aplica atenção a esse contexto. A ativação do MTP, sozinha, não estabelece aceitação útil de rascunho nem uma aceleração fixa.
Ao investigar um turno lento, separe inicialização e preparação, tempo até o primeiro conteúdo e geração sustentada. A métrica ax_runtime_decode_tok_per_sec do engine é uma média exponencialmente ponderada entre as requisições, não a taxa da resposta atual. Use os tempos da requisição e as contagens de tokens dessa resposta, e os deltas dos contadores para a aceitação MTP dela. Os fragmentos do fluxo podem conter vários tokens; contar fragmentos como se fossem tokens produz uma taxa incorreta.
O AX Code reutiliza, por até cinco minutos, sondagens bem-sucedidas da versão do executável. Ele confere a disponibilidade do executável em cada resolução e invalida versões em cache quando muda a identidade do arquivo do lançador ou do servidor nativo. Sondagens com falha continuam podendo ser repetidas. Isso reduz trabalho repetido de preparação; não altera a velocidade de decode do modelo. Um backend de desenvolvimento precisa ser reiniciado para carregar mudanças do código-fonte.