Qwen 3.6 35B-a3b ローカル運用ガイド｜MoE モデルの実力

70BクラスのDense（密）モデルをRTX 4090で動かそうとした際、VRAM容量の限界によるOut-of-Memory（OOM）エラーや、トークン生成速度が1桁台まで低下する現象に直面したことは、ローカルLLMユーザーにとって共通の課題だろう。こうした「巨大モデルとハードウェア制約のジレンマ」を打破する存在として注目されているのが、Mixture-of-Experts（MoE）アーキテクチャを採用したQwen 3.6 35B-a3bだ。総パラメータ数35B（350億）という規模を持ちながら、推論時にアクティブ化されるパラメータ数を約3B（30億）程度に抑制することで、従来のモデルとは一線を画す極めて高いスループットを実現している。しかし、この高度なMoEモデルを実用レベルで運用するには、4-bit量子化によるメモリ節約術や、LM Studio、Ollama、vLLMといった推論エンジンごとの特性理解、さらにはMac Studio M3 Ultraのユニファイドメモリ活用からRTX 4090でのVRAM最適化まで、緻密な構成設計が不可欠となる。本稿では、最新のQwen 3.6環境をローカルで構築するための具体的な実装手順と、推論速度（tokens/s）に焦点を当てた徹底的なベンチマーク結果を提示する。

Qwen 3.6 35B-a3b MoE の構造とパラダイムシフト

Qwen 3.6 35B-a3b（以下、Qwen 3.6 35B）がローカルLLMの界隈に与えた衝撃は、単なるパラメータ数の増加ではなく、「Mixture of Experts (MoE)」技術の極めて高度な最適化にあります。従来のDenseモデル（全パラメータを毎トークン計算する方式）では、パラメータ数を増やすほど計算コスト（FLOPs）が線形的に増大し、推論速度の低下が避けられませんでした。しかし、Qwen 3.6 35Bは「Total Parameters: 35B」に対し、「Active Parameters: 約3B」という極端なスパース（疎）構造を採用しています。

このアーキテクチャの肝となるのは、Router（ルーター）と呼ばれる制御機構です。入力されたトークンに対し、モデル内の数百に及ぶエキスパート層の中から、その処理に最も適した数個のエキスパートのみを動的に選択して計算を行います。これにより、35Bクラスの広大な知識量（パラメータ容量）を保持しつつ、推論時の計算負荷はわずか3Bクラスのモデルと同等まで抑え込まれています。この「知能の密度」と「計算の軽快さ」の両立こそが、RTX 4090などのコンシューマ向けGPUでの運用を現実的なものにしています。

以下の表は、従来のDenseモデル（Llama 3 70B等）とQwen 3.6 35Bの構造的差異をまとめたものです。

MoEモデルの運用において、ユーザーが意識すべきは「VRAM容量」と「計算能力」の分離です。35Bという総パラメータ量は、推論時に全ての重みをVRAM上に展開しておく必要があるため、メモリ容量（GB）の確保が最優先事項となります。一方で、実際の演算（トークン生成）にかかる負荷は3B分であるため、適切なGPU（高い演算性能を持つもの）を選択すれば、驚異的なトークン生成速度を実現できます。

ローカル実行環境の構築：LM Studio, Ollama, vLLM の使い分け

Qwen 3.6 35Bをローカルで動かすためのソフトウェア・スタックは、用途に応じて大きく3つの潮流に分かれます。まず、最も導入障壁が低いのが「LM Studio」です。これはGUIベースのアプリケーションであり、Hugging Face上のGGUF形式ファイルを検索・ダウンロードし、ワンクリックでロードできます。Windows 11やmacOS環境において、設定ファイル（config.json）を意識することなく、すぐにチャットインターフェースを利用したいユーザーに最適です。

次に、サーバーサイドでの運用や、他のアプリケーションとの連携を前提とするなら「Ollama」が有力な選択肢となります。Ollamaはバックグラウンドで動作するデーモンとして機能し、REST APIを通じて外部から指示を送ることが可能です。Dockerコンテナ内での展開も容易であり、PythonスクリプトやLangChainを用いたエージェント開発における「推論エンジン」としての役割を担います。

