Hy4 preview vs outros modelos de IA para código: como comparar sem cair no hype?

Modelo novo aparece e a primeira pergunta é sempre a mesma: "é melhor que o modelo X?"

Aí está o problema, porque essa pergunta, do jeito que ela vem, não tem resposta

Em 28 de agosto de 2026 a Tencent lançou e abriu o código do Hy4 preview, e junto já veio um número: média 2,99 de 4,00, contra 2,94 do Kimi K3 e 2,92 do GLM 5.3, saído de um teste cego INTERNO da própria Tencent

Guarda esse número aí que a gente volta nele, tem bastante coisa pra falar sobre o que ele mede e o que ele não mede

O que você NÃO vai encontrar aqui é ranking chutado

O que tem é método: quais critérios realmente importam num comparativo de modelo de código, onde cada critério se mede, e como montar seu próprio teste cego pra decidir com o seu repositório, não com o print do anúncio 🙂

O que é o Hy4 preview e por que ele entrou na conversa

Antes de comparar qualquer coisa, bora fixar o que é verificável sobre o modelo

O Hy4 preview é um Mixture-of-Experts com 770B de parâmetros totais e 49B ativados por token

E o que significa esse "ativados por token"? Num MoE, nem todo parâmetro entra em ação a cada token gerado: existe um roteador que escolhe quais partes da rede respondem naquele momento

São 78 camadas (a primeira com FFN densa e as outras 77 em MoE), com 256 experts roteados mais 1 shared expert por camada, e top-8 experts roteados ativados por token

É como ter uma sala com 256 especialistas e um coordenador que chama só 8 pra cada pergunta, em vez de acordar a sala inteira

O resto da ficha técnica:

• Contexto: 1.048.576 tokens, com até 64.000 tokens de saída
• Licença: Apache License 2.0
• Pesos: repositório tencent/Hy4-preview no Hugging Face, com variante quantizada em tencent/Hy4-preview-FP8
• Código: GitHub em Tencent-Hunyuan/Hy4-preview
• Execução local: existe receita oficial de execução no vLLM publicada pro modelo
• Onde está disponível: nos produtos WorkBuddy e CodeBuddy (versões chinesa e internacional), Yuanbao e ima, e por API via Tencent Cloud TokenHub e OpenRouter

Uma coisa que eu não vou fazer é chutar quanto de VRAM ou quantas GPUs isso pede pra rodar local

Esse dado não está confirmado em lugar nenhum que eu consiga apontar, e botar número por achismo é justamente o que este post tá tentando combater

Nada disso aí em cima diz se o modelo é bom, beleza? Diz só o terreno onde ele joga

Critérios que importam de verdade num comparativo de modelos de código

A maioria dos comparativos que circula mistura tudo numa nota só

Mas "escrever código" não é uma habilidade, são várias, e cada uma se mede num lugar diferente

A tabela abaixo é de CRITÉRIOS, não de ranking de modelos

A última coluna só está preenchida onde existe dado verificado, e onde não existe eu deixei explícito

Repara que a coluna da direita tem buraco

Isso não é preguiça, é honestidade: resultado independente de terceiro em benchmark de código eu não achei publicado numa página de dados viva, então não entra

Qual critério pesa mais no seu caso

Não existe critério mais importante no vácuo

Existe o critério que domina o SEU uso, e é ele que decide o comparativo

• Monorepo grande e muita documentação: contexto longo manda

Se o seu problema é o modelo perder o fio da meada no meio de uma base gigante, olhe avaliação de contexto longo antes de qualquer outra coisa

• Manutenção e correção de bug: benchmark de patch em repo real manda

Aqui o que importa é ler uma issue, entender código alheio e devolver um diff que aplica e passa nos testes, que é exatamente o desenho do SWE-bench Verified (subconjunto do SWE-bench validado por humanos, com issue real do GitHub em repositório Python) e do SWE-Bench Pro

• Automação de terminal e CI: Terminal-Bench manda

É outro bicho: o modelo precisa rodar comando, ler o erro e se recuperar sozinho, sem você segurando a mão

• Landing page, dashboard, produto visual: Frontend Code Arena manda

E aqui tem um detalhe massa: o Code Arena tem sete visões separadas de leaderboard, criadas a partir da análise de mais de 250.000 prompts (Brand & Marketing, Reference-Based Design, Data & Analytics, Consumer Product, Gaming, Simulations e Content Creation Tools)

