Nanbeige4.3-33B: 33B denso, contexto de 512K e pesos Apache 2.0, mas benchmarks próprios divergem de model cards de concorrentes
Segundo o MarkTechPost, em 25 de outubro de 2026, o Nanbeige LLM Lab, ligado à plataforma de recrutamento BOSS Zhipin, publicou no Hugging Face, sob licença Apache 2.0, o modelo denso de 33B Nanbeige4.3-33B, além da versão Base para pós-treinamento customizado, com suporte a contexto de 524.288 tokens; a própria empresa afirma liderar em 17 de 20 benchmarks, mas alguns valores de concorrentes não coincidem com os model cards oficiais desses concorrentes.
O que mudou
Segundo o repórter Asif Razzaq, do MarkTechPost, em reportagem de 25 de outubro de 2026, o Nanbeige LLM Lab (descrito na reportagem como pertencente à plataforma de recrutamento BOSS Zhipin) publicou no Hugging Face, sob licença Apache 2.0, o Nanbeige4.3-33B, junto com o Nanbeige4.3-33B-Base para pós-treinamento customizado. A reportagem afirma que o modelo é um modelo de linguagem denso de 33B (não MoE) e que o config.json citado declara a arquitetura padrão LlamaForCausalLM: 52 camadas, dimensão oculta 7.168, 56 cabeças de consulta e 8 cabeças de chave/valor (atenção por consultas agrupadas), dimensão intermediária da FFN 22.016, vocabulário de 166.912 tokens, RoPE theta de 120.000.000, até 524.288 posições (contexto de 512K) e modalidade de entrada apenas texto; a reportagem também afirma que o model card lista 1 versão quantizada da comunidade. A reportagem diz que o template de chat expõe três controles: enable_thinking (ativado por padrão), preserve_thinking e tools; a Nanbeige recomenda ativar preserve_thinking em uso de ferramentas multi-turno e cenários de agentes de código, e recomenda o formato de chamada XML para chamadas de ferramentas. A reportagem afirma que o laboratório posiciona o Nanbeige4.3-33B como modelo "professor" da série e planeja destilar capacidades de agente para modelos menores, começando pelo Nanbeige4.3-3B. Em benchmarks, a reportagem afirma que, na própria tabela comparativa da Nanbeige, o modelo lidera em 17 de 20 itens contra Qwen3.8-27B, Muse-Glimmer-30B e Gemma4-31B: Terminal-Bench 2.1 com 80,9 (Qwen3.8-27B com 73,0), DeepSWE com 65,5 contra 42,5; Terminal-Bench 4.0 com 23,8 (descrito na reportagem como a pontuação mais baixa do modelo), e SWE-Bench Pro com 60,3, atrás dos 61,7 do Qwen3.8-27B. A reportagem destaca que vários valores de concorrentes na tabela da Nanbeige contradizem os model cards oficiais: a Meta reporta Muse-Glimmer-30B com 51,2 no SWE-Bench Pro e Gemma4-31B com 36,9, enquanto a Nanbeige lista exatamente o inverso; o Google lista Gemma 4 31B com 84,3 no GPQA Diamond, mas a tabela da Nanbeige mostra 91,3; a Meta reporta Muse-Glimmer-30B com 51,7 no Terminal-Bench 2.1, e a Nanbeige mede 61,8. A reportagem considera que diferenças de harness podem explicar parte das discrepâncias, mas o par do SWE-Bench Pro parece ter sido trocado, e essas linhas devem ser tratadas como provisórias até que haja reprodução independente. Em implantação, a reportagem afirma que o model card oferece receitas para Transformers, SGLang e vLLM, que o exemplo de servidor usa paralelismo de tensor em 4 vias com os parsers de raciocínio e chamada de ferramentas do Qwen3; a reportagem estima, com base no config.json, que os pesos em BF16 exigem cerca de 66 GB e que o cache KV em BF16 ocupa cerca de 208 KiB por token, com uma sequência completa de 524.288 tokens exigindo cerca de 112 GB; a reportagem afirma que, até a publicação, nenhum provedor de inferência do Hugging Face hospedava o modelo. Todos os benchmarks acima são auto-relatados pelo fabricante ou reproduzidos pela mídia; os números de pesos e cache KV são estimativas apresentadas na reportagem, não divulgações oficiais; não fizemos testes próprios nem verificamos de forma independente os arquivos de configuração e de licença do repositório do modelo.
Impacto para desenvolvedores
A restrição mais direta para desenvolvedores é a forma de implantação. A receita oficial descrita na reportagem é paralelismo de tensor em 4 vias em servidor com múltiplas GPUs, não um caminho de workstation com uma única GPU; a reportagem também apresenta a estimativa de cerca de 66 GB para pesos em BF16, o que significa que, mesmo sem quantização, será preciso ambiente multi-GPU ou multi-máquina para colocar o serviço em produção — o plano de avaliação precisa resolver hardware antes de discutir qualidade do modelo. Esta parte é análise condicional: o consumo real de VRAM varia com framework de inferência, tamanho de batch e concorrência, e precisa ser medido na própria máquina. Segundo ponto é o custo real do contexto longo. A reportagem estima cerca de 208 KiB de cache KV por token em BF16 e cerca de 112 GB para a sequência completa de 524.288 tokens, na mesma ordem de grandeza dos próprios pesos. Isso significa que 512K é mais uma "capacidade sob demanda" do que uma configuração padrão: se a proporção de requisições longas no negócio não for alta, reduzir o limite de contexto muda significativamente o orçamento de VRAM e a capacidade de concorrência; se for realmente necessário usar todo o comprimento, o cache KV se torna o principal item de custo, e quantizar os pesos não resolve diretamente essa parte, sendo necessário configurar quantização de KV ou estratégias de paginação. Terceiro ponto é a forma de integração e adaptação de framework. A reportagem afirma que a chamada de ferramentas recomenda formato XML e que o exemplo de servidor usa os parsers de raciocínio e de chamada de ferramentas do Qwen3. Para equipes que já montaram o ciclo de agentes seguindo o protocolo de function calling no estilo OpenAI, isso normalmente significa alterar a camada de parsing e o template de prompt, e não apenas trocar o endereço de acesso. O enable_thinking ativado por padrão e o preserve_thinking, que retém o conteúdo de raciocínio histórico, também mudam a composição de tokens por rodada e o custo multi-turno; se o framework trunca ou reordena turnos anteriores, é preciso primeiro confirmar o comportamento real desses controles. Quarto ponto é o critério de avaliação. A reportagem lista conflitos entre a tabela auto-relatada da Nanbeige e os model cards oficiais da Meta e do Google em várias linhas de benchmark, com uma linha do SWE-Bench Pro aparentemente trocada; portanto, qualquer conclusão comparativa do tipo "quanto melhor que certo modelo de quase 30B" não se sustenta antes de reprodução independente. O que pode servir de referência é a informação estrutural dentro da mesma tabela: o Terminal-Bench 2.1 aparece liderando, enquanto o Terminal-Bench 4.0 tem pontuação absoluta de apenas 23,8, e essa diferença entre benchmarks da mesma família sugere alta sensibilidade a tarefa e harness, de modo que a escolha deve se basear em reprodução nas próprias tarefas. Quinto ponto é modalidade e licença. O modelo é de entrada apenas texto, não processa diretamente capturas de tela, gráficos ou vídeo, e não substitui fluxos que exigem entrada visual. Em licenciamento, é preciso distinguir pesos abertos de termos de licença: a reportagem afirma que os pesos foram publicados sob Apache 2.0, o que é mais permissivo do que "apenas pesos abertos", mas ainda se deve tomar como referência o arquivo de licença que acompanha o repositório do modelo, sem inferir condições de uso comercial e redistribuição apenas por os pesos serem baixáveis. De acordo com a verificação no catálogo atual do KimiSeek, nem Nanbeige4.3-33B nem Nanbeige4.3-33B-Base estão na lista de modelos disponibilizados; a forma de distribuição mencionada na reportagem refere-se ao download dos pesos no Hugging Face e, se houver API hospedada, aos canais da própria fabricante.
Integração e avaliação
Tudo abaixo são sugestões ou análises condicionais, não conclusões factuais da reportagem. Decisão 1 (escolha da stack de inferência): a reportagem afirma que o model card oferece receitas tanto para SGLang quanto para vLLM, e que o exemplo de servidor usa paralelismo de tensor em 4 vias com parsers de raciocínio e de chamada de ferramentas do Qwen3. A escolha é manter uma única stack ou duas em paralelo. A condição é se você depende de chamada de ferramentas: se o fluxo de agentes precisa de parsing estável de function calling, o vínculo de parser divulgado na reportagem significa que trocar de stack pode mudar o comportamento de parsing, e só então vale o custo de manter duas stacks; se for apenas inferência de texto, uma stack é mais econômica. O critério mensurável de verificação é preparar de 20 a 50 tarefas com chamada de ferramentas e medir, nas duas stacks, a taxa de erro de formato de chamada e a taxa de falha de parsing; se a diferença ficar dentro do aceitável, convergir para uma stack. Decisão 2 (limite de contexto e orçamento de VRAM): a reportagem estima cerca de 66 GB para pesos em BF16, cerca de 208 KiB de cache KV por token e cerca de 112 GB para a sequência completa. A escolha é o limite de comprimento de contexto e o limite de concorrência do serviço. A condição depende da distribuição real de contexto das requisições: se a grande maioria fica dentro de 32K, baixar o limite para bem menos que 512K libera bastante VRAM para aumentar concorrência, reservando 512K para poucas tarefas longas. O critério mensurável de verificação é registrar os percentis de comprimento de contexto em produção ou em teste de carga e medir a VRAM de pico e a latência P95 do primeiro token com o limite definido, confirmando que ambos cabem na margem do hardware; se estourarem, reduzir o limite ou usar a versão quantizada da comunidade (a reportagem afirma que o model card lista 1, cujo impacto de qualidade precisa ser medido por conta própria). Decisão 3 (prioridade e ordem de avaliação): a reportagem aponta conflitos entre a tabela auto-relatada e os model cards oficiais em linhas como SWE-Bench Pro, GPQA Diamond e Terminal-Bench 2.1, e avalia que a linha do SWE-Bench Pro parece ter sido trocada. A escolha é continuar discutindo rankings públicos ou direcionar o orçamento para reprodução nas próprias tarefas. A condição é se sua carga de trabalho tem forte relação com programação agêntica ou colaboração de escritório: se tiver, seus próprios repositórios e tarefas reais valem mais que rankings. O critério mensurável de verificação é medir, com o mesmo script de avaliação, a taxa de sucesso executável ou de aprovação no seu conjunto de tarefas, comparando com uma linha de base de mesmo porte no mesmo script; apenas diferenças dentro do mesmo harness podem orientar a escolha. Decisão 4 (composição de tokens em agentes multi-turno): a reportagem afirma que enable_thinking vem ativado por padrão, que preserve_thinking retém o conteúdo de raciocínio de turnos anteriores e que a recomendação oficial é ativá-lo em uso de ferramentas multi-turno e agentes de código. A escolha é manter o raciocínio histórico por padrão ou truncá-lo por rodada. A condição é o número de rodadas da sessão: quanto mais rodadas, mais a retenção do raciocínio amplia contexto e custo. O critério mensurável de verificação é comparar, em um mesmo lote de tarefas multi-turno, as configurações de retenção e de truncamento quanto a taxa de sucesso, consumo total de tokens e latência do primeiro token; só adotar o truncamento para controlar custo se não houver queda clara de sucesso.
Limites e pontos a confirmar
É preciso deixar claro: de acordo com a verificação no catálogo online atual do KimiSeek, nem Nanbeige4.3-33B nem Nanbeige4.3-33B-Base aparecem na lista de modelos disponibilizados, e essa versão não é oferecida atualmente no KimiSeek; a distribuição e a disponibilidade mencionadas na reportagem referem-se ao download dos pesos no Hugging Face e, se houver API hospedada, aos canais da própria fabricante. A reportagem confirma apenas que, até sua publicação, nenhum provedor de inferência do Hugging Face hospedava o modelo, e não afirma que todos os outros canais de hospedagem não o fazem; a disponibilidade em outros canais deve ser verificada separadamente. Não verificamos de forma independente o repositório do modelo, os arquivos de configuração ou os arquivos de licença que o acompanham; os parâmetros de arquitetura, controles e descrições de licença neste texto vêm da transcrição que a reportagem faz do model card e do config.json. Todas as pontuações de benchmark na reportagem são auto-relatadas pela Nanbeige ou reproduzidas pela mídia, sem reprodução independente de terceiros, e a própria reportagem já aponta que vários valores de concorrentes conflitam com os model cards oficiais da Meta e do Google, com uma linha do SWE-Bench Pro aparentemente trocada; essas linhas devem ser consideradas provisórias até reprodução independente. Os valores de cerca de 66 GB de pesos, cerca de 208 KiB de cache KV por token, cerca de 112 GB de cache KV para sequência completa e paralelismo de tensor em 4 vias são estimativas da reportagem com base no config.json ou transcrições do model card, não divulgações oficiais nem medições nossas; o consumo real de VRAM é afetado por framework de inferência, tamanho de batch, concorrência e distribuição de contexto, e precisa ser medido no próprio hardware. Apache 2.0 é a descrição de licença dada na reportagem; poder baixar os pesos não equivale aos termos de licença, e as condições concretas de uso comercial e redistribuição devem se basear no arquivo de licença que acompanha o repositório do modelo. Comportamentos como o formato XML recomendado para chamada de ferramentas, o uso dos parsers do Qwen3 e o enable_thinking ativado por padrão vêm da descrição que a reportagem faz do model card e do template de chat, e o comportamento real pode mudar com atualizações de versão. O plano de destilação do Nanbeige4.3-3B é uma declaração de planejamento divulgada pelo fabricante, sem pesos públicos ou dados de capacidade, e não deve ser tratado como capacidade já entregue.