Qwen3.6-27Bとは｜必要スペック・メモリ(VRAM)・FP8/GGUFサイズと動かし方、ベンチ比較

Qwen3.6-27Bは、AlibabaのQwenチームが2026年4月22日に公開した、約278億パラメータ（視覚エンコーダ込み）の密（dense）モデルです。重みはApache 2.0で公開され、画像と動画の入力にも対応します。SWE-bench Verifiedは77.2で、同じQwenの大型MoEであるQwen3.5-397B-A17B（76.2）を上回ります。

ローカルで動かすときに知りたいのは「何GBのGPUやMacで動くか」です。4bitのGGUFなら重みは約17GBで、24GBのGPUに収まります。ただし文脈長を伸ばすとKVキャッシュが1トークンあたり64KiBずつ増え、262Kトークンでは16GiBに達します。この記事では、Hugging Faceの設定ファイルと重み、Ollamaのレジストリ、推論エンジンのソースを2026年10月25日時点で確認し、トークナイザとチャットテンプレートは手元で実測しました。メモリの見積もり、量子化による精度の差、動かし方と高速化、後継のQwen3.8-27Bとの選び分けを整理します。

まとめ：Qwen3.6-27Bの必要メモリと選ぶ条件

• 中身：27.8Bの密モデル。64層のうち48層は線形アテンション（Gated DeltaNet）で、通常のアテンションは16層だけです。文脈長は標準262,144トークンで、YaRNで1,010,000トークンまで伸ばせます。
• 重みのサイズ：BF16で55.6GB、公式FP8版で30.9GB、4bitのGGUF（Q4_K_M）で16.8GBです。
• KVキャッシュ：1トークンあたり64KiB（BF16）。32Kで2GiB、128Kで8GiB、262Kで16GiBです。日本語は実測で1トークン約1.7字なので、262Kは約44万字に当たります。
• 動く環境の目安：24GB GPU1枚なら4bitで32K前後、KVキャッシュを8bitにして64K前後まで。128K以上を使うなら32GB以上のGPUが必要です。
• 量子化の影響：リコーの日本語評価では、公式FP8版はBF16とほぼ同じ値でした（ELYZA-tasks-100で4.58対4.56）。ほかの8bit形式や自社業務での精度は、別に確かめます。
• 手軽に試すなら：ollama run qwen3.6:27b。LinuxやWindowsでは、このタグはMTP（投機デコード用の予測層）付きの4bit版を指します。MTPによる高速化は、Unslothの測定（予測2トークン）で平均1.4倍です。
• 選ぶ条件：新しく採用するなら後継のQwen3.8-27B（2026年8月公開・同じApache 2.0）を先に検討します。Qwen3.6-27Bは、既に評価やファインチューニングを済ませた環境を維持する場合に向きます。

Qwen3.6-27Bの仕様と公開経緯

公式GitHubの告知日は2026年4月22日で、Hugging FaceとModelScopeで同時に公開されました（Hugging Faceのリポジトリ作成日時は4月21日）。同時に公式のFP8版Qwen/Qwen3.6-27B-FP8も公開されています。モデルカードは強化点として、エージェント型コーディングと、過去の思考内容を保持するThinking Preservationを挙げています（Qwen3.6-27Bのモデルカード）。

Qwen3.6の種類：公開重みは27Bと35B-A3Bの2サイズ

Hugging FaceのAPIでQwen公式アカウントのQwen3.6を検索すると、出てくるのは35B-A3B（4月16日公開）と27B、それぞれのFP8版の4件だけです（2026年10月25日時点）。27Bは公開重みのうち唯一の密モデルで、9BなどほかのサイズやBase版はありません。Instruct版も別にはなく、1つのモデルを思考モードと非思考モードで切り替えて使います。ほかにAlibaba CloudのAPI専用モデル（qwen3.6-plus・qwen3.6-flash）があり、上位モデルはQwen3.6-Plusの1Mコンテキストと階梯課金で扱っています。

画像と動画は入力できますが、画像を生成する機能はありません。出力はテキストだけです。アーキテクチャの識別子は前世代と同じQwen3_5ForConditionalGenerationで、モデルカードはvLLM 0.19.0以上、SGLang 0.5.10以上を推奨しています。