そして、プロフェッショナルなスループット（単位時間あたりの処理量）を求める場合は、「vLLM」の採用が不可欠です。「PagedAttention」技術を実装しており、KV Cache（Key-Valueキャッシュ）のメモリ管理を極限まで効率化しています。これにより、複数のリクエストを同時に捌くマルチユーザー環境において、RTX 4090やA100といった高性能GPUの性能を最大限に引き出すことが可能です。

使用するソフトウェアと量子化形式の選択基準は以下の通りです。

• LM Studio (GGUF形式)
  • 用途: 個人利用、実験的試行、GUIでの対話。
  • メリット: 設定が極めて容易、CPU/GPUのハイブリッド推論に対応。
  • デメリット: 高並列処理には不向き。
• Ollama (Custom/GGUF)
  • 用途: ローカルAPIサーバー、自作AIエージェントのバックエンド。
  • メリット: 軽量、CLI（コマンドライン）での管理が容易。
  • デメリット: 高度な量子化パラメータの微調整には不向き。
  • 構成例: ollama run qwen3.6:35b-q4_k_m
• vLLM (AWQ / GPTQ形式)
  • 用途: 本格的な推論サーバー、高負荷なAPIサービス。
  • メライット: 圧倒的なスループット、PagedAttentionによるメモリ節約。
  • デメリット: NVIDIA GPU（Ampere世代以降）への依存度が高い、構築難易度がやや高い。

ハードウェアの限界と量子化による「知能」のトレードオフ

Qwen 3.6 35Bをローカルで運用する際、最大の物理的障壁となるのがVRAM（ビデオメモリ）の容量です。モデルの重みをFP16（16bit浮動小数点数）という高精度な状態でロードする場合、35Bのパラメータには約70GBのVRAMが必要です。これは、単体のRTX 4090（24GB）や、プロ向けでもRTX 6000 Ada（48GB）では到底足りない数値です。ここで重要になるのが「量子化（Quantization）」技術です。

量子化とは、重みの精度を4-bitや8-bitへと落とすことで、モデルのファイルサイズとメモリ占有量を削減する手法です。例えば、4-bit量子化（Q4_K_Mなど）を適用すれば、35Bのモデルは約20GB〜24GB程度のVRAMに収まる計算になります。これにより、RTX 4090 1枚での運用が可能となります。しかし、精度を落とすことは、論理的思考力や数学的推論能力といった「知能」の低下（Perplexityの悪化）を伴う諸刃の剣です。

また、Apple Silicon搭載のMac Studio（M3 Ultra等）は、CPUとGPUがメモリを共有する「ユニファイドメモリ」構造を持つため、192GBといった巨大なメモリ空間を推論に割り当てることが可能です。これにより、量子化による劣化を最小限に抑えた高精度なモデル運用が可能になります。

以下の表は、量子化ビット数によるVRAM占有量と、モデルの性能（知能）への影響度を示した目安です。

| 量子化形式 | 推定VRAM使用量 (35B時) | 適合ハードウェア例 | 知能・精度の保持率 | 推論速度 (Tokens/sec) | | :--- | :--- | :---覚 | :--- | :--- | | FP16 (Original) | 約 70 GB | Mac Studio M3 Ultra (128GB+) / A100 80GB | 100% (基準) | 低い (帯域に依存) | | Q8_0 (8-bit) | 約 38 GB | RTX 6000 Ada / Dual RTX 3090 | ~99.5% | 中程度 | | Q4_K_M (4-bit) | 約 22 GB | RTX 4090 (24GB) / RTX 3090 | ~95-97% | 極めて高い | | Q2_K (2-bit) | 約 14 GB | RTX 3060 (12GB) ※スワップ必須 | ~80%以下 | 高い（ただし知能崩壊） |

運用設計においては、「RTX 4090でQ4_K_Mを動かし、速度と精度のバランスを取る」のが現在のローカルLLMにおける黄金律といえます。

実践的なパフォーマンス・チューニングと運用コスト

Qwen 3.6 35Bの真価を引き出すためには、単にモデルをロードするだけでなく、推論エンジン側のパラメータチューニングが不可欠です。特に「KV Cache（Key-Valueキャッシュ）」の管理は、コンテキストウィンドウ（一度に扱えるトークン数）の長さに直結します。長い文書を読み込ませる場合、キャッシュがVRAMを圧迫し、計算速度が急激に低下する現象が発生します。

