Suporte vLLM para Nanbeige4.2-3B está chegando: o modelo de agente de 3B em loop da BOSS Zhipin deixa sua era de apenas forks

Nanbeige4.2-3B — o modelo agêntico compacto lançado pelo Nanbeige Lab da BOSS Zhipin no final de julho de 2026 — está prestes a se tornar disponível pela primeira vez em uma instalação padrão de vLLM. Um pull request aberto em 9 de setembro de 2026 adiciona a arquitetura ao registro de modelos do vLLM por meio do backend transformers. Se for mesclado, `vllm serve Nanbeige/Nanbeige4.2-3B` se torna um comando padrão, em vez de um ritual de fork do fornecedor. Isso é uma mudança real no que um autohospedador pode fazer: durante as seis semanas desde o lançamento do modelo, todos os mecanismos de inferência listados em sua ficha técnica — vLLM, SGLang, llama.cpp, Ollama — apontaram para um fork mantido pela Nanbeige, não para uma instalação sem modificações.

O modelo em si não é a novidade; ele pode ser baixado desde a última semana de julho. A novidade é que a era do fork-only está terminando, e termina esta semana. O SGLang integrou uma implementação nativa do Nanbeige4.2 ao seu branch principal em 5 de setembro, e o pull request do vLLM foi aberto quatro dias depois. Ambos oferecem suporte upstream, de instalação padrão, para uma arquitetura que todos os motores tratavam antes como um caso especial. Abaixo, tudo está rotulado: o que os pull requests realmente fazem, o que está verificado versus o que ainda está em aberto, as alegações de benchmark do fornecedor e os números independentes que os colocam em contexto.

O que mudou esta semana, precisamente

O pull request do vLLM é o vllm-project/vllm #56071, "[Model] Add support for Nanbeige4.2 (transformers backend)", aberto em 9 de setembro por um engenheiro da Nanbeige e ainda aberto no momento em que este texto foi escrito. Ele é deliberadamente pequeno — dois arquivos. O primeiro adiciona uma linha ao registro de modelos do vLLM, mapeando o nome da arquitetura Hugging Face NanbeigeForCausalLM para TransformersForCausalLM, o fallback genérico do vLLM que executa um modelo através do backend transformers. O segundo adiciona um NanbeigeModelArchConfigConvertor, cuja única função é informar ao vLLM quantas camadas alocar: ele retorna o num_hidden_layers da configuração multiplicado por num_loops, porque o transformer em loop da Nanbeige repete sua pilha de camadas e o vLLM deve dimensionar seu KV-cache e as instâncias de atenção de acordo.

