O rematch chegou 1 day early. Ontem artigo de ajuste do M1 Ultra fechou com uma previsão: quando uma versão MLX chega com gráficos de decodificação compilados, a revanche contra a corrente de 20,3 tok/s levaria uma tarde e 1 download. Esta manhã eu avistei um novo runtime chamado MTPLX prometendo esse futuro como um produto acabado — decodificação especulativa multi-token-prediction nativa em Apple Silicon, um autotuner que mede sua máquina específica, um servidor OpenAI- e Anthropic-compatible, lançamentos de 1-clique para os harnesses de agente que realmente usamos, e Qwen3.8-27B como seu modelo de codificação principal. O site deles diz "seus ferramentas favoritas, com velocidade dupla." Eu o trouxe para Kimi K3, meu colaborador na aventura de tuning no dia anterior, e definimos os termos juntos: instale-o limpo no Studio, deixe seu próprio tuner fazer o melhor caso, então meça o que o servidor realmente serve. Kimi executou o trabalho remoto e os contadores; eu mantive as regras da casa e fiz as chamadas. É assim que o dia realmente aconteceu.

MTPLX é a versão de produto da pista que construímos juntos

A arquitetura merece crédito de início, porque é a ideia certa executada seriamente. MTPLX redige com as próprias cabeças MTP do modelo — o mesmo mecanismo que nossa pista usa — e aceita rascunhos por amostragem de rejeição exata, então amostrar na temperatura 0.6 produz a mesma distribuição que a decodificação comum, apenas mais rápido. Não há modelo de rascunho separado consumindo memória, a profundidade do rascunho é ajustada por máquina contra uma linha de base autorregressiva, e o projeto recusa anexar sidecars MTP não verificados a pesos arbitrários. Essa última política é uma disciplina que Kimi e eu tivemos que aplicar manualmente no dia anterior, quando reparamos os tensores MTP caídos do Qwen3.8 com seu tronco. A pista da parte um foi a régua óbvia: mesmo Studio, mesma família de modelos, medido da mesma forma.

A instalação passou pelas verificações de quarentena 2 antes de tocar em um peso

A primeira verificação foi minha. Em março, no meu laboratório de refinamento autônomo, encontramos uma armadilha onde um ambiente Python isolado perdeu silenciosamente o acesso às bibliotecas aceleradas do Apple, e os números só voltaram lentos. Antes que Kimi avançasse, pedi prova de que a armadilha não se aplicava. Um probe de linha 3 resolveu — interpretador arm nativo64, Metal disponível, GPU como o dispositivo padrão. O caminho Metal do Apple embarca dentro da própria roda mlx-metal, então a origem do interpretador é irrelevante para o acesso à GPU, e a via da parte um já havia provado a taxa de transferência nativa GPU através da mesma forma de isolamento. O próprio inspetor do MTPLX concordou, avaliando ambos os seus builds Qwen3.8-27B verificados-nativos com todos os tensores MTP 15 presentes.
A segunda verificação foi a de Kimi, no meio do download. O comando pull do MTPLX ignora as variáveis de ambiente de cache usual do Hugging Face, e a primeira tentativa foi escrever 20 GB de modelo no diretório home do Studio em vez do volume de dados que as regras da casa protegem. Kimi interrompeu o pull, removeu apenas o que havia criado, e reiniciou com um diretório de cache explícito. Os fãs permaneceram na curva do Apple o dia todo, o que importa em uma máquina que também funciona como simulador de voo.

A máquina mais barulhenta naquela manhã não era a que executava o experimento

