Qwen3.8-27BのMTPは16GBで速くなるか｜有効化で増えるVRAMと、速くならない条件を実測

MTPで速くなるかどうかは、有効化で増えたGPU全体使用量の大きさと対応した

llama-server で Qwen3.8-27B のマルチトークン予測 (MTP) を有効にし、その前後で GPU 全体使用量と生成速度を測った組が7つある。どの組もカード・量子化・KVキャッシュの型・文脈長をそろえたまま、--spec-type draft-mtp の有無だけを変えたものだ。割れ方は、有効化で GPU 全体使用量がどれだけ増えたかに対応した。増分+610〜+800MiBの5組が速くなり、+416MiB以下の2組は速くならなかった。分かれ目が+416MiBと+610MiBの間のどこにあるかは測っていない。

MTP という仕組み自体はMTP（マルチトークン予測）でローカルLLMは本当に速くなるかで扱った。

カード	量子化	KVキャッシュ	MTPなし	MTPあり	増分
RTX 5060 Ti	UD-IQ4_XS	f16	毎秒27.27トークン	毎秒46.46トークン	+800MiB
RTX 5060 Ti	UD-IQ4_XS	q8_0	毎秒27.19トークン	毎秒44.77トークン	+800MiB
RTX 5060 Ti	UD-Q3_K_XL	f16	毎秒28.88トークン	毎秒47.12トークン	+800MiB
RTX 5060 Ti	UD-Q4_K_M	q4_0	毎秒24.22トークン	毎秒41.05トークン	+800MiB
RTX 5080	UD-Q3_K_XL	f16	毎秒54.36トークン	毎秒81.46トークン	+610MiB
RTX 5060 Ti	UD-Q4_K_M	f16	毎秒24.57トークン	毎秒8.19トークン	+416MiB
RTX 5080	UD-IQ4_XS	f16	毎秒22.45トークン	毎秒23.70トークン	+32MiB

文脈長 (一度に扱えるトークン数の枠。llama-server では -c で指定する) はすべて8,192、先読み上限は2。増分は nvidia-smi の memory.used の差であり、これはプロセス単位ではなく GPU 全体の使用量だ。RTX 5060 Ti は画面出力に使っておらず総量16,310MiB・測定開始時0MiB、RTX 5080 はデスクトップ表示に使用中で総量16,303MiB・測定開始時2,363〜2,367MiB。カードをまたいで速度の絶対値を比べる場合は、この測定開始時の差に加えてメモリ構成 (128bit と 256bit) と CUDAコア数 (4,608 と 10,752) の違いも同時に入るため、絶対値はカード内で読むことになる。

図の縦軸は有効化で増えた量だが、有効化する前に空いていた容量も同じ7組を同じように分ける。どちらが結果を分けているかはこの測定では切り分けられない。数字は「増分の大きさで結果が割れた」に置いた。

速くなった5組は RTX 5060 Ti の4組と RTX 5080 の1組にまたがり、量子化3種・KVキャッシュの型3種と条件が違う。それでも増分が+610〜+800MiBに収まった組はいずれも向上した。向上の幅は組ごとに違い、増分+800MiBで揃った4組でも毎秒24.22〜28.88トークンから毎秒41.05〜47.12トークンと開きがある。増分の大きさと向上の幅の対応は、カードをまたいでは比べられない。同じ指定が向上・横ばい・低下に分かれる以上、MTP の効果を単一の倍率では表せない。

そうならなかった2組のうち、+416MiBの組 (RTX 5060 Ti・UD-Q4_K_M・KV f16) は毎秒24.57トークンから毎秒8.19トークンへ落ちた。+32MiBの組 (RTX 5080・UD-IQ4_XS) は毎秒22.45から23.70トークンで、ほとんど動いていない。

GPU 1枚で画面も出している構成に当たるのは RTX 5080 の2行だ。測定開始時の使用量も2,363〜2,367MiBの範囲でそろっているが、UD-Q3_K_XL は+610MiBで毎秒54.36から81.46トークンへ上がり、UD-IQ4_XS は+32MiBでほとんど動かなかった。表示に使っているかどうかで一方に倒れるのではなく、このカードの中でも割れている。ただしこの2行は重みの大きさが違うため、増分と有効化前の空きが同時に動いている。この測定からはどちらとも切り分けられない。

