この記事の要点
- 公称16GB 1枚でも、比べた2枚で結論が分かれた。画面出力に使っていない1枚 (RTX 5060 Ti) では文脈4,096 の枠で量子化3種とも速度が出て、いちばん重い Q4_K_M だけは起動時の指定が条件になる。表示に使っている1枚 (RTX 5080) では、同じ枠で届かない量子化があった。
- 起動が通ったことは VRAM に収まったことを意味しない。判別に使えたのは、同条件どうしを並べた生成速度と消費電力の組だけだった。GPU使用率も nvidia-smi の表示値も、この判別には使えない。
- 比べた2枚は型番・画面出力の有無・接続方式が同時に違うため、どれが結果を分けたかは切り分けていない。速度と消費電力の測定で、生成の品質は測っていない。
16GB 1枚で何が動いたか
公称16GBのカード2枚でも、結論が分かれた。文脈4,096・llama.cpp b10356・-ngl 99 での結果を量子化ごとにまとめると次のようになる。
| 量子化 | RTX 5060 Ti 16GB (画面出力なし) | RTX 5080 16GB (デスクトップ表示に使用中) |
|---|---|---|
| UD-Q3_K_XL | 既定の起動指定のまま速度が出た | 既定の起動指定のまま速度が出た |
| IQ4_XS | 既定の起動指定のまま速度が出た | 既定の起動指定のまま速度が出た |
| Q4_K_M | 既定では遅く、--parallel 1 を付けると速度が出た |
既定でも --parallel 1 でも、他の2種と同じ速度帯には届かなかった |
この2列は RTX 5060 Ti と RTX 5080 という別のカードで、しかも片方だけがデスクトップ表示に使われている。型番・画面出力の有無・ホストとの接続方式の3つが同時に違うため、どれが結果を分けたのかは本記事では分けられていない。手元のカードがどちらに近いかは、この3つで見当を付けることになる。
ここでの「速度が出た」は、同じカードで余裕のある量子化を動かしたときと同じ水準に並んだという意味で、絶対値はカードごとに違う。判定に使った数値は「速度と消費電力で『載ったか』を判定する」と「もう1枚の16GB (RTX 5080) では結論が変わる」の表に載せた。
この表は文脈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月15日に取得した。
推論エンジンは llama.cpp b10356 の CUDA ビルド。b10356 は Qwen3.8-27B の公開より前のビルドだが、GGUF が宣言するアーキテクチャ名が qwen35 で、Qwen3.5系として既に対応済みだったため、そのまま読み込めた。将来 GGUF 側の仕様が変わった場合までは保証しない。
モデルは unsloth が配布している GGUF を使った。Hugging Face 上の表示サイズは、2026年8月15日時点で UD-Q3_K_XL が13.4GB、IQ4_XS が15.7GB、Q4_K_M が17.1GB (配布側の再アップロードで変わりうる)。この表示は10進の GB で、llama.cpp や nvidia-smi が使う GiB とは基数が違う。同じ IQ4_XS のファイルが 15.7GB = 14.63GiB になるので、カードの容量と直接引き算するときは単位を揃える必要がある。オープンウェイトのライセンスは Apache-2.0 (2026年8月15日時点の 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-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 | 12,088MiB | 256MiB | 598.5MiB | 126MiB | 13,068MiB |
| IQ4_XS | 14,032MiB | 256MiB | 598.5MiB | 126MiB | 15,012MiB |
| Q4_K_M | 15,346MiB | 256MiB | 598.5MiB | 126MiB | 16,326MiB |
重みのうち521〜682MiBはCPU側に残るため、表のGPU側の値と配布ファイルのサイズは一致しない。計算バッファは文脈長を伸ばすと少しずつ増える(4,096で126MiB、262,144で378MiB)。
既定での Q4_K_M の合計は、カードの総量16,310MiB と同じ帯に並ぶ。ただしこの2つの差だけで収まりを判定することはできない。llama.cpp が収まり判定に使う空きはカードの総量とは別の数字で、その扱いは「起動できたことは載ったことを意味しない」で扱う。
--parallel 1 で線形アテンション状態が縮むと総量の下に入る。配布ファイルのサイズとGPU上の重みが一致しない理由は、突き合わせると分かれる。次の表は、配布ファイルの実バイト数と、起動ログが示す確保先を並べたもの (RTX 5060 Ti / 文脈4,096)。
| 量子化 | 配布ファイル | GPU上の重み | CPU側 | 読み飛ばされる分 | 残差 |
|---|---|---|---|---|---|
| UD-Q3_K_XL | 12,818MiB | 12,088MiB | 521MiB | 198.8MiB | 10.5MiB |
| IQ4_XS | 14,978MiB | 14,032MiB | 682MiB | 253.5MiB | 10.5MiB |
| Q4_K_M | 16,314MiB | 15,346MiB | 682MiB | 276.1MiB | 10.5MiB |
読み飛ばされる分は、GGUFに入っているマルチトークン予測用の層のテンソルを起動ログから合計したもの。残差は表のとおりどの量子化でも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 減れば足りるのかどうかは、この数字だけでは決まらない。何から引くかで結論が変わるためで、その事情は後の節で扱う。
速度と消費電力で「載ったか」を判定する
起動ログの数字だけでは収まったかどうかが決まらないため、同じ条件で並べた実測から判定した。RTX 5060 Ti 16GB (画面出力なし)、llama-server b10356、文脈4,096、-ngl 99。量子化3種それぞれについて、既定と --parallel 1 の2通りを測った。
| 量子化 | 設定 | 生成速度 | 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 |
生成トークン数は128を上限とした短い応答での測定。プロンプトの内容や長さを変えると値は動く。品質は測っていない。
この表で大きく動いたのは Q4_K_M だけで、毎秒5.44トークン・64.7W が毎秒23.63トークン・162.4W になった。UD-Q3_K_XL と IQ4_XS は同じ指定変更で毎秒28.64→28.65トークン、25.64→25.67トークンと、ほとんど動いていない。
ここで使えなかった指標が2つある。1つはGPU使用率で、どの量子化・どの指定でも97〜99%に並び、速い側と遅い側を区別できない。NVIDIA の定義では、この値は「直前のサンプリング期間のうち、1つ以上のカーネルが実行されていた時間の割合」であり、演算器を何パーセント使い切っているかや、処理がどれだけ進んでいるかを直接示す値ではない。定義の原文は NVIDIA の nvidia-smi ドキュメントにある。
もう1つは nvidia-smi のメモリ表示で、Q4_K_M は遅い側が16,026MiB、速い側が16,024MiB とほぼ同じ値を示す。上限付近ではどちらの状態も似た表示になるため、この数字を収まりの根拠には使えない。
残ったのが生成速度と消費電力の組で、遅い側では消費電力も一緒に下がる。ただし消費電力の絶対値は GPU と構成で水準が変わるため、「何W以上なら収まっている」という閾値としては使えない。同じカード・同じ文脈長で並べたものどうしを比べる材料としてだけ意味を持つ。
速度が戻った原因は1つに絞れていない
--parallel 1 は線形アテンション状態を449MiB減らすと同時に、スロット数も4から1に変える。この測定では2つを分離していないため、速度が戻った原因をメモリ側だけに帰属させることはできない。絞れない代わりに、次の2つの対照が使える。1つは、余裕のある UD-Q3_K_XL と IQ4_XS では同じスロット変更で速度がほとんど動かないこと。もう1つは、スロットの指定を変えずに文脈長だけ広げても同じ落ち方が出ることで、UD-Q3_K_XL を既定のまま文脈65,536で起動すると毎秒7.66トークン・70.0W まで落ちる (後掲の「文脈をどこまで伸ばせるか」の表)。速度と消費電力が揃って落ちるという型は、--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 なし) | 毎秒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 |
遅い側は3回の値のばらつきが大きい(Q4_K_M –parallel 1 で毎秒9.84・8.75・5.16トークン)。表示に使っているカードは他のアプリの動きで空き容量が変わるため、遅い側は再現性そのものが低い。速い側のばらつきは小さい。
Q4_K_M は既定でも --parallel 1 でも、同じカードで UD-Q3_K_XL や IQ4_XS が示す水準には戻らなかった。このカードはデスクトップ表示に使っている状態で測っている。同じ量子化・同じ設定どうしで nvidia-smi の使用量を比べると、5080側が571〜600MiB多い。この差が表示によるものか、カードごとの違いによるものかは分けていない。手元でどれだけ保持されているかは、推論を起動していない状態の nvidia-smi の使用量で確認できる。なお本記事は表示ありと表示なしが別のカードでの測定で、同じカードからモニタを外して前後を比べてはいない。
この落ち方がカード自体の基礎的な処理性能だけでは説明できないことは、余裕のある量子化どうしを比べると分かる。次は llama-bench b10356 / UD-Q3_K_XL / -ngl 99 / 各3回での測定。
| GPU | 深さ0のプロンプト処理 | 深さ0の生成 | 深さ8,192の生成 |
|---|---|---|---|
| RTX 5060 Ti 16GB | 毎秒987.35トークン | 毎秒28.61トークン | 毎秒27.63トークン |
| RTX 5080 16GB | 毎秒2088.02トークン | 毎秒52.69トークン | 毎秒51.05トークン |
RTX 5080はデスクトップ表示に使っているカードで、その状態での測定。表示がどれだけ保持しているかは環境で変わるため、量は記事の別の表で同じ構成どうしを比べた差として示している。
同じ表示ありのカードでも、llama-bench の深さ0の生成で毎秒52.69トークン、llama-server でも UD-Q3_K_XL なら毎秒50.11〜52.11トークン出ている。Q4_K_M で毎秒4.30〜9.20トークンまで落ちるのは、カードの速さでは説明がつかない。この RTX 5080 で文脈4,096を確保したとき、速度が出たのは IQ4_XS までだった。
文脈をどこまで伸ばせるか
公式の 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 で動かし、測り方は前節と同じ。
| 文脈長 | 設定 | 生成速度 | 消費電力 |
|---|---|---|---|
| 4,096 | 既定 | 毎秒28.64トークン | 164.4W |
| 32,768 | –parallel 1 | 毎秒28.65トークン | 166.0W |
| 65,536 | 既定 | 毎秒7.66トークン | 70.0W |
ここでの文脈長は起動時に確保される枠のことで、実際に長文を流し込んだ結果ではない。枠を大きく取るだけで速度が変わることを示している。
対照になっているのは1行目と3行目で、どちらも設定は既定 (スロット4) のまま文脈長だけが違う。この2行の間で速度と消費電力が揃って落ちている。2行目は --parallel 1 なのでスロットの条件が違い、1行目や3行目と直接比べる行ではない。同じ量子化でも、枠の取り方しだいで速い側にも遅い側にも入る。
IQ4_XS で --parallel 1 を付けたときの到達点も測った。
| 文脈長 | 生成速度 | 消費電力 | nvidia-smi |
|---|---|---|---|
| 8,192 | 毎秒25.68トークン | 152.1W | 15,036MiB |
| 16,384 | 毎秒25.63トークン | 153.0W | 15,556MiB |
| 24,576 | 毎秒25.67トークン | 153.5W | 16,012MiB |
枠として確保できた文脈長のことで、実際にその長さの入力を流し込んだ結果ではない。24,576より上は測っていない。
3つの枠で生成速度も消費電力もほとんど動かず、nvidia-smi の表示だけが16,012MiBまで上がった。24,576 が限界という意味ではなく、そこから上を測っていないというだけになる。
なお、-c を指定せずに起動すると llama.cpp が文脈長を自動で決める。その値と、実測で速度が落ちなかった枠を並べると差がある。
| 量子化 | 自動で選ばれた文脈長 | 実測で全速だった文脈長 |
|---|---|---|
| UD-Q3_K_XL | 11,520 | 32,768 |
| IQ4_XS | 4,096 | 24,576 |
| Q4_K_M | 4,096 | 4,096 |
自動で決まる値は llama.cpp 側の見積もりに基づく。同じ量子化でも、実測では自動値より長い文脈が全速で回った。なお「実測で全速だった文脈長」はいずれも --parallel 1 での値になる。Q4_K_M は同じ4,096でも既定では毎秒5.44トークンにとどまる。「実測で全速だった文脈長」は測った範囲の上端であって、そこが上限だと確かめたものではない。
起動できたことは載ったことを意味しない
起動ログには、収まっていないことを示す行が出たうえで起動が完了するという場面がある。RTX 5060 Ti で実際に出た行を挙げる。
- 文脈131,072で起動したとき、必要量21,128MiBに対し空きは14,572MiBだと表示し、6,556MiB足りないと出したうえで起動が完了した
- 同じ起動で「66層すべてをGPUへ配置した」旨の行が出た。これは収まったことを意味しない
- GGUFに含まれるマルチトークン予測用の層のテンソルは読み飛ばされた (投機デコードを有効にしていないため)
- 2枚構成でIQ4_XSとQ4_K_Mを文脈262,144で起動したときは、確保に失敗して起動そのものが止まった
起動ログの既定の詳細度ではこれらの行は表示されない。-lv 4 を付けて初めて出る。
2行目の「66層」は、config.json のテキスト64層とは数え方が違う。何をどう数えて66になっているかは確認していないため、内訳には踏み込まない。4行目は、足りないと表示されても起動が続く1行目とは逆に、確保の失敗で止まった例になる。ただし1行目は UD-Q3_K_XL・文脈131,072の1枚構成、4行目は IQ4_XS と 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,016〜16,032MiBで頭打ち |
同じカード・同じ瞬間でも、llama.cpp が判定に使う空きは –parallel の指定で450MiB動いた。差は線形アテンション状態のサイズとほぼ一致するが、llama.cpp 内部の会計がどうなっているかまでは確認していない。
この表の値は、どれも「このカードで使えるVRAMの量」としてそのまま読めるものではない。デバイス一覧に出る空き15,172MiBと収まり判定に使う空き14,572MiBは600MiB違い、しかも後者は起動指定で動く。したがって、前掲の必要量から超過分を計算して「449MiB減れば足りる」と決めることもできない。カードの総量から引くか、判定に使う空きから引くかで結論が変わり、内部の会計は確認していないためどちらが正しい引き算かも決められない。推論を常駐させたまま他のAI作業を回す場合にVRAMがどう取り合いになるかはローカルLLM常駐時のVRAM配分｜他のAI作業と同時に回すと重みとKVキャッシュで詰まるで扱っている。
nvidia-smi の表示も同様に判定には使えない。このカードでは、溢れた構成の表示が16,016〜16,032MiBで頭打ちになる。ただし同じ帯の中に速度が出ている構成も並ぶ。頭打ちの位置自体もカードで違い、RTX 5080 では遅い側が15,881〜15,904MiBだった。Q4_K_M に --parallel 1 を付けた構成が16,024MiB、IQ4_XS を文脈24,576で起動した構成が16,012MiB で、いずれも溢れている側と見分けがつかない。手元で判断するときは、同じカード・同じ文脈長で設定だけを変えた2回の測定を並べ、生成速度と消費電力が揃って落ちるかどうかを見るのが確実だった。
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 | 毎秒1380.38トークン | 毎秒35.88トークン |
| IQ4_XS | 毎秒1402.41トークン | 毎秒32.31トークン |
| Q4_K_M | 毎秒1249.90トークン | 毎秒30.04トークン |
2枚に分けると重み・KVキャッシュ・線形アテンション状態のすべてが両方のカードに分かれる。カードごとの配分量は後掲の表のとおりで、均等に割れるのは KVキャッシュ、重みは均等ではない。
3種とも同じ帯の速度になり、1枚の llama-server では既定のまま遅かった Q4_K_M も他の2種と並んだ。ただしこの表は llama-bench での測定で、llama-server のスロットの指定 (--parallel) は関わらない。2枚構成で llama-server を既定のまま起動したときに Q4_K_M がどうなるかは測っていない。UD-Q3_K_XL で比べると、同じ llama-bench の測り方で 5060 Ti 単体の毎秒28.61トークンより速く、5080 単体の毎秒52.69トークンよりは遅い位置になる。
配分は次のようになっていた (UD-Q3_K_XL / --parallel なし / 起動ログが示すカードごとの確保量)。
| 確保するもの | RTX 5080側 | RTX 5060 Ti側 | 備考 |
|---|---|---|---|
| 重み | 5,804.35MiB | 6,283.79MiB | 1枚のときの合計12,088MiBが分かれたもの |
| 線形アテンション状態 | 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の枠でも生成が回った一方、IQ4_XS と Q4_K_M を同じ枠で起動したときは確保に失敗して起動が止まっている。UD-Q3_K_XL で長い枠を取ったときの値が次の表で、生成中に0.5秒間隔でサンプリングした中央値になる。
| 文脈長 | 生成速度 | RTX 5080側 | RTX 5060 Ti側 |
|---|---|---|---|
| 131,072 | 毎秒35.88〜36.18トークン | 使用率29% / 136.3W / 11,721MiB | 使用率66% / 118.8W / 11,484MiB |
| 262,144 | 毎秒35.94〜36.15トークン | 使用率35% / 136.0W / 15,521MiB | 使用率63% / 118.4W / 15,284MiB |
1枚構成の消費電力はカードごとに水準が違う。RTX 5060 Ti では速度が出ている側が150〜166W、遅い側が65〜70Wだったが、同じ1枚構成でも RTX 5080 は速い側が269〜290W、遅い側が106〜120Wだった。2枚構成の136.3W・118.8W をこれらの帯と直接比べることはできない。カードで水準が違ううえ、重みが層単位で2枚に分かれているためになる。各カードが実際にどう動いているかまでは測っていない。2枚での判定は速度に拠っている。
2枚目のカードをホストへどうつなぐかという話はローカルLLMを2枚のGPUのVRAMプールで動かす｜OCuLink接続の帯域ボトルネックを見極めるで扱っている。
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枚での結果は次のとおり。
| 項目 | 結果 |
|---|---|
| 画像のエンコード時間 | 170ミリ秒 |
| 画像内の文字列の読み取り | 「VRAM CHECK 14572 MiB」「quant = IQ4_XS」「3 shapes: circle / square / triangle」「answer code: QW-38-27B-OK」をすべて正しく再現 |
| 図形の認識 | 赤い円・青い正方形・緑の三角形を左から右の順で正しく列挙 |
| 出力トークンの上限を200にしたとき | 思考部分で使い切り、可視の回答が途中で切れた |
静止画1枚のみの確認で、動画・複数枚・高解像度は測っていない。読み取りの正確さも1枚の結果で、一般的な精度を示すものではない。
出力トークンの上限を200にしたときの結果は、思考モードの扱いに関係する。思考モードは既定で有効で、公式のチャットテンプレートは reasoning_effort の既定値を xhigh としている (GGUF に埋め込まれたチャットテンプレートの記述による。テンプレートを通すかどうかで効き方が変わる)。この画像入力の実行 (llama-mtmd-cli) がテンプレートを通す経路だったかは記録していないため、この観測を既定値と結びつけるところまでは踏み込めない。上限200での1回の実行では、思考部分で出力の枠を使い切り、可視の回答が途中で切れた。これは上限200での1点の観測で、上限一般の規則として測ったものではない。
よくある質問
配布ファイルが17.1GBの Q4_K_M が、16GBのカードで起動できるのはなぜか
3つが重なっている。まず Hugging Face の表示は10進の GB で、llama.cpp や nvidia-smi が使う GiB とは基数が違う。次に、重みの一部 (量子化により521〜682MiB) はCPU側に残る。最後に、GGUFに入っているマルチトークン予測用の層のテンソルは、投機デコードを有効にしていない今回の起動では読み飛ばされる。突き合わせは「量子化3種の必要メモリ」の2つ目の表にある。ただし起動できることと速度が出ることは別で、RTX 5060 Ti・文脈4,096では --parallel 1 が条件になり、RTX 5080 では付けても他の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つになる。速度の面では、余裕のある UD-Q3_K_XL と IQ4_XS で付けても付けなくても値がほとんど動かなかったため、この測定の範囲では代償は見えていない。注意したいのは -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種とも起動し、Q4_K_M だけが --parallel 1 を付けたときに他の2種と同じ速度帯に入った。デスクトップ表示に使っている RTX 5080 では、速度が出たのは IQ4_XS までで、Q4_K_M はどちらの指定でも他の2種と同じ速度帯には届かなかった。公称の容量が同じでも、この2枚の間では選べる量子化が変わった。同じカードを表示あり・なしで測り分けてはいないため、型番・画面出力の有無・ホストとの接続方式のどれが効いたのかは分けられていない。
--parallel 1 を付けると、線形アテンション状態がスロット単位で確保されるぶん、文脈長を1トークンも削らずに起動時の必要量が449MiB動く。ただし同じ指定はスロット数も4から1に変えるため、速度が戻った原因をメモリ側だけに帰属させることはできない。文脈長は起動時に確保する枠のことで、実際に流し込んだ長さではない。枠を広げるだけでも速度は落ちる。
判定に使えたのは、同じカード・同じ文脈長で設定だけを変えた測定どうしの生成速度と消費電力の組で、起動が完了したこと・GPU使用率・nvidia-smi の表示のどれも単独では根拠にならなかった。16GBのカードで別の30B級モデルを測った記事にMuse Glimmer 30BをVRAM 16GBで動かすがある。
参考資料
- Qwen3.8-27B 公式モデルカード (Hugging Face)
- Qwen3.8-27B config.json
- unsloth/Qwen3.8-27B-GGUF
- llama.cpp b10356 リリース
- llama-server のドキュメント (llama.cpp)
量子化を変えて必要メモリを詰める話の先に、モデルがVRAMに収まらなくなったときどうなるかがある。その境界の前後はNVIDIA DGX Sparkは買いかで実測している。
同じ3.8世代でも、名前だけ3.8を冠した第三者の4Bは中身が別物になる。土台のQwen3.5-4Bと同条件で測った結果は「Qwen3.8-4B」は使えるか｜土台のQwen3.5-4Bと同条件でRTX 5080/5060 Ti実測にまとめた。
