64GB MacBookで2.78T Kimi K3を実行：WASTEのNVMeストリーミングエンジン
WASTEを発見しよう。依存関係のないC製推論エンジンで、エキスパートの重みをNVMeからストリーミングし、コンシューマーハードウェア上で完全な2.78TパラメータのKimi K3を0.6トークン/秒で実行します。
ノートパソコンで2.78兆パラメータのモデルを実行することを想像してみてください。蒸留版でも、量子化近似でもなく、完全なオリジナルのKimi K3 — 既存の最大級のオープンモデルの一つを動かすのと同じ重みです。それを実現するのがWASTE（Weight-Aware Streaming Tensor Engine）で、混合エキスパート（MoE）アーキテクチャ、積極的な量子化、そして現代のNVMeストレージがRAMの遅いが広大な拡張として機能するという深い理解を巧みに組み合わせています。
WASTEは、Cで書かれた組み込み可能な推論エンジンで、サードパーティのランタイム依存関係はゼロです。モデルの共有トランクをメモリに保持し、アクティブなエキスパートの重みだけをディスクから直接ストリーミングし、残りのRAMを境界付きキャッシュとして使用します。その結果、完全な2.78TパラメータのKimi K3が64GB MacBook Pro上で約0.6トークン/秒で動作します。これはクラウド標準では遅いですが、ローカルAIにとっては画期的な一歩であり、プロジェクトの最終目標はKimi K3が机の上で完全に動作しながら自己改善することです。
なぜ重要か：トークン廃棄問題
プロジェクト名は単なる巧妙な頭字語ではありません。クラウドAPIを介して生成するすべてのトークンは、二重に支払われます。一度は請求書で、もう一度はデータセンターの電気代で、あなたがすでに所有しているハードウェアに（かろうじて、ぎこちなく、しかし本物に）収まる可能性のあるモデルを実行しているのです。WASTEは、フロンティア規模のモデルが遅くてもローカルで実行できることを証明することで、その無駄をなくすことを目指しています。これは技術的な立場であると同時に哲学的な立場でもあります。
WASTEの仕組み：NVMeからのエキスパートのストリーミング
Kimi K3は2.78兆パラメータの混合エキスパートモデルですが、任意のトークンに対してアクティブなのはそのうち約4%だけです。WASTEはこのスパース性を根本的な方法で活用します：
- 常駐トランク：共有（非エキスパート）レイヤーはRAMに留まります。K3の場合、約27.28GBです。
- ストリーミングエキスパート：コンテナ形式は、各エキスパートがディスクから正確に1回の整列読み取りを必要とするように配置されています。ルーターがエキスパートを選択すると、WASTEはNVMeから直接読み取ります。
- 境界付きエキスパートキャッシュ：未使用のRAMは最近使用されたエキスパートのキャッシュになり、繰り返しのディスク読み取りを回避します。
- 先読みルーター：予測ルーターが次のレイヤーが必要とするエキスパートを予測し、早期に読み取りを開始します。実際のルーターが最終決定を行うため、これはタイミングのみを変更し、結果は変更しません。
- 積極的な量子化：エキスパートは3ビットの残差ベクトル量子化を使用し、より敏感な共有重みは4ビットまたは8ビットに保たれます。
この設計により、メモリフットプリントが劇的に削減されます。完全なK3コンテナは982GBですが、WASTEが開くために必要なRAMは29.06GBだけです。残りのメモリ（設定可能な予算まで）はエキスパートキャッシュに使用されます。
パフォーマンス数値：期待できること
M5 Proと内蔵SSDを搭載した64GB MacBook Proでは、WASTEは次のパフォーマンスを提供します：
| モデル | コンテナサイズ | 最小RAM | デコード速度 |
|---|---|---|---|
| Kimi K3 2.78T | 982 GB | 29.06 GB | 0.45–0.62 tok/s |
| Kimi-Linear 48B | 19 GB | 1.28 GB | 10.65 tok/s |
K3の場合、64GBが実用的な最小値です。32GBのマシンでも技術的にはモデルを開けますが、ページングが激しくなり、使用できなくなります。テストマシンのデフォルトのメモリ予算は46.25GBで、17.56GBのエキスパートキャッシュを含みます。
キャッシュサイズのトレードオフ
WASTEのパフォーマンスはエキスパートキャッシュサイズに非常に敏感です。チームは単一プロセスで4つの構成を測定しました：
| エキスパートキャッシュ | ヒット率 | デコード速度 |
|---|---|---|
| 3.32 GB | 29.1% | 0.56–0.58 tok/s |
| 17.32 GB | 36.2% | 0.63 tok/s |
| 23.32 GB | 38.4% | 0.07–0.09 tok/s |
| 29.32 GB | 41.3% | 0.07–0.08 tok/s |
最後の2行は重要な教訓です：プロセスにより多くのメモリを与えても、常に高速になるとは限りません。キャッシュがOSがRAMに快適に収められる量を超えると、キャッシュヒットがページフォールトになり、スループットは8倍に低下します。エンジンは予算内ですが、マシンはそうではありません。
ストレージが本当のボトルネック
コールドK3トークンは約17GBのエキスパートを読み取ります。内蔵SSDは12.78GB/sを維持しますが、テストしたUSBエンクロージャは0.94GB/sしか達成できませんでした — 13倍の差です。常にコンテナを内蔵NVMeストレージに置いてください。
はじめに：ゼロからK3を実行するまで
エンジンをビルド
git clone https://github.com/sqliteai/waste
cd waste
make
make check
makeはwasteCLIとlibwaste.aをビルドします。make checkはモデルフリーのテストスイートを実行し、小さな合成モデルを作成するため、重みはダウンロードされません。
変換済みコンテナを入手（最速の方法）
K3を入手する最も簡単な方法は、BitTorrentで事前変換済みコンテナをダウンロードすることです。これにより、1.42TBのソースダウンロードと4.7時間の変換プロセスをスキップできます。トレントのピースハッシュは、コンテナが到着する際に検証します。
aria2c --dir ~/models --seed-time=60 \
'magnet:?xt=urn:btih:abe7123a60b2b1171c1c4dcaa381b93c46806afe&dn=k3.waste&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce'
--dirを内蔵NVMeストレージに向けてください — 外付けディスク上のコンテナは遅すぎて使用できません。
公開された重みから変換（お好みで）
サードパーティのコピーを信頼したくない場合、または元の重みをすでに持っている場合は、自分で変換できます。プロセスは再開可能です：
# 必要なダウンロード容量を確認
tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry-run
# 元の重みをダウンロード
tools/fetch_weights.sh --dest /Volumes/staging/k3
# 変換（出力は内蔵SSDに）
uv run --with torch --with safetensors python tools/convert.py \
--src /Volumes/staging/k3 \
--out ~/models/k3.waste \
--jobs 3
変換にはテストマシンで3ワーカーを使用して約4.7時間かかります。1.42TBの一時的なステージングストレージが必要で、外付けでもよく、後で解放できます。
実行
./waste plan ~/models/k3.waste
./waste run ~/models/k3.waste "The capital of France is" -n 32
./waste chat ~/models/k3.waste
理由がない限り--budgetを設定しないでください。デフォルトでは、WASTEは安全なメモリ予算を選択し、モデルの下限を下回ると起動を拒否します。コンテナ内では、ホストのRAMではなくcgroup制限に基づいてサイズを調整します。
マルチモーダルとサーバー
Kimi K3はマルチモーダルであり、WASTEは画像をサポートしています：
./waste run ~/models/k3.waste "Describe this image" --image photo.jpg
./waste run ~/models/k3.waste "Compare these images" --image before.png --image after.png
インタラクティブモードでは、/image FILEで次のメッセージに画像を添付します。896×896の画像は256のプロンプト位置を使用し、各位置は約2.8秒の言語モデル時間を要します。
WASTEにはオプションのOpenAI互換サーバーも含まれています：
make libwaste.dylib # Linuxではlibwaste.soを使用
python3 -m serve ~/models/k3.waste --port 8000
curl localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"k3","messages":[{"role":"user","content":"Why is the sky blue?"}]}'
ストリーミング、ツール、構造化出力、思考制御、画像をサポートしています。
ライブラリと検証
WASTEは組み込み可能なCライブラリでもあります。CLIとサーバーはどちらもsrc/waste.hの公開APIを使用しています。推論パスはlibcとpthreadsのみに依存しており、BLAS、Python、CUDA、その他の外部依存関係はありません。
検証は厳格です。すべてのレイヤーはPyTorchリファレンスと照合され、最終ロジットは3.6e-06以内で一致し、ビジョンタワーはオラクルと2.3e-06以内で一致します。モデルフリースイートは合成コンテナを構築し、実モデルチェックは変換の往復とサーバーのプロンプトレンダリングを検証します。
プロジェクトの状況と哲学
フォーマットとAPIは固定されていません。K3が主なターゲットであり、最もテストされたモデルです。CPUパスは現在最速の測定実装ですが、CUDA、Metal、その他のハードウェア固有の最適化はまだ探求されていません。プロジェクトは失敗したアイデアと否定的な結果のためにdocs/LEARNED.mdファイルを維持しています — これは珍しく価値のある実践です。
測定はマーケティング数値ではなく実験結果として扱われます。それぞれが取得されたハードウェア、コンテナ、構成、コミットに結び付けられています。不安定な測定は範囲として報告され、後に誤りと判明した結果もそのまま記録されます。
最終的な考え
WASTEは、フロンティアモデルにはデータセンター規模のインフラが必要という前提に挑戦する大胆な実験です。NVMeから重みをストリーミングし、MoEのスパース性を活用することで、2.78Tパラメータのモデルをノートパソコンにもたらします。遅いですが、動作します — そしてApache 2.0の下でオープンソースです。
ローカルAIの限界を押し広げることに興味がある開発者なら、WASTEは一見の価値があります。まずはKimi-Linear（19GBコンテナ、10.7 tok/s）でエンジンの感触をつかみ、その後フルK3体験を検討してください。プロジェクトは特に新しいハードウェアバックエンドやパフォーマンス実験への貢献者を歓迎しており、否定的な結果も評価されます。
完全なドキュメント（コンテナ形式、バックエンド比較、研究の方向性を含む）については、GitHubリポジトリをチェックしてください。