Qwen3.8-27BをVRAM 16GBのGPU一枚で動かす — 量子化とキャッシュ設定で「32GB必要」の常識を覆す

8月23日、autodidacts.ioが「How to fit Qwen3.8-27B into 16GB of VRAM and run it on a single RTX 3080 card: the best quantizations and Llama.cpp flags I've found」と題した記事を公開した。この記事では、Qwen3.8-27BをVRAM 16GBのRTX 3080一枚で実用的に動かすための量子化選択とllama.cppフラグの設定について詳しく紹介されている。

27Bパラメータのモデルは「32GB以上のVRAM向け」というのが通説だ。公式のLlamaサイトもQ8以下の量子化へのリンクを張らず、Q4未満は「幼児と話しているようなもの」、KVキャッシュの量子化は「ロボトミー手術」と称されることが多い。それでもRTX 3080（VRAM 16GB）一枚で動かした記録がこの記事だ。

なお、Qwen3.8はAlibabaのQwenチームが開発するQwen3ファミリーの27Bパラメータモデルで、ハイブリッド推論（Thinking/非Thinkingモード切り替え）に対応した最新世代のオープンモデルだ。

結論から言う：UD-IQ3_XXSが正解

著者が試した量子化の遍歴はこうだ：

Q4_K_M → 遅すぎ、コンテキストの余裕もなし
IQ4_XS → 若干マシ、でも大差なし
UD-Q3_K_XL / UD-Q3_K_S → 平凡

そして最終的に行き着いたのが **UD-IQ3_XXS**（UnslothのDynamic v3量子化）だ。「UD-」プレフィックスはUnslothが開発した「Dynamic量子化」を指す。通常の均一量子化とは異なり、モデルの重みをレイヤーごとに重要度に応じて異なるビット幅で量子化することで、同じファイルサイズでも品質劣化を抑えられる手法だ。全レイヤーがGPUに乗り、生成速度も実用的で、コンテキストの余裕もある。ロードも速い。

品質面での劣化は「おそらくある」が、イテレーションを速く回せることで補えるという判断だ。より高品質が必要な場面では UD-Q5_K_M を --n-gpu-layers 24 で動かす選択肢もあるが、速度は大幅に落ちる。これは --n-gpu-layers 24 に設定した場合、モデルの全レイヤーがGPUに収まりきらず、残りのレイヤーがCPUで処理されるためだ。GPU↔CPU間のデータ転送がボトルネックになるため、全レイヤーをGPUに乗せた場合と比べて生成速度が著しく低下する。

肝はKVキャッシュの量子化とコンテキストサイズ

著者が実際に使っているllama-serverのコマンドはこれだ：

LLAMA_CACHE="models/" llama serve --model models/Qwen3.8-27B/Qwen3.8-27B-UD-IQ3_XXS.gguf \
--mmproj models/Qwen3.8-27B/mmproj-BF16.gguf \
--cache-type-k q4_0 --cache-type-v q4_0 \
--n-gpu-layers all --gpu-layers-draft all \
--flash-attn on \
--spec-type draft-mtp,ngram-mod --spec-draft-n-max 2 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.0 \
--temp 1.0 \
--ctx-size 32000

各フラグの中で特に重要なものを以下に整理する。

**--cache-type-k q4_0 --cache-type-v q4_0**（最重要その1）

KV（Key-Value）キャッシュ——Transformerがトークンの文脈情報を保持するバッファ——の量子化設定だ。これを下げるとVRAMが節約できるが、出力品質と速度がトレードオフになる。著者いわく「Qwenはアグレッシブなキャッシュ量子化に他のモデルより強い」。q8_0/q8_0 や q8_0/q4_0 を使う人も多い。KV量子化なしではコンテキスト上限が約32,000トークン止まりだが、q4_0にすることで128,000トークン以上を扱えるようになる。

なお、コマンド中の --mmproj フラグはマルチモーダル投影モデル（mmproj）のパスを指定するものだ。テキストとビジョンエンコーダーの特徴空間を橋渡しする役割を持つ。Qwen3.8-27BはVision対応モデルのため、テキスト専用で動かす場合は省略できる。

**--ctx-size 32000**（最重要その2）

コンテキストサイズは速度と品質に直結する。Qwen3.8は推論（Thinking）中にトークンを大量消費するため、デフォルトの約4,000トークンは話にならない。著者の推奨は：

一問一答なら16,000〜32,000
コーディングや長い対話なら64,000〜128,000
長いセッションでは、途中でサーバーを再起動してコンテキストを増やす運用が現実的

なお著者はUD-Q5_K_Mを使って36時間ぶっ通しで動かし続け（約1.5トークン/秒）、スクリプト生成を待ったエピソードも紹介している。ほぼ全時間が「思考中」だったという。

--spec-type draft-mtp,ngram-mod --spec-draft-n-max 2

Multi-Token Prediction（MTP）による投機的デコード。--spec-draft-n-max 2 が著者の見つけたスイートスポットで、ngram-mod の追加で数トークン/秒の上乗せが得られた。ただしVRAM消費は増える。

llama.cppのインストールとCUDAビルド

llama.cppは公式の curl | bash インストーラーも存在するが、著者はBlackwell（最新世代GPU）向けバイナリが届いたと報告している。Ampere世代（RTX 3080）で確実にCUDAサポートを得るにはソースビルドが確実だ：

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
sudo apt-get install libvulkan-dev glslc spirv-headers
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release
cp build/bin/llama "/home/$USER/.local/bin/llama"

NVIDIAドライバーは595-openを使用。610ドライバーでは動作しなかったという。

実測パフォーマンス

この構成で著者が得た生成速度は20〜30トークン/秒（コンテキスト長によって変動）。GPU使用状況の監視には btop が見やすいと紹介されている。

Qwen3.8の特徴として、推論中のself-talkが「原始的な洞窟人語」のようなスタイルになるという点も触れられている。トークン節約のためと著者は好意的に解釈しているが、量子化とは無関係のモデル固有の挙動だ。

詳細はHow to fit Qwen3.8-27B into 16GB of VRAM and run it on a single RTX 3080 card: the best quantizations and Llama.cpp flags I've foundを参照していただきたい。