この記事の要点
- 公称16GB 1枚でも、比べた2枚で結論が分かれた。画面出力に使っていない1枚 (RTX 5060 Ti) では文脈4,096 の枠で量子化3種とも既定の起動指定のまま速度が出た。表示に使っている1枚 (RTX 5080) では、同じ枠で届かない量子化があった。
- 起動が通ったことは VRAM に収まったことを意味しない。今回の測定で判別の材料として最も有効だったのは生成速度と消費電力の組で、比べ方は2通りある。同じ量子化で指定だけを変えた前後の対照と、同じカード内で余裕のある量子化が示す帯との比較になる。GPU使用率も nvidia-smi の表示値も、この判別には使えなかった。
- 比べた2枚は型番・画面出力の有無・接続方式が同時に違うため、どれが結果を分けたかは切り分けていない。速度と消費電力の測定で、生成の品質は測っていない。
- 配布元は本記事の初回測定 (2026年8月15日) の後にファイルを作り直しており、同じ16GBのカードでも収まりの結論が変わった。旧版での測定もこの記事に残してある。
16GB 1枚で何が動いたか
公称16GBのカード2枚でも、結論が分かれた。文脈4,096・llama.cpp b10356・-ngl 99 での結果を量子化ごとにまとめると次のようになる。数値は2026年8月25日に取得した、配布元が作り直した後のファイルでの測定になる。
| 量子化 | RTX 5060 Ti 16GB (画面出力なし) | RTX 5080 16GB (デスクトップ表示に使用中) |
|---|---|---|
| UD-Q3_K_XL | 既定の起動指定のまま速度が出た | 既定の起動指定のまま速度が出た |
| UD-IQ4_XS | 既定の起動指定のまま速度が出た | 既定の起動指定のまま速度が出た |
| UD-Q4_K_M | 既定の起動指定のまま速度が出た | 既定でも --parallel 1 でも、他の2種と同じ速度帯には届かなかった |
この2列の違いは型番だけではない。5060 Ti は画面出力に使っておらず OCuLink 経由、5080 はデスクトップ表示に使っていて PCIe gen5 x16 と、3つが同時に違う。どれが結果を分けたのかは本記事では分けられていないので、この表を 5060 Ti と 5080 の型番そのものの性能比較として読むことはできない。手元のカードがどちらに近いかは、少なくともこの3点が比較材料になる。実際には背景で常駐しているアプリのVRAM使用や、ドライバ、メモリの断片化なども効きうるので、この3つで尽きるわけではない。
ここでの「速度が出た」は、同じカードで余裕のある量子化を動かしたときと同じ水準に並んだという意味で、絶対値はカードごとに違う。判定に使った数値は「速度と消費電力で『載ったか』を判定する」と「もう1枚の16GB (RTX 5080) では結論が変わる」の表に載せた。
この表の RTX 5060 Ti の列は、初回に測ったときとは違う。当時のファイルでは UD-Q4_K_M にあたる量子化が既定では遅く、--parallel 1 を付けて初めて速度が出ていた。配布元がファイルを作り直して重みが軽くなったため、いまは指定を足さなくても収まる。経緯と旧測定は「配布元がファイルを作り直すと結論が変わる」で扱う。
この表は文脈4,096 に限った結果で、枠を広く取れば同じ量子化でも結果は変わる。文脈長を伸ばしたときの挙動は後半の「文脈をどこまで伸ばせるか」、2枚のカードに分けた場合は「2枚構成にすると何が変わるか」で扱う。
測定環境と、測っていないもの
機材は RTX 5060 Ti 16GB (画面出力に使っていない・総量16,310MiB・OCuLink 接続でリンクは負荷時 PCIe gen4 x4) と RTX 5080 16GB (デスクトップ表示に使用中・総量16,302MiB・PCIe gen5 x16)。OS は Windows 11。数値はいずれも2026年8月25日に取得した。初回の測定は2026年8月15日に行っており、その値は「配布元がファイルを作り直すと結論が変わる」に残してある。
推論エンジンは llama.cpp b10356 の CUDA ビルド。b10356 は Qwen3.8-27B の公開より前のビルドだが、GGUF が宣言するアーキテクチャ名が qwen35 で、Qwen3.5系として既に対応済みだったため、そのまま読み込めた。将来 GGUF 側の仕様が変わった場合までは保証しない。
モデルは unsloth が配布している GGUF を使った。Hugging Face 上の表示サイズは、2026年8月25日時点で UD-Q3_K_XL が13.1GB、UD-IQ4_XS が14.3GB、UD-Q4_K_M が16.5GB。この表示は10進の GB で、本記事が llama.cpp や nvidia-smi から示す MiB とは基数が違う。たとえば UD-IQ4_XS は Hugging Face 上で14.3GBと表示されるが、実ファイルは14,252,845,984バイトで13,592MiB (約13.27GiB) になる。カードの容量と直接引き算するときは、表示値ではなく実バイト数から換算した値を使うことになる。オープンウェイトのライセンスは Apache-2.0 (2026年8月25日時点の Hugging Face の model card の表示。将来変更されうる)。
測り方は次のとおり。生成速度は llama-server の /completion が返す timings の値で、毎回異なるプロンプトで3回測った中央値。チャットテンプレートは通していないため、llama-server の速度表はテンプレート由来の思考トークンを含まない生成経路の値になる。同じモデルを同じ llama.cpp 環境で /v1/chat/completions から呼んだ確認では思考モードが有効になり、上限128トークンでは思考だけで枠を使い切って可視の回答が出なかった。生成トークン数は128を上限とした短い応答での測定なので、プロンプトの内容や長さを変えれば値は動く。
GPU使用率と消費電力は生成中に0.5秒間隔でサンプリングした中央値。メモリの内訳は起動ログ (-lv 4) から読み取った。llama-bench を使った測定は各3回で、pp512 がプロンプト処理、tg128 が生成にあたる。
起動指定は次の4通りを使った。モデルのパスは環境ごとに違うため置き換え表記にしてある。
- 余裕のある量子化を既定のまま起動する:
llama-server -m <Qwen3.8-27B-UD-Q3_K_XL.gguf のパス> -ngl 99 -c 4096 - スロットを1つに固定して線形アテンション状態を減らす:
llama-server -m <Qwen3.8-27B-UD-Q4_K_M.gguf のパス> -ngl 99 -c 4096 --parallel 1 - メモリの内訳と収まり判定を起動ログに出す: 上記に
-lv 4を足す - 画像入力:
llama-mtmd-cli -m <Qwen3.8-27B-UD-Q3_K_XL.gguf のパス> --mmproj <mmproj-F16.gguf のパス> -ngl 99 -c 8192に画像の指定を足す (本記事の画像測定は文脈8,192。--parallelは llama-server 側のオプションでここには引き継がない)
GGUF のファイル名は unsloth の配布ページのもの。-lv 4 は内訳を確認するときだけ必要で、常用には要らない。配布ページのファイル名は入れ替わることがあるので、取得したファイルのバイト数を控えておくと、後から同じものを測ったか確かめられる。
測っていない次元は次のとおり。生成の品質。動画入力・複数枚・高解像度の画像。ここに挙げた以外の OS と推論エンジン。測定に使った3種以外の量子化 (Q5_K_M や Q8 など)。16GB 以外の容量のカード単体。これらについて本記事は可否も優劣も示さない。
Qwen3.8-27Bのメモリの使い方は普通の27Bと違う
公式の config.json にある layer_types と full_attention_interval=4 から、テキスト側は64層のうち16層だけが通常のアテンションで、残る48層は線形アテンションを使う構成になっている。画像エンコーダはこれとは別立てで、ここでの層数はテキスト側の話になる。
メモリの観点でこの構成が効いてくるのは、KVキャッシュを持つのが通常のアテンション層だけだからだ。文脈長を伸ばしたときに増えるのは16層分に限られ、線形アテンション側の状態は文脈長を変えても大きさが変わらない。起動ログが示す線形アテンション状態のサイズは、文脈4,096でも262,144でも同じ値のままだった (後掲の表)。アテンション以外の仕組みを混ぜたモデルを同じ16GBで測った例としては、Mambaハイブリッドを扱ったNemotron 3 Nanoを16GBで実測がある。
代わりに、線形アテンション側の状態はスロットの数に比例して確保される。文脈長では増えず、スロット数では増える。この非対称が、次に出てくる --parallel の効き方の前提になる。
量子化3種の必要メモリ
まず内訳から。以下は --parallel を指定しない既定の経路で起動したときの値で、RTX 5060 Ti 16GB (画面出力なし・総量16,310MiB)、文脈4,096、llama-server の起動ログ (-lv 4) から取得している。
| 量子化 | GPU上の重み | KVキャッシュ | 線形アテンション状態 | 計算バッファ | 合計 |
|---|---|---|---|---|---|
| UD-Q3_K_XL | 11,671MiB | 256MiB | 598.5MiB | 126MiB | 12,651MiB |
| UD-IQ4_XS | 12,726MiB | 256MiB | 598.5MiB | 126MiB | 13,706MiB |
| UD-Q4_K_M | 14,674MiB | 256MiB | 598.5MiB | 126MiB | 15,654MiB |
重みのうち521〜682MiBはCPU側に残るため、表のGPU側の値と配布ファイルのサイズは一致しない。計算バッファは文脈長を伸ばすと少しずつ増える(4,096で126MiB、262,144で378MiB)。
既定での UD-Q4_K_M の合計15,654MiBは、カードの総量16,310MiB の下に入る。ただしこの2つの差だけで収まりを判定することはできない。llama.cpp が収まり判定に使う空きはカードの総量とは別の数字で、その扱いは「起動できたことは載ったことを意味しない」で扱う。作り直される前のファイルではこの合計が16,326MiBで、総量を超える側にあった。
配布ファイルのサイズとGPU上の重みが一致しない理由は、突き合わせると分かれる。次の表は、配布ファイルの実バイト数と、起動ログが示す確保先を並べたもの (RTX 5060 Ti / 文脈4,096)。
| 量子化 | 配布ファイル | GPU上の重み | CPU側 | 読み飛ばされる分 | 残差 |
|---|---|---|---|---|---|
| UD-Q3_K_XL | 12,537MiB | 11,671MiB | 521MiB | 334.7MiB | 10.5MiB |
| UD-IQ4_XS | 13,592MiB | 12,726MiB | 521MiB | 334.7MiB | 10.5MiB |
| UD-Q4_K_M | 15,701MiB | 14,674MiB | 682MiB | 334.7MiB | 10.5MiB |
読み飛ばされる分は、GGUFに入っているマルチトークン予測用の層のテンソルを起動ログから合計したもの。作り直された後のファイルでは3種とも334.7MiBで揃っている (作り直される前は量子化ごとに198.8〜276.1MiBと違っていた)。残差は表のとおりどの量子化でも10.5MiB (配布ファイルの列を MiB に丸めているため、列をそのまま引くと0.5MiB前後ずれる)。内訳は確認していない。
この「読み飛ばされる分」は、公式の config.json が mtp_num_hidden_layers を1としている層に対応する。マルチトークン予測用の層が1層あること自体は仕様どおりで、b10356 にも投機デコードの指定として --spec-type draft-mtp があり、既定は none になっている。本記事の速度測定ではこれを有効にしておらず、通常の推論経路では起動ログのとおりこの層のテンソルが読み飛ばされた。以下の速度値は、マルチトークン予測を使わない状態での結果になる。
--parallel 1 で必要量が449MiB減る
llama-server の --parallel はサーバのスロット数の指定で、既定値は -1 (自動) だと公式ドキュメントに記載がある。自動のときに実際に何スロットになるか、-c で指定した文脈長が1リクエストあたりどう割り当てられるかは、起動ログを読んで確かめた。次の表は UD-Q3_K_XL で -c 4096 を指定した状態から、--parallel の書き方だけを変えたもの (値は起動ログの n_ctx_slot)。
| 起動時の指定 | スロット数 | 1リクエストが使える文脈長 |
|---|---|---|
--parallel を書かない |
4 | 4,096 |
--parallel 4 と書く |
4 | 1,024 |
--parallel 1 と書く |
1 | 4,096 |
スロット数が4になる2つの指定 (--parallel を書かない場合と --parallel 4 と書く場合) では、KVキャッシュの総量(256MiB)も線形アテンション状態の総量(598.5MiB)も同じ。この2つの違いは1リクエストが使える文脈長だけ。--parallel 1 を指定したときだけ線形アテンション状態が149.6MiBに減る。
598.5MiB から149.6MiB へ減る分が449MiBで、文脈長を1トークンも削らずに起動時の必要量がこれだけ動く。線形アテンション状態がスロット単位で確保されるためで、KVキャッシュ側を削って捻出しているわけではない。ただし、この減り方はスロットごとに状態を持つ構造に由来するもので、同じ指定を他の27B級モデルに当てはめて同じ効果を期待できるとは限らない。
スロット数を書かない場合と --parallel 4 と明示した場合で1リクエストの文脈長が変わる点は、--kv-unified の既定と対応している。公式ドキュメントによれば --kv-unified はスロット数が自動のときだけ既定で有効になり、有効なときは全スロットが単一の共有KVバッファを使う。つまり -c で指定した文脈長は1リクエスト専用の枠ではなく共有の枠になる。スロット数を明示すると自動ではなくなるため、同じ4スロットでも1リクエストあたりの取り分が変わる。
なお、この449MiBが効くのは、必要量がカードの空きを超えている構成に限られる。本記事の3種は文脈4,096ではどれも既定で収まっているため、ここで差は出ない。効かせたい場面が来たとして、449MiB 減れば足りるのかどうかは、この数字だけでは決まらない。何から引くかで結論が変わるためで、その事情は後の節で扱う。
速度と消費電力で「載ったか」を判定する
起動ログの数字だけでは収まったかどうかが決まらないため、同じ条件で並べた実測から判定した。RTX 5060 Ti 16GB (画面出力なし)、llama-server b10356、文脈4,096、-ngl 99。量子化3種それぞれについて、既定と --parallel 1 の2通りを測った。
| 量子化 | 設定 | 生成速度 | GPU使用率 | 消費電力 | nvidia-smi |
|---|---|---|---|---|---|
| UD-Q3_K_XL | 既定 (--parallel なし) |
毎秒29.02トークン | 98% | 171.2W | 12,792MiB |
| UD-Q3_K_XL | --parallel 1 |
毎秒28.90トークン | 98% | 172.7W | 12,342MiB |
| UD-IQ4_XS | 既定 (--parallel なし) |
毎秒26.80トークン | 97% | 158.5W | 13,848MiB |
| UD-IQ4_XS | --parallel 1 |
毎秒27.44トークン | 97% | 163.9W | 13,398MiB |
| UD-Q4_K_M | 既定 (--parallel なし) |
毎秒24.51トークン | 98% | 162.1W | 15,796MiB |
| UD-Q4_K_M | --parallel 1 |
毎秒24.53トークン | 98% | 161.7W | 15,346MiB |
この表は速度と消費電力の測定で、生成の品質は測っていない。
この表では、3種とも --parallel 1 を付けても値がほとんど動かない。毎秒29.02→28.90トークン、26.80→27.44トークン、24.51→24.53トークンで、消費電力も同じ帯に留まる。ただし「指定を変えても動かない」だけでは収まっている根拠にならない。溢れている幅が449MiBより大きければ、どちらの指定でも低いまま動かないためで、後で出てくる RTX 5080 の UD-Q4_K_M がその形になる。ここで効いているのはもう1つの条件で、いちばん重い UD-Q4_K_M でも、余裕のある UD-Q3_K_XL に対して速度で15%・消費電力で5%しか下がっていない。後で出てくる RTX 5080 では、同じ2つの差が60%と40%まで開く。動かないことと、余裕のある量子化との差がこの程度に収まっていることの2つが揃って初めて、このカードでは文脈4,096の枠なら3種とも既定のまま収まっていると読める。
初回に測ったときは違った。作り直される前の Q4_K_M は既定で毎秒5.44トークン・64.7W しか出ず、--parallel 1 を付けて毎秒23.63トークン・162.4W に戻るという、この表の中で唯一大きく動く行だった。速度と消費電力が揃って落ちて揃って戻るという型が、収まっていなかったことの根拠になっていた。同じ判定を作り直された後のファイルに当てると、どの行も落ちていないという読み方になる。
ここで使えなかった指標が2つある。1つはGPU使用率で、この表の3種はどの指定でも97〜98%に並ぶ。速度が落ちた構成と比べても、この値は下がらない。同じカードで量子化も起動指定も変えず、文脈長だけを65,536へ広げると生成は毎秒29.02トークンから7.67トークンへ落ちるが、使用率は98%から99%へ上がる (後掲の「文脈をどこまで伸ばせるか」の1行目と3行目)。変えた条件は文脈長ひとつだけで、速度が4分の1になってもこの値は高いままだった。使用率の高さを「速度が出ている」ことの根拠にはできない。NVIDIA の定義では、この値は「直前のサンプリング期間のうち、1つ以上のカーネルが実行されていた時間の割合」であり、演算器を何パーセント使い切っているかや、処理がどれだけ進んでいるかを直接示す値ではない。定義の原文は NVIDIA の nvidia-smi ドキュメントにある。
もう1つは nvidia-smi のメモリ表示で、こちらは上限に近い領域で速い側と遅い側が分かれなくなる。この表でいちばん表示が大きい UD-Q4_K_M の15,796MiBは速度が出ている側だが、文脈65,536まで広げて毎秒7.67トークンまで落ちた構成は16,032MiBで、差は236MiBしかない。この2つは量子化も文脈長も違うが、どちらも上限付近に来ると表示はこの幅に収まってしまう。速度は3倍以上違うので、表示の大小を収まりの根拠には使えない。作り直される前のファイルでは差がさらに小さく、Q4_K_M の遅い側が16,026MiB、速い側が16,024MiB とほぼ同じ値を示していた。
残ったのが生成速度と消費電力の組で、遅い側では消費電力も一緒に下がる。ただし消費電力の絶対値は GPU と構成で水準が変わるため、「何W以上なら収まっている」という閾値としては使えない。同じカード・同じ文脈長で並べたものどうしを比べる材料としてだけ意味を持つ。
この組も、収まったかどうかを直接示す指標ではない。速度と消費電力が揃って落ちるのは VRAM から溢れたときに限らず、PCIe 越しの転送やCPU側の処理、電力や温度の制限、他のプロセスとの取り合いでも同じ形になる。本記事の測定では、同じカードで他の条件を揃えたうえで量子化や文脈長だけを動かしているため、この組の落ち方を収まりの手がかりとして使えた。手元で使うときも、他に思い当たる原因を潰したうえでの材料になる。
初版で速度が戻った原因は1つに絞れていない (作り直される前のファイルの話)
--parallel 1 は線形アテンション状態を449MiB減らすと同時に、スロット数も4から1に変える。作り直される前のファイルで速度が戻ったとき、この2つを分離していなかったため、原因をメモリ側だけに帰属させることはできなかった。絞れない代わりに、次の対照が使える。スロットの指定を変えずに文脈長だけ広げても同じ落ち方が出ることで、UD-Q3_K_XL を既定のまま文脈65,536で起動すると毎秒7.67トークン・72.2W まで落ちる (後掲の「文脈をどこまで伸ばせるか」の表)。速度と消費電力が揃って落ちるという型は、--parallel の有無とは独立に現れる。
もう1枚の16GB (RTX 5080) では結論が変わる
もう1枚の RTX 5080 では結果が違った。こちらはデスクトップ表示に使っている。RTX 5080 16GB (総量16,302MiB)、llama-server b10356、文脈4,096、-ngl 99、測り方は前節と同じ。生成速度は3回の測定の幅で示している。
| 量子化 | 設定 | 生成速度 | 消費電力 | nvidia-smi |
|---|---|---|---|---|
| UD-Q3_K_XL | 既定 (--parallel なし) |
毎秒52.52〜56.19トークン | 280.5W | 14,141MiB |
| UD-Q3_K_XL | --parallel 1 |
毎秒55.08〜56.15トークン | 306.5W | 13,692MiB |
| UD-IQ4_XS | 既定 (--parallel なし) |
毎秒48.96〜52.12トークン | 271.7W | 15,206MiB |
| UD-IQ4_XS | --parallel 1 |
毎秒46.75〜52.90トークン | 267.8W | 14,773MiB |
| UD-Q4_K_M | 既定 (--parallel なし) |
毎秒20.85〜21.50トークン | 168.9W | 15,708MiB |
| UD-Q4_K_M | --parallel 1 |
毎秒19.16〜21.75トークン | 165.2W | 15,727MiB |
表示に使っているカードは他のアプリの動きで空き容量が変わるため、遅い側は再現性そのものが低い。作り直される前のファイルでは Q4_K_M の --parallel 1 が毎秒9.84・8.75・5.16トークンと大きくばらついていた。作り直された後は同じ構成で毎秒19.16〜21.75トークンに収まっているが、他の2種の帯には依然として届かない。
UD-Q4_K_M は既定でも --parallel 1 でも、同じカードで UD-Q3_K_XL や UD-IQ4_XS が示す水準には戻らなかった。消費電力も168.9W・165.2W で、他の2種の267.8〜306.5W より低い。速度と消費電力が揃って動くという読み方は前節と同じだが、対照の取り方は違う。ここでは指定を変えた前後ではなく、同じカードで余裕のある2種が示す帯との比較になる。指定を変えても戻らないので、449MiBの増減では説明がつかない側にあると読める。このカードはデスクトップ表示に使っている状態で測っている。同じ量子化・同じ設定どうしで nvidia-smi の使用量を比べると、UD-Q3_K_XL と UD-IQ4_XS では5080側が1,349〜1,375MiB多い。ところが UD-Q4_K_M ではこの関係が崩れ、既定は5080側が88MiB少なく、--parallel 1 でも381MiB多いにとどまる。速度が出ていない側では使用量の差がこの範囲に収まらないため、カード間で引き算した値をそのまま「表示が保持している分」と読むことはできない。速度が出ている2種に限った差についても、表示によるものかカードごとの違いによるものかは分けていない。手元でどれだけ保持されているかは、推論を起動していない状態の nvidia-smi の使用量で確認できる。なお本記事は表示ありと表示なしが別のカードでの測定で、同じカードからモニタを外して前後を比べてはいない。
この落ち方がカード自体の基礎的な処理性能だけでは説明できないことは、余裕のある量子化どうしを比べると分かる。次は llama-bench b10356 / UD-Q3_K_XL / -ngl 99 / 各3回での測定。
| GPU | 深さ0のプロンプト処理 | 深さ0の生成 | 深さ8,192の生成 |
|---|---|---|---|
| RTX 5060 Ti 16GB | 毎秒959.96トークン | 毎秒28.25トークン | 毎秒26.17トークン |
| RTX 5080 16GB | 毎秒2029.98トークン | 毎秒53.71トークン | 毎秒53.56トークン |
表示がどれだけ保持しているかは環境で変わるため、量は記事の別の表で同じ構成どうしを比べた差として示している。
同じ表示ありのカードでも、llama-bench の深さ0の生成で毎秒53.71トークン、llama-server でも UD-Q3_K_XL なら毎秒52.52〜56.19トークン出ている。UD-Q4_K_M で毎秒20.85〜21.50トークンまで落ちるのは、カードの速さでは説明がつかない。llama-bench で測るとこの差はさらに開き、UD-Q4_K_M はプロンプト処理が毎秒159.01トークン (他の2種は毎秒2,029.98と2,209.56)、深さ8,192の生成が毎秒5.61トークン (同じく毎秒53.56と50.50) になる。この RTX 5080 で文脈4,096を確保したとき、速度が出たのは UD-IQ4_XS までだった。
配布元がファイルを作り直すと結論が変わる
ここまでの数値は2026年8月25日に取得したものだが、この記事の初版は8月15日に測っている。その間に配布元の unsloth がリポジトリを作り直しており、同じ16GBのカードで同じ量子化を指しているのに、収まるかどうかの結論が変わった。
何が起きたかを先に挙げる。8月19日から20日にかけて、非UD版の IQ4_XS と Q4_K_M は削除されて UD-IQ4_XS / UD-Q4_K_M に置き換わった。UD-Q3_K_XL はファイル名が変わらないまま中身が入れ替わっている。20日には imatrix (量子化の重み付けに使う校正データ) も同じリポジトリにアップロードされている。ただし配布元は作り直しの手順を明示していないため、この imatrix を使って量子化し直したのかどうかまでは本記事では判断しない。
| 量子化 | 初版が測ったファイル (8/15) | 現行のファイル (8/25) | 差 |
|---|---|---|---|
| UD-Q3_K_XL | 13,441,059,904バイト | 13,146,393,504バイト | -294,666,400バイト |
| IQ4_XS → UD-IQ4_XS | 15,705,861,088バイト | 14,252,845,984バイト | -1,453,015,104バイト |
| Q4_K_M → UD-Q4_K_M | 17,106,775,008バイト | 16,464,440,224バイト | -642,334,784バイト |
3種とも軽くなっている。効いたのは UD-Q4_K_M で、GPU上の重みが15,346MiBから14,674MiBへ672MiB減り、必要量の合計が16,326MiBから15,654MiBになった。カードの総量16,310MiBを挟んで、超える側から下回る側へ移っている。
同じ名前の量子化でも、いつ取得したかで別のファイルになる
本記事の初版が測った IQ4_XS と Q4_K_M は、配布元にもう存在しない。UD-Q3_K_XL は名前が同じまま中身が変わっているので、いま同じ名前で取得しても初版とは別の重みになる。手元のファイルが記事と同じものかを確かめるには、名前ではなくバイト数か、配布元が公開している sha256 を見ることになる。上の表に初版が測ったバイト数を載せてあるのはそのためで、一致しなければ別のファイルを測っていることになる。
結論がどう変わったかは、同じ表を並べると早い。RTX 5060 Ti・文脈4,096・-ngl 99 で、初版では既定と --parallel 1 の間に大きな差が出ていた量子化が、現行では差がなくなっている。
初版 (2026年8月15日・作り直される前のファイル) の測定値
以下は配布元が作り直す前のファイルでの測定で、いまは同じファイルを入手できないため追試できない。現行の値と取り違えないよう畳んである。RTX 5060 Ti 16GB (画面出力なし)、llama-server b10356、文脈4,096、-ngl 99、測り方は本文と同じ。
| 量子化 | 設定 | 生成速度 | GPU使用率 | 消費電力 | nvidia-smi |
|---|---|---|---|---|---|
| UD-Q3_K_XL | 既定 (--parallel なし) |
毎秒28.64トークン | 97% | 164.4W | 13,216MiB |
| UD-Q3_K_XL | --parallel 1 |
毎秒28.65トークン | 98% | 166.1W | 12,766MiB |
| IQ4_XS | 既定 (--parallel なし) |
毎秒25.64トークン | 98% | 152.2W | 15,226MiB |
| IQ4_XS | --parallel 1 |
毎秒25.67トークン | 98% | 153.1W | 14,776MiB |
| Q4_K_M | 既定 (--parallel なし) |
毎秒5.44トークン | 99% | 64.7W | 16,026MiB |
| Q4_K_M | --parallel 1 |
毎秒23.63トークン | 98% | 162.4W | 16,024MiB |
Q4_K_M の行だけが大きく動いており、既定では毎秒5.44トークン・64.7W、--parallel 1 を付けると毎秒23.63トークン・162.4W になった。速度と消費電力が揃って落ち、揃って戻る。これが「収まっていない」ことの根拠だった。
同じ日の RTX 5080 (デスクトップ表示に使用中・総量16,302MiB) では次のようになっていた。
| 量子化 | 設定 | 生成速度 | 消費電力 | nvidia-smi |
|---|---|---|---|---|
| UD-Q3_K_XL | 既定 (--parallel なし) |
毎秒50.11〜50.58トークン | 268.9W | 13,816MiB |
| UD-Q3_K_XL | --parallel 1 |
毎秒50.69〜52.11トークン | 280.2W | 13,366MiB |
| IQ4_XS | 既定 (--parallel なし) |
毎秒45.74〜46.82トークン | 274.9W | 15,797MiB |
| IQ4_XS | --parallel 1 |
毎秒46.17〜47.83トークン | 289.9W | 15,365MiB |
| Q4_K_M | 既定 (--parallel なし) |
毎秒4.30〜9.20トークン | 105.6W | 15,881MiB |
| Q4_K_M | --parallel 1 |
毎秒5.16〜9.84トークン | 120.0W | 15,904MiB |
初版の必要メモリの内訳は、UD-Q3_K_XL が重み12,088MiB・合計13,068MiB、IQ4_XS が重み14,032MiB・合計15,012MiB、Q4_K_M が重み15,346MiB・合計16,326MiB (いずれも文脈4,096・既定の起動指定・起動ログより)。配布ファイルはそれぞれ12,818MiB・14,978MiB・16,314MiBだった。
初版で --parallel 1 を勧める根拠になっていた差は、現行のファイルでは消えている。一方で RTX 5080 の側は、作り直された後も他の2種の速度帯に届かないままで、「公称の容量が同じでも、カードによって選べる量子化が変わる」という本記事の見立ては変わっていない。
ここから引ける実務的な含意が1つある。量子化ファイルの測定結果は、モデル名と量子化名だけでは特定できない。配布元が同じ名前で中身を差し替えることがあるためで、他所の実測値を手元の判断に使うときは、いつ取得したファイルの話なのかまで見ないと噛み合わない。本記事が測定日とバイト数を併記しているのはそのためになる。
文脈をどこまで伸ばせるか
公式の model card と config.json によれば、Qwen3.8-27B はネイティブで262,144トークンの文脈長を持ち、YaRN による100万トークンへの拡張にも言及がある。以下で扱うのは、起動時に枠として確保できた範囲と、そのときの速度の実測で、拡張側については検証していない。
まず枠の大きさとメモリの関係から。起動ログが示すKVキャッシュと線形アテンション状態のサイズで、量子化によらず同じ値になる (RTX 5060 Ti)。
| 文脈長 | KVキャッシュ | 線形アテンション状態 |
|---|---|---|
| 4,096 | 256MiB | 598.5MiB |
| 16,384 | 1,024MiB | 598.5MiB |
| 32,768 | 2,048MiB | 598.5MiB |
| 65,536 | 4,096MiB | 598.5MiB |
| 131,072 | 8,192MiB | 598.5MiB |
| 262,144 | 16,384MiB | 598.5MiB |
KVキャッシュはf16での値。線形アテンション状態の値はスロット数4(--parallel を指定しないときの既定)のもので、--parallel 1 では149.6MiBになる。
KVは文脈長に比例して増え、線形アテンション状態は動かない。増えるのはKV側だけなので、長文を狙うほど16層分のKVがそのまま効いてくる。KVキャッシュが文脈長でどう増えるかという一般的な挙動はローカルLLMで長文を扱うとVRAMはどれだけ増えるかで扱っている。
次に、枠を広げたときの速度。UD-Q3_K_XL を RTX 5060 Ti で動かし、測り方は前節と同じ。
| 文脈長 | 設定 | 生成速度 | GPU使用率 | 消費電力 | nvidia-smi |
|---|---|---|---|---|---|
| 4,096 | 既定 | 毎秒29.02トークン | 98% | 171.2W | 12,792MiB |
| 32,768 | --parallel 1 |
毎秒28.77トークン | 98% | 168.5W | 14,162MiB |
| 65,536 | 既定 | 毎秒7.67トークン | 99% | 72.2W | 16,032MiB |
ここでの文脈長は起動時に確保される枠のことで、実際に長文を流し込んだ結果ではない。VRAM の余裕を超えるところまで枠を広げると、長文を実際に入力していなくても速度が落ちうる、ということを示している。起動指定を揃えて比べられるのは既定どうしの1行目と3行目で、4,096 では全速、65,536 で落ちた。
対照になっているのは1行目と3行目で、量子化も起動指定も同じまま文脈長だけが違う。この2行の間で速度と消費電力が揃って落ちている。一方でGPU使用率は98%から99%へ上がった。nvidia-smi の表示も12,792MiBから16,032MiBへ増えているが、これは枠を広げたぶんKVキャッシュの確保が増えただけで、その確保が実際にカードに載ったかどうかとは別の話になる。確保しようとした量は分かっても、載ったかは分からない。落ちていることを示すのは速度と消費電力の側だけになる。2行目は --parallel 1 なのでスロットの条件が違い、1行目や3行目と直接比べる行ではない。同じ量子化でも、枠の取り方しだいで速い側にも遅い側にも入る。
UD-IQ4_XS で --parallel 1 を付けたときの到達点も測った。
| 文脈長 | 生成速度 | GPU使用率 | 消費電力 | nvidia-smi |
|---|---|---|---|---|
| 8,192 | 毎秒27.41トークン | 97% | 160.1W | 13,658MiB |
| 16,384 | 毎秒27.46トークン | 97% | 163.5W | 14,178MiB |
| 24,576 | 毎秒27.44トークン | 98% | 163.0W | 14,698MiB |
24,576より上は測っていない。
3つの枠で生成速度も消費電力もほとんど動かず、nvidia-smi の表示だけが14,698MiBまで上がった。24,576 が限界という意味ではなく、そこから上を測っていないというだけになる。作り直される前のファイルでは同じ3つの枠で表示が16,012MiBまで上がっており、上限に近い側で回っていた。
なお、-c を指定せずに起動すると llama.cpp が文脈長を自動で決める。その値と、実測で速度が落ちなかった枠を並べると差がある。
| 量子化 | 自動で選ばれた文脈長 | 実測で全速だった文脈長 |
|---|---|---|
| UD-Q3_K_XL | 18,176 | 32,768 |
| UD-IQ4_XS | 4,096 | 24,576 |
| UD-Q4_K_M | 4,096 | 4,096 |
自動で決まる値は llama.cpp 側の見積もりに基づく。ここでの自動値は --parallel を書かない既定のスロット数での値で、右列は UD-Q3_K_XL と UD-IQ4_XS が --parallel 1、UD-Q4_K_M は既定での実測になる。左右でスロット指定が違う行では、右列のほうが線形アテンション状態を449MiB少なく確保しているぶん有利になる。この449MiBがどれだけの文脈長に化けるかは測っていないので、差のどこまでがスロット指定によるもので、どこからが見積もりの保守分なのかは分けられない。指定が揃っている UD-Q4_K_M では自動値と実測値が一致した。「実測で全速だった文脈長」は測った範囲の上端であって、そこが上限だと確かめたものではない。
起動できたことは載ったことを意味しない
起動ログには、収まっていないことを示す行が出たうえで起動が完了するという場面がある。RTX 5060 Ti で実際に出た行を挙げる。
- 文脈131,072で起動したとき、必要量20,711MiBに対し空きは14,572MiBだと表示し、7,163MiB減らす必要があると出したうえで起動が完了した (超過分は6,139MiBで、llama.cpp が別に1,024MiBの空きを残そうとするため、減らすよう求める量はその分だけ大きくなる)
- 同じ起動で「66層すべてをGPUへ配置した」旨の行が出た。これは収まったことを意味しない
- GGUFに含まれるマルチトークン予測用の層のテンソルは読み飛ばされた (投機デコードを有効にしていないため)
- 2枚構成でUD-IQ4_XSとUD-Q4_K_Mを文脈262,144で起動したときは、確保に失敗して起動そのものが止まった (前者は計算バッファ、後者はKVキャッシュ)
起動ログの既定の詳細度ではこれらの行は表示されない。-lv 4 を付けて初めて出る。
2行目の「66層」は、config.json のテキスト64層とは数え方が違う。何をどう数えて66になっているかは確認していないため、内訳には踏み込まない。4行目は、足りないと表示されても起動が続く1行目とは逆に、確保の失敗で止まった例になる。ただし1行目は UD-Q3_K_XL・文脈131,072の1枚構成、4行目は UD-IQ4_XS と UD-Q4_K_M・文脈262,144の2枚構成で、量子化も文脈長も違う。同じ構成を1枚と2枚で並べた測定はしていないため、何が分かれ目になったかは特定できていない。
ここで厄介なのが「空き」の数字で、同じカードについても、出どころの違う値が複数ある。UD-Q3_K_XL を起動したときの値を並べる (RTX 5060 Ti・画面出力なし)。
| 数字の出どころ | 値 |
|---|---|
| カードの総量 | 16,310MiB |
| llama.cpp がデバイス一覧で表示する空き | 15,172MiB |
llama.cpp が収まり判定に使う空き (--parallel なし) |
14,572MiB |
llama.cpp が収まり判定に使う空き (--parallel 1) |
15,022MiB |
| 溢れた構成で nvidia-smi が示す上限 | 16,032〜16,040MiBで頭打ち |
同じカードでも、起動指定を変えると llama.cpp が判定に使う空きは450MiB動いた (--parallel の有無は別々の起動なので、同一時点の値ではない)。差は線形アテンション状態のサイズとほぼ一致するが、llama.cpp 内部の会計がどうなっているかまでは確認していない。
この表の値は、どれも「このカードで使えるVRAMの量」としてそのまま読めるものではない。デバイス一覧に出る空き15,172MiBと収まり判定に使う空き14,572MiBは600MiB違い、しかも後者は起動指定で動く。したがって、必要量が空きを超えた構成について、超過分を計算して「449MiB減らせば足りる」と決めることもできない。カードの総量から引くか、判定に使う空きから引くかで結論が変わり、内部の会計は確認していないためどちらが正しい引き算かも決められない。推論を常駐させたまま他のAI作業を回す場合にVRAMがどう取り合いになるかはローカルLLM常駐時のVRAM配分｜他のAI作業と同時に回すと重みとKVキャッシュで詰まるで扱っている。
nvidia-smi の表示も同様に判定には使えない。このカードでは、溢れた構成の表示が16,032〜16,040MiBで頭打ちになる。ただし同じ帯の中に速度が出ている構成も並ぶ。頭打ちの位置自体もカードで違い、RTX 5080 では遅い側が15,708〜15,727MiBだった。作り直される前のファイルでは、Q4_K_M に --parallel 1 を付けた構成が16,024MiB、IQ4_XS を文脈24,576で起動した構成が16,012MiB で、いずれも溢れている側と見分けがつかなかった。手元で判断するときは、同じカード・同じ文脈長で設定だけを変えた2回の測定を並べ、生成速度と消費電力が揃って落ちるかどうかを見ると、今回の測定では明瞭に分かれた。ただし速度と消費電力が揃って落ちること自体は、VRAM から溢れた場合だけに起きる現象ではない。PCIe 越しの転送やCPU側の処理、電力や温度の制限、他のプロセスとの取り合いでも同じ形になりうるので、他の原因を潰したうえでの材料として扱うことになる。
2枚構成にすると何が変わるか
RTX 5080 (PCIe gen5 x16) と、OCuLink 経由の RTX 5060 Ti (PCIe gen4 x4) の2枚構成でも測った。llama-bench b10356、-ngl 99、深さ0、各3回、llama.cppの既定の分け方(層単位)。
| 量子化 | プロンプト処理 | 生成 |
|---|---|---|
| UD-Q3_K_XL | 毎秒1351.57トークン | 毎秒36.60トークン |
| UD-IQ4_XS | 毎秒1368.90トークン | 毎秒34.18トークン |
| UD-Q4_K_M | 毎秒1362.68トークン | 毎秒31.54トークン |
2枚に分けると重み・KVキャッシュ・線形アテンション状態のすべてが両方のカードに分かれる。カードごとの配分量は後掲の表のとおりで、均等に割れるのは KVキャッシュ、重みは均等ではない。
3種とも同じ帯の速度になり、1枚の RTX 5080 では他の2種に届かなかった UD-Q4_K_M も、2枚に分ければ並ぶ。ただしこの表は llama-bench での測定で、llama-server のスロットの指定 (--parallel) は関わらない。2枚構成で llama-server を既定のまま起動したときに UD-Q4_K_M がどうなるかは測っていない。UD-Q3_K_XL で比べると、同じ llama-bench の測り方で 5060 Ti 単体の毎秒28.25トークンより速く、5080 単体の毎秒53.71トークンよりは遅い位置になる。
配分は次のようになっていた (UD-Q3_K_XL / --parallel なし / 起動ログが示すカードごとの確保量)。
| 確保するもの | RTX 5080側 | RTX 5060 Ti側 | 備考 |
|---|---|---|---|
| 重み | 5,266.01MiB | 6,405.15MiB | 1枚のときの合計11,671MiBが分かれたもの |
| 線形アテンション状態 | 311.72MiB | 286.78MiB | 1枚のときの598.5MiBが分かれたもの |
| KVキャッシュ (文脈32,768) | 1,024MiB | 1,024MiB | 1枚のときの2,048MiBが分かれたもの |
| KVキャッシュ (文脈262,144) | 8,192MiB | 8,192MiB | 1枚のときの16,384MiBが分かれたもの |
llama.cpp の既定の分け方(層単位)での配分。層が何層ずつ割り当てられたかは起動ログに出ないため確認していない。配分の決まり方も確認していない。
長文側の到達点は量子化で分かれた。UD-Q3_K_XL は文脈262,144の枠でも生成が回った一方、UD-IQ4_XS と UD-Q4_K_M を同じ枠で起動したときは確保に失敗して起動が止まっている。ただし UD-Q3_K_XL も無傷で通ったわけではなく、この枠では2枚目の計算バッファ1,186MiBの確保に一度失敗したうえで、llama.cpp が小さいバッファで取り直して起動している。起動ログにエラー行が出ていても最終的に回ることがある、という意味でこの節の主題と地続きになる。UD-Q3_K_XL で長い枠を取ったときの値が次の表で、生成中に0.5秒間隔でサンプリングした中央値になる。
| 文脈長 | 生成速度 | RTX 5080側 | RTX 5060 Ti側 |
|---|---|---|---|
| 131,072 | 毎秒35.39トークン | 使用率31% / 127.9W / 11,646MiB | 使用率64% / 115.1W / 11,600MiB |
| 262,144 | 毎秒35.32トークン | 使用率28% / 129.8W / 15,141MiB | 使用率63% / 115.3W / 15,400MiB |
1枚構成の消費電力はカードごとに水準が違う。RTX 5060 Ti では速度が出ている側が158〜173W、文脈を広げて落ちた側が72Wだったが、同じ1枚構成でも RTX 5080 は速い側が268〜307W、遅い側が165〜169Wだった。2枚構成の127.9W・115.1W をこれらの帯と直接比べることはできない。カードで水準が違ううえ、重みが層単位で2枚に分かれているためになる。各カードが実際にどう動いているかまでは測っていない。2枚での判定は速度に拠っている。
2枚目のカードをホストへどうつなぐかという話はローカルLLMを2枚のGPUのVRAMプールで動かす｜OCuLink接続の帯域ボトルネックを見極めるで扱っている。
1枚で収めるか2枚にするか決めるなら16GBを1枚にするか、2枚で合計32GBにするか。必要なVRAM容量のまま、売っているグラフィックボードを厚み・補助電源・予算の上限から絞り込めます。
Qwen3.6-27Bから移る場合
両モデルの公式 config.json を2026年8月15日に比較すると、テキスト側のアーキテクチャは一致している。クラス名は Qwen3_5ForConditionalGeneration で共通し、層数64、hidden_size 5120、head_dim 256、full_attention_interval 4 のいずれも同じ。ヘッド数と語彙サイズも一致する。重みや学習内容が同じという意味ではなく、器の形が同じという話になる。
したがって、Qwen3.6-27B を動かしていた環境なら、必要量の内訳の読み方も、スロット数で線形アテンション状態が変わるという構造上の前提も共通する。一方で、量子化ごとのファイルサイズと重みの確保量はモデルごとに違うため、数字は取り直す必要がある。1世代前のモデルについてはQwen3.6-27Bとは？Dense 27BコーディングLLMをローカルGPUで動かすガイドで扱っている。
画像入力もllama.cppで動く
公式は Qwen3.8-27B を画像と動画の理解に対応したモデルとして公開しており、config.json にも vision_config が入っている。ここで確認したのは静止画1枚を llama.cpp 経由で読ませた場合だけになる。RTX 5060 Ti、llama-mtmd-cli、UD-Q3_K_XL と mmproj-F16.gguf、文脈8,192、900×520の検証用画像1枚での結果は次のとおり。
| 項目 | 結果 |
|---|---|
| 画像のエンコード時間 | 200ミリ秒 |
| 画像内の文字列の読み取り | 「VRAM CHECK 14572 MiB」「quant = IQ4_XS」「3 shapes: circle / square / triangle」「answer code: QW-38-27B-OK」をすべて正しく再現 |
| 図形の認識 | 赤い円・青い正方形・緑の三角形を左から右の順で正しく列挙 |
| 出力トークンの上限を200にしたとき | 思考部分で使い切り、可視の回答が途中で切れた |
読み取りの正確さは1枚の結果で、一般的な精度を示すものではない。
出力トークンの上限を200にしたときの結果は、思考モードの扱いに関係する。思考モードは既定で有効で、公式のチャットテンプレートは reasoning_effort の既定値を xhigh としている (GGUF に埋め込まれたチャットテンプレートの記述による。テンプレートを通すかどうかで効き方が変わる)。この画像入力の実行 (llama-mtmd-cli) がテンプレートを通す経路だったかは記録していないため、この観測を既定値と結びつけるところまでは踏み込めない。上限200での1回の実行では、思考部分で出力の枠を使い切り、可視の回答が途中で切れた。これは上限200での1点の観測で、上限一般の規則として測ったものではない。
よくある質問
配布ファイルが16.5GBの UD-Q4_K_M が、16GBのカードで起動できるのはなぜか
3つが重なっている。まず Hugging Face の表示は10進の GB で、本記事が llama.cpp や nvidia-smi から示す MiB とは基数が違う。16.5GBという表示は、実ファイル16,464,440,224バイトでは15,701MiBにあたる。次に、重みの一部 (量子化により521〜682MiB) はCPU側に残る。最後に、GGUFに入っているマルチトークン予測用の層のテンソルは、投機デコードを有効にしていない今回の起動では読み飛ばされる (334.7MiB)。突き合わせは「量子化3種の必要メモリ」の2つ目の表にある。ただし起動できることと速度が出ることは別で、RTX 5060 Ti・文脈4,096では既定のまま速度が出た一方、RTX 5080 では既定でも --parallel 1 でも他の2種と同じ速度帯には届かなかった。
手元が12GBや24GBのとき、この記事の数字はどう使えるか
その容量では測っていないため可否は示せないが、見積もりの材料にはなる。内訳表のGPU上の重み・KVキャッシュ・線形アテンション状態・計算バッファのうち、文脈長で動くのはKVキャッシュと計算バッファだけになる。KVの値を使いたい文脈長のもの (文脈長とKVの表) に差し替え、計算バッファは4,096で126MiB・262,144で378MiBの範囲で見る。線形アテンション状態は文脈長では動かず、--parallel 1 なら149.6MiBになる。ここまでは内訳表からの計算で出せる。モデルごとの必要メモリを容量別に並べた早見表は巨大オープンモデルは手元で動くのか比較｜GLM-5.2・Kimi K2.6・Qwen3.5 122Bの必要メモリ早見表にある。
一方で、その合計をカードの総量から単純に引いた判定はできない。llama.cpp が収まり判定に使う空きはカードの総量より小さく、しかも起動指定で動くためで、画面出力に使っているカードでは表示が保持している分もそこから減る。合計はどの量子化から試すかの当たりを付ける材料までで、最終的な可否は手元で確かめることになる。手順は「起動できたことは載ったことを意味しない」の末尾にある、同じカード・同じ文脈長で設定だけを変えた2回を並べる方法が使える。
--parallel 1 は常に付けておいてよいか
--parallel はスロット数の指定なので、1にすると枠は1つになる。速度の面では、作り直された後のファイルは文脈4,096 の測定では3種とも付けても付けなくても値がほとんど動かなかった。長い枠を測った表では --parallel 1 側の値を載せているので、枠を広げる場合まで「付けても付けなくても同じ」とは言えない。注意したいのは -c の割り当てのほうで、--parallel を書かない場合は1リクエストが4,096を使えたのに対し、--parallel 4 と明示すると同じ4スロットでも1,024に下がった。スロット数だけでなく、書き方によって1リクエストの取り分が変わる。
量子化を下げると品質はどれだけ落ちるか
本記事は品質を測っていないため、Qwen3.8-27B で具体的にどれだけ変わるかは示せない。一般には、量子化を下げるとVRAMに収まりやすくなる一方で生成の品質は落ちる方向にあるとされる、という傾向までしか言えない。ここで示せるのは、収まりと速度がどう変わるかだけになる。量子化をさらに下げて27B級を16GBに収める方向の話は量子化で27B級LLMはVRAM 16GBに載るか｜1bit・Ternary圧縮の実力と精度の代償で扱っている。
まとめ
16GB 1枚・文脈4,096・llama.cpp b10356 の範囲では、画面出力に使っていない RTX 5060 Ti で3種とも既定の起動指定のまま速度が出た。デスクトップ表示に使っている RTX 5080 では、速度が出たのは UD-IQ4_XS までで、UD-Q4_K_M はどちらの指定でも他の2種と同じ速度帯には届かなかった。公称の容量が同じでも、この2枚の間では選べる量子化が変わった。同じカードを表示あり・なしで測り分けてはいないため、型番・画面出力の有無・ホストとの接続方式のどれが効いたのかは分けられていない。
--parallel 1 を付けると、線形アテンション状態がスロット単位で確保されるぶん、文脈長を1トークンも削らずに起動時の必要量が449MiB動く。この構造は配布ファイルが作り直された後も変わっていない。効き目のほうは変わり、初回の測定では収まらない量子化を収める手段になっていた。いまの3種は RTX 5060 Ti・文脈4,096 ではどれも既定で収まるため、その条件では差が出ない。RTX 5080 の UD-Q4_K_M のように既定でも --parallel 1 でも速度帯に届かない側や、枠を広げた構成では話が別になる。文脈長は起動時に確保する枠のことで、実際に流し込んだ長さではない。枠を広げるだけでも速度は落ちる。
そしてこの記事の数字は、配布元がファイルを差し替えた時点で作り直しになる。同じ名前の量子化でも中身が変われば、16GBに収まるかどうかの結論まで変わった。判定の材料として本記事でいちばん有効だったのは生成速度と消費電力の組で、比べ方は2通りあった。同じカード・同じ量子化で設定だけを変えた前後の対照と、同じカード内で余裕のある量子化が示す帯との比較になる。起動が完了したこと・GPU使用率・nvidia-smi の表示は、どれも単独では根拠にならなかった。速度と消費電力が落ちる原因は VRAM 超過に限られないので、これも他の要因を潰したうえで使う材料になる。
16GBのカードで別の30B級モデルを測った記事にMuse Glimmer 30BをVRAM 16GBで動かすがある。
量子化を変えて必要メモリを詰める話の先に、モデルがVRAMに収まらなくなったときどうなるかがある。その境界の前後はNVIDIA DGX Sparkは買いかで実測している。
同じ3.8世代でも、名前だけ3.8を冠した第三者の4Bは中身が別物になる。土台のQwen3.5-4Bと同条件で測った結果は「Qwen3.8-4B」は使えるか｜土台のQwen3.5-4Bと同条件でRTX 5080/5060 Ti実測にまとめた。
この記事では MTP を無効・KVキャッシュを f16 のままで測っている。その2つを動かすと使用量と速度がどう変わるかはQwen3.8-27BのMTPは16GBで速くなるか｜有効化で増えるVRAMと、速くならない条件を実測で実測した。
同じ Qwen3.8-27B を NVFP4 の GGUF で動かし、この記事の UD-IQ4_XS と速さ・共有メモリへのあふれを比べた結果は、Qwen3.8-27BのNVFP4 GGUFをRTX 5080・5060 Tiで実測にまとめた。
参考資料
- Qwen3.8-27B 公式モデルカード (Hugging Face)
- Qwen3.8-27B config.json
- unsloth/Qwen3.8-27B-GGUF
- llama.cpp b10356 リリース
- llama-server のドキュメント (llama.cpp)
同じ Qwen3.8-27B を三値の重みへ置き換えた Bonsai 2 27B を、同じ RTX 5080 16GB で測った結果はBonsai 2 27BはVRAM 16GBで動くかにある (専用ビルドが要る点も含めて扱っている)。
同じ VRAM 16GB で、125B の Qwen3.8-Flash-Next を Strata でメインメモリと組み合わせて動かし、この 27B と速さや答えを比べた結果はStrataで125BのQwen3.8-Flash-NextをVRAM 16GBで実測にある。
