Qwen3.6-35B-A3Bとは｜必要VRAM・GGUFサイズ・Ollama/vLLMの動かし方とベンチ比較

Qwen3.6-35B-A3Bは、Alibaba Cloud（Qwenチーム）が2026年4月16日に公開したMoE（Mixture of Experts）モデルです。総パラメータは35B、1トークンあたりの活性パラメータは約3Bです。重みはApache 2.0で、画像・動画入力にも対応します。Qwen3.6世代で最初に重みが公開されたモデルで、前世代のQwen3.5-35B-A3Bからエージェント型のコーディング性能を大きく伸ばしました。

この記事では、Hugging Faceの重みファイルと設定ファイル、Ollamaのレジストリ、vLLMとllama.cppのソースコード、vLLM公式レシピを2026年10月24日時点で確認しました。そのうえで、メモリの見積もり、量子化の選び方、起動コマンド、思考モードの扱いを整理します。起動コマンドは公式資料と実装に基づく例で、モデルの起動・推論を実測したものではありません。

まとめ：Qwen3.6-35B-A3Bの要点と選ぶ条件

• 中身：「A3B」は活性（Activated）3Bの意味です。総35.95B（視覚エンコーダとMTP層を含む）のうち32.2Bが256個の専門家重みで、1トークンで使うのは8個＋共有1個、計算量は約3B相当です。
• メモリ：計算は軽くても、重みはすべてメモリに載せます。BF16で約72GB、4bit量子化のGGUFで約22GB、Mac向けMLX 4bitで約20GBです。
• 長文脈に強い：40層のうち通常のアテンションは10層だけです。KVキャッシュは262,144トークンでも約5GiB（BF16）に収まります。
• 性能：SWE-bench Verifiedは73.4（Qwen3.5-35B-A3Bは70.0）です。ただし同世代の密モデルQwen3.6-27B（77.2）には及びません。
• 手軽に試すなら：ollama run qwen3.6:35b-a3b。このタグのllamacpp用重みはMTP（投機デコード用の予測層）付きのQ4_K_Mです。同じタグにはMLX用の重みもあります。16GB GPUならllama.cppで専門家重みの一部をCPU側メモリへ退避します。
• 2026年10月の変更点：llama.cpp v0.7.0のllama-serverは、過去ターンの思考を残す設定が既定でオンになりました。文脈長に余裕がない環境では--no-reasoning-preserveで切ります。
• 選ぶ条件：24GB級のGPU1枚やMac 32GB以上で、応答の速さと長文脈を優先するなら35B-A3Bを選びます。掲載したコーディング系ベンチマークの成績を優先するなら、Qwen3.6-27Bが候補です。

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

公式GitHubの告知日は2026年4月16日で、Hugging FaceとModelScopeで同時に公開されました（Hugging Faceのリポジトリ作成日時は4月15日05:59 UTC）。同時にFP8版のQwen/Qwen3.6-35B-A3B-FP8も公開されています。Hugging Faceの公式モデルカードの区分は「Causal Language Model with Vision Encoder」で、テキスト・画像・動画を入力でき、出力はテキストです。Qwen3.5以降はVL（視覚言語）を別系列に分けず、1つのモデルに統合しています。そのため、Qwen3-VL世代のように「VL版」を別途探す必要はありません。前世代のVL専用モデルはQwen3-VL-30B-A3BのInstructとThinkingの違いで扱っています。

「A3B」の意味と総35Bの内訳（safetensorsヘッダの実測値）

モデル名の「35B」は総パラメータ数、「A3B」は1トークンの処理で実際に計算に使う活性パラメータが約3Bという意味です。Qwenは同じ命名をQwen3-Next-80B-A3BやQwen3.5-397B-A17Bにも使っています。

この「35B」と「3B」の内訳は、モデルカードに書かれていません。そこで、Qwen/Qwen3.6-35B-A3B（コミット995ad96）の26個のsafetensorsファイルについて、ヘッダに記録されたテンソル形状の積を部位ごとに合計しました。分類はテンソル名で行っています。visualを含むものは視覚エンコーダ、mtpで始まるものはMTP層、mlp.expertsは専門家、shared_expertは共有専門家です。合計はHugging Face APIが返すsafetensors.totalの35,951,822,704と一致します。

