Qwen3.5の『thinking mode』を8GBで使い分ける3つの判断軸 — 『常にオン』も『常にオフ』も最適ではない2026年

『常にオン』も『常にオフ』も最適ではない

2026年のローカルLLM環境では、プロンプトエンジニアリングの「最初の選択」がプロンプト本文よりも前にある。thinking モードを使うか使わないか だ。Qwen3 から Qwen3.5 にかけて、思考プロセスを内部で長く展開する「thinking mode」のトグルが正式な仕様として入った。Anthropic の extended thinking、OpenAI の o-series、DeepSeek-R1 と続いてきた潮流の、ローカル側での実装だと思えばいい。

この toggle、APIで使う分にはあまり気にならない。だが8GBのRTX 4060でQwen3.5-9Bを動かしているような環境では、thinking modeのオン/オフは出力時間とコンテキスト消費を直接2〜10倍動かす。試しに「常にオン」で運用すると、対話アプリは遅くて使い物にならない。「常にオフ」で運用すると、数学やマルチステップ推論で目に見えて精度が落ちる。

この記事の主張はひとつだ。thinking mode は「常にオン」も「常にオフ」も最適ではない。タスク種別と速度予算で 3つの軸を引いて切り替える。 その3軸を、公開ベンチマークと8GB実機の制約から組み立てる。なお実機 tok/s の自前計測値は出さない。公開数値とアーキテクチャの制約から、判断に必要な輪郭は描ける。

thinking modeとは何をやっているのか

Qwen3/Qwen3.5 の thinking mode は、ざっくり言えば「出力の前にモデルが自分で長いCoTを書いて、それを参照してから本答を出す」仕組みだ。

具体的には、応答生成の前に

<think>...</think>

プロンプト側からは

/think

/no_think

thinking_budget

重要なのはコストの構造だ。

• 出力トークン数が thinking ブロックの分だけ膨らむ (タスクによっては 5〜20倍)
• KV キャッシュも比例して伸びる
• ローカル環境では

  tokens/sec

  がそのまま時間に効く

API 利用では「出力トークン課金」と「待ち時間」のかたちで現れるが、8GB のローカルではここに VRAM 制約 が加わる。長い thinking 出力 = 長い KV キャッシュ = 32K context 上限の手前で頭打ち。前回の catA 記事で議論した KV キャッシュ予算が、ここでまた効いてくる。

ベンチが見せる「効く場面」と「効かない場面」

Qwen 公式が出している thinking-on / thinking-off の差分は、ジャンルで明確に割れる。

表の絶対値は Qwen3-235B-A22B-Thinking-2507 と非 thinking 版の公開ベンチで、フラッグシップ規模の数字だ。

8GB に載る Qwen3.5-9B では絶対スコアは下がる(規模で素直に効く)が、thinking-on / off の差分の向きは同じ方向に出ることが Qwen 公式ブログで確認できる範囲だ。本稿で読みたいのは絶対値ではなく差分の構造のほうである。

ここから読めるのは、thinking mode は「考える時間が報われる問題」でだけ効くということだ。

• 数学やコーディングのような「ステップ間の整合性」が物を言う問題: 大きく効く (AIME で 約11ポイント)
• 一般知識の単発回答 (ファクト検索的なもの): 効かないか、誤差レベル
• 会話のリアクションや要約: コストだけが膨らんで価値が薄い

これは Qwen 固有の癖ではない。OpenAI の o-series、DeepSeek-R1、Claude の extended thinking でも基本同じ形が観察されている。

つまり、プロンプト本文を工夫する前に、「このタスクは thinking が報われる種類か」 を一段先で問うべきだ。

8GBで効いてくるトレードオフ

ここからが本題で、8GB の RTX 4060 で Qwen3.5-9B を動かしているとき、API ユーザーには見えにくいコストが出てくる。

コスト1: 出力時間
Qwen3.5-9B を Q4_K_M で 8GB に載せたとき、4060 級の GPU では概ね 20〜35 tok/sec のオーダーになる、というのが llama.cpp 系コミュニティで報告されている数字だ (環境依存、CPU オフロードがあると半分以下)。thinking ブロックが 1000 トークン以上に伸びると、それだけで 30秒〜1分の待ち時間が乗る。これは対話 UX では致命的だ。

