Tencent Hy4 preview: o novo 770B open-source e o que muda no custo de rotear modelo

49B ativos de 770B totais é o número que você paga

Em 28 de agosto de 2026, a Tencent abriu os pesos do Hy4 preview, MoE com 770B de parâmetros totais e apenas 49B ativos por token, licença Apache 2.0 e contexto de 1M de tokens, pela fonte primária no GitHub. A implicação para quem roteia workloads de LLM: cada requisição paga só 49B de computação, não os 770B.

O número que decide a conta na inferência é o ativado, não o total. O total é ficha; o ativado é a conta. Um CTO que lê a ficha como "770B de parâmetros, logo caro de servir" está olhando para a métrica errada, e é exatamente isso que esta release muda na pauta de seleção de modelo.

O que aconteceu no lançamento do Hy4 preview

O Hy4 preview é o novo modelo flagship do Tencent Hy Team, anunciado oficialmente em 2026-08-28 no README do GitHub, com ficha completa no Hugging Face. É uma arquitetura Mixture-of-Experts (MoE) cuja decisão de custo mora na densidade de ativação. Os dados publicados:

• 770B de parâmetros totais, 49B ativos por token.
• 78 camadas: a primeira densa, as 77 seguintes MoE, cada uma com 256 experts roteados e 1 expert compartilhado. Cada token ativa os top-8 experts roteados e o expert compartilhado.
• 1 camada nativa MTP (10B totais, 0.7B ativados) para speculative decoding.
• Atenção Gated DeepSeek Sparse Attention (Gated DSA) com IndexCache, arquitetura inspirada em DeepSeek e GLM.
• Contexto de 1M de tokens.
• Licença Apache 2.0, com pesos abertos.
• Disponibilidade no Hugging Face, ModelScope, GitCode e CNB, em duas variantes: Hy4 preview e Hy4 preview-FP8.

O deploy usa as receitas oficiais de vLLM e SGLang, com imagens pré-build vllm/vllm-openai:hy4-preview e lmsysorg/sglang:hy4-preview. A API é compatível com OpenAI e a Tencent publica parâmetros recomendados: temperature=0.9, top_p=1.0, com modo de raciocínio padrão "alto" (cadeia de pensamento profunda) e opção no_think para respostas diretas.

Os ganhos nomeados pela Tencent são de produtividade, não de toy benchmark: engenharia de software em tarefas de long-horizon, office e análise (artefatos, planilhas, modelos financeiros), game development do prompt ao protótipo e pesquisa científica.

Na avaliação cega, a Tencent usou 163 experts internos em 203 tarefas. O Hy4 preview ficou ligeiramente à frente do GLM 5.3 (2.99 vs 2.92, com 46,8% de vitórias) e do Kimi K3 (2.99 vs 2.94, 51,2% de vitórias). Esses números são do fornecedor e medem preferência humana interna, não um placar objetivo de custo ou latência, então a leitura correta é de posicionamento, não de veredito.

A Tencent declara limitações diretas: é uma versão early, com headroom real em pré e pós-treinamento, e tendência a sobre-raciocinar e sobre-verificar o próprio trabalho em tarefas complexas. Confesse o fator quando medir em produção.

Por que 49B ativos importam para o custo de inferência

Em um MoE, cada requisição só executa a fatia ativada de parâmetros. A conta de computação por token é decidida pelos 49B, não pelos 770B. É por isso que a ficha do Hy4 preview quebra a intuição clássica: um modelo gigante não é necessariamente um modelo caro de servir quando a densidade de ativação é baixa.

O número é a razão ativações/total: 49B sobre 770B é cerca de 6,4%. Em inferência self-hosted, o custo incremental por token é fortemente determinado pela capacidade ativada por token, pela latência de atenção e pelo hardware que você serviu. Os 770B ainda decidem o tamanho de memória para carregar os pesos e o custo de inicialização, mas é o 49B que corta o preço de cada request.

Isso reposiciona a decisão de rotear. A pergunta deixa de ser "qual modelo é mais barato no catálogo?" e passa a ser "qual é o custo por token medido deste modelo para esta classe de tarefa?". Um MoE open-weight de fronteira como o Hy4 preview coloca um custo por token de modelo pequeno em cima de qualidade de modelo grande, e é essa combinação que muda a conta entre servir público e fechar a porta.

O comparativo no eval cego completa o quadro: 49B ativos entregando resultado 2.99 no teste cego da própria Tencent, à frente de dois modelos de peso na mesma medição. Para um CTO que roteia por custo e qualidade, o dado é concreto o suficiente para exigir um teste de rota, não para assumir vitória.

Há um limite a nomear. A densidade de ativação define o custo de FLOPs, mas o custo observado em produção depende de concorrência, batching contínuo, KV-cache e do padrão de atenção esparsa, que é novo. Nenhum valor de custo por token em tráfego real foi publicado. Teste no seu workload.

O que muda na prática para a seleção de modelo

O Hy4 preview não é uma troca automática. Ele é um candidato a rota que muda como a seleção de modelo costumava funcionar. A tabela abaixo compara o regime fixo com a política de roteamento que um MoE de fronteira a 49B ativos habilita.

O preço desta leitura é uma observação honesta: benchmarks da Tencent, custo de FLOPs teórico e densidade de ativação são sinais, não são o custo do seu tráfego. A parte que só a sua operação responde é o custo por tarefa medido, com a sua amostra de requests.

