ハクソク

世界を動かす技術を、日本語で。

29GBのRAMを使用して、0.50トークン/秒でKimi K3を実行する

2026年7月31日原文(github.com)

概要

  • WASTE は、巨大な2.78兆パラメータモデル（Kimi K3）を 一般消費者向けノートPC で動作可能にするC製推論エンジン
  • モデル全体はRAMに収まらず、必要なエキスパートのみを ストリーミングでディスクから読み込み、残りのRAMはキャッシュに活用
  • 依存ライブラリなし・自己完結型、PyTorch基準で検証済みの高精度
  • パフォーマンスは遅いが実用的 （0.5トークン/秒）、消費者PCでのトリリオン級モデル動作実証
  • ネットワーク不要・完全ローカル で大規模モデル利用を可能にするアーキテクチャ

WASTEエンジンとKimi K3モデルの特徴

  • WASTE はC言語のみで書かれた 埋め込み可能な推論エンジン、サードパーティランタイム依存なし
  • Kimi K3 ：2.78兆パラメータ、変換後982 GiBコンテナ、 64 GB RAMのMacBook Pro で動作実績
  • モデルは圧縮・削減なしの完全版、混合エキスパート方式で1トークンあたり約4%のみ活性化
  • モデル本体（trunk）は常駐メモリ、エキスパートはディスクからオンデマンドで読み込み、 RAMはキャッシュに最大活用
    • 例：64 GBマシンで46 GBを予算に設定し、うち17.56 GBがエキスパートキャッシュ
  • CLI利用例 ：waste run ~/models/k3.waste 'What is the capital of Italy?' → 「The capital of Italy is Rome.」

技術的アプローチと仕組み

  • モデル変換 ：一度だけJSONマニフェスト＋常駐trunk＋各レイヤごとのエキスパートバンクに分割
  • エキスパートは1つのreadでアクセス、各レコードは4 KiBアライン、ゲート・行列隣接配置でI/O最適化
  • ページキャッシュをバイパス （macOS: F_NOCACHE, Linux: O_DIRECT, Windows: FILE_FLAG_NO_BUFFERING）
  • エキスパート重みは3ビット量子化 （Residual Vector Quantization）、行列はそのまま展開せず部分積テーブルで計算
  • キャッシュ設計 ：1トークン分の作業セット（K3で17 GB）を超えて初めてヒット率が向上
    • 32 GB予算：ヒット率0%、46 GB：13%、58 GB：37%だがページアウトで逆に遅くなる
  • 自己調整型メモリ割当 ：OSのページアウトを避けつつ最大効率となるようキャッシュ予算を自動調整

パフォーマンス・要件

  • Kimi K3 ：982 GiBコンテナ、RAM 29.05 GB以上（4Kコンテキスト）、64 GB推奨
    • 内部NVMe必須（12.78 GB/s）、USB経由だと極端に低速化（0.94 GB/s）
  • Kimi-Linear 48B ：19 GiBコンテナ、RAM 1.87 GB以上、10.7 tok/sで動作
  • 自己完結型バイナリ ：libwaste.aとwasteバイナリのみ、BLAS/CUDA/Python不要
  • API公開 ：Cヘッダから26関数、RAM上限指定→モデルオープン→生成→セッション保存/終了

工学的な工夫・限界

  • I/Oと演算のオーバーラップ で1.6倍高速化
  • キャッシュサイズ増加や読み込みバイト削減 は効果なし（機械の物理制約による）
  • 今後の改善余地 ：より高速なディスクや大容量RAMマシンの利用
  • キャッシュは「一単位分」ごとにしか価値がない、中途半端な増加は逆効果
  • 線形アテンションと小型KVキャッシュ ：Kimi Delta Attention + Gated Multi-head Latent Attentionで効率化
    • 4Kコンテキストで11.25 GB→0.21 GBにキャッシュ削減

WASTEの意義と哲学

  • API利用やクラウド課金なし、完全ローカルで巨大モデルを活用
  • K3専用設計ではなく、任意のMoEモデルに適用可能
  • 測定値はすべてコミット時点で検証済み、誤りは履歴に明記
  • 「クラウドで消費されるトークンの二重支払い」へのアンチテーゼ
  • WASTE は「その無駄なトークン消費を終わらせる第一歩」

導入要件まとめ

  • ディスク ：変換後コンテナ982 GB（実質1 TB必要）、元シャード変換用に1.42 TB一時領域
  • RAM ：K3で最低29.05 GB、実用は64 GB推奨
  • ストレージ速度 ：内部NVMe必須、USB外付け不可
  • ビルド ：C11コンパイラとmakeのみ、追加ライブラリ不要