数値で具体化するとこうなる。仮に 25 tok/sec (上記レンジの中央) として、

thinking budget 256 トークン  → 約 10 秒
thinking budget 1024 トークン → 約 40 秒
thinking budget 2048 トークン → 約 80 秒

これに本答 (200〜500 トークン程度) の生成時間が乗る。対話で許容できるのは合計で 5〜10 秒前後だから、現実には budget = 256 前後が対話用の上限になる。フル thinking-on (budget 上限なし) を許すのは、非同期バッチか待たせていい用途に限られる。

コスト2: KV キャッシュ
前回触れたとおり、Qwen3.5 は Gated DeltaNet と Gated Attention のハイブリッドで、KV キャッシュは一般的な dense モデルより軽い。それでも thinking 出力が伸びる分はそのまま KV を食う。Q4_K_M モデル本体 ~5.7GB + 32K まで張ったときの KV キャッシュ + 表示・CUDA バッファで、8GB は ギリギリの予算で回している。thinking を常時オンで context を膨らませ続けると、簡単に頭打ちにぶつかる。

コスト3: コンテキスト汚染
複数ターンの会話で thinking ブロックを履歴に残し続けるか、削るか、という運用設計が必要になる。残せば次ターンの入力コンテキストが thinking で埋まり、削れば「さっきなぜそう答えたか」を本人(モデル)が思い出せなくなる。ローカル運用ではここを自前で決める必要がある。

API なら課金で表現される問題が、ローカルでは VRAM・時間・運用複雑度の3軸に分散して降りてくる。それを踏まえた上で、3つの判断軸を立てる。

軸1: タスクは「ステップ間整合性」を要求しているか

最初の判断軸はタスクの性質だ。

• 要求している (thinking on を推奨): 多段の数式、複数ステップのアルゴリズム検討、コードのデバッグ、矛盾の検出、要件からの設計分解。
• 要求していない (off で十分): 単発の事実確認、フォーマット変換、文章の言い換え、定型的なコード補完、要約、翻訳。

判定の目安は「途中で間違ったまま進むと最終答えが崩れるか」だ。Yes なら thinking-on が効く。No なら off で時間とトークンを浮かせる。

具体例で見ると線引きが立ちやすい。たとえば「

fn(x)

[::-1]

reversed()

.reverse()

過去の記事 (ID:96) で書いた「『ステップで考えて』と書いたら local LLM が逆に悪化した」現象とは別系統で読む必要がある。あの記事は外部から CoT をプロンプトで強制する話だった。thinking mode はモデル内蔵の推論回路を起こす機能で、訓練分布的に「効く問題」と「効かない問題」がはっきりしている。プロンプトでの強制CoT が逆効果になっていたタスクでも、モード切替で素直に on にすれば改善することがある — というのが、両者の使い分けの肝だ。

軸2: 速度予算は対話的か非同期か

第2軸は応答時間の許容度だ。

• 対話 (off 推奨): チャット、コーディング補完、リアルタイム支援。1〜3秒以内の応答が要求される。Qwen3.5-9B の thinking-on は4060環境で簡単に10秒を超えるので、対話 UX 上は使えない場面が多い。
• 非同期/バッチ (on 可): コードレビュー、テスト生成、複雑な問い合わせを「夜の間に回しておく」用途。応答時間を気にしない代わりに精度を取りに行ける。

軸1で「効く問題」だったとしても、軸2で対話文脈なら off に倒す、というのが現実解になる。「数学的だが対話で速く返したい」場合は thinking-off で挑んで、不正解だったら thinking-on で投げ直す、という二段構えが合理的だ。

軸3: 出力長の予算と KV の余力

第3軸は資源の側だ。8GB という制約は thinking を「使えるが安くはない」道具にする。

• 余力あり (on 可): 短いコンテキスト (4K〜8K) でモデルを呼んでいる場合、KV キャッシュには余裕がある。thinking で 1000〜2000トークン使っても 8GB に収まる。
• 余力なし (off 推奨): すでに 16K〜32K のコンテキストでツール呼び出しや長い履歴を持っている場合、thinking ブロックの追加でカード上限を超える。実用上は thinking-off に固定する。

ここで

thinking_budget

実運用での budget の目安としては、4060/8GB の制約下では次の3段階くらいに固めると扱いやすい。

