VRAM10GBのAIエージェント ～Bonsai2 x KVarNでVRAMを超節約 256kも夢じゃない～

こんにちはRcatです。
少し前にこちらの記事で、Bonsai2について触れました。
こちらでは結論として、ギリギリ12GB(128k時)に何とかおさまるという結論でしたが、今回はここからさらに下げて10GBで収めてしまえという話になります。
これによりRTX3080、2080Tiなどの10GB帯のGPUでも爆速動作が期待できます。
また、16GBあればMTP & 256kコンテキストも可能です。

はじめに

利用規約

情報や作品の活用時は事前に利用規約をご確認ください。

コメントについて

利用規約のガイドラインを確認の上コメントしてください。
則っていないコメントは削除します。

免責

`Geminiで生成`と書いてある画像はAIによるイラストです。
雰囲気が伝われば中身の細かい内容(主に文字)は間違っていても許容しています。
ご了承ください。

概要

VRAM10GBってどういうこと?

前回の記事では、Bonsai2を128kコンテキストで読んだ場合、11.7GBのVRAMを占有しました。

モデルってサイズいくつでしたっけ?
→6.7GB

つまり、5GBが128kコンテキストによるKVキャッシュ。
しかもQ8量子化なのですでに本来の半分の状態でです。
ということなので、これをあと半分くらいに小さくできればVRAM10GBにおさまる計算になります。

Q4/Q4はやめとけ

これは数値的なデータを提示できないのですが、KVキャッシュをQ8にしたときとQ4にしたときで、ペアプログラミングをすると体感で差が出ます。
ミスが増えたり理解が浅くなったりしてイライラしてきます。

Bonsaiはそもそもモデルを極限まで量子化していますので、ここをさらに削ると致命傷になりかねません。
ですので、llama.cpp標準のQ4 KVキャッシュは用いません。

精度を維持したKVキャッシュ圧縮 KVarN

KVキャッシュを精度を維持しながらさらに量子化するための技術です。
Huaweiが開発したらしいです。大昔P20とか使ってたなw。

GoogleのTurboQuantに比べて、Kの方も圧縮できるという特徴があります。

通常KVキャッシュは"K"側はもろに影響が出るので圧縮しないのが基本で、TurboQuantではQ8/t3のような非対称で使っていました。
しかし、KVarNはどっちも圧縮できるので、K5/K4のように圧縮してしまえるのがポイント。

上記推奨値の場合、Turboは5Bit、KVarNは7Bitの削減に成功しており1.4倍の圧縮効率です。

Bonsai × KVarNの実力

VRAM10GBを切る衝撃

結論から言うとこのような状態になりました。
無負荷で1.5GB前後使っているので、読み込み時はそれを差し引くとBonsaiが使用しているメモリ量になります。

256kコンテキストも視野に

VRAM10GBで128kが入ってしまうのも驚きですが、Bonsai2の対応上限である256kコンテキストまで拡張してもまだ余裕がある状態に持ってくることができました。

また、有志のモデルがMTPヘッダをつけてくれたものがあったので、それをロードしても16GBならまだギリギリセーフです。

パフォーマンス

素のBonsai2の時のログがこちら。1700/65くらいですね。

KVarN適用時がこちら。
若干前処理が重くなりましたが誤差ですね。

prompt eval time =    7319.74 ms / 11654 tokens (    0.63 ms per token,  1592.13 tokens per second)
       eval time =   57229.43 ms /  3550 tokens (   16.13 ms per token,    62.01 tokens per second)
      total time =   64549.16 ms / 15204 tokens

MTP有効時がこちら。これ受容率80%超えれば100t/s行くのでは?
なおヘッド分また少しだけ前処理が遅くなります。

prompt eval time =    7791.21 ms / 11654 tokens (    0.67 ms per token,  1495.79 tokens per second)
       eval time =   22505.39 ms /  2036 tokens (   11.06 ms per token,    90.42 tokens per second)
draft acceptance = 0.54573 ( 1062 accepted /  1946 generated), mean len =  2.09

BonsaiをVRAM10GBで動かすには?

これまでの話を聞いていれば、Q4/Q4ならすでに10Gでも動くのはお分かりだと思います。
しかしそれだと128kコンテキストでは後半記憶があいまいになるリスクがあるので、動くだけで"使える"わけではありません。

というわけで、BonsaiにKVarNを取り込んでしまいます。

KVarNに対応したフォーク beellama.cpp

前提として、素のllama.cppはKVarNに対応していません。
対応しているのは下記llama.cppのフォークになります。

Qwen3.8 27Bなどは読み込めるので、もし使えるならそれで動かすのもおすすめ。27B DenseはKVキャッシュ大きいですからね。

Bonsaiに対応した専用フォーク

さて、ここで問題が。
Bonsaiって専用のフォークなんですよねぇ。
何が言いたいかというと、フォーク同士が何も言わずに合流してくれる可能性なんてまずない。

フォークをマージしよう!

概要

結論これです。双方が別々のフォークで合流する可能性が限りなく低いなら自分でマージするしかない。
しかし、推論エンジンという高度なC++をマージできるだけの技量は私にはない。

どうするか? アレに決まってるでしょ。

おねがい! Qwen3.8 Flash

でました! Qwen3.8 Flash Nextです。
こちらの記事で紹介しているモデルで、現在の私の主力ローカルLLMです。