重みの約9割（89.6%）が専門家で、そのうち毎トークン計算するのは32分の1だけです。これがMoEの性質です。活性パラメータは3B級でも、保存・配置する重みは35B級です。「3Bだから8GBのGPUで動く」とは考えないでください。MoEの仕組みはMoE（Mixture of Experts）の疎活性化とルーターの解説で扱っています。なお、第三者の解説には「128エキスパート」と書くものがありますが、config.jsonのnum_expertsは256です。

3対1のハイブリッド構成とKVキャッシュ量

40層は「Gated DeltaNet→MoE」を3層、「Gated Attention→MoE」を1層という4層の組を10回繰り返す構成です。トークン数に比例してKVキャッシュが増えるのは、通常アテンションの10層だけです。残り30層の線形アテンションは、系列長に関係なく固定サイズの状態を持ちます。その量はfp32で1系列あたり約63MBです。

config.jsonの値（KVヘッド2、head_dim 256）から試算すると、KVキャッシュはBF16で1トークンあたり20,480バイトです。ネイティブ上限の262,144トークンでも約5.0GiB、YaRNで拡張した1,010,000トークンでも約19GiBに収まります。前世代のQwen3-30B-A3B-Instruct-2507は48層すべてが通常アテンション（KVヘッド4・head_dim 128）で、262,144トークンでは約24GiBでした。同じ文脈長で、KVは約5分の1です。KVキャッシュの計算方法はKVキャッシュの仕組みとメモリ削減の解説を参照してください。

ベンチマークで見るQwen3.5-35B-A3B・Qwen3.6-27Bとの差

数値はQwen公式モデルカードの報告値で、ローカルの量子化版を測定した結果ではありません。SWE-bench系は独自のエージェント構成（200K文脈）での評価で、SWE-bench Proは公開セットの問題のある課題を修正した版での結果です。SkillsBenchはAPI依存の課題を除いた78課題での評価です。QwenWebBenchは正答率ではなく、Elo形式の指標です。Qwen3.6-27Bの列は、Qwen3.6-27Bのモデルカードから取りました。

Qwen3.5-35B-A3Bから伸びた指標と下がった指標

同じ35B-A3Bの構成で伸びたのは、コーディングエージェント系です。Terminal-Bench 2.0は11ポイント、SWE-bench Multilingualは6.9ポイント上がりました。フロントエンド生成のQwenWebBenchも978から1397に伸びています。モデルカードが掲げる「Agentic Coding」の強化と一致します。画像理解のMMMUは81.4から81.7で、ほぼ横ばいです。

汎用エージェントや知識系は、指標によって増減があります。VITA-Benchは29.1から35.6、MCPMarkは27.0から37.0へ上がりました。下がったのはTAU3-Bench（68.9→67.2）やTool Decathlon（28.7→26.9）などです。HLEは22.4→21.4、Claw-EvalのPass^3は51.0→50.0、MMLU-Proは85.3→85.2でした。コーディング以外の用途でQwen3.5-35B-A3Bから置き換えるなら、使うツールや質問に近い評価で改善があるかを確かめてから判断します。

Qwen3.6-27B・Qwen3.8-27Bとの選び分け

掲載したコーディング系ベンチマークでは、Qwen3.6-27Bが35B-A3Bを上回ります。前世代の密モデルQwen3.5-27Bでも、SWE-bench Verifiedは75.0で35B-A3Bの73.4を上回ります。一方、27Bは毎トークン27B分を計算します。活性パラメータ数の比で約9倍ですが、演算量の比はアテンション構成や文脈長でも変わります。実際の生成速度の差は、量子化、バッチサイズ、メモリ配置、推論エンジンをそろえて測る必要があります。ファイル容量は逆で、Ollamaの4bitタグは27Bが17〜19GB、35B-A3Bが23〜24GBです。27Bの必要メモリはQwen3.6-27Bの必要スペックとFP8・GGUFサイズにまとめています。

