# Qwen3.8-27Bの必要VRAM：RTX 5090・GPU 2枚・量子化と262Kの設定 > RTX 5090の32GBでQwen3.8-27Bを使うなら、重みの量子化に加えてKVキャッシュとコンテキスト長の設定が重要です。実ファイルから必要メモリを計算し、1枚・2枚構成の起動例と262Kを実際に使えるか確かめる手順を紹介します。 - URL: https://blog.laozhang.ai/ja/posts/qwen3-8-27b-vram-guide - Published: 2026-09-06 - Updated: 2026-09-06 - Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about) - Topic: 開発ツールとエージェント - Tags: Qwen3.8-27B, 必要VRAM, RTX 5090, 量子化, KVキャッシュ --- **RTX 5090を1枚使う場合は、4ビット系の重みと短めのコンテキストから始めると、必要VRAMを切り分けやすくなります。** 262Kまで使うには、重みだけでなく、読み込んだトークンを保持するKVキャッシュも見積もる必要があります。GPUを2枚に増やしても、メモリが自動的に一つにつながるわけではありません。 Qwen3.8-27Bは画像も扱える稠密モデルで、標準の最大コンテキスト長は**262,144トークン**です。これは256×1,024であり、資料によって「262K」「256K」と表記されます。上限には入力と生成する出力の両方が含まれます。[公式モデルカード](https://huggingface.co/Qwen/Qwen3.8-27B) 以下では、2026年9月6日時点の配布ファイル、モデル設定からの計算値、開発元や実験者が公開した動作報告を区別して扱います。必要量の計算は推論用です。起動例の動作条件はそれぞれの公開資料に基づきます。 ## まず「空きVRAM」をGiBで確認する デスクトップ版RTX 5090の公称メモリは32GB GDDR7です。ノートPC用GPUとは仕様が異なり、NVLinkにも対応していません。[NVIDIAのRTX 5090仕様](https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/) 見積もりには、公称値ではなく次のコマンドで取得する空き容量を使います。 ```bash nvidia-smi --query-gpu=index,name,memory.total,memory.free --format=csv ``` 出力がMiBなら、1,024で割るとGiBになります。画面表示、ドライバー、ほかのGPUプロセスが使う分は、モデルに割り当てられません。GPUが2枚ある場合は、各カードの空き容量を記録してください。 この記事の表は、ファイル配布ページとの照合用にGB、メモリ計算用にGiBを使います。**1 GBは10億バイト、1 GiBは1,073,741,824バイト**です。「約16GBのファイルだから16GiB使う」と置き換えると、残り容量の計算がずれます。 ## 量子化した重みは何GiBあるか 公式BF16版のテンソルは合計55,562,855,904バイト、約51.75GiBです。32GBのカード1枚に全体を載せることはできません。これはモデルの索引に記載されたテンソル量であり、起動中のVRAM使用量ではありません。[BF16版の索引](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/model.safetensors.index.json) | 配布形式 | ファイル／テンソル量（GB） | GiB換算 | 見積もり上の注意 | |---|---:|---:|---| | 公式BF16 | 55.563 | 51.75 | 重みだけで32GBを超える | | 公式FP8 | 30.867 | 28.747 | 1枚ではKVと作業領域の余裕が小さい | | Unsloth UD-IQ4_XS GGUF | 14.253 | 13.274 | 対応する実行環境と用途別の品質確認が必要 | | Unsloth UD-Q4_K_M GGUF | 16.464 | 15.334 | 以下の1枚構成の計算例で使用 | | Unsloth UD-Q5_K_M GGUF | 19.772 | 18.414 | 4ビット系より重みの占有量が増える | | Unsloth UD-Q6_K GGUF | 21.984 | 20.474 | 長文用KVの余裕を別途確保する | | Unsloth Q8_0 GGUF | 29.047 | 27.052 | 1枚で長文を扱う際の制約が大きい | FP8は[公式FP8版の配布ファイル](https://huggingface.co/Qwen/Qwen3.8-27B-FP8/tree/main)の合計、GGUFは[Unslothの固定リビジョン](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/4ca720788d1e01f1bff70c033e0d0028fd02e502)の値です。FP8の容量がBF16のちょうど半分にならないのは、スケール値や量子化されない部分なども含まれるためです。 これらはダウンロード量を基にした見積もりで、ロード後の常駐量を保証しません。同じ「4ビット」でもGGUFとNVFP4では形式も実行経路も異なります。別の配布者のQ4_K_Mに、UD-Q4_K_Mの容量や品質をそのまま当てはめることもできません。 量子化の選択では、まず手元のメモリに収まる候補を絞り、次に手元の日本語文書、コード、数値抽出などで比較します。容量順に並べただけでは、誤答の増え方や長文からの情報抽出精度は判断できません。 ## 262KではKVキャッシュに何GiB必要か Qwen3.8-27Bは64層すべてに通常のKVキャッシュを保持する構成ではありません。48層が線形アテンション、16層がフルアテンションです。フルアテンション部分はKVヘッド数4、ヘッド次元256なので、KとVをF16またはBF16で保存する場合、1トークンあたりのデータ量は次のようになります。[公式config.json](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/config.json) ```text KとV × 層数 × KVヘッド数 × ヘッド次元 × 1要素のバイト数 = 2 × 16 × 4 × 256 × 2 = 65,536バイト = 64KiB／トークン ``` 64層をそのまま代入すると、この部分を4倍に見積もってしまいます。一方、線形アテンションにも状態を保持するメモリが必要です。「通常のKVが増えない層だからメモリはゼロ」とする計算も正しくありません。 以下は**1つの系列について、フルアテンション部分のKとVを両方保存する量**です。実行時の総使用量ではありません。 | 保存トークン数 | F16／BF16 | FP8の理想データ量 | llama.cpp q8_0 | llama.cpp q4_0 | |---:|---:|---:|---:|---:| | 32,768 | 2GiB | 1GiB | 1.0625GiB | 0.5625GiB | | 65,536 | 4GiB | 2GiB | 2.125GiB | 1.125GiB | | 131,072 | 8GiB | 4GiB | 4.25GiB | 2.25GiB | | 262,144 | 16GiB | 8GiB | 8.5GiB | 4.5GiB | llama.cppのq8_0は32要素あたり34バイト、q4_0は18バイトで、ブロックごとの付加情報を含みます。そのため、q8_0をFP8と同じ8GiB、q4_0を単純な4GiBとして扱うことはできません。[llama.cppのブロック定義](https://github.com/ggml-org/llama.cpp/blob/master/ggml/src/ggml-common.h) 重みを4ビットにしても、KVが自動的に4ビットになるとは限りません。重みの形式とKVの形式は別々に確認します。KVの量子化も結果に影響し得るため、収まることと、用途に十分な精度を保つことは別の確認項目です。 ### 重みとKVを足したあとにも余裕が必要 ピーク時の見積もりは、次のように分けると不足箇所を特定しやすくなります。 ```text 常駐する重み + フルアテンションのKVキャッシュ + 線形アテンションの状態 + 実行時の作業領域・活性値・CUDAグラフ + 必要に応じて画像処理・MTPの追加領域 ``` SGLangの資料ではGDNの状態1スロットにFP32で153.9MB、BF16で78.4MBという値が示されています。ただし、確保するスロット数や投機的デコードの中間状態は設定次第です。一定サイズの状態であっても、運用全体で無視できるとは限りません。[SGLangのQwen3.8-27B手順](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B) UD-Q4_K_Mの重み15.334GiBと262,144トークン分のKVを足すと、次のようになります。 | KVの形式 | 重み＋KV | 1枚のRTX 5090での判断 | |---|---:|---| | F16 | 31.334GiB | 追加領域の余裕がほぼなく、通常の全GPU実行用の見積もりとしては厳しい | | q8_0 | 23.834GiB | 残り容量から状態・作業領域を確保できるか確認する候補 | | q4_0 | 19.834GiB | メモリは減るが、実装対応と長文での品質確認が必要 | ![同じUD-Q4_K_Mの重みと262KのKVキャッシュを足したメモリ見積もりの比較](https://blog.laozhang.ai/posts/ja/qwen3-8-27b-vram-guide/img/quantized-kv-budget.webp) この表から「4ビットの重みなら262Kが必ず動く」とは言えません。逆に、F16のKVで不足しても、直ちにモデルをさらに小さく量子化する必要があるとは限りません。コンテキスト長、KVの形式、同時実行数のうち、用途上調整できる項目を先に選びます。 ## RTX 5090を1枚使うときの開始設定 最初はテキストのみ、同時実行1、32,768トークン程度に絞り、短い入力で応答を確認します。その後、65,536、131,072と段階的に伸ばすと、起動時の不足と長文処理時の不足を区別できます。以下は環境別の開始例であり、モデル形式を変えずに両方のコマンドを使い回すことはできません。 ### GGUFを使う場合 Qwen3.8-27Bに対応するllama.cppを用意し、先に`llama-server --version`と`llama-server --help`を確認します。次はダウンロード済みのUD-Q4_K_Mを指定する、文書化されたオプションに基づく設定例です。ファイルパスは実際の保存先に合わせてください。[llama-serverのオプション](https://github.com/ggml-org/llama.cpp/tree/master/tools/server) ```bash llama-server \ --model /models/Qwen3.8-27B-UD-Q4_K_M.gguf \ --n-gpu-layers 99 \ --ctx-size 32768 \ --parallel 1 \ --flash-attn on \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --host 127.0.0.1 \ --port 8080 ``` GPUへ載せる層数の指定は要求値です。起動ログで実際の配置、KVの形式、確保容量を確認します。長文で不足する場合は、まずコンテキストを短くして同じ入力が通るか調べます。CPUへのオフロードを使う場合はGPUへ載せる層数を減らせますが、システムRAMの余裕と、入力処理・生成の所要時間も再確認します。 ### NVFP4をvLLMで使う場合 vLLMのRTX 5090向けレシピには、Inferact版NVFP4、FP8のKV、32,768トークンの1枚構成が掲載されています。掲載環境ではCUDAグラフ確保時にメモリ不足が発生し、`--enforce-eager`で回避しています。これはその構成の報告であり、すべてのNVFP4環境に共通する条件ではありません。[vLLMの1枚構成](https://recipes.vllm.ai/Qwen/Qwen3.8-27B#1x-rtx-5090-nvfp4-needs-enforce-eager) ```bash vllm serve Inferact/Qwen3.8-27B-NVFP4 \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --kv-cache-dtype fp8 \ --enforce-eager \ --reasoning-parser qwen3 ``` 起動ログに十分なKV容量が表示されても、この32K設定を262Kに書き換えるだけで同じように動くとは限りません。実行環境の版、量子化モデル、グラフや同時実行の設定を記録して比較してください。 ## GPUを2枚にするときは分散方式を選ぶ 2枚構成が役立つのは、重みやKVを分散して、各カードに作業領域を残せる場合です。先に次のコマンドで接続関係を確認します。 ```bash nvidia-smi topo -m ``` RTX 5090同士でも、PCIeの接続経路やほかの機器との共有状態によってGPU間通信の条件が変わります。2枚の合計容量に収まることは、各カードへの配置に成功することや、生成速度が2倍になることを意味しません。 vLLMではテンソル並列を指定します。公式レシピの2枚構成は`0.26.1rc1.dev608+g99a10304d`で検証され、Unsloth NVFP4の起動時KVプールは920,517トークン、重みは1枚あたり10.64GiBと報告されています。これは確保できた容量の報告であり、262Kの入力処理を完走した速度測定ではありません。[vLLMの2枚構成](https://recipes.vllm.ai/Qwen/Qwen3.8-27B#2x-rtx-5090-consumer-blackwell-sm120) ```bash vllm serve unsloth/Qwen3.8-27B-NVFP4 \ --tensor-parallel-size 2 \ --max-model-len 262144 \ --kv-cache-dtype fp8 \ --reasoning-parser qwen3 ``` GGUFでは、先ほどのllama-server設定に`--split-mode layer --tensor-split 1,1`を加える方法があります。`layer`は層とKVを分割する方式です。`row`では中間結果とKVが主GPUに置かれるため、単に2枚を選べばKVも均等になるとは考えないでください。容量の異なるカードなら比率を調整し、実際の各GPU使用量で確認します。[llama-serverの分割方式](https://github.com/ggml-org/llama.cpp/tree/master/tools/server) フルコンテキストを想定すると、**BF16の重み約51.75GiB＋F16のKV 16GiB＝約67.75GiB**です。追加領域を入れる前から、32GBのカード2枚では不足します。また、24GBを2枚用意してQ8_0の重み27.052GiBとF16のKV 16GiBを載せる計算は、合計43.052GiBです。合計容量に余裕があるように見えても、片側に偏るメモリや作業領域まで収まる保証はありません。 ## 1枚で262Kという報告をどう再現するか MiaAI-Labには、RTX 5090を1枚使い、RadixArk版NVFP4で262,144トークンを設定する公開実験があります。ただし、条件は`vllm==0.27.1`に特定修正のバックポート、`turboquant_4bit_nc`、5.5GiBのKVプール、`max-num-seqs 1`、バッチ内トークン数512、MTP3という組み合わせです。通常のFP8 KVを指定する上の例とは別の構成です。[MiaAI-Labの再現手順](https://github.com/MiaAI-Lab/Qwen3.8-27B-NVFP4-RTX-5090) この報告は、指定されたソフトウェアと設定を再現するための参考になります。同リポジトリは、標準の実行経路で出力が崩れる問題や、MTPと同時実行の組み合わせでクラッシュする場合にも言及しています。実験を追うなら、指定された修正とモデル版を確認したうえで、短文での正常応答を先に確立します。公開された生成速度を、262Kの入力すべてを処理したときの速度やGPU購入の目安に転用することはできません。 長文対応の確認は、次の順で行います。 1. **入力と出力の枠を分けます。** 262,144トークンの上限で出力を8,192トークン残すなら、整形後の入力は最大253,952トークンです。システム指示やチャットテンプレートも入力に含めます。文字数から推測せず、実行環境と同じトークナイザーで数えます。 2. **実際に長い文書を送ります。** 上限値の設定だけで済ませず、切り捨てや自動短縮が起きていないことを、サーバー側の入力トークン数で確認します。 3. **入力処理と生成を両方完了させます。** 入力を読み込むプリフィルで停止する場合と、生成中に不足する場合を分け、各GPUのピーク使用量と所要時間を記録します。 4. **先頭・中央・末尾の情報を取り出させます。** 位置の離れた識別子や事実を入れ、回答が本文と一致するか調べます。長い入力を受理できても、必要な情報を取り出せなければ用途には不十分です。 5. **設定を変えたら同じ課題で比較します。** KVをq8_0からq4_0へ変更した場合などは、正答率、数値の転記、引用箇所の対応も見ます。次に本番の文書で確認します。 ![262Kの入力と出力の枠を分け、長文の処理と情報抽出の正確さを確認する手順](https://blog.laozhang.ai/posts/ja/qwen3-8-27b-vram-guide/img/long-context-validation.webp) SGLangの一般向けGPU設定でも、掲載された検証条件は入力8,192、出力1,024、同時実行1です。最大コンテキストの記載と、すべての構成を262Kで検証したことは同じではありません。[SGLangの検証条件](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B) ## 画像・同時実行・MTPを足す前に確認すること テキスト1件が通ったあとに、用途で必要な機能を一つずつ追加します。複数項目を同時に変更すると、メモリ不足や出力の変化を切り分けにくくなります。 **画像入力を使う場合**、GGUF版ではモデルに対応する画像用プロジェクターも必要です。Unslothの`mmproj-F16.gguf`は927,607,488バイト、約0.864GiBですが、これは画像処理時のピーク使用量ではありません。画像処理用の一時領域も見込み、実際に使う画像枚数と解像度で確認します。[Unslothの画像用ファイル](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/4ca720788d1e01f1bff70c033e0d0028fd02e502) **同時実行を増やす場合**、基本は同時に保持するトークンの合計でKVを計算します。たとえば131,072トークンの系列を2件保持すると、共有を考えないF16のフルアテンションKVは合計16GiBです。共通の接頭辞を再利用する実装があっても、実際に共有できることを確認するまでは削減分を見込まない方が確実です。線形アテンションの状態や実行用バッファーも増える場合があります。 **MTPを使う場合**、投機的デコードの追加領域と安定性を確認します。標準設定での品質とメモリ使用量を記録してから有効にし、同じ入力・出力長・同時実行数で比べます。短い対話での速度改善が、長文の読み込み時間も同じ割合で短縮するとは限りません。 ## メモリ不足になったら発生箇所で対処を分ける | 発生する場面 | 先に確認する項目 | 次の調整 | |---|---|---| | 重みの読み込み中 | 空きVRAM、モデルの正確な形式、GPUごとの配置 | より小さい重み、2枚への分散、CPUへのオフロードを検討 | | CUDAグラフの作成中 | 実行環境の版とグラフ設定 | 該当するvLLMの1枚構成では`--enforce-eager`を確認 | | KVの確保時 | 最大コンテキスト、K/Vの形式、同時実行数 | まず長さや同時実行数を減らし、KV量子化の対応を確認 | | 長文の読み込み中 | 入力トークン数、一度に処理する量、一時領域 | 実行環境で対応するバッチ設定を調整し、同じ文書で再確認 | | 画像やMTPを追加したあと | 追加モデル・状態・バッファーの使用量 | 追加した機能を一つずつ戻して原因を特定 | | 動くが回答が崩れる | 重みと実行環境の互換性、KV形式、モデル版 | 既知の対応構成へ戻し、短文と長文の品質を比較 | 27Bのメモリ調整では解決しない能力上の課題がある場合は、[Qwen3.8-Flash-Nextと27Bの選び方](https://blog.laozhang.ai/ja/posts/qwen3-8-flash-next-vs-qwen3-8-27b)で、モデルを変更する際の条件を比較できます。 ## 参考資料 本文で参照している外部ページを、登場順に並べています。最終更新日：2026-09-06。 - [公式モデルカード](https://huggingface.co/Qwen/Qwen3.8-27B) (huggingface.co) - [NVIDIAのRTX 5090仕様](https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/) (nvidia.com) - [BF16版の索引](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/model.safetensors.index.json) (huggingface.co) - [公式FP8版の配布ファイル](https://huggingface.co/Qwen/Qwen3.8-27B-FP8/tree/main) (huggingface.co) - [Unslothの固定リビジョン](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/4ca720788d1e01f1bff70c033e0d0028fd02e502) (huggingface.co) - [公式config.json](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/config.json) (huggingface.co) - [llama.cppのブロック定義](https://github.com/ggml-org/llama.cpp/blob/master/ggml/src/ggml-common.h) (github.com) - [SGLangのQwen3.8-27B手順](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B) (docs.sglang.io) - [llama-serverのオプション](https://github.com/ggml-org/llama.cpp/tree/master/tools/server) (github.com) - [vLLMの1枚構成](https://recipes.vllm.ai/Qwen/Qwen3.8-27B) (recipes.vllm.ai) - [MiaAI-Labの再現手順](https://github.com/MiaAI-Lab/Qwen3.8-27B-NVFP4-RTX-5090) (github.com)