Mon ordinateur portable de 2,5 ans écrit désormais Space Invaders en JavaScript (GLM-4.5 Air)

 (simonwillison.net)
3 points par GN⁺ 2025-07-30 | 1 commentaires | Partager sur WhatsApp
  • Sur un MacBook Pro M2 vieux de 2,5 ans, le modèle GLM-4.5 Air 3bit a permis de générer d’un seul coup le code du jeu Space Invaders
  • Ce modèle est le tout dernier modèle open weight publié sous licence MIT par Z.ai en Chine, et affiche d’excellentes performances sur les benchmarks de code
  • Grâce à la version quantized 3bit de 44 Go, il peut fonctionner même sur un PC avec 64 Go de RAM
  • En utilisant la bibliothèque ml-explore/mlx-lm avec son commit le plus récent, le modèle a pu être exécuté en local avec une vitesse relativement élevée et un fonctionnement stable
  • Les grands modèles de langage récents spécialisés dans le code en local affichent des capacités de génération de code très élevées et progressent rapidement

Expérience de génération de JavaScript Space Invaders avec GLM-4.5 Air et MLX

29 juillet 2025

La famille de modèles GLM-4.5 présentée hier est un tout récent modèle open weight haute performance publié sous licence MIT par Z.ai en Chine
Elle est considérée comme affichant de très bonnes performances sur les benchmarks de code, au point d’être comparée à des modèles existants comme Claude Sonnet 4

Même le plus petit modèle GLM-4.5 Air compte 106 milliards de paramètres au total, pour environ 206 Go
Ivan Fioravanti en a publié une version quantifiée en 3bit à 44 Go pour pouvoir l’exécuter avec MLX, ce qui le rend utilisable même sur un ordinateur portable avec 64 Go de mémoire
Après l’avoir essayé directement, même ce petit modèle a montré des performances extrêmement solides

Prompt d’entrée :

Saisie d’un prompt demandant d’écrire une page implémentant Space Invaders en HTML et JavaScript

Le modèle a mis un peu de temps à générer sa réponse, et ce résultat a été produit avec succès
Même s’il s’agit d’un exemple élémentaire, il est impressionnant qu’un ordinateur portable de 2,5 ans (MacBook Pro M2 avec 64 Go) ait pu générer du code abouti qui fonctionne dès la première tentative

Comment exécuter le modèle

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

  • Les poids du modèle, d’une taille de 44 Go, sont stockés dans le dossier ~/.cache/huggingface/hub/models--mlx-community--GLM-4.5-Air-3bit

  • La génération est lancée en saisissant le prompt comme suit

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
)
  • Pendant la génération, le modèle commence par résumer les exigences du problème et la conception du jeu
  • Il génère ensuite à bonne vitesse le code HTML, CSS et JavaScript réellement fonctionnel

Statistiques de génération

  • Prompt : 14 tokens, génération à 14.095 tokens par seconde

  • Corps : 4193 tokens, génération à 25.564 tokens par seconde

  • Utilisation mémoire maximale : 47.687 Go

  • L’historique complet de la conversation est disponible via le lien gist

  • Le code source généré peut être consulté dans cet exemple GitHub

  • Il est aussi possible de le tester directement dans le navigateur

Test sur le benchmark Pelican

  • Le benchmark pelican riding a bicycle a aussi servi à évaluer les capacités de génération d’images SVG du même modèle
  • Avec le prompt Generate an SVG of a pelican riding a bicycle, il a réussi à produire un code SVG créatif
  • Le modèle consomme jusqu’à environ 48 Go de RAM pour renvoyer le résultat
  • Il faut fermer certaines applications du portable pour libérer suffisamment de mémoire
  • La vitesse est elle aussi d’un niveau satisfaisant

Les progrès des modèles de code en local

  • En 2025, la plupart des grands modèles de langage se concentrent sur le renforcement des performances en génération de code
  • En conséquence, ils montrent des capacités de génération de code élevées réellement exploitables, même sur du matériel local
  • On s’approche d’un niveau qu’il était difficile d’imaginer lors des premiers essais avec LLaMA il y a deux ans
  • Sur le même ordinateur portable utilisé actuellement, il est déjà possible de profiter de modèles open source haute performance qui s’enchaînent, comme GLM-4.5 Air, Mistral 3.2 Small, Gemma 3 et Qwen 3
  • L’environnement de développement s’améliore avec l’arrivée, ces six derniers mois, de nombreux modèles de langage de haute qualité spécialisés dans le code et exécutables en local

