あるエンジニアが、中国産AIのフラグシップモデルである「Kimi K3」を29GBのメモリ（一般的なPCの全メモリ容量に相当）に無理やり押し込みました。動作自体は成功したものの、「イタリアの首都はどこ？」と尋ねると、31秒間思考した末にわずか16文字の回答を出力するにとどまりました。
図：Kimi K3、Moonshot AIが7月末にオープンソース化した最新フラグシップモデル。出典：github.com/MoonshotAI
この出来事はここ数日、エンジニアコミュニティで大きな話題となっています。Hacker Newsでは130以上のVoteと50件以上のコメントが集まり、称賛と懐疑の声が半々に分かれています。技術背景に詳しくない読者に向けて、両者の意見や技術的背景を分かりやすく整理しました。
なぜモデルはこれほどメモリを消費するのか
まず根本的な疑問として、Kimi K3がどれほど巨大なモデルなのかを確認しておきましょう。
Kimi K3は、Moonshot AIが2026年7月末に全パラメータを公開した最新フラグシップモデルです。K3のパラメータ数は実に2.78兆個に達します。
パラメータとは、モデルの「頭脳」に記録された数値の集まりと捉えることができます。AIの高度な知能は海量な数値の計算によって成り立っており、一般に数値が多いほど賢くなりますが、その分占有する容量も増大します。2.78兆個の数値を記録した公式リリース版（FP4圧縮済）でも1.42TBあり、通常の1TB SSD1台には収まりきりません。
モデルが回答を生成するたび、これらの数値をすべてメモリ（PCの作業領域）に読み込んで計算する必要があります。1.42TBのデータを29GBのメモリ空間に押し込もうとすると、およそ50倍もの容量不足が生じます。
そのため、この規模のモデルは本来、数十万台規模のサーバーや多数のGPUを揃え、TB単位のメモリを備えたクラウドデータセンターでしか動作しません。アプリ経由で質問を送ると、向こう側の大型計算資源で処理された結果が送られてくる仕組みです。
なぜあえて自前のPCに移植しようとするのか
クラウドが高速で利便性も高いのなら、なぜリスクを冒してまでローカル環境での駆動に挑むのでしょうか。その理由は非常に現実的です。
第一の理由はプライバシーです。クラウドAIに送るプロンプトは、すべて第三者のサーバーへ送信されます。日常の雑談なら問題なくても、企業の契約書、医療記録、財務諸表などの機密データは、多くの組織で外部送信が厳しく禁止されています。「データを一歩も外に出さない」ことこそが、ローカル実行の最大の正当性です。
第二の理由はコストです。クラウドAPIはトークン従量課金制であり、日常的な利用では気にならなくても、大量のバッチ処理や自動エージェントの運用ではコストが嵩みます。一方、ローカル環境はハードウェア購入と電気代という初期・固定コストのみで、購入後は無制限に使用できます。
第三の理由はオフライン動作です。ネット接続が切れても利用可能であり、サービスプロバイダのポリシー変更やサービス停止の影響を受けません。
さらに、純粋な好奇心と情熱を持つ開発者たちの存在もあります。エンジニア界隈には「ローカル推論」を追求するコミュニティが存在し、「普通では動かないモデルを一般的なマシンで動かす」ことに情熱を注いでいます。今回の「WASTE」プロジェクトは、その全アプローチと失敗談を含む実験記録をGitHub上でオープンソースとして公開しました。
29GBのメモリにどうやって収めたのか
ここで重要となるのが**「量子化（Quantization）」**という技術です。分かりやすく言えば、モデル内の数値を「圧縮」する作業です。
元の数値は高い精度（小数点以下多数）で保存されていますが、量子化によって精度を削り、4ビットや3ビットで記録します。K3の公式版自体が4ビット圧縮（1.42TB）されたものですが、WASTEプロジェクトではエキスパート部分をさらに3ビットまで圧縮し、982GBまで軽量化しました。
しかし、圧縮だけでは982GBを29GBのメモリに収めることはできません。WASTEの真の工夫は、モデル全体をメモリにロードしない点にあります。
K3は「Mixture of Experts（MoE：混合エキスパート）」アーキテクチャを採用しています。モデル全体には896人の「エキスパート」が存在しますが、1文字（トークン）を生成する際に呼び出されるのはそのうち16人のみで、残りの880人は待機状態にあります。これは巨大総合病院で、1回の診察に必要な科の医師だけを集め、他の科の医師は待機させておくような構造です。
そこでプロジェクトチームは、頻繁に使用される「バックボーン」部分（27GB）のみをメモリに常駐させ、残りの880人のエキスパートは高速SSDに置いたまま、必要に応じてリアルタイムで読み込む手法を採りました。
図：K3のアーキテクチャ概要——混合エキスパートと新しいアテンション機構、総パラメータ数2.8兆。出典：sebastianraschka.com
その代償となるのが「速度」です。1文字を出力するたびに、SSDから17GBのエキスパートデータを読み込む必要があります。内蔵の超高速NVMe SSD（転送速度12.78 GB/s）でギリギリ維持できるレベルであり、外付けドライブ（0.94 GB/s）に変更すると、1文字の出力に13秒も待たされることになります。
また、この環境を整えるハードルも低くありません。1.42TBの公式FP4モデルから982GBのフォーマットへ変換するだけで約5時間を要し、高速な内蔵SSDの準備も必須です。
したがって、「29GB」という数字は必要なシステムメモリの最小要件であり、モデル自体のサイズではありません。29GBの中にモデル全体が収まっているわけではなく、最も使用頻度の高い骨格部分だけがメモリに常駐しているのです。 32GBのメモリを積んだマシンでも起動は可能ですが、快適に動かすには64GB以上が推奨されます。メモリが不足してOSがSSDを仮想メモリとして使い始めると、速度はさらに8倍低下します。
圧縮に伴うトレードオフ
量子化は無条件の魔法ではありません。数値を切り詰めれば、回答の精度や品質は低下します。Unslothチームの検証によると、2ビットへの圧縮ではオリジナルとの一致率が約90%を維持できますが、1ビットまで削ると約80%まで低下します。
図：同一モデルにおいて、小さく圧縮するほどオリジナル回答との剥離率が高くなる。出典：unsloth.ai
さらに難しいのは、同じビット数であっても量子化の手法や品質によって結果が大きく異なる点です。同一モデルをベースにしても、チームごとの1ビット量子化の出来栄えによって精度に20倍以上の差が出ることがあります。量子化は単なる数値のカットではなく、高度な技術的ノウハウを要する職人技なのです。
1秒に0.5トークン：「動く」ことと「使える」ことの壁
出力速度は1秒あたり0.5トークン。日本語の文章に換算すると、1秒間に約0.5文字しか進みません。
16文字の回答に31秒、128文字の文章には6分もの時間を要します。チャットツールとしての利用はもちろん、文章の転写としても実用的とは言えません。さらにK3は「思考してから回答する」タイプのアニメーションモデルであるため、回答の前に思考プロセスの出力が発生し、ローカル環境での待ち時間はさらに増大します。
しかし、プロジェクトチームの姿勢はきわめて誠実です。彼らは速度を誇張することなく、「実際に動作させた」という事実を強調しています。モデルの出力精度を公式のリファレンス実装とレイヤーごとに比較検証し、誤差が100万分の数レベルに収まっていることを証明しました。彼らの調べによると、兆単位の超大型モデルを一般的なPCのストレージからストリーミングしながらローカルで完走させた公開記録は、これが世界初となります。
一方で、同じ手法をやや小さめのモデルに適用すると全く異なる世界が見えてきます。480億パラメータの「Kimi-Linear」であれば、19GBのストレージ容量と1.87GBのメモリ領域で起動し、1秒あたり10.7文字の速度で軽快に動作します。中規模モデルであれば、一般的なPCでも十分に実用的な領域に達しています。また、K3をデータセンターの本格的なサーバー環境で動かせば、1秒間に100文字以上のスピードが出ます。
「動く」ことと「実用に耐える」ことの間には、大きな隔たりが存在します。 片側が工学的な偉業であるならば、もう片側は日常のプロダクトです。今回の取り組みは、そのふたつの岸を繋ぐ距離を確実に縮めました。
ローカル派とクラウド派の議論
ローカル環境重視派とクラウド重視派の議論は長年続いており、今回の発表によって再びスポットライトが当てられました。
- ローカル派の主張：データの外部漏洩がない、従量課金が発生しない、オフラインで動作する、システムを完全に制御できる。
- クラウド派の主張：1秒に数十〜数百トークンの圧倒的スピード、常に最新モデルを利用可能、メンテナンス不要。
Hacker Newsの議論では、一部の開発者から「K3の規模を考えると、密パラメータだけでも本来115GB以上のメモリが必要なはずだ。29GBで2.78兆モデルを動かしたという主張は妥当なのか？」という技術的疑義も呈されました。これに対し開発チームは、「3ビットMoE量子化とNVMeストリーミングの組み合わせによる数値的結果である」と回答しています。
このような建設的な議論はコミュニティにとって非常に有益です。ローカル推論の技術は、これまで「不可能だ」という懐疑論をこうした議論と実証によって乗り越え、進化を遂げてきました。
おわりに
29GBのメモリで1秒に半文字というパフォーマンスは、日常的なAIツールとしての「使いやすさ」にはまだ程遠いのが現状です。しかし、技術のタイムライン全体で見れば、その進歩は目覚ましいものがあります。わずか2年前には数十億パラメータのモデルを家庭用PCで動かすことすらニュースになっていましたが、今や兆単位のモデルが個人環境の視野に入りつつあります。SSDの高速化、量子化技術の精緻化、モデル構造の効率化が進むにつれ、この限界線はさらに押し広げられていくでしょう。
一般的なユーザーにとって、今すぐKimiを利用するには公式アプリを使うのが最も快適で手軽です。しかし、次にアプリ上で「回答はクラウドで生成されました」という表示を目にした際には、その背後で動いている巨大な技術インフラと、ローカル領域の限界に挑むエンジニアたちの足跡に思いを馳せてみるのも面白いかもしれません。
参考リンク：
- GitHub：sqliteai/waste リポジトリ
- HN 議論 (item?id=49123386)
- Hugging Face：moonshotai/Kimi-K3 議論スレッド #148
- Sebastian Raschka：Kimi K3 アーキテクチャノート
- Unsloth：Kimi K3 ローカル実行ドキュメント
- Apidog ブログ：Kimi K3 をローカルで実行する方法
