はじめに

クラウドLLM（Claude/ChatGPT/Gemini）はある程度触ったものの、初めてローカルLLMを触ってみたのでメモと所感を残す。
今となっては旧スペックの「GeForce RTX 2080Ti VRAM 11GB の一昔前のGPUで何がどこまでできるか」を実機で確かめてみた。
すべてのテスト用スクリプトと実行結果はGitHubにある。

TL;DR

この記事で分かること：

同じモデルでも量子化レベルで挙動がどう変わるか
同じパラメータ規模でも製造元（Meta / Google / Alibaba / DeepSeek）で性格が違うこと
VRAMを超える70Bモデルを「動かせる」が「実用しにくい」境界
ローカルLLMの選定基準

環境

OS：Windows 11 Pro (26200ビルド)
CPU：AMD Ryzen 9 9900X
マザーボード：ASRock X870E Nova WiFi
メモリ：64GB（DDR5）
GPU：NVIDIA GeForce RTX 2080 Ti（VRAM 11GB）
NVIDIAドライバ：595.79、CUDA対応：13.2
Python：3.12
ディスク：Cドライブ約626GB空き
LM Studio：v0.4.14、Developer Mode ON
Ollama：v0.24.0、サービス常駐

1. 触ったツール

1-1. LM Studio (v0.4.14)

GUI主体のローカルLLM環境。
Developer Modeを有効化すると、量子化レベルの詳細、Local Server機能、tokens/sec計測などの詳細情報が見える。Variants機能で同一モデルの複数量子化を簡単に切替できる点が量子化比較に強い。
バックグラウンド常駐 ON だと VRAM を食う。

1-2. Ollama (v0.24.0)

CLI と REST API 主体。最新版(2026年時点)では GUI ランチャー機能が付き、他社製エージェント（Claude Code、Codex App、Hermes Agent、OpenClaw など）の起動ショートカットも組み込まれている。

ollama pull <モデル名> で対象のモデルをインストール。
ollama run <モデル名> --verbose で対話開始。
対話中 /bye で対話終了。

実践したパターン

No.	経路	用途	学び
1	`ollama run --verbose`	CLI 対話	履歴累積で速度が落ちる体感
2	(PowerShell) `Invoke-RestMethod` で `/api/generate`	単発API	JSON ベース、`context` 配列でステートレス対話継続
3	(Python) `requests` で `stream=true/false`	ストリーミング比較	TTFT の概念、絶対速度は変わらない
4	公式 `ollama` ライブラリ	実装の簡潔さ	`messages` 配列で商用APIと共通の書き方

2. 触ったモデル

経由	モデル	総パラメータ	量子化	DLサイズ	用途
LM Studio	Gemma 4 E4B	7.9B (active 4B)	Q4_K_M	6.33GB	世代差比較・MatFormer体感
LM Studio	Gemma 3 4B	4B	Q3_K_L	3.09GB	量子化比較
LM Studio	Gemma 3 4B	4B	Q4_K_M	3.34GB	量子化比較（基準）
LM Studio	Gemma 3 4B	4B	Q4_0 QAT	3.21GB	QAT vs PTQ 比較
LM Studio	Gemma 3 4B	4B	Q6_K	4.04GB	量子化比較
LM Studio	Gemma 3 4B	4B	Q8_0	4.98GB	量子化比較
Ollama	Gemma 4 E4B	7.9B (active 4B)	Q4_K_M	9.6GB	Ollama経由とLM Studio経由の比較
Ollama	Llama 3.1 8B	8B	Q4_K_M	4.9GB	Meta製、英語中心モデル体感
Ollama	Llama 3.3 70B	70B	Q4_K_M	42GB	ハイブリッド推論実験
Ollama	Qwen 2.5 7B	7B	Q4_K_M	4.7GB	Alibaba製、東アジア言語強い
Ollama	DeepSeek-R1 Distill 7B	7B	Q4_K_M	4.7GB	推論特化モデル比較

合計ディスク使用：約91GB
同じモデルでも Ollama と LM Studio ではファイルサイズが異なる
（Gemma 4 E4B は LM Studio 6.3GB に対し Ollama 9.6GB）

3. やったこと

3-1. 以下4つのプロンプトを投げる（LM Studio / Ollama）

Q1. 日本語で自己紹介を300文字書いて
Q2. Pythonで階乗を計算する関数を再帰なしで書いて。例外処理も入れて。
Q3. 2024年の日本のIT業界トレンドを3つ挙げて、それぞれ100字程度で説明して
Q4. 2025年の生成AI業界で最も大きな変化を3つ挙げて、それぞれ100字程度で。具体的なモデル名や会社名も入れて。