測定環境と、測っていないもの

本記事の実測値は2026年9月5日・当該構成での測定に基づく。

項目	内容
GPU (1)	RTX 5060 Ti 16GB。画面出力に使っていない。総量16,310MiB・測定開始時の GPU 全体使用量 0MiB
GPU (2)	RTX 5080 16GB。デスクトップ表示に使用中。総量16,303MiB・測定開始時の GPU 全体使用量 2,363〜2,367MiB
OS	Windows 11
推論	llama.cpp b10356 の CUDA ビルド、llama-server
モデル	Qwen3.8-27B (GGUF は unsloth/Qwen3.8-27B-GGUF の配布ファイル)
量子化と実バイト数	UD-Q3_K_XL 13,146,393,504バイト / UD-IQ4_XS 14,252,845,984バイト / UD-Q4_K_M 16,464,440,224バイト
共通引数	-ngl 99 / --parallel 1 / -c 8192 / KVキャッシュ f16 (変えた節では明記)
測り方	llama-server の /completion に生プロンプトを送り、生成320トークン×3回の中央値 (文脈長32,768と94,208の行は256トークン×2回、チャット経路の節は上限512トークン)
VRAM	nvidia-smi の memory.used。GPU 全体使用量であり、モデルが確保した分だけの値ではない

表中の MiB は2進の単位で、配布ページに並ぶ10進表示とは基数が違う。GGUF は同じ量子化名のまま作り直されることがあるため、量子化名だけで結論を固定できる保証はない。オープンウェイトのライセンスは、2026年9月時点の Hugging Face model card に Apache 2.0 と表示されている (将来変更されうる)。

以下は bash 系シェルの記法で、行末の \ は次の行へ続けるための記号になる。日本語フォントの環境では円記号として表示されることがあるが、同じ文字だ。1行につなげて書いても動作は変わらない。モデルのパスは置き換えてある。

llama-server \
  -m /path/to/Qwen3.8-27B-UD-IQ4_XS.gguf \
  -ngl 99 --parallel 1 -c 8192 \
  --cache-type-k f16 --cache-type-v f16

MTP を有効にする場合は、同じ引数に2つ足す。

llama-server \
  -m /path/to/Qwen3.8-27B-UD-IQ4_XS.gguf \
  -ngl 99 --parallel 1 -c 8192 \
  --cache-type-k f16 --cache-type-v f16 \
  --spec-type draft-mtp --spec-draft-n-max 2

-c 8192 を省くと、この記事の測定と同じ条件にならない可能性がある。ビルド b10356 の llama-server では -c の既定が 0 で、0 はモデルから読み込む指定だ。Qwen3.8-27B の config.json は max_position_embeddings を 262,144 としており、その文脈長を16GB 1枚で確保する条件は本記事では再現していない。さらにこのビルドは、未指定の引数を空きメモリに合わせて調整する動作を既定で有効にしており、調整で下げられる文脈長の下限は既定で4096である。つまり -c を省いた起動が成立しないのではなく、文脈長が自動的に縮められうる。省略したときに実際どこへ落ち着くかは測っていない。

生成品質 (MTP 有効時・KVキャッシュ量子化時のいずれも)、画像入力、GPU 2枚構成、YaRN による文脈拡張、並列2以上、長時間稼働は本記事の測定範囲の外だ。また /completion 経路の応答は思考テキストのまま320トークンの上限に達しており、この経路の速度は可視の回答部分だけを生成する速度ではない。チャット形式で送ったときの値は「チャット経由で使う場合の値は別に測った」の節に置いた。

2枚構成そのものの挙動はローカルLLMを2枚のGPUのVRAMプールで動かすで、同じ RTX 5080 と RTX 5060 Ti を使って測った。ただし Qwen3.8-27B と MTP を2枚で測ったものではない。

既定のまま起動するとMTPは無効になっている

ビルド b10356 の llama-server の --help 出力には、本記事で動かした4つの引数の既定値が記載されている。