Qwen3.7の27Bを探している場合も答えておきます。Qwen公式アカウントにQwen3.7の名前を持つ公開重みはなく、Qwen3.7世代はAPIのQwen3.7-Plusなどとして提供されています。27Bの後継の公開重みは、Qwen3.8-Maxと27Bの選び方で扱っているQwen3.8-27Bです。

1Mトークンへ伸ばすYaRNの設定

262,144トークンを超える入力には、RoPEのスケーリング（YaRN）を使います。モデルカードが示すvLLMの指定は次のとおりで、factor 4.0で262,144の4倍弱、1,010,000トークンまで扱えます。

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve Qwen/Qwen3.6-27B-FP8 \
  --hf-overrides '{"text_config": {"rope_parameters": {"mrope_interleaved": true, "mrope_section": [11, 11, 10], "rope_type": "yarn", "rope_theta": 10000000, "partial_rotary_factor": 0.25, "factor": 4.0, "original_max_position_embeddings": 262144}}}' \
  --max-model-len 1010000

モデルカードは、主要なフレームワークのYaRNは入力の長さに関係なく倍率が固定（static YaRN）なので、短い入力では性能が落ちる可能性があると注意しています。長い入力が必要なときだけ有効にし、想定の長さが524,288トークンならfactorを2.0にするのが推奨です。1,010,000トークンのKVキャッシュはBF16で約61.6GiBになり、FP8の重みと合わせると80GB GPU1枚には収まりません。

Qwen3.6-27Bの必要スペック：重み＋KVキャッシュで見積もる

必要なメモリは「重み」「KVキャッシュ」「計算用の作業領域」の合計です。ファイルサイズだけを見て選ぶと、長い文脈を入れたときにメモリ不足で落ちます。

量子化別の重みサイズ（FP8・GGUF）

Hugging FaceのAPIで各ファイルのサイズを取得しました。GGUFで画像を入力する場合は、表の重みに別配布の視覚エンコーダ（mmproj）約0.93GBが加わります。公式BF16版とFP8版のサイズには視覚エンコーダが含まれるため、重複して加算しません。

公式FP8版は、E4M3形式で128×128のブロックごとにスケールを持つ量子化です。FP8になっているのは24.70B分で、埋め込み層と出力層（約2.5B）、視覚エンコーダ、正規化やゲートの層など計3.08B分はBF16のまま残っているため、BF16のちょうど半分にはなりません。FP8の数値形式はFP8とFP16・BF16の違いで、GGUFの量子化名の読み方はGGUFの仕組みとGPTQ・AWQとの違いで解説しています。

KVキャッシュの計算：1トークン64KiB

KVキャッシュは通常アテンションの層にだけ必要です。Qwen3.6-27Bは64層のうち16層しか通常アテンションを持たないため、同じ規模の全層アテンションのモデルより小さく済みます。config.jsonの値から、16層×KVヘッド4×head_dim 256×（KとV）×2バイトで、1トークンあたり65,536バイトです。

線形アテンション（Gated DeltaNet）の48層は、文脈長に関係なく固定サイズの状態を持ちます。fp32で保持しても1系列あたり約0.14GiBなので、見積もりではほぼ無視できます。ただし同時に処理する系列数（バッチ）の分だけKVと状態が増える点は、サーバー運用で効いてきます。

同世代のQwen3.6-35B-A3Bは、通常アテンションが10層・KVヘッド2本なので1トークン20KiBです。27Bは35B-A3Bより重みが小さい一方、KVキャッシュは約3.2倍になります。長い文脈を常用するなら、この差が重みのサイズ差より大きく効きます。KVキャッシュを削る手法はKVキャッシュの仕組みとメモリ削減にまとめています。

日本語なら何文字入るか：1トークン約1.7字

公式のトークナイザ（tokenizer.json）で、日本語の技術解説文10,842字（この記事の10月16日版の本文からコードを除いたもの）を数えると6,455トークンでした。1トークンあたり1.68字です。同じ方法でチャットテンプレートのJinjaコードを数えると1トークンあたり3.84字でした。この2つのサンプルでは、同じ文字数に対して日本語本文のほうが多くのトークンを使いました。

日本語1万字はおよそ6,000トークンで、KVキャッシュは約0.36GiB増えます。社内規程や仕様書をまとめて読ませる場合は、文書の総字数を1.7で割ってトークン数を出し、そこに出力分（モデルカードの推奨は通常32,768トークン）を足してから文脈長を決めます。表記や記号の多さで比率は変わるため、自社の文書で一度数えてください。