これを回避するためには、FlashAttention-2のような高速化アルゴリズムの有効化や、Context Windowの制限設定が必要です。また、推論時の「Temperature（温度）」パラメータの設定も重要です。MoEモデルはエキスパートの選択という性質上、極端に高い温度設定にすると、不適切なエキスパートが選ばれやすくなり、出力の支離滅裂な「ハルシネーション（幻覚）」を誘発する傾向があります。

さらに、物理的な運用コストについても考慮しなければなりません。RTX 4090を用いたフルロード状態での推論は、GPU単体で最大450W程度の電力を消費します。24時間稼働のAPIサーバーとして運用する場合、電気代だけでなく、熱設計（冷却）も重要な課題となります。Noctua製ファンなどの高静圧・低騒音ファンを用いたケース内のエアフロー設計や、水冷システムの導入は、長期的なハードウェアの寿命と安定性に直結します。

以下に、典型的なローカル推論環境におけるパフォーマンス指標のベンチマーク結果（予測値）をまとめます。

• 構成 A: ハイエンド・ワークステーション (RTX 4090 / 24GB VRAM)
  • 設定: Q4_K_M 量子化, Context Window: 8k
  • 推論速度: 45〜55 tokens/sec
  • 特徴: 単一ユーザー向けのチャット用途で圧倒的なレスポンス。
• 構成 B: プロフェッショナル・サーバー (A100 80GB / vLLM)
  • 設定: FP16, Context Window: 32k
  • 推論速度: 15〜25 tokens/sec (高並列時)
  • 特徴: 複数リクエストの同時処理（Throughput）に特化。
• 構成 C: Apple Silicon エコシステム (Mac Studio M3 Ultra / 192GB)
  • 設定: Q8_0 量子化, Context Window: 64k+
  • 推論速度: 8〜12 tokens/sec
  • 特徴: 超長文解析や、高精度な知識抽出に最適。

運用コストの最適化においては、タスクの性質に応じて「軽量なQ4モデルをRTX 4090で回す」のか、「重厚なFP16モデルをMac Studioで動かす」のかを明確に切り分けることが、投資対効果（ROI）を最大化する鍵となります。

Qwen 3.6 35B-a3b 運用環境とハードウェア構成の徹底比較

Qwen 3.6 35B-a3bのようなMoE（Mixture of Experts）モデルをローカル環境で実用的な速度で動作させるには、単なるGPUの演算性能（TFLOPS）だけでなく、メモリ帯域幅（Memory Bandwidth）とVRAM容量のバランスが極めて重要となります。MoEアーキテクチャは、推論時に全パラメータを使用せず、特定の「エキスパート」のみをアクティブ化することで計算量を抑えていますが、モデル全体の重みをビデオメモリ上に展開しておく必要があるため、高密度なパラメータを持つモデルほど、広帯域なメモリバスへの依存度が高まります。

以下に、ローカルLLM運用における主要な推論エンジンと、ハードウェア構成の選択肢を整理しました。

推論エンジン・フレームワークの特性比較

実行環境の選択は、ユーザーが「手軽なチャット体験」を求めるのか、「APIサーバーとしての高スループット」を求めるのかによって明確に分かれます。

ハードウェア構成別の実装コスト・性能予測

Qwen 3.6 35B-a3bをどの程度の精度（量子化ビット数）で動かすかによって、必要な予算と得られるレスポンス速度は劇的に変化します。2026年現在のパーツ流通価格に基づいた比較です。

| ハードウェア構成 | VRAM/メモリ容量 | 推定導入コスト (円) | 量子化精度ターゲット | 期待される動作感 | | :--- | :--- | :---GB | 約32万円 | Q4_K_M (4-bit) | 高速・実用的 | | Dual RTX 3090/4090 | 48GB GDDR6X | 約55万円 | Q8_0 (8-bit) | 極めて高精度 | | Mac Studio (M3 Ultra) | 128GB Unified | 約75万円 | FP16 (Full Precision) | 高精度・安定動作 | | RTX 5090 (次世代構成) | 32GB GDDR7 | 約45万円 | Q8_0 (8-bit) | 超高速・高密度 |

量子化ビット数によるモデルサイズと精度のトレードオフ