まとめ

  • WASTE は、 消費者PCでトリリオン級モデルをローカル実行 する新たな実装例
  • I/O最適化・キャッシュ設計・量子化技術 で「現実的な速度と精度」を両立
  • 今後は高速化・大容量RAM環境での展開が課題
  • APIおよびCLIで容易に組み込み・利用可能 な自己完結型エンジン
  • 完全ローカル・プライバシー重視・コスト削減 を志向するエッジAIの新しい潮流

Hackerたちの意見

あのREADMEは「これ、LLMが書いたな」って直感が働くよね。コードベースもLLMが書いてるんじゃないかな？

└

Contributors >... >claude 予想する必要はないよ。もし誰かが怠けすぎてclaudeにコードをコミットさせるようなことをしてるなら（つまり、自分でgit commitを実行するのも面倒くさいってこと）、そのコードをレビューした可能性は低いね。

└

俺はたくさんのソフトウェアを書いてきたし、手作りのプログラミング言語もあるよ。https://github.com/marcobambini/gravity。今は自分のスキルを使ってLLMやエージェントをオーケストレーションしてるんだ。もっと早く、より良いコードが書けるよ。開発者として、新しい技術に適応するか、絶滅するかの選択ができるんだ。

└

LLMに関連するプロジェクトが純粋に人間の努力になると思ってる人いるの？新しいルールを作ろうぜ：LLMの書いたものに文句を言うのは、その製品がLLMと全く関係ない時だけにしよう。

└

せめてこの著者たちにはLLMが生成したREADMEを読んでほしいよ。めちゃくちゃ理解しづらいからね。LLMは読者に対する理論がすごく限られてるから、外部の読者がプロジェクトの開発に関する全ての文脈や決定の歴史にアクセスできると思い込んでるんだ。これらの決定やユーザーからの指示はモデルには非常に重要だけど、外部の読者には「完成した」製品を見る上でほとんど関係ない。だから、こんな文が出てくるわけ：「レバーがあった場所は今は違う。専門家の読みを算術と重ねるのは約1.6倍の価値があって出荷された；見た目が大きい二つは — トークンあたりのバイト数を減らして、RAMにもっと保持すること — 両方とも測定されて、拒否された。一つはこのファミリーのルーターに降格するためのテールがないから、もう一つはマシンが常駐できないキャッシュはどんな値段でも買えないから。」これ、何を意味してるの？明らかに内部の開発決定で、Claudeが大好きな全く理解不能な内部用語を使ってる。もし人々が自分たちが出版するものを読んでくれたら、すぐにおかしいって気づくと思う。俺はLLM嫌いじゃないし、たくさん使ってるし、複雑なコードを書くのにはすごく役立つのは否定できない。でも、最初のドラフトは本当にクソみたいな文章になるんだよね。

└

それって重要？

└

うーん、「浅い否定」に見えるのは嫌なんだけど、プロジェクトのドキュメントがモデルを本当にネイティブ精度で動かしてるかどうかで自分自身に矛盾してるみたいだね（主張されてる3ビット量子化は面白いかもしれないけど）。それに、29GBのRAMで2秒/トークンを達成するっていう見出しの主張は、K3についてわかってることを考えると、全く意味不明だよね（ネイティブ精度で密なパラメータだけで約115GB、トークンごとに約25GBのアクティブスパースエキスパート、KVキャッシュのための比較的小さなフットプリントもあるし）。これはあんまり役に立たないな。

└

うん、でもすごく遅いよ。

└

その通り。誰でもフラグを外して、典型的なLLMのダメな部分を取り除けるよ。俺はそれのために簡単なツールをCIの一部として作ったんだ。https://github.com/jv-k/deslopper

└

確かに一番「クラウディ」だね。変な感じだけど、頭の中に他の人の書き方のためのメンタルモデルを置く場所の隣に、クラウドがデフォルトで生成する短くてカクカクしたダイアリアのためのスポットができてるみたい。

もしこのMacが30-50W使うなら、それは40-60 tok/Whってことだよね…対して、現代のGPUクラスターは多分80kくらい？だから、SSDストリーミングには約1000-2000倍の電力が必要ってことだ、残念ながら。

└

Kimiを保持して動かすのに必要なGPUは、初期投資コストが全然違うんだよね。

Hacker Newsで議論の続きを見る