Meu notebook de 2,5 anos agora escreve Space Invaders em JavaScript (GLM-4.5 Air)

 (simonwillison.net)
3 pontos por GN⁺ 2025-07-30 | 1 comentários | Compartilhar no WhatsApp
  • Em um MacBook Pro M2 de 2,5 anos, foi usado o modelo GLM-4.5 Air 3bit para gerar de uma vez o código do jogo Space Invaders
  • O modelo é o mais recente open weight de alto desempenho lançado pela chinesa Z.ai sob licença MIT e apresenta ótimo desempenho em benchmarks de programação
  • Graças à versão quantizada de 44 GB em 3bit, ele pode rodar até em PCs com 64 GB de RAM
  • Usando a biblioteca ml-explore/mlx-lm no commit mais recente, foi possível executar o modelo localmente com velocidade relativamente alta e funcionamento estável
  • Grandes modelos de linguagem locais focados em programação lançados recentemente estão mostrando capacidade muito alta de geração de código e evoluindo rapidamente

Experiência gerando Space Invaders em JavaScript com GLM-4.5 Air e MLX

29 de julho de 2025

A família de modelos GLM-4.5, apresentada ontem, é o mais recente modelo open weight de alto desempenho lançado pela chinesa Z.ai sob licença MIT
Ela vem sendo avaliada como tendo alto desempenho, comparável a modelos já estabelecidos como o Claude Sonnet 4 em benchmarks de programação

Mesmo o menor modelo, o GLM-4.5 Air, tem 106 bilhões de parâmetros no total e cerca de 206 GB de tamanho
Ivan Fioravanti publicou uma versão quantizada para 3bit e reduzida para 44 GB para rodar no MLX, permitindo execução até em notebooks com 64 GB de memória
Ao testar pessoalmente, até esse modelo menor mostrou desempenho muito forte

Prompt de entrada:

Foi inserido um prompt pedindo para escrever uma página com Space Invaders em HTML e JavaScript

O modelo levou um pouco de tempo para gerar a resposta, e este resultado foi produzido com sucesso
Embora seja um exemplo básico, foi impressionante ver um laptop de 2,5 anos (MacBook Pro M2 com 64 GB) gerar diretamente, já na primeira tentativa, um código bem acabado que funciona

Como executar o modelo

from mlx_lm import load, generate
model, tokenizer = load("mlx-community/GLM-4.5-Air-3bit")

  • Os pesos do modelo, com 44 GB, são salvos na pasta ~/.cache/huggingface/hub/models--mlx-community--GLM-4.5-Air-3bit

  • Em seguida, insira o prompt abaixo para executar a geração

prompt = "Write an HTML and JavaScript page implementing space invaders"
messages = [{"role": "user", "content": prompt}]
prompt = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True
)
response = generate(
    model, tokenizer,
    prompt=prompt,
    verbose=True,
    max_tokens=8192
)
  • Durante o processo de geração, o modelo primeiro organiza e exibe os requisitos do problema e as informações de design do jogo
  • Em seguida, gera rapidamente código HTML, CSS e JavaScript que realmente funciona

Estatísticas de geração

  • Prompt: 14 tokens, geração a 14.095 tokens por segundo

  • Corpo: 4193 tokens, geração a 25.564 tokens por segundo

  • Pico de uso de memória: 47.687 GB

  • O histórico completo da conversa está no gist

  • O código-fonte gerado pode ser visto neste exemplo no GitHub

  • Também é possível fazer um teste direto no navegador

Teste com o benchmark Pelican

  • A capacidade do mesmo modelo para gerar imagens SVG também foi avaliada com o benchmark pelican riding a bicycle
  • Com o prompt Generate an SVG of a pelican riding a bicycle, ele conseguiu gerar com sucesso um código SVG criativo
  • O modelo consome até cerca de 48 GB de RAM para retornar o resultado
  • Foi necessário fechar alguns aplicativos do notebook para garantir memória suficiente
  • A velocidade também ficou em um nível satisfatório