GPU・Mac別の目安：24GBで32K、32GBで128K

重みとKVを足し、作業領域として1〜2GBを見込んだ目安です。実測ではなく計算値なので、推論エンジンの設定によって前後します。

24GB GPUの場合、Q4_K_Mの重み16.8GBに、32KのKV 2GiB（約2.1GB）と作業領域を足すと21GB前後になります。128KのKVをBF16で持つと8GiBが加わり、24GBを超えます。KVを8bitにしても128Kでは4.25GiBで、MTP版の追加分（Unslothによれば約1GB）や画像入力用のmmproj（0.93GB）まで載せると24GBに収まりません。モデルカードは「思考能力を保つため文脈長は128K以上を推奨」としているので、エージェント用途なら32GB以上のGPUを選びます。画像を使わないなら、llama-serverに--no-mmprojを付けると視覚エンコーダを読み込みません。

量子化で精度はどれだけ落ちるか：FP8・4bit・3bitの差

サイズの表だけでは、どこまで量子化してよいか決められません。公開されている3種類の測定を並べると、8bitまではほぼ差が出ず、4bitで小さな劣化、3bitで劣化がはっきり大きくなります。

日本語の3項目は、リコーが2026年6月5日の発表で公開した値です（リコーのQwen3.6-Ricoh-27B発表）。vLLMで推論し、gpt-4.1による採点を5回平均しています。BF16と公式FP8版の差は、ELYZA-tasks-100で0.02、Japanese MT-Benchで0.01、JDocQA-Reasoningで0.002でした。これらの日本語ベンチマークでは公式FP8版の低下は小さい結果でした。業務で必要な抽出精度や誤回答率は、自社の評価データでも確認してください。英語系の指標はUnslothのNVFP4検証の値で、GPQAはBF16が1ポイント余り高い一方、MMLU-ProはFP8やNVFP4のほうがわずかに高い報告値です。ただし、この表には信頼区間や試行間の分散が示されていないため、差が測定のぶれかどうかは判断できません。

3bit以下はUnslothがMac向けMLX版で公開している平均KLダイバージェンス（元のBF16の出力分布とのずれ）が目安になります。8bitは0.0028、4bitは0.0227、3bitは0.0734で、3bitは4bitの約3倍ずれます。パープレキシティも8bitの4.812に対して3bitは4.976です（UnslothのQwen3.6日本語ガイド）。16GB GPUに収めるために3bit以下へ落とすくらいなら、24GB GPUで4bitを使うか、MoEの35B-A3Bを検討するほうが結果は安定します。

Qwen3.6-27Bのベンチマーク：Qwen3.5-27B・35B-A3B・Gemma 4 31Bとの差

数値はQwen公式モデルカードの報告値で、ローカルの量子化版で測った値ではありません。SWE-bench系はQwen社内のエージェント構成（bashとファイル編集ツール）での評価で、SWE-bench Proは問題のある課題を修正した版で全モデルを評価し直したと注記されています。

伸びが大きいのはエージェント系です。Terminal-Bench 2.0は前世代の41.6から59.3へ上がり、表の上ではClaude 4.5 Opusと同じ値です。SkillsBenchは27.2から48.2へ伸びました。知識系はほとんど動いておらず、MMLU-Proは86.1から86.2、HLEは24.3から24.0でわずかに下がっています。Qwen3.5-27Bから乗り換える効果が大きいのは、コーディングエージェントやツール操作の用途です。

Terminal-Bench 2.0は評価環境（Harbor／Terminus-2、3時間制限、32CPU・48GB RAM、5回平均）が注記されており、手元で同じ条件をそろえるのは困難です。採用判断には、自社のリポジトリで数十件の課題を解かせる小さな評価を別に用意してください。

Qwen3.6-27Bの動かし方：Ollama・llama.cpp・vLLM

Ollamaで動かす（qwen3.6:27b）

ollama run qwen3.6:27b

Ollamaのレジストリでタグの中身を確認すると、qwen3.6:27bはqwen3.6:27b-mtp-q4_K_Mと同じ重み（16.84GB）と視覚エンコーダ（0.93GB）を指していました。パラメータにはdraft_num_predict 3が入っており、MTPで3トークン先まで予測する指定です。主なタグは次のとおりです（Ollamaのqwen3.6タグ一覧・2026年10月25日時点の表示サイズ）。