--spec-type none,draft-simple,draft-eagle3,draft-mtp,draft-dflash,draft-dspark,ngram-simple,... (default: none)
--spec-draft-n-max N   number of tokens to draft for speculative decoding (default: 3)
-ctk, --cache-type-k TYPE  KV cache data type for K  allowed values: f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1  (default: f16)
-c, --ctx-size N   size of the prompt context (default: 0, 0 = loaded from model)

投機デコードの指定 --spec-type は draft-mtp を選択肢に持つが、既定は none だ。モデルが MTP 用の層を持っていても、引数を足さずに起動した時点では使われていない。先読み上限 --spec-draft-n-max の既定は3、KVキャッシュの型 --cache-type-k / --cache-type-v の既定は f16 で、受け付ける型は f32・f16・bf16・q8_0・q4_0・q4_1・iq4_nl・q5_0・q5_1 である。ここで確認したのは llama-server の挙動であり、llama.cpp 全体の仕様として述べているのではない。

前記事「Qwen3.8-27BをVRAM 16GBで実測｜量子化3種の必要VRAMと起動オプションの差」では、この2つを既定のまま、つまり MTP を無効・KVキャッシュを f16 のみで測っていた。本記事はその2つを動かした結果を扱う。

1構成の起動ログでは3つのバッファが増えた

-lv 4 を付けて起動したときのログには、確保したバッファの内訳が出る。RTX 5060 Ti・UD-IQ4_XS・文脈長8,192・KVキャッシュ f16 の1構成で、MTP の有無だけを変えた内訳が次の値だ (生成は行っていない)。

項目	MTPなし	MTPあり n-max 2	差
モデル本体 (CUDA0)	12,726.35MiB	13,061.10MiB	+334.75MiB
再帰状態 (RS buffer)	149.62MiB	448.88MiB	+299.26MiB
ドラフト側のKVキャッシュ	なし	32.00MiB	+32.00MiB
KVキャッシュ (CUDA0)	512.00MiB	512.00MiB	0
計算バッファ (CUDA0)	130.02MiB	130.02MiB	0
CPU側に残るモデル	521.00MiB	521.00MiB	0
nvidia-smi の GPU 全体使用量	13,658MiB	14,458MiB	+800MiB

増えたのは上の3項目で、合計666.01MiB。同じ起動での GPU 全体使用量の増分は+800MiB あり、両者は一致しない。起動ログの数字は llama-server が確保のたびに出力したもので、nvidia-smi が見ている GPU 全体の使用量とは、そもそも数え方が違う。差の内訳は確認しておらず、原因も特定していない。

モデル本体が増えたこと自体は、Qwen3.8-27B の config.json に書かれている内容と食い違わない。config.json の記載は次のとおり (2026年9月時点)。

config.json の項目	記載値
num_hidden_layers	64
hidden_size	5120
num_attention_heads	24
num_key_value_heads	4
linear_num_value_heads	48
linear_num_key_heads	16
mtp_num_hidden_layers	1
mtp_use_dedicated_embeddings	false

マルチトークン予測用の層を1層持ち、その層に専用の埋め込みは持たせない、と書かれている。MTP を有効にしたときにモデル本体側が334.75MiB増えたこと自体は、この記載と食い違わない。ただし334.75MiB がその1層ぶんにあたるかどうかまでは突き合わせていない。

このモデルは通常のアテンションとは別に、線形アテンション側のヘッド (value 48・key 16) を持つと書かれている。再帰状態のバッファはこの構成に対応するものだ。アテンション以外の仕組みを混ぜたモデルを同じ16GBで測った例としてはNemotron 3 Nanoを16GBで実測もある。ただし、このバッファが149.62MiBから448.88MiBへちょうど3倍に増えた点は、config.json のヘッド数だけからは説明がつかない。何が3つ分なのかは確認していない。

同じ起動ログの1行目には [spec] estimated memory usage of MTP context is 162.02 MiB という行もある。これは MTP コンテキスト分の推定値で、実測値ではない。内訳の合計666.01MiB や GPU 全体使用量の増分800MiB とは指している範囲が違うため、突き合わせて過不足を論じる対象ではない。

なお、この内訳を取ったのは RTX 5060 Ti・UD-IQ4_XS の1構成だけだ。他の構成でも同じ内訳になるとは限らない。