A evolução dos modelos locais para programação

  • Em 2025, a maior parte dos grandes modelos de linguagem tem se concentrado em reforçar o desempenho de geração de código
  • Como resultado, eles estão mostrando alta capacidade de geração de código utilizável na prática até em hardware local
  • É um nível que estaria próximo do inimaginável na época das primeiras tentativas com o LLaMA, dois anos atrás
  • No mesmo laptop usado atualmente, já é possível se beneficiar de uma sequência de modelos open source de alto desempenho como GLM-4.5 Air, Mistral 3.2 Small, Gemma 3 e Qwen 3
  • Com o lançamento, nos últimos seis meses, de vários modelos de linguagem de alta qualidade especializados em programação para execução local, o ambiente de desenvolvimento vem melhorando

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-30
Comentários do Hacker News

  • Quando conheci o LLaMA pela primeira vez, há 2 anos, eu jamais imaginaria ver modelos como o GLM 4.5 Air de hoje em dia rodando no notebook que eu usava naquela época, junto com Gemma 3, Qwen 3, Mistral 3.2 Small e afins. Tanto a qualidade quanto a velocidade de lançamento dos modelos abertos superaram muito as minhas expectativas. Só para situar, quando o ChatGPT saiu em dezembro de 2022, os melhores modelos abertos que existiam eram o GPT-J (algo como 6~7B) e o GPT-neoX (uns 22B?). Eu realmente cheguei a operar um serviço para usuários por quase um mês com gpt-j, e a qualidade era péssima: ele não seguia instruções de jeito nenhum, então eu precisava escrever prompts em formato de história ou incluir vários exemplos para que funcionasse minimamente. Depois disso, o modelo LLaMA foi “vazado” — e eu acho que foi um vazamento intencional — e a história mudou. Na era do L1 surgiram várias otimizações, como quantização e fine-tuning; no L2, o fine-tuning passou a ser comercializado de verdade, e a maioria dos fine-tunes era melhor do que o original da Meta. Depois da demonstração de LoRA do Alpaca, vieram Mistral, Mixtral, L3, Gemma, Qwen, DeepSeek, glm, Granite e muitos outros modelos extremamente fortes. Segundo algumas análises, os modelos abertos ficam cerca de 6 meses atrás dos modelos lançados pelos laboratórios de ponta — e vale lembrar que esses laboratórios provavelmente nem divulgam seus melhores modelos, usando-os internamente para curadoria de dados da próxima rodada de treino e coisas do tipo. Uma diferença de 6 meses é coisa de maluco. Eu achava que levaria uns 2 anos para chegarmos ao nível do GPT-3.5, mas nunca imaginei que viveríamos em um mundo em que eu pudesse rodar esses modelos localmente e até fazer fine-tuning por conta própria

    • Faz um tempo que continuo perguntando como se cria ou como se usa fine-tuning de LLM ou LoRA (ajuste fino com eficiência de parâmetros). Nunca recebi respostas realmente úteis, e a busca na web está lotada de conteúdo feito para SEO e propaganda. Eu já sei há 2 anos como criar e usar SD LoRA e lido bem com isso. Mas, por algum motivo, tudo sobre LoRA para LLM parece um segredo escondido

    • O Zuck (Mark Zuckerberg) certamente não foi lá pessoalmente vazar isso em lugares como o 4chan

    • Fico curioso se o GLM 4.5 é melhor do que o Qwen3 coder

  • Ainda me impressiona que esse tipo de geração de código seja possível em um MacBook Pro M2 com 64GB comprado há 2 anos e meio. Principalmente porque saiu código que funcionou de primeira, sem correções. Acho que estamos subestimando demais o potencial incrível do hardware atual. Fico preocupado que o “bitter lesson” — essa ideia de que a mágica depende de poder computacional — e a mentalidade de “fronteira de computação eficiente” acabem afastando justamente as pessoas mais brilhantes de explorar abordagens inovadoras. Na prática, quando vemos que os modelos atuais continuam funcionando mesmo depois de uma redução brutal na precisão dos pesos após o treinamento, dá até a impressão de que talvez estejamos sendo ineficientes na direção oposta

    • A essência do bitter lesson não era justamente que o volume de dados precisa ser enorme? O modelo citado como exemplo foi treinado, na prática, em um corpus gigantesco, algo como 22 trilhões de tokens

  • Fico me perguntando se a pessoa realmente entendeu o resultado da implementação ou se só viu que ela executou. Parece plausível que um LLM também consiga cuspir respostas mais ou menos corretas para perguntas comuns de entrevista. Quando colegas apresentam mudanças em dados, já vi criarem com LLM um app de visualização de JSON, mesmo já existindo visualizadores de JSON que funcionam bem, então eu me pergunto por que reinventar isso. No trabalho, parece que as pessoas usam LLM mais para melhorar apresentações do que para criar ferramentas realmente úteis no dia a dia. Outro colega precisava de uma macro para modificar muito conteúdo de material didático, mas para fazer isso primeiro criou até uma rubrica para prompts de LLM, depois resumiu os requisitos da macro em slides de apresentação e então jogou isso de volta no LLM. Como o sistema ficou complexo demais, não acho que isso realmente tenha economizado tempo. O resultado era curioso, mas muitas vezes não servia para mais ninguém

    • Eu passei o olho no código e entendi o que ele fazia, mas, se eu só verifico que funciona, normalmente não investigo mais a fundo. Quando uso LLM para código de produção, eu verifico cada linha. Só faço commit do código quando o entendo completamente, a ponto de conseguir explicá-lo para outra pessoa. Tem um texto que detalha bem como usei LLM para escrever código de verdade
      https://simonwillison.net/2025/Mar/11/using-llms-for-code/

    • O próprio LLM é a solução

    • Na verdade, código descartável é exatamente uma área em que a IA brilha. Se ela puder gerar automaticamente boilerplate absurdo de sistemas de build, código de animação e afins, ótimo — pensando no esforço que o 3Blue1Brown coloca em animações, eu apoiaria totalmente se a IA ajudasse nisso. O fato de agora até alguém que não programa poder montar pelo menos um protótipo e repassar para um desenvolvedor profissional tem um valor enorme. Nem é necessário entender todos os detalhes do código gerado; basta julgar se passou ou falhou, e isso já tem utilidade prática imensa. Por outro lado, os problemas que valem “milhões” são justamente de outro tipo: corrigir bugs reais de serviço, adicionar funcionalidades em produto de verdade, e aí a IA bate em limites. Também existe um ponto incômodo: código descartável sempre foi um espaço de aprendizado importante para desenvolvedores juniores, e agora a IA está tomando esse lugar

  • Imagino que os dados de treinamento desse modelo devam conter uma quantidade enorme de versões de Space Invaders escritas em várias linguagens

    • O teste de verdade é pedir refinamentos de implementação, tipo “altera a função para a nave atirar para baixo”, “faz aparecer pela esquerda/direita”, “adiciona modo para 2 jogadores”, e ver se o modelo acompanha

    • Também acho provável que parte desses dados já inclua jogos existentes que o próprio modelo tenha copiado para gerar dados sintéticos. Quando vejo código de frontend em React gerado por LLM, tudo parece sair com a mesma cara

    • Essa discussão já foi encerrada há 3 anos. Desde o GPT-3, todo código utilizável já entrou nos dados de treinamento, e em apenas 2 anos saímos de “o código parece certo, mas na prática está tudo errado” para “um app full-stack que funciona em 0-shot aparece do nada”. A chave desse salto não é simplesmente o dataset, mas pós-treinamento, RL, contexto longo, comportamento agentic e coisas assim. Os primeiros modelos tinham limite de 2/4k tokens, mas hoje o jogo já mudou completamente. Ficar falando só de dados sem essa perspectiva é perder totalmente o ponto

    • A semelhança visual com o jogo Breakout é interessante

    • Há uma boa chance de que comentários como este também acabem virando mais um monte de comentários sintéticos parecidos, sem análise real, dentro dos dados de treinamento

  • Tenho um Mac M4 com 128GB de RAM e estou baixando agora o GLM-4.5-Air-q5-hi-mlx (80GB) no LM Studio. Logo compartilho os resultados

  • Acho que mostrar um LLM rodando localmente em um notebook tem um grande valor. No passado isso era quase impossível com modelos pequenos, então é de fato um marco importante. Dito isso, em um domínio tão específico e estreito quanto Space Invaders, provavelmente seria mais eficiente simplesmente procurar uma implementação pronta no GitHub ou em outro lugar e baixar. Em casos assim, o conjunto de treino em si é extremamente pequeno, e o espaço vetorial do modelo inevitavelmente também fica limitado, então há uma boa chance de o código resultante ser quase idêntico ao original ou praticamente um copia e cola. Além disso, você ainda tem que esperar a velocidade de digitação do modelo, então o valor agregado é bem baixo. Sinceramente, me parece mais inteligente pedir ao LLM algo como “encontre no GitHub um código existente de Space Invaders escrito na linguagem X”. O curioso é que, quando você pede ao ChatGPT para organizar esse tipo de código, o LLM parece ser induzido a repetir a tese de que “quase não existe overfitting e o modelo não memoriza”, e eu honestamente não confio muito em nenhuma das duas afirmações

    • Não consegui reproduzir essa mensagem de aviso no ChatGPT. Na verdade, existe uma força política considerável na forma como esse tipo de aviso é inserido — seja de forma direta ou levemente reformulada — e isso é bem interessante

  • Tentei com Claude Sonnet 4 e não funcionou direito. Nesse caso, o GLM-4.5 Air quantizado em 3bit ficou na frente. Histórico do chat: https://claude.ai/share/dc9eccbf-b34a-4e2b-af86-ec2dd83687ea Claude Opus 4 também funciona, mas ainda fica bem atrás do GLM-4.5 que o Simon mostrou: https://claude.ai/share/5ddc0e94-3429-4c35-ad3f-2c9a2499fb5d

  • No começo eu tinha lido o título errado como “nosso filho de 2 anos e meio agora faz Space Invaders em JavaScript (GLM-4.5 Air)”. Mas, daqui a alguns anos, talvez isso realmente seja possível

  • Essa discussão levanta uma pergunta interessante, bem de ficção científica. Se um binário de uma IA futura caísse por um wormhole no hardware de consumo de hoje, será que daria para rodar essa superinteligência — ou pelo menos um agente fraco — ou ela conseguiria se auto-impulsionar em outro hardware por meio de rede e persuasão?

    • Essa é exatamente a premissa básica de toda a minha pesquisa em ML até hoje. Se você trocar “wormhole” por “programação genética / neuroevolução etc.”, é a mesma coisa. Foi o software de otimização extrema da demoscene que me levou por esse caminho. A pergunta que continuo fazendo hoje é: “qual seria a complexidade de Kolmogorov de um binário que ofereça exatamente todas as capacidades de um LLM da geração atual?”. Se esse tamanho — essa complexidade — coubesse para rodar no meu desktop atual, como seria esse cenário? Meu PC roda jogos AAA a 400fps, então me recuso a acreditar que a diferença para um LLM cuspindo texto utf-8 a 100b/s precise ser tão grande assim

    • Essa é a parte que realmente acho fascinante. Quantas capacidades ocultas existem e até que ponto dá para levar isso mais ao extremo? E se estivermos falando de hardware exótico e novo? Em geral trabalhamos com abstrações por causa das limitações do cérebro humano. Essas abstrações nos forçam a focar em áreas estreitas, mas elas têm um custo alto, e eu fico curioso sobre o potencial de remover esses limites

  • Queria saber se existe algum site que organize os requisitos mínimos/recomendados de hardware para rodar LLM localmente, como se fosse uma página de “requisitos de sistema” de jogo

    • No LM Studio — entre outras ferramentas — é muito fácil escolher um modelo compatível com o desempenho do seu hardware

    • Além das outras respostas, uma boa regra prática é que a maioria dos modelos locais entrega o melhor desempenho em quantização q4, o que exige em memória pouco mais da metade do número de parâmetros do modelo. Por exemplo, para um modelo 14B, algo em torno de 8GB, e somando o contexto, cerca de 10GB de VRAM já seria uma faixa razoável. Se sobrar recurso em q4, use um modelo com mais parâmetros; se não sobrar, vá para uma quantização menor

    • Também há material de referência aqui
      https://www.reddit.com/r/LocalLLaMA/

    • Acho este site muito útil
      https://apxml.com/tools/vram-calculator

    • Se você tiver uma conta no HuggingFace, pode registrar as especificações do hardware que possui e verificar imediatamente, modelo por modelo, o que dá para rodar ou não