🫑tech.miyabitti
Markdownmdで開く

RTX 3070 (8GB VRAM) で27Bモデルが34tpsで爆速動作!「Bonsai 2 27B」環境構築&限界ベンチマーク検証記

2026年9月17日リリースの3値量子化モデル「Ternary Bonsai 2 27B」をRTX 3070環境へ導入。KVキャッシュ最適化、コンテキスト長とスワップ限界の実測データ、Web検索ツール連携まで徹底検証。

目次

X(旧Twitter)を見ていたら、とんでもなく軽い容量のモデルである、Bonsai 2 27Bというものが発表されていて普段使いのPC(RTX3070 8GB VRAM)で動くか気になったので検証させてみました。

大して使ったわけじゃないですが、2年半前に動かしてみたGemma2JPNというモデルはお話にならないレベルだったのですが、めちゃくちゃ簡単なタスクなら実用可能なレベルの出力+速度もまあまあだったので記録として残しておきます。

Warning

タイトルから何からAIに書かせています。


※ 以下、AIが書いた文章です。

2026年9月17日、PrismML社よりオープンウェイト言語モデル 「Ternary Bonsai 2 27B」 がリリースされました。

本モデルは、Qwen3.8-27B をベースに最新の3値量子化(Ternary: 、約1.76 bit/weight)とHadamard rotation技術を適用したもので、元のフル精度(FP16で約54GB)から 約5.95 GB へと約9分の1に圧縮されています。また、元モデルの 98.2% のベンチマーク性能を維持 しているとされています。

「一般的なミドルレンジGPU(VRAM 8GB)環境で、27Bクラスのモデルが完全GPUオフロードでどこまで実用的に動作するのか?」

本稿では、NVIDIA GeForce RTX 3070 (8GB VRAM) 環境における環境構築から、KVキャッシュの最適化、限界コンテキスト長の調査、スワップ発生時の挙動、Web検索(MCP)連携までの検証記録をまとめます。


#1. 検証環境スペック

  • GPU: NVIDIA GeForce RTX 3070 (8,192 MiB VRAM / メモリ帯域幅 448 GB/s)
  • OS: Windows 11 (PowerShell)
  • NVIDIA Driver: 596.49 / CUDA: 12.4+ (13.2)
  • 推論ランタイム: PrismML fork版 llama.cpp (CUDA 12.4 最適化ビルド)
  • ベースモデル: prism-ml/Ternary-Bonsai-2-27B-gguf (Apache 2.0)

#2. 環境構築のポイント:PTQ1_0 vs PQ2_0

Bonsai 2 27B の GGUF リポジトリには、主に2つのバリアントが存在します。

バリアントファイルサイズ特徴8GB VRAM環境での適性
PTQ1_0約 5.95 GB1.76 bpw の高密度3値パッキング最適(全層GPUオフロード可能)
PQ2_0約 7.21 GB2-bitスロット展開型(アンパック高速)❌ OS使用量と合わせて8GBを超過

Windowsでは通常、OSやブラウザ等の描画でアイドル時でも約 1.5〜1.8 GB の VRAM が消費されています。
そのため、実質的に利用可能な空きVRAMは 約 6.4 GB 前後です。

  • PQ2_0 (7.21GB) だと、空き容量を超えてしまい即座にメインメモリへのスワップが発生します。
  • 一方、PTQ1_0 (5.95GB) であれば、RTX 3070 の空きVRAM内に全レイヤーがすっぽり収まる ため、8GB環境では PTQ1_0 の選択が前提となります。

#セットアップ手順

公式デモリポジトリ(PrismML-Eng/Bonsai-demo)を取得し、Windows PowerShell で環境変数を設定して実行します。

Terminal window
# 1. リポジトリのクローン
git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo
# 2. モデル指定(bonsai2 27B)とPTQ1_0バリアントの指定
$env:BONSAI_FAMILY = "bonsai2"
$env:BONSAI_MODEL = "27B"
$env:BONSAI_QUANT = "PTQ1_0"
# 3. セットアップスクリプト実行 (CUDAバイナリとモデルが自動取得されます)
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup.ps1

※ Bonsai 2 は特殊な三値カーネルを必要とするため、通常の mainline llama.cpp や Ollama ではロードできません。上記スクリプトが自動ダウンロードするフォーク版バイナリを使用する必要があります。


#3. RTX 3070 向け限界ベンチマーク検証

モデルの全層オフロードに成功した環境で、「どこまで長いコンテキスト長を取れるか」「どれくらいの速度(tps)が出るか」 の測定を行いました。

#① KVキャッシュ量子化別のスループット比較 (llama-bench実測)

まず、KVキャッシュ(過去の文脈を記憶するメモリ領域)の方式を変えて llama-bench.exe で計測しました(Prompt 512 / Gen 64, Flash Attention ON)。

KVキャッシュ方式Prefill (Prompt処理)Decode (テキスト生成)メモリ消費総合評価
Q8_0 (-ctk q8_0 -ctv q8_0)376.7 t/s34.5 t/sFP16の半分最優秀(最高速&精度ロス極小)
FP16 (標準)339.7 t/s31.8 t/s基準(大)高速だがメモリ消費が大きい
Q4_0 (-ctk q4_0 -ctv q4_0)323.9 t/s29.3 t/sFP16の約1/3.5超省メモリ(長文専用)

実測の結果、Q8_0 KVキャッシュ が FP16 よりも高速かつメモリを半分に削減できることが確認されました。

#② コンテキスト長とスワップ限界の実測比較

