こんにちは、皆さん。
RTX 4060 (8GB VRAM) + 96GB RAM のノートPCで Qwen3.6-35B-A3B を動かしていて、うまく機能しているセットアップを共有したいと思いました。
これは インタラクティブなチャット のセットアップではありません。私はこれをエージェント型パイプライン内の コーディング・サブエージェント として使っているので、以下の選択のいくつかはその用途に特化しています。
TL;DR
- - Qwen3.6 35B A3B は、コーディングのサブエージェントとしてなら 8GB VRAM + RAM で問題なく動く
- - 私の実際のバグはクラッシュではない：無制限の「考える（thinking）」が max_tokens の上限を丸ごと消費してしまっていた
- - thinking を無効化したら解決した
- - より良い修正：リクエストごとの thinking_budget_tokens を使う
- - 未解決：8GB での最適な n-cpu-moe の分割
ハードウェア / 実行環境
- GPU: RTX 4060 Laptop、8GB VRAM
- RAM: 96GB DDR5
- 実行環境: llama-server
- モデル: Qwen3.6-35B-A3B GGUF
- 用途: コーディング・サブエージェント / 構造化パイプライン作業
現在のサーバコマンド
llama-server -m Qwen3.6-35B-A3B-Q4_K_M.gguf -ngl 99 --n-cpu-moe 99 -c 50000 -np 1 -fa on --cache-type-k q8_0 --cache-type-v turbo2 --no-mmap --mlock --ctx-checkpoints 1 --cache-ram 0 --jinja --reasoning on --reasoning-budget -1 -b 2048 -ub 2048 PowerShell 環境変数：
$env:LLAMA_SET_ROWS = "1" $env:LLAMA_CHAT_TEMPLATE_KWARGS = '{"preserve_thinking":true}' 分かりにくい選択肢についてのメモ
--n-cpu-moe 99: 8GB VRAM では、現状 MoE 層を CPU に押し出しています。これは一部は自分の制約によるもので、一部はコミュニティのチューニング議論に基づいています。公式の案内ではありません。-np 1: これは単一ユーザー / 単一エージェントのセットアップなので、追加のスロットで RAM を無駄にしたくありません。-b 2048 -ub 2048: 私のテストでは、デフォルトの低い値よりも、~2K トークンを超えるプロンプトに対するプリフィルが明確に良くなりました。LLAMA_SET_ROWS=1: コミュニティのヒントで、試しやすく、続ける価値があるように見えます。preserve_thinking: true: Qwen3.6 が明示的にこれをサポートしており、エージェントのワークフローでは、毎ターンすべてを再計算する代わりに、過去の推論をキャッシュに保持できるためです。
重要な違い：公式情報 vs 実測
ここで Qwen3.6 向けに 公式にドキュメント化されている ものがいくつかあります：
enable_thinkingpreserve_thinking- thinking モードがデフォルトでオン
- コーディング / thinking / thinking なしの用途に推奨されるサンプリングプリセット
それ以外の設定は、MoE の配置、KV 設定、バッチ / ubatch の選択など、特に 私の現在の最良の実測セットアップ か コミュニティ由来のチューニング に過ぎません。
そのため、これは 普遍的なベスト設定 というより、“動作するセットアップ + 観察結果” として投稿しています。
ハマった罠：thinking が出力予算を丸ごと食べてしまう
最初は妙なバグに見えたものの、実際には予算（バジェット）の問題でした。
私は chat.completions.create を使い、OpenAI 互換API経由で llama-server を呼び出していました。そしてリクエストごとに max_tokens を設定していました。
以下の条件：
--reasoning on--reasoning-budget -1- やや大きめのプロンプト
- 長い内部推論を誘発するコーディングタスク
…この場合、モデルは出力の予算（出力枠）を思考（thinking）に使い切ってしまい、有用な“目に見える”回答を返さないことがありました。
実際に見た例：
| max_tokens | thinking | finish_reason | 可視のコード出力 | elapsed |
|---|---|---|---|---|
| 6000 | ON | length | empty / unusable | ~190s |
| 10000 | ON | length | empty / unusable | ~330s |
| 5000 | OFF | stop | ~3750 トークンのきれいなコード | ~126s |
つまり、一部のコーディングタスクでは、モデルが「典型的な意味で失敗」していたわけではありません。推論に予算を使い切っていただけでした。
役に立つ点：リクエストごとの対処がある
私は当初、推論予算はサーバ側でしか制御できないのかもしれないと思っていました。
しかし llama-server にはリクエストごとのフィールドがあるようです：
{ "thinking_budget_tokens": 1500 } 私の理解では、これは すでに CLI で推論予算を固定していない場合 に動作します。
そのため、この用途にとってよりきれいなアプローチはおそらく：
- リクエスト単位で制御したいなら、グローバルな推論予算をハードコードしない
- 簡単なリファクタリングでは thinking を無効化する
- それを使う価値が本当にあるタスクでは、上限付きで thinking を使う
私の現在の経験則
今は次の方向に寄っています：
| タスク種別 | Thinking | 私の現時点の見解 |
|---|---|---|
| 正確な仕様からの明確なリファクタリング | OFF | スループットが良く、トークンの無駄が少ない |
| 適度に曖昧なコーディング | ON（ただし上限付き） | おそらくリクエスト単位の予算が最適 |
| アーキテクチャ / 設計上のトレードオフ | ON | そのコストの価値がある |
| 固定スキーマの抽出 / 構造化トランスフォーム | OFF | スキーマ側がほとんどの作業をする |
もう一つ：thinking のソフト切り替え
Qwen3.6 では、公式の制御面であるかのように /think や /nothink のようなプロンプトに頼るべきではないと思います。
ドキュメント化されている手順は chat_template_kwargs で、特に非-thinking モードにしたいときは enable_thinking: false です。
なので、私の現在の方針はプロンプトハックで切り替えるのではなく、その方法でモードを切り替えることです。
ぜひフィードバックがほしいこと
--n-cpu-moe8GB VRAM について：このクラスのハードウェアで「全部 CPU に押し込む」以外の、より良い分割を見つけた人はいますか？-b/-ub超長いプロンプト向けのチューニング これまでのところ 2048 は私には良さそうに見えていますが、50K+ のコンテキストを日常的に押し込んでいる人からのデータも欲しいです。- 実運用での Qwen3.6 の KV 設定 私はコミュニティの知見とテストに基づいて現在
turbo2を使っています。他の人は最終的に何に落ち着いたのでしょうか。 - エージェント型コーディングの thinking 方針 ローカルで Qwen3.6 をコーディングワーカーとして使う場合、いつ thinking を維持して、いつ強制的にオフにしますか？
役に立つなら、もっと詳細も共有できます。これはローカルなナレッジコンパイラ / プロジェクトメモリのパイプラインの一部なので、チャットのUXよりも、信頼できる構造化出力のほうをはるかに重視しています。
[link] [comments]
