miHoYo abre o código do GameScaling, modelo de teclado e mouse

A equipe de pesquisa em IA de Honkai da miHoYo, em conjunto com a Universidade Tsinghua, a Universidade da Academia Chinesa de Ciências, a Universidade de Hong Kong e outras instituições, lançou o GameScaling, um conjunto de modelos de agentes de jogo que geram diretamente ações de teclado e mouse. O artigo foi publicado no arXiv em 20 de outubro; os pesos do modelo e o cliente de inferência já estão públicos no Hugging Face e no GitHub, com licença Apache-2.0.

O modelo usa como base o modelo de visão e linguagem Qwen3.5, da Alibaba, com pré-treinamento continuado em vídeos de jogos acompanhados de registros de teclado e mouse. Basta mostrar alguns quadros, e ele responde quais teclas apertar e para onde mover o mouse em seguida.

Como as ações são codificadas

A cada chamada, o modelo gera as ações dos próximos 200 milissegundos, divididas em 6 passos de 33 milissegundos, mais o deslocamento do mouse e a roda de rolagem para todo esse bloco de tempo. O deslocamento do mouse é expresso em milésimos, limitado a mais ou menos 1000; a roda fica limitada a mais ou menos 5. Cada passo admite no máximo 4 teclas simultâneas, e o vocabulário de teclas usado no treinamento tem 74 itens.

O modelo pode pensar antes de agir ou emitir a ação diretamente, alternando conforme a tag <think> seja ou não preenchida previamente. O projeto recomenda implantação com vLLM, com até 8 imagens por requisição; o padrão é 5 quadros de histórico mais 1 quadro atual.

Há quatro tamanhos: 0,8B, 2B, 9B e 27B. Os três primeiros rodam em uma única placa; os pesos em bfloat16 do 27B ocupam cerca de 54,7 GB e exigem duas placas com paralelismo de tensores. Cada tamanho tem ainda duas versões, S1 e S3: a S1 usa só dados de Minecraft, enquanto a S3 é uma mistura equilibrada, com 27% de Minecraft e o restante vindo de outros jogos, somando 8 checkpoints.

O que 120 configurações revelaram

O núcleo do artigo são os experimentos de escala. Os autores desenharam 120 configurações de treinamento em três eixos: volume de dados, diversidade e tamanho do modelo. O orçamento de dados foi dividido em 6 faixas, de 50 a 1.600 horas, com 5 esquemas de mistura de dados.

As conclusões têm várias camadas. Quanto mais dados, melhor o desempenho no mesmo jogo; a diversidade ajuda o modelo a transferir para jogos parecidos, mas, ao passar para mundos muito diferentes, o ganho é limitado. Quando o treino ocorre em um único jogo, um modelo maior melhora a eficiência dos dados, mas generalizar para jogos distantes fica mais difícil.

O treinamento também se divide em duas fases. No início vem a "fase da interface", em que o modelo aprende a operar teclado e mouse, e esse ganho vale entre jogos; depois vem a "fase do mundo", em que o ganho se restringe ao mesmo jogo e a jogos próximos. Com base nisso, os autores ajustaram leis de escala empíricas entre a perda de validação e as três variáveis, e afirmam que, em mundos 3D, os modelos conseguem rivalizar com modelos especializados em Minecraft e com modelos de ponta, com o melhor desempenho em cenários de tempo real.

A conclusão do artigo também é direta: o aprendizado por imitação tem um teto, a diferença em mundos distantes persiste, e para criar agentes incorporados de uso geral o pré-treinamento continuado, sozinho, não basta.

Até onde desenvolvedores na China podem ir

O conjunto traz algumas facilidades prontas para equipes na China. A base é o Qwen3.5, cujas ferramentas de implantação em nuvens locais e em ambiente próprio já são familiares; sob a licença Apache-2.0, pesos e código de inferência podem ser modificados e integrados.

As limitações também estão claras. O repositório não tem código de treinamento, o corpus de treino não é público, os dados de imagens dos jogos não são divulgados, os direitos autorais dos jogos pertencem às respectivas publicadoras e a licença não concede direito de uso sobre nenhum conteúdo de jogo. O projeto declara que se destina apenas à pesquisa, sem atividade comercial; o próprio artigo no arXiv usa a licença CC BY-NC-SA 4.0, que é distinta da Apache-2.0 do modelo, e as equipes que pretendem comercializar precisam avaliar as duas separadamente.

Em cenários concretos, equipes que querem fazer testes automatizados de jogos, bots de companhia ou pesquisa em agentes incorporados podem testar diretamente a versão 0,8B ou 2B em uma única placa e ver até onde ela chega no próprio jogo. Para continuar o treino com dados próprios sobre essa base, será preciso montar por conta própria o pipeline de treinamento.

O README não lista todos os jogos suportados; nos exemplos aparecem apenas o Minecraft e uma fase de Doom do ViZDoom. Como o modelo se sai nos jogos da própria miHoYo, nem o artigo nem o repositório mencionam.

Fontes: página do artigo no arXiv, CocoLoop, repositório do GameScaling no GitHub; o README do repositório foi usado para conferir o número de checkpoints, o tamanho dos pesos e o formato de codificação das ações.