2.5年前の自分のノートPCがJavaScriptでSpace Invadersを書くようになった（GLM-4.5 Air）

 (simonwillison.net)
3 ポイント 投稿者 GN⁺ 2025-07-30 | 1件のコメント | WhatsAppで共有
  • 2.5年前の MacBook Pro M2 で GLM-4.5 Air 3bitモデル を使い、Space Invaders のゲームコードを一発で生成
  • このモデルは 中国のZ.aiがMITライセンスで公開 した最新の open weight モデルで、コーディングベンチマークで優れた性能を示す
  • 44GB の 3bit 量子化版 により、64GB RAM のPCでも実行可能
  • ml-explore/mlx-lm ライブラリ を最新コミットで使ってローカルでモデルを動かし、比較的 高速 かつ安定した動作を体験
  • 最近リリースされた ローカルコーディング特化の大規模言語モデル は非常に高いコード生成能力を示しており、急速に進化中

GLM-4.5 Air と MLX で JavaScript の Space Invaders を生成した体験

2025年7月29日

昨日紹介した GLM-4.5 モデルファミリーは、中国のZ.aiがMITライセンスで公開した最新の高性能 open weight モデルである。
コーディングベンチマークでは Claude Sonnet 4 のような既存モデルと比べても、高い性能を示すと評価されている。

最も小さい GLM-4.5 Air モデルでも、総計1060億パラメータ、約206GBのサイズを持つ。
Ivan Fioravanti が MLX で動かせるよう 3bitで44GBに量子化 した版を公開しており、64GBメモリのノートPCでも実行できる。
実際に試してみると、この小さなモデルでさえ非常に強力な性能を見せた。

入力プロンプト:

HTMLとJavaScriptでSpace Invadersを実装したページを書くよう求めるプロンプトを入力

モデルが応答を生成するまで少し時間がかかったが、この成果物 の出力には成功した。
初歩的な例ではあるものの、2.5年前のノートPC（64GB MacBook Pro M2）で、最初の試行でそのまま動く完成度の高いコードを直接生成したのは印象的だった。

モデルの実行方法

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

  • 44GB のモデル重みは ~/.cache/huggingface/hub/models--mlx-community--GLM-4.5-Air-3bit フォルダに保存される

  • 次のようにプロンプトを入力して生成を実行する

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
)
  • 生成過程では、まず問題の要件とゲーム設計の情報を整理して出力する
  • 続いて、実際に動作する HTML、CSS、JavaScript コードを高速に生成する

生成統計

  • プロンプト: 14トークン、毎秒14.095トークン生成

  • 本文生成: 4193トークン、毎秒25.564トークン生成

  • 最大メモリ使用量: 47.687GB

  • 全対話ログは gist リンク

  • 出力ソースは GitHub サンプル で確認できる

  • ブラウザで直接 動作テスト も可能

ペリカンベンチマークのテスト

  • pelican riding a bicycle ベンチマークで、同モデルの SVG画像生成能力 も評価した
  • Generate an SVG of a pelican riding a bicycle というプロンプトで、創造的な SVG 画像コードの生成に成功
  • モデルは最大約48GBのRAMを消費しながら結果を返した
  • 十分なメモリを確保するには、ノートPC上で一部のアプリを終了する必要があった
  • 速度も満足できる水準だった

ローカルコーディングモデルの進化

  • 2025年に入ってから、大半の大規模言語モデルは コード生成性能の強化 に注力している
  • その結果、ローカルハードウェアでも実用可能な 高いコード生成能力 を示している
  • 2年前に LLaMA を最初に試した頃には想像しにくかった水準に近づいている
  • 現在使っている同じノートPCでも、GLM-4.5 Air、Mistral 3.2 Small、Gemma 3、Qwen 3 など、次々と登場する高性能オープンソースモデルの恩恵を受けられる
  • この6か月ほどで、ローカルで動作するさまざまな 高品質なコーディング特化言語モデル が登場し、開発環境が改善されている