2026年8月には、密モデルの後継としてQwen3.8-27B（Apache 2.0）が公開されました。Qwen3.8-27Bのモデルカードでは、Claude Code・256K文脈で評価したSWE-bench Proが61.7で、同条件で再評価したQwen3.6-27Bの53.5を上回ります。一方、Hugging FaceのQwen公式アカウントの公開一覧を見る限り、Qwen3.8世代に35B-A3B相当の小型MoEはありません。Qwen3.8世代の構成はQwen3.8-Maxの必要VRAMと27Bの選び方で解説しています。

判断の目安は次のとおりです。対話しながらコードを書く用途や、長いリポジトリを読ませる用途で応答の速さが効くなら、35B-A3Bを選びます。夜間のバッチ修正のように待ち時間を許容でき、正答率が成果に直結するなら、Qwen3.8-27Bを選びます。どちらもApache 2.0なので、ライセンスは判断材料になりません。

必要VRAMと量子化別のGGUF・MLXサイズ

ローカル実行で決めるのは「どの量子化を、どのメモリに載せるか」です。重みのサイズに、KVキャッシュと計算用バッファが加わります。

量子化別のファイルサイズ（Unsloth GGUF・2026年10月実測）

unsloth/Qwen3.6-35B-A3B-GGUFのファイル一覧から、主な量子化のサイズを取りました。MTP層を同梱したunsloth/Qwen3.6-35B-A3B-MTP-GGUFは、量子化方式によって追加容量が異なり、下表では4bitで約0.5GB、BF16で約1.7GB大きくなります。

画像を入力する場合は、視覚用のmmproj-F16.gguf（0.90GB）が別に必要です。LM Studioのモデルページは最小システムメモリを20GBとしていますが、これは低ビット版で起動できる下限と考えてください。まず4bit（Q4_K系かMXFP4_MOE）を候補にし、メモリが足りない場合だけ、低ビット版を同じ課題で比べて選びます。8bitのQ8_0は、4bitとの差を確かめる比較用か、48GB以上のメモリに余裕がある環境向けです。

24GB GPUで使える文脈長の試算

Ollamaのqwen3.6:35b-a3bのllamacpp用ファイルは、重み21.72GBと視覚用0.90GBの合計22.62GB（約21.1GiB）です。RTX 4090などの24GiB GPUでは、残りは約2.9GiBです。KVキャッシュはf16で32Kトークンなら0.625GiB、64Kで1.25GiB、128Kで2.5GiBかかります。計算用バッファも必要なので、全層をGPUに載せたまま使えるのは64K前後までと見積もれます。この値は重みとKVからの試算で、バッファ量は実行環境によって変わります。

画像を使わないならmmprojを読み込まない、KVキャッシュをq8_0にする、という方法でも1〜2GiBを空けられます。モデルカードは思考能力を保つため128K以上の文脈を勧めていますが、短い質疑が中心なら32Kでも動きます。

16GB・12GB GPU向けの専門家重みのCPU退避

16GB以下のGPUでは、llama.cppの--n-cpu-moe N（略記-ncmoe）を使います。先頭N層の専門家重みだけをCPU側のメインメモリに置き、アテンションと共有専門家はGPUに残す指定です。層ごと全部をCPUへ移す-nglの調整より、GPUに残る計算が多くなります。

Nの初期値は次のように見積もれます。UD-Q4_K_XL（22.4GB）では、重みの約9割が40層の専門家に分かれるので、1層あたりの専門家重みは約0.5GBです。16GB GPUでGPU側の重みを約13GBに抑えるなら、退避する層は約19層です。12GB GPUなら約27層になります。退避した分（約10〜14GB）はメインメモリに載るので、OSの使用分とは別に、その空き容量が必要です。CPU退避による速度低下は、退避量、メモリ帯域、CPU性能によって変わります。Nを2〜4ずつ減らしながら、メモリ不足で落ちない最小値を探してください。

# 16GB GPU：Q4_K_XLの専門家重みを先頭20層ぶんCPUへ退避（32K文脈）
llama-server -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q4_K_XL \
  -ngl 99 --n-cpu-moe 20 -c 32768 --no-mmproj

