WASTE推論エンジン — Kimi K3をRAM29GBで動かす仕組み

RAM 29GBのノートPCで、2.78兆パラメータのKimi K3が動く。ただしスループットは0.45〜0.62 tok/sにとどまる。 2026年8月1日にHacker News上位（328pt）に入った推論エンジン「WASTE」（sqliteai/waste）は、MoEモデルの疎な活性化とNVMeストリーミングを組み合わせることで、通常なら数百GB〜数TBのメモリを要求する超巨大モデルを一般的なノートPCで動かす。この記事ではWASTEの仕組み、実測スペック、導入手順、そして0.5 tok/s前後という速度が実務でどこまで使えるのかを整理する。

WASTE（sqliteai/waste）は、依存関係を持たないC11製の推論エンジンで、必要なのはlibcとpthreadsだけ。macOS・Linux・Windows（MinGW-w64）で動作し、ライセンスはApache 2.0。GitHub上の著作権表記はSQLite Cloud, Inc.で、SQLiteの作者自身がHacker News上でこのプロジェクトに関わっていることに言及している。llama.cppのような汎用推論エンジンとは異なり、WASTEは「超巨大MoEモデルを、全重みをメモリに載せずに動かす」という一点に狙いを絞って設計されている。

対象になるのはKimi K3のような数兆パラメータ級のMixture-of-Expertsモデルだ。K3自体の詳細なアーキテクチャやAPI料金はKimi K3とは — 2.8T MoEの実力・API料金・ローカル実行の現実で扱っており、weights公開後の自前ホスト条件（H100×64基級が必要という結論）はKimi K3 のweightsが公開 — 2.8T MoEを自前で動かす条件で整理した。WASTEはこの「クラスタが要る」という前提そのものをノートPC1台に置き換える試みといえる。

鍵はMoEモデルの性質にある。トークンごとに実際に計算へ参加する（活性化する）パラメータは全体のわずか約4%に過ぎない。WASTEはこの性質を逆手に取り、全モデルで共有される部分（trunk）だけをRAMに常駐させ、トークンごとに選択されるexpert（専門家）の重みはNVMeから都度読み出す。オンディスク上の配置は「1 expert = 1回のアラインされたリード」になるよう最適化されており、無駄なシーク・断片読みを避けている。

- 共有部（trunk）: 全トークンで使われる重みのみRAMに常駐させる
- expertの選択的読み出し: トークンごとに必要なexpertだけをNVMeから読む（全体の約4%相当の活性化率）
- 先読みルータ（lookahead router）: 本来のルータが確定する前に先回りしてどのexpertを読むか予測し、I/Oを先行開始する
- 計算とI/Oのオーバーラップ: 先読みの結果、GPU/CPU計算とディスク読み出しが並行して進み、推論結果自体は先読みの有無に関わらず不変
- 余剰RAMのexpertキャッシュ化: 上限付きのキャッシュとして使い、ヒット率が上がるほど実効速度が伸びる

この仕組みにより、モデル全体のサイズがRAM容量をはるかに超えていても、常時RAMに載っているのは「共有部＋アクティブなexpertの一部」だけで済む。Kimi K3では、既定の17.56GBのexpertキャッシュを使った場合のヒット率は36.2%と報告されている。

Kimi K3はコンテナ982GBに対し最小RAM29.06GB・推奨64GBという非対称さが特徴で、これがWASTEの「メモリ容量の呪縛から逃れる」というコンセプトを最も端的に示している。一方、コンテナサイズが小さいKimi-Linear 48Bでは、必要RAMも1.28GBまで下がり、スループットは10 tok/s台に乗る。モデルサイズが小さいほどNVMe読み出しの割合が下がり、体感速度が上がる傾向がここから読み取れる。

WASTEの性能はストレージ速度に強く依存する。公開されている実測では、内蔵NVMeが12.78GB/sを記録したのに対し、テストされたUSB外付けストレージは0.94GB/sにとどまった。約13.6倍の差があり、外付けドライブでKimi K3クラスのモデルを動かそうとすると、実用に耐えるスループットは望みにくい。導入を検討する際は、まず自分のマシンの内蔵NVMeの実効読み出し速度を確認することが最初のチェックポイントになる。