続いて、コンテキスト長(-c)を段階的に引き上げ、実際のテキスト生成速度(Generation tps)をテストしました。

設定モードコンテキスト長KVキャッシュ生成速度 (tps)状態
最高速モード (推奨)24,576 (24k)Q8_033.8 t/sGPU完全オフロード・爆速
限界付近28,672 (28k)Q8_033.5 t/s安定動作
スワップ発生32,768 (32k)Q8_00.9 t/s⚠️ 8GB超過によりPCIeスワップ発生
超長文モード32,768 (32k)Q4_033.7 t/sGPU完全オフロード・爆速
超長文モード49,152 (48k)Q4_032.9 t/sGPU完全オフロード・爆速
スワップ発生65,536 (64k)Q4_03.8 t/s⚠️ 8GB超過によりPCIeスワップ発生

#⚠️ スワップした瞬間に 34 t/s → 0.9 t/s に急落する理由

検証中、32k (Q8_0) や 64k (Q4_0) に設定した途端、生成速度が 0.9〜3.8 tps(約37分の1) にまで落ち込みました。

これは、VRAM(8GB)から溢れたKVキャッシュが PCIeバスを経由してメインRAM(共有GPUメモリ)へと退避(スワップ)されたため です。

  • RTX 3070 の VRAM帯域幅: 約 448 GB/s
  • PCIe 4.0 x16 / メインRAM帯域幅: 約 15〜30 GB/s(15分の1以下)

LLMは1トークン生成するごとにメモリ全域を参照するため、溢れたデータへのアクセスがボトルネックとなり、1秒に1文字程度しか出力されなくなってしまいます。

したがって、RTX 3070 では以下の2つのモードを使い分けるのが最適解となります。

  • 日常使い・コーディング支援: 24kコンテキスト + Q8_0(最高速 34 tps)
  • 長大なドキュメント・ログ解析: 40k〜48kコンテキスト + Q4_0(安定 33 tps)

#4. 最適化済み起動スクリプト

手軽に起動できるよう、検証に基づいた最適化オプションを組み込んだ PowerShell スクリプトを作成しました。

#① コンソール対話ランチャー (run_bonsai_chat.ps1)

Terminal window
# 通常起動: 24kコンテキスト / Q8_0 (~34 tps)
.\run_bonsai_chat.ps1
# 超長文モード: 40k〜48kコンテキスト / Q4_0 (~33 tps)
.\run_bonsai_chat.ps1 -LongContext
# ワンショット実行
.\run_bonsai_chat.ps1 -Prompt "こんにちは!自己紹介をお願いします。"

実際の対話ログ(思考プロセス含む):

> こんにちは!自己紹介をお願いします。
[Start thinking]
...
[End thinking]
こんにちは!私はQwenです。
自然言語モデルのAIアシスタントで、質問への回答、文章作成、翻訳、コード作成、アイデア出し、情報整理など、さまざまなタスクをお手伝いできます。
あなたの仕事や勉強、趣味など、どんなことでも協力できますので、気軽に話しかけてくださいね!
[ Prompt: 137.4 t/s | Generation: 33.8 t/s ]

日本語の出力も自然で、思考(Reasoning)を行いながらも 33.8 tps でスムーズに出力されます。

#② WebUI & OpenAI互換APIサーバー (start_bonsai_server.ps1)

Terminal window
.\start_bonsai_server.ps1
  • ブラウザUI: http://localhost:8080 でChatGPT風のチャットUIが開きます。
  • OpenAI互換API: http://localhost:8080/v1 でエンドポイントが立ち上がり、Cursor や VS Code、Goose などのAIエディタからそのまま接続できます。

#5. Web検索ツール (Tool Calling / MCP) との連携

Bonsai 2 27B は Qwen3.8 ベースのため、ネイティブな Tool Calling(関数呼び出し) および MCP(Model Context Protocol) に標準対応しています。

ローカルLLMに最新のWeb情報を検索させるには、以下の方法が利用できます。

  1. 付属WebUIで Brave Search MCP を接続(公式推奨):
    • Brave Search API で無料キー(月2,000回まで無料)を取得。
    • npx -y @brave/brave-search-mcp-server --transport http --host 127.0.0.1 --port 8001 を起動。
    • http://localhost:8080 の Settings → MCP Client に登録すると、チャット欄からワンクリックでWeb検索を有効化できます。
  2. ブラウザ拡張機能「Page Assist」を使う:
    • Chrome / Edge 拡張機能の Page Assist に http://localhost:8080/v1 を登録。
    • 画面の「Web Search」トグルをONにするだけで、DuckDuckGo 経由でリアルタイム検索しながら回答させることが可能です。

#6. まとめ

項目検証結果
モデルサイズ元54GB → 5.95 GB (PTQ1_0)
GPU適合性RTX 3070 (8GB VRAM) に 全層完全オフロード 可能
生成速度33.8 〜 34.5 tokens/sec(実用的な速度)
実用コンテキスト長24k (Q8_0) 〜 48k (Q4_0) までスワップなしで安全に拡張可能
ツール対応ネイティブ Tool Calling / MCP (Web検索等) 完全対応

27Bクラスのモデルを動かすには、従来であれば最低でも 24GB〜48GB 以上のVRAM(RTX 3090/4090や複数GPU構成)が必要とされていました。

今回の検証により、8GB VRAMのコンシューマー向けGPU(RTX 3070)であっても、適切な量子化バリアント(PTQ1_0)とKVキャッシュ設定(Q8_0/Q4_0)を選択することで、思考プロセス付きの27Bモデルが 34 t/s という実用速度でローカル動作可能 であることが確認できました。