Qwen3.6-35B-A3B とは？MoE型マルチモーダル LLM のローカル実行ガイド

Qwen3.6-35B-A3B は、Alibaba が HuggingFace 上で配布する総350億・動作30億パラメータの MoE 型マルチモーダル LLM である。公式モデルカード上は総35B・推論時3B active と明記されるが、配布サイトやランタイムのメタデータでは 36B params と表示される箇所もあるため、本記事では概数として「総350億」と表記する。総パラメータは大きいが、推論時に動くのは30億分だけというのが MoE の肝で、量子化版を使えばコンシューマ GPU でも扱える射程に入る。公式モデルカードはコーディング系・視覚言語系の双方でベンチマークを掲げており、ライセンスは Apache 2.0、コンテキストはネイティブ 262,144 トークン（最大約101万トークンまで拡張可能）とされている。総350億という数字から「重そう」に見えるが、当サイトで Q4 量子化版を Ollama 上で計測したところ、RTX 5080 + RTX 5060 Ti のデュアル構成で約124 tokens/秒、RTX 5080 単体でも約68 tokens/秒だった（いずれも短文・think=false 条件）。スペックと実行環境、実測値を整理する。

概要：Qwen3.6-35B-A3B の位置づけ

Qwen3.6-35B-A3B は、Alibaba が展開する Qwen 系列のオープンウェイト版で、ビジョンエンコーダを内蔵したマルチモーダル LLM である。同シリーズには Alibaba Cloud Model Studio 経由の商用 API 版「Qwen3.6-Plus」もあるが、Qwen3.6-35B-A3B はその後に公開された Qwen3.6 世代のオープンウェイト派生モデルであり、Plus と同一モデルとは限らない。

設計の読みどころは2つ。1つ目は総パラメータ350億に対し動作時は30億しか使わない MoE (Mixture of Experts) の圧縮効率。2つ目はビジョン能力の組み込みで、公式モデルカードは視覚言語ベンチマークで Anthropic Claude Sonnet 4.5 を上回るとするスコアを掲載している（MMMU 81.7 対 79.6、RealWorldQA 85.3 対 70.3、OmniDocBench1.5 89.9 対 85.8、VideoMMU 83.7 対 77.6）。いずれも Alibaba 公式の自己申告値である。

注意したいのは、このモデルが視覚言語だけのモデルではない点だ。公式モデルカードはコーディング・推論系のベンチマークも掲げており（SWE-bench Verified 73.4、Terminal-Bench 2.0 51.5、MMLU-Pro 85.2、GPQA 86.0、LiveCodeBench v6 80.4）、agentic coding を主要な訴求の一つにしている。同じ Qwen3.6 でも Dense 構成のQwen3.6-27B はコーディング寄りの別モデルとして比較対象になるが、35B-A3B も「マルチモーダル＋速度＋コーディング」の複合モデルとして見るのが公式の位置づけに近い。これらは公式（開発元）の提示値であり、本記事では同条件での独立再現は確認していない。なお Terminal-Bench 2.0 の公開リーダーボードや Artificial Analysis のような別条件の第三者評価は存在するため、公式値と第三者値は評価条件を分けて読みたい。

スペック詳細とストレージ要件

配布されている重みは複数の精度・量子化があり、容量で土俵が大きく変わる。容量は10進の GB と2進の GiB で値が変わるため、両方を併記する。

1M 級のコンテキストは商用版 Qwen3.6-Plus が既定で備えるが、オープン公開版の 35B-A3B も公式モデルカード上はネイティブ 262,144 トークンに対応し、最大約101万トークンまで拡張可能とされている。ただし 262,144 トークンはモデル仕様上の対応長であり、Ollama で実際に使える有効コンテキスト長は設定と VRAM に依存する。Ollama の既定コンテキスト長は VRAM 別に決まり（公式では 24GiB 未満で 4K、24〜48GiB で 32K、48GiB 以上で 256K）、16GB GPU で 256K 級のコンテキストを使えることは本記事では確認していない。

