Qwen 3.8 27B をローカルで動かす：17GBは総メモリ、VRAMではない

出回っている数字は17GBで、出どころはUnsloth自身のハードウェア表です。ただし表のヘッダーまで読むと、その数字が示すよりもずっと具体的なことが書かれています。単位は総メモリ、つまりRAMとVRAMの合計、あるいはユニファイドメモリです。この違いが、モデルがGPU上で動くのか、一部がマザーボード側で動くのかを分けます。

ローカルで動かせるもの、動かせないもの

24GBならQwenが想定した量子化が動き、16GBでは妥協版、それ未満なら手を出す価値はありません。 Qwenは Qwen3.8-27B をApache 2.0でHugging Faceに公開しました。27Bの密なビジョン言語モデルで、ネイティブコンテキストは262,144トークンです。問いが「どのデータセンターか」から「机の上のこのマシンに収まるか」へ移るくらいには小さい。2-bitでも256GBのMac Studioを要求するGLM 5.2とはまったく別の話です。要点から示します。

重みのライセンス：       Apache 2.0、商用利用可
パラメータ数：           27B密（llama.cppは27.32Bと表示）
ネイティブコンテキスト： 262,144トークン（YaRNで1Mまで）
最小の実用GGUF：         9.01 GB（Unsloth UD-IQ2_XXS）
4-bit GGUF：             配布元により16.81〜18.97 GB
ベンダーのメモリ指針：   2-bitで11〜13GB、4-bitで17〜19GB、RAM+VRAMの合計
視覚機能：               別途mmprojファイル、+0.63〜0.93GB（配布元による）
M2 Pro 16GB実測：        2-bitで生成7.11 tok/s、プロンプト74.59 tok/s
同一機の4-bit：          プロンプトは4倍遅く、生成は完全に失敗
セットアップ時間：       約20分、大半はダウンロード

このセットアップの後にできること：強力なコーディング・エージェントモデルをオフラインで、トークン課金なし、データを外に出さずに動かせます。できないこと：ホスト版のレイテンシに並ぶこと、コンシューマ機で256Kコンテキストをフルに使うこと、そしてMaxティアを使うこと。Maxにはそもそもオープンウェイトがありません。

正直な結論：Qwenが本来使わせたい量子化の入口は24GBカードであり、窮屈でなくなるのは32GBからです。16GB未満で問うべきなのは、どの量子化かではなく、そもそもローカル推論が正しい選択かどうかです。

Qwen 3.8 27Bには実際どれだけVRAMが必要か？

総メモリで11GBから19GB。この文で効いているのは「総」の一語です。 Unslothのハードウェア表は単位を明示しています。総メモリ、すなわちRAMとVRAMの合計、Appleシリコンではユニファイドメモリです。これはマシン全体に対する予算であって、グラフィックカードの仕様ではありません。

指針がファイルサイズより数GB上にあるのは、メモリに載るのがファイルだけではないからです。KVキャッシュ、計算バッファ、そしてOSがすでに握っている分にも払う必要があります。

誤読されやすいのはここです。同じUnslothのページの本文には、4-bitは「RTX 5080、4090、あるいは24GB RAMのMacのような17-19GB VRAMのほとんどのデバイスで動作する」と書かれています。しかし NVIDIA自身の比較ページによれば、RTX 5080のメモリは16GB GDDR7で、5070 Tiも同じく16GBです。4090が24GB、5090が32GBです。つまり5080における4-bitは、表のヘッダーが書いているとおり、カードとシステムRAMで満たす総メモリ予算であって、17GBがVRAMに収まっているわけではありません。それでも動きます。一部のレイヤーがPCIeバスの向こう側に置かれ、生成速度もそちらに引っ張られるだけです。

ルールを一つだけ覚えるならUnslothのものを使ってください。RAMとVRAMの合計は少なくとも量子化ファイルのサイズ以上にすること。さもなければ動きはしますが、ディスクへのページングでひどく遅くなります。

どのGGUF量子化をダウンロードすべきか？

2〜3GBの余裕が残る中で最大のファイルを選び、量子化名ではなくバイト数を比べてください。 名前はサイズではありません。このモデルにはQ4_K_Mという名のファイルを3社が出しており、互いに2.2GB離れています。同じラベルの下で各社がテンソルごとの精度を違う形で選んでいるためです。

16GBのカードではこの差がすべてを決めます。LM Studio版はUnslothより300MB、ggml-orgより2.2GB小さく、そのどれも量子化名からは見えません。