（指定してる年が 2024年 / 2025年の理由はモデルの学習タイミングに合わせた。）

3-2. RESTリクエストを投げてみる（Ollama llama3.1:8b）

PowerShell から Invoke-RestMethod メソッドで REST リクエストを実施して戻り値を見るテスト。
llama3.1:8bのみで実施。

3-3. Pythonから使ってみる（Ollama）

GitHubにあるテストコードを実行。

stream_test.py
⇒ stream有効・無効の挙動の違いを検証
ollama_lib_test.py
1. test_1_generate()
  ⇒ 旧式の completion スタイル。プロンプト1本投げて応答1つ受ける
2. test_2_chat_with_system()
  ⇒ messages 配列スタイル。system プロンプトで挙動を制御
3. test_3_chat_streaming()
  ⇒ messages + streaming。chat 履歴を持ちつつトークン即時表示
4. test_4_multi_turn()
  ⇒ マルチターン対話。messages 配列に履歴を積んでいく

4. 実行結果（LM Studio 経由）

4-1. Gemma 世代差比較

観点	Gemma 3 4B	Gemma 4 E4B
総パラメータ	4B	7.9B（active 4B）
アーキテクチャ	Transformer	MatFormer※
reasoning機能	なし	標準搭載（6〜12秒思考）
平均 tok/s	95.4	71.4（約25%遅い）
平均出力tokens	353	1296（3.7倍冗長）
知識限界の自覚	弱い（素でハルシネーション）	あり（「未来予測」と注釈）
マルチモーダル	テキストのみ	画像入力対応

※ MatFormer とは：Matryoshka Transformer。1つのモデルの中に複数サイズが入れ子で内包される構造。推論時に「今回は4B相当で動かす」と動的に切り替えられる。エッジデバイス向け設計思想で、Google Pixel などで採用されているらしい。

所感

応答速度はむしろ Gemma 3 の方が速い
reasoning がない分、Gemma 3 は 4 に対して応答速度で勝る
Gemma 4 の利点は正確性と用途幅
逆に、Gemma 4は正確性と用途の面で上回る。速度を犠牲にしてより知性的になるというトレードオフで、単純に高性能化したとは言えない結果となった

Gemmaで選ぶなら、コード生成のような定型タスクであれば Gemma 3、複雑な指示ならば Gemma 4 という選定基準が良い。

4-2. 量子化レベル差（Gemma 3 4B、全5バリアント）

Gemma 3 4Bの各量子化バリエーションの比較結果。

量子化	サイズ	VRAM消費	平均 tok/s	コード設計	知識整合性
Q3_K_L	3.09GB	5970 MiB	94.7	△ 無意味な try-except	架空組み合わせ生成（Meta Ray Tracing）
Q4_K_M	3.34GB	6197 MiB	95.4	△ catch→None	既存名乱列
Q4_0 QAT	3.21GB	5997 MiB	95.4	◎ 素直	正しい
Q6_K	4.04GB	6809 MiB	86.9	◎ 素直	架空組み合わせ生成（みずほFG AI Edge）
Q8_0	4.98GB	7725 MiB	79.0	△ 後退	全部実在

所感

4bit帯（Q4_K_M と Q4_0 QAT）が速度最速で同点
GPU カーネル最適化が4bit帯に集中しているせいか、ビット数とは別の理由からか速度面で優位だった
速度はビット数と単純な反比例ではない
Q3_K_L < Q4帯が反直感（3bitなのに4bitより遅い。誤差？）、Q6 > Q8 は順当（ビット数増で計算量増）
VRAM はファイルサイズと正比例
Q3_K_L < Q4_0 QAT < Q4_K_M < Q6_K < Q8_0
品質向上は逓減
Q3 → Q4 で大きく改善（HTMLタグ混入が消える）、Q4 → Q6 で改善（コード設計向上）、Q6 → Q8 はほぼ横ばい
ハルシネーションは量子化と無関係
Q8 でも実在サービスを「2025年の変化」と誤る。学習データ起因で量子化精度では消えない様子

4-3. Q4_K_M (PTQ) と Q4_0 QAT の比較結果

観点	Q4_K_M	Q4_0 QAT	QATの優位
サイズ	3.34GB	3.21GB	-130MB
VRAM	6197 MiB	5997 MiB	-200MiB
tok/s	95.4	95.4	完全同等
コード設計	△	◎	明確に勝ち
知識整合性	既存名乱列	全部実在	明確に勝ち