ここで押さえたいのは、Q4_K_M クラスのモデルファイルは約21〜24GB規模で、16GB GPU の VRAM に全量が常駐するわけではない、という点だ。実際にどう動くかは次の実測で示す。

ローカル実行の前提とランタイム

公式モデルカードが互換先として挙げているのは Transformers、vLLM、SGLang、KTransformers で、GitHub の README では llama.cpp（量子化版経由）や MLX も案内されている。LM Studio はコミュニティ配布の GGUF 経由の選択肢にあたる。Ollama についても、GGUF 量子化版を引くか ollama create で登録すれば動く。当サイトでは Ollama 上の qwen3.6:35b-a3b（Q4_K_M クラス）を計測対象にできた。

個人ユーザーが最短で試すなら、GGUF 量子化版を Ollama か LM Studio に読み込み、自分の GPU で VRAM 使用量とトークン生成速度を計測するのがよい。RTX 4060 8GB（ノート）のような小容量環境での動作報告（Reddit の投稿を当サイトで整理した記事）もあり、thinking が暴走して止まらなくなる症状とその対処など、MoE 特有のつまずきはそちらが詳しい。

当サイトの実測：RTX 5080 と デュアル GPU

Q4_K_M クラスの qwen3.6:35b-a3b を Ollama 上で動かし、トークン生成速度と GPU の VRAM 使用量を計測した。下表は3回計測の中央値である（IQR 判定による除外対象はなかった）。

※VRAM 使用ピークは nvidia-smi の memory.used（表示用常駐分を含む GPU 全体の使用量）であり、モデル単体のロード増分ではない。

読みどころは2つ。1つ目は速度で、デュアル構成では約123.8 tokens/秒だった。これは当サイト環境・短文・think=false・Q4_K_M 条件での値で、他モデルや他環境との一般的な速度順位を示すものではない。2つ目は VRAM と常駐率の関係だ。Q4_K_M のモデルファイルは約21〜24GB あるため、RTX 5080 単体（16GB）では全量が VRAM に載らず、当サイト計測では常駐率62%（残り38%は CPU 側）になり、速度は約67.7 tokens/秒に落ちた。一方、16GB を2枚使うデュアルでは常駐率100%（モデルが2枚の GPU に分散ロードされ CPU オフロードが消える）となり、速度が約1.8倍に伸びた。これは「16GB×2 が常に32GBの単一 VRAM として使える」という意味ではなく、Ollama がモデルを2枚に分散配置した結果である。「FP8 版で RTX 5090 32GB が要る」という見え方は高精度版に限った話で、Q4 量子化版なら 16GB クラスでも（単体は一部オフロード、デュアルは常駐率100%で）動く、というのがこの短文条件での実測の結論になる。ただしこれは短文・低コンテキストでの速度確認であり、Qwen 公式は複雑タスクで thinking 能力を保つには少なくとも 128K トークン程度のコンテキスト維持を推奨している。長文 agentic 用途や thinking 込みの本来の運用を 16GB 級で十分にまかなえることを示すものではなく、長いコンテキストを確保するにはさらに VRAM が要る。

測定条件は次の通り。Ollama 0.30.7、NVIDIA ドライバ 610.47、Windows。モデルタグ qwen3.6:35b-a3b（digest 07d35212…、タグ更新 2026-05-06）、think=false（Ollama 側の実行条件。Qwen3.6 は既定で思考モードのため Ollama の think フラグで無効化した）、num_predict=512、temperature・seed・num_ctx は固定せず Ollama 既定値、3回計測の中央値（IQR による除外対象はなし）、固定の日本語プロンプト、各測定は同一ロード状態で連続実行（測定ごとにアンロードはしていない）、GPU 配置と割当コンテキストは ollama ps（PROCESSOR / CONTEXT）と Ollama API の size_vram/size で確認、計測日 2026-06-18（計測時の Ollama は 0.30.7。公開時点の最新は v0.30.10・2026-06-17 で、ランタイム更新により速度・メモリ挙動は変わり得る）。temperature・seed・num_ctx を固定していないため、これは厳密な再現ベンチではなく、当サイト環境での参考比較として読んでほしい。計測しているのは生成速度・TTFT・GPU 使用 VRAM であり、回答品質、長文・画像入力時の挙動、num_ctx を増やした場合の VRAM 増加は対象外で、これらは別途検証が要る。デュアル構成の VRAM プールの挙動はRTX 5080 + 5060 Ti のデュアル GPU 構成で扱っている。

