ここ最近、ローカルLLM周りの話題の流れがいよいよ早くなってきたなと感じています。新しいモデルが発表されたかと思えば、翌週には量子化版が公開され、その次の週には本家llama.cppにマージされて…というペースで、ちょっと目を離すとすぐ置いていかれそうになるんですよね。
そんな中、ふと自分の業務PCを見て「あれ…これでAI開発とかできるんだろうか…」と思う方も多いんじゃないかなと思います。業務用PCって、GPU非搭載のスリムなモデルだったりすることが多くて、SNSで流れてくる「RTX 4090でローカルLLM爆速!」みたいな記事を見ると、正直ちょっと遠い世界の話に感じたりするんですよね。
でも最近、その「遠い世界」の方がどんどんこっち側に近づいてきていて、その象徴みたいなモデルが1ヶ月ほど前に登場しました。PrismML社の「Bonsai」 という1bit LLMです。
- 8Bパラメータのモデルが たった1.15GB
- Apache 2.0ライセンスで商用利用OK
- GPU非搭載の普通のPCでも動く
発表直後はSNSでもかなり話題になっていて、自分も「これはすごい」とすぐ飛びつきそうになったんですが、少し時間を置いてから触るのもアリかなと思ってちょっと寝かせていました。 1ヶ月経つと、初期のお祭り感が落ち着いて、実際にどこまで使えるモデルなのか、どのツールで動くのか、を冷静に見られる タイミングかなと思います。
今回はこの Bonsaiを、手持ちの中でAIにはパワー不足な環境(GPU非搭載PC)から試してみた という実験ログです。Windowsネイティブだけで完結する構成 にしたので、WSLの準備も不要です。業務PCしか持っていない人でも、そのまま真似できるようにしました。
⚠️Bonsaiは2026年3月末に公開されたモデルで、本記事は発表から約1ヶ月経った時点での実験記録です。ツールのサポート状況は日々変わっていくので、最新情報は必ず公式を確認してください。公式情報: prismml.com / HuggingFaceモデルカード
- 1. Bonsaiってどういうモデルなの?
- 2. 今回使う2台のPC
- 3. ツールの対応状況を先に整理しておく
- 4. Step 1: llama.cppのWindowsバイナリを用意する
- 5. Step 2: Bonsaiモデルの取得 〜 -hf オプションが便利
- 6. Step 3: まずCPUで動かしてみる
- 7. Step 4: Vulkanに切り替えてiGPUを使う
- 8. Step 5: AMD機でも測ってベンチ比較
- 9. 比較
- 10. 実験結果
- 11. 1ヶ月経って冷静に見えてきたこと
- 12. おわりに
- 参考リンク
1. Bonsaiってどういうモデルなの?
かなり省略して表現するならば「LLMの重みを、全部 +1 か −1 のどちらかに圧縮してしまった」モデルです。
普通のモデルは1つの重みに16bitとか8bitを使っていますが、Bonsaiは 1bit。2の1乗、つまり「プラスかマイナスか」の2値しかありません。にもかかわらずQwen3 8Bなどの同サイズ帯モデルと競える性能を出しているので、業界がざわついた、という感じです。
https://cdn.prod.website-files.com/699604cc2b9dd89bdbda0608/69c95988a858e3b0a355401e_64b61e17.png
自分がこれを見て面白いと思ったのは、大げさかもしれないけど、「もうクラウド前提じゃなくてもいいんじゃない?」 という点です。
会社の業務PCは、GPU積んでないことがほとんどだと思います。でもBonsaiみたいなモデルが実用になってくると、業務PCそのままでローカルAIアシスタント みたいな話が、2026年内には現実的になっていく可能性を感じさせます。実際、ビジネス的には「社外にデータを出したくない業務」のほうが圧倒的に多いので、ここは本当に大きい変化といえるでしょう。というわけで、試す価値は十分にあります。
2. 今回使う2台のPC
今回の趣旨は「AIにはパワー不足な環境から試す」なので、使うのはGPU非搭載のPC 2台です。
| 呼び名 | CPU | RAM | iGPU | OS |
|---|---|---|---|---|
| Intel機 | Intel 12th gen | 32GB | Iris Xe(iGPUのみ) | Win11 |
| AMD機 | Ryzen 9 6950H | 32GB（VRAM 8G割当） | Radeon 680M(iGPUのみ) | Win11 |
どちらも「iGPUしか載っていない、ごく普通のPC」という点で共通です。
なぜあえてGPU非搭載機から始めるのか
理由は3つあります。
- Bonsaiの売りはそもそも「小さい・速い・省電力」。この魅力が一番光るのは、AIにはパワー不足とされる機体の側
- 一般社員の方が手にするのは、ほとんどの場合GPU非搭載のPC。多くの人にとって再現性の高い構成 から書きたい
- 「RTX 4070 Tiで動きました」という記事は世の中にいくらでも出るので、GPU非搭載機での実測値は日本語情報がまだ少ない
というわけで、Intel機を主役にCPU推論→Vulkan推論と段階を踏んで、最後にAMD機でiGPU同士の比較までやってみようと思います。2台でiGPUメーカーが違うので、比較としてもちょうど面白い組み合わせですよね。
3. ツールの対応状況を先に整理しておく
Bonsaiは1bit量子化という特殊な形式(GGUFの Q1_0 タイプ、内部的にはtype 41)を使います。これが曲者で、「普段LLMを動かしているツール」がまだ追いついていない ケースが多いんです。
自分自身、最初は「LM Studioでサクッとモデル差し替えるだけじゃないの?」と思っていたのですが、見事にハマりました。同じところで詰まる人が出ると思うので、先に現状をまとめておきます。
| ツール | Q1_0対応 | 状況 |
|---|---|---|
| 本家 llama.cpp (CLI/server) | ✅ 対応済み | Windows/Linux/macOSのプリビルドバイナリそのまま使える |
| LM Studio 0.4.5 | △(実機NG) | モデル検索にはBonsaiが出るようになったが、ロード時に別エラーで落ちる(後述) |
| Ollama | ❌ 未対応(2026/4時点) | 対応PRはOpen状態。有志フォークでは動いている例あり |
| AnythingLLM | △ | Custom GGUFインポーター経由で動かしている報告あり |
LM Studio 0.4.5 で動かない(自分のハマり記録)
先ほども言いましたが「LM Studioでサクッとモデル差し替えるだけじゃないの?」と思っていました。実際、LM Studio 0.4.5 の モデル検索ではBonsai-8Bが普通にヒットします。検索結果から prism-ml/Bonsai-8B-gguf を選んでダウンロードまでは問題なく進むんですよね。
でもロードしようとすると、こんなエラーに遭遇しました。
🥲 モデルの読み込みに失敗しました Attempt to pull a snapshot of system resources failed. Error: 'System resources observer shutdown requested.'
調べてみるとBonsai固有の問題ではなさそう でした。LM Studioのバグトラッカーに、同じエラーメッセージで他のモデルでも発生しているIssueが複数上がっています(#1584 / #1580)。つまり、これは LM Studio 0.4.5 本体側のバグ の可能性が高いです。
というわけで、現時点(2026/04)のLM StudioでBonsaiを快適に動かすのは厳しい というのが実感です。これはLM Studio側が次のマイナーアップデートでバグを直してくれれば解消する話なので、数週間待てば状況は変わるかな🤔
👉️今すぐ動かしたい人には、まだ選択肢にならない。同じところで詰まった人が「自分のPCがおかしいのか?」と悩まないよう書き残しておきます。
というわけで、今回は 本家llama.cppのWindowsプリビルドバイナリを直接使う のが一番確実、という結論になります。そんなに難しくはないので、以下そのまま手順に入ります。
4. Step 1: llama.cppのWindowsバイナリを用意する
ここは以前の記事で手順を細かくまとめているので、未導入の方はまずそちらを済ませてください。
参考
要点だけ再掲すると…
- llama.cppのReleasesページ から、自分の環境に合ったプリビルドZIP を取得
- 今回のIntel機・AMD機は両方ともGPU非搭載のiGPU機なので、CPU版(
llama-b8902-bin-win-cpu-x64.zip)と Vulkan版(llama-b8902-bin-win-vulkan-x64.zip)の2つ を落とす(b8902は本記事執筆時点の最新リリースです。みなさんが試すときは、そのタイミングでの最新を選べばOK) - それぞれ展開してフォルダを適当な場所に配置、環境変数PATHを通せば
llama-clillama-serverllama-benchがどこからでも実行できます
[📷 スクリーンショット: GitHubのReleasesページで対象ZIPファイルが選択されている様子]
配置例:
C:\llama.cpp\llama-cpp-cpu\ C:\llama.cpp\llama-cpp-vulkan\
今回は実験で、CPU版とVulkan版をどちらも使いたいので、フォルダ名を分けて両方入れてある のがポイントです。PATHに入れるのは比較時に切り替えたい方でOKかなと思います。 実行にあたっては各フォルダに移動して実行しているのですが、実際にはPATHに入れておけばどこからでも呼び出せるので、Vulkan版は必要なときだけ絶対パスで呼び出す 形にしてもいいかもしれません。
5. Step 2: Bonsaiモデルの取得 〜 -hf オプションが便利
最新のllama.cppには -hf オプションがあって、Hugging Faceから直接モデルをダウンロードしてそのまま実行 できます。手動でcurlでDLする必要もありません。
PS> .\llama-cli.exe -hf prism-ml/Bonsai-8B-gguf -p "Hello" -n 64 -ngl 0
初回実行時にモデルが C:\Users\<ユーザー名>\AppData\Local\llama.cpp\ にキャッシュされ、2回目以降は即起動です。
もし手動でDLして配置したい場合は、こちらでもOK:
PS> mkdir $HOME\models\bonsai -Force PS> cd $HOME\models\bonsai PS> curl.exe -L -O https://huggingface.co/prism-ml/Bonsai-8B-gguf/resolve/main/Bonsai-8B-Q1_0.gguf
ファイルサイズは約1.15GB。「8Bモデルが1GBちょいで落ちてくる」の時点で結構びっくりします。普通のLlama 3.1 8B(fp16)だと16GBありますからね。
以降の手順では、状況に応じて -hf と -m を使い分けながら 進めます(ベンチマーク取るときは同じファイルを再利用したいので -m のほうが都合がよかったりします)。
6. Step 3: まずCPUで動かしてみる
CPU版のllama-cliで動作確認します。
PS> .\llama-cli.exe -hf prism-ml/Bonsai-8B-gguf -p "Hello, introduce yourself in one sentence." -n 128 --temp 0.5 --top-p 0.85 --top-k 20 -ngl 0
-ngl 0 は「GPUに一切オフロードしない = フルCPU実行」の意味です。
Bonsaiは学習データが英語中心なので、日本語でいきなり試すと品質にがっかりすると思います。まずは英語で 「動くか」「どれくらいの速度か」 を確認するのがおすすめです。
軽くベンチマーク
雰囲気で「速い」「遅い」と言っても後で比較できないので、llama-bench で客観的な値を取ります。
PS> .\llama-bench.exe -hf prism-ml/Bonsai-8B-gguf -ngl 0 -t 4,8,12
ファイルパスは -hf でキャッシュされた場所を指定します(手動DLした場合はそのパスを指定)。-t にカンマ区切りで複数のスレッド数を指定すると、全パターンを自動で回してくれます。
ベンチマーク結果
結果テーブルの
model列にqwen3 8B Q1_0と表示されますが、これは llama-bench がGGUFメタデータからアーキテクチャ名を読み取って表示しているためです。Bonsai は Qwen3 アーキテクチャをベースにしているので、動かしているのは Bonsai-8B で間違いありません。
| model | size | params | backend | threads | test | t/s |
|---|---|---|---|---|---|---|
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 4 | pp512 | 12.10 ± 0.18 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 4 | tg128 | 9.99 ± 0.15 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 8 | pp512 | 13.51 ± 0.11 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 8 | tg128 | 9.31 ± 0.19 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 12 | pp512 | 13.77 ± 0.42 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 12 | tg128 | 9.61 ± 0.16 |
pp512 はプロンプト処理、tg128 はトークン生成の速度です。体感で効いてくるのはほぼ tg128 となります。pp512 はプロンプトが長くなったときの速度で、プロンプトが短いときはあまり気にならないと思います。
7. Step 4: Vulkanに切り替えてiGPUを使う
次はVulkan版を使います。コマンドはほぼ同じで、-ngl 99 に変えるだけ です。Vulkan版をPATHに入れていない場合は絶対パスで叩きます。
PS> .\llama-cli.exe -hf prism-ml/Bonsai-8B-gguf -p "Explain quantum computing in one paragraph." -n 256 --temp 0.5 --top-p 0.85 --top-k 20 -ngl 99
-ngl 99 で全レイヤーをGPU(iGPU)にオフロードしています。
Vulkan側でもベンチマーク
PS> .\llama-bench.exe -hf prism-ml/Bonsai-8B-gguf -ngl 99 -t 4,8,12
これでCPU版と同じ指標でiGPU推論の速度が測れます。
ベンチマーク結果
| model | size | params | backend | ngl | threads | test | t/s |
|---|---|---|---|---|---|---|---|
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 4 | pp512 | 58.08 ± 0.24 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 4 | tg128 | 14.87 ± 0.18 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 8 | pp512 | 53.25 ± 2.23 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 8 | tg128 | 14.85 ± 0.76 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 12 | pp512 | 52.21 ± 2.81 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 12 | tg128 | 14.67 ± 0.59 |
このスピードは結構すごいですね🤩CPU版の tg128 が9〜10トークン/秒だったのに対して、Vulkan版は14〜15トークン/秒。体感で明らかに速くなります😎ただし、CPU版とVulkan版でスレッド数の効き方が違うので、単純に「1.5倍速い」とは言いづらいですが、同じ環境で同じモデルを動かすなら、Vulkan版のほうが速い というのは間違いないです。
つまずきポイント
- デバイスが認識されない → GPUドライバを最新に(Intel Graphics Command Center / AMD Adrenalin)
- iGPUのVRAM割り当て不足 → BIOSで共有メモリ量を増やす(2GB以上推奨)。システムRAMが32GBあるので余裕はあります。
-ngl 99だとプロセスが落ちる → オフロードの値を段階的に下げる(-ngl 20など)
8. Step 5: AMD機でも測ってベンチ比較
ここまでIntel機(Intel 12th gen + Iris Xe)の測定だったので、AMD機(Ryzen 9 6950H + Radeon 680M)でも まったく同じ手順 で測ります。
Windowsプリビルドなのでセットアップは一瞬で、ZIP2つとモデル1つをコピーするだけ。
CPUベンチマーク
| model | size | params | backend | threads | test | t/s |
|---|---|---|---|---|---|---|
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 4 | pp512 | 15.98 ± 0.06 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 4 | tg128 | 13.70 ± 0.08 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 8 | pp512 | 27.71 ± 0.17 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 8 | tg128 | 22.64 ± 0.05 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 12 | pp512 | 28.84 ± 0.16 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | CPU | 12 | tg128 | 22.45 ± 0.04 |
iGPUベンチマーク
| model | size | params | backend | ngl | threads | test | t/s |
|---|---|---|---|---|---|---|---|
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 4 | pp512 | 179.91 ± 0.45 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 4 | tg128 | 17.17 ± 0.12 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 8 | pp512 | 179.63 ± 0.13 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 8 | tg128 | 27.59 ± 0.01 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 12 | pp512 | 179.44 ± 0.07 |
| qwen3 8B Q1_0 | 1.07 GiB | 8.19 B | Vulkan | 99 | 12 | tg128 | 27.53 ± 0.01 |
9. 比較
CPUとVulkanの数値は、同じWindows・同じプリビルドバイナリ・同じモデルファイル で測ったものなので、そのまま比較できます。
各機内での CPU vs Vulkan(同じハードの中で比べる)
各PCの中で 一番速かった値 を抜き出しました(カッコ内は最速だったスレッド数)。生成速度(tg128)とプロンプト処理(pp512)で傾向が違うので、表は分けています。
生成速度(tg128)
| PC | CPU (t/s) | Vulkan (t/s) | Vulkan倍率 |
|---|---|---|---|
| Intel機 (Iris Xe) | 9.99 (4t) | 14.87 (4t) | 約1.5倍 |
| AMD機 (Radeon 680M) | 22.64 (8t) | 27.59 (8t) | 約1.2倍 |
プロンプト処理(pp512)
| PC | CPU (t/s) | Vulkan (t/s) | Vulkan倍率 |
|---|---|---|---|
| Intel機 (Iris Xe) | 13.77 (12t) | 58.08 (4t) | 約4.2倍 |
| AMD機 (Radeon 680M) | 28.84 (12t) | 179.91 (4t) | 約6.2倍 |
面白いのは、生成よりもプロンプト処理のほうがVulkanの恩恵が大きい という傾向です。短いプロンプトで雑談するような使い方だと「思ったほど速くなってないな?」と感じるかもしれませんが、長文を一気に流し込む用途(長いコードを読ませるなど)ほどiGPUを使う意味が大きくなる ということですね。
Intel機 vs AMD機(iGPUメーカー違いでの比較)
同じくベスト値同士で横並びにすると、こうなります。
| 指標 | Intel機 (Iris Xe) | AMD機 (Radeon 680M) | AMD / Intel |
|---|---|---|---|
| CPU pp512 | 13.77 | 28.84 | 約2.1倍 |
| CPU tg128 | 9.99 | 22.64 | 約2.3倍 |
| Vulkan pp512 | 58.08 | 179.91 | 約3.1倍 |
| Vulkan tg128 | 14.87 | 27.59 | 約1.9倍 |
なんとなく「AMD機が優勢」だと思っていましたが、差が思っていたより大きい というのが正直な感想です。
特にVulkanの pp512 が 3倍以上 違うのは衝撃で、Radeon 680M(RDNA2世代)のiGPUとしての地力がはっきり出た形になりました。
CPU側もRyzen 9 6950Hのほうが世代・コア構成で有利なので、ハード総合での差が出やすい組み合わせになっていました。
10. 実験結果
実験前に立てていた予想と、実際に測ってみた結果を並べると、予想通りだった点と、想定以上だった点 が両方ありました。まずはざっくりとした全体像から。
- CPU推論 … Intel機で約10 tok/s、AMD機で約22 tok/s。「そこそこ出るだろう」という予想に対して、AMD機は予想を超えるスコア。1bit量子化が加算中心でCPUと相性が良いという仮説は、おおむね当たっていそう
- Vulkan iGPU推論 … 生成(
tg128)は1.2〜1.5倍、プロンプト処理(pp512)は4〜6倍。長いプロンプトほどiGPUの恩恵が大きい という傾向がはっきり出た - Intel機(Iris Xe) vs AMD機(Radeon 680M) … 予想通りAMD機が優勢。ただし 差は予想以上 で、Vulkanの
pp512では3倍以上の開き - Bonsaiの日本語品質 … 英語ベースのモデルなので、日本語で長文を書かせると論理がブレやすい。タスクは英語で投げるのが現実的 という印象
Intel機（Iris Xe）で見えたこと
CPUでも約10 tok/s 出る。スレッドは4で生成は飽和、増やしても劇的な変化はない。Vulkanに切り替えるとプロンプト処理は約4倍、生成は約1.5倍。長いプロンプトほどVulkanの恩恵が大きい。14〜15 tok/s は チャット用途なら十分実用、業務PCそのままで8Bが動くインパクトを実感ができる。
AMD機（Radeon 680M）で見えたこと
CPUだけでも 22〜23 tok/s。これは Intel機のVulkan(14〜15 tok/s)をCPUだけで上回ってしまう 数字で、正直ちょっと驚きました。スレッドは8で最大化、12にしてもほぼ伸びないので、Ryzen 9 6950Hの物理8コア構成にきれいに合っている形ですね。
Vulkanに切り替えると、生成は27〜28 tok/sで CPU比1.2倍 とそこまで派手な伸びではないものの、プロンプト処理は 約180 tok/s まで跳ね上がり、CPU比6倍超。pp512 の値はスレッド数によらずほぼ一定なので、ボトルネックは完全にiGPU側に移っているのが分かります。
RAGで資料を詰めたり、長いコードを読ませたりする 長コンテキスト用途では、AMD機 + Vulkan の組み合わせが圧倒的 に有利、というのは大きな収穫でした。
11. 1ヶ月経って冷静に見えてきたこと
発表直後のSNSでは「10倍の知識密度!」「クラウド不要!」みたいな勢いのある言葉が飛び交っていて、自分も最初は正直テンションが上がっていました。でも1ヶ月経って手を動かしてみると、少し落ち着いた感覚で結果を見られるようになってきました。その中で特に印象に残ったのは以下です。
- 「同じハードでこれだけ動くモデルが他にない」 という事実は、やはり大きい
- 「万能選手」ではなく「選択肢が増えた」くらいの評価が、自分の今の実感に近い
もう一つ、1ヶ月置いたことのご褒美として エコシステム側の整備 があります。発表直後はPrismMLフォークのllama.cppを使うしかなかった Q1_0 量子化形式が、現在はCPU・Metal・CUDA・Vulkanすべて本家にマージ済みです。一方でLM StudioやOllamaのようなGUI/CLIラッパーはまだ追いついていなくて、「本家は対応したがラッパーは時差で未対応」 みたいな状態になっています。LM Studioの場合はQ1_0対応のllama.cppを取り込んだ途端に別バグが顔を出す、という多段のハードルが待っていたりします。このあたりの"ズレ"も含めて、1ヶ月経たないと見えてこない印象でしょうか。
12. おわりに
発表から少し時間を置いてBonsaiを触ってみました。発表直後のお祭り感がひと段落したタイミングで触ってみると、「確かにすごいモデルなんだけど、万能ではない」「本家llama.cppでは動くけどGUIラッパーはまだ追いついていない」みたいな、ベンチマーク値だけでは見えない景色 がちゃんと見えてきて面白かったです🤗
業務で使うPCがAIにはパワー不足に感じても、今はそれがハンデじゃなくなりつつある 時期に入りつつある、というのが今回の実感です。Bonsaiはその流れの象徴で、ここから1〜2年のうちにもっと加速するんじゃないかなと思っています。
参考リンク
llama.cpp の導入について(参考記事)
Bonsai / llama.cpp 関連
llama.cppのビルドはこちらからダウンロード
LM Studio 既知バグIssue(同エラー全般)
LM Studio Q1_0関連Issue(旧エラー、参考)