Ou seja, o modelo bom pra landing page de marketing não é necessariamente o bom pra dashboard de dados, e olhar a visão certa te poupa uma escolha errada

• Volume alto em produção: preço e cache read mandam

Quando o consumo é grande, a diferença entre o preço de entrada e o de cache read vira a diferença entre a conta caber ou não

E se a troca de modelo já faz parte de um processo maior, dá pra encaixar a comparação dentro de uma automação de MLOps no n8n e acompanhar custo e regressão sem depender do olhômetro

Como montar seu próprio teste cego entre modelos de código

Essa é a parte que ninguém faz, e é a única que responde a sua pergunta de verdade

O método abaixo é agnóstico de ferramenta: serve pro modelo da Tencent, serve pro que sair mês que vem

1. Separe de 15 a 20 tarefas reais da sua base

Nada de fizzbuzz e de "faça um todo list": pega issue fechada, bug que já aconteceu, refactor que você adiou

Tarefa real tem contexto sujo, dependência estranha e requisito implícito, que é onde os modelos se separam

O erro comum deste passo: escolher só tarefa fácil, porque aí todo mundo acerta e o teste não decide nada

2. Defina o critério de acerto ANTES de rodar

Escreve num arquivo: compila? passa nos testes existentes? o diff ficou dentro do escopo? não quebrou lint?

Critério escrito depois vira torcida, e você vai achar bonito o código do modelo que você já gostava

O erro comum deste passo: deixar "código limpo" como critério sem definir o que isso significa no seu projeto

3. Mesmo prompt, mesmo contexto, para todos os modelos

Se você caprichou no prompt do modelo A e jogou o do modelo B de qualquer jeito, o resultado mede o seu carinho, não o modelo

O erro comum deste passo: dar arquivo extra de contexto pra um e não pro outro sem perceber

4. Anonimize as saídas e embaralhe antes de julgar

Salva tudo em arquivo com nome neutro, sem marca de modelo nenhuma:

   comparacao/
     tarefas/
       t01-corrige-timeout-no-worker.md
       t02-migra-endpoint-de-usuarios.md
     saidas/
       t01-A.diff
       t01-B.diff
       t02-A.diff
       t02-B.diff
     chave.txt   (quem é A e quem é B, e você só abre no final)

O erro comum deste passo: esquecer que a própria saída se entrega sozinha, com comentário assinado ou estilo de formatação característico, então limpe isso antes de julgar

5. Use mais de um avaliador quando der

Duas pessoas julgando o mesmo diff cego já reduz um monte de viés pessoal

Só de comparar onde vocês discordaram você aprende mais sobre o seu próprio critério do que sobre os modelos, e isso é ótimo

O erro comum deste passo: o avaliador ser a mesma pessoa que escreveu o prompt e já sabe qual saída é de quem

6. Registre custo e tokens de cada rodada

Qualidade sem custo do lado é meia informação

Uma planilha boba já resolve:

   tarefa,modelo,tokens_entrada,tokens_saida,cache_read,custo_usd,passou_nos_testes,tamanho_diff
   t01,A,18400,3200,12000,,sim,42
   t01,B,18400,5100,0,,nao,131

Pro Hy4 preview a referência pública de preço no OpenRouter é US$ 0,834 por milhão de tokens de entrada, US$ 2,501 por milhão de saída e US$ 0,042 por milhão de cache read

O erro comum deste passo: comparar custo entre provedores diferentes sem checar o preço de cada um, porque o valor do OpenRouter não fala pelo Tencent Cloud TokenHub

7. Repita a tarefa mais decisiva algumas vezes

Modelo generativo varia, e uma rodada única pode te vender sorte como habilidade

Roda a tarefa que mais importa pro seu dia a dia três vezes em cada modelo e olha a consistência, não só o melhor resultado

O erro comum deste passo: trocar de modelo no fluxo de trabalho com base num único acerto espetacular

Armadilhas comuns na hora de comparar modelos (e como evitar)

Sintoma: o número veio do próprio fabricante

Causa: aquela média 2,99, contra 2,94 do Kimi K3 e 2,92 do GLM 5.3, saiu de um teste cego INTERNO da Tencent, com 163 especialistas da própria empresa avaliando saídas de 203 tarefas de engenharia