このモデル、まだ正直底が見えないんですよね。
今はAndroidアプリ作らせたりしてますが無理とは言わない。つまり今のところ何が限界なのかよくわからないこと。
Claude Opus4.6超えと言われるだけあると思います。

では、このモデルにマージを丸投げしてみましょう
これができたとしたら正直やばいと思います。ローカルLLMが高度なC++エンジンをフォークってできたらすごいと思いませんか?

マージ開始

というわけでマージ開始です。
環境はいつものです。

前提

今回のマージはちょっと特殊な環境で行っています。

• AI PC(EVO-X2)
  ローカルLLM推論用のPC。ここでQwenが動いている。
  OpenHandsもここ

• Rcat PC v3
  普段使いのWindows PC。自作。
  RTX5070Tiが載っており、Bonsaiを使うのはこっち。

そのため、基本的な作業はAI PCの方で行いますが、ビルドと動作テストは物理的にNvidiaのGPUがないと無理なので、メインPCの方につないでやってもらう構成です。

テスト用の環境を用意する

マージ環境とは別に、CUDA環境のPCでテストやビルドができるようにして置きます。

というわけでこちら!
そう、SSHで待機するCUDAコンテナです。
つまりAI PCで作業しているAIエージェントに、SSHでメインPCにリモートアクセスしてもらってビルドや動作チェックをしてもらいます。
こうすることで、PCや環境をまたいだ作業もこなすことができます。
コンテナなのでメインPCの重要な部分をいじられる心配もありません。

Dockerfileはこちら。
ベースイメージをcudaにすることで環境構築の手間を省きます。
パスワードは好きに決めてください。ユーザー名は安定を優先してデフォルトのubuntuユーザーをそのまま使います。

接続ができないと作業が止まってしまうので、最初にちゃんとつながるか確認してもらいます。

マージ指示を検討する

具体的な指示は成功率に直結します。
今回は100行程度の指示を綿密に作成して投入しました。
チャットではなく、PLAN.MDとして格納する感じです。

ポイント

• 目的を書く
  何のために何をしたいのかを書く。
  どこのソースをどのようにというレベルで指示できない以上、目的から何をすべきか判断できるだけの材料が要ります。

• リポジトリの概要を教える
  事前情報があったほうが作業が入りやすくなります。
  特に、今回はKVarNとPQ2_0量子化を使うためにこのリポジトリを持ってきたことを明記します。
  それ以外の対応も入ってる可能性があるので、ここで言わないと全部マージしようとして事故るでしょう。

• 手順を指定する
  今回は分析、ベース決定、作業、ビルド、テスト、納品の手順を指示しました

• 制約をしっかり
  やることとやらないことをはっきり書かないとスコープがあいまいになり事故率が上昇します。
  今回は、CUDAだけ、PQ2とKVarNだけ、llama-serverだけと書いています。それ以外は壊れてよいと書くことで作業量軽減もできます。

• 環境情報
  ビルド&テストは別マシンなのでそのことをしっかり書いておかないと、作業空間でやろうとします。
  OpenHandsにはGPUアクセス権を与えてませんし、そもそもRadeonなのでここでCUDAビルドできない。

• モデルは用意する
  勝手にDLさせると何を持ってくるかわからないので、事前に動くことがわかっているものを用意しておきましょう。
  これが動くのがゴールですと書くとよいです。

開始する

準備ができたら作業開始です。
指示書は作ったので、それを読むようにとだけ言って開始。

おやすみなさい zzz ←寝ましたw

朝起きたら終わってました。
5時間ちょいで終わったっぽいですね。なお、この後テスト時にMTPモデル使ってなかったのでそれやった?と一言突っ込んで動かなかったみたいなので修正が入りますが、すぐ終わりました。

結果

マージできました。ローカルLLMでマージできちゃうんですね…

というわけで結果がこちら。
入力は33Mで出力が思ったより少ない300k程度。
価格は「もしClaudeだったら」設定です。ローカルなので実際は0円。

まとめ

今回は超小型AIエージェント、BonsaiをVRAM10GB以下で動作させるためにKVarNを導入しました。

副作用として、16GBモデルなどでは256kコンテキストが視野に入るうえ、MTPヘッドまで載せられる始末です・・・。
本格的にコンシューマー向けのハードでもガンガン開発を進められる準備が整いつつあります…。

それではまたお会いしましょう

配布情報

配布URL

以下のURLより配布しています。
利用規約に同意の上ご利用ください。

https://script.google.com/macros/s/AKfycbxdcr8pnazR7RbjaSICTtaNWfN7h_rjQrKlZ3h9CZpPRFzRILk1OGc8mZqKbF-NXNO9/exec?name=Bonsai-KVarN

リンク集

感想投稿フォーム

コメントは公開で恥ずかしい!! Rcatだけに送りたい人向け

メンバーシップの説明

Docker-Composeマネージャー

【ローカルLLM】バイブコーディング完全ガイド

【ローカルLLM】ローカルLLM活用三本柱

【ローカルLLM】仕様駆動開発で、下流を丸投げ!

【ローカルLLM】OpenHandsで丸投げ開発

【ローカルLLM】自己成長AIエージェントHermesをホスト

【ローカルLLM】完全ローカルでAndroidアプリを開発!?

ミニPCにLinuxをインストール

メンバーシップ特典