この記事の要点
Saluki の配布元が書く「8GB 未満」はファイルの大きさで、全部の層を GPU に置くと VRAM はもっと使う。画面を出していない 16GB のカードで KV キャッシュを8ビットにすると、文脈 131,072 トークンまで全部の層を GPU に置けた。文脈 262,144 では VRAM がほぼ埋まり、共有 GPU メモリの使用が大きく増えた。8GB・12GB は試していないが、16GB の値では 8GB は文脈 4,096 でも空きがほぼ無く、12GB を下回るのは 65,536 までだった。
Ollama・LM Studio で Saluki は読み込めたが、Bonsai 2 27B の PQ2_0 は読み込めなかった。
温度0 (GPU の温度ではなく言葉の選び方の設定) で比べると、税込み合計の計算は Bonsai 2 27B だけが正解し、PC 構成の相談は RTX 5060 Ti の Saluki だけが最後まで答えた。Saluki の税の誤りは、温度などが既定の Ollama・LM Studio では多く正解に変わったが、原因は切り分けていない。
Underdog Saluki 27BはVRAM何GBのカードで動くか
配布元のモデルカードは、Underdog Saluki 27B 1.0 (以下 Saluki) を、Qwen3.8-27B を 8GB 未満にしてツール呼び出しの力を保つよう調整したもので、標準の llama.cpp で読める GGUF だと説明している。ツール呼び出しは、アプリから渡された関数の名前と引数をモデルが決まった形で返し、アプリがその関数を実行する使い方のことだ。配布元のリポジトリでは本体のファイル (IQ2-mix) が 7.90GB で、画像を読ませるときは別のファイル (mmproj。F16 は 928MB、Q8_0 は 629MB) を足す形になっている。
この「8GB 未満」はファイルの大きさの話で、動かすときに要る VRAM の値ではない。動かすときはモデル本体のほかに、KV キャッシュ (会話の途中の計算結果をためておく領域) の分も VRAM に置かれる。KV キャッシュは、文脈の長さ (一度に扱える入力と出力の長さ。コンテキスト長) を長くするほど大きくなる。文脈の長さはトークン (文字のかたまり) の数で数える。量子化でファイルが小さくなる仕組みと、ファイルの大きさと必要な VRAM の違いは、1bit・Ternary の量子化で27B級の LLM が VRAM 16GB に載るかを扱った記事で基礎から説明している。
VRAM の容量ごとに、分かったことは次のとおり。値はどれもモデルを読み込んだ直後の使用量で、llama.cpp b11218 を使い 2026年10月10日に測った。
- VRAM 16GB (RTX 5060 Ti、画面を出していないカード): KV キャッシュを8ビット (q8_0) にすると、文脈 131,072 トークン (約13万) までモデルの全部の層を GPU に置けて、使用量は 12,618MiB だった。土台のモデルの標準の 262,144 トークンにすると、使用量が 16,010MiB に達し、共有 GPU メモリの使用も 1,880MiB 増えた。
- VRAM 12GB: 試していない。16GB のカードで測った使用量 (KV キャッシュ q8_0) のうち 12GB (12,288MiB) を下回ったのは、文脈 65,536 トークン (10,122MiB) までだった。131,072 トークン (12,618MiB) は上回った。
- VRAM 8GB: 試していない。16GB のカードでは KV キャッシュ q8_0・文脈 4,096 トークンでも 7,808MiB を使ったので、8GB (8,192MiB) のカードでは、画面を出していなくても残りは 384MiB しかない計算になる (8GB のカードで測った値ではない)。
画面出力に使っている GPU では、OS の表示処理やほかのアプリが使う分だけ、モデルに使える VRAM が減る。作業を続けると、使用量は読み込み直後より少し増える。
ここでいう「全部の層を GPU に置いた」は、モデルのすべての層を GPU に置く指定 (-ngl 99) で読み込めたという意味で、使うメモリがすべて VRAM の中に収まったことまでは示さない。llama-server では層の置き場所をログで確かめてはおらず、この指定で読み込めたことと、nvidia-smi で読んだ使用量から判断した。
共有 GPU メモリは、Windows が GPU にも使わせるメインメモリの領域で、VRAM が足りないときの退避先にもなるが、それ以外の用途にも使われる。
同じ測定機で RTX 4070 SUPER 12GB に差し替えて測ったときは、Qwen3.8-27B を4ビット前後に量子化したファイル (UD-IQ4_XS・NVFP4 の BUDGET・UD-Q3_K_XL) はどれも 12GB に全部は載らず、残りが CPU へ回った。たとえば UD-IQ4_XS は 14.25GB で、Saluki (7.90GB) の約1.8倍の大きさがある。これは 2026年10月3日の別の測定で、Saluki のものではない。その結果はRTX 4070 SUPER 12GB でも4ビット前後の Qwen3.8-27B を測った記事にある。
文脈の長さごとの細かい値は「文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）」の節にまとめた。
Underdog Saluki 27Bとは
配布元 (ConwayResearch) は、Saluki の土台を Qwen チームの Qwen3.8-27B と、ISTA-DASLab の Qwen3.8-27B-GSQ-RCO-GGUF だと書いており、どちらも Apache 2.0 としている。Saluki 自身のライセンスも Apache 2.0 とされている。
土台の Qwen3.8-27B のモデルカードは、文脈の長さを標準で 262,144 トークンとし、画像と動画を扱えるモデル (vision-language model) としている。
配布元はツール呼び出しの比較として、BFCL v4 (Berkeley Function Calling Leaderboard) から選んだ120問 (Underdog Bench) を、思考なし・温度0で解かせた結果を載せている。ここでいう温度は GPU の温度ではなく、モデルが次に出す言葉をどれだけばらつかせるかを決める生成の設定で、0 にすると毎回いちばんそれらしい言葉を選ぶ。通った問題の数は、Saluki が 88、元の大きさの Qwen3.8-27B (54GB) が 84、配布元の比較表の「Bonsai 2」(5.95GB) が 70 となっている。あわせて、9つのベンチマークで元のモデルの 96% を保つとしている。この「Bonsai 2」が誰のどのファイルかを、配布元は書いていない。大きさから見てどのファイルに当たるかは「Bonsai 2 27Bと同じ作業で並べると」の節に書いた。本記事で比べた PrismML の Bonsai 2 27B は、Qwen3.8-27B をもとに重みを3つの値に絞ったモデルとして配布されている。
これらは配布元の測り方の値で、本記事では確かめていない。元のモデル側の一部の値は、配布元とは別の測り方で公開された値だと配布元自身が断っている。
配布元は弱い点も挙げている。競技数学の成績が元のモデルの約82〜85%にとどまること、文字単位の指示 (回文・母音の規則・アルファベット順) に弱いこと、並列のツール呼び出しの返答の約5分の1に小さな書式の崩れがあること、思考ありでは答える前に長く考えることが多いこと、の4つだ。
配布元は使い方ごとの設定も挙げている。一般の用途・推論・指示には思考あり (既定) で温度 0.6・top_p 0.95・top_k 20、速く直接ツールを呼ぶ用途には思考なし・温度0 としている。本記事のチャットの課題は、思考の強さに high を指定し (使ったテンプレートが xhigh に置き換えてモデルへ渡す)、温度0 で出しており、このどちらとも違う。
OllamaとLM Studioで読み込めるか
Ollama のドキュメントは、GGUF を取り込む手順として、Modelfile の FROM にファイルのパスを書き、ollama create でモデルを作る方法を示している。
Ollama 0.40.2 でこの手順どおりに Saluki の GGUF を取り込むと、65層すべてが RTX 5060 Ti 1枚の GPU に置かれた (Ollama のログと /api/ps の表示で確かめた)。取り込んだモデルはツール呼び出し (tools) と思考 (thinking) に対応と表示され、文脈の長さは既定のままで 4,096 トークンだった。測定機には GPU が2枚あるので、Ollama のサーバーは RTX 5060 Ti だけを使うように起動した。CUDA_VISIBLE_DEVICES で RTX 5060 Ti だけを見せ、GGML_VK_VISIBLE_DEVICES=-1 で Vulkan から見える GPU を無くしている (後者を外すと、Vulkan 経由で RTX 5080 も見えた)。それ以外の設定は既定のままで、2026年10月10日に試した。mmproj を足していないので画像の入力は試しておらず、長い文脈や速さの比較も Ollama では試していない。
取り込みに使った Modelfile は次の1行だけで、ほかの指定は足していない。FROM のパスは GGUF を置いた場所に合わせる。
FROM C:/models/Underdog-Saluki-27B-1.0-IQ2-mix.ggufModelfile を置いたフォルダーで取り込み、起動する例は次のとおり (saluki-27b は自分で付ける名前)。
ollama create saluki-27b -f Modelfile
ollama run saluki-27bツール呼び出しは1回だけ試した。指定した都市の気温を返す関数を1つ渡し、思考なしで「東京と大阪の今の気温を調べて、どちらが暖かいか教えて」と頼むと、最初の返答として東京と大阪の2つの呼び出しを、正しい引数で並べて返した。呼び出しの結果を返して会話を続けるところまでは試していない。
文脈の長さの既定について、Ollama のドキュメントは VRAM の量で決めるとしており、24GiB 未満では 4k としている。変えるには、アプリの設定のスライダーを動かすか、OLLAMA_CONTEXT_LENGTH を付けて ollama serve を起動する。Ollama で文脈を伸ばしたときの使用量と速さは、本記事では測っていない。
LM Studio 0.4.26 では、入れたあと lms runtime get で llama.cpp のランタイム 2.55.0 を入れ、Saluki の GGUF を取り込んで読み込めた。lms コマンドで読み込んだときの既定は文脈 8,192・同時処理 4 だった。lms load --gpu max で読み込むと、GPU を指定する環境変数 (CUDA_VISIBLE_DEVICES) を付けていても、モデルは画面を出している RTX 5080 に載った。環境変数がサービスに引き継がれなかったのか、LM Studio 側の GPU の選び方によるのかは切り分けていない。RTX 5080 に載ったこの状態で、税込み合計の問題 (後で Bonsai 2 27B とも比べる計算問題) を5回出すと、生成 (decode。答えを1トークンずつ作る段階) は1秒あたり 62.2〜64.5 トークンだった。LM Studio で読み込みを試したのは 0.4.26 だけで、画像と長い文脈は試していない。
一方、Bonsai 2 27B のファイルのうち PQ2_0 は、どちらでも読み込めなかった。Ollama 0.40.2 では ollama create が次のエラーで止まった。
Error: unsupported tensor "output.weight" size overflowsLM Studio 0.4.26 では、読み込みが 12% のところで次のエラーになった。
Error: Failed to load model.どちらも 2026年10月10日の結果で、Bonsai 2 27B の低ビットのもう1つのファイル PTQ1_0 は試していない。
文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）
表は、RTX 5060 Ti 16GB (OCuLink で外付けし、画面を出していないカード。待機時の使用 0MiB) で llama.cpp b11218 の llama-server にモデルを読み込み、その直後に nvidia-smi で読んだ使用量 (MiB) だ。起動は -ngl 99 (全部の層を GPU に置く)・--fit off (自動調整を切る)・--parallel 1・flash attention on で、「170,752 (自動)」の値だけは -c と -ngl を外し、llama.cpp の --fit に文脈の長さを選ばせた。
KV キャッシュの型は、8ビット (q8_0) にした場合と16ビット (f16) の場合を並べた。q8_0 は KV キャッシュを8ビットで持つ指定で、f16 より VRAM を使わない。llama-server では型を指定しないと f16 になる (Ollama と LM Studio の既定の型は確かめていない)。
どの値も1回の読み込みで読んだもので、131,072 と 262,144 は読み込みをやり直して同じ値になった。この2つは Windows の GPU メモリのカウンタを1秒おきに記録し、共有 GPU メモリの使用も見た。40,960 と「170,752 (自動)」は速さを測った回の読み込み直後の値で、速さの3回の中央値とは別に読んでいる。
KV キャッシュ q8_0 では、文脈 131,072 トークンでモデルを読み込んだ直後の使用量が 12,618MiB で、全部の層を GPU に置けた。文脈の長さを llama.cpp の自動調整 (--fit。-fitc 16384 で、選べる長さの下限を 16,384 にした) に任せると 170,752 トークンが選ばれ、14,130MiB だった。選ばれる長さはそのときの空きメモリと設定で変わり、決まった上限の値ではない。
q8_0 の使用量は、文脈 4K〜131K の範囲で文脈1トークンあたり約39KiB ずつ、ほぼ直線的に増えた。自動調整が選んだ 170,752 トークンでも、その直線から求めた値 (14,129MiB) と実測 (14,130MiB) がほぼ一致した。この増え方は RTX 5060 Ti・Saluki・llama.cpp b11218 での値で、ほかのモデルや量子化には当てはめられない。
| 文脈の長さ (トークン) | KV キャッシュ q8_0 | KV キャッシュ f16 |
|---|---|---|
| 4,096 | 7,808MiB | 7,928MiB |
| 16,384 | 8,250MiB | 測っていない |
| 16,384 + 画像用の mmproj (F16) | 9,386MiB | 測っていない |
| 32,768 | 8,874MiB | 9,748MiB |
| 40,960 | 9,186MiB | 測っていない |
| 65,536 | 10,122MiB | 11,828MiB |
| 131,072 | 12,618MiB | 測っていない |
| 170,752 (自動) | 14,130MiB | 測っていない |
| 262,144 | 16,010MiB (共有 GPU メモリの使用が 1,880MiB 増加) | 測っていない |
8GB・12GB のカードでは測っていない。画面出力に使っている GPU では、OS の表示処理やほかのアプリが使う分だけ、モデルに使える VRAM が減る。
文脈を土台のモデルの標準いっぱいの 262,144 トークンに指定しても、読み込みは通った。ただし読み込んだ瞬間に VRAM の使用は 16,010MiB とほぼいっぱいになり、共有 GPU メモリの使用も 76MiB から 1,956MiB へ増えた。VRAM が足りずに一部がメインメモリ側へ退避したとみられるが、増えた分がすべてモデルの領域かは切り分けていない。文脈 131,072 でも、読み込みの最後に共有 GPU メモリの使用は 74MiB から 228MiB へ増えた。このときの VRAM の使用 (12,618MiB) は容量の内側で、増えた分が何に使われたかは、記録したカウンタからは分からなかった。文脈の長さを指定できることと、16GB に収まって使えることは別になる。262,144 のときの速さは測っていない。VRAM が足りずにメインメモリ側が使われたときに何が起きるかは、Qwen3.8-27B で指定できる文脈長と使える文脈長の差を VRAM 16GB で測った記事で詳しく扱っている。
KV キャッシュを f16 のままにすると、文脈を伸ばしたときの増え方が大きい。モデルを読み込んだ直後の使用量は、文脈 32,768 で 9,748MiB (q8_0 は 8,874MiB)、65,536 で 11,828MiB (q8_0 は 10,122MiB) だった。
配布元のモデルカードが例に載せている llama-server の起動は、文脈の長さを -c 32768 とし、KV キャッシュの型は指定していない。llama.cpp の server の README によれば、KV キャッシュの型 (-ctk / -ctv) を指定しないと f16 になる。配布元の例のまま (--fit と --parallel を指定しない) 起動したときの使用量は測っていない。README では、--fit の既定は on、--parallel の既定は -1 (同時に処理する数を llama-server に任せる指定) となっている。KV キャッシュを q8_0 にしたときに答えがどう変わるかも測っていない。
配布元の例の起動に、KV キャッシュを8ビットにする指定 (-ctk q8_0 -ctv q8_0) を足すと次の形になる。表の q8_0 の値は、これに --fit off・--parallel 1・-lm mmap --lazy-mode on を足し、-c を表の文脈の長さに変えて測った (自動調整に文脈を選ばせた 170,752 の値は除く)。
llama-server -m Underdog-Saluki-27B-1.0-IQ2-mix.gguf --jinja -ngl 99 -fa on -c 32768 -ctk q8_0 -ctv q8_0画像を読ませる mmproj (F16) を足すと、文脈 16,384 トークンでモデルを読み込んだ直後の使用量は 8,250MiB から 9,386MiB へ増えた (KV キャッシュ q8_0)。
表の値はどれもモデルを読み込んだ直後のもので、作業中はそれより少し増えた。文脈 40,960 で Claude Code の作業とチャットを続けた1回で、nvidia-smi を約24秒おきに読んだ中の最大は 9,486MiB (読み込み直後は 9,186MiB) だった。KV キャッシュは q8_0。読み取りの間に一瞬だけ増えた分は拾えないので、実際の最大はこれより大きかった可能性がある。ほかの文脈の長さや、画像・MTP を使ったときに作業中どれだけ増えるかは測っていない。
生成の速さ（RTX 5060 Ti・RTX 5080）
LLM の処理は2つの段階に分かれる。入力の処理 (prefill) は渡した文章をまとめて計算する段階で、生成 (decode) は答えを1トークンずつ作る段階だ。表には入力 約1K・約4K・約32K トークンのそれぞれで、入力の処理と生成の速さを、1秒あたりのトークン数で「入力の処理 / 生成」の順に載せた。
値は API の応答を受け取った時刻から求めた。入力の処理は、入力のトークン数を「要求を送ってから最初のトークンが届くまでの時間」で割り、生成は、生成したトークン数から1を引いた数を「最初のトークンから最後のトークンまでの時間」で割った。この時間には要求の受け付け、最初のトークンを作る時間、通信も含まれるので、入力の処理だけの速さではなく、llama-server が内部で計った値とも違う。Bonsai 2 27B との比較に載せた速さも、同じ求め方だ。
測り方は、llama.cpp b11218 の llama-server、KV キャッシュ q8_0、flash attention on、--parallel 1。入力はコード系の文章で、約1K・約4K・約32K トークンの入力を同じ起動のまま3回ずつ続けて測り、3回の中央値を取った。実際の入力は、Saluki と MTP 付きのファイルの各回で 1,002〜1,129・4,173〜4,678・31,585〜31,712 トークンだった。生成は 256 トークン、温度0 (greedy)、思考なし。RTX 5060 Ti は画面を出していないカード、RTX 5080 は画面を出しているカードだ。表の置き方は次の3つ。
- 文脈を指定: -ngl 99 --fit off -c 40960 で、層をすべて GPU に置いた
- 文脈を自動調整: -c と -ngl を外し、-fitc 16384 を付けて --fit に文脈の長さを選ばせた。この置き方でも全部の層を GPU に置けた
- MTP 付きのファイル: -c 65536 を指定して層の載せ方を --fit に任せ、--spec-type draft-mtp --spec-draft-n-max 2 を付けた
条件ごとに llama-server を起動し直し (起動の前に、ほかの llama-server が動いていないことを確かめた)、ウォームアップの回は入れていない。前の回の計算を使い回させないよう毎回先頭を変え、長さが目標に近づくよう文章の量を調整した。
1K の入力での生成は、文脈を 40,960 に指定した回で RTX 5060 Ti が1秒あたり 37.2 トークン、RTX 5080 が 71.9 トークンだった。32K の入力では 29.9 と 60.2。llama.cpp の自動調整に文脈を任せて 170,752 (RTX 5060 Ti)・165,888 (RTX 5080) まで伸ばしても、1K の入力の生成は 37.1 と 68.5 だった。
MTP 付きのファイル (8.35GB) は Kujira が配布しているもので、Saluki に Qwen3.8-27B の MTP の層 (multi-token prediction。次の数トークンを先読みして生成を速める仕組み) を足したものだ。配布元 (ConwayResearch) のファイルではない。Kujira 自身が、温度0でも Saluki と出力が完全には一致しないこと、品質の数字は元のファイルのものであることを書いている。
この MTP 付きのファイルで先読み (1回に最大2トークン) を有効にすると、文脈 65,536 を指定した回の1K の入力での生成は、RTX 5060 Ti で1秒あたり 55.1 トークン、RTX 5080 で 106.2 トークンだった。先読みが当たった割合は RTX 5060 Ti で 0.63〜0.72。読み込み直後の使用量は、同じ文脈 65,536 で 11,238MiB と、Saluki 本体 (10,122MiB) より 1,116MiB 多かった。-c を外して自動調整に文脈を選ばせた別の回では、選ばれた文脈は 125,440 (RTX 5060 Ti)・121,088 (RTX 5080) で、Saluki 本体より短かった。MTP 付きのファイルの答えの中身は確かめていない。
| ファイルと置き方 | 1K の入力 (入力の処理 / 生成) | 4K の入力 (入力の処理 / 生成) | 32K の入力 (入力の処理 / 生成) |
|---|---|---|---|
| Saluki・RTX 5060 Ti・文脈を指定 (40,960) | 665 / 37.2 | 797 / 36.1 | 750 / 29.9 |
| Saluki・RTX 5060 Ti・文脈を自動調整 (170,752) | 666 / 37.1 | 794 / 36.1 | 750 / 29.8 |
| Saluki・RTX 5080・文脈を指定 (40,960) | 1,290 / 71.9 | 1,703 / 70.5 | 1,681 / 60.2 |
| Saluki・RTX 5080・文脈を自動調整 (165,888) | 1,247 / 68.5 | 1,628 / 67.0 | 1,588 / 57.1 |
| MTP 付き・RTX 5060 Ti・文脈 65,536 を指定 (層の載せ方は --fit に任せた) | 615 / 55.1 | 751 / 59.7 | 714 / 41.5 |
| MTP 付き・RTX 5080・文脈 65,536 を指定 (層の載せ方は --fit に任せた) | 1,164 / 106.2 | 1,556 / 111.7 | 1,559 / 84.3 |
MTP 付きのファイルは第三者が作ったもので、Saluki 本体とは別のファイルだ。MTP の先読みの指定は llama-server のもので、Ollama と LM Studio では試していない。生成の値は思考なし・256 トークンの短い生成のもので、長い会話の途中の速さではない。Qwen3.8-27B で MTP を有効にしたときに増える VRAM と、速くならない条件は、Qwen3.8-27B の MTP を VRAM 16GB で有効にして測った記事にまとめてある。
同じ測定機・同じ llama.cpp b11218 で以前測った Qwen3.8-27B の UD-IQ4_XS (14.25GB、MTP の先読みあり) は、RTX 5060 Ti で文脈を 40,960 に指定し全部の層を GPU に置いた回で、1K の入力の生成が1秒あたり 50.6 トークンだった。Saluki と並べるときは MTP の有無をそろえる必要があり、Saluki 本体には MTP が無いので、比べる相手は Saluki の 37.2 ではなく MTP 付きのファイルの 55.1 になる。配布されている Saluki 本体をそのまま使うときの値は 37.2 のほうだ。ただし MTP 付きどうしでも、起動の仕方 (文脈 40,960 を指定した回と、文脈 65,536 を指定して層の載せ方を --fit に任せた回) と測った日 (UD-IQ4_XS は 2026年10月3日、Saluki は 2026年10月10日) がそろっていない。4ビット前後の Qwen3.8-27B の必要 VRAM と起動の指定による差は、Qwen3.8-27B の量子化3種を VRAM 16GB で比べた記事で測っている。
Claude Code・チャット・画像で試した結果
Claude Code で3つの作業
Claude Code の作業には、Qwen3.8-27B の UD-IQ4_XS の GGUF に入っているチャットテンプレート (会話をモデルへの入力の形に整える書式) を1行だけ変えたものを使った。このテンプレートは、会話の途中に来た system メッセージで System message must be at the beginning. の例外を出す。以前の測定 (Claude Code 2.1.284) では、このテンプレートのままだと会話の途中に system メッセージが来て例外になり、要求が失敗した。Claude Code が送った時点でそうなっているのか、llama-server が変換した後なのかは切り分けていない。そこで、この例外を出している1行を、例外にせずその場に system メッセージとして書き出す形に変えた。次の - の行が変更前、+ の行が変更後だ。
- {{- raise_exception('System message must be at the beginning.') }}
+ {{- '<|im_start|>system\n' + content + '<|im_end|>' + '\n' }}変えたテンプレートは llama-server の --chat-template-file で、Saluki・Bonsai 2 27B・UD-IQ4_XS のどれにも指定した。Saluki の GGUF に入っているテンプレートは UD-IQ4_XS のものとは中身が違い、そのままでは Claude Code を試していない。
Claude Code 2.1.293 を llama-server (Anthropic 互換の API) につなぎ、小さな Python のリポジトリの複製で3つの作業を3回ずつ行った。リポジトリはレシートの税を計算するもので、テストが1件失敗するバグを仕込んである。作業は次の3つ。
- コードの説明: リポジトリの構成と、失敗するテストの原因を説明する (ファイルは変えない)
- バグ修正: テストが全部通るようにバグを直す
- 機能追加: CSV ファイルから品目のリストを読む関数と、そのテストを足す
Claude Code は非対話のモード (-p) で動かし、Read・Edit・Write・Glob・Grep と python -m pytest は確認なしで実行してよいツールとして許可した (--allowedTools)。モデルに見せるツールそのものは絞っていない。1つの作業のやり取りは最大30回 (--max-turns 30)、1つの作業が1,800秒を超えたら外から止めるようにした。温度や思考の強さは Claude Code の要求に任せており、実際にどの値で動いたかは確かめていない。GPU は RTX 5060 Ti で、文脈を 40,960 に指定し全部の層を GPU に置いた (速さの表の「文脈を指定」と同じ起動)。表の値は作業1つにかかった時間 (秒) とその間のやり取りの回数で、テストは作業のあとに別に pytest を回した結果だ (コードの説明はファイルを変えない作業なので省いた)。比べるために、Qwen3.8-27B の UD-IQ4_XS も同じ起動で測り直した。UD-IQ4_XS は MTP の先読み (1回に最大2トークン) を使った。
Saluki は9回のうち8回を終え、バグ修正と機能追加の後のテストはすべて通った。残る1回 (2回目の機能追加) は、26回目のやり取りで送る入力が 41,263 トークンになり、文脈の上限 40,960 を超えてサーバーが要求を断った。作業は途中のまま終わり、その後のテストは7件が失敗した。Claude Code の側がこの 40,960 という上限を知っていたかは確かめていない。文脈を長くしたときの使用量は「文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）」の表にある。
UD-IQ4_XS は9回とも終わったが、そのうち2回は同じ GPU に別のモデルが読み込まれていた時間と重なったので、比較から外した。表の「除外」がその回で、かかった時間とやり取りの回数は比較に使わず、作業後のテストの結果だけ載せた。重なりの無い回で比べると、コードの説明とバグ修正は UD-IQ4_XS のほうがどの回も短かった。機能追加は、終わった回どうしで Saluki が 350.2秒・291.3秒、UD-IQ4_XS が 193.5秒・323.0秒で、どちらが短いとは言えない。
この比較は参考にとどまる。UD-IQ4_XS は MTP の先読みを使っていて、1K の入力の生成は1秒あたり 50.6 トークン (Saluki は 37.2) と条件がそろっておらず、温度や思考の強さの実際の値も確かめていない。差はモデルの違いだけによるものではなく、原因は切り分けていない。
| モデル | 回 | コードの説明 | バグ修正 | 機能追加 | 作業後のテスト (バグ修正 / 機能追加) |
|---|---|---|---|---|---|
| Saluki | 1回目 | 479.0秒 / 14回 | 248.3秒 / 10回 | 350.2秒 / 15回 | 6件通過 / 14件通過 |
| Saluki | 2回目 | 363.4秒 / 10回 | 238.7秒 / 10回 | 途中で終了 1253.3秒 / 26回 | 6件通過 / 7件失敗・9件通過 |
| Saluki | 3回目 | 212.8秒 / 9回 | 361.4秒 / 10回 | 291.3秒 / 15回 | 6件通過 / 11件通過 |
| UD-IQ4_XS | 1回目 | 190.3秒 / 9回 | 214.3秒 / 9回 | 除外 | 6件通過 / 19件通過 |
| UD-IQ4_XS | 2回目 | 除外 | 178.5秒 / 10回 | 193.5秒 / 13回 | 6件通過 / 12件通過 |
| UD-IQ4_XS | 3回目 | 183.1秒 / 9回 | 155.7秒 / 10回 | 323.0秒 / 14回 | 6件通過 / 15件通過 |
小さなリポジトリの3つの作業の結果で、大きなリポジトリや長い作業の結果ではない。Claude Code の答えに中国語が混ざることは、Saluki・UD-IQ4_XS・Bonsai 2 27B のどれの9回にも無かった。
チャットの3つの課題
チャットの課題は llama.cpp b11218 (Bonsai 2 27B は PrismML のビルド b10685) の llama-server で出した。思考 (reasoning) の強さは high を指定し (使ったテンプレートが xhigh に置き換えてモデルへ渡す)、1回の出力の上限は 8,192 トークン、温度0 (greedy)。どの課題も3回ずつで、答えは3回とも同じだった。時間は3回の中央値。RTX 5080 の文脈 16,384 は、以前の Qwen3.8-27B の測定とそろえた値だ。
1つめは税込み合計の問題。10% の商品と 8% の商品を別々に合計し、それぞれ1円未満を四捨五入して税額を出す店で、105円 (10%) と 1,031円 (8%) を1つずつ買ったときの税込み合計を、途中の式も書いて求めさせた。正解は、税額が 105×0.10=10.5 で 11円、1,031×0.08=82.48 で 82円。合計は 105+1,031+11+82=1,229円になる。
Saluki は RTX 5060 Ti・RTX 5080 の計6回とも、税額 11円・82円と、税額の合計 93円までは正しく出し、最後の 105+1,031+93 を 2,229円とした。Bonsai 2 27B は3回とも 1,229円だった。
2つめは PC 構成の相談。VRAM 16GB の GPU が1枚とメインメモリが 96GB の PC で、総パラメータ 100B を超える MoE の LLM を動かすとき、GPU とメインメモリにそれぞれ何を置くと速くなるかを、理由と合わせて説明させた。決まった正解が無いので、答えが最後まで出たかだけを見た。Saluki は RTX 5060 Ti (文脈 40,960) で約200秒・思考を含め 7,200 トークンで答え終えたが、RTX 5080 (文脈 16,384) では上限の 8,192 トークンに達して答えは途中までだった。2つの GPU で結果が分かれた原因は確かめていない。Bonsai 2 27B は3回とも上限に達し、答えの本文は出なかった。PrismML の既知の不具合の一覧 (KNOWN_ISSUES.md) は、思考も出力の上限に数えられるので上限が尽きると答えが空になるとして、出力の上限を 16,384 トークン以上、文脈を 65,536 にすることを勧めている。この課題の上限 8,192 トークンと文脈 40,960 はそれより小さく、答えが出なかったことをモデルの力の差とは言えない。
3つめはコードを書く課題。フォルダーの中の .log ファイルをすべて読み、「ERROR」を含む行の数をファイルごとに数えて多い順に表示する関数を、標準ライブラリだけで書かせた。Saluki も Bonsai 2 27B も関数を返したが、その関数が正しく動くかは確かめていない。
| 課題 | Saluki・RTX 5060 Ti (文脈 40,960) | Saluki・RTX 5080 (文脈 16,384) | Bonsai 2 PQ2_0・RTX 5060 Ti (文脈 40,960) |
|---|---|---|---|
| 税込み合計の計算 (正解 1,229円) | 32.5秒・不正解 (2,229円) | 24.1秒・不正解 (2,229円) | 27.5秒・正解 (1,229円) |
| PC 構成の相談 | 199.9秒・答え終えた (思考を含め 7,200 トークン) | 115.5秒・上限 8,192 トークンに達し答えは途中まで | 182.1秒・上限 8,192 トークンに達し答えなし |
| ログの ERROR を数える関数 | 63.2秒・関数を返した | 54.7秒・関数を返した | 20.0秒・関数を返した |
税の問題を Ollama・LM Studio で出し直すと
温度0 (greedy) は毎回いちばんそれらしい言葉を選ぶので、同じ環境・設定なら同じ問題にはほぼ同じ答えが出る。温度0の6回が同じ誤りだったのは、その1つの誤りが繰り返されたものだ。そこで同じ税の問題を、Ollama 0.40.2 (思考あり) と LM Studio 0.4.26 で、サンプリングの設定 (温度など) を既定のままにして出し直した。Ollama は RTX 5060 Ti、LM Studio は RTX 5080 で動かした。Ollama では5回のうち3回が 1,229円・2回が 2,229円、LM Studio では5回とも 1,229円だった。
| 動かし方 | 生成の設定 | 正解 (1,229円) の回数 | 不正解の答え |
|---|---|---|---|
| llama.cpp b11218 の llama-server (チャットの3つの課題と同じ設定) | 温度0 (greedy)・思考 high | 0 / 6 | 6回とも 2,229円 |
| Ollama 0.40.2 | 既定のサンプリング・思考あり | 3 / 5 | 2回とも 2,229円 |
| LM Studio 0.4.26 (ランタイム 2.55.0) | 既定のサンプリング | 5 / 5 | なし |
回数が少なく、正解の割合として一般化できる数ではない。温度などのほかに、実行するソフト、チャットテンプレート (llama-server は1行変えたもの、Ollama と LM Studio は GGUF に入っているもの)、思考の指定、文脈の長さ、GPU も違い、差の原因は切り分けていない。Ollama と LM Studio の既定の温度などの値も確かめていない。配布元が挙げる設定 (思考ありで温度 0.6 など) では試していない。
画像の3つの課題
画像の課題は Saluki だけで測った。mmproj (F16) を足し、RTX 5060 Ti・文脈 16,384・思考なし・温度0・出力の上限 1,024 トークンで3つの課題を3回ずつ出し、どの課題も3回とも同じ答えだった。
1つめは、見出しを含めて5行・4列の表を写した画像を Markdown に書き起こす課題で、全セルが一致した。2つめは、画像の下の帯に書かれた日本語の題を書き出す課題で、文字が一致した。
3つめは、GPU のカードを1枚写した写真を見せ、何が写っているか、見えている部品の名前を挙げて説明させる課題。写真の下の帯には「NVLink の無い RTX 5080+5060 Ti」を含む文字が入っている。Saluki は「2つのファンを備えた GPU が1枚」と正しく答えたうえで、写っているカードを「RTX 5080 と RTX 5060 Ti を NVLink なしで接続した構成を示している」と説明し、帯の文字をカードの説明に混ぜた。
Bonsai 2 27Bと同じ作業で並べると
配布元の比較の表にある Bonsai 2 は、5.95GB と書かれている。PrismML が配布する Bonsai 2 27B の低ビットの2つのファイル (PTQ1_0 と PQ2_0) のうち、この大きさに当たるのは PTQ1_0 (5,946,648,928 バイト) のほうだ。本記事で並べたのはもう一方の PQ2_0 (7,206,168,928 バイト、7.21GB) で、PTQ1_0 は測っていない。配布元は表の「Bonsai 2」が誰のどのファイルかを書いておらず、PTQ1_0 に当たるというのは大きさから読んだものだ。
Bonsai 2 27B は、PrismML が配布する llama.cpp のビルド (b10685) で動かした。このビルドは GitHub の PrismML-Eng/llama.cpp (llama.cpp のフォーク) で、リリースのタグ prism-b10685-7dffb15 (2026年9月15日公開) として配布されている。標準の llama.cpp のビルド b9745 では、低ビットの2つのファイルとも読み込めなかった (2026年9月18日の測定)。Saluki に使った標準のビルド b11218 では、Bonsai 2 27B を試していない。Saluki は b11218 でそのまま読み込めた。2つのファイルの中身と PrismML のビルドを使う理由は、Bonsai 2 27B を VRAM 16GB で動かした記事で扱っている。
並べた条件は、どちらも RTX 5060 Ti で文脈 40,960 を指定し、全部の層を GPU に置き、KV キャッシュは q8_0 で、課題と主な設定も同じだ (どちらも MTP なし。Saluki の起動に付けた --lazy-mode は PrismML のビルドに無いので、Bonsai 2 27B には付けていない)。どちらも配布元が勧める設定では測っていない (Bonsai 2 27B の配布元が思考ありに勧める値は温度 1.0・top_p 0.95・top_k 20・min_p 0.05)。チャットテンプレートも、どちらも GGUF に入っているものではなく、Claude Code の作業と同じ、1行変えたものを使った。PrismML の既知の不具合の一覧によれば、Bonsai 2 27B の GGUF のテンプレートは、system メッセージが先頭に1つでないと要求を断り、思考の強さ high も受け付けない。Bonsai 2 27B の PQ2_0 は、モデルを読み込んだ直後の使用量が 8,580MiB と Saluki (9,186MiB) より少なく、1K の入力の生成も1秒あたり 46.5 トークンと Saluki (37.2) より多かった。Claude Code は Saluki と同じく9回中8回を終え、残る1回 (2回目の機能追加) も同じく、入力が 40,996 トークンになって文脈の上限で断られた。機能追加で出力したトークンは Bonsai 2 27B のほうが多かった (11,196〜37,984、Saluki は 6,747〜16,982)。
Saluki と Bonsai 2 27B の比較表のうち、Ollama・LM Studio の行は「OllamaとLM Studioで読み込めるか」の結果を再掲した。画像の課題は Saluki だけで測ったので、表には入れていない。
| 項目 | Saluki (IQ2-mix) | Bonsai 2 27B (PQ2_0) |
|---|---|---|
| ファイルの大きさ | 7.90GB | 7.21GB |
| モデルを読み込んだ直後の使用量 | 9,186MiB | 8,580MiB |
| 生成 (1K / 32K の入力、1秒あたりのトークン数) | 37.2 / 29.9 | 46.5 / 36.1 |
| Claude Code の9回 | 8回終えた (1回は文脈の上限) | 8回終えた (1回は文脈の上限) |
| 税込み合計の計算 (温度0) | 0 / 3 正解 (RTX 5080 の3回も同じ誤り) | 3 / 3 正解 |
| PC 構成の相談 | 答え終えた (RTX 5080・文脈 16,384 では上限 8,192 トークンに達し途中まで) | 3回とも上限 8,192 トークンに達し答えなし |
| Ollama 0.40.2・LM Studio 0.4.26 | どちらも読み込めた | どちらも読み込めなかった |
| 動かした llama.cpp | 標準の b11218 | PrismML のビルド b10685 (標準の b9745 では読み込めなかった。b11218 では試していない) |
作業ごとに結果が分かれた。税の計算は Bonsai 2 27B が3回とも正解し、Saluki は温度0で、RTX 5060 Ti でも RTX 5080 でも同じ誤りだった。どちらも同じ問題を温度0で繰り返し出した結果で、別々の問題での正解率を測ったものではない。PC 構成の相談は Saluki が RTX 5060 Ti で答え終え、Bonsai 2 27B は3回とも答えが出なかった (出力の上限 8,192 トークンは、PrismML が勧める 16,384 トークン以上より小さい)。配布元の比較 (Underdog Bench) はツール呼び出しの成績で、本記事の作業とは測っているものが違う。本記事の結果からは、どちらが上とは一律に言えない。配布元が勧める設定や、GGUF に入っているテンプレートで比べたものでもない。
Bonsai 2 27B の Claude Code の回ごとの値は次のとおり。作業と設定は「Claude Code・チャット・画像で試した結果」の節の Saluki と同じで、PrismML のビルド b10685 を RTX 5060 Ti で、文脈 40,960 を指定し全部の層を GPU に置いて動かした。小さなリポジトリの3つの作業の結果で、大きなリポジトリや長い作業の結果ではない。
| 回 | コードの説明 | バグ修正 | 機能追加 | 作業後のテスト (バグ修正 / 機能追加) |
|---|---|---|---|---|
| 1回目 | 287.5秒 / 8回 | 244.8秒 / 10回 | 924.0秒 / 19回 | 6件通過 / 12件通過 |
| 2回目 | 143.8秒 / 8回 | 337.4秒 / 9回 | 途中で終了 1699.8秒 / 26回 | 6件通過 / 11件失敗・7件通過 |
| 3回目 | 282.5秒 / 12回 | 477.4秒 / 11回 | 474.1秒 / 19回 | 6件通過 / 12件通過 |
検証環境と測り方
GPU は2枚使った。RTX 5060 Ti 16GB は OCuLink で外付けした、画面を出していないカード (待機時の使用 0MiB)。RTX 5080 は画面を出しているカードだ。測定機の OS は Windows 11 で、詳しい構成は検証環境のページに載せている。
llama.cpp は 2026年9月27日に公開されたビルド b11218 を使った。llama-server は CUDA_VISIBLE_DEVICES で使う GPU を1枚だけ見せて起動し、flash attention on・--parallel 1・KV キャッシュ q8_0 とした (VRAM の表の f16 の列を除く)。バッチの大きさ (-b・-ub) とスレッド数 (-t) は指定せず、既定のままにした。b11218 は Windows 向けの CUDA 13.4 のビルドで、NVIDIA のドライバは 610.47 だった (計測の前と後に確かめた)。「文脈を指定」の回は -ngl 99 --fit off で文脈の長さを指定し、「文脈を自動調整」の回は -c と -ngl を外し -fitc 16384 を付けて --fit に文脈の長さを選ばせた。Saluki の起動には -lm mmap --lazy-mode on も付けた (PrismML のビルドには --lazy-mode が無いので、Bonsai 2 27B には -lm mmap だけ)。付けたことの影響は確かめていない。速さは入力 約1K・約4K・約32K トークン (長さは目標に近づけて調整) に対して 256 トークンを温度0・思考なしで生成させ、3回の中央値を取った。値は API の応答の時刻から求めたもので、求め方は「生成の速さ（RTX 5060 Ti・RTX 5080）」の節に書いた。メモリの値は、どれも1回の読み込みの直後に nvidia-smi で読んだもので、速さの中央値とは別の集計だ。文脈 131,072 と 262,144 の回は Windows の GPU メモリのカウンタを1秒おきに記録した。Claude Code とチャットを続けた回は nvidia-smi を約24秒おきに読んだ。
測ったファイル (Saluki 本体・mmproj F16・Kujira の MTP 付きのファイル・Bonsai 2 27B の PQ2_0・Qwen3.8-27B の UD-IQ4_XS) は、手元で計算した sha256 が配布元のリポジトリに載っている値と一致した。
チャットテンプレートは、「Claude Code で3つの作業」の節に書いたもの (UD-IQ4_XS の GGUF に入っているテンプレートの1行を変えたもの) を、チャットと画像の課題にも使った。このテンプレートは、思考の強さの指定 high を xhigh に置き換えてモデルへ渡す。Ollama と LM Studio は GGUF に入っているテンプレートのまま使った。
以前 Qwen3.8-27B を測ったときの Claude Code は 2.1.284 で、今回は 2.1.293 だったため、比べるための UD-IQ4_XS も 2.1.293 で測り直した。2.1.293 での UD-IQ4_XS のコードの説明は 183〜190秒で、2.1.284 のときの 64〜105秒より長かった。Claude Code の番号の違いによるのか、ほかの原因によるのかは確かめていない。
本記事で測っていないことは次のとおり。
- VRAM 8GB・12GB のカードでの動作 (使用量はすべて RTX 5060 Ti 16GB での値)
- Ollama・LM Studio での長い文脈と画像の入力、使用量と速さの比較
- Bonsai 2 27B の PTQ1_0 と、Bonsai 2 27B での画像の課題
- 文脈 262,144 のときの速さと、KV キャッシュを q8_0 にしたときの答えの違い
- 配布元が挙げる設定 (思考ありで温度 0.6・top_p 0.95・top_k 20 など) での答え
本記事の実測値は、2026年10月10日に llama.cpp b11218・Ollama 0.40.2・LM Studio 0.4.26・Claude Code 2.1.293 で測ったもの (比べた Qwen3.8-27B の値の一部は 2026年10月3日、Bonsai 2 27B を標準の llama.cpp で読ませた結果は 2026年9月18日の測定)。どのソフトも、これより後に出たものでは測り直していない。
まとめ
画面を出していない VRAM 16GB のカードでは、KV キャッシュを8ビット (q8_0) にすると、Saluki の全部の層を GPU に置いたまま文脈 131,072 トークンまで読み込めた (読み込み直後の使用量 12,618MiB)。土台のモデルの標準 262,144 トークンの半分にあたる。262,144 トークンでも読み込みは通ったが、VRAM の使用は 16,010MiB とほぼいっぱいになり、共有 GPU メモリの使用も大きく増えた。指定した文脈で読み込めることと、16GB に収まって使えることは別だ。
8GB・12GB のカードで動くかは試していない。文脈の長さごとの使用量の表は、RTX 5060 Ti 16GB で llama-server にモデルを読み込んだ直後の値で、手元のカードで実際に空いている VRAM と見比べる目安にはなるが、動くことを保証する値ではない。動かしている間は使用量が読み込み直後より増え、文脈 40,960 で作業を続けた1回では、約24秒おきに読んだ中の最大が読み込み直後より 300MiB 多かった。1回の観測で、増える量の上限ではない。
Ollama と LM Studio では Saluki を読み込めた。読み込んだときの文脈は、Ollama が既定の 4,096 トークン、LM Studio が lms コマンドで読み込んだときの既定の 8,192 トークンだったので、長い文脈を使うにはそれぞれの設定で伸ばすことになる。この2つでの使用量は測っていない。
VRAM に載りきらないときの動きは、起動の指定で変わる。RTX 4070 SUPER 12GB で4ビット前後の Qwen3.8-27B を測ったときは、層の置き方を llama.cpp に任せたので、一部の層が CPU へ回った。Saluki の 262,144 トークンは、全部の層を GPU に置く指定 (-ngl 99) で自動調整を切っていたので、読み込みは通り、共有 GPU メモリの使用が増えた。Saluki を CPU と GPU に分けたときの速さは測っていない。
Bonsai 2 27B と同じ課題で比べると、作業ごとに結果が分かれた。毎回いちばんそれらしい言葉を選ぶ設定 (温度0) の llama-server では、税込み合計の計算は Bonsai 2 27B だけが正解し、PC 構成の相談は RTX 5060 Ti の Saluki だけが最後まで答えた。Bonsai 2 27B が答えを出せなかったのは、PrismML が勧めるより小さい出力の上限 (8,192 トークン) での結果だ。Saluki が間違えた税の計算は、温度などを既定のままにした Ollama で5回中3回、LM Studio で5回とも正解したが、原因は切り分けていない。
同じ RTX 5060 Ti で、MoE の LFM2.5-24B-A2B についても文脈の長さごとの使用量を測った (LFM2.5-24B-A2BはVRAM 16GBで動くか)。文脈1トークンあたりの使用量の増え方を Saluki と比べている。
参考資料
- ConwayResearch/Underdog-Saluki-27B-1.0 (Hugging Face)
- Kujira/Underdog-Saluki-27B-1.0-MTP-GGUF (Hugging Face)
- Qwen/Qwen3.8-27B (Hugging Face)
- prism-ml/Ternary-Bonsai-2-27B-gguf (Hugging Face)
- PrismML-Eng/llama.cpp (GitHub、Bonsai 2 用の llama.cpp のフォーク)
- llama.cpp server README
- llama.cpp b11218 (リリース)
- Ollama ドキュメント: Importing a Model
- Ollama ドキュメント: Context length
- Ollama v0.40.2 (リリース)