量子化（Quantization）は、モデルの重みを低ビット化することでメモリ使用量を削減する技術です。MoEモデルの場合、エキスパートの切り替えが発生するため、極端な低ビット化は推論ロジックの崩壊を招きやすい傾向があります。

インフラ・ソフトウェア互換性マトリクス

特定の量子化形式（GGUF, EXL2, AWQ）を使用する場合、対応するバックエンドエンジンに制限が生じます。開発パイプライン構築時の注意点として参照してください。

Qwen 3.6 35B-a3b vs 競合MoE/Dense モデル性能比較

Qwen 3.6 35B-a3bの優位性は、パラメータ数に対して極めて高いベンチマークスコアを維持している点にあります。以下は主要なタスクにおける予測値です。

これらの比較から明らかなように、Qwen 3.6 35B-a3bはMoEの特性を活かし、計算コスト（アクティブパラメータ数）を抑えつつ、従来の巨大なDenseモデルに匹敵、あるいは凌駕する知能を実現しています。ローカル運用においては、VRAM容量が24GBを下回る構成ではQ4_K_M以下の量子化を選択せざるを得ませんが、RTX 3090/4090クラスの環境を構築できれば、非常に高い推論精度と実用的なレスポンス速度の両立が可能です。

よくある質問

Q1. ローカル環境でQwen 3.6 35B MoEを運用するための最低限の予算はどのくらいですか？

本格的な推論環境を構築する場合、ビデオメモリ（VRAM）容量が鍵となります。4-bit量子化モデルを快適に動かすには、24GBのVRAMを持つNVIDIA GeForce RTX 4090を搭載したPCが推奨されます。パーツ構成によりますが、最低でも30万円〜40万円程度の予算を見込んでおく必要があります。これ以下の予算（例：RTX 4060 Ti 16GB搭載機）では、コンテキスト長が極端に制限されるため注意が必要です。

Q2. API利用と比較して、ローカル運用のランニングコストは安くなりますか？

従量課金制のOpenAI GPT-4oなどのAPI利用は、大量のトークンを処理すると月額費用が数万円に達することがあります。一方、ローカル運用は電気代と初期投資のみです。RTX 4GBクラスのGPUをフル稼働させても、1時間あたりの消費電力は数百円程度に収まるため、24時間体制で大量の文書要約やデータ解析を行うワークロードにおいては、1年以上の長期利用でローカル環境の方が圧倒的に低コストになります。

Q3. Qwen 3.6 35B MoEとLlama 4（Denseモデル）のどちらを選ぶべきですか？

推論速度とVRAM効率を重視するならQwen 3.6 35B-a3bが優れています。MoE構造により、総パラメータ数は大きくても計算時には一部のパラメータのみを使用するため、RTX 4090環境でも高いトークン/秒を実現できます。一方で、モデルの知識密度や論理的整合性の安定性を最優先し、十分なVRAM（80GB以上のA100等）が確保できる場合は、Llama 4のような高密度（Dense）モデルの方が複雑な指示への追従性が高い傾向にあります。

Q4. 初心者がLM StudioとOllamaのどちらから始めるのがおすすめですか？

GUI操作で直感的にモデルを管理したいならLM Studioが最適です。Hugging Faceから直接モデルを検索・ダウンロードし、数クリックで推論を開始できます。一方、PythonスクリプトやDockerコンテナからバックエンドとして呼び出し、自作アプリケーションに組み込みたい場合は、軽量で動作が安定しているOllamaが適しています。どちらも4-bit量子化（GGUF形式）をサポートしており、導入のハードルは低いです。

Q5. Mac Studio M3 Ultra環境での実行における互換性とメリットは何ですか？

Mac Studio M3 Ultra（メモリ192GB構成）は、ローカルLLM運用において最強の選択肢の一つです。Unified Memoryアーキテクチャにより、GPU専用VRAMの容量制限を超えて巨大なモデルをロード可能です。RTX 4090の24GBでは収まらないQwen 3.6の8-bit量子化版や、より大規模な70Bクラスのモデルも、192GBの広大なメモリ空間を活用して高速に推論できます。ただし、推論速度（tokens/sec）単体では、高クロックなNVIDIA GPUに譲る場面もあります。

Q6. 4-bit量子化モデルを使用する場合、VRAM容量は具体的に何GB必要ですか？