Duas observações da thread de review importam para qualquer pessoa acompanhando isto. Primeiro, o mapeamento de registro é o que faz o modelo rodar automaticamente pelo backend transformers — um mantenedor do vLLM observou que, uma vez que o mapeamento exista, a flag explícita `--model-impl transformers` se torna redundante, e que o trabalho restante antes do merge é uma entrada de docs e um mapeamento de registro de teste de CI. Segundo, os revisores sinalizaram que uma mudança recentemente integrada no vLLM (PR #54941) pode já tornar o conversor de contagem de camadas desnecessário, detectando módulos de atenção diretamente em vez de inferi-los a partir de uma contagem de camadas. Em termos simples: a correção pode ficar mais simples antes de ser integrada, não mais complicada.

O caminho do vLLM importa mais por aquilo que não é. Esta não é a primeira tentativa de colocar o Nanbeige4.2 nativamente no vLLM. O PR #49433, aberto pelo mesmo engenheiro no final de julho como uma implementação nativa de dia zero, foi fechado em 9 de setembro — no mesmo dia em que o PR do backend transformers apareceu — depois que os mantenedores argumentaram que uma implementação de modelo sob medida era mais trabalho do que a arquitetura justificava e apontaram para o backend transformers. A conclusão para os leitores: o suporte upstream do vLLM está chegando pela rota de compatibilidade, não por uma implementação nativa ajustada manualmente, e essa distinção tem consequências reais de desempenho discutidas abaixo.

O modelo que precisou de todo esse tratamento especial

Para entender por que o Nanbeige4.2-3B quebrou todas as suposições dos runtimes, ajuda saber o que é o modelo. É um modelo de aproximadamente 4 bilhões de parâmetros, com 3 bilhões de parâmetros não-embedding, lançado sob Apache-2.0 em inglês e chinês, voltado diretamente para cargas de trabalho agênticas: agentes de código, automação de escritório, uso de ferramentas, operação de terminal. O relatório técnico (arXiv 2607.22083, datado de 24 de julho de 2026) descreve o pré-treinamento do zero em 28 trilhões de tokens, seguido por uma receita de SFT mais RL em três estágios, construída em torno da interação com ambientes do mundo real. A janela de contexto chega a 262.144 tokens. Tudo isso é verificável.

O que não é comum é a arquitetura. Nanbeige4.2-3B usa um "Looped Transformer": a mesma pilha de 22 camadas de transformer é executada duas vezes, então um modelo de 3B parâmetros faz aproximadamente o dobro do custo computacional por token de um 3B convencional, sem adicionar pesos. É assim que o laboratório concilia uma contagem pequena de parâmetros com resultados de benchmark que superam sua classe de peso — o modelo efetivamente faz uma segunda passagem sobre suas próprias representações, e a configuração expressa essa reutilização como um num_loops de 2 sobre 22 camadas ocultas (44 estágios efetivos de atenção). A contrapartida é que todo mecanismo de inferência precisa ser instruído sobre como lidar com uma pilha de camadas usada duas vezes: como indexar a atenção para o cache KV e os grafos CUDA, como dimensionar o cache, como transmitir os pesos. Um mecanismo padrão construído em torno de transformers de passagem única não faz ideia do que fazer com isso, por isso o código de modelagem personalizado vem dentro do repositório e exige trust_remote_code=True no Hugging Face Transformers.

Esse código personalizado é também onde residem as arestas mais ásperas do modelo. Um relatório independente (arXiv 2608.13987, meados de agosto) documentou cinco bugs que impediam o checkpoint lançado de carregar diretamente no Hugging Face Transformers — entre eles um buffer de incorporação de posição rotativa zerado silenciosamente e chamadas a APIs de cache removidas — e publicações da comunidade descreviam soluções alternativas como use_cache=False antes que o modelo pudesse ser executado de alguma forma. Esses problemas eram corrigíveis, e checkpoints e harnesses corrigidos agora circulam, mas o padrão é o ponto: esta é uma arquitetura inteligente que vem pagando um imposto incomum em atrito de implantação desde o primeiro dia.

Os números, fornecedor e independente

A alegação principal de benchmark, diretamente do relatório técnico, é que o Nanbeige4.2-3B supera modelos abertos maiores — Qwen3.5-9B e Gemma4-12B — em avaliações de agentes. O número principal é SWE-Bench Verified com 63,6 contra 53,1 do Qwen3.5-9B e 44,2 do Gemma4-12B. O relatório também lista GPQA-Diamond com 87,4, HMMT-Feb-2026 com 82,8, Terminal-Bench 2.0 com 44,1 e SWE-Bench Pro com 46,9. Nenhum desses foi reproduzido de forma independente no harness escolhido pelo fornecedor, e devem ser lidos como o próprio relato do laboratório sobre seu modelo — o mesmo relato que o model card resume como estando no topo do leaderboard de modelos pequenos da Artificial Analysis.

A coisa mais próxima de uma verificação independente até agora vem de uma superfície totalmente diferente. Em um benchmark on-device da Artificial Analysis × Liquid AI executado em um iPhone 17 Pro e publicado no final de agosto, uma compilação de 4 bits do Nanbeige4.2-3B empatou pela maior pontuação média entre 33 modelos sub-8GB em funcionamento em um contexto de 16K (63, no mesmo nível do LFM2.5-2.6B e à frente de vários modelos da classe 9B), e em um contexto de 64K obteve 65, perdendo apenas para os 66 do Ling 3.0 Tiny. Seu perfil por teste foi impressionante: melhor da categoria no MATH-500 (96%) e forte em chamada de funções (76% no BFCL), mas com uma taxa fraca de 33% de não alucinação no AA-Omniscience — e, decisivamente para o uso real, lento. Ele gerou aproximadamente 14 tokens por segundo e levou 21,4 segundos e 4,0 GB para responder a um prompt de 1.024 tokens; sob um limite de resposta de 60 segundos, sua pontuação média despencou de 63 para 18. Em outras palavras: a qualidade que supera os modelos de 9B é real, e também é real o custo da arquitetura em loop que a produz.

O que o suporte upstream realmente oferece

Juntando os dois eventos upstream, o panorama prático para quem faz self-hosting é direto. Se você usa SGLang, o Nanbeige4.2-3B já pode ser servido a partir de uma instalação padrão com o suporte mesclado na main branch — sem fork, com os parsers de chamada de ferramentas e de raciocínio do modelo conectados aos mesmos detectores qwen3 que o SGLang já inclui. Se você usa vLLM, o suporte padrão está a um merge de distância: a linha do registry roteia o modelo para o backend transformers, o conversor de arquitetura dimensiona o cache corretamente, e os parsers de raciocínio e de chamada de ferramentas do qwen3 são reutilizados — é assim que funciona a superfície de chamada de ferramentas compatível com a OpenAI.

A ressalva honesta é que {{1}}a rota do vLLM é um caminho de compatibilidade, não um caminho otimizado{{/1}}. Executar NanbeigeForCausalLM por meio de TransformersForCausalLM significa que o vLLM executa o código Hugging Face do próprio modelo dentro da camada de serviço, em vez de uma implementação nativa com kernels personalizados e manipulação de grafo CUDA — {{2}}essa diferença é exatamente o que o SGLang escolheu construir nativamente{{/2}}. Para um modelo de 3B cujo custo por token já é dobrado pelo loop, {{3}}é improvável que a rota com backend transformers seja o caminho de serviço mais rápido possível{{/3}}, e o histórico de cinco bugs no código personalizado subjacente significa que o caminho herda quaisquer peculiaridades remanescentes. Para cargas de trabalho agênticas, onde a correção das chamadas de ferramentas e o comportamento de contexto longo geralmente importam mais do que tokens brutos por segundo, {{4}}isso pode ser uma troca aceitável{{/4}}; para chat sensível à latência, {{5}}vale a pena fazer benchmarking antes de apostar um caminho de produção nele{{/5}}. E dois mecanismos ainda são apenas fork: llama.cpp e Ollama continuam apontando para branches Nanbeige, com o servidor llama.cpp integrado no LM Studio {{6}}ainda sem suporte à arquitetura{{/6}}.

O que assistir em seguida

Três coisas mudariam o quadro. Primeiro, o PR do vLLM precisa ser mesclado e lançado em uma versão — acompanhe o tópico e as notas de versão do vLLM; os revisores já sinalizaram que uma entrada de documentação e um mapeamento de checkpoint de CI ainda faltam antes de estar pronto para mesclagem. Segundo, observe se o conversor de contagem de camadas sobrevive à revisão, já que os mantenedores acreditam que o PR #54941 pode tê-lo tornado redundante — um sinal de quanto dessa solução alternativa é arcabouço em torno da arquitetura em loop. Terceiro, acompanhe a questão do provedor hospedado: o card do Hugging Face atualmente não mostra nenhum provedor de inferência servindo o modelo, e nós também não o hospedamos, então hoje isso é um caso de autohospedagem. Quando um provedor o listar, o lado do roteamento vira rotina — uma única API em um grande catálogo de modelos, com os preços de tabela dos provedores repassados sem nenhum acréscimo, é o caminho de baixo atrito para fazer um teste A/B de um Nanbeige4.2-3B autohospedado contra os modelos hospedados que ele afirma superar. Até lá, o marco a observar é o que acaba de acontecer: seis semanas após um lançamento que todos os principais runtimes receberam com um encolher de ombros e um fork, dois deles agora servem o Nanbeige4.2-3B a partir de uma instalação não modificada.