増分の大きさで結果が割れた

増分+610〜+800MiBの5組では、RTX 5060 Ti の4組が毎秒24.22〜28.88トークンから毎秒41.05〜47.12トークンへ、RTX 5080 の1組が毎秒54.36トークンから毎秒81.46トークンへ上がった。+416MiB以下の2組はそうならず、+416MiBの組は毎秒24.57トークンから毎秒8.19トークンへ落ち、+32MiBの組はほとんど動かなかった。

速くなった5組の内訳は RTX 5060 Ti の4組と RTX 5080 の1組で、カードをまたいで揃ったと言えるのはこの5組を合わせた場合だ。増分+800MiB の4組だけを取り出すと、いずれも RTX 5060 Ti である。

この分かれ方は、有効化したあとに残っていた容量では説明できない。MTP を有効にしたあとの GPU 全体使用量は、毎秒8.19トークンへ落ちた組が16,022MiB、毎秒41.05トークンへ上がった組が16,038MiB、文脈長94,208で毎秒42.55トークンが出た構成が16,040MiBと、いずれも総量16,310MiB に対してほぼ同じ位置にある。それでも結果は分かれた。

ただし有効化する前に空いていた容量のほうは、同じ7組を分けている。総量から MTPなし側の使用量を引くと、速くなった5組は1,072MiB以上、そうならなかった2組は704MiB以下だった。有効化前の空きと増分はどちらも同じ分かれ方をするため、この測定ではどちらが結果を分けているか切り分けられない。増分は有効化の前後を比べて初めて出るが、有効化前の空きは MTPなし の起動だけで分かる。どちらも同じ分かれ方をした以上、片方だけを閾値として使えるわけではない。

2026年9月8日に、同じGGUF・同じllama.cpp b10356・同じプロンプトで測り直した。RTX 5060 Ti の条件は誤差の範囲で再現したが、RTX 5080 の UD-IQ4_XS だけが変わった。記録上の違いは測定開始時のGPU全体使用量で、9月5日は2,363MiB、9月8日は1,332MiBだった。速度は MTPなし が毎秒22.45から49.58トークン、MTPあり が毎秒23.70から75.90トークンになった。重みの小さい UD-Q3_K_XL は両日とも大きく変わっていない。ただしこれは「空きが増えて収まったから速くなった」とは読めない。9月8日の毎秒75.90トークンの回も、起動ログは必要量を803MiB減らす必要があると出しており、共有GPUメモリへ376MiB出て、生成中のPCIe受信は毎秒1,824MBだった（毎秒49.58トークンの回は毎秒117MB）。収まりきってはいない。同じ指定でも測定開始時の状態で結果が変わる、というところまでになる。1台・各3回の測定なので、この倍率は他の環境に持ち出せない。

+32MiB という増分は、バッファの内訳表にあるドラフト側KVキャッシュ32.00MiB と同じ大きさだ。ただし内訳を取ったのは RTX 5060 Ti で、+32MiB を記録した RTX 5080 側では起動ログの内訳を取っていない。nvidia-smi に現れるのは GPU 上の使用量だけであり、残り2項目が確保されなかったと読める材料はない。同じ大きさの数字が出た、というところまでになる。

内訳を1構成でしか取っていない以上、MTP が要求する量が構成ごとに同じかどうかも確かめていない。分かれ目が+416MiBと+610MiBの間のどこにあるかについても、その間を刻んだ測定はしていない。

配布元の Unsloth は、Qwen3.8-27B の所要メモリをビット幅別の表で案内したうえで、MTP を使う場合には1〜2GBの余裕を用意するよう記載している (2026年9月時点)。その所要メモリの表の単位は RAM と VRAM を合わせた総量で、VRAM 単独ではない。文脈長や KVキャッシュの型も指定されていないため、本記事の増分と条件がそろっているとは限らず、実測と食い違うと断じる根拠にもならない。

failed to fit と出ても載っていないわけではない

-lv 4 で起動すると、メモリの見積もりに関する行が出る。MTP なしと MTP あり n-max 2 で、それぞれ次のように出た (RTX 5060 Ti・UD-IQ4_XS・文脈長8,192・KVキャッシュ f16・-ngl 99・--parallel 1、ビルド b10356)。