性能と特徴：MoE と視覚言語の組み合わせ

MoE 設計の狙いは推論コストの軽さである。同じ「35B」を名乗っても、Dense なら 350億分の計算が走るのに対し、MoE なら 30億分しか走らない。上の実測でも短文生成では高い tokens/秒が出ているが、速度差には量子化、GPU 分散、CPU オフロード量、ランタイム実装、生成設定など複数の要因が絡むため、本記事の計測だけで速度を MoE 単独の効果に分解しているわけではない。MoE の3B active 設計が速度に寄与し得る、という読み方にとどめておきたい。

視覚言語タスクについては、少なくとも公式モデルカード上では MMMU・RealWorldQA・OmniDocBench・VideoMMU などで高いスコアが提示されている（前掲）。これら公式の提示値に従えば、画像を含む RAG、ドキュメント OCR 後の構造化、多言語対応などの用途で有力候補に入り得る。

一方、コーディングや推論系の公式スコア（前掲）は開発元の提示値で、本記事では同条件での独立再現を確認していない。Terminal-Bench 2.0 の公開リーダーボードや Artificial Analysis のような別条件の第三者評価は存在するが、評価条件が異なるため、公式値とは分けて読むのが安全だ。量子化後の品質はタスクと量子化方式に依存するため、Q4/Q5 GGUF を使うなら自分のタスクで一度品質を確かめるのが確実だ。速度が出ることと回答品質が保たれることは別の軸である。

既存モデルとの比較：35B-A3B と 27B、ローカルとクラウド

同じ Qwen3.6 でも、MoE の 35B-A3B と Dense の 27B は構成も狙いも分かれる。どちらもコーディングを訴求するが、35B-A3B は動作パラメータが少なく速度とマルチモーダルを併せ持ち、27B は密な推論が持ち味だ。M5 Pro 上での35B-A3B と 27B を AI 用途で比較した記録もあり、サイズの数字だけでは選べないことがそこで見えてくる。

クラウドとの距離感の参考として、当サイトが実施したローカル8モデル実測（RTX 5060 Ti 16GB, agent_bench 11タスク）の結果を併記する。これは 35B-A3B 自体のスコアではなく、同クラスのローカル LLM が Claude Sonnet とどれくらい差があるのかの相場観として読んでほしい。※下表は本記事の対象モデル（35B-A3B）の実測ではなく、別クラスのローカルモデルの参考値である（プロンプト・採点基準・モデルのスナップショットはリンク先記事の条件に依存）。

この 11タスクという狭いセットでは、E4B〜14B クラスのローカルモデルが claude-sonnet-4-6 API と同点だった。ただしこれは当サイトの agent_bench 11タスクでの結果であり、Claude 全般やローカル LLM 全般の性能が同等という意味ではない。複雑な長文推論、マルチステップの計画立案、視覚言語タスクは含まれておらず、ベンチマーク依存の数値は対象タスクの範囲を確認せずに一般化してはならない。Qwen3.6-35B-A3B が視覚言語ベンチで優秀である可能性は十分にあるが、テキスト推論やコーディングでの優位性は別の検証が必要になる。

用途別の使いどころ

導入を検討する側の立場別に、現時点で取れる現実的な選択を整理する。

情シス・DX 担当者

