Labo › 検証ノート

ローカル LLM

Ternary Bonsai 2 27B は RTX 5060 Ti で 67 tok/s 出るのか — 条件をそろえれば 65 tok/s。日本語の文章では 54 tok/s で、日本語の質は元の Qwen3.8-27B より下がった

IVYXON 編集部 ・ 2026年10月1日

65.3tok/s（作者と同じ条件）日本語の文章では 54.1 tok/s
×1.5〜1.8Qwen3.8-27B より速い3 ビット台の版と比べて
3.73ELYZA-tasks-100Qwen3.8-27B は 4.10
CONTENTS目次（9）
  1. 測った 4 つの組み合わせ
  2. 測った環境
  3. 結果 1: 作者と同じ条件では 65.3 tok/s
  4. MTP の当たりは、問いの種類で大きく違う
  5. Qwen3.8-27B（3 ビット台の版）と比べた速さと VRAM
  6. 日本語の質は 3 つの試験とも下がった
  7. 測っていないこと
  8. まとめ
  9. 出典

この記事の結論

  • 「67 tok/s」は、条件をそろえるとほぼ出た（65.3 tok/s）。改造版の llama.cpp（sudoingX の bonsai2 v1.1）に、MTP（先読みの頭）を足したファイルを載せ、作者と同じ英語の短い問いを解かせたときの数字。PrismML 版の llama.cpp で MTP なしだと 42〜47 tok/s で、「37 tok/s」の報告はこちらの条件に近い。
  • 日本語の文章では 54.1 tok/s だった。MTP の上乗せはコードで 1.36 倍あったが、文章では英語・日本語とも 1.1 倍ほど。同じ設定で測った Qwen3.8-27B（3 ビット台の版）と比べると、MTP なしどうしで 1.8 倍、MTP ありどうしで 1.5 倍速く、VRAM は約 6 割（文脈 32K で 8,680MiB）。
  • ただし日本語の質は、3 つの試験とも Qwen3.8-27B より下がった。ELYZA-tasks-100 は 3.73 対 4.10（差 -0.37）。公称の「FP16 の 98.2%」は、英語中心の試験を思考ありで解かせた値で、日本語を思考なしで書かせた今回は、3 ビット台の Qwen3.8-27B に対して 85〜91% だった。

Ternary Bonsai 2 27B は、PrismML が 2026年9月に公開したモデルです。Qwen3.8-27B の重みを、-1・0・+1 の 3 つの値（三値）と、128 個ごとに 1 つの倍率で表しています。1 つの重みあたり 1.75 ビットで、ファイルは 5.95GB です（元の FP16 は 53.8GB）。ライセンスは Apache-2.0 です。本家の llama.cpp（ggml-org）では動かず、PrismML が手を入れた llama.cpp（fork）が必要です。

この Ternary Bonsai 2 27B について、RTX 5060 Ti 16GB で「67 tok/s 出る」という報告があり、一方で同じ GPU で「37 tok/s ほど」という報告もあって、数字が割れていました。また公開元は「FP16 の 98.2% の性能を保つ」としていますが、その評価は英語中心の試験です。そこで同じ GPU の Windows 機で、速さを両方の条件で測り、日本語の質を元の Qwen3.8-27B と比べました。数字は 2026年10月1日時点のものです。

測った 4 つの組み合わせ

llama.cpp は 2 種類を、どちらもソースからビルドしました。1 つは PrismML の fork の最新版（以下「PrismML 版」）、もう 1 つは、67 tok/s を出した作者（sudoingX）が PrismML 版に RTX 50 向けの手直しを足したもの（以下「改造版」）です。

組み合わせllama.cppファイル大きさ
PrismML 版・PTQ1_0PrismML の fork（prism-b10743-adfffbe）PTQ1_0（1 つの重みあたり 1.75 ビット）5.95GB
PrismML 版・PQ2_0同上PQ2_0（三値を 2 ビットの枠に入れた形・2.13 ビット）7.21GB
改造版・PTQ1_0sudoingX の bonsai2 v1.1（ff41412）PTQ1_0（上と同じファイル）5.95GB
改造版・PTQ1_0＋MTP同上PTQ1_0 に MTP の頭を足したファイル（sudoingx の GGUF）7.01GB