所感

同じ4bitでも Q4_K_M（PTQ）と Q4_0 QAT で性能に明確な差が出た。
QAT は「学習時から量子化前提」で訓練されているため、4bit 表現でも誤差を吸収する重み配置を獲得している。
Q4_0 QAT は Q4_K_M と速度・サイズ・VRAM がほぼ同等で、品質では明確に上回る。提供されているなら Q4_K_M を選ぶ理由が存在しない。Google が Gemma 系列で QAT に注力する理由を実感した。

4-4. 実測値

Gemma 4 E4B Q4_K_M

プロンプト	tok/sec	tokens	sec
Q1	71.12	1398	0.24
Q2	71.87	1830	0.11
Q3	70.98	1135	0.50
Q4	75.79	819	0.28

Gemma 3 4B Q4_K_M

プロンプト	tok/sec	tokens	sec
Q1	95.00	226	0.08
Q2	96.33	691	0.05
Q3	92.28	244	0.07
Q4	98.01	252	0.07

Gemma 3 4B Q3_K_L

プロンプト	tok/sec	tokens	sec
Q1	93.96	256	0.07
Q2	97.03	699	0.06
Q3	94.32	196	0.08
Q4	93.54	203	0.0

Gemma 3 4B Q6_K

プロンプト	tok/sec	tokens	sec
Q1	88.72	259	0.07
Q2	86.73	628	0.06
Q3	87.42	256	0.08
Q4	84.74	251	0.08

Gemma 3 4B Q8_0

プロンプト	tok/sec	tokens	sec
Q1	76.98	223	0.07
Q2	79.78	689	0.06
Q3	79.56	251	0.06
Q4	79.51	270	0.08

Gemma 3 4B Q4_0 QAT

プロンプト	tok/sec	tokens	sec
Q1	98.18	233	0.06
Q2	98.10	648	0.05
Q3	93.89	209	0.07
Q4	91.48	212	0.09

4-5. モデル特性差

Llama 3.1 8B および Gemma 4 E4B に対して、Ollama 経由で同じツール、同じ system プロンプト、同じユーザー質問で対比した結果。（ollama_lib_test.py）

観点	Llama 3.1 8B	Gemma 4 E4B
製造元	Meta	Google
パラメータ	8B	7.9B (active 4B)
Ollama 版 DL サイズ	4.9GB	9.6GB
reasoning機能	なし	標準搭載
平均 tok/s（API単発）	92.78	37.73（1/2以下）
出力トークン量（同プロンプト）	114	654（5.7倍）
日本語の自然さ	△ 文法破綻あり（「お盆祭り」等の造語）	◎ ネイティブ感覚
system プロンプト追従	× 「関西弁で」を完全無視	◎ 完璧な関西弁
マルチターン記憶	-	◎（ただし「将棋さん」誤り）
装飾癖	少ない	絵文字過多

4-6. CPU/GPU ハイブリッド推論実測（Llama 3.3 70B、VRAM 11GB + RAM 64GB）

実験条件

モデル：Llama 3.3 70B Q4_K_M（DLサイズ 42GB）
ツール：Ollama（自動レイヤー分割）
GPU 担当：約23%（VRAM 9.66GB 使用）
CPU 担当：約77%（RAM 約32GB 使用）

速度実測（4プロンプト連続）

プロンプト	eval rate (tok/s)	prompt eval rate (tok/s)	duration	eval tokens
Q1. 自己紹介300字	1.61	35.81	2:16	215
Q2. Python階乗	1.60	110.12	2:42	254
Q3. 2024年トレンド	1.59	186.01	3:04	287
Q4. 2025年予測	1.58	306.80	2:39	247
平均/合計	1.60	–	計11分	-

全 VRAM に収まるとき（フル GPU 推論）との比較

モデル	配置	tok/s	倍率
Llama 3.1 8B Q4_K_M	全VRAM	92.78	基準
Gemma 4 E4B Q4_K_M	全VRAM	37.73	0.41倍
Llama 3.3 70B Q4_K_M	ハイブリッド	1.60	0.017倍

所感

生成速度はキャッシュ効果を一切受けない
4プロンプトで 1.58〜1.61 とブレずに安定。PCIe 帯域が完全な律速になっている証拠
prompt eval rate は履歴累積で上昇
35→110→186→306 tok/s と急上昇。これは KV キャッシュが効くため。**「入力理解は速くなるが、生成は遅いまま」**という非対称性
VRAM フル使用ではない
Ollama がデフォルトで KV キャッシュ拡張用に余裕（約1.6GB）を残す設計