• 対話モード: budget 0 (= thinking-off)、もしくは 128 まで。即答性優先。
• ハイブリッドモード: budget 256〜512。対話ぎりぎりの範囲で thinking を許す。デバッグや短い設計判断に向く。
• バッチモード: budget 上限なし or 4096+。非同期で精度を取りに行く。

このプリセットを3つ用意してアプリ側で切り替えるだけで、軸1〜3の判断をUIに表出させることなく、利用者は「速度を上げる/精度を上げる」のスライダーとして触れるようになる。

3つの軸を合わせて1枚の表に落とすとこうなる。

プロンプト側の制御 — タグと budget

llama.cpp 系の Qwen3.5-9B GGUF で thinking mode を制御するには、入力プロンプトに

/think

/no_think

/no_think

# thinking-off をデフォルトに固定する例 (chat-template に /no_think を埋め込む)
# プロンプトは "You are a helpful assistant. /no_think\nUser: ..." の形に整形

thinking_budget

軸2 (対話)に厳しい運用では、入力に応じて自動でモード切替を判定するルーターを前段に置くのが現実解だ。

ルーターのシンプルな第一近似はキーワードベースで動く。

# 簡易ルーターの第一近似 (擬似コード)
THINKING_KEYWORDS = {"solve", "prove", "debug", "optimize",
                    "計算", "証明", "デバッグ", "最適化"}
SHORT_INTENT = {"what is", "how do i", "explain briefly",
                "とは", "簡単に"}

def route(query: str) -> str:
    q = query.lower()
    if any(k in q for k in THINKING_KEYWORDS):
        return "/think"
    if any(k in q for k in SHORT_INTENT):
        return "/no_think"
    if len(query) < 80:           # 短い問いは即答側
        return "/no_think"
    return "/no_think"            # デフォルト off (8GBの保守側)

これだけで軸1の判定はかなり捌ける。さらに精度を上げたければ、Qwen3.5-4B のような軽量モデルをルーター専用に置いて「これは多段推論が要りそうか?」を1秒以内で判定させる二段構成にできる。8GB なら 4B + 9B のスワップ運用も視野に入る (4Bは Q4 で 2.5GB 級、メモリは余る)。本記事ではここまで踏み込まないが、設計の方向としては筋がいい。

反証側 — thinking-onが裏目に出る場面

「考えさせれば精度が上がる」と素朴に信じると 8GB ではかえって損をする。thinking mode が裏目に出る場面を3つ書いておく。

裏目1: ハルシネーションの長文化
thinking ブロックの中で誤った仮説が立つと、モデルはその仮説を補強する方向に追加の推論を積む。短く答えていれば短いハルシネーションで済んだものが、長い「説得力のあるハルシネーション」に化ける。事実確認系のタスクで thinking-on にすると、これが頻繁に観察される。

裏目2: 過剰思考 (over-thinking)
簡単な問題に対しても thinking ブロックが膨らみ、シンプルな正解にたどり着くのに何百トークンも費やす。ベンチ評価では精度に効くが、UX としては「遅くて何も生んでいない」状態になる。

thinking_budget

裏目3: コンテキスト汚染
複数ターンの会話で thinking ブロックを履歴に残し続けると、入力コンテキストが膨れあがり、後続ターンで本来の指示が「中の方」に埋もれる (lost in the middle 現象)。ローカル運用では、thinking ブロックは生成直後に履歴から削除する設計が安全だ。

これらは Qwen3.5-9B 固有ではなく、推論モード一般に観察される副作用だが、8GB ではコストの絶対値が大きいため、より明確に効く。

残った疑問

書いていて引っかかったのは、「thinking mode の最適化はモデル開発者の責任なのか、利用者の責任なのか」という線引きだ。

thinking_budget

次に試したいのは、軸1の自動判定 (キーワードベースのルーター) をどこまで簡素に作れるか、だ。Qwen3.5-9B を呼び出す前段にもう一つ軽量モデル (Qwen3.5-4B でも十分そう) を置いて、「これは thinking 必要?」を10ms で判定させる構成が、8GB のなかでもう一段使い倒し方を増やしそうな気がしている。

「考えるか考えないか」を本体モデルに任せず、入り口で別の小さなモデルに振り分けさせる。これはローカル LLM 運用のお作法として、案外汎用に効くパターンかもしれない。