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の設定を見直すことで解決した、という内容でした。本記事ではこの投稿を起点に、同じ構成で詰まりやすいポイントと設定値の読み解き方として整理します。

Qwen3.6-35B-A3Bの必要スペック｜VRAM 8・12・16GBでの動き方

先に、VRAMの容量ごとの動き方をまとめておく(最低限のVRAMやメモリの量を確かめた測定ではない)。手元で動かすときによく使われるQ4_K_MクラスのGGUFは、モデルファイルが約21〜24GBある(配布元で値が違い、Ollamaのq4_K_Mのタグは24GB、LM Studio Communityの配布は21.2GB)。VRAMにこれが全部入らなくても、入りきらない分をメインメモリに置いて動く。当サイトがOllamaで測った結果と、この記事の起点の投稿を、VRAMの容量ごとに並べると次のとおり。

当サイトの3行は、どれもQ4_K_Mクラス・思考なし・短い入力(答えは最大512トークン)での値だ。12GBの行と16GB×2の行には、外付けドック(OCuLink)でつないだカードが入っている。測った日、Ollamaの版、入力文などが行ごとに違うので、速さもGPU側の割合も、行どうしで数字を比べることはできない。GPU側の割合は、OllamaがGPUに載せた量を読み込んだ全体で割った値で、重みだけの割合ではない。この条件で言えるのは、12GBでも16GBでも1枚ではモデルの一部がメインメモリに置かれ、16GBを2枚使ったときにはCPU側へ置く分が表示上なくなった、というところまでだ。メインメモリは、VRAMに入らない分を置けるだけの量が要る。当サイトの測定機は96GBで、どれだけあれば足りるかは測っていない。12GBの測定の詳細はRTX 4070 SUPERとRTX 5060 Ti 16GBを比べた記事に、16GBの2つの構成はQwen3.6-35B-A3Bのローカル実行ガイドにまとめてある。

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の読み込みを疑って時間を溶かしがち、という状況が想像できます。なお、本家 llama.cpp の v0.8.0 では、サーバーの --reasoning-budget を -1 のままにしても、リクエストごとに指定する上限(次の節の「思考の上限を掛ける」手順)で思考に上限を掛けられます。リクエストに書いた上限がサーバーの値より優先されるためです(投稿者のビルドで同じ順位かは確かめていません)。

こうした挙動は、Qwen3.6-35B-A3Bに限らずreasoningをサポートするモデル全般で起こりうると見られます。ローカルで回す場合はAPIプロバイダが気を利かせて制御してくれるわけではないので、自分で上限を設計する必要があるのが現状。

応答が返らないときの切り分けと、思考の上限の掛け方

投稿者が辿り着いた手は2つ。1つ目はthinkingそのものを切って切り分ける即効策、2つ目はリクエストごとに思考の上限を掛ける方法でした。両方を押さえておくのが安全です。

対処手順（即効策）:

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

この切り分けで応答が正常に戻れば、thinkingの生成かその出力の扱いが関係している可能性が高いと見られます。ただ、thinkingを切ると生成する量やテンプレートの扱いも変わるので、これだけでは原因は決まりません。症状が出ていたときの設定(thinkingオン)の応答で、思考側の出力、生成されたトークン数、finish_reason（length なら出力の上限(max_tokens)に達して止まっています）、クライアント側の応答の処理を見て、思考だけでmax_tokensを使い切っていないかを確かめてください。逆に、thinkingを切っても治らなければ、別の要因（max_tokensの設定やストリーミング処理）を疑う順序になります。

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

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

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

続けて使うための手としては、リクエストごとにthinking_budget_tokensを指定して上限を与える方法があり、投稿者もこちらをより望ましい対処として挙げていました。投稿者は --reasoning-budget -1 のまま、リクエストごとに thinking_budget_tokens を渡す形で動いたと報告しています(投稿者のTurboQuant系ビルドでの話)。本家 llama.cpp の v0.8.0 では、POST /v1/chat/completions に送るJSONのトップレベルに reasoning_budget_tokens を書きます。thinking_budget_tokens も同じ意味の別名として受け付けます。リクエストに書いた値は、サーバーの --reasoning-budget より優先されます。ただし、リクエストに書かないときと、リクエストに書いた値が -1 のときは、サーバー側の値が使われます。上限が働くのは、チャットテンプレートから思考の終わりのタグを読み取れるモデルに限られます。

対処手順（思考の上限を掛ける）:

1. リクエストのJSONのトップレベルにreasoning_budget_tokensを追加する(v0.8.0。値は次の2.で決める)。別名の thinking_budget_tokens でも通り、投稿者のビルドでは 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。

これは2026年4月に投稿者がTurboQuant系のビルドで使った引数で、今の本家 llama.cpp にそのまま渡すと起動しないものが含まれます。v0.8.0(2026年10月28日公開)には --no-mmap と --mlock が無く、モデルの読み込み方は --load-mode で指定します。元投稿の2つを合わせた指定(mmapを使わず、モデルをRAMに固定する)は --load-mode mlock です。--cache-type-v の turbo2 も本家にはありません(後述)。写すときは、使っているビルドの --help と照らし合わせてください。

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 の値を手動で比較する読み方になります。比べるときは、2通りの起動を別々に立ち上げて測ります。1つは、-nglと--n-cpu-moeの指定を外して--fitに任せる起動、もう1つは、これらを手動で指定する起動です(手動指定が残っていると、v0.8.0の--fitは層の置き方を変えません)。99 を推奨値として固定で写すと遅くなる点に注意が必要です。

