私はここ数日、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 枚スライド版もあります:

RTX 4070でQwen 35Bを2.8倍速くする ― Ollamaの12.2 tok/sを34.6 tok/sに引き上げた実測ノート by @kenimo49