MTP なし:

projected to use 13517 MiB of device memory vs. 15022 MiB of free device memory
will leave 1504 >= 1024 MiB of free device memory, no changes needed
successfully fit params to free device memory

MTP あり n-max 2:

[spec] estimated memory usage of MTP context is 162.02 MiB
projected to use 14151 MiB of device memory vs. 14722 MiB of free device memory
cannot meet free memory target of 1186 MiB, need to reduce device memory by 616 MiB
failed to fit params to free device memory: n_gpu_layers already set by user to 99, abort
load_tensors: offloaded 66/66 layers to GPU

failed to fit という語だが、これは載らないという意味ではない。見積もり14,151MiBは、そのとき空いていた14,722MiBに収まっている。満たせていないのは確保後に残したい余白の目標1,186MiBのほうで、確保後に残るのは571MiB程度で、目標に616MiB足りないという指摘が出ている (ログの値はMiB単位に丸められており、引き算は1MiBずれる)。どちらの起動でもサーバは立ち上がり、生成も行えた。同じログには 66/66 の行もあるが、これは収まりの証拠にならない。

この判定には空きが2つ出てくる。ログが示す実測の空き14,722MiBと、確保後に残そうとする余白の目標1,186MiBだ。満たせなかったのは後者で、これは nvidia-smi が示す残量とは別の基準になる。MTP なし側の目標1,024MiBは、ビルド b10356 の --help にある「デバイスごとに残そうとする余白の目標は既定1024」という記載と一致する。MTP あり側の目標1,186MiBとの差は、同じログ1行目にある MTPコンテキストの推定162.02MiBとほぼ一致する。

この警告が出たかどうかは、MTP で速くなる構成かどうかの判断材料にならない。警告が出た同じ構成が、毎秒27.27トークンから毎秒46.46トークンへ上がっている。有効化で GPU 全体使用量がどれだけ増えたかを見るほうが、判断の材料になる。

KVキャッシュの型を落とすと置き場所ができる

7組のうち唯一大きく落ちた組は、RTX 5060 Ti で最も重い量子化 UD-Q4_K_M を使った組み合わせだった。同じカード・同じ量子化で、KVキャッシュの型と MTP の有無を変えた4行が次の値だ (文脈長8,192・生成320トークン×3回の中央値)。

KVキャッシュ	MTP	VRAM	生成速度
f16	なし	15,606MiB	毎秒24.57トークン
f16	n-max 2	16,022MiB	毎秒8.19トークン
q4_0	なし	15,238MiB	毎秒24.22トークン
q4_0	n-max 2	16,038MiB	毎秒41.05トークン

MTP なしどうしを比べると毎秒24.57トークンと毎秒24.22トークンで、KVキャッシュの型そのものは速度をほとんど動かしていない。動いたのは MTP を有効にしたときの結果のほうで、f16 のままだと毎秒8.19トークンへ落ち、q4_0 にすると毎秒41.05トークンへ上がった。

MTPなし側は15,606MiBから15,238MiBへ368MiB下がった。一方、有効化後は16,022MiBと16,038MiBで16MiB違うため、増分は+416MiBから+800MiBへ384MiB広がっている。368MiBと384MiBの差はこの16MiBぶんで、有効化前に空いた容量が概ねMTP側の追加確保に回った形になる。空いたのは有効化前の余地であって、有効化後の残量が増えたわけではない。

文脈長を伸ばした場合の値も測ってある。文脈長が伸びると KVキャッシュが増える一般的な挙動についてはローカルLLMで長文を扱うとVRAMはどれだけ増えるかで扱った。UD-IQ4_XS で型だけを変えた値は次のとおり。

文脈長	KVキャッシュ	MTP	VRAM	生成速度
8,192	f16	なし	13,658MiB	毎秒27.27トークン
8,192	q8_0	なし	13,418MiB	毎秒27.19トークン
8,192	f16	n-max 2	14,458MiB	毎秒46.46トークン
8,192	q8_0	n-max 2	14,218MiB	毎秒44.77トークン
32,768	f16	n-max 2	15,986MiB	毎秒44.64トークン
32,768	q8_0	n-max 2	15,240MiB	毎秒45.88トークン
32,768	q4_0	n-max 2	14,728MiB	毎秒47.66トークン

使用量は型を落とすほど下がる。速度については、隣り合う型どうしの差を判定できるだけの反復を取っていない。3回の幅を取ったのは文脈長8,192の測定で、MTP なしが毎秒27.25〜27.28トークン、MTP あり n-max 2 が毎秒45.03〜47.37トークンという幅だった。文脈長32,768の3行 (毎秒44.64・45.88・47.66トークン) の差はこの幅と同程度で、しかも32,768での再現幅は測っていない。この3行から単調な傾向までは読み取れない。

先読み上限は、測った1構成では3で頭打ちだった

RTX 5060 Ti・UD-IQ4_XS・文脈長8,192・KVキャッシュ f16 で、先読み上限 --spec-draft-n-max だけを振った値が次のとおり。

設定	VRAM	生成速度	3回の幅
MTPなし	13,658MiB	毎秒27.27トークン	27.25〜27.28
MTPあり n-max 2	14,458MiB	毎秒46.46トークン	45.03〜47.37
MTPあり n-max 3	14,608MiB	毎秒48.94トークン	48.53〜49.13
MTPあり n-max 4	14,758MiB	毎秒48.98トークン	48.46〜50.28

2 から 3 へ上げた分は速度に出たが、3 と 4 の中央値は毎秒48.94トークンと毎秒48.98トークンで、3回の幅も重なっている。この構成では3で頭打ちだった。使用量のほうは1段あたり約150MiBずつ増え、n-max 4 では14,758MiBに達している。

同じ起動のログから読み取ったドラフトの採択率と平均確定長は次の値である (3回の生成それぞれ)。

n-max	採択率	平均確定長
2	0.628 / 0.689 / 0.669	2.26 / 2.37 / 2.34
3	0.580 / 0.588 / 0.583	2.74 / 2.77 / 2.75
4	0.534 / 0.510 / 0.507	3.13 / 3.04 / 3.03

先読みを増やすと採択率は下がり、1回で確定するトークン数の平均は伸びる。採択率は生成したドラフトのうち採用された割合であって、回答の精度や正答率ではない。

先読み上限を振ったのは RTX 5060 Ti・UD-IQ4_XS・文脈長8,192・KVキャッシュ f16 の1構成だけだ。空きが薄い構成で同じ刻み方になるか、1段あたり約150MiBという増え方が他の量子化や文脈長でも同じかは測っていない。

画面に使っていない16GB1枚で、文脈長94,208トークンの枠を確保できた

KVキャッシュを q4_0 にして MTP を有効にしたまま、文脈長を広げた場合の値が次のとおり (RTX 5060 Ti・画面出力に使っていない・測定開始時0MiB・総量16,310MiB・生成256トークン×2回の中央値)。

量子化	文脈長	n-max	VRAM	生成速度
UD-Q3_K_XL	32,768	3	13,822MiB	毎秒47.54トークン
UD-Q3_K_XL	94,208	2	15,322MiB	毎秒43.51トークン
UD-IQ4_XS	94,208	2	16,040MiB	毎秒42.55トークン

確保できたのは起動時の枠で、94,208トークンの長文を流し込んだ結果ではない。この値も16GBに載る範囲を探る過程で置いたもので、上限を詰めた数字ではない。モデルやカードの上限として扱える値ではなく、構成が変われば別の値になる。

config.json の max_position_embeddings は262,144と記載されている (2026年9月時点)。YaRN による拡張は本記事では検証していない。

表示に使っているカードでも、量子化で結果が割れた

RTX 5080 はデスクトップ表示に使用中で、総量16,303MiBのうち測定開始時点で約2,363〜2,367MiBが使われている。表の VRAM はその表示分2.3GiB前後を含んだ GPU 全体使用量だ。

量子化	MTP	VRAM	生成速度
UD-Q3_K_XL	なし	15,099MiB / 15,097MiB	毎秒53.07トークン / 毎秒54.36トークン
UD-Q3_K_XL	n-max 2	15,705MiB / 15,707MiB	毎秒83.35トークン / 毎秒81.46トークン
UD-IQ4_XS	なし	15,643MiB	毎秒22.45トークン
UD-IQ4_XS	n-max 2	15,675MiB	毎秒23.70トークン
UD-Q3_K_XL (KV q4_0・文脈長32,768)	n-max 2	15,669MiB	毎秒37.47トークン