KVキャッシュ量子化とフラッシュアテンションの役割

-fa onはフラッシュアテンションの有効化。メモリ帯域の効率を上げて推論速度に寄与する仕組みです。加えて--cache-type-k q8_0と--cache-type-v（元投稿では turbo2）でKVキャッシュ自体を量子化し、VRAM消費を抑える戦略が取られています。ただし turbo2 は TurboQuant 系ビルド独自の値で、本家 llama.cpp の標準ビルドには無く起動しません。本家 llama.cpp の v0.8.0 で試す場合は、--cache-type-v を q8_0 などの標準値にします。KVキャッシュの型を変えると必要なメモリの量も変わるので、投稿者と同じ -c 50000 で8GBに収まるかは別に確かめてください。なお、--no-mmap・--mlock の読み込みの指定は、v0.8.0 では --load-mode に直します(フラグ一覧の直後の注意と、次の段落を参照)。

KVキャッシュはコンテキスト長が伸びるほどVRAMを食う部分。-c 50000のように長めのコンテキストを確保しようとすると、量子化しないと8GBに収まらない可能性が高いと考えられます。KVキャッシュとは別に、読み込みの指定にも触れておきます。元投稿の --no-mmap と --mlock の組み合わせ(v0.8.0 では --load-mode mlock)は、モデルをRAMに固定して、スワップによる速度低下を防ぐための指定です。OSが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 です。v0.8.0 では thinking のオン・オフは --reasoning on / --reasoning off で明示します(--chat-template-kwargs で渡す enable_thinking は非推奨)。ほかの引数を環境変数で渡すときも、使っているビルドのヘルプで引数名と環境変数名を確かめてください。

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

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らしく消費電力も抑えめです。68・124 tokens/秒はどちらも短い入力・思考なしでの生成速度で、答えの質や、長い入力・思考ありで使ったときの待ち時間は測っていません。RTX 4060 の8GB構成（当サイト未実測）はMoE層の大半をCPUに置くので、この2つの値より遅くなると考えられますが、どこまで落ちるかはこの記事の数字からは言えません。8GBで動くという投稿者の報告と、上の16GBでの測定値は、条件も測り方も違うので分けて読むのが安全です。

8GB VRAM環境での使い方｜投稿者の報告と、確かめていないこと

RTX 4060 8GB構成でQwen3.6-35B-A3Bを動かす際、どういう使い方の報告があり、何がまだ確かめられていないかを最後に整理します。

対話チャットに向くかは確かめていない

投稿者はこの構成を、エージェントパイプラインのサブエージェントとしてコード生成に使っていました。当サイトは8GB構成で対話したときの待ち時間や使い勝手を測っておらず、対話用途に向くかどうかはこの記事からは判断できません。

今のカードから替える先として考えられるVRAM 16GBのカード(RTX 5070 Tiなど)でも、このモデルを対話に使ったときの使い勝手は当サイトでは確かめていません。対話に使うつもりでGPUを選ぶなら、使う予定の入力の長さ・thinkingの設定・量子化で、最初の応答が出るまでの時間と生成速度を確かめてから決めるのが安全です。一方で、エージェントパイプラインの裏方として動かすなら、多少遅くてもローカルで完結するメリットの方が大きい、というのが投稿者の割り切り方でした。

RAM優先のアップグレードが向く条件

8GB VRAMのまま35Bクラスを動かす以上、GPU側でできることには限界があります。この環境でまず検討したいアップグレードは、GPU交換よりもRAMの増設と考えるのが合理的な場合が多いのではないでしょうか。

GPU買い替えでVRAMを増やすなら、16GB VRAMを持つRTX 5060 Ti 16GBが新品で最も手が届きやすい選択肢という位置づけ。RTX 5070 TiやRTX 5080も16GBなので、GPU側に置ける量はRTX 5060 Ti 16GBとほぼ変わりません。この記事で扱うQ4_K_M(約21〜24GB)は16GB 1枚には全部は載らず、当サイトの測定でも一部がCPU側になりました。この2機種との違いは計算性能やメモリ帯域です。RTX 4060 8GBからこれらに替えたとき、このモデルがどれだけ速くなるかは、この記事では測っていません。

まとめ

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

見直す順番は症状で変わります。応答が空のまま返らないときは、まずthinkingを切って切り分け、そのあと、症状が出ていた設定(thinkingオン)の応答で、思考側の出力・生成トークン数・finish_reason・クライアント側の処理を確かめます。起動の時点で読み込めないときはRAM容量とGGUFのサイズ、動くが遅いときはMoE層の置き方を見直します。--fitの自動配置と手動指定を比べるときは、--fitに任せる側の起動で-nglと--n-cpu-moeの指定を外します(指定が残っていると、v0.8.0の--fitは層の置き方を変えません)。動作したあとの使い道は、投稿者がエージェントパイプラインの裏方として使っていたという報告があるだけです。対話に向くかどうかも含め、この記事では確かめていません。

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 製品ページ