Q3_K_M（16.6GB）を16GB GPUに全部載せる手もありますが、KVとバッファを入れる余地がほとんど残りません。Q4_K_XLを一部退避するほうが、量子化による劣化を抑えられます。

Apple SiliconのMLX版とGGUF版

Macでは、LM StudioがGGUF版とMLX版（4bit・6bit・8bit）を配布しています。MLX版の重みは、4bitが20.4GB、6bitが29.1GB、8bitが37.7GBです（lmstudio-communityのファイル一覧で確認）。macOSはGPUに割り当てられる統合メモリに上限を設けているため、メモリ32GBのMacでは4bit、48GBで6bit、64GB以上で8bitが目安です。16GBのMacでは、4bitのMLX版も載りません。

Ollama・llama.cpp・LM Studioでのローカル実行

Ollamaのタグと実行バックエンド別の配布形式

Ollamaのqwen3.6ライブラリのマニフェストを比べると、qwen3.6:latest・qwen3.6:35b・qwen3.6:35b-a3bの3つは、qwen3.6:35b-a3b-mtp-q4_K_Mと同じllamacpp用重みを指します。既定タグには別のMLX用重みも含まれます（2026年10月24日時点）。パラメータにはdraft_num_predict: 2が入っており、MTP層で2トークン先を予測する投機デコードが有効です。MTPを使わないqwen3.6:35b-a3b-q4_K_M（24GB）は別ファイルで、パラメータにdraft_num_predictがありません。特に理由がなければ、既定のタグで足ります。

# 既定（思考モード・一般タスク向けのサンプリング）
ollama run qwen3.6:35b-a3b

# 同じ重みで temperature 0.6 ／ presence_penalty 0 に変えたコーディング向け
ollama run qwen3.6:35b-a3b-coding

# 8bit（39GB）
ollama run qwen3.6:35b-a3b-q8_0

-codingタグも、重みは既定のタグと同一で、違うのはサンプリング設定だけです。モデルカードにある「精密なコーディング向け思考モード」の推奨値に合わせてあります。-mlxや-nvfp4のタグは、Apple Silicon向けのMLX形式です。Ollamaからはollama launch claude --model qwen3.6のように、Claude CodeやOpenCodeのバックエンドとして起動することもできます。

llama.cpp v0.7.0の起動例とMTPの指定

llama.cpp v0.7.0（2026年10月15日リリース）のllama-serverは、-hfでHugging FaceのGGUFを直接取得できます。次の例は、128Kの文脈を確保するため先頭8層の専門家重みをCPUへ退避し、コーディング向けの推奨サンプリング値を指定したものです。llama.cppのmin_pの既定値は0.05なので、モデルカードの推奨値に合わせて--min-p 0を明示します。

llama-server -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL \
  -ngl 99 -c 131072 --n-cpu-moe 8 \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0 --presence-penalty 0

--spec-type draft-mtpは、別のドラフトモデルを指定しなければ、読み込んだGGUFに同梱されたMTP層をそのまま予測に使います（common/speculative.cppで確認）。そのため、MTP層を含む-MTP-GGUFのほうを指定します。以前の--draft-maxは削除され、指定すると--spec-draft-n-maxを使うよう求めるエラーになります。--n-cpu-moeの値は、VRAMが余る範囲で小さくしていくと速くなります。

v0.7.0では、思考に関する既定値が変わりました。common/arg.cppには、テンプレート引数のpreserve_reasoningを明示しなければtrueにする処理があります。この値はQwen3.6のテンプレートではpreserve_thinkingに読み替えられるため、過去ターンの思考も毎回プロンプトに積まれます。文脈長が足りない環境では--no-reasoning-preserveを付けて切ってください。思考そのものを切るのは--reasoning offで、--chat-template-kwargsでenable_thinkingを渡す方法は非推奨の警告が出ます。

LM Studioの既定値で見落としやすい設定

