この記事の要点
文脈長の指定だけで 256K まで動かすなら、Ollama の qat タグ (QAT は量子化を学習に組み込む手法で、qat タグはその手法で作った 4 ビットの Q4_0 の重み) で動いた。RTX 5080 では一部が CPU 側に回り、文脈を伸ばすほど生成が遅くなった。
RTX 5080 では llama.cpp で QAT のファイルの全部の層を GPU に置いた構成のほうが、短い回の生成 (短いプロンプトに続く生成) が速かった。エンジン自体の差とは読めず、全部の層を GPU に置けるかどうかという構成の違いを含む。KV キャッシュを量子化するとあふれない文脈長が伸び、MTP (下書きモデルが先の数トークンを下書きし、本体が確かめる仕組み) を足すと短い回の生成はさらに速くなった。QAT のファイルは、Google 公式と unsloth のどちらもこの記事の 3 つの課題を同じように解けた。
1 枚では QAT のどのファイルも、速さで見て GPU からあふれなかったのは 64K までで、公式 Q4_0 を 2 枚に分けると 256K まであふれなかった。
Gemma 4 26B-A4BのQATはVRAM 16GBでどう使うか
Ollama の qat タグ (gemma4:26b-a4b-it-qat) は RTX 5080 1 枚で 8K から 256K まで動いたが、この記事の Ollama の設定では、どの文脈長でも 16GB の GPU に全部は載らず、一部が CPU 側に回った。llama.cpp で公式 Q4_0 の全部の層を GPU に置いて動かすと、KV キャッシュを q8_0 にしたときに RTX 5080 で 32K、RTX 5060 Ti で 64K まで、GPU からあふれずに長い入力まで読めた (この記事の「あふれる」は、モデルと KV キャッシュが GPU の VRAM に入りきらず、エラーにはならないまま速さだけが大きく落ちた状態を指す)。なお、この記事の「全層 GPU」は全部の層を GPU に置く指定 (-ngl 99) のことで、「あふれなかった」は速さの落ち方で判定したもの。すべての重みが VRAM にあることまでは確かめていない。公式 Q4_0 と unsloth の QAT ファイルを、測った KV の型 (f16・q8_0) で 1 枚で動かした範囲では、あふれずに測れたのはどの組も 64K までだった。64K を超える文脈は、RTX 5080 と RTX 5060 Ti の 2 枚に公式 Q4_0 を分けて載せると、256K まで全層 GPU のままあふれなかった。
速さは 2 種類の回で測った。「短い回」は短いプロンプトに続けて生成させた回、「長い回」は文脈いっぱい (Ollama は約 75%) まで文章を入れてから生成させた回で、表の「短い回の生成」は短い回の生成の速さ、「長い入力の読み込み」は長い回で入れた文章を読む速さ、「長い入力のあとの生成」はその文章を読んだあとに続けて生成した速さを表す。
文脈長 8K の短い回の生成を、エンジンと構成ごとに並べたのが「8K の短い回の生成の図」になる。
図の Ollama の 2 本は、モデルの一部が CPU 側に載った状態の値で、生成させた長さと、モデルが受け取るプロンプトの形 (チャットのテンプレートを通すかどうか) も llama.cpp と違う。そのため、図の差をエンジンそのものの速さの差としては読めない。llama.cpp の中では、MTP の下書きモデルを足した構成が 1 枚でも 2 枚でも、足さない構成より上に来た。
量子化の形式 (Q4_K_M・Q8・QAT) の違いをまず押さえたい場合は量子化フォーマットの選び方の記事が前提になる。Ollama と llama.cpp がそもそもどう違うかは、Ollama・llama.cpp・LM Studio・vLLM の推論エンジン比較で整理している。
Gemma 4 26B-A4BとQATのファイル
QAT のモデルカード (google/gemma-4-26B-A4B-it-qat-q4_0-gguf) の仕様表によると、Gemma 4 26B-A4B は Google DeepMind の Gemma 4 ファミリーの MoE (Mixture-of-Experts) モデルで、総パラメータは 25.2B、1 トークンあたりに動くパラメータは 3.8B。エキスパートは 128 個のうち 8 個が動き、ほかに共有のエキスパートが 1 個ある。層は 30。名前の「26B」「A4B」は、仕様表の総パラメータ 25.2B と動くパラメータ 3.8B をおおよその大きさで表した呼び名。MoE でも、全部を GPU で動かすには、生成で動く 3.8B ぶんだけでなく 25.2B 全体の重みを VRAM に置く必要があり、そこが 16GB の GPU での課題になる。公式 Q4_0 を RTX 5080 で読み込んだ llama.cpp の起動ログでは、全部の層を GPU に置いても 577.50MiB の重みが CPU 側のメモリに残った。
同じモデルカードは、文脈長の上限を 256K トークンとし、26B-A4B の入力はテキストと画像で、音声の入力に対応するのは E2B・E4B・12B だと書いている。llama.cpp の起動ログでも、公式 Q4_0 のファイルの学習時の文脈長 (n_ctx_train) は 262,144 トークンと出た。この記事で測った文脈長の刻み (以下「段」と呼ぶ) は 8K (8,192)・32K (32,768)・64K (65,536)・128K (131,072)・256K (262,144 トークン) で、最大の 256K はこのモデルの学習時の文脈長の上限なので、それより長い文脈は測らなかった。
QATは普通の量子化と何が違うか
Google のブログ (2026年6月5日) の説明では、QAT (Quantization-Aware Training) は学習が終わってから量子化するのではなく、量子化を学習の中に組み込む。学習中に量子化を模すことで、圧縮したときの品質の落ち方を小さくするという。この記事では、学習の中身は確かめていない。Google はこの QAT の重みを、Q4_0 という 4 ビットの量子化形式で出している。
配布元のモデルカードは、QAT の重みは bfloat16 と同じくらいの品質を保ったまま、読み込みに要るメモリを大きく減らせると書いている。これは配布元の主張で、この記事では bfloat16 の重みと比べていない。
この記事で使ったファイルとOllamaのタグ
Google の QAT のリポジトリには、本体の gemma-4-26B_q4_0-it.gguf と、画像を読むための gemma-4-26B-it-mmproj.gguf が入っていて、ライセンスは Apache 2.0。unsloth の gemma-4-26B-A4B-it-qat-GGUF は、モデルカードのメタデータで Google の QAT の量子化前の重み (google/gemma-4-26B-A4B-it-qat-q4_0-unquantized) をもとにしたと示していて、この記事ではそのうち UD-Q4_K_XL を使った。unsloth がそこからどう量子化したかの説明は読んでいない。比べるために使った unsloth の gemma-4-26B-A4B-it-GGUF の UD-IQ4_XS は、メタデータの記載では QAT でない元の重み (google/gemma-4-26B-A4B-it) をもとにしている。
llama.cpp で使った 4 つのファイルを、記事の中での呼び名とあわせて「4 つのファイルの表」にまとめた。大きさは手元に取得したファイルのバイト数を測った値。
| 記事での呼び名 | ファイル名 | リポジトリ | もとにした重み (メタデータの記載) | 大きさ |
|---|---|---|---|---|
| 公式 Q4_0 | gemma-4-26B_q4_0-it.gguf | google/gemma-4-26B-A4B-it-qat-q4_0-gguf | QAT | 14,439,363,584 バイト (13.45GiB) |
| unsloth UD-Q4_K_XL (QAT) | gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf | unsloth/gemma-4-26B-A4B-it-qat-GGUF | google/gemma-4-26B-A4B-it-qat-q4_0-unquantized | 14,249,047,104 バイト (13.27GiB) |
| unsloth UD-IQ4_XS (QATでない) | gemma-4-26B-A4B-it-UD-IQ4_XS.gguf | unsloth/gemma-4-26B-A4B-it-GGUF | google/gemma-4-26B-A4B-it | 13,597,177,568 バイト (12.66GiB) |
| 画像用の mmproj | gemma-4-26B-it-mmproj.gguf | google/gemma-4-26B-A4B-it-qat-q4_0-gguf | — | 1,194,828,160 バイト (1.11GiB) |
測った GPU の容量は、nvidia-smi の表示で RTX 5080 が 16,303MiB (15.92GiB)、RTX 5060 Ti が 16,311MiB (15.93GiB)。公式 Q4_0 の本体 (13.45GiB) はどちらにも入る大きさだが、KV キャッシュと計算用の領域を足すと余裕は小さい。
Ollama では、公式ライブラリの 3 つのタグを使った。中身と大きさは ollama.com のタグのページの表示で、「Ollama の 3 つのタグの表」にまとめた。
| タグ | 中身 (ollama.com の表示) | 表示の大きさ (10 進の GB) |
|---|---|---|
| gemma4:26b-a4b-it-qat | Q4_0 の本体 (14GB) と画像用の projector (1.2GB) | 16GB |
| gemma4:26b-a4b-it-q4_K_M | — | 18GB |
| gemma4:26b (取り込まれたのは llama.cpp 向けの 19GB) | llama.cpp 向けは Q4_K_M の本体 (17GB)・projector・MTP の下書きモデル (gemma4-assistant、462MB)。ほかに mlx 向けの 16GB のものが並ぶ | 16GB - 19GB (llama.cpp 向けは 19GB) |
既定の gemma4:26b は、ollama.com のタグ一覧では大きさが 16GB - 19GB と表示され、個別のページには mlx 向けの 16GB のものと、llama.cpp 向けの 19GB のものの 2 つが並ぶ。19GB のほうは gemma4:26b-a4b-it-mtp-q4_K_M と同じ digest で、この記事の Windows の Ollama に取り込まれたのもこの llama.cpp 向けの 19GB だった (手元の digest も同じ)。この記事の gemma4:26b の値は、MTP の下書きモデル込みで測ったもの。Ollama がこの下書きモデルをどう使っているかは確かめていない。
Ollamaで動かす: qatタグは256Kまで動くが一部はCPU側
Ollama の 3 つのタグのうち、短い回の生成は 128K までのどの文脈長でも qat タグが一番速く、8K で 107 tok/s だった。256K では qat タグと gemma4:26b がほぼ並んだ。qat タグの GPU に載った割合は、8K の 84% から 256K の 50% まで下がった。
3つのタグを8Kから256Kまで測った結果
RTX 5080 1 枚、Ollama 0.40.13、思考なし (think false) で 3 つのタグを測り、各 3 回の中央値を「Ollama の実測表」に載せた。Ollama の短い回は約 60 トークンのプロンプトに 512 トークンを生成させ、長い回は文脈長の約 75% の文章を入れてから生成させた。GPU に載った割合は、API (/api/ps) の size_vram ÷ size で計算したメモリ量の比率で、層の数の比率ではない。gemma4:26b は MTP の下書きモデル入りのタグで、/api/ps の size がタグの大きさより小さい値で出て、その値の意味を確かめられなかったので「—」にした。
| タグ | 文脈長 | 短い回の生成 | 長い入力の読み込み | 長い入力のあとの生成 | 長い入力 | GPUに載った割合 |
|---|---|---|---|---|---|---|
| gemma4:26b-a4b-it-qat | 8K | 107 tok/s | 4,843 tok/s | 102 tok/s | 約6,100トークン | 84% |
| gemma4:26b-a4b-it-qat | 32K | 96 tok/s | 4,747 tok/s | 88 tok/s | 約24,400トークン | 80% |
| gemma4:26b-a4b-it-qat | 64K | 88 tok/s | 4,065 tok/s | 75 tok/s | 約48,600トークン | 76% |
| gemma4:26b-a4b-it-qat | 128K | 66 tok/s | 2,900 tok/s | 55 tok/s | 約97,400トークン | 66% |
| gemma4:26b-a4b-it-qat | 256K | 52 tok/s | 1,971 tok/s | 38 tok/s | 約194,700トークン | 50% |
| gemma4:26b-a4b-it-q4_K_M | 8K | 77 tok/s | 3,640 tok/s | 75 tok/s | 約6,100トークン | 73% |
| gemma4:26b-a4b-it-q4_K_M | 32K | 73 tok/s | 3,591 tok/s | 68 tok/s | 約24,300トークン | 70% |
| gemma4:26b-a4b-it-q4_K_M | 64K | 66 tok/s | 3,228 tok/s | 59 tok/s | 約48,700トークン | 65% |
| gemma4:26b-a4b-it-q4_K_M | 128K | 53 tok/s | 2,482 tok/s | 46 tok/s | 約97,400トークン | 57% |
| gemma4:26b-a4b-it-q4_K_M | 256K | 47 tok/s | 1,821 tok/s | 35 tok/s | 約194,800トークン | 43% |
| gemma4:26b (MTP入り) | 8K | 89 tok/s | 3,195 tok/s | 81 tok/s | 約6,100トークン | — |
| gemma4:26b (MTP入り) | 32K | 83 tok/s | 3,217 tok/s | 72 tok/s | 約24,400トークン | — |
| gemma4:26b (MTP入り) | 64K | 79 tok/s | 3,030 tok/s | 65 tok/s | 約48,700トークン | — |
| gemma4:26b (MTP入り) | 128K | 59 tok/s | 2,449 tok/s | 49 tok/s | 約97,500トークン | — |
| gemma4:26b (MTP入り) | 256K | 53 tok/s | 1,845 tok/s | 34 tok/s | 約195,100トークン | — |
Ollama の実測表から読めるのは、qat タグでも 8K の時点で 16GB の GPU に全部は載っておらず、文脈を伸ばすほど GPU に載る割合と速さがそろって下がったこと。それでも 256K で止まらずに動き、約 19 万 5 千トークンの長い入力を読めた。
qat タグは画像用の projector を含むタグで、llama.cpp の速さとあふれなかった文脈長の計測は mmproj を付けない本体だけで行った。Ollama の KV キャッシュの型は指定せず既定のまま測っていて、8K でも 84% にとどまった理由は確かめていない。
既定の gemma4:26b は、短い回の生成が q4_K_M のタグより速く、128K までは qat タグより遅かった。gemma4:26b の /api/ps の size は 8K で 1,593,751,631 バイトと、タグの大きさ (18,731,025,629 バイト) より小さく出たため、GPU に載った割合は読めなかった。
手元でモデルが GPU と CPU にどう分かれて載ったかは、Ollama のドキュメントにあるとおり、ollama ps の PROCESSOR の欄で確かめられる。同じ RTX 5080 で gemma4:26b が 16GB に載りきらないときの消費電力は、MoE の消費電力を Ollama で測った記事で見ている。
長い文脈を使うときの指定
Ollama のドキュメントによると、VRAM が 24GiB 未満の GPU では文脈長が既定で 4k になる。16GB の GPU では、この記事の 8K 以上の段はどれも、文脈長を指定しないと使えない。
Ollama の FAQ では、文脈長はサーバーを起動するときの環境変数 OLLAMA_CONTEXT_LENGTH か、ollama run の中の /set parameter num_ctx で指定できる。API から呼ぶときは options の num_ctx で指定し、この記事の計測もこの方法で文脈長を決めた。qat タグを計測と同じ思考なしにして、64K で対話に使う例は次のとおりで、1 行目で起動し、2 行目は起動後の対話の中で打つ。
ollama run gemma4:26b-a4b-it-qat --think=false/set parameter num_ctx 65536この例の指定の意味は「Ollama の指定の表」のとおり。
| 指定 | 意味 |
|---|---|
gemma4:26b-a4b-it-qat |
Q4_0 の本体と画像用の projector を合わせた qat タグ |
--think=false |
思考 (thinking) を使わない |
/set parameter num_ctx 65536 |
ollama run の中で文脈長を 65,536 トークン (64K) にする |
OLLAMA_CONTEXT_LENGTH |
サーバーを起動するときに文脈長を指定する環境変数 |
options の num_ctx |
API から呼ぶときの文脈長 |
Windows の Ollama は、ユーザーとシステムの環境変数を引き継ぐ。OLLAMA_CONTEXT_LENGTH を設定するときは、Ollama の FAQ のとおり、タスクバーから Ollama を終了し、設定アプリで環境変数を編集してから、スタートメニューから Ollama を起動し直す。
llama.cppで動かす: KVキャッシュをq8_0にすると全層GPUのままあふれなかった文脈長が伸びる
llama.cpp では、KV キャッシュの型を f16 から q8_0 にすると、どのファイル・GPU でも全層 GPU のままあふれなかった文脈長が同じか長くなった。全層 GPU のままあふれていない範囲では、RTX 5080 1 枚の短い回の生成は公式 Q4_0・KV q8_0・8K で 153 tok/s だった。
起動コマンドと指定の意味
公式 Q4_0 を RTX 5080 1 枚で、KV キャッシュを q8_0 にして 32K で動かすときのコマンドは次のとおり。RTX 5060 Ti では -c 65536 にすると 64K になる。2 枚の GPU が入った機械では llama.cpp が既定で 2 枚に分けて載せるので、1 枚で動かすなら CUDA_VISIBLE_DEVICES で使う GPU を絞る (この記事の計測と同じ)。
llama-server -m gemma-4-26B_q4_0-it.gguf -ngl 99 -c 32768 -fa on -ctk q8_0 -ctv q8_0各指定の意味を「llama.cpp の起動コマンドの表」にまとめた。最後の行の --reasoning off は、チャットで使うときに足す指定。
| 指定 | 意味 |
|---|---|
-m gemma-4-26B_q4_0-it.gguf |
読み込むモデルのファイル (公式 Q4_0) |
-ngl 99 |
VRAM に置く層の数の上限。99 は Gemma 4 26B-A4B の層の数 (30) より大きく、全部の層を GPU に置く |
-c 32768 |
文脈の大きさ (トークン数)。32,768 は 32K |
-fa on |
Flash Attention を使う |
-ctk q8_0 |
KV キャッシュの K の型を q8_0 (8 ビット) にする。既定は f16 (16 ビット) |
-ctv q8_0 |
KV キャッシュの V の型を q8_0 (8 ビット) にする。既定は f16 (16 ビット) |
--reasoning off |
思考 (thinking) を使わない |
この記事の llama.cpp の画像と品質の計測は --reasoning off で、速さの計測はチャットのテンプレートを通さない /completion で測った。Gemma 4 のモデルカードは、思考はシステムプロンプトの先頭に <|think|> のトークンを入れると使われ、外すと使われないと書いている。品質と画像の試験は思考を切って測り、Ollama の速さも思考なし (think false) で測った。llama.cpp の速さは、テンプレートを通さずに文章の続きを生成させる /completion で測った。モデルカードが勧めるサンプリングは temperature 1.0・top_p 0.95・top_k 64 で、llama.cpp の速さの計測もこの値で測った (Ollama の速さの計測は temperature 0.7、品質の課題は答えを固定するため temperature 0 で解かせた)。
全層GPUのままあふれなかった文脈長
ファイル・GPU・KV の型の組ごとに、あふれずに長い入力まで読めた最大の文脈長を「全層 GPU のままあふれなかった文脈長の表」に載せた。llama.cpp b12015 (CUDA 13)、-ngl 99、-fa on で、測った文脈長の段は 1 枚が 8K・32K・64K・128K・256K、2 枚が 8K・64K・128K・256K。あふれたかどうかは速さの落ち込みで判定した (判定の条件は「測定の条件」の節に書いた)。各行の値は、あふれずに測れた最大の文脈長で、その次の段は、あふれたか、手前の段であふれたので起動しなかった段になる。
| ファイル | GPU | KV f16 | KV q8_0 |
|---|---|---|---|
| 公式 Q4_0 | RTX 5080 | 8K | 32K |
| 公式 Q4_0 | RTX 5060 Ti | 32K | 64K |
| unsloth UD-Q4_K_XL (QAT) | RTX 5080 | 8K | 64K |
| unsloth UD-Q4_K_XL (QAT) | RTX 5060 Ti | 32K | 64K |
| unsloth UD-IQ4_XS (QATでない) | RTX 5080 | 32K | 64K |
| unsloth UD-IQ4_XS (QATでない) | RTX 5060 Ti | 64K | 128K |
| 公式 Q4_0 | RTX 5080 + RTX 5060 Ti | 256K | 256K |
この記事の Windows 環境では、GPU からあふれた条件でも、llama-server はエラーで止まらずに動き続け、速さだけが大きく落ちた。たとえば RTX 5080 の公式 Q4_0・KV f16 は、8K の短い回の生成が 129 tok/s だったのに対し、32K では 41 tok/s だった。あふれた先が共有メモリ (メインメモリ) かどうかは直接は測っておらず、GPU 全体の使用量が容量の手前で頭打ちになったことと、速さの落ち方からの判断になる。
ここでいう「GPU 全体の使用量」は nvidia-smi で読んだ GPU 全体の値で、モデルが必要とする VRAM ではない。RTX 5080 は画面の表示も担っていて、1 枚の計測ではモデルを読み込む前から GPU 全体で 346〜1,304MiB (計測ごとに変わった) を使っていた。表示に使っていない RTX 5060 Ti は 0MiB だった。RTX 5060 Ti のほうが、同じファイル・KV の型で 1 段長い文脈まであふれずに測れることが多く、表示の使用量が影響した可能性がある。
全層 GPU のままあふれなかった文脈長の表では、どの組も KV q8_0 の列が f16 の列と同じか長い。ただし、q8_0 にしたときの答えの質は測っていない。KV キャッシュを量子化して文脈長を伸ばす話は、VRAM 16GB でコンテキスト長をどこまで伸ばせるかを測った記事で詳しく扱っている。RTX 5080 の KV q8_0 で 64K まで全層 GPU のままあふれなかったのは、unsloth の 2 つのファイルで、公式 Q4_0 は 32K までだった。
全層GPUのままあふれていないときの速さ
あふれずに長い入力まで読めた段だけを、「llama.cpp の速さの表」に載せた。1 枚、-ngl 99、KV q8_0、/completion (テンプレートなし)、temperature 1.0・top_k 64・top_p 0.95 で、各 3 回の中央値。短い回は約 50〜60 トークンのプロンプトを渡した。長い回は、文脈長から生成と余白の 384 トークンを引いた長さに合わせて英単語の列を入れ、実際の入力は 64K の段で 65,152 トークンだった。llama-server の応答で、入力の切り詰めが無かったことも確かめた。どちらの回も、そのあとに最大 128 トークンを生成させた (数トークンで生成が止まった回を含む)。RTX 5060 Ti は、短い回の 3 回のうち 1 回だけ 75〜80 tok/s 前後に落ちる回が混じることがあり、表は 3 回の中央値で示している。
| ファイル | GPU | 文脈長 | 短い回の生成 | 長い入力の読み込み | 長い入力のあとの生成 |
|---|---|---|---|---|---|
| 公式 Q4_0 | RTX 5080 | 8K | 153 tok/s | 6,599 tok/s | 138 tok/s |
| 公式 Q4_0 | RTX 5080 | 32K | 153 tok/s | 5,677 tok/s | 104 tok/s |
| unsloth UD-Q4_K_XL (QAT) | RTX 5080 | 8K | 162 tok/s | 6,460 tok/s | 146 tok/s |
| unsloth UD-Q4_K_XL (QAT) | RTX 5080 | 32K | 160 tok/s | 5,587 tok/s | 115 tok/s |
| unsloth UD-Q4_K_XL (QAT) | RTX 5080 | 64K | 145 tok/s | 4,505 tok/s | 81 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5080 | 8K | 131 tok/s | 6,630 tok/s | 126 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5080 | 32K | 107 tok/s | 5,613 tok/s | 101 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5080 | 64K | 132 tok/s | 4,556 tok/s | 80 tok/s |
| 公式 Q4_0 | RTX 5060 Ti | 8K | 110 tok/s | 3,325 tok/s | 94 tok/s |
| 公式 Q4_0 | RTX 5060 Ti | 32K | 111 tok/s | 2,798 tok/s | 71 tok/s |
| 公式 Q4_0 | RTX 5060 Ti | 64K | 107 tok/s | 2,261 tok/s | 52 tok/s |
| unsloth UD-Q4_K_XL (QAT) | RTX 5060 Ti | 8K | 113 tok/s | 3,331 tok/s | 94 tok/s |
| unsloth UD-Q4_K_XL (QAT) | RTX 5060 Ti | 32K | 116 tok/s | 2,797 tok/s | 71 tok/s |
| unsloth UD-Q4_K_XL (QAT) | RTX 5060 Ti | 64K | 117 tok/s | 2,259 tok/s | 53 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5060 Ti | 8K | 89 tok/s | 3,301 tok/s | 77 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5060 Ti | 32K | 89 tok/s | 2,742 tok/s | 61 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5060 Ti | 64K | 89 tok/s | 2,225 tok/s | 48 tok/s |
| unsloth UD-IQ4_XS (QATでない) | RTX 5060 Ti | 128K | 88 tok/s | 1,614 tok/s | 33 tok/s |
llama.cpp の速さの表では、どちらの GPU でも QAT の 2 ファイルが QAT でない UD-IQ4_XS より短い回の生成が速かった。短い回の生成は文脈長が伸びてもあまり変わらない一方、長い入力のあとの生成は文脈が長いほど下がった。ただし 3 つのファイルは、もとにした重みが QAT かどうかだけでなく、量子化の形式 (Q4_0・UD-Q4_K_XL・UD-IQ4_XS) と大きさも違うので、速さや ppl の差を QAT の有無だけの差とは言えない。RTX 5080 の UD-IQ4_XS は 32K の短い回だけが 107 tok/s と前後の段より低く、理由は確かめていない。
RTX 5080 1 枚の llama.cpp は、短い回の生成が Ollama の qat タグより速かった (公式 Q4_0・KV q8_0・8K で 153 tok/s)。ただし、この差はエンジンそのものの速さの差とは読めない。Ollama は一部が CPU 側に載った状態で、さらにプロンプトの渡し方 (llama.cpp はテンプレートを通さない /completion、Ollama はテンプレートを通す /api/generate) と生成の長さ (Ollama は 512 トークン、llama.cpp は 128 トークン) も llama.cpp と違う。
2枚構成なら256Kまで全層GPUのままあふれなかった
RTX 5080 と RTX 5060 Ti の 2 枚に公式 Q4_0 を分けて載せると、KV キャッシュが f16 でも q8_0 でも 256K まで GPU からあふれず、256K でも GPU 全体の使用量は 1 枚あたり多くて 12,206MiB だった。長い入力のあとの生成は 64K 以上の段で f16 のほうが速く (256K では f16 が 49 tok/s、q8_0 が 27 tok/s)、8K は f16 が 103 tok/s、q8_0 が 107 tok/s でほぼ同じだった。
llama.cpp b12015 (CUDA 13)、-ngl 99、層を 2 枚に分ける既定の分け方で、8K・64K・128K・256K を測った。短い回・長い回の中身は 1 枚の計測と同じで、各 3 回の中央値を「2 枚構成の実測表」に載せた。GPU 全体の使用量は読み込み後の値で、RTX 5080 / RTX 5060 Ti の順に並べている。
| KVの型 | 文脈長 | 短い回の生成 | 長い入力の読み込み | 長い入力のあとの生成 | GPU全体の使用量 |
|---|---|---|---|---|---|
| f16 | 8K | 131 tok/s | 6,695 tok/s | 103 tok/s | 9,224MiB / 7,566MiB |
| f16 | 64K | 132 tok/s | 4,584 tok/s | 81 tok/s | 9,907MiB / 8,462MiB |
| f16 | 128K | 123 tok/s | 3,141 tok/s | 68 tok/s | 10,689MiB / 9,486MiB |
| f16 | 256K | 130 tok/s | 1,915 tok/s | 49 tok/s | 12,206MiB / 11,534MiB |
| q8_0 | 8K | 121 tok/s | 6,662 tok/s | 107 tok/s | 9,055MiB / 7,346MiB |
| q8_0 | 64K | 120 tok/s | 4,460 tok/s | 62 tok/s | 9,690MiB / 8,100MiB |
| q8_0 | 128K | 120 tok/s | 3,043 tok/s | 43 tok/s | 10,496MiB / 9,020MiB |
| q8_0 | 256K | 122 tok/s | 1,854 tok/s | 27 tok/s | 12,034MiB / 10,860MiB |
2 枚構成の実測表の短い回の生成は、どの段も RTX 5080 1 枚の KV q8_0 (153 tok/s) より遅かった。2 枚にする利点は短い回の生成の速さではなく、全層 GPU のまま長い文脈まであふれずに使えることにある。2 枚では KV キャッシュが f16 でも、このモデルの学習時の文脈長の上限の 256K まであふれなかったので、q8_0 にして文脈長を伸ばす余地はなかった。q8_0 にすると GPU 全体の使用量はどの段も f16 より小さかったが、長い入力のあとの生成は 64K・128K・256K の段で f16 のほうが速く、8K はほぼ同じだった。
16GB のカードを 2 枚使って 32GB にしたとき、ほかのモデルで何が変わるかはVRAM 32GB の 2 枚構成の実測にまとめている。
MTPで生成は速くなるか
MTP の下書きモデルを足すと、RTX 5080 1 枚では短い回の生成が速くなったが、長い入力のあとの生成は速くなったとは言えなかった。2 枚構成では、--spec-draft-device の指定 (なし・CUDA0・CUDA1) で、短い回の生成はほぼ変わらない・起動しない・速くなる、と分かれた。長い入力のあとの生成は、指定なしでは MTP なしより大きく遅くなり、CUDA1 でも 64K では MTP なしを下回った。
下書きモデルの仕組みと付け方
unsloth のモデルカードでは、MTP (Multi-Token Prediction) の下書きモデルは本体の KV キャッシュを共有して先の数トークンを下書きし、本体が下書きのトークンを全部確かめるので、出力は変わらないとしている。一方、unsloth のサイトの MTP の解説は、本体が確かめたトークンだけを残すので品質を保つ、という書き方をしている。この記事では、MTP の有無で出力が同じかは確かめていない。llama.cpp には 2026年6月7日に取り込まれた。
下書きモデルは unsloth の QAT のリポジトリの MTP フォルダにある mtp-gemma-4-26B-A4B-it-Q4_0.gguf (251,939,328 バイト、約 240MiB) を使った。RTX 5080 1 枚で公式 Q4_0 に足すときのコマンドは次のとおりで、前半は「llama.cpp の起動コマンドの表」と同じ指定になる。
llama-server -m gemma-4-26B_q4_0-it.gguf -ngl 99 -c 32768 -fa on -ctk q8_0 -ctv q8_0 --spec-draft-model mtp-gemma-4-26B-A4B-it-Q4_0.gguf --spec-type draft-mtp2 枚構成で下書きを RTX 5060 Ti に置いて 64K (KV f16) で動かすときは、次のようにした。
llama-server -m gemma-4-26B_q4_0-it.gguf -ngl 99 -c 65536 -fa on --spec-draft-model mtp-gemma-4-26B-A4B-it-Q4_0.gguf --spec-type draft-mtp --spec-draft-device CUDA1MTP のために足した指定の意味は「MTP の指定の表」のとおり。
| 指定 | 意味 |
|---|---|
--spec-draft-model mtp-gemma-4-26B-A4B-it-Q4_0.gguf |
下書きモデルのファイル |
--spec-type draft-mtp |
下書きの方式を MTP にする |
--spec-draft-device CUDA1 |
下書きモデルを置く GPU。CUDA1 はこの環境で 2 枚目 (本体の後半の層が載る側、RTX 5060 Ti) の番号。番号は llama-server の起動ログの GPU 一覧で確かめる |
1 回に下書きするトークン数の上限は --spec-draft-n-max で決まり、既定は 3、unsloth の例は 4 を指定している。この記事は既定の 3 で測り、RTX 5080 1 枚の 8K だけ 4 でも測った。unsloth の MTP の説明は、複数の GPU で使うときは --spec-draft-device CUDA0 -sm layer を足すよう書いている。-sm layer は層を GPU ごとに分ける分け方で、llama.cpp の既定になっている。
MTPの実測
公式 Q4_0 に unsloth の MTP の下書きモデルを足し、--spec-type draft-mtp、--spec-draft-n-max は既定の 3 (「下書き 4 本」の行だけ 4) で測った結果を、各 3 回の中央値で「MTP の実測表」に載せた。MTP なしの値は、1 枚・2 枚の速さの表と同じ計測。下書きの採用は、短い回の 3 回の、採用されたトークン数 ÷ 下書きしたトークン数の幅。長い入力のあとの生成は、途中で生成を止めた回を含み、出した長さがそろっていない。2 枚構成の「置き場所の指定なし」は --spec-draft-device を付けない回、「下書きを RTX 5060 Ti に置く」は --spec-draft-device CUDA1 の回で、--spec-draft-device CUDA0 (RTX 5080) は起動の途中で止まり、測れなかった。
| 構成 | 文脈長 | MTP | 短い回の生成 | 長い入力のあとの生成 | 下書きの採用 |
|---|---|---|---|---|---|
| RTX 5080 1 枚・KV q8_0 | 8K | なし | 153 tok/s | 138 tok/s | — |
| RTX 5080 1 枚・KV q8_0 | 8K | あり | 223 tok/s | 145 tok/s | 52〜61% |
| RTX 5080 1 枚・KV q8_0 | 8K | あり (下書き 4 本) | 197 tok/s | 72 tok/s | 40〜43% |
| RTX 5080 1 枚・KV q8_0 | 32K | なし | 153 tok/s | 104 tok/s | — |
| RTX 5080 1 枚・KV q8_0 | 32K | あり | 210 tok/s | 62 tok/s | 52〜61% |
| 2 枚・KV f16 | 8K | なし | 131 tok/s | 103 tok/s | — |
| 2 枚・KV f16 | 8K | あり (置き場所の指定なし) | 134 tok/s | 30 tok/s | 50〜56% |
| 2 枚・KV f16 | 8K | あり (下書きを RTX 5060 Ti に置く) | 179 tok/s | 108 tok/s | 50〜56% |
| 2 枚・KV f16 | 64K | なし | 132 tok/s | 81 tok/s | — |
| 2 枚・KV f16 | 64K | あり (置き場所の指定なし) | 131 tok/s | 22 tok/s | 50〜56% |
| 2 枚・KV f16 | 64K | あり (下書きを RTX 5060 Ti に置く) | 173 tok/s | 72 tok/s | 50〜56% |
RTX 5080 1枚: 短い回は速くなり、長い入力のあとは速くなったとは言えなかった
RTX 5080 1 枚 (KV q8_0) では、MTP を足すと短い回の生成が 8K で 153 tok/s から 223 tok/s、32K で 153 tok/s から 210 tok/s に上がった。下書きのトークンが採用された割合は、短い回で 52〜61%。MTP を足すと、読み込み後の GPU 全体の使用量は 8K で 15,244MiB から 15,764MiB に増えた。
1 回に下書きする本数を 4 にすると、8K の短い回は 197 tok/s で、3 本 (223 tok/s) より遅かった。採用された割合も 40〜43% に下がった。
長い入力のあとの生成では、MTP で速くなったとは言えなかった。RTX 5080 の 32K では MTP ありが 62 tok/s だった一方、MTP なしは 104 tok/s だった。ただし MTP なしの 3 回は 13〜22 トークンで生成が止まっていて、出した長さがそろっていない。
2枚構成: --spec-draft-device の指定で結果が分かれた
2 枚構成 (KV f16) では、下書きモデルを置く GPU を指定しないと、MTP を足しても短い回の生成は 8K で 131 tok/s から 134 tok/s とほぼ変わらず、長い入力のあとの生成は 103 tok/s から 30 tok/s に落ちた。指定しなかったときに下書きモデルがどの GPU に置かれたかは確かめていない。
この環境は CUDA_VISIBLE_DEVICES=0,1 で、起動ログの表示では CUDA0 が RTX 5080、CUDA1 が RTX 5060 Ti。配布元の例どおり --spec-draft-device CUDA0 (RTX 5080) を付けると、llama-server は起動の途中で止まった。ログには、本体の 28 層目の KV キャッシュ (cache_k_l28) が CUDA1 にあってその処理を実行できない、という趣旨のエラーが出た。このエラーと、下書きモデルは本体の KV キャッシュを共有するという配布元の説明から、下書きを置いた GPU と本体の KV キャッシュの置き場所が分かれたことで止まったと考えられる。llama.cpp のコードは読んでおらず、ほかのビルドや 3 枚以上の構成では確かめていない。
下書きを CUDA1 (RTX 5060 Ti) に置くと起動し、短い回の生成は 8K で 179 tok/s、64K で 173 tok/s に上がった。2 枚構成の MTP は、llama.cpp b12015・層を 2 枚に分ける既定の分け方のこの環境では、置き場所の指定で、短い回の生成は速くなる・ほぼ変わらない・起動しないに分かれた。MTP を足すと、長い入力の読み込みが遅くなる段もあった (64K で 4,584 から 3,895 tok/s)。
MTP をほかのモデルで測った結果は、MTP（マルチトークン予測）を RTX 5080 で測った記事にある。
画像を読ませる: RTX 5080 1枚は前処理が遅かった
mmproj を足すと、RTX 5080 1 枚・KV f16 ではテキストだけの質問の生成まで 45 tok/s に落ちた。KV q8_0 にするとテキストの生成は 159 tok/s に戻ったが、画像つきの質問の前処理 (画像を含むプロンプト全体を処理した時間で、画像のエンコードだけの時間ではない) には 3.5〜3.7 秒かかった。RTX 5060 Ti の KV q8_0 は 0.73〜0.74 秒、2 枚構成は 0.24〜0.28 秒だった。RTX 5080 で前処理が遅い理由は確かめていない。
mmprojの足し方
llama-server で画像を読ませるには、--mmproj で mmproj のファイル (gemma-4-26B-it-mmproj.gguf、1.11GiB) を渡す。mmproj は既定で GPU に置かれ、--no-mmproj-offload で GPU に置かないようにできる (この記事では --no-mmproj-offload では測っていない)。画像の計測と同じ 8K・KV q8_0 で動かすときのコマンドは次のとおりで、-c 8192 は 8K を表す。ほかの指定は「llama.cpp の起動コマンドの表」と同じ。
llama-server -m gemma-4-26B_q4_0-it.gguf -ngl 99 -c 8192 -fa on -ctk q8_0 -ctv q8_0 --mmproj gemma-4-26B-it-mmproj.gguf --reasoning off| 指定 | 意味 |
|---|---|
--mmproj gemma-4-26B-it-mmproj.gguf |
画像を読むための mmproj のファイルを渡す |
棒グラフ1枚を読ませた結果
チーム別の月間注文数の棒グラフ (5 本の棒に 42・87・63・29・71 の数字) を 1 枚だけ使い、画像の説明・一番目立つもの・文字の読み取り (「文字が写っていれば読み取って」) という違う 3 つの質問を 1 回ずつ送った。llama.cpp b12015 (CUDA 13)、公式 Q4_0 + mmproj、文脈長 8K、--reasoning off、チャット (/v1/chat/completions) で測り、「画像の実測表」に載せた。画像は 960×600 ピクセルの PNG を使い、生成の設定は temperature 1.0・top_k 64・top_p 0.95、seed は質問ごとに固定した。cache_prompt は false にして、質問のたびに新しい会話として送った。3 つの質問とは別に最初の 1 回 (ウォームアップ) を送り、集計から外した。llama-server の応答にある cache_n (前の要求の KV キャッシュから再利用された分) は、どの回も 0 だった。テキストだけの生成は日本語の 2 文の説明を求める質問 3 つの生成の中央値、画像つきの質問の前処理は画像を含む約 290 トークンのプロンプトの処理にかかった秒数 (llama-server が返した prompt_ms) で、表の幅はその 3 つの質問の値の幅。棒グラフの 5 本の値は、構成ごとに、文字の読み取りを頼んだ質問への回答 1 件で確かめた。GPU 全体の使用量は読み込み後の値。
| GPU | KVの型 | テキストだけの生成 | 画像つきの質問の前処理 | GPU全体の使用量 | 棒グラフの5本の値 |
|---|---|---|---|---|---|
| RTX 5080 | f16 | 45 tok/s | 4.2〜4.4秒 | 15,818MiB | 正しく読んだ |
| RTX 5080 | q8_0 | 159 tok/s | 3.5〜3.7秒 | 15,726MiB | 正しく読んだ |
| RTX 5060 Ti | f16 | 110 tok/s | 9.8〜9.9秒 | 16,024MiB | 正しく読んだ |
| RTX 5060 Ti | q8_0 | 112 tok/s | 0.73〜0.74秒 | 15,916MiB | 4本目まで読んで上限で切れた |
| RTX 5080 + RTX 5060 Ti | f16 | 126 tok/s | 0.24〜0.28秒 | 10,225MiB / 7,566MiB | 正しく読んだ |
値の読み取りは、RTX 5060 Ti・KV q8_0 以外の 4 構成では 5 本すべて正しかった。RTX 5060 Ti・KV q8_0 は生成の上限の 128 トークンに当たり、正しい 4 本の値を出したところで終わった。画像は棒グラフ 1 枚だけで、ほかの種類の画像では測っていない。
画像の実測表から読めるのは、1 枚構成では KV の型によって前処理やテキストの生成が大きく遅くなる組があり、遅くならなかったのは RTX 5060 Ti の KV q8_0 と 2 枚構成だったこと。
公式Q4_0・unslothのQAT・IQ4_XSのどれを使うか
3 つの課題では、JSON と計算はすべての組で 3 回とも正解し、要約の合否は 80 字の上限の境目で分かれただけだった。ppl では QAT の 2 ファイルが近く、QAT でない UD-IQ4_XS は大きく悪かったが、このファイルだけ読み込み時にトークンの型の警告が出ていて、この値は参考の値として扱う。
出した3つの課題
課題は次の 3 つで、どれも日本語で出した。
- ノート PC の製品名・重さ・発売日・税込価格が入った 1 文から、4 項目を JSON で抜き出す。正解は「ミライブック Air 14」「1.18」「2025-09-12」「189800」。
- 1 個 280 円のパン 12 個と 1 本 150 円の牛乳 8 本を買い、会員割引で 1 割引きになったところへ 5,000 円を払ったときのおつりを計算する。正解は 896 円。
- ローカル LLM と VRAM・量子化・MoE についての 7 文ほどの文章を、「VRAM」と「量子化」の 2 語を含めて 80 字以内に要約する。
RTX 5080、文脈長 8K、temperature 0・seed 42、思考なしで各課題を 3 回ずつ解かせた。Ollama の q4_K_M タグの要約だけは 1 回目と 2・3 回目の文面が違い、字数は 80・79・79 字だった。ほかの組と課題では 3 回の出力が同じだった。llama.cpp は KV f16・--reasoning off、Ollama は 0.40.13・think false。JSON は、コードフェンスを外して取り出した 4 項目と型を見て採点し、要約は、前置きを含む出力の字数 (前後の空白は除く) と、指定の 2 語が入っているかで採点した。内容の良し悪しは採点していない。結果は「課題の結果の表」にまとめた。
| エンジン | ファイル・タグ | JSONの抜き出し | おつりの計算 | 80字以内の要約 |
|---|---|---|---|---|
| llama.cpp | 公式 Q4_0 | 3/3 | 3/3 | 3/3 (80字) |
| llama.cpp | unsloth UD-Q4_K_XL (QAT) | 3/3 | 3/3 | 3/3 (79字) |
| llama.cpp | unsloth UD-IQ4_XS (QATでない) | 3/3 | 3/3 | 0/3 (81字) |
| Ollama | gemma4:26b-a4b-it-qat | 3/3 | 3/3 | 0/3 (82字) |
| Ollama | gemma4:26b-a4b-it-q4_K_M | 3/3 | 3/3 | 3/3 (80・79・79字) |
| Ollama | gemma4:26b (MTP入り) | 3/3 | 3/3 | 0/3 (82字) |
要約はどの組も 79〜82 字に収まり、80 字を 1〜2 字超えた組が不合格になっただけで、この結果からモデルの差は言えない。課題は 3 つだけで、日本語の一般的な能力を測ったものではない。
同じ日本語の文章でのppl
ppl (perplexity) は、モデルが文章の次のトークンをどれだけうまく当てられるかを表す値で、小さいほうがよい。llama.cpp の説明では、モデルどうし (特にトークナイザーが違うもの) では直接比べられず、微調整したモデルは出力の質が上がっても ppl が高く出やすい。この記事の値も、チャット向けに調整したモデルに、テンプレートを通さない素の文章を読ませた値で、値そのものが高い。llama.cpp の 3 つのファイルに、同じ日本語の文章 (約 13 万 4 千字) を読ませて ppl を測り、「ppl の表」に載せた。llama-perplexity (llama.cpp b12015)、RTX 5080、文脈 2,048、37 チャンクで、各ファイル 1 回ずつ実行した値を載せた。± は llama-perplexity が出した推定の幅で、繰り返し測った最小と最大の幅でも、信頼区間でもない。文脈 2,048 の評価なので、長い文脈での品質は分からない。
| ファイル | ppl |
|---|---|
| 公式 Q4_0 | 361.07 (±9.41) |
| unsloth UD-Q4_K_XL (QAT) | 331.32 (±8.64) |
| unsloth UD-IQ4_XS (QATでない) | 2,137.27 (±74.53) |
QAT の 2 ファイルは近く、QAT でない UD-IQ4_XS は 2,137.27 と大きく悪かった。ただし UD-IQ4_XS のファイルは、読み込み時に llama.cpp がトークンの型の警告を出して型を上書きしていて (公式 Q4_0 では警告は出なかった)、ppl が大きく悪かった理由が量子化とトークナイザーの設定のどちらにあるのかは切り分けていないので、UD-IQ4_XS の ppl は参考の値として扱う。同じ文章どうしでしか比べられず、ほかの記事やほかのモデルの ppl とは比べられない。
ppl で大きく悪かった UD-IQ4_XS も、3 つの課題の結果はほかとほとんど変わらなかった。ppl の差がどの程度の答えの差になるかは、この記事の課題では分からない。速さについては、llama.cpp の速さの表で QAT の 2 ファイルと UD-IQ4_XS を同じ GPU どうしで見比べられる。
QAT の 2 ファイルは、3 つの課題 (JSON・計算・要約の形式) では同じように解け、ppl は公式 Q4_0 が 361.07、unsloth UD-Q4_K_XL (QAT) が 331.32 だった。答えの質が同じかは評価していないので、この記事で比べられたのは速さとあふれずに測れた文脈長で、品質は用途ごとに確かめる必要がある。RTX 5080 の KV q8_0 で全層 GPU のままあふれなかった文脈長は unsloth UD-Q4_K_XL (QAT) が 64K、公式 Q4_0 が 32K だったが、RTX 5080 はモデルを読み込む前の GPU 全体の使用量が計測ごとに変わり、その幅が 2 ファイルの大きさの差より大きいので、ファイルの違いとは言い切れない。RTX 5060 Ti ではどちらも 64K だった。QAT でない UD-IQ4_XS は ppl が大きく悪かったが、このファイルだけトークンの型の警告が出ていて、この値は参考の値として扱う。
どちらを使うか: 文脈の長さと使い方で決める
ここまでの結果を、使い方ごとに「使い方ごとの選び方の表」にまとめた。
| 使い方 | 使うもの | 本文で分かったこと |
|---|---|---|
| 手軽に始めて、256K までの長い文脈も使う | Ollama の gemma4:26b-a4b-it-qat (文脈長を指定して使う。RTX 5080・メインメモリ 96GiB の機械で測定) | どの文脈長でも動いたが、一部が CPU 側に回り、文脈が長いほど遅くなった。RTX 5080 1 枚で 64K を超える文脈の長い入力まで測れたのは Ollama だけ (llama.cpp は全部の層を GPU に置く構成だけを測った) |
| 64K までを速く使う | llama.cpp を KV q8_0 で。RTX 5080 では unsloth UD-Q4_K_XL (QAT) のほうが長い文脈まであふれなかった (RTX 5080 が画面の表示も担っていることの影響は切り分けていない)。RTX 5060 Ti なら公式 Q4_0 か unsloth UD-Q4_K_XL (QAT) | RTX 5080 で 64K まで全層 GPU のままあふれなかったのは unsloth UD-Q4_K_XL (QAT) で、公式 Q4_0 は 32K まで。ただし RTX 5080 はモデルを読み込む前の GPU 全体の使用量が計測ごとに変わり、その幅が 2 ファイルの大きさの差より大きいので、ファイルの違いとは言い切れない。RTX 5060 Ti ではどちらも 64K まで。答えの質 (3 つの課題) は文脈 8K・KV f16・MTP なしで測った (64K や q8_0・MTP ありでは測っていない) |
| RTX 5080 1 枚で短い回の生成をさらに速く | MTP の下書きモデルを足す (下書きの本数は既定の 3) | RTX 5080 1 枚・KV q8_0 の 8K と 32K で測った。短い回の生成は上がったが、長い入力のあとの生成は速くなったとは言えなかった。答えの質 (3 つの課題) は文脈 8K・KV f16・MTP なしで測った (q8_0・MTP ありでは測っていない) |
| 256K まで全層 GPU のまま扱う | RTX 5080 と RTX 5060 Ti の 2 枚構成 (公式 Q4_0・KV f16 で測定) | 短い回の生成は RTX 5080 1 枚・KV q8_0 より遅い。MTP を足すなら下書きを RTX 5060 Ti (この環境で CUDA1) に置く (8K と 64K で測り、短い回の生成が上がった) |
| 画像を読ませる | 前処理の速さなら RTX 5060 Ti の KV q8_0 か 2 枚構成 (棒グラフ 1 枚の試験では、RTX 5060 Ti の KV q8_0 は生成の上限で 4 本目の値を出したところで回答が終わった) | RTX 5080 1 枚は前処理が遅く、KV f16 ではテキストの生成まで遅くなった (理由は確かめていない)。RTX 5060 Ti でも KV f16 は前処理に 9.8〜9.9 秒かかった |
ファイルは、QAT の 2 ファイル (公式 Q4_0 と unsloth UD-Q4_K_XL (QAT)) が 3 つの課題を同じように解けたが、答えの質が同じかは評価していない。この記事で比べられたのは速さとあふれずに測れた文脈長で、品質は用途ごとに確かめる必要がある。RTX 5080 の KV q8_0 で全層 GPU のままあふれなかった文脈長は、unsloth UD-Q4_K_XL (QAT) が 64K、公式 Q4_0 が 32K と違ったが、RTX 5080 はモデルを読み込む前の GPU 全体の使用量が計測ごとに変わり、その幅が 2 ファイルの大きさの差より大きいので、ファイルの違いとは言い切れない。RTX 5060 Ti ではどちらも 64K だった。QAT でない UD-IQ4_XS の ppl は大きく悪かったが、トークンの型の警告が出たファイルなので、この値は参考の値として扱う。
測定の条件
測定機と、使ったソフトのバージョンは「測定機の表」のとおり。
| 項目 | 内容 |
|---|---|
| CPU | Core i7-14700F |
| メインメモリ | 96GiB |
| OS | Windows 11 (ビルド 26200) |
| GPU | RTX 5080 (画面の表示も担う)、RTX 5060 Ti (OCuLink で外付け) |
| ドライバー | 610.88 |
| llama.cpp | b12015 の Windows x64 向け (CUDA 13) のビルド |
| Ollama | 0.40.13 |
| モデルのファイル | google/gemma-4-26B-A4B-it-qat-q4_0-gguf (revision d1c082b)、unsloth/gemma-4-26B-A4B-it-qat-GGUF (revision 7b92b5b)、unsloth/gemma-4-26B-A4B-it-GGUF (revision c099eb4) |
本記事の実測値は2026年10月31日に、上記の測定機・設定で計測したもの。配布元のページとドキュメントの記載も同じ日に確認した。llama.cpp は b12015 で測り、後のビルドでは確かめていない。
速さは 2 種類の入力で測った。短い回は約 50〜60 トークンのプロンプトに続けて生成させた。長い回は、一般語と技術語の英単語の一覧から擬似乱数で作った単語の列を入れてから生成させた (自然な日本語の文書・会話・コードの長い入力は測っていない)。列の長さは、llama.cpp では文脈長から生成と余白の 384 トークンを引いた長さにほぼ合わせ、実際の入力は 256K なら 261,754〜261,761 トークンだった。Ollama は文脈長の約 75% にした。表の値は、短い回は違う 3 つのプロンプト、長い回は違う 3 本の単語の列を 1 回ずつ送った 3 回の中央値で、同じ入力の繰り返しではない。短い回の 3 つのプロンプトは、構成が違っても同じ文を使った (Ollama はチャットのテンプレートを通し、llama.cpp は通していない)。長い回の 3 本の単語の列は、llama.cpp では文脈長が同じなら構成が違っても同じ列を使い、Ollama ではタグごとに別の列を作って、揃えたのは文字数だけにした。生成の seed は回ごとに固定した (短い回は 42・43・44、長い回は 1042・1043・1044)。llama.cpp はチャットのテンプレートを通さない /completion に cache_prompt を false で送り、構成ごとに最初の 1 回 (ウォームアップ) は集計から外した。構成を切り替えるたびに llama-server を起動し直し、Ollama は読み込み済みのモデルを keep_alive 0 で外し、何も読み込まれていないことを確かめてから次の構成を測った。生成は最大 128 トークンで、数トークンで止まった回もあるので、短い回の速さの小さな差は参考の値として扱う。Ollama は /api/generate に think を false・temperature 0.7 で送り、生成は 512 トークン (品質の課題だけは /api/chat・temperature 0)。Ollama の KV キャッシュの型と Flash Attention は指定せず既定のままで、実際にどの設定で動いたかは確かめていない。tok/s は、llama.cpp は llama-server が返す生成の速さ、Ollama は eval_count ÷ (eval_duration ÷ 10億) で計算した (eval_duration は API が返すナノ秒の値)。
1 枚の計測は、CUDA_DEVICE_ORDER=PCI_BUS_ID と CUDA_VISIBLE_DEVICES で見える GPU を 1 枚にして測った (RTX 5080 は 0、RTX 5060 Ti は 1。Ollama は 0)。2 枚の GPU が入った機械で同じコマンドを打つと、llama.cpp は既定で 2 枚に分けて載せる。Ollama の値はモデルの一部を CPU 側に載せた状態のものなので、CPU とメインメモリにも左右される。
あふれの判定は 3 つの条件で見た。1 つ目に、短い回の生成が、同じファイル・KV の型で最初に起動できた文脈長の半分を下回ったら、その組の長い回は回さない。2 つ目に、長い回の読み込みが 8,000 トークンを過ぎても通算で 600 tok/s を下回ったら、その回を止める。これは測定の途中から足した打ち切りの条件で、その前に回した RTX 5060 Ti の 128K・KV q8_0 (公式 Q4_0) は手で止めた。3 つ目に、長い入力の読み込みの速さ (3 回の中央値) が、同じファイル・KV の型で 1 つ手前の段の半分を下回った組も、あふれたとした。この条件は、計測を終えたあとに結果を見て決めたもので、当てはまったのは RTX 5080 の 3 組 (公式 Q4_0・KV q8_0 の 64K が 0.32 倍、unsloth UD-Q4_K_XL (QAT)・KV f16 の 32K が 0.20 倍、unsloth UD-IQ4_XS・KV q8_0 の 128K が 0.05 倍) だった。あふれなかったとした段は、どれも 1 つ手前の段の 0.61 倍以上だった。この判定は速さの落ち込みで見ているので、速さが落ちない程度の小さなはみ出しは拾えない。
単位は、それぞれの表示のまま書いている。ファイルの大きさは測ったバイト数で、1GiB = 1,073,741,824 バイトで GiB に直した。配布ページの表示の 14.4 GB・1.19 GB や、Ollama の表示の GB は 10 進の GB。GPU の容量と使用量は nvidia-smi の MiB の表示で、1GiB = 1,024MiB。
測定機の構成の詳しい内容は検証環境のページに、ほかの GPU やモデルの実測はAIハードウェア実測データベースにまとめている。
測っていないこと
この記事で測っていないことをまとめる。
- bfloat16 の重みとの品質の比較
- KV q8_0 にしたときと MTP を足したときの答えの質
- 3 つの課題と 1 つの文章の ppl のほかの品質
- 思考を使ったときの速さと答え
- Ollama で KV キャッシュの型や Flash Attention の指定を変えた構成
- Ollama の qat タグの RTX 5060 Ti での速さ
- Ollama で gemma4:26b の下書きモデルを外したときの速さ
- llama.cpp で層やエキスパートの一部を意図して CPU 側に置いた構成
--spec-draft-n-maxを 3・4 以外にした MTP と、2 枚構成の KV q8_0 での MTP- 1 枚で MTP を足した 64K 以上
- unsloth のファイルでの画像と
--no-mmproj-offload - 棒グラフ 1 枚のほかの画像
- LM Studio と vLLM、Linux
- VRAM 12GB 以下の GPU と、NVIDIA 以外の GPU
- 同時に複数のリクエストを処理したときの速さ
- 電力
参考資料
- google/gemma-4-26B-A4B-it-qat-q4_0-gguf (Hugging Face)
- Gemma 4 の QAT の発表 (Google ブログ、2026年6月5日)
- unsloth/gemma-4-26B-A4B-it-qat-GGUF (Hugging Face)
- unsloth/gemma-4-26B-A4B-it-qat-GGUF の MTP/README.md (Hugging Face)
- unsloth/gemma-4-26B-A4B-it-GGUF (Hugging Face)
- Ollama gemma4 のタグ一覧
- Ollama ドキュメント Context length (v0.40.13)
- Ollama FAQ (v0.40.13)
- llama.cpp b12015 tools/server/README.md (GitHub)
- llama.cpp b12015 リリース (GitHub)
- llama.cpp b12015 tools/perplexity/README.md (GitHub)