No meio do download, minha própria estação de trabalho começou a disparar forte — média de carga ultrapassando 50 — e paramos o experimento para responder a uma pergunta mais importante: era isso culpa nossa? Não era. Nosso trabalho rodou no Studio em sessões SSH de curta duração; a pegada local era apenas alguns processos curl e ssh concluídos. A tempestade foi uma onda de daemon Apple — um download de ativo travado, indexação, e um estouro de um processo de virtualização que desapareceu antes que pudéssemos nomear seu dono — além da descoberta de que os "processos de nó misteriosos que respawnavam" que eu estava matando eram 3 supervisores de desenvolvimento fazendo exatamente o trabalho deles ao reiniciar seus servidores. Escrevemos tudo isso na transferência de guarda da máquina e voltamos ao experimento com uma consciência limpa. A pausa pertence a esta história porque a disciplina é a mesma que os benchmarks usam: conheça sua própria pegada antes de culpar uma máquina.

O autotuner mediu um estouro de 2.20x

O ritual de afinação da MTPLX é engenharia honesta: ele executa o modelo real em seu hardware em cada profundidade de rascunho, mantém a decodificação autoregressiva como linha de base, e salva uma profundidade apenas se superar essa linha de base. No M1 Ultra ele produziu AR 11.4, profundidade 1 em 9.2, profundidade 2 em 25.1, profundidade 3 em 20.7 tok/s — profundidade 2 coroou o vencedor em 2.20x, salvo para todas as futuras execuções.
Esse 25.1 é uma medição real de um motor real, 24% acima da taxa de serviço da nossa faixa 20.3. Se o servidor tivesse reproduzido, este artigo seria um guia de migração.

O servidor serviu 16.5, e os padrões estavam gastando tokens fora de vista

O banco de teste de serviço usou os mesmos prompts, temperatura 0, e contabilidade de relógio de parede como a linha de base do lane. A primeira execução retornou em 14.7 tok/s, e os metadados da resposta mostraram 2 padrões funcionando contra a medição:
  • O modo de raciocínio padrão está ligado, e Qwen3.8 pensa antes de responder. Em um prompt trivial de contar até 10, 44 dos tokens gerados 64 estavam ocultos em raciocínio que o cliente nunca exibe. Cargas de trabalho reais pagam por esses tokens, então a taxa de parede já os inclui — mas os prompts do afinador não tinham tal imposto.
  • O perfil de tempo de execução Turbo, com seus kernels de verificação compilados, é uma regra de lançamento do aplicativo Mac nativo. Um terminal mtplx serve resolve para o perfil Sustained em vez disso, então o caminho de linha de comando nunca vê os kernels rápidos a menos que você peça.
Fixar Turbo, profundidade 2, e raciocínio desligado elevou a construção FP16 para 16.5 tok/s de parede — o melhor MTPLX produziu o dia todo. A construção 4-bit Optimized-Speed, a que o projeto recomenda para codificação, serviu 15.5. Ambas as construções ficam em 20.4 GB no disco contra os 15 GB do nosso lane, e em uma máquina limitada por largura de banda cada token paga para transmitir esses extra 5 GB.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)
Chart data
tokens per second
our lane (part one)20.3
MTPLX tune claim (D2)25.1
MTPLX FP16 turbo D216.5
MTPLX 4-bit turbo D215.5
MTPLX defaults14.7

O afinador e o servidor medem 2 máquinas diferentes

A descoberta mais útil do dia explica a lacuna entre 25.1 e 16.5. O próprio servidor da MTPLX registra uma escada de aquecimento na inicialização, e essa escada relata 20-24 tok/s do motor — dentro do mesmo processo que então serve 16,5 sobre HTTP. O motor é rápido e o transporte é taxado. Entre o loop de decodificação e o cliente está a camada HTTP, contabilidade de banco de sessão por solicitação (uma gravação de instantâneo de 160 MB apareceu nas estatísticas da primeira solicitação), e a maquinaria de raciocínio, e cada token atravessa essa fronteira. Nos chips M4 e M5, onde os números publicados 1.6-2.24x do projeto foram medidos, CPU mais rápida e tecido absorvem a travessia. O motor do M1 Ultra mantém o ritmo; seu caminho de serviço não.
Diagram source
graph LR
    subgraph Caminho do afinador
        A[Modelo real] --> B[Profundidades de rascunho D1-D3]
        B --> C[Temporizador apenas de decodificação  
25.1 tok/s]
    end
    subgraph Caminho de serviço
        D[Solicitação HTTP] --> E[Banco de sessão  
+ padrões de raciocínio]
        E --> F[Mesmo motor  
escada mostra 20-24]
        F --> G[Fronteira por token  
16.5 tok/s parede]
    end

    style C fill:transparent,stroke:#10B981,stroke-width:2px
    style G fill:transparent,stroke:#F59E0B,stroke-width:2px
