はじめに

12GBのGPUに、35Bのモデルは載らない。少し前なら、そう言って話は終わりでした。

けれど私のRTX 4070は、いま手元で35BクラスのローカルLLM、Qwen3.5-35B-A3Bを34.6 tok/sで動かしています(後継の3.6も同じレンジです)。Ollamaの自動設定では12.2 tok/sだったものを、設定を2つ変えるだけで2.8倍にした数字です。家庭用GPUでも、35Bは思ったより速く、十分に賢く、ちゃんと働きます。

本書は、そこに至るまでを、すべて私自身がこの1枚のRTX 4070で計測した数字だけで書いた実践書です。借りてきた数字は使いません。

この本が扱うこと

本書は、家庭用GPU(RTX 4070 12GB)でQwen3.5/3.6-35B-A3Bを動かし、速く・賢く・働かせるところまでを扱います。

扱う問いは5つあります。

• どうすればOllamaの12.2 tok/sを、2.8倍の34.6 tok/sまで引き上げられるか
• その速い設定で、賢さは本当に落ちていないのか
• Qwen3.5と3.6の世代差は、速度でないなら何に出るのか
• ローカルの35Bを、コーディングエージェントとして実際に働かせられるか
• そして、これらの数字を、どこまで信じてよいのか

これらに、私は手元のコマンドと実測値とスクリーンショットで答えていきます。

対象読者と賞味期限

本書は、ローカルLLMをすでに一度は動かしたことがある人に向けて書いています。もっと速く動かしたい、もっと賢く使いたい、日々の道具として働かせたい、という段階の方です。インストールの最初の一歩は付録に薄く置くだけにとどめました。

本書にはもう一つ、裏テーマがあります。「自分の数字を疑う」ことです。ローカルLLMの計測は、共用のPCで雑多なプロセスが動く中で行います。だから数字は簡単に汚れます。本書が品質検証や世代比較に入る前に計測の作法(第4章)を置いた理由は、すぐ次の序章で書きます。

最後に正直なことを。ここに載せた数字は、2026年6月の特定のモデル・ドライバ・GPUで私が測ったものです。モデルは更新され、ツールは変わり、数字もいずれ古びます。本書を「唯一の正解表」としてではなく、「自分の環境で測り直すための補助線」として読んでいただけると、いちばん長く役に立つはずです。

では、本編に入りましょう。

この続きはKindleで →

序章 借り物のベンチマークは、あなたのGPUを知らない

新しいモデルが出るたびに、開発元は華やかなベンチマークを公開します。前世代より何割速い、あのモデルを上回る。数字は立派です。けれど、その数字が出たのは、あなたの机の上のGPUではありません。

私の手元にあるのは、RTX 4070が1枚です。12GBのVRAM、家庭用の1枚。データセンターのGPUでも、複数枚構成でもありません。同じモデルでも、この1枚の上で出る数字は、公式の表とは違います。だから本書は、借り物のベンチマークを引用しません。すべて、この1枚のRTX 4070で、私が自分の手で測ります。

なぜローカルで、なぜ35Bか

クラウドのAPIを叩けば、もっと賢いモデルがすぐ使えます。それでもローカルで動かす理由は、3つあります。叩くたびの課金がゼロになること。コードもデータも、自分のPCの外に出ないこと。そして、好きなだけ、何度でも試せること。

問題は速度でした。35BクラスのLLMは重く、家庭用GPUでは遅くて使い物にならない、というのが通り相場です。本書はそこに反論します。Ollamaの自動設定で12.2 tok/sだったQwen 35Bを、設定を2つ変えるだけで34.6 tok/sにします。2.8倍です。家庭用GPUの35Bは、実用ラインに乗ります。

ただし、自分の数字にもだまされる

自分で測ることには、落とし穴もあります。

私は一度、新しいQwen3.6が前世代の半分の速度しか出ず、世代が劣化したと記事に書きかけました。実際には、私のGPUのVRAMを別のプロセスが握っていただけで、モデルには何の罪もありませんでした。遅かったのは、モデルではなく私の計測環境です(この一件は第6章で扱います)。