LM Studioの公式モデルqwen/qwen3.6-35b-a3bには、モデル固有の設定として「Enable Thinking」（既定オン）と「Preserve Thinking」（既定オフ）があります。llama.cpp v0.7.0とは、思考保持の既定値が逆です。一方で、Presence PenaltyとMin Pは、既定のプリセットで無効になっています。モデルカードは一般タスクでpresence_penalty 1.5を推奨しているので、同じ語句を繰り返す出力が出たら、まずここを1.5に設定してください。文脈長の上限に達したというエラーが出たら、モデル読み込み時のContext Lengthを増やします。増やした分は、KVキャッシュとしてメモリを消費します。

vLLM・SGLangでのサーバー運用と推奨パラメータ

モデルカードの起動例は8GPUのテンソル並列（TP=8）ですが、35B-A3Bにそこまでの規模は要りません。vLLM公式レシピの必要VRAMの下限は、BF16が84GB（H200 1枚かH100 2枚）、Qwen公式のFP8版が42GB（H100 1枚など）、NVIDIAのNVFP4版が21GBです。推奨バージョンは、モデルカードの記載でvLLM 0.19.0以上、SGLang 0.5.10以上です（2026年10月24日時点の最新はvLLM 0.32.0、SGLang 0.5.22）。サービング基盤の比較はLLM Servingの仕組みと主要フレームワーク比較にまとめています。

vLLM 0.32でのMTP指定と思考の切り方

vllm serve Qwen/Qwen3.6-35B-A3B --port 8000 \
  --tensor-parallel-size 2 --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

vLLM公式レシピは、MTPのドラフト数を3トークンとしています（RTX PRO 6000とRTX 5090のNVFP4構成だけ4トークン）。モデルカードのMTP例は"method":"qwen3_next_mtp"のままですが、vLLM 0.32.0のvllm/config/speculative.pyでは、この値は非推奨の警告付きでmtpに読み替えられます。新しく書く設定ではmtpと書いてください。

--reasoning-parser qwen3は、思考部分を応答のreasoningフィールドに分離します。--tool-call-parser qwen3_coderは、Qwen3.6のチャットテンプレートが使う<tool_call><function=...><parameter=...>形式のツール呼び出しを、OpenAI互換のtool_callsに変換します。サーバー全体で思考を切るなら--default-chat-template-kwargs '{"enable_thinking": false}'を付けます。画像を使わない用途では--language-model-onlyを付けると、視覚エンコーダ分のメモリをKVキャッシュに回せます。

NVFP4版とDGX Spark・RTX 5090での公式構成

Blackwell世代のGPUでは、NVIDIAが量子化したnvidia/Qwen3.6-35B-A3B-NVFP4（重み23.4GB）が使えます。vLLM 0.28.0以上が必要です。レシピは4つの構成を検証済みとしており、DGX Spark（GB10）は統合メモリをホストと共有するため--gpu-memory-utilizationを0.5までに抑えます。RTX 5090（32GB）では文脈長が64Kまでに制限されます。

レシピには、2026年8月31日にDGX Spark 1台（TP=1・vLLM 0.28.0）で測った結果が載っています。入力8Kトークン・出力256トークン・同時実行1で、プリフィルは6,265トークン毎秒、デコードは97.7トークン毎秒、平均の応答完了時間は3.95秒でした。卓上機1台で、対話に使える速度が出ていることになります。

SGLangの起動例とmem-fraction-static

python -m sglang.launch_server --model-path Qwen/Qwen3.6-35B-A3B --port 8000 \
  --tp-size 2 --mem-fraction-static 0.8 --context-length 262144 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder \
  --speculative-algo NEXTN --speculative-num-steps 3 \
  --speculative-eagle-topk 1 --speculative-num-draft-tokens 4

--mem-fraction-static 0.8は、GPUメモリの80%を重みとKVキャッシュの静的領域に割り当てる指定です。残りは活性化やCUDAグラフなどの作業領域に回ります。起動時や画像入力時にOOM（メモリ不足）が出る場合は、この値を下げます。

262Kを超える文脈のYaRN設定