メモリ予算別の実用的な選択：

• 32GB以上：UD-Q4_K_XL 17.92 GB、あるいは余裕をコンテキストではなく精度に使うなら Q6_K 22.88 GB。
• 24GB：lmstudio-communityの Q4_K_M 16.81 GB。KVキャッシュに最も余地が残ります。
• 16GB：UD-Q3_K_XL 13.44 GB。作業の余地を残して収まります。4-bitのファイルはオフロードなしでは収まりません。
• 16GBユニファイドメモリのMac：UD-IQ2_XXS 9.01 GB。これが下限で、下限であることは体感できます。

UnslothのUD接頭辞は動的量子化を示し、一律に量子化するのではなく感度の高いレイヤーを高精度のまま残します。2-bitや3-bitの領域では、これが公称ビット数より効きます。

Qwen 3.8 27Bをローカルで動かす価値があるのはどんなときか？

データが社外に出せないとき、あるいはGPUを償却できるほど使用量が多いときです。 それ以外ではホスト版のほうが安く、しかもかなり速い。

ローカル構成が向くケース：

1. 第三者推論を禁じる契約下のコードや文書を扱っている。
2. すでに24GBか32GBのGPUを持っていて、日常のリファクタリングやレビューでトークン課金をやめたい。
3. オフラインで必要になる。機内、エアギャップされたラボ、あるいは自分の管理下にないネットワークの内側で。

ローカル構成が向かないケース：

1. カードが12GB以下。収まる量子化はセットアップの手間に見合う品質ではありません。
2. このファミリーの頂点が欲しい。Qwen3.8-MaxはAPI専用でオープンウェイトがなく、2.4T-A95Bという兄弟モデルは1-bitでも397GB必要です。
3. 長時間のエージェント実行をしたい。後述する実リクエストでの2.91 tok/sでは、ホストモデルが4分で終える作業に1時間近くかかります。

打ち切りの基準： 下の手順4まで進めて、実際に使うコンテキスト長で生成が5 tok/s未満なら、チューニングはやめてください。そのマシンはこのモデルのホストに向いておらず、どのフラグでも桁は変わりません。

Qwen 3.8 27Bはどんなハードウェアで動くか？

24GBのGPUか32GBのMacが快適な入口で、16GBは妥協つきで動きます。 カードそのものより、総メモリプールとその帯域のほうが効きます。

ソフトウェア側では、llama.cppは思われているほど障害になりません。config.json のアーキテクチャ文字列は qwen3_5 で、llama.cppは2026年2月に PR #19435 が密モデルとMoEのサポートを入れて以来このファミリーに対応しています。ここで実際に試しました。ビルド b10375 は2026-08-12 12:18 UTCに公開されており、重み自体が翌日08:23 UTCにHugging Faceへ現れるより前ですが、文句なくロードして動きます。つまり「llama.cppを更新する」が本当の解になることはまれで、Qwen 3.5や3.6を動かせた程度に新しいビルドならこれも動きます。macOSでは brew install llama.cpp で十分新しく、LinuxとWindowsではリリースバイナリを取るかソースからビルドしてください。

どのベンダーの表にも載っていないAppleシリコンの詳細が一つあります。macOSはメモリプール全体をGPUに渡しません。この記事で使った16GBのM2 Proでは、llama.cppが起動時にMetalの上限をそのまま出力しました。

ggml_metal_device_init: has unified memory    = true
ggml_metal_device_init: recommendedMaxWorkingSetSize  = 12713.12 MB

16GBではなく12.71GBです。この1行がどのMacでもどの量子化が候補になるかを決めるので、17GBの重みをダウンロードする前に読む価値があります。

llama.cppでQwen 3.8 27Bをどう動かすか？

5ステップ、遅いのはダウンロードです。 以下はすべて前述のM2 Proで実行しました。

ステップ1：llama.cppをインストールする

brew install llama.cpp
llama-cli --version

期待される結果：ビルド文字列。手元では b10450-ece963f41 でした。前述のとおり2026年のビルドならほぼ何でも動きます。

ステップ2：量子化を選び、自分の上限と照らす

curl -s "https://huggingface.co/api/models/unsloth/Qwen3.8-27B-GGUF/tree/main" \
  | python3 -c "import json,sys;[print(f\"{f['path']:32s}{f['size']/1e9:6.2f} GB\") for f in json.load(sys.stdin) if f['path'].endswith('.gguf')]"