27b-codingは重みが同じで、サンプリングの温度だけがモデルカードの「精密なコーディング向け」推奨値（0.6）になっています。27bのマニフェストにはllama.cppランナーの指定があり、Macでは同じタグでMLX版が選ばれる可能性があります。MacでGGUF版を確実に使うならqwen3.6:27b-mtp-q4_K_Mを指定してください。qwen3.6:latestは35B-A3Bを指すので、27Bを使うときはタグを明示します。長い入力を使う場合は、環境変数OLLAMA_CONTEXT_LENGTHか、対話中の/set parameter num_ctx 32768で文脈長を明示します。

llama.cppで動かす（MTPとKVの8bit化）

2026年10月25日時点の最新リリースは、10月15日（UTC）公開のv0.7.0です。オプション名はソースコード（common/arg.cpp）で確認しました。

llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_M \
  -c 65536 -ngl 99 -fa on \
  -ctk q8_0 -ctv q8_0 \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0

• --spec-type draft-mtp：MTP層を使う投機デコードです。UnslothのMTP版GGUFはMTP層を同じファイルに含み、Q4_K_Mで17.11GB（通常版は16.82GB）です。ggml-orgのリポジトリでは、MTP層がmtp-Qwen3.6-27B-Q8_0.gguf（3.16GB）などの別ファイルに分かれています。
• -ctk q8_0 -ctv q8_0：KVキャッシュを8bitにして、上の表の「8bit」列の量に抑えます。
• --min-p 0：llama.cppの既定のmin_pは0.05なので、モデルカードの推奨値（0.0）に合わせて明示します。

思考モードの切り替えは--reasoning off（またはon・auto、既定はauto）で行います。--chat-template-kwargs '{"enable_thinking":false}'でも動きますが、非推奨の警告が出ます。Unslothの日本語ガイドはこの旧来の書き方のままなので、v0.7.0では--reasoning offに置き換えてください。

vLLMで動かす（公式FP8版）

vllm serve Qwen/Qwen3.6-27B-FP8 \
  --max-model-len 131072 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder \
  --speculative-config '{"method":"mtp","num_speculative_tokens":2}'

モデルカードのMTPの例は"method":"qwen3_next_mtp"ですが、10月18日公開の最新版vLLM 0.32.0では非推奨で、内部でmtpに読み替えて警告を出します（vllm/config/speculative.py）。新しく書く設定はmtpにしておきます。画像を使わない場合は--language-model-onlyを付けると、視覚エンコーダの分のメモリをKVキャッシュに回せます。FP8版の重み30.9GBなら80GB GPU1枚に収まり、262Kの文脈でもKVは16GiBです。vLLMの全体像はvLLMの仕組みと使い方で、MacでのMLXの使い方はMLXとmlx-lmの使い方で解説しています。

生成速度を上げる：MTPとDFlashの投機デコード

27Bは密モデルなので、毎トークン27B分を計算します。生成の速さを補う手段が、軽い予測器で数トークン先を下書きし、本体がまとめて検証する投機デコードです。仕組みは投機的デコーディングの仕組みと速くなる条件とMTP（Multi-Token Prediction）の解説で扱っています。

MTPはUnslothの測定で、密モデルの27Bは予測2トークンで平均1.4倍速くなり、RTX 6000では160トークン/秒で生成しています。予測を4トークンに増やすと受理率が83%から50%に下がるため、Unslothは2を推奨しています。Ollamaの既定タグは3を指定しているので、速度を詰めるなら2と3を自分の環境で比べてください。

DFlashは、ブロック拡散モデルで16トークン単位の下書きを並列に作る方式です。Qwen3.6-27B用の予測器z-lab/Qwen3.6-27B-DFlashはMITライセンスで、BF16の1,730,213,120パラメータです（z-labのQwen3.6-27B-DFlash）。モデルカードには「まだ学習中で、推論エンジンの対応が完全でない場合がある」と書かれており、ベンチマーク欄も空のままです。vLLM 0.32.0はdflashを本体で受け付けますが、この予測器は5層のうち4層がスライディングウィンドウのアテンションで、全層アテンションと混在する構成はV2のモデルランナーでしか動きません（vllm/model_executor/models/qwen3_dflash.py）。

