【geek-terminalニュース】744B MoEを25GB RAMで動かす？ローカルLLM省メモリ限界突破ログ

【事象の全貌と背景】
以前お伝えしたMiniMax巨大MoE、GLM-5.2の実運用評価、そしてNVIDIA Puzzle-75B-A9Bの続報です。今回の主役は、単一の新モデル発表ではありません。LocalLLaMA周辺で同時多発的に出てきた、巨大MoEを個人環境に無理やり近づける省メモリ実装と推論効率ハックです。中心にあるのは、GLM-5.2の744B級MoEを25GB RAMのconsumer machineで動かすというReddit発の話題、Qwen3.6 NVFP4/Unsloth量子化をめぐる「2.5x faster」報告、そしてユーザー入力中にKV cacheを先読みで温めるspeculative cache warmingです。

ここで最初に線を引くべきなのは、公式に確認できる事実とコミュニティ報告の境目です。公式・準公式に確認できる範囲では、NVIDIA NIMのモデル一覧にGLM-5.2が掲載され、agentic workflow、coding、long-horizon reasoning向けのflagship LLMとして扱われています。またNVIDIA Developer Forums上では、GB10/DGX Spark系の環境でGLM-5.2を動かす投稿や、256K context、decode速度に関する議論が見えます。ただし、744Bという総パラメータ数、2-bit量子化時の必要メモリ、25GB RAM consumer machineでの具体的な実行条件は、提示された公式系ソースだけでは検証済み事実として断定できません。したがって本件は「公式発表された省メモリ版GLM」ではなく、「ローカルLLMコミュニティが巨大MoEの現実的な運用限界を押し下げようとしているログ」として読むのが正確です。

【技術的ディープダイブ】
GLM-5.2の744B MoEを25GB RAMで、という表現は刺激的ですが、ここで起きているのはモデル全体が25GBに魔法のように収まったという話ではありません。コミュニティと周辺解説で語られている要点は、MoEのactive parameter特性、2-bit級の極端な量子化、CPU/RAM/SSDオフロード、複数GPU構成、長文コンテキスト時のKV cache管理を組み合わせ、限られたVRAMでも巨大モデルの一部を逐次的に扱う方向です。7minAI系の解説では、最小級の実用quantでも約239GBが必要とされ、2-bit buildなら256GB Macや24GB GPU＋オフロード構成で扱える可能性がある、という文脈で説明されています。これは「軽い」ではなく、「遅くてもいいなら動作域に近づく」という意味に近いです。

MoEでは総パラメータ数と推論時に実際に使うactive parametersが一致しません。このため744Bという数字だけを見ると絶望的でも、各トークンで使う専門家の数、ルーティング、量子化精度、メモリ転送設計次第で、個人環境にも実験余地が出ます。ただし、VRAMが足りなければCPU RAMやSSDから重みを引き回すため、ボトルネックは計算からメモリ帯域とI/Oに移ります。Hacker Newsでも、4bitなら500GB未満で可能という見方や、active parametersをディスクからストリーミングすれば単一MacBookでも理論上は動くが、speculative decoding込みでも1 token/s程度ではないか、という冷めた見積もりが出ています。

Qwen3.6 NVFP4/Unsloth側の話題は、巨大MoEとは逆方向から同じ問題を叩いています。中小型モデルを低ビット化し、NVFP4のような形式やUnslothの量子化で速度と容量を詰める流れです。Redditでは「2.5x faster Qwen3.6 NVFP4 Unsloth quants」という形で注目されていますが、これも公式ベンチとして断定するのではなく、ユーザー報告ベースの高速化議論として扱うべきです。さらにspeculative cache warmingは、ユーザーが入力している間に候補プロンプトや既存文脈のprefillを先に進め、送信後の待ち時間を短く見せる発想です。744B級や長文コンテキストではprefillが重くなるため、decode速度だけでなく「待つ場所」をずらすUXレイヤーの最適化が重要になります。

【コミュニティの生々しい熱量と議論】
この話題が面白いのは、夢と現実の温度差がそのままログに残っている点です。RedditのGLM-5.2スレッドでは「744B MoE on a 25GB-RAM consumer machine」という見出しだけで、ローカルLLM勢の神経を直撃しています。反応のひとつは短く、「We’re probably going to need that soon.」というもの。今は奇行に見えても、半年後には普通の最適化項目になっているかもしれない、というローカルLLM界隈らしい感覚です。

一方でHacker News側はかなり現実的です。simonwは、GLM-5.2級は今日の128GB級マシンでは走らず、1TB+ RAMが必要になるとしつつ、同じ64GBや128GBで動くモデルの品質は半年前より大きく改善した、と整理しています。johndoughは、4bit量子化なら500GB未満という見立てを出しつつ、128GB MacBookを複数つなげば動くかもしれない、ただしディスクストリーミングでは実用速度は厳しい、という笑いと現実が半分ずつ混ざったコメントをしています。

Qwen側でも熱量は高いです。あるユーザーはQwen 3.6 35B-A3Bを常用しているが、報告されている挙動は見ていないと述べ、UnslothのQ8_K_XL quantを使っていると具体的な構成を出しています。別のユーザーはQwen 3.6 27/35のNVFP4 quantをベンチしたうえで、fp8/bf16との差はわずかだったとし、DGX Spark系におけるNVFP4対応こそが面白いと見ています。つまり議論の芯は「すごいモデルが出た」ではなく、「どのquantなら品質劣化を許容できるか」「どのハードなら帯域が足りるか」「どこからがベンチで、どこからが常用か」です。

【今後の展望とエコシステムへの影響】
今回の流れが示すパラダイムシフトは、ローカルLLMの競争軸がモデル名から実行計画へ移っていることです。744B MoE、75B A9B、Qwen3.6 NVFP4、KV cache warmingは別々のニュースに見えますが、実際には同じ問いに答えています。巨大化したモデルを、限られたVRAM、電力、冷却、PCIe、RAM、SSD、予算の中でどう扱うのか。ここで古くなるのは「パラメータ数だけでモデルを語る見方」です。今後は総パラメータ、active parameters、quant形式、prefill速度、decode速度、KV cache効率、オフロード時の実効帯域、同時ユーザー数まで含めた運用プロファイルが重要になります。

NVIDIA Puzzle-75B-A9Bの文脈もここにつながります。MarkTechPostが紹介したNemotron Labs 3 Puzzle 75B A9Bは、744B級そのものではありませんが、Nemotron-3-Superのような大型hybrid MoEがactive parameters、KV cache、Mamba stateで同時ユーザー数を制限される課題を背景に、圧縮hybrid MoEとして位置づけられています。同等のユーザー当たりスループット条件で2.03倍のサーバースループットとされる点は、ローカルLLMだけでなく配信側にも効く設計思想です。

結論として、今回の744B省メモリ騒動は「25GBで744Bが普通に動く」という勝利宣言ではありません。むしろ、ローカルLLM界隈が巨大MoE時代の現実にぶつかり、量子化、疎性、キャッシュ再利用、先読み、オフロード、複数GPU、大容量統合メモリを組み合わせて、強引に実験可能域を広げているという話です。クラウドAPIが安くなる未来を待つのか、自分の机の下で1 token/sでも巨大モデルを動かすのか。この狂った選択肢が真面目に議論されている時点で、ローカルLLMはまだ終わっていません。むしろ、ここからが運用ハックの本番です。