ローカルでLLMを動かすとき、モデルサイズの上限を決めているのはほぼ常にメモリです。ところが WASTE（Weight-Aware Streaming Tensor Engine） は、その前提を「重みはRAMに載せるもの」から「重みはNVMeに置いて必要な分だけ流し込むもの」へ置き換え、2.78兆パラメータのKimi K3を64GBのMacBook Proで動かすと公式に公表しています。C言語製・サードパーティ依存ゼロ・Apache-2.0、GitHubスターは1,977（2026-08-10時点）。2026年7月31日にHacker Newsで339ポイント・166コメントを集めました。
ただ、この記事で主役に据えるのはそこではありません。WASTEのリポジトリで本当に読む価値があるのは、「メモリを増やしたら8倍遅くなった」「GPUに載せたら負けた」「ディスクを測るツール自身がRAMを測っていた」といった否定的な実測が、修正前の誤った結論ごと一次記録として残されている点です。そしてその中に、ローカル推論の設計を考えるうえで効く一般則が入っています。
- ・正体：SQLite Cloud社の
sqliteaiが公開するC言語製・サードパーティ依存ゼロの推論エンジン。★1,977・Apache-2.0・最新は v0.6.6（2026-08-05）。 - ・何をするもの：MoEのトランクだけをRAMに常駐させ、エキスパートの重みをNVMe SSDから直接ストリーミングする。2.78兆パラメータのKimi K3（全93層・エキスパート896／top-16）が対象。
- ・実測：64GB MacBook Pro（M5 Pro）で 0.45〜0.62 tok/s。4Kコンテキストでの最小RAMは 29.06GB、変換後コンテナは 982GB（公開重みは1.42TB）。
- ・最大の落とし穴：メモリ予算を増やすと速くなるとは限らない。46GB→52GBでヒット率は上がるのにデコードは約8分の1に落ちる（後述の「ページングの崖」）。
- ・注意：フォーマットもAPIも未凍結。GPU（Metal/CUDA）は現状CPUに負ける。まず試すならコンテナ19GB・必要RAM 1.28GBの Kimi-Linear から。
- ・何ができるか：MoEモデルのトランク（共有部分）だけをRAMに常駐させ、エキスパートをNVMeから直接読む。これで2.78兆パラメータのKimi K3が64GB機で0.45〜0.62 tok/s。蒸留版でも枝刈り版でもなく全部入りのモデル。
- ・何を解決するか：「巨大MoEを動かすにはパラメータ全部が載るRAM/VRAMが要る」という制約。K3の公開重みは1.42TBあるが、WASTEは4Kコンテキストで29.06GBあれば開ける。
- ・何を代替できるか：手軽さで選ぶOllama/llama.cppの代替ではない。「そのモデルは手元では動かないので諦める／クラウドAPIに投げる」という判断そのものを、速度と引き換えに置き換える。
LLM全体の仕組み・主要モデル比較・ローカル実行・量子化の見取り図は、当サイトのLLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめてあります。本記事はそのうち「重みをストレージに置いたまま推論する」という一点を、WASTEの公開実測で深掘りします。
WASTEとは——2.78兆パラメータをNVMeから流し込む依存ゼロのC製エンジン
WASTEを開発しているのは、SQLiteのクラウド版を手がけるSQLite Cloud社の sqliteai 組織です。リポジトリは2026年7月28日作成と新しく、コミットの大半は同社のMarco Bambini氏によるもの。READMEには開発体制が率直に書かれています——アイデア・仮説・優先順位・テスト・意思決定は人間が行い、コードはLLMが書いている、この規模で新しいアルゴリズムを十分な速さで試すにはそれしかない、と。当サイトはこの記述を評価も批判もせず、プロジェクト自身の表明としてそのまま紹介します。
読者がまず知りたい3点を整理します。
・何ができるか：MoEモデルを「トランク（全トークンが通る共有部分）」と「エキスパート（トークンごとに一部だけ発火する部分）」に分け、前者をRAMに常駐、後者をNVMeから随時読む。CLI・C言語ライブラリ・OpenAI互換サーバーの3つの使い方があり、画像入力にも対応する
・何を解決するか：Kimi K3は2.78兆パラメータあるが、1トークンで実際に発火するのは約4%だけ。にもかかわらず従来の方式では全パラメータ分のメモリを要求される。WASTEはこの「使わない96%」をストレージに置いたままにする
・何を代替できるか：GPUを何枚も並べる構成の代替ではなく、「手元のハードでは無理」という結論の代替。0.5 tok/s前後という速度は対話用途には遅いが、バッチ処理や夜間実行なら成立しうる
数値で全体像を掴んでおきます。以下はすべて公式の測定値で、64GB MacBook Pro（M5 Pro）・内蔵SSD上のコンテナという条件です。
| 項目 | Kimi K3 | Kimi-Linear 48B |
|---|---|---|
| パラメータ数 | 2.78T | 48B |
| 公開重みのサイズ | 1.42 TB | — |
| 変換後のWASTEコンテナ | 982 GB | 19 GB |
| 最小RAM（4Kコンテキスト） | 29.06 GB | 1.28 GB |
| 常駐トランク | 27.28 GB | — |
| デコード速度（既定予算） | 0.45〜0.62 tok/s | 10.65 tok/s |
| エキスパートキャッシュのヒット率 | 36〜38% | 89% |
| モデルのロード時間 | 約20秒 | — |
「まず動かしてみたい」だけならKimi-Linearが現実的な入口です。19GBのコンテナと1.28GBのRAMで10.65 tok/s出ます。一方K3は、64GBが実用上の下限であり、32GB機では「開けるが激しくページングする」と明記されています。
なぜ64GBのMacBookで2.78Tが動くのか——4つの設計判断
「NVMeから読む」だけでは説明になりません。ディスクは速くてもRAMより桁で遅いからです。WASTEが成立しているのは、次の4つが噛み合っているためです。
1. MoEの疎性を最大限に使う。 K3は2.78兆パラメータのうち1トークンあたり約4%しか発火しません。WASTEはトランクをRAMに置き、選ばれたエキスパートだけをディスクから読みます。
2. 1エキスパート＝1回のアライン済み読み込み。 コンテナのレイアウトが「1エキスパートを1回のアラインされたreadで取れる」ように設計されています。ランダムな細切れI/Oではなく、まとまった読み込みが並ぶ形にすることで、NVMeの実力が出ます。
3. エキスパートは3ビット残差ベクトル量子化。 エキスパートの重みは3ビットの残差VQで格納され、より誤差に敏感なトランク側は4ビットまたは8ビットのまま残されます。読むバイト数そのものを削る一方、品質が効く場所には精度を残す配分です。
4. KVキャッシュが小さい。 K3の線形注意と圧縮潜在KVキャッシュにより、4KコンテキストでKVキャッシュは約0.21GBで済みます。通常の方式なら11.25GB相当のところで、この差がそのままエキスパートキャッシュに回せる余裕になります。
この4点の結果として、K3を開くのに必要なメモリは29.06GBまで下がります。コンテキスト長を伸ばすとこの下限も上がっていきます。
| コンテキスト長 | 最小RAM |
|---|---|
| 4K | 29.06 GB |
| 32K | 30.54 GB |
| 128K | 35.64 GB |
| 1M | 83.22 GB |
正しさの検証も公表されています。全レイヤーがPyTorchの参照実装と突き合わせられ、最終ロジットの一致は3.6e-06以内、画像側のビジョンタワーは2.3e-06以内とされています。速度は妥協していても、出力そのものは近似ではないという主張です。
デコード1ステップの流れをMermaidで示します。
RAM常駐 27.28GB"] TRUNK --> ROUTER{"MoEルーター
上位16エキスパートを選択"} ROUTER --> CACHE{"エキスパートキャッシュに
載っているか"} CACHE -->|"ヒット 36〜38%"| COMPUTE["エキスパート計算
3bit残差VQを展開"] CACHE -->|"ミス"| DISK["NVMeから読む
1エキスパート＝1回のread"] DISK --> COMPUTE COMPUTE --> MERGE["出力を統合"] MERGE --> NEXT["次のレイヤーへ"] NEXT -->|"全93層を通過後（うちMoE層92）"| OUT["次トークンを出力"]
WASTEの核心①：キャッシュを増やすと8倍遅くなる「ページングの崖」
ここからが本題です。上の図を見た人がまず考えるのは「じゃあキャッシュを大きくすればヒット率が上がって速くなるはずだ」でしょう。公式の実測はその逆を示しています。
ルーター先読みを有効にした現行版で、同一プロセス内で4つのキャッシュサイズを測ったのが次の表です。
| メモリ予算 | エキスパートキャッシュ | スロット数 | ヒット率 | デコード速度 |
|---|---|---|---|---|
| 32 GB | 3.32 GB | 287 | 29.1% | 0.56〜0.58 tok/s |
| 46 GB | 17.32 GB | 1,498 | 36.2% | 0.63 tok/s |
| 52 GB | 23.32 GB | 2,018 | 38.4% | 0.07〜0.09 tok/s |
| 58 GB | 29.32 GB | 2,537 | 41.3% | 0.07〜0.08 tok/s |
下2行が問題の箇所です。ヒット率は上がり続け、ディスクから読むバイト数は減り続けているのに、スループットは8分の1に落ちます。 エンジンは自分に与えられた予算の内側にいます。はみ出しているのはマシンのほうです。OSがそのメモリをページアウトし始めるため、キャッシュ「ヒット」がエンジンの管理下にある pread ではなくページフォールトに化け、全レイヤーがその代金を払います。
この崖には、設計者にとって痛い含意が3つ記録されています。
・メモリを解放する最適化が、8倍の減速を招いた。 embed_tokens を常駐セットから外す変更で1.11GBが空きました。ところが予算を固定したままだったため、空いた1.11GBはそのままキャッシュに積まれ、27.99GBから29.1GBへ——0.32 tok/sが0.04 tok/sになりました。メモリを空けることと、空けた分を使わずにおくことは別の行為で、安全なのは後者だけです
・崖の位置はエンジンの性質ではない。 1回目のスイープでは52GBが最良の行（0.33 tok/s）でした。2回目では同じ52GBがその3分の1です。23.00GBのキャッシュは生き延び、23.32GBは生き延びなかった。どこに崖が来るかは、そのときマシンが他に何を抱えているかで動きます
・測定順序そのものが結果を変える。 重い行を測った後に46GBを測り直すと、0.32ではなく0.25や0.22になります。3回の実行でキャッシュ統計は「2961ヒット / 20591ミス」と1桁まで完全に同一なのに、時間だけが違う。macOSは重い行で圧縮・ページアウトしたものを返してくれないため、その後の測定は事実上「別のコンピュータ」で行われています。公式の結論は「予算は必ず小さいほうから大きいほうへ測れ。ページングした行の後に取った行は無効として捨てろ」
そして最も実務的な話——既定値がこの谷のど真ん中に落ちていました。 --budget を付けない場合、エンジンは推奨値をRAMの8分の7で頭打ちにしており、この機体では56.00GB・キャッシュ27.32GBになっていました。0.11 tok/sの23.32GBと0.04 tok/sの29.32GBのちょうど間です。何も指定しない普通の実行が、--budget 46G を付けた同じコマンドより3〜8倍遅いという状態で、これはコードを読んで見つかる類のバグではありません。
現在は、キャッシュは1トークン分の作業セットの整数倍でしか価値を持たないという性質から、3x → 2x → 1x → 下限、と上限に収まる最大の倍数まで段階的に下げる方式に変更されています。K3では 下限 + 1x = 46.24GB（キャッシュ17.56GB）に着地し、フラグなしで0.33 tok/sになりました。
これはWASTE固有の話ではありません。自前でキャッシュを管理するプロセスは、OSがそのメモリを取り返せる限り、キャッシュ統計が良化しながら性能が崩壊しうる——という一般則です。ヒット率とバイト数だけを見ていると崖は見えません。壁時計時間とRSS、そしてマシン全体の空きメモリを同時に見る必要があります。
WASTEの核心②：崖の手前を作り替えたのは容量でなく「先読み」
ここで、READMEの表と実験ログの表を並べて読んだ人は混乱するはずです。同じ4つのキャッシュサイズで、数値がまるで違うからです。
| キャッシュ | 現行版（先読み有効） | 2026-07-28版（先読み実装前） |
|---|---|---|
| 3.32 GB | 29.1% / 0.56〜0.58 tok/s | 0% / 0.31 tok/s |
| 17.32 GB | 36.2% / 0.63 tok/s | 13% / 0.32 tok/s |
| 23.32 GB | 38.4% / 0.07〜0.09 tok/s | 27% / 0.11〜0.14 tok/s |
| 29.32 GB | 41.3% / 0.07〜0.08 tok/s | 37% / 0.04 tok/s |
これは矛盾でも誤記でもありません。両者を分けている変数は「ルーター先読み（router lookahead）」です。 2026-08-01に実装されたこの機構が、崖の手前側を丸ごと作り替えました。とくに左上——3.32GBのキャッシュのヒット率が0%から29.1%へ跳ねているのが決定的です。
仕組みはこうです。レイヤーLのMoE処理が終わり、次のレイヤーの注意計算のあいだディスクが暇になる瞬間に、レイヤーL+1のルーターをレイヤーLの隠れ状態に対して先に走らせ、上位6エキスパートの読み込みを始めてしまう。本物のルーターは従来どおり後から選び直すので、先読みが変えるのはバイトが動くタイミングだけで、出力は1ビットも変わりません。
予測精度は公表されており、上位6件までなら5回に4回当たる水準です。
| 予測幅 | 的中率 |
|---|---|
| 1位のみ | 92.2% |
| 上位6件（累積） | 81.4% |
| 上位16件（累積） | 59.0% |
なぜ「6」なのか。約5.9ミリ秒の空き時間に、1回0.92ミリ秒の読み込みが6回入るからです。16件まで広げると精度が59.0%まで落ち、投機的な読み込みが無駄になります。
決定的なのは、この機構が「キャッシュの下限は1トークン分の作業セット（K3で17.0GB）」という、このプロジェクトで最も古い測定を無効化したことです。287スロット（1トークン分の1,472レコードの5分の1）での対照実験がこれです。
| 287スロット | ヒット率 | 速度 | 読み込み量 |
|---|---|---|---|
| 先読みオフ | 0.0% | 0.507 tok/s | 153.1 GB |
| 先読みオン | 29.1% | 0.585 tok/s | 165.2 GB |
理由は一言で説明できます。先読みされたレコードは「次のトークンまで」生き延びる必要がなく、「次のレイヤーまで」生き延びればいい。 従来は1つのエキスパートが再利用されるまで約3秒かかり、その間キャッシュに居座る必要がありました。先読みなら数ミリ秒後に消費されます。1トークン分の作業セットを到底保持できない小さなキャッシュでも、6個のエキスパートを注意計算1回分のあいだ抱えるには十分なのです。
公式ドキュメントはこの点を、レバーの棚卸しとして総括しています——I/Oの「サイズ」を変えるレバー（キャッシュ増量、バッチ化、投機的デコード、活性化ごとの精度調整）はすべて測定のうえ却下され、これまで実際に効いた2つはどちらもI/Oの「タイミング」を変えるものだった、と。読み込みの先行発行は16トークンの実行を48.41〜58.61秒から30.03〜32.85秒へ、約1.6倍に短縮しています（ロジットとキャッシュ統計は同一）。
ボトルネックはどこにあるのか——ディスク・GPU・エンクロージャの実測
「じゃあ結局どこが遅いのか」に、WASTEはプロファイル結果で答えています。読み込みの先行発行を有効にした状態で、K3のデコード6ステップを分解した結果です。
| 処理 | 秒 | 割合 |
|---|---|---|
| エキスパートI/O | 9.95 | 54.8% |
| エキスパート行列積 | 4.94 | 27.2% |
| — うちLUT適用 | 4.34 | 23.9% |
| KDA（線形注意） | 1.69 | 9.3% |
| LUT構築 | 0.48 | 2.7% |
読み込みを計算の裏に隠したあとでも、I/Oは演算の2倍を占めます。ここから3つの実務的な結論が出ます。
ストレージは内蔵に置く。これは推奨ではなく必須。 ディスクの実測はエンジンの実際のアクセスパターン（12MBレコード・F_NOCACHE・pread・複数スレッド）で測られています。
| デバイス | 12MBランダム読み込み |
|---|---|
| 内蔵SSD | 12.78 GB/s |
| 外付けUSB SSD（ASM246Xブリッジ） | 0.94 GB/s |
13.6倍の差です。しかも外付けはスレッドを増やしても伸びません。天井はエンクロージャの中のNVMeではなく、USB 10Gbpsのブリッジだからです。K3の冷えたトークン1つは約17GBのエキスパートを読むので、この差は体感どころではありません。公式の運用も「外付けにはダウンロードと変換の作業領域を置き、エンジンが読むコンテナは内蔵SSDに置く」と分けられています。
GPUに載せても、現時点では負ける。 Apple SiliconのMetalバックエンドは実装済みで、ユニファイドメモリを活かしてコピーを一切しない設計になっています。正しさも確認済み（CPU比8.1e-06）。それでもK3の5デコードステップでCPU 15.93秒に対しMetal 19.43秒——22%遅い。最も分かりやすいのは lm_head で、1.17GBのint8重みに対しCPU 6ms／GPU 22ms、帯域に直すと195GB/s対53GB/sです。CPU側が既にマシンのメモリ帯域いっぱいで走っており、GPUが取れる余地がありません。
NVIDIA側でも同じ問いが測られ、結論の理由が変わりました。ディスクリートGPUではカーネル自体は速く、lm_head の往復はCPUの6.25倍です。しかし決め手はエキスパートの転送でした——1トークン分544MiBをPCIe経由で送ると19.807ms（28.8GB/s）。リンクは正常に働いています（Gen5 x8の90%）。問題は、それがこのCPU自身のRAM帯域63〜80GB/sより遅いことです。カードは「ホストのRAMにエキスパートを読み込み、それをホストが既に持っていた速度の半分でリンク越しに押し出す」という構造的に不利な経路にいます。加えて1トークン分のエキスパート16.5GiBは、使えるVRAM 15.5GiBにそもそも入りません。
測定ツール自身が嘘をついていた事例も残っている。 これが個人的には一番読む価値がある1件です。ディスクを認証する役目の tools/diskbench が、Linuxではページキャッシュを測っていました。ヘッダのコメントには「ページキャッシュはバイパスされる」と書いてあるのに、nocache() の中身が #ifdef __APPLE__ だけで、Linuxでは空だったのです。外部からの報告で判明した数値がこれです。
| Samsung 970 PRO（Gen3 x4） | 修正前 | 修正後 | リンクの理論上限 |
|---|---|---|---|
| シーケンシャル読み込み | 44.67 GB/s | 3.15 GB/s | 3.94 GB/s |
| ランダム（1スレッド） | 36.75 GB/s | 2.91 GB/s | |
| ランダム（飽和時） | 65.72 GB/s | 3.33 GB/s |
リンクの理論上限の11倍・17倍という値が出ていました。公式の総括が的確です——「兆候は毎回の実行に出ていたのに、誰も割り算をしなかった。Gen3 x4のドライブが65GB/s出せるはずがない、ベンチが何と言おうと」。この修正はv0.6.6（2026-08-05）に入っています。公開済みの数値はすべてmacOSで測られていたため動きませんが、「ディスクバウンドだと主張する前にdiskbenchを走らせて割り算しろ」というルール自体が、Linux上では2026-07-28から機能していなかったことになります。
インストールと実行手順——実機ビルドで確かめた範囲
ここからは筆者環境で実際に確認した内容です。検証環境：Apple M2 / macOS 14.5 / arm64 / RAM 16GB / Apple clang 15.0.0、リポジトリはタグ v0.6.6。 RAMが16GBしかないためK3そのものは動かせません（4Kコンテキストでの下限が29.06GB）。したがって以下で確認したのは、ビルド・テストスイート・メモリプラン・予算の拒否挙動までで、K3の速度は未検証です。速度に関する数値はすべて公式値をそのまま引用しています。
ビルドは依存関係がないため素直に通ります。
git clone --branch v0.6.6 https://github.com/sqliteai/waste
cd waste
make # waste CLI と libwaste.a を生成
make check # 合成モデルを作って自己検証（重みのDL不要）
make は筆者環境で15.0秒で完了しました。生成された waste バイナリは334,600バイト（約327KB）。依存の少なさは実際に確認できます。
$ otool -L waste
waste:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)
$ ./waste version
WASTE 0.6.6 (container v0, backend NEON, crc32 armv8, arm64)
リンクしているのは libSystem 1本だけでした。「サードパーティのランタイム依存なし」というREADMEの主張は、少なくともmacOS/arm64のCPU推論パスについては文字どおりです。なお --version はフラグではなくサブコマンド waste version で、--version を渡すと終了コード2で拒否されます。
make check は1分7秒で完走し、30件成功・0件失敗・13件スキップでした。スキップはすべて「実物のコンテナが要る」種類のもので、合成コンテナでは検証できない項目です。成功した中に、本記事の主張を直接裏づけるものが3つ含まれていました。
・expert cache is bit-identical to no cache（エキスパートキャッシュ有無で出力がビット単位一致）
・read-ahead is bit-identical to synchronous reads（先行読み込みと同期読み込みで一致）
・router lookahead is bit-identical to no lookahead（ルーター先読みの有無で一致）
3つ目が重要です。「先読みが変えるのはタイミングだけで結果は変わらない」という主張が、筆者の手元で実際に走ったテストとして確認できました。速度の数値は追試できませんでしたが、この設計上の性質は追試できます。
メモリプランは実行前に確認でき、機械可読な出力もあります。
$ ./waste plan /tmp/tiny.waste
memory plan for /tmp/tiny.waste (ctx 4096)
resident trunk 0 MB
KDA state + KV cache 1 MB
scratch 9 MB
minimum expert cache 0 MB
---------------------------------
FLOOR 10 MB
recommended 10 MB (floor + 3x a token's working set)
そして前述の「下限を割った予算は拒否する」という挙動も確認しました。10MBが下限の合成コンテナに1MBの予算を渡すと、終了コード1で拒否されます。
$ ./waste bench /tmp/tiny.waste --budget 1M
open: RAM budget below the model's floor
(run `waste plan MODEL` to see the floor)
$ echo $?
1
黙ってスワップに落ちるのではなく、エラーで止めて waste plan を案内する——ページングの崖を知っているプロジェクトらしい設計です。予算を64Mに増やすと終了コード0で通ります。
K3本体を入手する経路は2つあります。公開重み1.42TBをダウンロードして自分で変換する方法（3ワーカーで約4.7時間、一時領域1.42TBが別途必要）と、変換済みコンテナ982GBをBitTorrentで落とす方法です。後者は1.42TBのダウンロードと変換時間と一時領域をまるごと省けます。マグネットリンクは公式READMEに掲載されているので、利用する場合はそちらを参照してください（本記事では転載しません）。いずれの場合も、コンテナの置き場所は内蔵NVMeにしてください。外付けに落とすと使う前にコピーし直すことになります。
OpenAI互換サーバーも同梱されており、ストリーミング・ツール呼び出し・構造化出力・思考制御・画像に対応します。
類似ツールとの比較——colibri・KTransformers・llama.cppとの違い
「エキスパートをRAMの外へ追い出す」というアイデア自体は、WASTEの発明ではありません。重要なのはそれぞれが答えている問いが違うことです。
| WASTE | colibri | KTransformers | llama.cpp（mmap/オフロード） | |
|---|---|---|---|---|
| エキスパートの置き場所 | NVMe（ディスク） | ディスク | CPUのシステムRAM | 主にRAM、不足分はmmap経由でディスク |
| 前提ハードの主軸 | 高速な内蔵NVMe | ディスク | 大容量DRAM（数百GB級） | 汎用（GPU/CPU両対応） |
| 実装言語・依存 | C・依存ゼロ | 純C・依存ゼロ | Python＋CUDA等 | C/C++ |
| 主対象モデル | Kimi K3（2.78T） | GLM-5.2（744B） | DeepSeek-R1/V3級 | 汎用（幅広い） |
| 公称の実測速度 | 0.45〜0.62 tok/s（K3・64GB機） | 0.05〜2.06 tok/s（機体依存） | 最大約16 tok/s（24GB VRAM＋約382GB DRAM） | モデル・機体依存 |
| GPUの扱い | 実装済みだが既定オフ（現状は負ける） | — | GPU前提（注意層とホット専門家） | GPUオフロード対応 |
| 際立った特徴 | 否定的結果を含む実験ログの公開 | 純Cでの省RAM実行 | CPU/GPUヘテロ配置とAMX活用 | エコシステムの広さと手軽さ |
棲み分けを整理すると次のようになります。
・手軽さが最優先なら llama.cpp / Ollama。 対象モデルの幅もツールの成熟度も比較になりません。巨大MoEを無理に動かす用途以外では、まずこちらです
・大容量DRAMを積んだマシンがあるなら KTransformers解説｜24GB VRAMでDeepSeek-R1級MoEを動かすCPU/GPUヘテロ推論。 GPUを1枚だけ持っていて、システムRAMを数百GB積める構成に向きます。エキスパートはディスクではなくRAMに置くので、WASTEより桁で速い代わりにDRAMの物量が要ります
・RAMを増やせないがNVMeは空いているなら WASTE / colibri。 同じ土俵です。colibri解説｜GLM-5.2（744B MoE）を25GB RAMで動かす純Cランタイムの実測速度では、ハードウェア別の実測速度と実用ラインの線引きを扱いました。WASTEはそれよりモデル規模が一桁大きい（2.78T対744B）一方、本記事で見たとおり「どこにボトルネックがあり、どの改善が効かなかったか」の記録が一次資料として読める点が独自です
最後に、WASTEを検討する際の注意点を挙げておきます。
・速度は対話用途に届かない。 K3で0.45〜0.62 tok/sは、100トークンの返答に3分前後かかる計算です。バッチ処理・夜間実行・「時間はかかっていいから最高性能のモデルで」という用途に限られます
・フォーマットもAPIも凍結されていない。 公式が「非常に速く変化している」「各リリース前に大規模QAを流しているが、不安定な箇所は確実にある」と明記しています。v0.6.6ではライブラリの構造体にフィールドが追加され、呼び出し側は再コンパイルが必須（しないと無言で誤ったオフセットを読む）とされました
・画像は高価。 896×896の画像は256プロンプト位置に展開され、ビジョンタワー自体は1024パッチで15.7秒ですが、その後の言語モデル通過が1位置あたり約2.8秒。画像1枚で約731秒のプリフィルになります
・ストレージ要件が重い。 変換済みコンテナだけで982GB、自分で変換するなら一時領域が別途1.42TB
WASTEが面白いのは、これらを隠していない点です。公式ドキュメントは測定値を「マーケティングの数字ではなく実験結果として扱う」と宣言し、各結果をハードウェア・コンテナ・設定・コミットに紐づけ、不安定なものは範囲で報告し、後から誤りと分かった結果もそのまま記録として残す方針を取っています。ローカル推論の限界を自分で押し広げたい人にとって、docs/LEARNED.md の否定的結果50件は、エンジン本体と同じくらいの資産です。
参照ソース
・sqliteai/waste（公式リポジトリ・README） — プロジェクト概要、性能表、必要ハードウェア、入手・実行手順（2026-08-10閲覧）
・docs/TECHNICAL.md（公式） — 性能スナップショット、ページングの崖の現行スイープ、ルーター先読みの精度、測定規律（2026-08-10閲覧）
・docs/LEARNED.md（公式） — 実験ログ。§2ストレージ、§16キャッシュ過大、§39キャッシュ下限の無効化、§49 diskbenchのバグ（2026-08-10閲覧）
・docs/EFFICIENCY.md（公式） — デコード時間の分解、各レバーの評価と却下理由（2026-08-10閲覧）
・docs/BACKENDS.md（公式） — Metalバックエンドの実測、CUDAのゲート評価（2026-08-10閲覧）
・docs/ENGINE.md（公式） — ライブラリ／CLI構成、RAM予算の下限と上限の決め方（2026-08-10閲覧）
・Release v0.6.6（公式・2026-08-05） — CPU配置指定の追加、diskbenchのページキャッシュ問題の修正、ABI変更の注意（2026-08-10閲覧）