E olha a escala: é até 4,00, com os três separados por centésimos

Correção: trate esse tipo de dado como "o fabricante diz", não como resultado independente, e repare no tamanho da diferença antes de chamar de vitória

Sintoma: o benchmark pode estar contaminado

Causa: se a solução do problema já estava no treino do modelo, o benchmark mede memória, não raciocínio

Correção: prefira benchmark que se defende disso de propósito

O SWE-Bench Pro, da Scale AI, tem 1.865 instâncias em 41 repositórios (731 públicas, 858 held-out e 276 comerciais), usa repositórios com licenças copyleft fortes como GPL nos subconjuntos público e held-out, e bases proprietárias de startups parceiras no comercial, justamente pra reduzir a chance do modelo já ter visto a resposta

Sintoma: um índice único virou a nota da prova inteira

Causa: índice sintético é resumo, e resumo esconde o que você precisa saber

O Artificial Analysis Intelligence Index v4.1.1 combina nove avaliações diferentes: GDPval-AA v2, τ³-Banking, Terminal-Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA-Omniscience e AA-LCR

Cada uma dessas mede outra coisa, e o seu caso de uso provavelmente depende de uma ou duas

Correção: abra o índice e olhe a avaliação que corresponde ao seu critério dominante, em vez de comparar a nota agregada

Sintoma: tratar arena como benchmark

Causa: o Frontend Code Arena é da Arena.ai (não do LMArena) e funciona por voto de preferência humana em tarefas reais de front-end

Isso é ótimo pra medir gosto e não serve pra medir correção

Correção: use arena pra pergunta subjetiva ("qual interface ficou melhor?") e benchmark de patch pra pergunta objetiva ("o teste passou?")

E lembre que posição em leaderboard de votos muda conforme novos votos entram, então print de ranking envelhece rápido

Sintoma: comparar preço olhando só a entrada

Causa: o custo real de um agente de código tem três pernas (entrada, saída e cache read), e agente relê contexto o tempo todo

Correção: simule com o seu volume de tokens medido no passo 6, com as três taxas na conta

Como prevenir tudo isso de uma vez: antes de repassar qualquer comparativo, pergunte quem produziu o dado, o que exatamente foi medido e quando

Se alguma das três respostas não existir, é hype, não é informação

Vale colocar o Hy4 preview na sua bateria de testes?

Vou responder o que dá pra responder, e o que dá pra responder aqui é sobre CUSTO DE AVALIAR, não sobre qualidade final

E o custo de avaliar é baixo

A licença é Apache 2.0, os pesos estão abertos no Hugging Face (com variante FP8), existe receita oficial de vLLM publicada, o acesso por API sai por Tencent Cloud TokenHub e OpenRouter, e o WorkBuddy e o CodeBuddy oferecem acesso gratuito por um período limitado de duas semanas a partir do lançamento

Pra quem já ia rodar uma bateria de teste de qualquer jeito, entrar mais um candidato nessa lista custa pouco

Agora as ressalvas, sem maquiagem:

• É preview, com tudo que a palavra carrega
• No OpenRouter o modelo é servido por um único provedor, e o OpenRouter encaminha as requisições direto pra ele, sem decisão de roteamento, então não há alternativa de fallback por lá
• Não existe, até onde eu consigo apontar com fonte, resultado independente de terceiro em benchmark de código pra esse modelo

Eu não rodei essa bateria, e não vou fingir que rodei pra te dar um veredito bonitinho

O veredito é este: o Hy4 preview é barato de testar e caro de assumir sem teste

Conclusão

Hype envelhece em semanas, método continua servindo

Daqui a um mês vai ter outro lançamento, outro gráfico de barrinha e outra thread dizendo que o rei caiu

E você vai poder passar o mesmo filtro: quem produziu o número, o que foi medido, quando foi medido, e qual critério pesa no MEU caso

Próximo passo concreto, pra fazer hoje: separa de 15 a 20 tarefas reais do seu repositório, escreve o critério de acerto num arquivo antes de rodar qualquer coisa, e faz a primeira comparação cega

Depois disso você troca de modelo com dado seu na mão, não com print de anúncio

Bora testar? 😀

Até o próximo post!