借り物のベンチマークも信用しません。けれど、自分の出した数字も鵜呑みにしません。本書が最後まで手放さない態度は、この「自分の数字を疑う」です。だから品質検証や世代比較に入る前に、計測そのものを疑う章(第4章)を置きました。

この本の地図

これから測るのは、家庭用GPUで35Bを「速く・賢く・働かせる」までの全工程です。本書は3部構成です。

• 第1部 速く動かす: 勝ち構成で2.8倍にし(第2章)、メモリと文脈をやりくりする(第3章)
• 第2部 速さと賢さ、世代を測る: 計測の作法(第4章)を土台に、品質(第5章)と世代差(第6章、第7章)を測る
• 第3部 働かせる: ローカル35Bをエージェントにし(第8章)、2つのCLIを比べ(第9章)、Qwen Codeを使いこなす(第10章)

借り物のベンチマークではなく、この1枚のRTX 4070で測った実測を3部で積み上げる

最後に、実測から持ち帰れる知見を終章にまとめます。

まずは、そもそもなぜ12GBのGPUに35Bが載るのか、その理屈から始めましょう。

この続きはKindleで →

第1章 なぜ4070でローカル35Bか

第1部 4070で35Bを速く動かす

12GBのGPUに、35Bのモデルが載る。この一文を、少し前の常識で読むと矛盾しています。

4bit量子化しても、35Bのモデルの重みはおよそ20GBあります。12GBのVRAMには、どう考えても入りきりません。それなのに、本書はRTX 4070でQwen3.5-35B-A3Bを34.6 tok/sで動かします。なぜ入りきらないものが動くのか。答えは、このモデルが「35BのDenseなLLM」ではなく、MoEと呼ばれる仕組みでできているからです。

35Bのうち、実際に動くのは3Bだけ

Qwen3.5/3.6-35B-A3Bという名前には、2つの数字が入っています。35Bが総パラメータ数、A3Bの3Bが、推論時に実際に活性化するパラメータ数です。Aは Active(活性)の頭文字です。

これがMixture-of-Experts(MoE)という設計です。モデルの中には多数の「エキスパート」と呼ばれる小さな専門家集団があり、トークンを1つ生成するたびに、その中のごく一部だけが選ばれて働きます。35Bぶんの専門家を抱えてはいるものの、1トークンごとに動くのは、そのうちの3Bぶんだけなのです。

Denseなモデル、つまり毎回すべてのパラメータが働くモデルとは、ここが決定的に違います。Denseな35Bは、1トークンごとに35Bすべてを計算します。MoEの35B-A3Bは、35Bを抱えながら、毎回の計算は3B相当で済ませます。

この「抱えるパラメータは大きいが、毎回動くのは小さい」という性質が、家庭用GPUでの逆転を生みます。

Denseは毎回全パラメータを計算する。MoEは35Bを抱えつつ、毎回動くのは約3Bぶんだけ

「全部GPUに載せない方が速い」という入口

普通に考えれば、モデルは全部GPUに載せたほうが速いはずです。GPUはCPUより圧倒的に速いのだから、と。

ところがMoEでは、この直感が裏切られます。本書の勝ち構成は、エキスパートをあえてGPUに載せず、CPU側に退避させる設定です。フラグで言えば --cpu-moe。詳しい中身は第2章で測りますが、ここでは「全部GPUに詰め込むより、計算が軽いエキスパートはCPUに逃がしたほうが、全体としては速くなる場面がある」という反直感だけ、頭の隅に置いてください。

なぜそうなるかの理屈も第2章で扱います。鍵になるのは、エキスパートの計算が疎で軽いこと、そしてGPUに本当に置きたいのはエキスパートではなく別の部分だ、ということです。

コラム: Qwenとは何者か

ここで一度、私たちがこれから測り続けるモデルの素性を確認しておきます。

本書が測るQwenは、Alibaba Cloudが開発する大規模言語モデル群です。中国語名は通義千問(Tongyi Qianwen)、「意味を通し、千の問いに答える」という意味になります。前身は2020年のマルチモーダルモデルM6で、2022年に立ち上がったTongyi Labがこの系譜を受け継ぎました。

公開の歩みは駆け足です。年表で並べます。