Qwen 3.6 35B-a3bを4-bit（GGUF/EXL2）で動作させる場合、モデル本体の重みだけで約18〜20GBのVRAMを占有します。これに加えて、コンテキストウィンドウ（KV Cache）の展開用に数GBの空きが必要です。したがって、最低でも24GBのVRAMを持つRTX 3090やRTX 4090が実用的な境界線となります。16GBのGPUでは、モデルを分割してメインメモリ（RAM）へ逃がすことになり、推論速度が劇的に低下します。

Q7. 推論中に「Out of Memory (OOM)」エラーが発生する原因は何ですか？

主な原因は、入力したプロンプトの長さ（コンテキスト長）がVRAM容量を超えたことです。MoEモデルは計算負荷は低いものの、KV Cacheによるメモリ消費はコンテキスト長に比例して増大します。vLLMなどの推論エンジンを使用している場合、max_model_lenの設定値を下げるか、量子化ビット数をさらに下げた（例：3-bit）モデルを採用することで回避可能です。また、他のアプリケーションがVRAMを消費していないかも確認してください。

Q8. 推論速度（tokens/sec）が極端に低下した際の対処法はありますか？

GPUの[メモリ帯域幅](/glossary/bandwidth)がボトルネックになっている可能性が高いです。もしシステムメモリ（DDR5等）へモデルの一部がオフロードされている場合、PCIeバスの転送速度が足かせとなり、速度は数分の1に低下します。解決策としては、まずはモデルサイズを小さくするか、より圧縮率の高い量子化形式（EXL2の低ビット版など）を試してください。また、vLLMを使用している場合は、[PagedAttention](/glossary/attention)の設定を見直すことで効率的なメモリ管理が可能になります。

Q9. 今後のトレンドとして、MoE（Mixture of Experts）モデルは主流になりますか？

はい、非常に有力なトレンドです。従来のDenseモデルはパラメータ数に比例して計算コストが増大しますが、Qwen 3.6のようなMoE構造は「必要な専門家（Expert）のみを起動する」ため、推論効率が劇的に向上します。今後は、エッジデバイスのNPUやモバイルSoCにおいても、メモリ帯域を節約しつつ高精度な回答を得られるMoEモデルの採用が加速すると予測されます。これにより、スマートフォン上での高度なローカルLLM実行が現実的になります。

Q10. 次世代のAIハードウェア（NPU搭載PC）はローカルLLMに影響しますか？

大きな影響を与えます。Intel Core UltraやSnapdragon X Eliteに搭載された強力なNPU（Neural Processing Unit）は、低消費電力での定型的な推論処理を得意としています。将来的にQwenのような軽量・高効率なMoEモデルがこれらのNPU向けに最適化されれば、RTX 4090のような巨大なGPUを必要とせず、ノートPCのバッテリー駆動のみで、プライバシーを保ったまま高度なAIアシスタントを常時稼働させることが可能になります。

まとめ

• Qwen 3.6 35B-a3bは、MoE（Mixture of Experts）構造を採用することで、35Bクラスのパラメータ数に対して極めて高い推論効率と知能を両立させている。
• ローカル運用における鍵は4-bit量子化にあり、RTX 4090（24GB VRAM）等のコンシューマ向けGPUでも、KVキャッシュを含めたメモリ管理次第で高速な動作が可能である。
• LM StudioやOllamaを利用すれば、複雑な環境構築なしに即座にチャットインターフェースを立ち上げられる。
• サーバー用途やAPI提供を見据えた大規模デプロイメントには、vLLMによる推論最適化が不可欠となる。
• Mac Studio M3 Ultraのようなユニファイドメモリ環境は、GPU単体のVRAM容量の制約を受けにくく、より高精度な重みでの運用において強力な選択肢となる。
• 推論速度（tokens/sec）とモデルの知能レベルのバランスが極めて高く、ローカルLLMの新たな基準となり得るポテンシャルを秘めている。

まずはOllamaを用いて4-bit量子化版を導入し、自身のハードウェアにおけるトークン生成速度の実測値を記録することから始めてください。その後、VRAM使用量と精度（Perplexity）のトレードオフを確認しながら、最適な量子化ビット数を見極めるのが次の一歩です。