短期は「焦って動かない」が無難。公式スコアの第三者検証がそろっていないこと、量子化版の品質が安定するまで時間がかかることが理由になる。中期的には、機密データを外に出せない用途（法務文書レビュー、人事情報を扱う RAG、医療記録処理）の候補として名前を残しておけばよい。ただしローカル推論であっても、ログ保存、外部ツール連携、RAG ストア、アクセス権限、監査、業法・社内規程への適合は別途必要で、「ローカルだから安全」と単純化はできない。また本記事は医療・法務・人事のような高リスク用途での正確性・法令適合・監査要件を検証したものではなく、これらの用途では専門家レビューと運用統制が前提になる。

ローカル LLM 運用者

Q4 量子化版の GGUF を Ollama か LM Studio で読み込み、自分の GPU で速度・TTFT・常駐率・VRAM を計測しておくとよい。上の実測どおり、16GB を2枚使うデュアル構成なら短文条件で約124 tokens/秒、単体16GB でも一部 CPU オフロード込みで約68 tokens/秒だった。GPU が1枚で VRAM に余裕がない場合は、より小さい量子化を選ぶとファイルが小さくなり VRAM に載る割合が増える。ただし品質と安定性は量子化方式・num_ctx・環境で変わるため、同じタスクで確認するとよい。

SaaS プロダクト開発者

API から手早く検証するなら、Alibaba Cloud Model Studio 経由の商用 API 版を叩くのが候補になる。Model Studio の掲載モデル・名称・価格はリージョンと時期で変わるため、本記事では特定のモデルIDを固定せず、利用リージョンと当日の公式モデル一覧で正しいモデルIDを確認してから呼び出す前提とする。費用対効果は入力／出力トークン量、リージョン、キャッシュ、既存 GPU 費用、人件費で変わるため、月額の損益分岐を語るなら前提計算を併記すべきだ。OSS 版を自社で回す合理性は、画像を含む RAG や OCR 後の構造化など、既存 API コストが大きい案件ほど成立しやすい。

個人開発者・プロンプト設計者

まずは Q4〜Q5 の GGUF 量子化版を Ollama か LM Studio で試すのが現実的な出発点。無理に BF16 や FP8 を動かそうとせず、量子化版で速度と品質のバランスを見るところから始めるとよい。

よくある質問

Qwen3.6-35B-A3B と Qwen3.6-Plus は何が違うのでしょうか。

Qwen3.6-Plus は Alibaba Cloud 経由の商用 API 版です。一方の Qwen3.6-35B-A3B は HuggingFace で配布されるオープンウェイト版で、総350億・動作30億パラメータの MoE モデル、ライセンスは Apache 2.0 です。オープン版もネイティブ 262,144 トークンに対応し、最大約101万トークンまで拡張可能とされています。

個人の PC で動かせますか。

Q4_K_M クラスの GGUF 量子化版（モデルファイル約21〜24GB）が現実的な選択肢です。当サイトの RTX 5080 16GB 環境では、短文・低コンテキスト条件で一部 CPU オフロード込みで実行でき、単体で約67.7 tokens/秒、デュアル（RTX 5080 + RTX 5060 Ti）で約123.8 tokens/秒でした（短文・3回中央値）。16GB 級 GPU 一般での速度・安定性や、長文・画像入力時の可否は、GPU 世代・システム RAM・num_ctx・量子化・ランタイムに依存します。ただし単体16GB では全量が VRAM に載らず、当サイト計測で常駐率62%（38%は CPU オフロード）です。長い入力や画像入力、num_ctx を大きくすると VRAM はさらに増えます。BF16・FP8 はそのままでは RTX 5090 級でもオフロードが要るため、まずは量子化版から試すのが現実的です。なお 262,144 トークン対応はモデル仕様上の値で、Ollama で実際に使える有効コンテキスト長は VRAM と設定に依存します（16GB 級では既定で数K 程度）。

Ollama で使えますか。