品質面：8B → 70B で改善した点

観点	Llama 3.1 8B	Llama 3.3 70B
自己認識	「AI」と曖昧	「Meta AI が開発した LLaMA」と正確
日本語破綻	「お盆祭り」「ディジタル庶民化」	なし
知識混線	T5 を新モデル扱い	実在物のみ言及（Stable Diffusion、DALL-E、Polly等）
コード品質	`n > math.inf` の意味不明な条件	適切な isinstance チェック

品質面：8B → 70B でも治らなかった点

階乗コードのエラーメッセージで Llama 系列特有の日本語誤訳癖が残った。
（例）

8B：「n は負でなければなりません」
70B：「入力は負の値ではありません」

本来「負の値であってはなりません」が正しい。これは英語 "must not be negative" の直訳ミスで、学習データの日本語訳に含まれる癖。パラメータ数 10倍弱に増やしても解決していない。モデルファミリー固有の弱点はサイズで解決しないことが実機で確認できた。

PCIe ボトルネックについて各経路の理論値

経路	帯域	LLM推論への影響	出典
VRAM ↔ GPUコア	約 616 GB/s	フルVRAMなら問題なし	NVIDIA 公式
GPU ↔ RAM (PCIe 4.0 x16)	約 32 GB/s	約20倍遅い、ハイブリッド推論の律速	PCI-SIG 仕様
RAM ↔ CPU (DDR5-6000)	約 96 GB/s	CPU推論時の律速	計算値（6000 MT/s × 8 byte × 2 ch）

実測した 1/57 の速度低下（92.78 → 1.60 tok/s）は、これらの理論帯域差（特に PCIe が GPU内VRAM の約 1/20）と矛盾しない。しかし帯域だけで全てが説明できるわけではなく、以下の要因も影響している。

KVキャッシュアクセスのレイテンシ：帯域だけでなくランダムアクセス性能も効く
CPU 命令性能：Ryzen 9 9900X の AVX-512 が llama.cpp の最適化でどこまで活かされるかは別問題
メモリチャネル数：シングルチャネルだと帯域は半減
llama.cpp のスレッド設定：デフォルトは物理コア数だが、最適値は環境依存

「理論帯域差と整合する観察結果」のレベルであって、「PCIeボトルネックが唯一の原因と証明した」わけではない。

結論：ローカルLLMの本質的制約は VRAM 容量

メインRAM拡張で「動かない」を「動く」にはできるが、「速い」にはならない。運用想定するなら VRAM に完全に乗るサイズが大前提で、それを超えるサイズは「動作確認用」か「速度を諦めた品質優先用」と割り切るしかない。

4-7. 4モデル比較（同じ Ollama API、同じプロンプト）

4つのモデルファミリーで同じプロンプト・同じ system プロンプトを試した結果。

観点	Llama 3.1 8B	Qwen 2.5 7B	Gemma 4 E4B	DeepSeek-R1 7B
製造元	Meta（米）	Alibaba（中）	Google（米）	DeepSeek（中）
パラメータ	8B	7B	7.9B (active 4B)	7B
DL サイズ	4.9GB	4.7GB	9.6GB	4.7GB
平均 tok/s	92.78	99.73	37.73	97.65
reasoning機能	なし	なし	あり（隠す）	あり（Ollamaでは出力されず）
日本語タスクで日本語応答	◎	◎（短文時）	◎	× 英語で返す事故
自己認識	△ 曖昧	◎ Alibaba/Qwen正確	◎	× プレースホルダー残し
日本語の自然さ	△ 「お盆祭り」造語	◎ 自然（短文）	◎ 完璧	× カオス
日本語誤訳癖	× Llama系癖	◎ なし	◎ なし	-
関西弁追従	× 標準語	× 多言語混入	◎ 完璧	× 3言語カオス
マルチターン記憶	-	◎ 正確	◎（将棋さん誤り）	× 韓国語混入
推論力（数列パターン）	-	-	◎ 正解+解説	◎ 正解+LaTeX解説
多言語混入リスク	なし	長文・方言で発生	なし	頻発（英・中・韓）

注目ポイント

1. Qwen 系の弱点：多言語境界の曖昧さ