O que fazer agora: medir a rota, não adivinhar o resultado

O Hy4 preview entra como rota candidata, em teste controlado, com a mesma disciplina que qualquer outro modelo de fronteira, e não como uma troca automática na aplicação. Custo e qualidade medidos no seu workload decidem a promoção. As ações abaixo resolvem a sequência na prática.

1. Medir o custo por tarefa, não por modelo. Registre o custo observado de cada classe de request (curto, longo, raciocínio, tool use) com o Hy4 preview servido na sua infraestrutura, e compare com a rota atual. O dado que decide a conta é o seu, não a densidade publicada.

2. Avaliar qualidade com critério definido antes. Use uma rubrica ligada ao trabalho, na tarefa que justifica a rota. Não converta o eval cego da Tencent (2.99 vs GLM 5.3 e Kimi K3) em validação independente de produção; trate como posicionamento do fornecedor e meça no seu caso de uso.

3. Testar o modo de raciocínio por classe de tarefa. O Hy4 preview sobre-raciocina e sobre-verifica por padrão. Para resposta direta, o no_think corta a cadeia de pensamento. Defina em qual classe cada modo entra, senão paga latência e output em excesso.

4. Adicionar o Hy4 preview como rota em um gateway, não no código do app. Uma camada de roteamento centraliza a escolha por custo, desempenho, latência e contexto, como o Nexforce Router documenta, e permite testar a rota sem reintegrar nenhuma aplicação. O roundtrip de um teste deixa de ser um projeto.

5. Definir o critério de promoção e o fallback. Só promova a rota quando custo, latência, contexto e qualidade atenderem aos limites da tarefa, com disponibilidade confirmada. Enquanto a evidência não fecha a conta, manter o Hy4 preview em avaliação é a decisão correta, e o fallback protege a aplicação.

FAQ sobre o Hy4 preview e o custo de rotear

O Hy4 preview é um modelo de 770B, então é caro de servir?

Não necessariamente. São 770B de parâmetros totais, mas apenas 49B ativos por token, porque é um MoE que só executa os top-8 de 256 experts a cada requisição. O custo incremental por token em inferência depende da capacidade ativada, não do número total, embora os 770B ainda definam memória para carregar os pesos e o custo de inicialização.

O que "49B ativos por token" significa para quem roteia?

Significa que a métrica que importa para a conta de cada request é a ativação, não o tamanho total. Para um CTO, a troca é de mentalidade: em vez de julgar o modelo pelo número grande da ficha, medir o custo por tarefa na rota. Um modelo de fronteira com densidade de ativação baixa muda a conta entre open-weight e a fronteira fechada.

O eval de 2.99 prova que o Hy4 preview é melhor que o GLM 5.3 e o Kimi K3?

Não prova. A avaliação é cega e interna, feita por 163 experts da Tencent em 203 tarefas, e os números são do fornecedor. Servem para posicionar o modelo no mapa, não como validação independente de qualidade, custo ou latência no seu tráfego. A decisão de produção sai de um teste no seu workload.

O Hy4 preview deve substituir a fronteira fechada?

Não como regra. Ele entra como rota candidata para tarefas de long-horizon em que a qualidade open-weight agora compete com a fronteira fechada, a um custo por token de modelo com 49B ativos. Para a régua restante, a fronteira fechada continua justificada. Quem decide por classe de tarefa é a política de roteamento, não a notícia do lançamento.

Já posso servir o Hy4 preview em produção?

Dá para servir hoje via vLLM ou SGLang, com imagens e receitas oficiais, e os pesos sob Apache 2.0. Rode um teste controlado antes de promoção. A Tencent declara limitações conhecidas, incluindo sobre-raciocínio e sobre-verificação, e o custo real em produção ainda não é público, então a recomendação é medir por tarefa antes de prometer qualquer ganho.

Referências e Leitura Complementar

A fonte primária do lançamento é o README oficial do Hy4 preview no GitHub, que publica arquitetura, specs, deploy, eval cego e limitações, com a ficha no Hugging Face sustentando os dados do modelo. O anúncio foi feito em 2026-08-28.

Esta análise continua o fio que o Qwen3.8-Flash-Next e a decisão de roteamento abriram dias antes: um MoE open-weight com ativação baixa muda a pergunta de "qual modelo é maior" para "qual custo por tarefa". Também se apoia na cobertura do GLM-5.3-Flash, outro open-weight de fronteira com custo baixo, e na leitura do roteamento por complexidade, que decide a rota pela tarefa em vez do modelo mais caro.

A próxima release vai confirmar ou refutar a régua

O curto prazo é de teste, não de veredito. O Hy4 preview abre um caminho concreto: servir um modelo de fronteira open-weight com a conta de uma fatia ativa de 49B, e isso dá ao comprador uma opção que antes não existia. A Tencent nomeou o headroom e as limitações; a expectativa realista é iteração rápida nas próximas semanas.

A decisão de rota fica com o dado da operação. O teste decide. Quem serve por gateway de modelo pode colocar o Hy4 preview como rota candidata, medir custo, latência e qualidade por tarefa e promover só o que fecha a conta. O que esta release muda é a régua: daqui para frente, o "modelo grande e caro" e o "modelo pequeno e barato" deixam de ser lidos pelo número total na ficha, e passam a ser decididos pelo que cada requisição realmente ativa.