使えます。当サイトでは Ollama 上で qwen3.6:35b-a3b（Q4_K_M クラス）を実行・計測しました。公式レジストリの掲載状況は時期で変わるため、見当たらない場合は HuggingFace の GGUF を ollama create で登録する手があります。Qwen 公式が案内する主な実行先は Transformers、vLLM、SGLang、KTransformers、llama.cpp、MLX です。LM Studio は Community 配布の GGUF／MLX を使う選択肢として扱ってください。

公式が言う「Claude Sonnet 4.5 超え」はどこまで信用できますか。

ここでいう「超え」は、公式モデルカード上の視覚言語ベンチで Claude Sonnet 4.5 を上回る項目がある、という意味です。総合性能・実運用品質・コーディング能力で一律に上回ることを本記事は確認していません。公式モデルカードは視覚言語ベンチで Claude Sonnet 4.5 を上回るスコア（MMMU、RealWorldQA、OmniDocBench、VideoMMU など）を掲載していますが、これは開発元の自己申告値です。コーディング・推論系のスコアも掲載されていますが、これらは開発元の提示値です。本記事では同条件での独立再現は確認していません（Terminal-Bench 2.0 公開リーダーボードや Artificial Analysis など別条件の第三者評価は存在します）。「視覚言語タスクには有望、総合性能は条件を分けて要検証」と捉えるのが妥当です。

商用利用は可能ですか。

Qwen3.6-35B-A3B の公式 HuggingFace モデルカードは Apache-2.0 ライセンスと表示しています。商用利用は Apache-2.0 の条件遵守（著作権表示・ライセンス文・NOTICE 等の扱い、商標の非許諾）が前提です。コミュニティの量子化版を使う場合は配布元のモデルカードとライセンス継承を確認してください。Plus 版を商用 API として使う場合は、Alibaba Cloud の利用規約が適用されます。

まとめ

Qwen3.6-35B-A3B の要点を3点に絞る。

1点目、350億/30億 MoE という設計と Apache-2.0 ライセンスにより、Hugging Face で重みを取得できるオープンウェイトモデルが、少なくとも公式の視覚言語ベンチでは商用 API 級モデルと競合するスコアを掲げた（API 利用料・ホスティング費・電気代まで無料という意味ではない）。コーディング・推論系のスコアも公式に掲げられているが、いずれも開発元の自己申告で、本記事では独立再現を確認していない。

2点目、「重くて動かしづらそう」という総パラメータ350億からの直感は、少なくとも当サイトの短文・think=false・Q4_K_M 条件では過剰だった。Q4_K_M クラスは約21〜24GB のファイルで、16GB GPU 単体では一部 CPU オフロード込みになるが、当サイト実測では単体で約67.7 tokens/秒、デュアル構成（常駐率100%）で約123.8 tokens/秒が出た。FP8・BF16 をそのまま載せる前提で「RTX 5090 級が要る」と判断すると、現実的な運用像を見誤る。

3点目、ただし速度と回答品質は別の軸で、公式ベンチの同条件再現は本記事で未確認だ（別条件の第三者評価は存在する）。過剰な期待も過剰な失望も避け、自分のタスクで品質を確かめるのが結局は近道になる。

本記事の情報は記載時点のもの。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。実測値は 2026-06-18 時点・当サイト環境（Ollama 0.30.7、Q4_K_M クラス、think=false、num_predict=512、短文プロンプト3回の IQR フィルタ後中央値）のもので、量子化・コンテキスト長・ドライバ・ランタイム版で変動する。一定期間経過した内容は再検証を推奨する。

参考資料

• Qwen3.6-35B-A3B 公式モデルカード（Hugging Face）
• QwenLM/Qwen3.6（GitHub・実行とランタイム案内）
• qwen3.6:35b-a3b（Ollama ライブラリ・量子化タグとサイズ）
• lmstudio-community/Qwen3.6-35B-A3B-GGUF（コミュニティ配布 GGUF・本文の約21.2GB はこの配布元の Q4_K_M 表示値）