1,010,000トークンまで伸ばす場合は、YaRNのRoPEスケーリングを指定します。vLLMでは--rope-scalingではなく--hf-overridesで、text_configの下のrope_parametersを上書きします。

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve Qwen/Qwen3.6-35B-A3B --tensor-parallel-size 2 \
  --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は「静的」で、入力が短いときにも拡大係数がかかるため、短文の性能が下がる可能性があります。モデルカードは、長文脈が必要なときだけ設定すること、想定長が524,288トークンならfactorを2.0にすることを勧めています。常時オンにする設定ではありません。

思考モード・Preserve Thinkingとサンプリング設定

Qwen3.6は、既定で思考モードになっています。回答の前に<think>ブロックを出力します。Qwen3にあった/think・/nothinkのソフトスイッチは、公式にはサポートされていません。思考を切るには、APIのリクエストでchat_template_kwargsに{"enable_thinking": false}を渡します。

チャットテンプレートで確かめた思考の扱い

Qwen3.6で新しく加わったのが、過去ターンの思考を残すPreserve Thinkingです。その効果を確かめるため、Hugging Faceのchat_template.jinjaを取得し、Jinja2で3つの条件をレンダリングしました。会話は「1+1は？」への回答（思考内容「足し算をする。」付き）のあとに、2問目を続けたものです。

# 既定（enable_thinking・preserve_thinkingとも未指定）
<|im_start|>assistant
2です。<|im_end|>
...
<|im_start|>assistant
<think>

# enable_thinking: false
...
<|im_start|>assistant
<think>

</think>

# preserve_thinking: true
<|im_start|>assistant
<think>
足し算をする。
</think>

2です。<|im_end|>

既定では、1問目の思考はプロンプトから消え、回答の「2です。」だけが残ります。enable_thinking: falseは、生成処理を強制停止する設定ではなく、テンプレートで非思考モードを指定する設定です。具体的には、空の<think></think>をテンプレートが先に書き込み、モデルに思考を飛ばさせます。preserve_thinking: trueでは、過去の思考がそのまま次のプロンプトに入ります。

この結果からわかるのは、思考保持をオンにすると、エージェントのように何十ターンも続く会話では思考の分だけ入力が増え続けるということです。モデルカードは、同じ前提の考え直しが減り、KVキャッシュの再利用率が上がるとしています。一方で、文脈長に余裕がない24GB GPUや16GB GPUでは、早く上限に達します。前述のとおりllama.cpp v0.7.0は既定でオン、LM Studioは既定でオフなので、使う実行環境の既定値を確かめてください。

モード別の推奨サンプリング値

3つのモードとも、min_pは0.0、repetition_penaltyは1.0です。出力長は通常32,768トークン、競技数学やプログラミングの難問では81,920トークンが推奨されています。presence_penaltyを上げると繰り返しは減りますが、他の言語が混ざる副作用があるとモデルカードに書かれています。日本語の出力に英語や中国語が混ざるなら、presence_penaltyを下げてみてください。

派生モデル：abliterated版とAMD NPU版（FastFlowLM）

Apache 2.0で公開されたため、第三者による改変版や、特定のハードウェア向けの変換版が出ています。検索で目にすることが多い2系統を、本家との違いの観点で整理します。

huihui-aiのabliterated版（拒否応答の除去）

huihui-ai/Huihui-Qwen3.6-35B-A3B-abliteratedは、本家公開の2日後（2026年4月18日）に登録された改変版です。モデルカードによると、「abliteration」という手法で、拒否応答に関わる内部表現を重みから取り除いています。ライセンスは本家と同じApache 2.0です。Ollamaのhuihui_ai/qwen3.6-abliterated:35bはQ4_K_M（23.9GB）で、マニフェストに視覚用のprojectorもdraft_num_predictも無いため、Ollamaでは画像入力とMTPを使えません。

モデルカード自身が、安全フィルタが大きく減っていること、研究・検証用途に限り、本番や一般公開のサービスには使わないよう勧めることを明記しています。業務で使うなら本家を選び、拒否が多すぎる場合はシステムプロンプトや用途の切り分けで対処してください。改変版の出力の責任は、使った側が負うことになります。

FastFlowLMでRyzen AIのNPUを使う版