UD-Q3_K_XL は別々の起動で2回測って両方を併記した。増分に使ったのは15,097MiB→15,707MiBの回の+610MiBで、もう一方どうしでは+606MiBになる。測定開始時の使用量が揃っている回だけを載せ、揃っていなかった2回分は除外した。KVキャッシュ q4_0・文脈長32,768 の行だけは、他の4行と条件が違う。

同じカードで、UD-Q3_K_XL は+610MiBの増分とともに毎秒54.36トークンから毎秒81.46トークンへ上がり、UD-IQ4_XS は+32MiBで毎秒22.45トークンから毎秒23.70トークンとほとんど動かなかった。表示に使っている1枚構成でも両側の結果が出ているが、量子化そのものの効果とは言えない。重みの大きさが違うぶん有効化前の空きも違い、両者が同時に動いている。

MTP なしどうしでも毎秒54.36と22.45トークンで開いているが、この差の理由は測っていない。増分が出なかったときに KVキャッシュの型を落とす回避が使えるかも、このカードの UD-IQ4_XS では測っていない。

RTX 5060 Ti の値と絶対値で比べる場合は、測定開始時の使用量 (0MiB と 2,363〜2,367MiB) の違いに加えて、メモリ構成 (128bit と 256bit) と CUDAコア数 (4,608 と 10,752) の違いも同時に入る。どれがどれだけ影響したかは、本記事の測定では分けられない。

チャット経由で使う場合の値は別に測った

ここまでの値は llama-server の /completion に生プロンプトを送った経路のものだ。チャットUI から使う構成に近いのは /v1/chat/completions の経路で、こちらは別に測った。RTX 5060 Ti・UD-IQ4_XS・文脈長8,192・KVキャッシュ f16、上限512トークン、none は3回・high は2回の中央値である。

reasoning_effort	MTP	生成速度	回答の文字数	思考の文字数	採択率
none	なし	毎秒27.34トークン	995	0	—
none	n-max 2	毎秒43.20トークン	987	0	0.592
high	なし	毎秒27.29トークン	191	708	—
high	n-max 2	毎秒39.32トークン	197	1,143	0.491

思考文字数と回答文字数は各回の平均で、どちらの設定でも上限512トークンで打ち切られている (finish_reason は length)。none では上限までが回答に使われ、high では思考側に多くが割かれた。この経路でも MTP 有効化で速度は上がり、none で毎秒27.34トークンから毎秒43.20トークンへ、high で毎秒27.29トークンから毎秒39.32トークンへ動いた。

採択率は none が0.592、high が0.491という記録だ。ただしこれは設定ごとに1値ずつで、反復ぶんの幅を出していない (none の3回・high の2回に対して記録は1つ)。採択率は同じ設定でも回ごとに動く値で、1値どうしの比較では「設定を変えると下がる」と判定できる状態にない。high の0.491も、思考と回答を含む生成1本ぶんのリクエスト単位の値であり、1回の生成の中の思考区間と回答区間を分けて測ったものではない。

まとめと、確かめる手順

MTP を有効にして速くなるかどうかは、有効化で GPU 全体使用量が増えるかどうかに対応していた。増分が+610〜+800MiBに収まった5組はカードも量子化も KVキャッシュの型も違うのに揃って速くなり、+416MiB以下の2組は速くならなかった。分かれ目がその間のどこにあるかは測っていない。有効化前に空いていた容量も同じ7組を同じように分けるため、どちらが結果を分けたかはこの測定では切り分けられない。起動の前後で見比べやすいのが増分のほうだ、というところまでになる。増分が伸びなかった構成でも、KVキャッシュの型を落として有効化前の使用量を下げると、増分が+800MiBまで伸びて速度が変わった例がある。

