RTX 4060 8GBでQwen3.6 35B MoEを動かす

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 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）側に回す」工夫を組み合わせると、GPU 側には dense・共有部分や KV キャッシュを優先して置き、重いエキスパート重みの一部または大半を大容量 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は、最終回答の前に <think>...</think> 形式の thinking content を生成する thinking mode を標準で持ちます（ローカル実行ではこの内容が見えたり reasoning_content 側に分離されたりと、テンプレートやサーバー実装で扱いが変わります）。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つ目はリクエストごとに思考予算を設定する根本策でした。両方を押さえておくのが安全です。

対処手順（即効策）:

1. thinking を明示的に無効化する。--reasoning off と --chat-template-kwargs '{"enable_thinking":false}' の両方を試し、実際のレスポンスに thinking content が残っていないか確認する。Qwen3.6 は既定で thinking するうえ、モデル・テンプレート・ビルドで効き方が揺れる報告もあるため、暗黙の auto に任せないのが安全
2. 環境変数で thinking を保持していた場合（後述の preserve_thinking 等）は外すか false にする
3. サーバーを再起動して同じリクエストを投げ直す

この切り分けで応答が正常に戻れば、原因はthinking設定で確定。逆に治らなければ別の要因（トークン数設定やストリーミング処理）を疑う順序になります。

まずthinkingをオフにして切り分ける

投稿者によれば、thinkingを無効化した瞬間に症状が消えた、という報告でした。thinkingを完全に切るとモデルの強みが一部失われる可能性はあるものの、「動くかどうか」を確認する切り分け用途としては有効な手段。

リクエスト単位でthinkingバジェットを設定する

恒久対応としては、リクエストごとにthinking_budget_tokensを指定して上限を与える方法があり、投稿者もこちらをより望ましい対処として挙げていました。これはサーバー側で固定の正の --reasoning-budget N を決め打ちしていない場合に使う想定で、投稿者は --reasoning-budget -1 のまま、リクエストごとに thinking_budget_tokens を渡す設計で動作確認したとしています。なお thinking_budget_tokens は公式 README の主要オプション表ではなく GitHub Discussion や実装側で確認されている挙動のため、使用する llama.cpp ビルドで動作確認しておくのが安全です。

対処手順（根本策）:

1. クライアント側のリクエストペイロードにthinking_budget_tokensを追加する
2. max_tokens全体の半分程度を上限目安として設定し、残りを最終回答用に確保する
3. タスクの難度に応じて値を調整し、コーディング系なら長め、短い回答なら短めに配分する

ここの数字に絶対解はなく、ワークロードごとに試行錯誤が必要です。経験的には、サブエージェント用途なら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、--reasoning on、--reasoning-budget -1。

MoE層をCPUに逃がす --n-cpu-moe の考え方

-ngl 99はGPUにオフロードするレイヤー数を99（≒全部）と指定するオプション。これだけだと当然8GBには収まりません。そこで併用されるのが--n-cpu-moeで、公式の説明は「先頭 N 層分の MoE（専門家）重みを CPU に置く」というもの。ざっくり言えば、重いエキスパート重みの一部または大半を RAM 側に回し、GPU 側には dense・共有部分や KV キャッシュを優先して置く発想になります。

ただし元投稿の初期コマンドにあった--n-cpu-moe 99（ほぼ全層の MoE を CPU へ）は、投稿者自身が後の追記で「8GB 環境の良いデフォルトではなく、遅い安全側の暫定設定だった」と訂正しています。コメント欄の検証を受けて値を 38 前後まで下げたところ、自身の環境で約10〜12 tok/s から約36.6 tok/s へ改善したとのこと。現在の本線は、まず--fit（既定 on＝空きメモリに収まるよう未指定の引数を自動調整）をベースラインにし、必要に応じて --n-cpu-moe の値を手動で比較する読み方になります。99 を推奨値として固定で写すと遅くなる点に注意が必要です。

KVキャッシュ量子化とフラッシュアテンションの効き方

-fa onはフラッシュアテンションの有効化。メモリ帯域の効率を上げて推論速度に寄与する仕組みです。加えて--cache-type-k q8_0と--cache-type-v（元投稿では turbo2）でKVキャッシュ自体を量子化し、VRAM消費を抑える戦略が取られています。ただし turbo2 は TurboQuant 系ビルド独自の値で、本家 llama.cpp の標準ビルドには無く起動しません。標準ビルドで再現する場合は --cache-type-v を q8_0 などの標準値に読み替えてください。