À lire aussi

1 commentaires

 
GN⁺ 2025-07-30
Commentaires Hacker News

  • Quand j’ai découvert LLaMA pour la première fois il y a 2 ans, je n’aurais jamais imaginé voir tourner sur le portable que j’utilisais alors des modèles comme GLM 4.5 Air qu’on voit aujourd’hui (Gemma 3, Qwen 3, Mistral 3.2 Small, etc.). La qualité des modèles open et le rythme de leurs sorties ont largement dépassé mes attentes. Pour situer, quand ChatGPT est sorti en décembre 2022, les meilleurs modèles open disponibles à l’époque étaient GPT-J (environ 6~7B) et GPT-neoX (autour de 22B ?). J’ai même exploité un service utilisateur pendant presque un mois avec gpt-j, mais la qualité était catastrophique et il ne suivait pas du tout les consignes ; il fallait lui présenter les prompts comme une histoire ou écrire plusieurs exemples pour qu’il fasse à peu près ce qu’on voulait. Ensuite, le modèle LLaMA a "fuité" (à mon avis, de façon intentionnelle), et l’histoire a changé. À l’époque de L1, toutes sortes d’optimisations sont apparues, comme la quantification et le fine-tuning ; avec L2, le fine-tuning est vraiment devenu commercialisable (la plupart des fine-tunes étaient meilleurs que l’original de Meta), puis après la démo LoRA d’Alpaca, on a vu déferler des modèles extrêmement puissants comme Mistral, Mixtral, L3, Gemma, Qwen, DeepSeek, glm, Granite, etc. D’après certaines analyses, les modèles open n’ont qu’environ 6 mois de retard sur ceux publiés par les laboratoires à l’état de l’art (en supposant d’ailleurs que ces labos ne publient pas leurs meilleurs modèles et les gardent en interne, par exemple pour la curation des prochaines données d’entraînement). Un écart de 6 mois, c’est complètement fou. Je pensais qu’il faudrait environ 2 ans pour atteindre le niveau de gpt-3.5, et je n’aurais jamais imaginé qu’on en arriverait à faire tourner ces modèles en local et même à les fine-tuner soi-même

    • Pendant un moment, j’ai continué à poser des questions sur la façon de créer ou d’utiliser le fine-tuning LLM ou les LoRA (adaptation fine efficace en paramètres). Je n’ai jamais obtenu de réponse vraiment utile, et les recherches web ne renvoyaient que des articles SEO ou publicitaires. Je sais depuis 2 ans comment créer et utiliser des LoRA pour SD, et je maîtrise bien ça. Mais pour les LoRA de LLM, tout donne l’impression d’un secret soigneusement caché

    • Il est peu probable que Zuck (Mark Zuckerberg) l’ait lui-même leaké sur 4chan ou un site du même genre

    • Je me demande si GLM 4.5 est meilleur que Qwen3 coder

  • Je suis encore stupéfait qu’un MacBook Pro M2 avec 64 Go acheté il y a 2,5 ans puisse générer ce genre de code. Surtout qu’il a produit du code qui fonctionnait du premier coup, sans correction. J’ai l’impression qu’on sous-estime énormément le potentiel du matériel actuel. Je m’inquiète du fait que la "Bitter lesson" (la magie dépend des ressources de calcul) et la manière de penser en termes de "frontière du calcul efficace" éloignent au contraire les gens brillants qui voudraient explorer des approches innovantes. Quand on voit qu’après entraînement, les modèles gardent leurs performances même après une énorme réduction de la précision des poids, on peut se demander si le problème n’est pas plutôt l’inefficacité dans l’autre sens

    • Je me demandais si le cœur de la bitter lesson n’était pas surtout le fait qu’il faut une énorme quantité de données. Le modèle donné en exemple a en réalité été entraîné sur un corpus colossal de l’ordre de 22 billions de tokens

  • Je me demande s’il a compris le résultat de cette implémentation, ou s’il a seulement constaté que ça s’exécutait. J’imagine qu’un LLM peut aussi sortir une réponse à peu près correcte à une question d’entretien très classique. Quand des collègues présentaient des changements de données, ils ont utilisé un LLM pour créer une appli de visualisation JSON, et je me suis demandé pourquoi en refaire une alors qu’il existe déjà de très bons viewers JSON. J’ai l’impression que dans le travail réel, les gens utilisent surtout les LLM pour améliorer des présentations, et très peu comme outils destinés à un vrai usage. Un autre collègue avait besoin d’une macro pour modifier en masse du contenu pédagogique, et pour la créer, il a commencé par faire une rubrique de prompts pour LLM, puis il a résumé les exigences de la macro dans des slides de présentation avant de les redonner au LLM. Comme le système était devenu trop complexe, je ne pense pas qu’il ait réellement gagné du temps. Le résultat était intriguant, mais bien souvent inutile pour quiconque d’autre

    • J’ai parcouru le code pour comprendre ce qu’il faisait, mais si je me contente de vérifier qu’il fonctionne, je ne vais pas plus loin. Quand j’utilise un LLM pour du code de production, je vérifie chaque ligne. Je ne commit le code que quand je le comprends parfaitement, au point de pouvoir l’expliquer à quelqu’un d’autre. Il y a un article qui détaille très bien comment utiliser les LLM pour écrire du code en pratique
      https://simonwillison.net/2025/Mar/11/using-llms-for-code/

    • Le LLM est justement la solution elle-même

    • En réalité, le code jetable est précisément le domaine où l’IA montre toute sa valeur. Si elle peut générer d’elle-même du boilerplate absurde pour un système de build, du code d’animation, etc., tant mieux (quand on pense au travail que 3Blue1Brown a dû fournir pour ses animations, si l’IA peut aider là-dessus, je suis preneur). Le fait qu’une personne qui ne sait pas programmer puisse au moins produire un prototype et le transmettre ensuite à un développeur pro a une vraie valeur. On n’a pas besoin de comprendre tous les détails du code produit ; il suffit de juger si ça passe ou pas, donc l’utilité concrète est énorme. En revanche, les problèmes à "valeur de plusieurs millions" sont d’une autre nature : corriger des bugs dans un vrai service ou ajouter des fonctionnalités, et là l’IA atteint ses limites. D’un autre côté, le code jetable servait aussi d’outil de progression aux développeurs juniors, et c’est un point qui pose question maintenant que l’IA s’en empare

  • J’imagine que les données d’entraînement de ce modèle contenaient probablement énormément d’exemples de Space Invaders écrits dans diverses langues

    • Le vrai test, c’est de voir si le modèle peut répondre à des demandes d’implémentation plus précises comme : "modifie la fonction, fais en sorte que le vaisseau tire vers le bas, qu’il apparaisse depuis la gauche ou la droite, ajoute un mode 2 joueurs", etc.

    • Je pense aussi qu’une partie des données a probablement été générée synthétiquement à partir de jeux déjà présents dans le dataset, avec des modèles qui copient puis recombinent. Quand je regarde le code frontend React généré par les LLM, j’ai l’impression que tout finit par se ressembler

    • Cette discussion est réglée depuis 3 ans déjà. Depuis gpt3, tous les morceaux de code exploitables sont présents dans les données d’entraînement, et en seulement 2 ans on est passé de "le code a l’air correct, mais en réalité tout est faux" à "une appli full-stack qui tourne correctement en 0-shot sort d’un coup". Le moteur de ce saut spectaculaire, ce n’est pas simplement le dataset, mais le post-training, le reinforcement learning (RL), les longs contextes, les comportements agentiques, etc. Les premiers modèles étaient limités à 2/4k tokens, mais aujourd’hui la situation a complètement changé. Réduire ça à une simple question de données, sans cette perspective, c’est passer complètement à côté du sujet

    • La ressemblance visuelle avec le jeu breakout est intéressante

    • Ce genre de commentaire a lui aussi de fortes chances de n’être qu’un commentaire synthétique du même type, sans vraie analyse, présent d’innombrables fois dans les données d’entraînement

  • J’ai un Mac M4 avec 128 Go de RAM, et je télécharge en ce moment GLM-4.5-Air-q5-hi-mlx (80 Go) via LM Studio. Je partagerai bientôt les résultats

  • Je pense qu’il y a quelque chose d’important dans le fait de montrer qu’un LLM peut tourner localement sur un portable. Autrefois, ce genre de chose était presque impossible avec de petits modèles, donc c’est une vraie étape marquante. Cela dit, pour un domaine aussi spécifique et étroit que Space Invaders, il serait probablement plus efficace d’aller chercher puis télécharger une implémentation existante sur GitHub ou ailleurs. Dans ce cas, l’ensemble d’entraînement lui-même est forcément minuscule, et l’espace vectoriel du modèle ne peut couvrir qu’un périmètre limité ; il y a donc de fortes chances que le code produit soit presque identique à l’original, voire un simple copier-coller. En plus, il faut attendre que le modèle tape, donc la valeur ajoutée est très faible. J’aurais plutôt envie de demander au LLM : "trouve-moi un code source existant de Space Invaders écrit en langage X sur GitHub". Ce qui est drôle, c’est que quand on confie ce genre de tri de code à ChatGPT, il tend à répéter que "le surapprentissage est quasiment absent et que le modèle ne mémorise pas" (personnellement, je ne crois pas beaucoup à l’une ni à l’autre de ces affirmations)

    • Je n’ai pas réussi à reproduire ce message d’avertissement dans ChatGPT. En fait, l’insertion de ce genre d’avertissement implique une force politique importante (directement ou via une légère reformulation), et je trouve ça très intéressant

  • J’ai essayé avec Claude Sonnet 4, mais ça ne fonctionne pas correctement. GLM-4.5 Air quantifié en 3 bits fait donc mieux. Historique du chat associé : https://claude.ai/share/dc9eccbf-b34a-4e2b-af86-ec2dd83687ea Claude Opus 4 fonctionne lui aussi, mais reste très loin derrière le GLM-4.5 publié par Simon : https://claude.ai/share/5ddc0e94-3429-4c35-ad3f-2c9a2499fb5d

  • Au début, j’avais mal lu le titre comme : "Mon enfant de 2,5 ans écrit maintenant Space Invaders en JavaScript (GLM-4.5 Air)". Mais dans quelques années, ce sera peut-être vraiment possible

  • Cette discussion soulève une question de science-fiction intéressante. Si le binaire d’une intelligence artificielle future tombait d’un trou de ver sur le matériel grand public d’aujourd’hui, pourrait-on exécuter cette superintelligence, ou au moins un agent faible (ou se bootstrapper elle-même sur d’autres machines via le réseau ou par persuasion) ?

    • C’est précisément l’hypothèse de base de toutes mes recherches en ML jusqu’ici. Il suffit de remplacer "trou de ver" par "programmation génétique / neuroévolution / etc.", et c’est la même idée. Les logiciels de la demoscene poussés à l’extrême optimisation m’ont conduit sur cette voie. La question que je continue à me poser aujourd’hui est : "quelle serait la complexité de Kolmogorov d’un binaire offrant toutes les capacités des LLM de la génération actuelle ?" Si cette taille (ou complexité) permettait de l’exécuter sur mon desktop actuel, à quoi cela ressemblerait-il ? Mon PC affiche des jeux AAA à 400 fps, et j’ai du mal à croire qu’il puisse y avoir un tel écart avec un LLM qui crache du texte en utf-8 à 100 b/s

    • C’est exactement la partie que je trouve vraiment fascinante. Combien de capacités latentes existent, et jusqu’où peut-on pousser leur exploitation ? Et qu’en serait-il avec un matériel exotique ou nouveau ? Nous travaillons surtout en introduisant des abstractions à cause des limites du cerveau humain. À cause de ces abstractions, nous nous concentrons sur des zones étroites ; or ces abstractions ont un coût élevé, et je me demande quel est le potentiel lorsqu’on supprime cette limite

  • Je me demande s’il existe un site qui récapitule le matériel minimum/recommandé pour faire tourner des LLM en local (un peu comme des "configurations requises" pour les jeux)

    • Avec LM Studio (et d’autres outils aussi), il est très facile de choisir un modèle adapté aux performances de son matériel

    • En plus des autres réponses, une bonne règle empirique est que la plupart des modèles locaux offrent leur meilleur rapport performance/ressources en quantification q4 (il faut en mémoire un peu plus de la moitié de la taille correspondant au nombre de paramètres du modèle). Par exemple, pour un modèle 14B, il faut environ 8 Go, auxquels il faut ajouter la capacité de contexte ; pour un 14B, autour de 10 Go de VRAM est donc une base raisonnable. Si vous avez encore de la marge en q4, vous pouvez prendre un modèle avec plus de paramètres ; sinon, il faut passer à une quantification plus petite

    • Il y a aussi des ressources ici
      https://www.reddit.com/r/LocalLLaMA/

    • Je trouve ce site très utile
      https://apxml.com/tools/vram-calculator

    • Si vous avez un compte HuggingFace, vous pouvez enregistrer les caractéristiques de votre matériel et vérifier immédiatement, pour chaque modèle, s’il peut tourner dessus