AMDのRyzen AIシリーズのNPU（XDNA2：Strix・Strix Halo・Kraken・Gorgon Point）で動かすなら、FastFlowLM（FLM）が対応しています。v0.9.45（2026年7月11日）で追加され、タグはqwen3.6-moe:35b-a3bです。v1.0.3（8月27日）で量子化がQ4_1からQ4_Kに変わったため、それ以前に取得した重みはflm pull qwen3.6-moe:35b-a3bで取り直す必要があります。文脈長は既定32K・最大256Kで、動画入力には未対応です。

flm run qwen3.6-moe:35b-a3b     # 対話
flm serve qwen3.6-moe:35b-a3b   # OpenAI互換サーバー

FastFlowLMの公式ベンチマーク（Ryzen AI 7 350・メモリ96GB・FLM v0.9.45）では、デコードが文脈1Kで17.48トークン毎秒、32Kで11.19トークン毎秒でした。プリフィルは1Kで102トークン毎秒、32Kで281トークン毎秒です。外付けGPUの無いノートPCで35B級を動かせる選択肢です。FLMのモデル一覧はこのモデルの所要メモリを22.1GiBとしており、Windows版の導入手順はメモリ32GB以上を推奨しています。WindowsとLinuxに対応します。WindowsではNPUドライバ32.0.203.311以上が必要で、Linuxでは専用の導入手順に従います。NPU用のカーネルはソース非公開ですが、独自のバイナリライセンスにより、商用を含めて無償で使えます。

Apache 2.0の商用利用とAPIの料金

重みのライセンスはApache License 2.0です。社内利用、商用サービスへの組み込み、ファインチューニングした派生モデルの公開まで、利用料なしで認められています。再配布時は、ライセンス文を提供し、変更したファイルには変更した旨を明示します。派生物をソース形式で配布する場合は、関係する著作権・特許・商標・帰属表示を保持します。元の配布物にNOTICEがある場合は、関係する帰属表示も継承します。Qwen3.5世代の大型モデルも含めたライセンスの比較は、Qwen3.5-397B-A17BのApache 2.0商用利用とAPI料金の解説にあります。

自前でGPUを持たない場合は、APIとして使えます。Alibaba Cloud Model StudioのモデルIDはqwen3.6-35b-a3bで、Model Studioの料金ページ（2026年10月24日確認）では、100万トークンあたりの単価がリージョンによって異なります。

同じInternationalでqwen3.6-27bは入力$0.6・出力$3.6なので、35B-A3Bは27Bの約6割の価格です。思考トークンも出力として課金されるため、思考オンでは出力トークン数そのものが増えます。OpenRouterでは10社がこのモデルを提供しており（2026年10月24日時点）、最安はDarkbloomのFP4です。事業者ごとに量子化（FP4・FP8）が違うため、単価だけで選ぶと精度が変わります。OpenRouterでは、リクエストのproviderでquantizationsや事業者を指定すると、使う量子化を固定できます。

上位のホスト型モデルとの違いはQwen3.6-Plusの1Mコンテキストと階梯課金で比較しています。自社のデータを外に出さずにローカルLLMを業務へ組み込む場合の、モデル選定から運用設計までの進め方は、生成AI導入支援で相談を受けています。

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

次の条件では、35B-A3Bの採用を見送るか、追加の検証を前提にしてください。

• GPUとメインメモリの空きを合わせても約25GBに届かない：4bitの重み約22GBに、KVキャッシュと作業領域が加わります。OSや他のアプリが使う分を除いた空き容量で判断してください。2bit級（11〜12GB）なら載りますが、採用前に、対象コードのテスト通過率を4bit版と比べる必要があります。比べられないなら、Qwen3.5の9B以下か、Gemma 4の小型モデルを選ぶほうが確実です。
• TAU3-BenchやHLEに近い課題が主な用途：この2指標は、前世代のQwen3.5-35B-A3Bからわずかに下がっています。既にQwen3.5-35B-A3Bで運用しているなら、乗り換えの優先度は低くなります。ただし、MCPMarkのようにツール操作で大きく伸びた指標もあるため、用途に近い評価で確かめてから判断します。
• レビューなしでパッチを自動適用する：SWE-bench Proは49.5で、難しい課題の約半分は解けていません。Qwen3.6-27Bの53.5やQwen3.8-27Bの61.7でも同じで、スコアの高いモデルに替えるだけでは、無人で反映してよい根拠になりません。対象リポジトリのテストと、反映前のレビュー工程を残してください。