Esta é a lição da parte um vestindo um novo traje. As reivindicações da comunidade do llama.cpp de 25-32 tok/s não sobreviveram ao contato com este chip, e o afinador da MTPLX 25.1 não sobreviveu ao seu próprio servidor. A regra durável afina: a taxa de serviço é medida no limite HTTP com os padrões de produção visíveis, nunca dentro do afinador. Isso é benchmark-driven development aplicado 1 camada acima da pilha.

O desafiante saiu 38 GB mais leve, e o watchdog ficou para trás

Eu dei a Kimi 1 não negociável antes do experimento começar: o que quer que rode naquele Studio tem que parar sozinho quando estiver ocioso, porque o trabalho noturno da máquina é um simulador de voo. A MTPLX não envia tempo limite de inatividade para seu servidor de chat, então Kimi incorporou o watchdog em um pequeno script wrapper — ligação apenas de loopback, ventiladores na política de Apple, e um observador de conexão que para o servidor após 10 minutos sem clientes. Ele passou no teste de fogo ao vivo, derrubando uma instância de teste no marco de 60 segundos e liberando a porta de forma limpa. O wrapper e o ambiente virtual permanecem na máquina, então o reteste está 1 download de distância quando uma liberação da MTPLX funciona o caminho de serviço da geração M1 ou envia um artefato MTP compatível mais próximo de 15 GB.
Os pesos em si não permaneceram. Uma vez que o veredicto ficou claro, fizemos a limpeza cuidadosamente — ambos os diretórios de modelo da MTPLX, 38 GB em toda a FP16 e builds de 4 bits, excluídos após confirmar que nenhum processo os mantinha, devolvendo o volume exatamente ao seu espaço livre pré-experimento. A exclusão permanece parte do fluxo de trabalho: todo desafiante que perde deixa o disco no mesmo dia, o que mantém o próximo experimento honesto.

O que o rematch adicionou à lista de verificação

A pista da parte um nunca se moveu. Ela serviu pela manhã em 20.3 tok/s, serviu à noite em 20.3 tok/s, e agora mantém seu slot contra desafiante 3 em vez de 2 — ainda uma pista experimental, 1 download de distância de seu próximo rematch. A lista de verificação da parte um ganha 3 entradas:
  • O número do afinador é o teto do motor, e o caminho de serviço decide quanto dele você mantém. Meça na fronteira o que seus clientes realmente cruzam.
  • Os padrões são parte do benchmark. Modos de raciocínio, perfis de tempo de execução e caches de sessão gastam tokens ou tempo, e uma luta justa os fixa explicitamente em ambos os lados.
  • Disco é um orçamento de hipótese. 2 desafiante constrói em 20.4 GB cada comprado 1 tarde de certeza, e a certeza é mais barata quando os bytes saem no cronograma.
A simetria satisfatória do par é que a parte um terminou enfileirando este experimento exato, e o experimento chegou embalado como um produto com verdadeira arte nele — amostragem exata, ajuste por máquina, verificação honesta. A arte foi real e a perda foi real, e ambos os achados surgiram do mesmo dia de medição, tempestade de CPU e tudo. Uma aventura com placar é o melhor tipo, e esta teve Kimi K3 lendo cada contador ao meu lado — o mesmo retorno composto que obtenho tratando ganhos de IA local como infraestrutura. A pista mantém seu slot, o disco é enxuto, a lista de verificação é mais longa, e o próximo desafiante já está bem-vindo para tentar.