KVキャッシュはコンテキスト長が伸びるほどVRAMを食う部分。-c 50000のように長めのコンテキストを確保しようとすると、量子化しないと8GBに収まらない可能性が高いと考えられます。--mlockでRAM上のメモリをロックし、スワップによる速度低下を防ぐのも長時間稼働で効いてくる設定。

環境変数（LLAMA_SET_ROWS / preserve_thinking）の役割

LLAMA_SET_ROWS=1は元投稿の初期コマンドに含まれていた環境変数ですが、投稿者は後の追記で「2025年8月にデフォルト化され、その後削除されたため、現在の llama.cpp では no-op（無効）で不要」と訂正しています。最新ビルドではチューニング項目として扱わず、設定から外して構いません。

preserve_thinking: trueはエージェントワークフローで「直前の思考を再利用するためにキャッシュに保持する」役割で、重複推論を減らして token 消費を抑えられる場合があります。ただし thinking が長引く設定と組み合わせる場合は、保持される thinking 量や max_tokens 消費を確認しながら使うのが安全です。thinking_budget_tokens で上限を切った上で preserve する、という順序で設計すると事故が少なくなります。なお元投稿では環境変数 LLAMA_CHAT_TEMPLATE_KWARGS が使われていますが、現在の llama.cpp 公式ドキュメントでは --chat-template-kwargs の環境変数名は LLAMA_ARG_CHAT_TEMPLATE_KWARGS です。再現時はコマンドラインで --chat-template-kwargs '{"enable_thinking":false}' のように明示するか、使用ビルドのヘルプで環境変数名を確認するのが安全です。

コーディング用途での量子化選びとモデルサイズ感

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 16GB + RTX 5060 Ti 16GB / i7-14700F / RAM 96GB）では、本モデル Qwen3.6-35B-A3B（Q4_K_M）を実測しており、RTX 5080 単体（16GB・一部CPUオフロード）で約68 tokens/秒、16GB を2枚使うデュアル構成（常駐100%）で約124 tokens/秒でした（短文・think=false・3回中央値。実測の詳細は前掲のローカル実行ガイドにまとめています）。MoEらしく消費電力も抑えめです。つまり16GBクラスなら一部オフロード込みでも実用速度が出ますが、RTX 4060 の8GB構成（当サイト未実測）では MoE層の大半をCPUに逃がすため、ここからさらに大きく落ちると見られます。8GBで起動できることと、16GBで実用速度を出すことは別の話として読むのが安全です。

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内に収めやすくなり、体感速度の伸びしろも変わってきます。

まとめ

RTX 4060 8GBでQwen3.6 35B MoEを動かすには、RAM容量・GGUF量子化・MoE配置・KVキャッシュ量子化がいずれも効きます。そのうえでこの投稿で実際に表面化した最大の落とし穴が、VRAM不足ではなく「thinkingが暴走してmax_tokensを食い尽くす挙動を制御できるか」だった、というのがRedditの投稿（と後の追記）から読み取れる教訓でした。

最初に確認すべきはthinking設定、次にllama-serverのMoEオフロードとKVキャッシュ量子化、最後にRAM容量とGGUF量子化の選択、という優先順位で見直すのが定石です。動作したあとの実運用を考えるなら、インタラクティブ用途ではなくエージェントパイプラインやバッチ処理に割り切る設計が現実的と考えます。

RTX 4060やそれに近いVRAM帯では、thinkingバジェットの最適解がタスクごとに変わるため、設定を一度自分のタスクで詰めておくのが結局は近道になります。

本記事は AIハードウェア図鑑 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。

参考資料

• r/LocalLLaMA（Reddit）：RTX 4060 8GB＋大容量RAM で Qwen3.6-35B-A3B を動かした実例と thinking 暴走の報告（本記事の起点）
• Hugging Face 公式: Qwen/Qwen3.6-35B-A3B モデルカード
• ggml-org 公式: llama.cpp リポジトリ
• llama.cpp 公式: llama-server ドキュメント
• NVIDIA 公式: GeForce RTX 4060 / 4060 Ti 製品ページ