Qwen 2.5 7B は短文では完璧な日本語、自己認識も正確、エラーメッセージの助詞使いも完璧（Llama系の誤訳癖がない）。ただし長文や方言タスクで多言語にフォールバックする。

2024年トレンドの応答に中国語混入：「データ分析通过对大量数据进行高级分析」
関西弁テストにインドネシア語と英語混入：「こんにちbuat」「Liberties」「行こらっしゃい」

学習データの多言語比率が高すぎる副作用で、**「言語の境界が曖昧」**という現象が発生する。

2. DeepSeek-R1 Distill 7B は「推論ベンチマーク特化モデル」

元の DeepSeek-R1 は o1 相当の推論能力で話題になったモデル。Distill 7B にも推論能力は残っているが、汎用対話能力は犠牲になっている模様。

数列パターン（2,6,12,20,30,?）は正解を LaTeX記法付きで丁寧に解説
一方、「日本語で自己紹介して」と頼んだのに英語で返答
関西弁テストは日本語＋英語＋中国語の 3言語カオス
マルチターン対話で韓国語まで混入

reasoningモデル ≒ 万能 ではない。Gemma 4 E4B のような「汎用 reasoning モデル」と、DeepSeek-R1 のような「推論専用モデル」は設計思想が違う。

3. system プロンプト追従の三極構造

関西弁テスト（system: 関西弁で話せ）の結果が、モデル選定の本質を象徴している。

モデル	結果	一言で
Gemma 4 E4B	完璧な関西弁（『張り付いとるだけやねん』）	多言語学習 + reasoning の合わせ技
Llama 3.1 8B	標準語 + 日本語破綻（『お盆祭り』）	英語中心学習、指示追従弱い
Qwen 2.5 7B	多言語混入カオス（『buat』『Liberties』）	多言語学習の副作用で境界曖昧
DeepSeek-R1 7B	3言語カオス	推論特化で対話品質低い

4. 用途別の最適選定

用途	推奨モデル	理由
機微な日本語タスク・キャラ設定・複雑指示	Gemma 4 E4B	reasoning + 多言語安定、ただし遅い
速度重視の短文日本語（要約・分類・コード生成）	Qwen 2.5 7B	最速、短文の日本語完璧、ただし長文要注意
英語タスク	Llama 3.1 8B	Meta主力、英語データ豊富
数学・論理推論・コード推論	DeepSeek-R1 Distill	対話は捨てて推論特化で使う
大規模モデルの品質が必要（速度妥協）	Llama 3.3 70B（ハイブリッド推論）	1.60 tok/s、品質は8Bより明確に上

5. まとめ

5-1. ローカルLLM の強み

機密データを外部API に出さずに処理できる
インターネット接続不要（オフライン稼働）
API 利用料金なし、利用量無制限
レイテンシ制御が自分でできる

5-2. ローカルLLM の弱み

学習データのカットオフから先に進めない：Gemma 4 E4B でも2024年中ごろまでが上限、2026年5月の今で約1.5〜2年遅れ
最新情報・時事ネタには不向き
パラメータサイズ上限が VRAM で決まる（家庭用GPU では 7〜13B が現実的）
ファインチューニングのコストが別途必要そう
VRAM 11GBを超えるとPCIe帯域がボトルネックになり、70Bだと 0.017倍（1/57）まで遅くなる

5-3. 用途別の選定基準

用途	推奨
コード生成・補完	Q4_K_M（速度重視）または Q4_0 QAT（QATあれば一択）
論理推論・数学	Q6_K 以上 or reasoning モデル（Gemma 4 E4B / DeepSeek-R1系）
機密文書要約・分類	Q4_K_M 〜 Q6_K
最新情報問い合わせ	クラウド LLM（Claude / GPT / Gemini）一択。ローカル不適
大量バッチ処理	Q4_K_M（コスト・速度バランス最良）

5-4. クラウド LLM との使い分け

クラウド優位：最新情報、最大モデル（Claude Opus、GPT-4 など）、Web検索連携、大規模マルチモーダル
ローカル優位：機密性、コスト（API 料金ゼロ）、レイテンシ制御、オフライン、カスタマイズ性
実務では両者を併用するのが現実解。判断系・最新情報系はクラウド、定型処理・機密データはローカル

RTX 2080 Ti では大規模モデルは扱えないが、スイートスポット的なサイズのモデル（7B〜13B Q4 量子化）であれば、十分扱えることが分かった。

謝辞

今回のテストに当たって、結果の取りまとめに Claude Cowork が大奮闘してくれたのでここに謝辞を示す。