私はここ数日、RTX 4070でローカルのQwen 35Bを追いかけています。エキスパートをCPUに追い出すと2.8倍速くなる勝ち構成で34.6 tok/s、標準7問で7/7正解、さらにコーディングエージェントのバックエンドとしても成立する、というところまで確かめてきました。
そんな折、新世代の Qwen3.6-35B-A3B がオープンウェイトで出ました。同じMoEの35B-A3B、Apache 2.0、しかもエージェンティックコーディング特化を謳っています。当然、同じ4070・同じ勝ち構成で測りたくなります。
結果、私は一度「3.6は3.5の半分の速度だ」と書きかけました。そして危うく、それを公開するところでした。本記事は、その誤報を寸前で食い止めた話です。犯人はモデルではありませんでした。
第一報: 「3.6、遅くない…?」
GGUFを落として、3.5とまったく同じ勝ち構成で回しました。
llama-server -m qwen36.gguf -ngl 99 --cpu-moe -c 4096 ...
標準7問を流すと、答えは全問正解。ところが速度が振るいません。
| 速度(tok/s) | |
|---|---|
| 3.5(数日前の実測) | 34.6 |
| 3.6(この日の実測) | 12〜13 |
半分どころか、3分の1近くまで落ちています。「新世代なのに遅くなった? エージェント特化で重くなった?」と、一瞬それらしい仮説が頭をよぎりました。記事のタイトルまで「3.6は賢いが遅い」と考え始めていました。
危ないのはここです。それらしい仮説は、検証を止める誘惑になります。
違和感: 基準が再現しない
書き始める前に、ひとつ引っかかりました。比較対象の3.5を、今もう一度測ったらどうなるのか。
念のため、3.5と3.6を続けてllama-benchにかけました。
qwen35.gguf ncmoe48 → 12.88 tok/s
qwen36.gguf ncmoe48 → 12.65 tok/s
おかしい。3.5まで12 tok/sに落ちている。 数日前は確かに34.6が出ていたのに、今日は同じ構成で再現しません。3.6だけが遅いのではなく、両方が同時に遅い。
これで仮説が裏返りました。原因はモデルの世代差ではなく、今この瞬間のGPU環境にある。両者が揃って落ちているのは、共通の何かが効いている証拠です。
犯人探し: VRAMを見る
nvidia-smiでメモリを見ました。
memory.used : 11442 MiB
memory.free : 569 MiB ← 12GB中、空きがこれだけ
12GBのうち11.4GBが埋まり、空きは569MBしかありません。私のモデルを動かす前から、誰かがVRAMをほぼ食い尽くしています。実行中のプロセスを問い合わせると、犯人が見えました。
pid 136, [N/A], [Not Found]
WSL2から見て「Not Found」、つまりWindows側のプロセスです。心当たりがありました。GPUの空き時間を貸し出すアプリ(Salad)が、裏で動いてVRAMを9〜11GB占有していたのです。
理屈はこうです。勝ち構成は「エキスパートはCPU、アテンションとKVキャッシュはGPU」に置くことで速度を稼ぎます。VRAMが埋まっていると、そのアテンション/KVをGPUに載せきれず、本来GPUで回るはずの計算まで遅い経路に落ちます。だからモデルに関係なく、3.5も3.6も同時に失速していた、というわけです。
真の数字: VRAMを空けて測り直す
犯人のアプリを完全に終了してもらい、VRAMが空いたことを確認しました。
memory.used : 339 MiB
memory.free : 11672 MiB ← クリーン
この状態で、今度は3.6を先に測りました(Saladは止めても1〜2分で自動復活するので、測りたい方を先に回すのが安全です)。
| model | clean時の速度(tok/s) | アーキ(GGUFメタ) |
|---|---|---|
| Qwen3.6-35B-A3B | 38.76 ± 0.82 | qwen35moe 34.66B 48層 |
| Qwen3.5-35B-A3B | 34.9〜38.6 | qwen35moe 34.66B 48層 |
同じでした。 3.6はclean状態で38.76 tok/s、3.5も同じ水準。半速どころか、誤差の範囲でまったく同速です。
種を明かすと、答えはGGUFのメタデータに最初から書いてありました。両者とも qwen35moe 34.66B 48層 20.5GiB と、寸分違わず同じアーキテクチャです。3.6-35B-A3Bは構造を変えた新型ではなく、同じ器のまま中身を鍛え直した精錬版だったのです。同じ計算量なら、同じ速度が出るのは当たり前でした。
では、賢くなったのか — 標準7問では差が出せなかった
速度が同じなら、世代を上げた意味は品質に出ているはず。そう考えて、3.5に解かせたのと同じ標準7問(日本語/英語/コード/論理推論)を3.6にも解かせ、回答を並べました。
結論から書きます。この7問では、3.5と3.6の差を見つけられませんでした。
両者とも7問すべて正解です。認知バイアスの引っかけ(バットとボール問題)も、思考モードを切った状態で「直感の10セントは誤り」と否定して5セントを導く流れは、3.5も3.6も同じでした。
私は最初、3.6のほうが回答が丁寧だと書こうとしました。ところが3.5の回答と並べた瞬間、その主張は崩れました。
| 問 | 3.5 | 3.6 |
|---|---|---|
| WebRTC vs WebSocket | 3点+選択基準+まとめ(593tok) | 3点+用途(514tok) |
| フランスの首都 | Paris + セーヌ川・金融都市の補足(55tok) | Parisのみ(9tok) |
| quicksort計算量 | 漸化式T(n)+表+空間計算量(471tok) | 表+introsort/std::sort(562tok) |
| top-3コード | 重複ケースまで考慮(361tok) | 要素3未満でValueError(239tok) |
見てのとおり、むしろ3.5のほうが厚い問もあります(フランスの首都やWebRTC)。quicksortは3.6がintrosortに触れる一方、3.5は漸化式を出す。どちらが上とも言えません。差は「世代差」というより、その時々の生成のブレの範囲に見えました。
理由はたぶん単純で、問題が易しすぎたのです。7問とも、3.5の時点ですでに満点。満点同士を比べても、上限に張りついた答案の差は出ません。いわゆるベンチマークの飽和(サチュレーション)です。世代間の本当の差を見たいなら、両者が転ぶくらい難しいタスク — 複雑な多段コーディングや、罠のある長文推論 — をぶつける必要があります。それは次の宿題にします。
エージェントとしての挙動も確認しました。claw-codeのバックエンドに3.6を据えて「ファイルを作れ」と指示すると、3.5と同じくwrite_fileのツール呼び出しを発火し、ファイルを作成しました。ここも成立は据え置きで、優劣はつきませんでした。
公式は「何が変わった」と言っているか
私の7問で差が出なかったのは、「差が無い」という意味ではありません。Qwen公式の発表を見ると、3.5→3.6の伸びはエージェンティックコーディングと難問に、はっきり集中していました。以下は公式モデルカードのベンチマーク値です(いずれもベンダー公称)。
| ベンチマーク | 3.5-35B-A3B | 3.6-35B-A3B | 伸び |
|---|---|---|---|
| Terminal-Bench 2.0 | 40.5 | 51.5 | +27% |
| QwenWebBench(フロントエンド生成) | 978 | 1,397 | +43% |
| SWE-bench Pro | 44.6 | 49.5 | +11% |
| LiveCodeBench v6 | 74.6 | 80.4 | +8% |
| SWE-bench Verified | 70.0 | 73.4 | +5% |
| AIME26(数学) | 91.0 | 92.7 | +2% |
| GPQA(難問QA) | 84.2 | 86.0 | +2% |
新機能としては、過去メッセージの推論を引き継ぐ「思考の保持」、ツール呼び出しパーサの標準化(qwen3_coder)、最大101万トークンの長文脈などが挙げられています。公式は一貫して「agentic coding」と「実運用での安定性」を強調しています。
ここで腑に落ちました。伸びているのは、ターミナル操作・フロントエンド生成・リポジトリ規模のコーディング・難問数学 — どれも、私がぶつけた「東京の人口は?」「quicksortの計算量は?」のような易しい単発QAとは別の軸です。だから7問では差が出なかった。3.6の進化は確かに在る。ただそれは、私の物差しが届かない場所にありました。前節で書いたベンチマーク飽和の、これが正体です。
(公称値なので鵜呑みにはしません。手元で裏を取るなら、Terminal-BenchやSWE-bench級の重いタスクを3.5と並走させる必要があります。それこそが「次の宿題」です。)
教訓: ローカルLLMベンチの落とし穴
今回いちばん持ち帰る価値があるのは、3.6の評価そのものより、危うく誤報しかけた構造のほうです。
共用GPUや、ふだん使いのマシンでローカルLLMを測るとき、数字はかんたんに汚染されます。私が踏みそうになった落とし穴と、対策はこうです。
- ベースラインを毎回いっしょに測る。新モデルだけ測って「遅い」と判断しない。既知の数字(今回なら3.5の34.6)が再現するかを必ず確認する
-
VRAMを before/after で見る。
nvidia-smiで空き容量と占有プロセスを確認。[Not Found]はWindows側プロセスの目印 - 「全部が同時に落ちたら、犯人はモデルではなく環境」。個別差なら一部だけ動くはず。揃って落ちるのは共通要因のサイン
- 背景のGPU利用アプリ(マイニング・GPU貸出・別の推論)は、測定中だけでも完全に止める。一時停止では自動復活することがある
数字そのものより、その数字が出た条件を疑えるかが、ローカルで測るときの分かれ目だと思います。
まとめ
- Qwen3.6-35B-A3Bは3.5と同一アーキ(qwen35moe 34.66B 48層)の精錬版。clean状態で速度は同じ(~38 tok/s)
- 品質は標準7問では3.5と差が出せなかった(両方7/7、易問の飽和)。一方、公式ベンチでは Terminal-Bench +27% / フロントエンド +43% などagentic coding系に伸びが集中 — 私の易問が届かない軸だった
- claw エージェントも成立は据え置き(
write_file発火)で優劣つかず(易タスクは伸びを映さない)
今回、私は二度あやうく間違えました。一度は「3.6は遅い」(VRAM汚染による誤計測)、もう一度は「3.6は丁寧」(印象だけで、3.5と並べずに書こうとした)。どちらも、3.5を隣で測り直したら消えました。
新モデルの評価でいちばん効くのは、派手なベンチより、退屈な「基準を隣で動かす」ことかもしれません。確かに言えるのは速度が据え置きという一点だけで、賢くなったかは易しい7問では分かりませんでした。それも含めて、正直な結果です。あなたが新モデルを試すとき、前モデルを隣で動かしていますか。
📖 本記事を体系化した書籍(発売中)
本記事のような実測ノートを、Ollamaの 12.2 tok/s を -ngl 99 --cpu-moe で 34.6 tok/s(2.8倍)まで引き上げる勝ち構成から、KV キャッシュ量子化、Qwen 3.5 vs 3.6 の世代差、ローカル 35B のエージェント化まで、通しで 1 冊にまとめました。
RTX 4070 で Qwen 35B を 2.8 倍速くする ― 自分の数字を疑え、実測ノート
序章 + 第1章 + 第2章は無料公開中(¥1,200)。
無料の 12 枚スライド版もあります: