Qwen3.6-35B-A3B は、Alibaba が HuggingFace 上で配布する総350億パラメータ・動作30億パラメータの MoE 型マルチモーダル LLM である。FP8 量子化版で 34.87GB に収まり、コンシューマ GPU の上位機種で扱える射程に入る。視覚言語ベンチマークの大半で Claude Sonnet 4.5 を上回ると公式が主張する点でも注目されているモデルで、ローカル実行を検討する個人ユーザーにとって押さえておきたい一本である。
- Qwen3.6-35B-A3B は総350億/動作30億パラメータの MoE モデル、FP8 版は 34.87GB
- 視覚言語ベンチマークでは Claude Sonnet 4.5 超えを謳うが、テキスト推論やコーディングは独立検証待ち
- Ollama 未対応のため、個人で試すなら LM Studio v0.4.12 以降か HuggingFace/vLLM 経由が現実解
概要：Qwen3.6-35B-A3B の位置づけ
Qwen3.6-35B-A3B は、Alibaba が展開する Qwen 系列のオープンソース版で、ビジョンエンコーダを内蔵したマルチモーダル LLM である。同シリーズにはクラウド側の商用版「Qwen3.6-Plus」(1M コンテキスト対応) があり、こちらが先行して投入されたうえで、HuggingFace に降りてきたのが本モデルにあたる。
設計上の読みどころは2つ。1つ目は総パラメータ350億に対し動作時は30億しか使わないという MoE (Mixture of Experts) の圧縮効率。2つ目はビジョン能力の組み込みで、これが「Anthropic Claude Sonnet 4.5 を VQA 系ベンチマークで上回った」という公式主張の根拠になっている。
ただしこの主張は「視覚言語ベンチマークの大半で」という限定付きで、テキスト推論・コーディング・長文要約などについては公式比較が出ていない。読み解くうえでこの点は前提として置いておきたい。
スペック詳細とストレージ要件
提供されている重みは BF16 (フル精度) と FP8 量子化版の2種類。容量は次の通りである。
| 精度・量子化 | サイズ・要件 |
|---|---|
| BF16 (フル精度) | 71.9GB、コンシューマ GPU 1枚での常駐は不可能 |
| FP8 量子化版 (Qwen3.6-35B-A3B-FP8) | 34.87GB、RTX 5090 (32GB) でも CPU オフロード併用が必要 |
| 総パラメータ | 350億 (MoE) |
| 動作パラメータ | 30億 (推論時にアクティブ化) |
| マルチモーダル対応 | ビジョンエンコーダ内蔵 |
1M コンテキストは Plus 版に限定されており、オープン公開された 35B-A3B 側の最大コンテキストは公式リポジトリの記載に従うのが正しい。Alibaba は OSS 版で話題を作り、長文処理が必要な商用顧客は Plus 版に誘導する二段階の構造を取っている。
ローカル実行の前提とランタイム
公式に動作確認されているランタイムは LM Studio v0.4.12 以降、HuggingFace transformers、vLLM の3つである。注意点は Ollama 未対応で、Ollama レジストリに公式 slug が存在していないこと。Ollama 派のユーザーは、HuggingFace から GGUF を落として ollama create で手動登録する手段はあるが、Modelfile の試行錯誤を覚悟する必要がある。
個人ユーザーが最短で試すなら次の流れになる。LM Studio を v0.4.12 以降にアップデートしたうえで FP8 版を読み込み、VRAM 使用量とトークン生成速度を自分の GPU で計測する。FP8 版を RTX 5090 で動かす場合、CPU オフロード併用時の実測速度は 15〜30tokens/秒 程度に落ちる可能性が高い (公式ベンチマーク未公表のため推測含む)。
コミュニティが配布する GGUF 量子化版 (Q4_K_M 等) を使う選択肢もある。4bit まで絞れれば 17〜20GB 前後に収まる計算で、RTX 4090・5080・5060 Ti 16GB と一部 CPU オフロードの構成で実用速度に届く可能性がある。
性能と特徴：MoE と視覚言語の組み合わせ
MoE 設計の利点は推論コストの軽さである。同じ「35B」を名乗っても、Dense なら 350億分の計算が走るのに対し、MoE なら 30億分しか走らない。設計次第で推論速度が約10倍違う局面もある。8GB クラスのローカル LLM と同等の推論速度で、350億の知識容量を引けるという構図がこのモデルの肝になる。
視覚言語タスクについては、Qwen シリーズが従来から VQA 系で強いトラックレコードを持つ流れの延長線上にある。Alibaba 公式の主張に従えば、画像を含む RAG、ドキュメント OCR 後の構造化、多言語対応などの用途で有力候補に入る。
一方、独立検証はまだ十分に出そろっていない。LiveBench、MMLU-Pro、HumanEval、SWE-bench Verified などサードパーティベンチでのスコアが公表されるまでは、テキスト推論やコーディングでの実力は「公式が黙っている=要保留」と読み取るのが妥当である。MoE モデルは量子化で性能が落ちやすい傾向があるとされるため (Mixtral シリーズでの観測例)、4bit/5bit GGUF が出てきた際の品質劣化度合いも観測ポイントになる。
既存モデルとの比較：ローカルとクラウドの距離感
Qwen3.6-35B-A3B 自体の独立検証は出ていないため、ここでは当サイトが実施したローカル8モデル実測 (RTX 5060 Ti 16GB, agent_bench 11タスク) の結果を参考値として併記する。同クラスのローカル LLM が Claude Sonnet とどれくらい差があるのかの相場観として読んでほしい。
| モデル | 一致率 (agent_bench 11タスク) |
|---|---|
| claude-sonnet-4-6 (API) | 10/11 タスク一致 (91%) |
| Gemma 4 (8B)（Ollama: gemma4:latest） (ローカル8B) | 10/11 (91%) |
| Phi-4 14B（Ollama: phi4:14b） (ローカル) | 10/11 (91%) |
| DeepSeek R1 8B（Ollama: deepseek-r1:8b） (ローカル) | 10/11 (91%) |
| Gemma 3 12B（Ollama: gemma3:12b） (ローカル) | 9/11 (82%) |
| Mistral 7B（Ollama: mistral:7b） (ローカル) | 9/11 (82%) |
8B〜14B クラスのローカルモデルは agent_bench で Claude Sonnet 4.6 API と同等のスコアに達している。「ローカルはクラウドに劣る」という素朴な直感は、特定タスクセットでは崩れているといえる。
ただし agent_bench の 11タスクは網羅的ではなく、複雑な長文推論、マルチステップの計画立案、視覚言語タスクは含まれていない。Alibaba の主張が「視覚言語ベンチマークの大半で」と限定されていたのと同じ構造で、ベンチマーク依存の数値は対象タスクの範囲を確認せずに一般化してはならない。Qwen3.6-35B-A3B が視覚言語ベンチで優秀である可能性は十分にあるが、テキスト推論やコーディングでの優位性は別の検証が必要になる。
用途別の使いどころ
導入を検討する側の立場別に、現時点で取れる現実的な選択を整理する。
情シス・DX 担当者
短期は「焦って動かない」が正解。独立検証がそろっていないため、ベンチマーク主張の真偽が判断できないこと、Ollama 未対応で PoC のハードルが高いこと、量子化版の品質が安定するまで時間がかかることが理由になる。中期的には、機密データを外に出せない用途 (法務文書レビュー、人事情報を扱う RAG、医療記録処理) の候補として名前を残しておけばよい。
ローカル LLM 運用者
最優先は LM Studio v0.4.12 以降へのアップデート確認。FP8 版を読み込めるか、自分の GPU で VRAM 使用量とトークン生成速度を計測しておく。GGUF 量子化版が出たら、そちらを優先する選択肢もある。
SaaS プロダクト開発者
API から呼ぶだけの検証なら、Alibaba Cloud 経由で Qwen3.6-Plus (1M コンテキスト版) を叩くのが最速。国内データレジデンシーを気にするプロダクトでは、リージョン選定とデータ取り扱い規約を精査する必要がある。OSS 版を自社で回す場合は、画像含む RAG や OCR 後の構造化など、既存の API コストが月100万円を超えている案件で経済合理性が成立する可能性がある。月10万円以下の案件では API 継続が依然として優勢。
個人開発者・プロンプト設計者
HuggingFace のモデル情報をブックマークし、サードパーティの GGUF 量子化版が出たタイミングで LM Studio 経由で試す。無理に BF16 や FP8 を動かそうとせず、4bit〜5bit 量子化を待つのが時間対効果の最適解。
よくある質問
Q. Qwen3.6-35B-A3B と Qwen3.6-Plus は何が違いますか？
Qwen3.6-Plus は Alibaba Cloud 経由の商用 API 版で、1M コンテキスト対応。Qwen3.6-35B-A3B は HuggingFace で配布されるオープンソース版で、総350億・動作30億パラメータの MoE モデル。1M コンテキストなど一部機能は Plus 側に限定されている。
Q. 個人の PC で動かせますか？
FP8 量子化版 (34.87GB) は RTX 5090 (32GB) でも CPU オフロード併用が必要。BF16 版 (71.9GB) はコンシューマ GPU 1枚では不可能。現実的な最短ルートは、コミュニティが作成する 4bit GGUF 量子化版を待ち、LM Studio v0.4.12 以降で読み込む流れ。
Q. Ollama で使えますか？
現時点で Ollama レジストリには登録されていない。HuggingFace の GGUF ファイルを手動で ollama create する方法はあるが、公式 slug 登録を待つほうが確実。LM Studio なら公式対応済み (v0.4.12 以降) なので、Ollama 派でない場合はこちらが早い。
Q. Claude Sonnet 4.5 より本当に性能が高いですか？
Alibaba 公式は「視覚言語ベンチマークの大半で上回る」と主張しているが、テキスト推論やコーディング分野での比較は公表されていない。独立したサードパーティベンチマークが出そろうまでは、「視覚言語タスクでは有望、汎用性能は要検証」という評価が妥当。
Q. 商用利用は可能ですか？
利用条件は HuggingFace の公式モデルカード記載に従う。Qwen シリーズは過去に Apache 2.0 相当の商用可の条件で提供されてきたが、3.6-35B-A3B の正式条件はモデルカードで要確認。Plus 版を商用 API で使う場合は Alibaba Cloud の利用規約が適用される。
まとめ
Qwen3.6-35B-A3B の意味を3点に絞る。
1点目、350億/30億 MoE という設計は、無料でダウンロードできる OSS が商用 API と並ぶ構図を視覚言語分野で成立させた。Alibaba が Claude Sonnet 4.5 を直接指名した意図は、課金の必要性そのものへの挑戦と読める。
2点目、ただし「視覚言語ベンチマークで勝った」という公式主張は、対象を限定した条件付き主張であり、テキスト推論やコーディングでの独立検証はまだ出ていない。サードパーティベンチマークが出そろうまで、過剰な期待も過剰な失望も避けたい。
3点目、今すぐとるべき対応は立場で違う。情シスは独立検証待ち。ローカル LLM 運用者は LM Studio v0.4.12 以降の準備と GGUF 量子化版待ち。SaaS 開発者は Alibaba Cloud 経由の Plus 版検証と、コスト試算の着手。個人開発者は HuggingFace モデル情報のウォッチ。クローズド API と OSS の境界線が視覚言語分野で実質的に溶け始めた転換点として、このモデルは記憶される一本になる。
本記事の情報は記載時点のもの。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
コメント