関連記事

1件のコメント

 
GN⁺ 2025-07-30
Hacker Newsの意見

  • 2年前にLLaMAに初めて触れたときは、当時使っていたノートPCで、今見ているGLM 4.5 Airのようなモデルたち（Gemma 3、Qwen 3、Mistral 3.2 Smallなど）が動く姿なんて想像もできなかった。オープンモデルの品質もリリース速度も、どちらも自分の予想をはるかに超えている。ちなみにChatGPTが22年12月に出た頃、当時存在していた最高のオープンモデルはGPT-J（約6〜7B）とGPT-neoX（22Bくらい？）だった。実際、ほぼ1か月gpt-jでユーザー向けサービスを運用したことがあるが、品質はひどく、命令にはまったく従わず、プロンプトを物語のように書いたり例をいくつも並べたりして、ようやく動くレベルだった。その後、LLaMAモデルが「リーク」されて（おそらく意図的なリークだと思っている）、歴史が変わった。L1時代には量子化やファインチューニングなど、さまざまな最適化が登場し、L2ではファインチューニングが本格的に商用化された（ほとんどのファインチューンはMetaの原版より良かった）。AlpacaのLoRAデモ以降、Mistral、Mixtral、L3、Gemma、Qwen、DeepSeek、glm、Graniteなど、非常に強力なモデルが次々に登場した。ある分析によれば、オープンモデルはSotA研究所がリリースするモデルに対しておよそ6か月遅れだという（ちなみに研究所では最高のモデルは公開せず、次の学習用データのキュレーションなどに内部利用していると推測される）。6か月差というのは本当に狂っている。gpt-3.5級に届くまで2年くらいかかると思っていたのに、こうしてローカルでこのモデルを動かし、ファインチューニングまで自分でできる時代が来るとは思わなかった

    • LLMのファインチューニングやLoRA（パラメータ効率の高い微調整）をどう作るのか、あるいはどう使うのかについて、しばらくずっと質問していた。実際に役立つ答えは聞けず、Web検索の結果はSEO目的や広告っぽい記事ばかりだった。SD LoRAの作り方と使い方は2年前から知っていて、よく扱っている。なのにLLM LoRAだけは、すべてが隠された秘密のように感じる

    • Zuck（マーク・ザッカーバーグ）が自ら4chanのような場所にリークしたわけではないだろう

    • GLM 4.5がQwen3 coderより優れているのか気になる

  • 2.5年前に買った64GBのMacBook Pro M2で、こういうコード生成ができるという事実に今でも驚く。しかも修正なしで一発で動くコードが出てきた。現在のハードウェアがどれほどすごい潜在力を持っているか、私たちはあまりに過小評価している気がする。「Bitter lesson」（魔法は計算資源に依存する）や「効率的計算境界」という考え方が、革新的なアプローチを探ろうとする優秀な人材を、かえって遠ざけているのではないかと心配している。実際、今のモデルは学習後に重みの精度を大幅に下げても性能が残っているのを見ると、むしろ今のほうが非効率なのではないかと思えてくる

    • bitter lessonの要点は、データ量が多くなければならないということではなかったか。例に挙がっているモデルも、実際には22兆トークンのような巨大コーパスで訓練されている

  • その実装結果を理解したのか、それとも単に動いたという点だけを見たのか気になる。LLMでも、よくある面接質問にはそれっぽい正答を出せる気がする。同僚たちがデータ変更内容をプレゼンするとき、JSON可視化アプリをLLMで作ったのだが、すでによく動くJSONビューアーがあるのに、わざわざ新しく作る意味があるのか疑問だった。実務では、人々はLLMを主にプレゼン強化のために使っていて、実用のためのツールとしてはほとんど使っていないように見える。別の同僚は、大量の教材コンテンツを修正するためのマクロが必要だったのだが、それを作るためにまずLLMプロンプト用のルーブリックを作り、その後でプレゼン用スライドにマクロ要件をまとめて、再度LLMに投げていた。システムがあまりに複雑すぎて、実際に時間が節約できたとは思えない。成果物は面白かったが、結局ほかの人には何の役にも立たないことが多かった

    • 私はコードをざっと読んで、どういう動作なのかは把握したが、実際に動くことを確認しただけなら、それ以上は深く見ない。LLMで本番用コードを書くときは、1行1行すべて確認するようにしている。ほかの人に説明できるくらい完全に理解したときだけコードをcommitする。LLMを実戦的なコード作成にどう活用したかを詳しくまとめた記事がある
      https://simonwillison.net/2025/Mar/11/using-llms-for-code/

    • LLMそのものが、まさにそのソリューションだ

    • 実際、使い捨てコード（Disposable code）こそ、AIが真価を発揮する分野だ。ばかばかしいビルドシステム向けのボイラープレートや、アニメーションコードなどを勝手に作ってくれるなら大歓迎だ（3Blue1Brownがアニメーション制作に注いだ労力を思えば、AIがそこを助けられるなら強く推したい）。プログラミングを知らない人でも、少なくともプロトタイプを作ってプロの開発者に渡せるようになったのは本当に大きな価値だ。結果コードの細部を理解する必要はなく、合格か不合格かだけ判断すればよいので、実質的な有用性が非常に高い。ただし、「億単位の価値」を持つ問題はこれとは別で、実サービスのバグ修正や機能追加のような領域では、AIは限界にぶつかる。とはいえ、使い捨てコードはもともとジュニア開発者の成長の場でもあったので、それをAIが奪ってしまったのは悩ましい点だ

  • そのモデルのトレーニングデータには、おそらくさまざまな言語で書かれたSpace Invadersが大量に含まれていたのだろうと推測する

    • 本当のテストは、「関数を修正して、宇宙船が下向きに撃つようにして、左右から出現するようにして、2人モードを追加して」といった細かな実装要求にもモデルが対応できるかを見ることだ

    • おそらく一部のデータは、すでにデータセット内にあるゲームをモデルがコピーして合成データにしたものも多いのではないか。LLMが生成するReactフロントエンドコードを見ると、どれも似たようなものになる印象がある

    • この議論はもう3年前から決着している話だ。gpt3以降は利用可能なコードがすべて学習データに入っている状態で、「コードは正しそうに見えるが実際には全部間違っている」段階から、「0-shotでちゃんと動くフルスタックアプリがさっと生成される」段階まで、わずか2年で到達した。飛躍的進歩の鍵は、単なるデータセットではなく、事後学習（post-training）、強化学習（RL）、長いコンテキスト、エージェント的な振る舞いなどにある。初期モデルには2/4kトークンという制約があったが、今はもうまったく様相が違う。こういう視点なしに単純にデータの話だけをするのは、論点を完全に外している

    • breakoutゲームとのビジュアル上の類似性が興味深い

    • こういうコメントですら、結局は似たような本物の分析のない合成コメントが学習データに無数に入っている可能性が高い

  • M4 Macに128GB RAMを積んでいて、今GLM-4.5-Air-q5-hi-mlx（80GB）をLM Studioでダウンロード中だ。近いうちに結果を共有するつもり

  • LLMがノートPCでローカルに動くことをショーケースするのは大きな意味があると思う。以前は小さなモデルではこういうことはほぼ不可能だったのだから、本当に重要な節目だ。ただし、Space Invadersのような特殊で狭いドメインなら、むしろGitHubなどで既存実装を探して落としてくるほうが効率的だと思う。こういうケースでは、トレーニングセット自体が極めて小さく、モデルのベクトル空間も範囲が限られているはずなので、生成されたコードがほぼ元の実装に近いか、コピペ同然である可能性が高い。しかもモデルがタイピングする速度を待たなければならず、付加価値は非常に低い。むしろLLMに「言語Xで書かれた既存のSpace InvadersソースをGitHubで探して」と頼むほうが賢い気がする。ChatGPTにこういうコード整理を任せると、LLMは「過学習はほとんどなく、モデルは暗記もしていない」という主張を繰り返す方向に誘導しようとするのが面白い（自分としてはそのどちらもあまり信じていない）

    • ChatGPTでその警告メッセージを再現できなかった。実際、こういう形で警告を差し込むことには政治的な力が強く働いているのだが（直接的であれ少し再構成されたものであれ）、それがとても興味深い

  • Claude Sonnet 4で試してみたが、きちんと動かなかった。3bit量子化したGLM-4.5 Airのほうが上だったわけだ。関連するチャット履歴: https://claude.ai/share/dc9eccbf-b34a-4e2b-af86-ec2dd83687ea Claude Opus 4も動きはしたが、Simonが投稿したGLM-4.5と比べるとかなり見劣りする: https://claude.ai/share/5ddc0e94-3429-4c35-ad3f-2c9a2499fb5d

  • 最初、タイトルを「2.5歳のうちの子が今やJavaScriptでSpace Invadersを作る（GLM-4.5 Air）」と読み違えていた。でも数年後には本当に可能になっているかもしれない

  • この議論は、興味深いSF的な問いを思い起こさせる。現代のコンシューマ向けハードウェアに、未来の人工知能のバイナリがワームホールから落ちてきたとしたら、その超知能、あるいは少なくとも弱いエージェントくらいなら実行できるのだろうか（あるいはネットワークや説得力を使って、別のハードウェア上で自力でブートストラップできるのだろうか）

    • これこそ、今までの自分のML研究の基本前提だ。「ワームホール」を「遺伝的プログラミング／ニューロエボリューションなど」に置き換えれば同じことだ。demosceneの極限最適化ソフトウェアが、この道に自分を導いた。最近ずっと自分が問い続けているのは、「現世代のLLMの全機能を同等に提供するバイナリのコルモゴロフ複雑性はどれくらいだろうか？」ということだ。もしそのサイズ（複雑性）が今の自分のデスクトップで実行可能なら、どんな景色が見えるのだろう。自分のPCはAAAゲームを400fpsで動かせるのに、LLMはutf-8テキストを100b/sで吐き出すだけという、この差がここまで大きいはずはないと信じている

    • ここが本当に興味深い。隠れた能力がどれほどあるのか、そしてそれをさらに極限までどう活用できるのか。さらに、それが異質で新しいハードウェアだったらどうなるのか。私たちは主に人間の脳の限界のために抽象化を導入して仕事をしている。その抽象化のせいで狭い領域に集中する形になっているが、抽象化には大きなコストがあり、その制約を取り払ったときの潜在力が気になる

  • ローカルLLM実行向けの最小／推奨ハードウェアを整理したサイトがあるのか気になる（ゲームの「システム要件」のような文書があるのか）

    • LM Studio（ほかにもいろいろなツールはあるが）では、ハードウェア性能に合ったモデルを選ぶのがとても簡単だ

    • ほかの回答に加えるなら、良い経験則として、たいていのローカルモデルはq4量子化で最適なパフォーマンスを示す（モデルパラメータ数の半分強の容量がメモリとして必要になる）。たとえば14Bモデルなら約8GBで、これにcontext容量を加えると、14Bモデルには10GB VRAM程度が妥当なラインになる。q4で余裕があるならより大きなパラメータモデルを使い、余裕がないならさらに小さい量子化にする、という進め方が無難だ

    • ここも参考になる
      https://www.reddit.com/r/LocalLLaMA/

    • このサイトは非常に役立つと思う
      https://apxml.com/tools/vram-calculator

    • HuggingFaceのアカウントがあれば、保有ハードウェア情報を登録することで、各モデルが実行可能かすぐ確認できる