WASTEで配布されるexpert重みは3bit residual vector quantizationで圧縮されており、影響の大きい共有重み部分は4〜8bitで持たれる。RAM要件を切り詰めるうえで、NVMeストリーミングと並ぶもう一つの柱がこの量子化戦略だ。加えてKimi K3自体がlinear attentionと圧縮されたlatent KVを採用しているため、4Kコンテキストでの KVキャッシュサイズは0.21GBで済む（通常のattention換算では11.25GB相当）。これはWASTEの独自最適化ではなくK3のアーキテクチャ由来だが、限られたRAMの中でKVキャッシュが占める割合を大きく減らす効果があり、29GBという下限値に直結している。

ビルドに特別な環境は要らない。C11コンパイラとmakeがあれば以下の3行で完結する。

git clone https://github.com/sqliteai/waste
cd waste
make && make check

動作確認まで含めたビルドが済んだら、単発実行は./waste run、対話セッションは./waste chatで開始する。OpenAI互換のchat completions APIを話すHTTPサーバも同梱されており、ストリーミング応答・structured output・tool useに対応しているため、既存のOpenAI SDK前提のクライアントコードをほぼそのまま向けられる。なお、重み自体の変換（PyTorch/safetensors形式からWASTE用フォーマットへの前処理）はオフラインの一度きりの作業で、3並列ワーカーを使ってもKimi K3クラスで約4.7時間かかる。推論の実行そのものにはPyTorchやsafetensorsは不要。

WASTEは画像入力にも対応している。CLIでは--imageオプション、対話モード中は/imageコマンドで画像を渡せる。896×896の画像は256のプロンプト位置に展開され、1位置あたり約2.8秒の処理時間がかかる。画像1枚あたりで見るとおよそ12分弱の追加処理時間になる計算で、テキストのみの応答に比べて待ち時間は大きく伸びる。

0.45〜0.62 tok/sという数値は、チャットのように即時応答を期待する用途には現実的ではない。Hacker Newsのコメント欄でも、この速度で100万トークンを生成すると約23日かかる計算になると指摘されており、対話用途としては非現実的だという評価が多い。加えてコンテキスト長が4Kに制限されている点も、長文コンテキストを前提とするタスクの選択肢を狭める。

一方で、バッチ処理・オフライン推論・応答が数分〜数十分後でよい非同期タスク（ドキュメント要約のバックグラウンド処理、開発中の検証用途など）であれば、そもそもクラウドAPIやクラスタなしに2.78兆パラメータモデルの出力そのものを手元で得られる点に価値がある。消費電力は約42W持続と報告されており、電力単価$0.20/kWhで試算すると100万トークンあたり約$5相当になる。クラウドAPI経由での同等トークン消費コストと比べると、多くの場合APIのほうが安く済むという指摘がHacker Newsでもなされており、「安く動かせる」ことと「動かせる」ことは切り分けて考える必要がある。

もう一点、Hacker Newsで指摘されていたのがREADMEの文体そのものへの批判で、初期版が冗長なAI生成文（いわゆる「LLM slop」）だと評され、作者が手書きで書き直すと表明している。ドキュメントの完成度はまだ発展途上と見ておくのが妥当だろう。

従来、超巨大MoEモデルを限られたメモリで動かす手段としては、llama.cppのmmapベースのオフロードや、GPU/CPU間でのレイヤー分割配置が一般的だった。これらは基本的に「モデル全体をディスク上に置き、必要な部分をOSのページキャッシュ任せで読み込む」発想に近く、どのexpertが次に必要になるかを予測する仕組みは持たない。WASTEの差別化点は、MoE特有の疎な活性化パターンに合わせてオンディスク配置とアクセスパターンそのものを設計し、さらに本ルータの確定前から先読みでI/Oを開始する点にある。ビルドはmakeのみで依存ライブラリを持たないため、CUDA/cuDNNのような重量級の環境構築も不要だ。ただし現時点ではCUDA/Metalバックエンドは実験的な位置づけで、CPU推論が主体になっている点は注意が必要。Apple Silicon環境では、MetalよりもARM NEON実装のほうが速かったという報告もある。