2.5x mais rápido: Qwen3-27B com MTP bate recorde de desempenho local

Rodar modelos grandes localmente sempre foi um jogo de equilíbrio entre qualidade e velocidade. Com o Qwen3-27B, um dos modelos mais capazes para tarefas de raciocínio, o gargalo sempre foi o número de tokens por segundo. Agora, um engenheiro conseguiu um ganho de 2.5x no throughput usando uma técnica chamada Multi-Token Prediction (MTP) em cima de quantizações GGUF, aproveitando um pull request ainda não mergeado do llama.cpp.

O Fato

O usuário havenoammo publicou no Reddit um conjunto de arquivos GGUF com MTP aplicado ao Qwen3-27B. Ele usou as quantizações UD XL do Unsloth como base e ``enxertou'' as camadas de MTP (que o Qwen3 já treinou) em Q8_0. O resultado: aproximadamente 2.5x mais tokens por segundo em comparação com a execução normal, mantendo uma taxa de aceitação alta dos tokens gerados.

Como Funciona (Visão de Operador)

O Qwen3 foi originalmente treinado com 3 passos de MTP, o que significa que cada forward pass do modelo prevê 4 tokens simultaneamente. Tecnicamente, isso é uma forma de speculative decoding: o modelo gera múltiplos tokens de uma vez, e um head pequeno verifica se eles são aceitos. A mágica é que as camadas de MTP são muito menores que o modelo base, então adicionam pouco overhead de VRAM (menos de 10% do tamanho total). No caso, o base fica em baixa quantização (UD XL, que é uma quantização de 4 bits ou similar) e os heads MTP permanecem em Q8_0 para preservar a precisão da especulação.

O grande desafio é que o llama.cpp oficial não suporta MTP. Por isso, o autor puxou o suporte de speculative decoding do PR #22673 (ainda aberto), mergeou com a master, e compilou o llama-server a partir desse fork. Para rodar, basta passar os parâmetros --spec-type mtp --spec-draft-n-max 3. Ele também disponibilizou um script de conversão (convert.py) para quem quiser adaptar a técnica para outros modelos.

O Que Isso Muda na Prática

Se você roda Qwen3-27B localmente, pode baixar os GGUFs preparados e compilar o llama.cpp customizado para obter 2.5x de velocidade. Isso significa que tarefas como geração de código, análise de documentos ou conversas longas ficam muito mais responsivas. Quem perde? Quem depende de soluções prontas tipo Ollama ou LM Studio, que ainda não suportam MTP — vai ter que sujar as mãos com compilação manual. Uma ação prática imediata: faça o fork do llama.cpp, aplique o PR #22673, e compile com suporte a MTP. Depois, baixe os GGUFs do havenoammo e teste.

Tensão / Reflexão

O ganho de 2.5x é real? Sim, mas com ressalvas. A técnica depende da qualidade dos heads MTP: se o modelo base for muito quantizado, a taxa de aceitação pode cair, anulando o benefício. Além disso, o PR ainda não foi mergeado, o que significa que pode haver bugs ou problemas de estabilidade. Outro ponto: o MTP não acelera todas as cargas de trabalho igualmente. Para geração curta (poucos tokens), o overhead de inicialização pode comer o ganho. Vale a pena o esforço de compilar um fork não oficial? Depende do seu nível de tolerância a risco e da frequência de uso do modelo. É uma otimização que resolve o gargalo de throughput, mas não o de latência inicial.

Conclusão

Multi-Token Prediction em GGUFs é o próximo passo lógico para inferência local eficiente. O trabalho do havenoammo mostra que é possível obter ganhos expressivos com uma técnica que já vem treinada no modelo, desde que o software acompanhe. A pergunta que fica: quando o llama.cpp oficial vai abraçar MTP de vez, e quanto tempo até as interfaces gráficas incorporarem isso?