MTP の有無を実際に測った組み合わせを、量子化ごとに並べる。すべて /completion に生プロンプトを送った経路で、文脈長8,192・先読み上限2・生成320トークン×3回の中央値。KVキャッシュは注記のない行は f16 で、型どうしの速度差を判定できるだけの反復は取っていない (チャット経路の値は別の節に置いた)。

量子化 (実バイト数)	カード	MTPなし	MTPあり n-max 2	増分
UD-Q3_K_XL (13,146,393,504バイト)	RTX 5060 Ti	毎秒28.88トークン / 12,602MiB	毎秒47.12トークン / 13,402MiB	+800MiB
UD-Q3_K_XL	RTX 5080	毎秒54.36トークン / 15,097MiB	毎秒81.46トークン / 15,707MiB	+610MiB
UD-IQ4_XS (14,252,845,984バイト)	RTX 5060 Ti	毎秒27.27トークン / 13,658MiB	毎秒46.46トークン / 14,458MiB	+800MiB
UD-IQ4_XS・KV q8_0	RTX 5060 Ti	毎秒27.19トークン / 13,418MiB	毎秒44.77トークン / 14,218MiB	+800MiB
UD-IQ4_XS	RTX 5080	毎秒22.45トークン / 15,643MiB	毎秒23.70トークン / 15,675MiB	+32MiB
UD-Q4_K_M (16,464,440,224バイト)	RTX 5060 Ti	毎秒24.57トークン / 15,606MiB	毎秒8.19トークン / 16,022MiB	+416MiB
UD-Q4_K_M・KV q4_0	RTX 5060 Ti	毎秒24.22トークン / 15,238MiB	毎秒41.05トークン / 16,038MiB	+800MiB

RTX 5060 Ti は測定開始時0MiB・総量16,310MiB、RTX 5080 は測定開始時2,363〜2,367MiB・総量16,303MiB。VRAM の絶対値をカードをまたいで比べる場合は、この測定開始時の使用量の差が乗る。速度の絶対値を比べる場合は、さらにメモリ構成 (128bit と 256bit) と CUDAコア数 (4,608 と 10,752) の違いも入る。UD-Q4_K_M を RTX 5080 で動かした組み合わせは測っていない。量子化ごとの必要 VRAM そのものは前記事にまとめてある。

文脈長を広げる用途では、画面出力に使っていない RTX 5060 Ti (測定開始時0MiB・総量16,310MiB) で、KVキャッシュ q4_0・MTP あり n-max 2 のとき、UD-Q3_K_XL が文脈長94,208の枠を15,322MiB、UD-IQ4_XS が同じ枠を16,040MiBで確保できた (起動時に確保できた枠であり、長文を流し込んだ結果ではない)。表示に使っているカードでは測定開始時の2.3GiB前後がそのまま乗るため、同じ数字にはならない。

確かめる手順は2段になる。

1. いま使っている起動引数はそのままに、--spec-type draft-mtp --spec-draft-n-max 2 を足して起動する。先読み上限を省くと既定の3になり、測った1構成では1段あたり約150MiB増えて、下の増分の帯とは比べられない値になる。
2. 有効化の前後で、生成速度と nvidia-smi の memory.used (GPU 全体使用量) を比べる。

測った範囲では、増分の大きさに沿って次のように分かれた。

• +610〜+800MiB規模の増分が出た構成は、5組とも速くなった。
• ほとんど増えない構成 (+32MiB) では、速度もほとんど動かなかった。
• 中途半端に増えた構成 (+416MiB) では大きく落ちたため、KVキャッシュの型を落として測り直す余地がある。同じ量子化で q4_0 にすると増分は+800MiBまで伸び、速度は毎秒41.05トークンへ変わった。

分かれ目が+416MiBと+610MiBの間のどこにあるかは測っていない。単一の閾値としては使えず、出た増分が速くなった5組の範囲と、そうならなかった2組の範囲のどちらに近いかまでが読み取れる。GGUF は同じ量子化名で作り直されることがあり、ビルドが変われば既定値も変わる。確認は使う構成とビルドで行うことになる。

参考資料

• Qwen3.8-27B 公式モデルカード (Hugging Face)
• Qwen3.8-27B config.json
• unsloth/Qwen3.8-27B-GGUF
• Unsloth ドキュメント Qwen3.8
• llama.cpp