VLLM_USE_V2_MODEL_RUNNER=1 vllm serve Qwen/Qwen3.6-27B \
  --speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.6-27B-DFlash", "num_speculative_tokens": 15}' \
  --attention-backend flash_attn \
  --max-num-batched-tokens 32768

環境変数を付けずに起動するとNotImplementedErrorで止まります。llama.cpp v0.7.0にも--spec-type draft-dflashがありますが、公称の高速化倍率はこのチェックポイントについて公表されていません。24GB GPUでは予測器の約3.5GBがKVキャッシュの枠を削るため、まずMTPを使います。DFlashを比べるなら、本体を量子化した構成で48GB以上が出発点です。上の起動例はBF16の本体を使い、重みだけで55.6GBあるため、80GB以上のGPUを目安に文脈長と空き容量を確認してください。

Claude Codeから使う：llama-serverのAnthropic互換API

Qwen3.6-27Bはコーディングエージェント向けに強化されたモデルなので、Claude CodeやOpenCode、Codexの裏側に置く使い方が多くなります。llama.cpp v0.7.0のllama-serverは、OpenAI互換の/v1/chat/completionsに加え、Anthropic互換の/v1/messagesを持っています。Claude Codeからは接続先を環境変数で切り替えます。

llama-server -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_M \
  --alias qwen3.6-27b --port 8001 -c 131072 -ngl 99 -fa on \
  -ctk q8_0 -ctv q8_0 --spec-type draft-mtp --spec-draft-n-max 2 \
  --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0

export ANTHROPIC_BASE_URL="http://localhost:8001"
export ANTHROPIC_AUTH_TOKEN="local"
export ANTHROPIC_API_KEY=""
export CLAUDE_CODE_ATTRIBUTION_HEADER=0
claude --model qwen3.6-27b

CLAUDE_CODE_ATTRIBUTION_HEADER=0は、Unslothのガイドが勧めている設定です。Claude Codeはシステムプロンプトの先頭にリクエストごとに値が変わる1行を付けるため、そのままではプロンプトの先頭がKVキャッシュに当たらず、ローカルモデルの推論が大きく遅くなると説明されています。エージェントはファイルの中身を何度も入力するので、文脈長128Kを使う構成は32GB以上のGPUを目安にしてください。24GB GPUではKVを8bitにしても容量に余裕があるとは限らないため、まず64K以下で起動し、実際のメモリ使用量を確認します。モデル名は--aliasで付けた名前を指定します。

思考モードと思考保持（preserve_thinking）の設定

Qwen3.6-27Bは既定で思考モードです。応答の前に思考内容を生成し、推論エンジンの--reasoning-parser qwen3がそれを本文と分けて返します。Qwen3にあった/think・/nothinkをプロンプトに書く切り替えは、Qwen3.6では公式にサポートされていません。

どのモードもtop_k 20・min_p 0.0がモデルカードの推奨です。非思考モードにするには、vLLMやSGLangのOpenAI互換APIではextra_bodyに{"chat_template_kwargs": {"enable_thinking": false}}を入れます。チャットテンプレートはこのとき、応答の先頭に空の思考ブロック（<think>と</think>の間が空）を差し込みます。Alibaba Cloud Model StudioのAPIでは"enable_thinking": falseを直接指定します。

思考保持で入力はどれだけ増えるか：テンプレートで実測

Qwen3.6で加わったのが思考保持（Thinking Preservation）です。"chat_template_kwargs": {"preserve_thinking": true}を指定すると、過去のターンの思考も履歴に残してモデルに渡します。公式のチャットテンプレート（chat_template.jinja）をJinja2で描画し、トークン数を数えて挙動を確かめました。

各ターンの思考は日本語1,500字（950トークン）で置きました。思考保持をオンにすると、3ターン分の思考がそのまま入力に戻り、約25倍になります。もう1つわかったのは、ツール呼び出しを繰り返している間は、指定しなくても思考が残ることです。テンプレートは最後のユーザー発言より後のアシスタント発言の思考を常に残すため、ツールの結果を返すだけの往復では思考は消えません。preserve_thinkingが効くのは、ユーザーが新しい指示を出したときに、それより前のターンの思考を残すかどうかです。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
messages = [{"role": "user", "content": "このリポジトリのテストが落ちる原因を調べて"}]

