Qwen3.6-35B-A3Bとは、Alibabaが2026年4月に公開したMoE型の大規模言語モデル。
海外のRedditコミュニティ（r/LocalLLaMA）で、RTX 4060 Laptop（VRAM 8GB）＋RAM 96GBの構成でQwen3.6-35B-A3Bを動かしたという報告が話題になっている。しかも投稿者がつまずいた本当の問題は「VRAM不足でクラッシュする」ことではなく、「thinking（推論）が無限に続いてmax_tokensを食い潰す」という挙動。llama-serverの設定を見直すことで解決した、という内容でした。本記事ではこの投稿を起点に、同じ構成で詰まりやすいポイントと設定値の読み解き方を筆者の視点で整理します。
- RTX 4060（VRAM 8GB）でQwen3.6-35B-A3Bが動くのは大容量RAMとMoE層のCPUオフロード前提
- 実用化の分水嶺はVRAMではなく「thinkingが止まらずmax_tokensを使い切る」挙動の制御
- 対処はthinking無効化の即効策と、thinking_budget_tokensによる上限制御の2段構え
RTX 4060 8GBでQwen3.6 35B MoEが動く条件とは
RTX 4060のVRAMは8GBしかありません。一方、Qwen3.6-35B-A3BはMoE（Mixture of Experts）型のモデルで、総パラメータは大きいもののアクティブに使われるパラメータは一部だけ、という構造を持ちます。この仕組みを活用すれば、8GB VRAM環境でも実用レベルで推論が回せる可能性がある、というのが投稿者の主張。
MoEアーキテクチャがVRAM節約に効く理由
通常の密（dense）モデルでは、全パラメータが推論のたびに計算に使われます。そのためモデルサイズがそのままVRAM要件に直結する構造でした。MoEはこれが違います。入力トークンごとに一部のエキスパート層だけが活性化されるため、アクティブ計算量は総パラメータ数より大幅に小さい、という特性を持ちます。
ここに「MoE層だけをCPU（RAM）に逃がす」工夫を組み合わせると、VRAMには重要な共有層だけ残し、エキスパート層は大容量RAMで処理する構成が取れると筆者は見ています。RTX 4060のような8GB環境で35Bクラスを動かす実例の背景には、この考え方がある。
ハードウェア前提（RTX 4060 Laptop／大容量RAM）
Redditの投稿者が使っているのはRTX 4060 Laptop GPUとRAM 96GBという構成。デスクトップ版RTX 4060とラップトップ版はクロックやTDPが異なるため、同一モデルの動作でも速度は変わる可能性があります。ただし「動くか動かないか」の観点ではVRAMと同じ8GBクラスに収まる点が共通です。
注意が必要なのは、VRAMよりRAM容量の方がこの構成ではクリティカル、という点。MoE層をCPUに逃がす以上、RAMが小さければそもそも読み込めません。投稿者の96GBは余裕のある部類で、32GBや64GB環境ではGGUFファイルサイズや量子化方式に応じて厳しくなるケースもあると考えられます。
実際に詰まったのはクラッシュではなく「thinking暴走」
この投稿の面白いところは、「VRAM 8GBで35Bを動かす設定の話」よりも「動いた後に最初に踏んだ地雷」にあります。投稿者が詰まったのはクラッシュでもOOM（メモリ不足）でもなく、「出力が一向に返ってこない」という症状でした。
症状：出力が返る前にトークン予算が尽きる
Qwen3.6-35B-A3BはOpenAI系のreasoningモデル同様、内部で「思考（thinking）」トークンを生成してから最終回答を出す仕組みを持ちます。llama-serverで–reasoning-budget -1と指定すると、この思考に上限を設けない挙動になる。
ここで問題が起きます。投稿者によると、thinkingが延々と続いた結果、リクエスト側で渡したmax_tokens予算を思考だけで使い切ってしまい、最終的なコード出力が一切返ってこなかった、という報告。エージェントパイプラインのサブエージェントとして使っていたため、「応答がnullで返ってくる」というバグとして最初は認識されていたそうです。
原因：reasoning-budgetを-1にした場合の挙動
–reasoning-budget -1は「思考トークンの上限なし」を意味する設定。投稿者はこれをデフォルトのまま使っていたため、モデルが長考すればするほどmax_tokens全体を消費する構造になっていました。クラッシュしないため一見「動いている」ように見えるのがたちの悪いところ。ログにはエラーも出ないのでVRAM設定やGGUFの読み込みを疑って時間を溶かしがち、という状況が想像できます。
こうした挙動は、Qwen3.6-35B-A3Bに限らずreasoningをサポートするモデル全般で起こりうると筆者は見ています。ローカルで回す場合はAPIプロバイダが気を利かせて制御してくれるわけではないので、自分で上限を設計する必要があるのが現状。
thinking暴走を止める2段構えの対処法
投稿者が辿り着いた解決策は2つ。1つ目はthinkingそのものを切る即効策、2つ目はリクエストごとに思考予算を設定する根本策でした。両方を押さえておくのが安全、と筆者は考えています。
対処手順（即効策）:
- llama-serverの起動オプションから–reasoning onと–reasoning-budget -1を外す
- 環境変数のLLAMA_CHAT_TEMPLATE_KWARGSでpreserve_thinkingを有効にしていた場合は外すか、falseに書き換える
- サーバーを再起動して同じリクエストを投げ直す
この切り分けで応答が正常に戻れば、原因はthinking設定で確定。逆に治らなければ別の要因（トークン数設定やストリーミング処理）を疑う順序になります。
まずthinkingをオフにして切り分ける
投稿者によれば、thinkingを無効化した瞬間に症状が消えた、という報告でした。thinkingを完全に切るとモデルの強みが一部失われる可能性はあるものの、「動くかどうか」を確認する切り分け用途としては有効な手段。
リクエスト単位でthinkingバジェットを設定する
恒久対応としては、リクエストごとにthinking_budget_tokensを指定して上限を与える方法が推奨されています。投稿者もこちらをより望ましい対処として挙げていました。
対処手順（根本策）:
- クライアント側のリクエストペイロードにthinking_budget_tokensを追加する
- max_tokens全体の半分程度を上限目安として設定し、残りを最終回答用に確保する
- タスクの難度に応じて値を調整し、コーディング系なら長め、短い回答なら短めに配分する
ここの数字に絶対解はなく、ワークロードごとに試行錯誤が必要と考えます。筆者の感覚では、サブエージェント用途ならmax_tokens 4096に対してthinking 1024〜2048くらいから始めると事故が少ないのではないかという見方もあります。
llama-server設定の要点を読み解く
投稿された起動コマンドには8GB VRAMで35Bを動かすための工夫が詰まっています。暗記するのではなく、なぜその設定なのかを理解したい部分。主要な引数を順に見ていきます。
起動コマンドの主要フラグ: -m Qwen3.6-35B-A3B-Q4_K_M.gguf、-ngl 99、–n-cpu-moe 99、-c 50000、-fa on、–cache-type-k q8_0、–cache-type-v turbo2、–no-mmap、–mlock、-b 2048、-ub 2048。
MoE層をCPUに逃がす –n-cpu-moe の考え方
-ngl 99はGPUにオフロードするレイヤー数を99（≒全部）と指定するオプション。これだけだと当然8GBには収まりません。そこで同時に指定されるのが–n-cpu-moe 99。MoEの専門家層をCPU側に逃がすフラグで、結果としてVRAMには共有層とKVキャッシュだけが残る構造になる、という仕組み。
投稿者自身も「この値は公式ガイダンスではなくコミュニティでのチューニング議論と自分の制約から決めた」と明記しており、万能の正解ではない点に注意が必要。環境ごとに調整の余地がある、と捉えておくのが無難でしょう。
KVキャッシュ量子化とフラッシュアテンションの効き方
-fa onはフラッシュアテンションの有効化。メモリ帯域の効率を上げて推論速度に寄与する仕組みです。加えて–cache-type-k q8_0と–cache-type-v turbo2でKVキャッシュ自体を量子化し、VRAM消費を抑える戦略が取られています。
KVキャッシュはコンテキスト長が伸びるほどVRAMを食う部分。-c 50000のように長めのコンテキストを確保しようとすると、量子化しないと8GBに収まらない可能性が高いと考えられます。–mlockでRAM上のメモリをロックし、スワップによる速度低下を防ぐのも長時間稼働で効いてくる設定。
環境変数（LLAMA_SET_ROWS / preserve_thinking）の役割
LLAMA_SET_ROWS=1はコミュニティで共有されているチューニングTipsの1つで、投稿者も「試す価値があった」と評価しています。効果の大きさには環境依存性がある可能性があるため、オン・オフで自分の環境を比較するのが確実、と筆者は見ています。
preserve_thinking: trueはエージェントワークフローで「直前の思考を再利用するためにキャッシュに保持する」役割。ただし前述のthinking暴走問題と組み合わさると副作用が出やすい部分でもあります。thinking_budget_tokensで上限を切った上でpreserveする、という順序で設計するのが安全と考えます。
コーディング用途での量子化選びとモデルサイズ感
GGUFにはQ4_K_M、Q6_K、IQ4_XSなど多数の量子化バリエーションがあり、サイズと精度のトレードオフが存在します。どれを選ぶかで体感品質は変わる、という点を押さえておきたいところ。
姉妹サイトに Qwen3.6-35B-A3Bの公開概要 をまとめた記事があるので、モデル自体の位置づけを確認したい方はそちらも参照してください。
量子化による精度劣化をどう見極めるか
量子化はビット数を下げるほどファイルサイズが小さくなりますが、元のBF16出力との乖離も大きくなります。r/LocalLLaMAではKLダイバージェンス（元モデルの出力分布との一致度）を使って量子化品質を測る手法がしばしば共有されています。
一般論として、Q4_K_MはサイズとVRAM効率のバランスが取れた選択肢と見られている量子化です。投稿者もQ4_K_Mを採用していました。精度を最優先するならQ6_K以上、VRAMを切り詰めたいならIQ系の方が向いている、という使い分けになると筆者は考えます。
コーディングサブエージェント用途で重視すべき指標
チャット用途と違い、エージェントパイプラインの一部として使う場合は「速度そのもの」より「指示通りの構造化出力が安定して出せるか」が重要になる、と筆者は見ています。tokens/secが多少遅くても、出力が安定してパースできる方がパイプライン全体のスループットには効く、という可能性があるからです。
当サイトの検証環境（RTX 5080 / i7-14700F / RAM 96GB）では、Qwen3.6-35B-A3Bそのものではなく類似規模のMoEモデルqwen3.5:35b-a3bで19.7 tokens/sec（VRAM使用量15.4GB、GPU温度49°C、消費電力62W）を記録しています。MoEらしく消費電力が抑えられている挙動が見て取れる一方、16GBクラスVRAMでも35Bクラスは速度が伸びにくいことも読み取れる数値。RTX 4060の8GB構成で同じモデルを動かした場合、MoE層をCPUに逃がす分だけtokens/secはさらに落ちると推定されます。
8GB VRAM環境で現実的に狙える運用シナリオ
RTX 4060 8GB構成でQwen3.6-35B-A3Bを動かす際、どういう使い方なら現実的に回せるのか、という視点を最後に整理します。
インタラクティブ利用には向かない理由
投稿者自身も明言していますが、この構成は対話型チャット向きではありません。MoE層のCPUオフロードを前提にしている時点で、1トークン出すごとにCPUとGPU間のやり取りが発生し、体感速度は厳しくなる可能性が高い、と考えられるからです。
ChatGPT的な使い勝手を求めるならRTX 5070 Ti以上のVRAM 16GBクラスが現実的という見方もあります。一方で、バッチ処理やエージェントパイプラインの裏方として動かすなら、多少遅くてもローカルで完結するメリットの方が大きい、というのが投稿者の割り切り方でした。
RAM優先アップグレードが効く条件
8GB VRAMのまま35Bクラスを動かす以上、GPU側でできることには限界があります。この環境で最も効くアップグレードは、GPU交換よりもRAMの増設と考えるのが合理的な場合が多いのではないでしょうか。
GPU買い替えでVRAMを増やすなら、16GB VRAMを持つRTX 5060 Ti 16GBが新品で最も手が届きやすい選択肢という位置づけ。RTX 5070 TiやRTX 5080まで視野に入れると、同じQwen3.6-35B-A3BをGPU内に収めやすくなり、体感速度の伸びしろも変わってくると筆者は見ています。
よくある質問
Q. VRAM 8GBで本当にQwen3.6 35Bが動くのですか？
Redditの投稿者はRTX 4060（VRAM 8GB）＋RAM 96GBの構成で動作させたと報告しています。MoE層をCPUに逃がし、KVキャッシュを量子化することでVRAMに収める構成。大容量RAMが前提であり、チャット用途ではなくコーディングサブエージェントやバッチ処理向けという割り切りが必要だと筆者は考えます。
Q. デスクトップ版RTX 4060でも同じ設定で動きますか？
VRAMは同じ8GBなので、基本の考え方は共通と見てよい可能性が高いと筆者は考えます。ただしRTX 4060 Laptop GPUとデスクトップ版ではTDPやクロックが異なるため、推論速度や発熱に差が出るケースはあるでしょう。まずは投稿者と同じ設定で起動し、自分の環境で微調整する順序が無難です。
Q. どのGGUF量子化を選べばよいですか？
Redditの投稿者はQ4_K_Mを採用していました。サイズと精度のバランスが取りやすい量子化として知られています。VRAMをさらに切り詰めたいならIQ系、精度を優先するならQ6_K以上という使い分けも選択肢。自分のタスクで出力品質を比較しながら決めるのが確実と考えます。
Q. 応答が返ってこない場合、まず何を疑うべきですか？
クラッシュせず無言になる症状なら、まずthinking関連の設定を疑うのが近道です。reasoning-budgetを-1にしている場合、thinkingがmax_tokensを食い尽くしている可能性があるからです。thinkingを一度オフにして切り分け、再発しなければ恒久策としてthinking_budget_tokensで上限を設定してください。
まとめ
RTX 4060 8GBでQwen3.6 35B MoEを動かす上での最大の分水嶺は、VRAM容量そのものよりも「thinkingが暴走してmax_tokensを食い尽くす挙動を制御できるか」という点にある、というのがRedditの投稿から読み取れる教訓でした。
最初に確認すべきはthinking設定、次にllama-serverのMoEオフロードとKVキャッシュ量子化、最後にRAM容量とGGUF量子化の選択、という優先順位で見直すのが筆者のおすすめ。動作したあとの実運用を考えるなら、インタラクティブ用途ではなくエージェントパイプラインやバッチ処理に割り切る設計が現実的と考えます。
| 対象モデル | Qwen3.6-35B-A3B（MoE） |
|---|---|
| 動作実績GPU | RTX 4060 Laptop（VRAM 8GB） |
| 必要RAM目安 | 大容量（Redditの実例は96GB） |
| 推論エンジン | llama.cppのllama-server |
| 量子化例 | GGUF Q4_K_M |
| 主な落とし穴 | reasoning-budget -1によるthinking暴走 |
あなたの環境ではRTX 4060やそれに近いVRAM帯で、どんなモデルをどう工夫して動かしていますか？thinkingバジェットの最適解はタスクごとに変わるはずで、正解は一つではない領域だと筆者は考えています。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
おすすめパーツ 価格まとめ
| 製品名 | カテゴリ | スペック | 参考価格 |
|---|---|---|---|
| RTX 4060 | GPU・グラフィックボード | NVIDIA GeForce RTX 4060 8GB GDDR6 | ¥45,000〜（中古相場） |
| RTX 5080 | GPU・グラフィックボード | NVIDIA GeForce RTX 5080 16GB GDDR7 | ¥199,800〜 （kakaku.com最安値・2026/04/29） |
| RTX 5070 Ti | GPU・グラフィックボード | NVIDIA GeForce RTX 5070 Ti 16GB GDDR7 | ¥158,000〜 （kakaku.com最安値・2026/04/29） |
本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