逆に、24GB GPU1枚で長いリポジトリを読ませ、人が確認しながら速く回したい場面では、メモリ容量と応答速度の両面から有力な候補です。

よくある質問

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

重みだけで、4bit量子化（Q4_K系・MXFP4_MOE）が約22GB、8bitが約37GB、BF16が約72GBです。これにKVキャッシュが加わり、BF16のKVで32Kトークンなら約0.6GiB、262Kトークンなら約5GiBです。24GiB GPUなら、4bitで64Kトークン前後までを全層GPUに載せられる見込みです。16GBや12GBのGPUでは、llama.cppの--n-cpu-moeで専門家重みの一部をメインメモリへ退避します。

Qwen3.6のMTPとは何ですか？使うと速くなりますか？

MTP（Multi-Token Prediction）は、本体とは別の1層（約0.85B）で数トークン先を予測し、本体がまとめて検証する投機デコードの仕組みです。予測が受理されると、本体の1回の検証で複数トークンを確定できます。ただし、予測と検証の処理が増えるため、速くなる幅は受理率、ハードウェア、同時実行数で変わります。vLLMでは--speculative-config '{"method":"mtp","num_speculative_tokens":3}'、llama.cppでは--spec-type draft-mtpで有効にします。Ollamaの既定タグのllamacpp用設定では、最初からMTPが有効です。仕組みの詳細はMTP（Multi-Token Prediction）の仕組みと投機的デコーディングでの使い方で解説しています。

OllamaでQwen3.6-35B-A3Bを使うときのモデル名は何ですか？

ollama run qwen3.6:35b-a3bです。qwen3.6:latestとqwen3.6:35bも同じ配布内容を指し、llamacpp用はMTP付きQ4_K_Mです。MLX用の重みも別に含まれます。コーディング向けのサンプリング値にしたqwen3.6:35b-a3b-codingや、8bitのqwen3.6:35b-a3b-q8_0もあります。qwen3.6:27bは密モデルの27Bなので、取り違えに注意してください。

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

できます。重みのライセンスはApache 2.0で、商用サービスへの組み込みや、ファインチューニングした派生モデルの公開も認められています。再配布時は、ライセンス文の提供、変更したファイルへの変更表示、配布形態に応じた権利・帰属表示の保持、元のNOTICEに含まれる関係する帰属表示の継承が必要です。APIとして使う場合は、モデルのライセンスではなく、提供事業者の利用規約と料金体系が適用されます。

Qwen3.6で思考モードをオフにするにはどうすればよいですか？

vLLMやSGLangのOpenAI互換APIでは、リクエストのextra_bodyに{"chat_template_kwargs": {"enable_thinking": false}}を入れます。サーバー全体で切るなら、vLLMの起動時に--default-chat-template-kwargs '{"enable_thinking": false}'を付けます。llama.cppのllama-serverでは--reasoning offです。Qwen3にあった/nothinkをプロンプトに書く方法は、Qwen3.6では公式にサポートされていません。非思考モードでは、temperature 0.7・top_p 0.80が推奨値です。

関連記事

• Qwen3.6-27Bとは｜必要スペック・メモリ(VRAM)・FP8/GGUFサイズと動かし方、ベンチ比較
• MoE（Mixture of Experts）とは？疎活性化とルーターの仕組み・VRAM要件と採用判断を実装者向けに解説
• MTP（Multi-Token Prediction）とは？LLMの複数トークン予測の仕組みと投機的デコーディングでの使い方
• Qwen3.6-Plusとは｜1Mコンテキスト・階梯課金・3.7世代との選び分けを実装目線で解説【2026年7月時点】
• Qwen3とは？読み方・モデル一覧・72Bの有無・商用利用と動かし方