chat_response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B-FP8",  # vLLMで起動したモデル名に合わせる
    messages=messages,
    max_tokens=32768,
    temperature=0.6,
    top_p=0.95,
    extra_body={
        "top_k": 20,
        "chat_template_kwargs": {"preserve_thinking": True},
    },
)

このコードは設定の指定例です。思考保持を実際に使うには、過去のアシスタント応答の本文とreasoning_contentをmessagesに含めて次のリクエストへ渡します。モデルカードは、エージェント用途で判断の一貫性が上がり、同じ推論の繰り返しが減ることで全体のトークン消費が減る場合が多いと説明しています。それでも、ユーザーが何度も指示を出す長い対話では、上の実測のとおり過去の思考の分だけ入力が膨らみます。27BはKVキャッシュが大きいので、思考保持を使うなら文脈長とメモリの余裕を先に確保してください。なお、llama.cpp v0.7.0のllama-serverは、何も指定しなくても思考保持が有効です（--reasoning-preserveが既定）。過去の思考を渡したくない場合は--no-reasoning-preserveを付けます。

Qwen3.6-27BのAPI料金と商用利用

重みのライセンスはApache 2.0です。商用サービスへの組み込みや、ファインチューニングした派生モデルの公開ができます。再配布時には、ライセンス文の同梱、変更したファイルへの変更表示、NOTICEファイルがある場合はその帰属表示の引き継ぎが必要です（Qwen/Qwen3.6-27Bのリポジトリには、2026年10月25日時点でNOTICEファイルはありません）。

Alibaba Cloud Model StudioではAPI名qwen3.6-27bで提供されています。100万トークンあたりの料金は、International（シンガポール）で入力0.6ドル・出力3.6ドル、中国（北京）で入力約0.41ドル・出力約2.48ドルです（Model Studioの料金表）。思考モードでも出力単価は変わりませんが、思考トークンも出力として課金されるため、思考オンでは出力トークン数そのものが増えます。同じInternationalで35B-A3Bは入力0.375ドル・出力2.25ドルで、27Bの約6割です。料金は改定されることがあるため、契約前に公式の料金ページで確認してください。

注意したいのは思考保持です。モデルカードはModel Studioでも"preserve_thinking": trueを指定する方法を載せていますが、Model Studioの思考モードの説明ページ（2026年10月19日更新）が挙げる対応モデルは、Qwen3.6世代ではqwen3.6-plusだけで、qwen3.6-27bは含まれていません。思考保持を前提にエージェントを組むなら、自前のvLLMやSGLangで動かすか、対応モデルを選んでください。

Qwen3.6-35B-A3B・Qwen3.8-27B・日本語派生版との選び分け

同世代のQwen3.6-35B-A3Bとの比較では、精度は27Bが上です。SWE-bench Verifiedは77.2対73.4、Terminal-Bench 2.0は59.3対51.5です。ただし、27Bは毎トークン27B分を計算し、35B-A3Bは約3B分しか計算しません。公称のアクティブパラメータ数の比は約9倍で、同じGPUでは27Bのほうが生成が遅くなります（実際の速度比は量子化や推論エンジンで変わります）。MTPの効きも違い、Unslothの測定では密モデルの27Bが1.4〜2倍、MoEの35B-A3Bは1.15〜1.25倍でした。35B-A3Bの詳細はQwen3.6-35B-A3Bの必要VRAMと動かし方にまとめています。

2026年8月14日には、密モデルの後継としてQwen3.8-27Bが公開されました。ライセンスは同じApache 2.0で、層構成（64層・DeltaNet×3＋Attention×1の16回）とKVの構成（通常アテンション16層・KVヘッド4・head_dim 256）も共通なので、この記事のKVキャッシュの見積もりはそのまま使えます。Qwen3.8-27Bのモデルカードでは、SWE-bench Proが61.7（Qwen3.6-27Bは53.5）、Terminal Bench 2.1が73.0（同63.4）で、テキスト性能の比較表の全項目でQwen3.6-27Bを上回っています。

日本語の図表読解を重視するなら、リコーがQwen3.6-27Bを独自の強化学習で調整した「Qwen3.6-Ricoh-27B-20260522」もあります。リコーの評価ではJDocQA-Reasoningが0.858から0.881、ELYZA-tasks-100が4.58から4.64に上がりました。ただしHugging Faceのリコーのアカウントには公開されておらず、提供はリコージャパンの「RICOH オンプレLLMスターターキット」経由です。自分でダウンロードして試せるモデルではありません。

