【geek-terminalニュース】Kimi K3を29GB RAMで動かすWASTE疑惑、LocalLLaMAがまた限界突破へ

【事象の全貌と背景】
以前お伝えしたKimi K3の重み公開・分散推論騒動の続報です。今回の焦点は、Kimi K3そのものの公開ではなく、Weight-Aware Streaming Tensor Engine、略してWASTEと呼ばれる実行エンジンが、Kimi K3を29GB RAMで動かすというコミュニティ発の主張に移っています。ここは表現を厳密に分ける必要があります。公式・大手メディア側で確認できるのは、Moonshot AIがKimi系モデルを開発しており、Kimi-K3開発や計算資源拡大に向けた資金調達文脈がある、という範囲までです。一方で、WASTEが29GB RAMでKimi K3を実行した、速度が0.50 tokens/secだった、という核心部分は公式に独立検証された事実ではなく、現時点ではLocalLLaMA周辺で先行している未確認の技術デモとして扱うべきです。

それでもこの話がギークに刺さる理由は明快です。Kimi K3は、周辺情報では2.8兆パラメータ級、active parametersは104B級と語られ、重みサイズも594GB、あるいはMXFP4形式96シャードで1.56TBダウンロードといった数字が出ています。ソース間で公開日や容量表記に食い違いがあるため断定は避けますが、少なくともコミュニティ上では「普通のローカル環境でまともに読む対象ではない巨大MoE」として受け止められています。これまでの議論は、80枚級RTX 5090、B300複数枚、A100/H200クラスタ、あるいはデータセンター級推論基盤が前提でした。そこに突然、「速くなくていい、29GB RAMでも動作に到達する」という方向の話が出てきた。これは性能競争ではなく、到達可能性のハックです。

【技術的ディープダイブ】
WASTEの名前が示すWeight-Aware Streaming Tensor Engineという発想は、全重みをRAMやVRAMへ常駐させるのではなく、必要な重みをストレージや低速メモリ階層から流し込みながら推論する設計だと推測されます。ただし、実装の詳細、対象量子化、CPU/GPU構成、ストレージ帯域、コンテキスト長、精度劣化、ベンチマーク条件は、提示された情報だけでは確認できません。したがって「Kimi K3が誰のPCでも快適に動くようになった」とは絶対に言えません。PulseAugurの要約では、最小29GB RAM、速度0.50 tokens/secという数字が示されていますが、これは実用的な高速推論というより、「巨大MoEを低RAM環境でプロセスとして成立させる」ことを示す実験に近いと見るべきです。

MoEでは、総パラメータが巨大でも各トークンで使う専門家は一部です。コミュニティで語られる104B active parametersという数字が正しければ、2.8T全体を毎トークン計算するわけではないものの、ルーティングされた専門家の重みをどこに置くかが最大のボトルネックになります。VRAMに載らないならRAM、RAMに載らないならNVMe、さらに足りなければ動的なページングやキャッシュ戦略に頼ることになります。ここで重要なのは、帯域だけでなくランダムリードのレイテンシです。MXFP4でもQ1でも、必要な専門家重みが頻繁にページフォルトを起こすなら、1bitか4bitか以前に、待ち時間が推論速度を支配します。

従来のローカル実行記事では、Kimi K3はMac StudioやゲーミングPC、マルチGPUワークステーションでも現実的には厳しく、データセンター級環境が必要だと説明されています。その前提から見ると、29GB RAMという主張は要件を下げたというより、計算を高速にする設計から、ストレージ階層まで含めて「巨大モデルを遅延実行する」設計へ問題設定を変えたものです。0.50 tokens/secなら、チャット用途ではかなり苦しい。だが、バッチで1日回して長文推論を少量吐かせる、研究目的で挙動を見る、量子化やキャッシュ戦略を比較する、といった使い方なら意味が出てきます。

【コミュニティの生々しい熱量と議論】
LocalLLaMAの反応は、この手の話題らしく半分は狂気、半分は真面目なシステム設計です。Kimi K3の重み公開時点から「my 512mb integrated graphics is so fucking ready」「My C64 is all fired up!」「How do I download ram in hugging face?」のような自虐ジョークが飛び交っていました。巨大モデルを前に、誰もが無理だと分かっているのに、とりあえず自分の古いGPUやノートPCを差し出すノリです。この温度感こそLocalLLaMAで、スペック表ではなく、限界をどう騙すかが娯楽になっています。

一方で議論はかなり実務的です。「I wonder if we can get it running from raid0 nvme drives with like 1 tok/sec」という声や、「NVMe offload + a dynamic Q1 is probably the only way this runs outside 8-GPU rigs」という見立てが出ています。つまり、WASTE的な方向性は単なるネタではなく、NVMeオフロード、動的Q1、専門家キャッシュ、RAM常駐比率、プリフィルとデコードの分離といった具体的な最適化問題として受け止められています。別のユーザーは、HDD速度なら最初のトークンがK4の頃に来る、という冗談でレイテンシ地獄を表現していましたが、これも本質を突いています。巨大MoEの低RAM実行で死ぬのは、平均帯域だけではなく、層ごとの専門家読み出しです。

ハードウェア談義も濃いです。B300を8枚、MI355Xを8枚、Gaudi 2/3、A100を絞り切る運用、768GB RAMの中古サーバー、Optaneを冷ストレージにする構成など、一般消費者向けという言葉からは遠い構成が次々に出ています。面白いのは、そこで「だから無理」と終わらず、「1-2 tok/sなら複数NVMeで行けるかもしれない」「100k tokens/24 hoursなら用途によっては意味がある」と考える人がいることです。速度の快適さではなく、24時間あたりの生成量、実験可能性、所有できる推論経路を評価軸にしているわけです。

【今後の展望とエコシステムへの影響】
今回のWASTE騒動が本当に重要なのは、29GB RAMという数字そのものではありません。むしろ、巨大オープンウェイトMoEに対するローカル勢の発想が、「全部VRAMに載せる」から「重みを流す、専門家を温める、遅くても動かす」へ広がっている点です。もしこの方向が洗練されれば、巨大モデル運用の裾野は少し変わります。リアルタイムチャットは小型蒸留モデル、重い検証や難問だけ巨大MoEを低速バッチで叩く、という二層運用が現実味を帯びます。

一方で、オワコンになる可能性があるのは「VRAM容量だけを絶対条件にする単純なローカル推論観」です。もちろんVRAMは依然として正義です。高速に使うならGPUメモリ帯域と容量は避けられません。しかし、巨大MoEでは全重み常駐を前提にしない実行エンジン、量子化、NVMe階層、CPUメモリ、専門家ルーティング最適化が同じくらい重要になります。これはllama.cpp的なローカル実行文化が、単なる軽量モデル実行から、巨大モデル用OSに近い領域へ進む兆候でもあります。

ただし、現時点で読者が取るべき態度は冷静でいいです。WASTEの29GB RAM実行や0.50 tokens/secは、公式に検証されたFactではなく、コミュニティで騒がれている未確認の実行ハックです。再現条件が出そろうまでは、実用品というより技術デモとして見るべきです。それでも価値はあります。なぜなら、Kimi K3級のモデルを「クラウドか超高額クラスタでしか触れない対象」から、「遅くても手元のシステム設計で触れるかもしれない対象」へ変える発想だからです。ローカルLLMの進歩は、いつも快適な速度から始まるわけではありません。まず無理やり動かし、次に1 tok/sを目指し、最後に使える形へ削っていく。WASTEが本物なら、その最初の一歩としてかなりギークな事件です。