改造版は、PTQ1_0 の計算を速くする処理と、RTX 50（Blackwell）で遅くなる不具合の修正 2 件を足したもの（作者のリポジトリの説明による）。MTP の頭は、元の Qwen3.8-27B の MTP の層を unsloth の GGUF からそのまま移したもので、三値化はされていない。

MTP（Multi-Token Prediction）は、モデルに付いた小さな「先読みの頭」が次のトークンを下書きし、本体がまとめて確かめる仕組みです（投機的デコーディング）。下書きが当たった分だけ速くなり、本体が確かめるので出力の傾向は変わりません。今回は作者の推奨どおり、1 回に 1 トークンだけ下書きさせました（--spec-draft-n-max 1）。下書きの方式の違いは DFlash・DSpark・MTP を日本語で比べた記事にまとめています。

測った環境

項目内容
GPUGeForce RTX 5060 Ti 16GB（電力の上限 180W）
CPU・メモリCore i5-12400F・DDR4-3200 32GB
OS・ドライバWindows 11・NVIDIA ドライバ 610.47
llama.cpp上の 2 種類。どちらも CUDA 13.4 でソースからビルド
サーバーの設定llama-server に -ngl 99 --fit off -fa on -ctk q8_0 -ctv q8_0 -b 512 -ub 512 -np 1（全部 GPU・KV キャッシュは q8_0）。MTP ありは --spec-type draft-mtp --spec-draft-n-max 1 を足す
速さ (1)
作者と同じ条件		作者の計測スクリプト（probe.py）と同じ英語の問い 3 つ（Python の関数を書く・mmap と read の違いを説明する・bash のスクリプトを書く）を 3 回ずつ。出力は 400 トークンまで、思考なし、サンプリングの指定なし。ストリーミングで届いた分を数え、最初のトークンが届くまでの時間は除く。9 回の中央値。文脈（一度に扱えるトークン数の枠）32K で起動
速さ (2)
日本語の文章		日本語の記事の本文（約 1,000〜1,100 トークン）を渡して続きを書かせ、512 トークンで打ち切る。別の文章で 2 回、文脈 8K と 32K。サンプリングは Qwen3.8 の推奨値（温度 0.7・top_p 0.8・top_k 20・presence_penalty 1.5）、思考なし
日本語の質改造版・PTQ1_0＋MTP を文脈 16K で起動し、ELYZA-tasks-100（100 問）・M-IFEval-Ja（172 問）・JamC-QA（300 問）を思考なしで 1 回ずつ。サンプリングは (2) と同じ、出力の上限は 3,072 トークン（JamC-QA は 256）

改造版＋MTP の起動は次のとおりです（文脈 32K の例。見やすいように折り返していますが、実際は 1 行で入力します）。思考を切るときは、要求の chat_template_kwargs に "enable_thinking": false を入れます。

llama-server -m Ternary-Bonsai-2-27B-PTQ1_0-mtp.gguf -c 32768
  -ngl 99 --fit off -fa on -ctk q8_0 -ctv q8_0 -b 512 -ub 512 -np 1 --jinja
  --spec-type draft-mtp --spec-draft-n-max 1

結果 1: 作者と同じ条件では 65.3 tok/s

組み合わせ英語の短い問い
（作者と同じ条件）		作者の表
（Linux）		日本語の文章
文脈 32K		日本語の文章
文脈 8K		VRAM
32K／8K
PrismML 版・PTQ1_042.242.040.740.77,346
6,422
PrismML 版・PQ2_046.8—44.944.78,490
7,566
改造版・PTQ1_052.353.449.849.97,250
6,326
改造版・PTQ1_0＋MTP65.367.354.155.58,680
7,660