• これから採用する：Qwen3.8-27Bを先に評価します。同じGPUで動かせる構成で、Qwen3.6-27Bを新規に選ぶ理由は少なくなりました。
• Qwen3.6-27Bを使い続ける：自社データでのファインチューニングや評価セットでの検証を済ませている場合です。乗り換えには再評価の工数がかかるため、ベンチマークの差だけで切り替えない判断もあり得ます。
• 応答速度を優先する：24GB GPUで人が待つ対話型のコーディング支援なら、35B-A3Bを候補にします。
• オンプレで日本語の帳票や図面を読ませる：サーバーごと導入する前提なら、リコーの派生版を比較対象に入れます。

社内でオープンウェイトのLLMを動かす構成やモデル選定を検討している場合は、生成AI導入支援でも相談を受け付けています。

Qwen3.6-27Bを選ばないほうがよい条件

• 16GBのGPUで長い文脈を使う：3bit以下まで落としても重みは11〜14GBで、KVに回せる余裕は数GBです。3bitは4bitの約3倍、元の出力分布からずれます。128K以上の推奨文脈長も確保できません。
• 長文脈を多数並行で処理する：KVが1トークン64KiBで、同時系列数に比例して増えます。262Kを4系列なら64GiBです。この用途は、KVが約3分の1で済む35B-A3Bのほうが有利です。
• レビューなしでパッチを自動適用する：SWE-bench Proは53.5で、難しい課題の半分近くは解けていません。テストと反映前のレビュー工程を残してください。
• 知識問題の精度向上を目的に乗り換える：MMLU-ProやHLEはQwen3.5-27Bとほぼ同じです。

よくある質問

Qwen3.6-27Bを動かすにはVRAMがどれくらい必要ですか？

4bitのGGUF（Q4_K_M）で重みが16.8GBです。KVキャッシュが32Kの文脈で2GiB加わるため、24GBのGPUが現実的な最小構成です。128K以上の文脈を使うなら32GB以上、BF16のまま動かすなら重みだけで55.6GBが必要です。

Qwen3.6-27B-FP8は通常版と何が違いますか？

重みをE4M3形式の8bit浮動小数点に量子化した公式版で、サイズは30.9GB（通常版は55.6GB）です。埋め込み層・出力層と視覚エンコーダはBF16のまま残しています。リコーの日本語評価ではELYZA-tasks-100が4.58対4.56で、精度の差はほとんどありません。vLLMやSGLangで80GB GPU1枚に載せる用途に向きます。

Ollamaのqwen3.6:27bとqwen3.6:27b-q4_K_Mの違いは何ですか？

LinuxやWindowsでは、qwen3.6:27bはMTP（3トークン先の予測）付きの4bit版で、qwen3.6:27b-mtp-q4_K_Mと同じ重みです。qwen3.6:27b-q4_K_Mは別の重みで、MTPの設定が入っていません。タグ一覧のサイズは前者が18〜19GB、後者が17GBです。

Qwen3.6の27Bと35B-A3Bはどちらを選べばよいですか？

正答率を優先するなら27B、応答速度と長い文脈の省メモリを優先するなら35B-A3Bです。27BはSWE-bench Verifiedで3.8ポイント上ですが、公称アクティブパラメータ数の比は約9倍で、同じ文脈長・精度での通常アテンションのKVキャッシュは約3.2倍です。実際の速度比は実行条件によって変わります。

Qwen3.6-27Bは商用利用できますか？

できます。重みのライセンスはApache 2.0で、社内システムや商用サービスに組み込めます。再配布するときは、ライセンス文の同梱と変更箇所の表示などの条件を守ってください。

関連記事

• Qwen3.6-35B-A3Bとは｜必要VRAM・GGUFサイズ・Ollama/vLLMの動かし方とベンチ比較
• Qwen3.8-Maxとは｜2.4兆MoEの必要VRAM・GPU台数・ライセンスと27Bの選び方
• Speculative Decoding（投機的デコーディング）とは？仕組みと速くなる条件、LM Studio・llama.cpp・vLLMでの設定
• MTP（Multi-Token Prediction）とは？LLMの複数トークン予測の仕組みと投機的デコーディングでの使い方
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】