期待される結果：バイト単位で正確なサイズ付きの全ファイル一覧。カードではなく総メモリと比べてください。

ステップ3：重みをダウンロードする

curl -L -o qwen38-27b.gguf \
  "https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/resolve/main/Qwen3.8-27B-UD-Q3_K_XL.gguf"

期待される結果：1ファイル、このサイズなら分割はありません。ステップ2で選んだ量子化にファイル名を差し替えてください。

ステップ4：実行する

llama-server -m qwen38-27b.gguf -c 16384 \
  --temp 1.0 --top-p 0.95 --top-k 20 --port 8080

期待される結果：localhost:8080 にOpenAI互換エンドポイント。このサンプリング値はQwenが公開している思考モード向けの設定です。非思考モードでは --temp 0.7 --top-p 0.80 --top-k 20 --presence-penalty 1.5 を使ってください。

ステップ5：必要なら視覚機能を足す

ベースGGUFはテキスト専用です。単体でロードするとllama.cppは modalities : text と表示してそう伝えます。視覚側は別のプロジェクターファイルにあります。

curl -L -o mmproj.gguf \
  "https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/resolve/main/mmproj-F16.gguf"
llama-server -m qwen38-27b.gguf --mmproj mmproj.gguf -c 16384 --port 8080

期待される結果：画像入力を受け付けます。このF16プロジェクターには0.93GBを見込んでください。重みの上に積まれるもので、当初見積もった数字の内側ではありません。より小さい0.63GBのQ8_0プロジェクターが欲しい場合、3つの配布元のうち出しているのはggml-orgだけなので、重みとは別のリポジトリから取ることになります。

16GBのMacでQwen 3.8 27Bはどれくらい速いか？

2-bitで毎秒7.11トークン、そして4-bitファイルはそもそも生成しません。 前述のM2 Pro、llama.cpp b10450 で llama-bench を使い、同一マシンで両方の量子化を測りました。

腰を据えて見る価値があるのは4-bitの行です。ファイルはロードされます。パラメータ数も正しく報告されます。プロンプト処理も走ります。2-bitの4倍遅いのは、重みが12.71GBのMetalワーキングセットに収まらなくなりマシンがページングしているからです。そして生成は failed to decode generation batch, res = -3 で落ちます。llama.cppのヘッダーは-1未満の戻り値を致命的エラーと定義しており、これは大きすぎるバッチで出る通常の「KVスロットが見つからない」を意味する戻り値1とは別物です。このハードウェアではベンダーのメモリ数値を下回っても緩やかには劣化しません。半分だけ完了したベンチマークが得られるだけです。

これらはコンテキストゼロの合成値です。実際の数字はもっと悪い。同じ2-bitモデルを llama-server で -c 16384 として提供し、7,072トークンのプロンプトを送ると、llama.cpp自身の計測レポートはこうなります。

prompt eval time = 208988.11 ms /  7072 tokens ( 33.84 tokens per second)
       eval time =  27129.34 ms /    80 tokens (  2.91 tokens per second)
      total time = 236117.45 ms /  7152 tokens

1ターンに4分、生成はベンチマークが約束した7.11ではなく2.91 tok/sです。プロンプト処理はコンテキストが埋まるにつれて遅くなります。llama.cppが進捗ごとに出す累積平均は、2,090トークン時点で43.58 tok/s、6,186トークン時点で37.82まで下がります。コンテキストゼロで示されるtok/sの値は、上の表のものも含めて、あなたが見る中で最良のケースです。

このリクエストは思考モードのデフォルトも示しています。補完トークンを80に制限した結果、答えではなく断片が返ってきました。reasoning_effort のデフォルトが xhigh で、答えが存在する前に推論が予算を使い切ったためです。この兆候は簡単に確認できます。数ステップの推論が要る質問をして max_tokens を80に制限すると、レスポンスは finish_reason: length、空の content、そして80トークンすべてが reasoning_content に入った状態で返ってきます。代わりに 84 * 3 を聞けば同じ制限でも問題なく、3回の実行で29から51トークンに収まりました。短い推論なら収まるからです。問題は制限そのものではなく、モデルが考え込みたくなる質問に制限がぶつかったことです。これだけ遅いマシンでは、日常的な用途では reasoning_effort を low にするか思考を無効化し、max_tokens にまともな値を与えてください。