• 2023年4月: 「通義千問」名でベータ公開
• 2023年8月: 7B / 72B / 1.8B をオープンウェイトで配布開始
• 2024年6月: Qwen2 を公開
• 2025年4月: Qwen3。MoE を採用
• 2025年11月: Qwenチームの注意機構の論文「Gated Attention」が NeurIPS 2025 の Best Paper を受賞
• 2026年1月時点: 累計ダウンロード7億超、派生モデルは20万を超え、オープンLLMで世界初の規模に

Alibaba Cloudがオープンウェイトで配り続けた系譜の先に、本書が測る35B-A3Bがある

本書が扱う35B-A3Bも、この系譜に連なるApache 2.0のモデルです。面白いのは、Best Paperを受賞したGated Attentionの考え方が、直後の世代のQwenモデル群に反映されていると各所で語られている点です。学会で最高評価を得たばかりの研究が、いま私の手元のGPUで動くモデルの近縁に位置している、というくらいの距離感で捉えてもらうのがちょうどよさそうです。

そして「A3B」。総パラメータ35Bのうち、推論時に実際に動くのは3Bだけ。これがMoEの肝で、12GBのRTX 4070でも35B級が実用速度で動く土台になります。重みそのものは20GBあり、GPUに全部は載りません。そこをどう収めるかは、第2章の --cpu-moe で扱います。

皮肉も書いておきます。2026年4月、Qwenのフラッグシップ(3.6-Max)は、3年の歴史で初めて重みを公開せずAPI限定になりました。それでも私が手元のGPUに載せて好きなだけ叩けるのは、彼らが「配ってくれた」オープンウェイトのモデルだからです。手元で測れること自体、当たり前ではありません。

このコラムの事実は、Wikipedia・Qwen公式ブログ・モデルカード・NeurIPSとAlibabaの公式発表で裏を取っています。出典は巻末の参考文献にまとめました。制作秘話の類は、出回っている情報の真偽が確かめにくいので、本書では裏の取れた事実だけを書いています。

ここまでの整理

12GBのGPUで35Bが動くのは、Qwenが35B-A3BというMoEモデルで、毎回動くのは3Bぶんだけだからです。そして本書の主役は、Alibaba Cloudがオープンウェイトで配ってくれた、Apache 2.0のモデルです。

理屈はわかりました。では、その理屈を使って、実際にどれだけ速くできるのか。ここからは数字の話です。

この続きはKindleで →

第2章 勝ち構成 —cpu-moe で2.8倍

結論から書きます。Ollamaの自動設定で12.2 tok/sだったQwen3.5-35B-A3Bは、llama.cppの次の設定で34.6 tok/sになりました。2.8倍です。

llama-server -m qwen35.gguf -ngl 99 --cpu-moe -c 4096

たった2つのフラグ、-ngl 99 と --cpu-moe。これが本書で言う「勝ち構成」です。この章では、なぜこれが効くのか、そして雑に真似しても再現しない理由までを、実測値で追います。

検証環境は次のとおりです。RTX 4070(12GB)、RAM 31GB、WSL2 Ubuntu 24.04、CUDA 12.9。モデルはQwen3.5-35B-A3BのQ4_K_M量子化(20.49 GiB、34.66Bパラメータ)です。

ベースライン: Ollamaの12.2 tok/s

まず、何もチューニングしない状態を測ります。Ollama 0.20.2に同じモデルを読ませると、生成速度は12.2 tok/sでした。このときOllamaは自動で、モデルの58%をCPU、42%をGPUに振り分けています。VRAM使用量は約11.4GBでした。

この12.2 tok/sは、決して異常な遅さではありません。Ollamaは賢く自動オフロードをしてくれていて、35Bが12GBのGPUで動いている時点で十分立派です。問題は、この自動配分が「MoEにとっての最適」ではない、という点です。

勝ち構成: エキスパートだけCPUに逃がす

llama.cppに切り替えて、配分を手で指定します。

-ngl 99 は、モデルの全層をGPUに載せる指定です。99という数字は「全部」を表す慣用で、実際の層数(48)を超えていれば全層を意味します。一見すると、12GBに収まらないはずです。

そこに --cpu-moe を足します。これは「MoEのエキスパートだけはCPUに置く」という指定です。全層をGPUに、と言いながら、エキスパートだけは例外的にCPUへ逃がす。結果として、GPUにはアテンションとKVキャッシュが載り、CPUには疎なエキスパート計算が載ります。