生成の tok/s。英語の短い問いは 9 回の中央値、日本語の文章は 2 回の中央値。作者の表は、作者が Linux の RTX 5060 Ti で同じ問いを測った値（KV キャッシュは q4_0）。VRAM は起動直後の GPU 全体の使用量（MiB・画面表示の分を含む。上が文脈 32K、下が 8K）。2026年10月1日に測定。

  • 作者の 67.3 tok/s は、条件をそろえると Windows でもほぼ出ました（65.3）。PrismML 版・改造版・MTP ありの 3 段階とも、作者の表との差は 3% 以内です（42.2 対 42.0、52.3 対 53.4、65.3 対 67.3）
  • 速さの上乗せは 2 段です。同じ PTQ1_0 のファイルで、改造版にすると 1.24 倍（42.2 → 52.3）、さらに MTP を足すと 1.25 倍（52.3 → 65.3）になりました
  • PrismML 版では、ファイルの大きい PQ2_0 のほうが PTQ1_0 より速くなりました（46.8 対 42.2）。改造版で足された速くする処理は PTQ1_0 向けです
  • 「37 tok/s」の報告は、PrismML 版・MTP なしの条件とみられます。モデルの公開ページの議論には、Windows 11 の RTX 5060 Ti で PQ2_0 を文脈 180K の設定で動かして 37 tok/s、という報告があります。今回の PrismML 版は 40.7〜46.8 tok/s で、それより少し速い程度でした。文脈を大きく取ったことや会話の長さで遅くなった可能性がありますが、長い文脈はこの記事では測っていません
  • 日本語の文章を書かせると、どの組み合わせも英語の短い問いより遅くなり、MTP ありでは差が大きくなりました（65.3 → 54.1）。理由は次の「当たり」です

MTP の当たりは、問いの種類で大きく違う

MTP の上乗せは、下書きの当たり（下書きしたトークンのうち、本体が採用した割合）でほぼ決まります。作者の 3 つの問いを分けて見ると、コードと文章で大きく違いました。

問いMTP なしMTP あり倍率当たり
Python の関数を書く52.371.2×1.3691%
bash のスクリプトを書く52.365.3×1.2577%
mmap と read の違いを説明する（英語の文章）52.556.8×1.0853%
日本語の文章（文脈 32K）49.854.1×1.09—
日本語の文章（文脈 8K）49.955.5×1.11—

生成の tok/s（改造版・PTQ1_0）。英語の問いは 3 回の中央値、日本語の文章は 2 回の中央値。当たりは llama-server が返す下書きの数と採用された数から計算した（日本語の文章の測定では記録していない）。2026年10月1日に測定。

  • コードでは下書きの 9 割が当たり、1.36 倍になりました。英語の説明文は当たりが 5 割ほどで 1.08 倍、日本語の文章も 1.09〜1.11 倍でした
  • 作者の 67.3 tok/s は、コードを書く 2 問と説明文 1 問の、計 9 回の中央値です。文章を書かせる使い方では、54〜57 tok/s が目安になります
  • 当たりが 9 割でも 2 倍に届かないのは、MTP の頭（元の Qwen3.8-27B の 1 層分で、三値化されていない）を動かす手間が、1.75 ビットに縮んだ本体に比べて重いためとみられます（確かめていません）

Qwen3.8-27B（3 ビット台の版）と比べた速さと VRAM

元の Qwen3.8-27B を、16GB に収まる unsloth の UD-Q3_K_XL（13.15GB）で、同じサーバーの設定で測った値と比べました。こちらは本家の llama.cpp（b11193）です。

モデル・組み合わせ日本語の文章
文脈 32K		VRAM
文脈 32K
Qwen3.8-27B（UD-Q3_K_XL）・MTP なし27.313,881
Qwen3.8-27B（UD-Q3_K_XL）・MTP（手数 2）37.214,771
Bonsai 2 27B PrismML 版・PTQ1_040.77,346
Bonsai 2 27B 改造版・PTQ1_049.87,250
Bonsai 2 27B 改造版・PTQ1_0＋MTP54.18,680

生成の tok/s（2 回の中央値）と、起動直後の GPU 全体の VRAM（MiB）。手数は 1 回に下書きさせるトークンの数。Qwen3.8-27B は 2026年9月29日に測定（MTP の付け方は Qwen3.8 の MTP の記事を参照）。入力は同じ作りの日本語の文章で、Qwen3.8-27B は約 1,500〜1,800 トークン、Bonsai は約 1,000〜1,100 トークン。Qwen3.8-27B は入力を約 4 倍にしても生成が 2〜3% しか遅くならなかったので、この差が比べ方に与える影響は小さい。

  • MTP なしどうしで 1.8 倍（49.8 対 27.3）、MTP ありどうしで 1.5 倍（54.1 対 37.2）速くなりました。PrismML 版の PTQ1_0 でも 1.5 倍です（40.7 対 27.3）
  • VRAM は約半分〜6 割です（7,250〜8,680MiB 対 13,881〜14,771MiB）。16GB の GPU なら、文脈を長く取ったり、別のモデルと一緒に載せたりする余裕が残ります（長い文脈での速さは測っていません）

日本語の質は 3 つの試験とも下がった

改造版・PTQ1_0＋MTP で日本語の 3 つの試験を思考なしで解かせ、Qwen3.8-27B（UD-Q3_K_XL）の記録と同じ問題どうしで比べました。Qwen3.8-27B の記録は、2026年9月26〜28日に Ollama で、同じサンプリング・同じ出力の上限で測ったものです。MTP は本体が確かめるので、答えの傾向は PTQ1_0 だけのときと同じです。

試験（思考なし）Bonsai 2 27BQwen3.8-27B
（UD-Q3_K_XL）		差（95% 区間）
ELYZA-tasks-100
100 問・1〜5 点の平均		3.734.10-0.37
（-0.58〜-0.16）
M-IFEval-Ja
226 の指示を守れた割合		0.5620.659-0.10
（-0.16〜-0.04）
JamC-QA
300 問の正答率		0.4170.483-0.07
（-0.13〜-0.003）

差の区間は、同じ問題どうしの差を問題単位で選び直して（ブートストラップ）求めた 95% 区間。ELYZA-tasks-100 は、OpenAI の gpt-5.6-luna に採点の基準を渡して 1〜5 点をつけさせた（両モデルとも同じ採点）。Qwen3.8-27B の ELYZA は 2 回の平均。M-IFEval-Ja は指示ごとの厳密な判定（問題ごとに全部の指示を守れた割合では 0.471 対 0.605）。JamC-QA は 4 択で、分野の比率に合わせて選んだ 300 問。2026年10月1日に測定。

  • ELYZA-tasks-100 は 3.73 で、Qwen3.8-27B（4.10）より 0.37 低くなりました。区間が 0 をはっきり下回っていて（p=0.001）、偶然の差とは考えにくい大きさです
  • M-IFEval-Ja（字数・形式・使う文字などの指示を守れるか）は 0.562 対 0.659、JamC-QA（日本の文化・地理・制度などの 4 択）は 0.417 対 0.483 でした。JamC-QA の差は小さく、区間の上端は 0 にほぼ接しています（正誤が入れ替わった問題だけで比べると p=0.054 で、偶然の差である可能性を否定しきれません）
  • 公称の「FP16 の 98.2%」は、英語中心の 14 の試験（数学・コード・指示の守り方・画像の読み取りなど）を、思考あり（xhigh）で、H100 と vLLM で解かせた平均です（FP16 の 86.32 に対して 84.78）。日本語を思考なしで書かせた今回は、3 ビット台の Qwen3.8-27B に対して 85〜91% でした。比べた相手も元の重みを縮めた版なので、元の重みからの落ち方はこれより大きいとみられます（確かめていません）