ロードログにもう一つ地味な詳細があります。llama.cppは model has unused tensor blk.64.nextn.* と出力してスキップします。これはマルチトークン予測ヘッドで、Qwenが推論高速化のために学習させたものの、このGGUF経路では使われません。ggml-orgはMTP重みを別ファイルとして公開しています。この高速化が欲しければ自分で取りに行く必要があります。

2-bitの品質コストはすぐ表に出ます。2つのソート済み連結リストのマージを頼んだところ、モデルの思考トレースは解を壊れたPythonとして書きました。def __init__(self, val): self.val; self.next は代入ではなく何もしない式が2つ並んでいるだけです。思考トレースは下書きであり最終回答は問題なかった可能性も十分ありますが、これは量子化を上げるほど減っていく類のミスです。16GBで何とかするより24GBを工面するほうがよい、という最も強い論拠になります。

紛らわしいラベルが2つあります。llama.cppはアーキテクチャを qwen35 と報告しますが、これはQwen3.8-27BがQwen3.5アーキテクチャ上に構築され config.json が model_type: qwen3_5 と宣言しているためです。またUnslothの動的2-bitファイルをftype Q4_K - Small と報告しますが、これはヘッダーのフィールドであって実際の精度構成ではありません。バイト数を信じてください。

なぜ27BモデルのKVキャッシュはこんなに小さいのか？

64レイヤーのうち16レイヤーしかフルアテンションを使わないからです。 Qwenはモデルカードでレイヤー構成を公開しています。3つのGated DeltaNetブロックの後に1つのGated Attentionブロック、これを16回繰り返す構成です。Gated DeltaNetは線形アテンション層で、その状態はシーケンスごとに固定サイズなので、会話が伸びても大きくなりません。トークンごとのキャッシュを保持するのは16のフルアテンション層だけです。

config.json から計算すると、これらの層はKVヘッド4、ヘッド次元256を使います。f16では1レイヤー1トークンあたり4KiB、16レイヤーで1トークンあたり64KiBです。

同じヘッド構成の一般的な64レイヤーモデルなら、キャッシュは4倍、フルコンテキストで64GiB必要です。このハイブリッド構成こそが、256Kの窓を持つ27Bモデルがデスクトップの話題になり得る理由です。

これはコンテキストについての正直な答えも与えてくれます。重みはネイティブで262,144トークンに対応し、YaRNで100万まで伸びますが、ネイティブのフルコンテキストはそれだけでキャッシュに16GiBかかります。16GBのテストマシンでは、2-bit量子化の llama-server が -c 16384 で起動しリクエストを処理でき、そこでの実用帯は8Kから16Kです。32GBなら4-bitモデルと並べて32Kを余裕をもって保持できます。-c は実際に使う長さに設定し、それ以上必要なら --cache-type-k q8_0 --cache-type-v q8_0 でキャッシュを量子化すれば、わずかな品質低下でフットプリントがおよそ半分になります。フルの窓はホスト版に取っておく、という考え方はコンテキスト窓一般にも当てはまります。

ローカル構築時によくあるエラーと対処

ここでのローカル障害の多くは、別のエラーメッセージを着たメモリ障害です。 以下の行は最後の1行を除きすべてテストマシンで再現しました。最後の1行はQwen自身のベストプラクティスに基づきます。

1台のローカルQwen 3.8 27Bをチームで共有できるか？

1台で開発者1〜2人、チームには足りません。 llama-server はOpenAI互換エンドポイントを公開するので、同僚は誰でもクライアントを向けられます。その部分は本当に簡単です。

llama-server -m qwen38-27b.gguf -c 16384 --host 0.0.0.0 --port 8080 --parallel 2

限界は算術です。4-bitの27Bを動かすコンシューマGPU1枚が生み出すトークンストリームは1本で、--parallel はスループットを増やすのではなくコンテキスト予算をスロット間で分割します。4090を2人で使えば互いを感じ取れますし、4人なら順番待ちになります。

共有のローカルエンドポイントが欲しいチームは、データセンター向けカード上のvLLMやSGLangを見るべきで、それは予算の桁が違う別のプロジェクトです。その道筋は GLM 5.2セルフホストのハードウェアとコストガイドにまとめてあり、モデルは違ってもサイジングの論理は引き継げます。4-bitの27Bは48GBカードが提供するメモリのおよそ3分の1で済み、同時実行のKVキャッシュに実質的な余地が残ります。だからチームにとっては、重みを各自1部ずつ抱える4090を4枚買うより、そうしたカードを1枚買うほうが理にかなっています。