この配分で、生成速度は34.6 tok/sになりました。VRAM使用量は11.7GB、12GBの95%まで使い切っています。

なぜエキスパートをCPUに逃がすと速くなるのか。理屈はこうです。

• エキスパートの計算は疎です。1トークンで動くのは128個中8個だけなので、CPUでも負担が軽い
• 一方、アテンションとKVキャッシュは、メモリ帯域の速さがそのまま速度に効きます。GPUの帯域(数百GB/s)はCPUの帯域(数十GB/s)を圧倒します
• 12GBにエキスパートまで無理に詰め込むと、帯域が効くアテンションとKVキャッシュの置き場が削られ、全体が破綻します

つまり最適解は、「帯域が効く部分はGPUに全部、計算が疎なエキスパートはCPUに」という役割分担なのです。

帯域が効く部品はGPUに、疎な計算はCPUに。この役割分担が2.8倍の正体

手元で再現する

借り物でない数字なので、再現の手順も全部出します。まずllama.cppをCUDA有効でビルドします。

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

速度の計測には、付属の llama-bench を使いました。生成側はトークンを128個生成する条件(tg128)で、複数回試行して測ります。

./build/bin/llama-bench -m qwen35.gguf -ngl 99 -ncmoe 48 -n 128 -r 3

-ncmoe 48 は --cpu-moe と同じ意味で、48層すべてのエキスパートをCPUに置く指定です。この数字を変えれば、次のスイープがそのまま再現できます。実際にサーバとして使うときは、同じフラグでllama-serverを立てます。

./build/bin/llama-server -m qwen35.gguf -ngl 99 --cpu-moe -c 4096

オフロード比率スイープの全実測

「全部CPUに逃がす」が本当に最適なのか。エキスパートを少しずつGPUに戻していくと、速度はどう動くのか。-ngl 99 を固定したまま、CPUに置くエキスパート層の数(n_cpu_moe)を変えてスイープした全結果が、次の表です。

n_cpu_moe	GPU側のエキスパート層	生成速度 tg128 (tok/s)	ベースライン比
48	0(全CPU)	34.60	2.8倍
44	4	27.19	2.2倍
40	8	16.88	1.4倍
36	12	15.29	1.3倍
32	16	14.06	1.2倍
28	20	12.85	1.1倍
24	24	11.71	0.96倍

エキスパートをGPUに戻すほど速度は落ち、24層まで戻すとOllamaの自動設定すら下回る

きれいな単調変化です。エキスパートをGPUに戻せば戻すほど、速度は落ちていきます。24層をGPUに戻すと、もうOllamaのベースラインを下回ります。

この表が示すのは、--cpu-moe(=全エキスパートをCPU)が、中途半端な配分よりはっきり速いということです。「GPUに載るだけ載せる」が最適だと思い込んでいると、ちょうど遅い側に倒れます。

雑に真似しても再現しない

ここで一つ、釘を刺しておきます。この34.6 tok/sは、上のコマンドをコピーすれば誰でも出る数字、ではありません。

第一に、VRAMが本当に空いている必要があります。裏で別プロセスがVRAMを握っていると、エキスパートをCPUに逃がしてGPUに置いたはずのアテンションが、そもそも載りません。私はこの計測の前に、Windows側のVRAM専有を解放してから測っています。

第二に、思考モードの扱いです。Qwen3.5は thinking機能を持つため、素のまま使うと自明な問いにも延々と思考トークンを使い、回答にたどり着かないことがあります。速度や品質を測るときは、この挙動を意識して条件をそろえる必要があります。

第三に、量子化とビルドです。ここでの数字はQ4_K_M量子化、CUDA有効でビルドしたllama.cppでのものです。量子化レベルやビルドオプションが違えば、当然数字も動きます。

速い設定は手に入りました。けれど、この勝ち構成にはまだ書いていない代償があります。VRAMをほぼ使い切ることです。長い文脈を読ませたり、エージェントを動かしたりするには、メモリの余白をどう作るかという、もう一段のやりくりが要ります。次はその話です。

この続きはKindleで →