答えの崩れ方にも違いがありました。M-IFEval-Ja では、日本語の答えに中国語の簡体字やハングルが混じったものが 172 問中 10 問ありました（Qwen3.8-27B は 1 問）。「歴史적으로」のように語の一部がハングルになったものや、答え全体が中国語になったもの（1 問）です。ただし ELYZA-tasks-100 では 100 問中 0 問（Qwen3.8-27B は 200 回答中 5）で、いつも起きるわけではありません。M-IFEval-Ja では、出力の上限まで書き続けた答えが 2 問、同じ段落を繰り返した答えが 1 問ありました（Qwen3.8-27B は繰り返し 1 問）。

日本語の長い答えの途中で HTTP 500 が返ることがある

質の試験に使った改造版（PrismML 版を元にしたもの）の llama-server で、M-IFEval-Ja の 172 問中 6 問、答えの途中で生成が止まり、The model produced output that does not match the expected peg-native format（出力が想定した書式に合わない）というエラーとともに HTTP 500 が返りました。このとき本文は 1 文字も返りません。ELYZA-tasks-100 と JamC-QA では起きませんでした。

同じ要求をストリーミング（"stream": true）で送り直すと、エラーの直前までの本文は届きました。6 問とも、出力の上限（3,072 トークン）より手前の 134〜1,421 トークン目で、日本語の語の途中で切れていました。チャットの書式の読み取りを通さない /completion で生成させても、同じ種類のエラー（Content-only format）になりました。原因は確かめていません。PrismML 版でも同じことが起きるかは、質の試験を回していないので分かりません。

今回の採点では、この 6 問は届いた本文のまま数えました。6 問の指示を全部守れたことにしても M-IFEval-Ja は 0.593 で、Qwen3.8-27B（0.659）には届きません。

ビルドするときの注意（Windows・CUDA）

改造版はビルド済みのファイルが見当たらなかった（2026年10月1日時点）ので、ソースからビルドしました。PrismML 版も同じ手順にそろえています。このドライバ（610.47）が対応する CUDA は 13.3 までで、CUDA 13.4 で作った PTX（実行時に GPU 向けに変換する中間のコード）は変換できません。そこで CMake の指定を -DCMAKE_CUDA_ARCHITECTURES=120a-real にして、RTX 50 向けの機械語だけを作るようにしました。PrismML 版だけを使うなら、PrismML が配っている Windows 向けのビルド済みファイル（CUDA 12.4 版・13.3 版）もあります。

測っていないこと

  • 思考ありの使い方の質と速さ（公開元の評価は思考あり）
  • 長い文脈（数万トークン以上を入れた状態）での速さ。作者の表でも、文脈が長いほど生成は遅くなっている
  • 英語の質と、元の重み（FP16）との直接の比較
  • PQ2_0 の質（質を測ったのは PTQ1_0 だけ）
  • Linux での速さ、KV キャッシュを q4_0 にした場合、複数の要求を同時に処理する使い方
  • Ollama・LM Studio での動作（本家の llama.cpp では動かないと案内されている）
  • 速さは各条件 2〜9 回なので、数 % の差は偶然の範囲かもしれない

まとめ

  • 「RTX 5060 Ti で 67 tok/s」は、改造版の llama.cpp・MTP・英語の短い問いの 3 つがそろったときの数字（今回 65.3 tok/s・2026年10月1日時点）
  • PrismML 版で MTP なしなら、英語の短い問いで 42〜47 tok/s。日本語の文章では、改造版＋MTP でも 54.1 tok/s（MTP の上乗せは文章で 1.1 倍ほど）
  • 3 ビット台の Qwen3.8-27B より 1.5〜1.8 倍速く、VRAM は約半分〜6 割
  • 日本語の質は 3 つの試験とも下がった（ELYZA-tasks-100 で 3.73 対 4.10）。公称の 98.2% は英語中心・思考ありの値で、日本語の文章を思考なしで書かせる使い方では、Qwen3.8-27B のほうが質は上だった

出典

← 検証ノートの一覧へ

この記事は、手元の機材で行った測定をもとにした一般的な技術情報の提供を目的としており、特定の製品・ソフトウェアの購入や利用を推奨・勧誘するものではありません。数値は 2026年9月26日〜10月1日の測定で、モデル・ソフトの版・設定・機材によって変わることがあります。