タスクの途中でローカルマシンが力尽きたら？

同じプロトコルを話すホストエンドポイントにクライアントを向けて、作業を続けてください。 どのローカル構成にも同じ2つの穴があり、それはllama.cppのせいではありません。

1つ目は容量です。あなたのマシンはメモリ帯域が許す速度で1つのモデルを動かしますが、タスクが2.4Tの兄弟モデルやMaxティア、あるいは単に速い答えを必要とするとき、ローカルエンドポイントには差し出せるものがありません。2つ目はカバー範囲です。Qwen3.8-27Bにはオープンウェイトがあり、Qwen3.8-Maxにはありません。モデルカードは Qwen Cloud 上のデフォルト1Mコンテキストのホスト版27Bを指していますが近日公開とされており、リンク先の概要ページは執筆時点でも404を返します。このファミリーには、ハードウェア予算をいくら積んでもホストできないものがあります。

llama-server はOpenAI Chat Completionsの形を話し、ホスト型ゲートウェイも同じなので、対処はどちら側でも同じです。base_url とキーを変え、コードはそのまま。ofox.ai のようなゲートウェイは bailian/qwen3.8-max を前世代の bailian/qwen3.6-27b や bailian/qwen3.5-27b と併せて扱うので、同じクライアントが2つ目のアカウントなしにGPUからホストティアへフォールバックできます。オープンウェイトの27B自体は執筆時点でそのカタログにはありません。OpenRouter では2つのプロバイダーが提供しており、どちらもフルの262,144トークンコンテキストです。Chutesは入力100万トークン0.40ドル、出力100万トークン3.00ドルでfp8、AkashMLは0.45ドルと3.20ドルでbf16です。GGUFの表と同じ教訓が一段上でも当てはまります。安いエンドポイントは量子化されたほうで、価格差は精度差です。

ハードウェアを買う前に計算してください。この単価なら、月に入力1,000万トークンと出力200万トークンを流す開発者の支払いは、どちらのプロバイダーが処理するかによって10〜11ドルです。4090はこれに対して元が取れません。所有する理由はプライバシーとオフライン利用であって、算術ではありません。

そもそも27Bを動かす価値はあるか？

自らの前世代に対しては明確にあります。 Qwenが公開した数字では、Qwen3.8-27BはTerminal Bench 2.1で73.0に対しQwen3.6 27Bが63.4、SWE-bench Proで61.7に対し53.5、自社製QwenSWEBenchで79.0に対し49.3です。コンピュータ操作では、OSWorld-Verifiedが63.9から84.3へ動きました。これらはClaude Code harness上で走らせ一部タスクセットに修正を加えたベンダー数値なので、順位表ではなく方向として扱ってください。ただし同じパラメータ数で1世代分としては、方向はかなり急です。27Bというサイズ帯が最前線のホストモデルに対してどうかを独立に読みたい場合、Qwen 3.6 27B対Claude Opus 4.6のコーディング比較が手元にある最も近いベースラインです。

ローカルマシンにとってより重要な比較は、実際に動かせる量子化との比較です。24GBカード上の4-bit 27Bは、Qwenがベンチマークしたモデルに近い。16GBノート上の2-bit 27Bはそうではなく、その差は世代間の差より大きい。

追加のメモリが何を買うのかについて、独立したデータ点があります。前世代が出たとき、Simon Willisonがローカルで動かし、2026-04-22に自身の数字を報告しています。“I tried it out with the 16.8GB Unsloth Qwen3.6-27B-GGUF:Q4_K_M quantized version” として生成25.57 tok/sを記録し、“an outstanding result for a 16.8GB local model” と評しました。これは同じサイズ帯の1世代前、4-bit、それが収まるマシン上での話です。この記事の16GB Macは2-bitで、合成ベンチマークで7.11 tok/s、実プロンプトで2.91 tok/sです。約8GBの差のために、3倍から9倍遅く、量子化も劣ります。何を買うより先にメモリを買ってください。

References

• Qwen/Qwen3.8-27B model card
• Qwen3.8-27B config.json
• Unsloth: Qwen3.8 how to run locally
• unsloth/Qwen3.8-27B-GGUF file listing
• ggml-org/Qwen3.8-27B-GGUF file listing
• lmstudio-community/Qwen3.8-27B-GGUF file listing
• NVIDIA GeForce graphics card comparison
• OpenRouter: qwen/qwen3.8-27b
• llama.cpp
• Simon Willison: Qwen3.6-27B