※ このREADMEはQiitaから転載したものです。ぜひQiitaも読んでね！
https://qiita.com/ayeci/items/2325ed030e7ab6b61371
クラウドLLM（Claude/ChatGPT/Gemini）はある程度触ったものの、初めてローカルLLMを触ってみたのでメモと所感を残す。
今となっては旧スペックの「GeForce RTX 2080Ti VRAM 11GB の一昔前のGPUで何がどこまでできるか」を実機で確かめてみた。
すべてのテスト用スクリプトと実行結果はGitHubにある。
この記事で分かること：
- 同じモデルでも量子化レベルで挙動がどう変わるか
- 同じパラメータ規模でも製造元（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、サービス常駐
GUI主体のローカルLLM環境。
Developer Modeを有効化すると、量子化レベルの詳細、Local Server機能、tokens/sec計測などの詳細情報が見える。Variants機能で同一モデルの複数量子化を簡単に切替できる点が量子化比較に強い。
バックグラウンド常駐 ON だと VRAM を食う。
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と共通の書き方 |
| 経由 | モデル | 総パラメータ | 量子化 | 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）
Q1. 日本語で自己紹介を300文字書いて
Q2. Pythonで階乗を計算する関数を再帰なしで書いて。例外処理も入れて。
Q3. 2024年の日本のIT業界トレンドを3つ挙げて、それぞれ100字程度で説明して
Q4. 2025年の生成AI業界で最も大きな変化を3つ挙げて、それぞれ100字程度で。具体的なモデル名や会社名も入れて。
（指定してる年が 2024年 / 2025年の理由はモデルの学習タイミングに合わせた。）
PowerShell から Invoke-RestMethod メソッドで REST リクエストを実施して戻り値を見るテスト。
llama3.1:8bのみで実施。
GitHubにあるテストコードを実行。
stream_test.py⇒ stream有効・無効の挙動の違いを検証ollama_lib_test.pytest_1_generate()⇒ 旧式の completion スタイル。プロンプト1本投げて応答1つ受けるtest_2_chat_with_system()⇒ messages 配列スタイル。system プロンプトで挙動を制御test_3_chat_streaming()⇒ messages + streaming。chat 履歴を持ちつつトークン即時表示test_4_multi_turn()⇒ マルチターン対話。messages 配列に履歴を積んでいく
| 観点 | 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 という選定基準が良い。
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年の変化」と誤る。学習データ起因で量子化精度では消えない様子
| 観点 | 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 に注力する理由を実感した。
| プロンプト | 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 |
| プロンプト | 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 |
| プロンプト | 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 |
| プロンプト | 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 |
| プロンプト | 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 |
| プロンプト | 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 |
Llama 3.1 8B および Gemma 4 E4B に対して、Ollama 経由で同じツール、同じ system プロンプト、同じユーザー質問で対比した結果。（ollama_lib_test.py）
| 観点 | Llama 3.1 8B | Gemma 4 E4B |
|---|---|---|
| 製造元 | Meta | |
| パラメータ | 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 プロンプト追従 | × 「関西弁で」を完全無視 | ◎ 完璧な関西弁 |
| マルチターン記憶 | - | ◎（ただし「将棋さん」誤り） |
| 装飾癖 | 少ない | 絵文字過多 |
実験条件
- モデル：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）を残す設計
| 観点 | Llama 3.1 8B | Llama 3.3 70B |
|---|---|---|
| 自己認識 | 「AI」と曖昧 | 「Meta AI が開発した LLaMA」と正確 |
| 日本語破綻 | 「お盆祭り」「ディジタル庶民化」 | なし |
| 知識混線 | T5 を新モデル扱い | 実在物のみ言及（Stable Diffusion、DALL-E、Polly等） |
| コード品質 | n > math.inf の意味不明な条件 |
適切な isinstance チェック |
階乗コードのエラーメッセージで Llama 系列特有の日本語誤訳癖が残った。 （例）
- 8B：「n は負でなければなりません」
- 70B：「入力は負の値ではありません」
本来「負の値であってはなりません」が正しい。これは英語 "must not be negative" の直訳ミスで、学習データの日本語訳に含まれる癖。パラメータ数 10倍弱に増やしても解決していない。モデルファミリー固有の弱点はサイズで解決しないことが実機で確認できた。
| 経路 | 帯域 | 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ボトルネックが唯一の原因と証明した」わけではない。
メインRAM拡張で「動かない」を「動く」にはできるが、「速い」にはならない。運用想定するなら VRAM に完全に乗るサイズが大前提で、それを超えるサイズは「動作確認用」か「速度を諦めた品質優先用」と割り切るしかない。
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より明確に上 |
- 機密データを外部API に出さずに処理できる
- インターネット接続不要（オフライン稼働）
- API 利用料金なし、利用量無制限
- レイテンシ制御が自分でできる
- 学習データのカットオフから先に進めない：Gemma 4 E4B でも2024年中ごろまでが上限、2026年5月の今で約1.5〜2年遅れ
- 最新情報・時事ネタには不向き
- パラメータサイズ上限が VRAM で決まる（家庭用GPU では 7〜13B が現実的）
- ファインチューニングのコストが別途必要そう
- VRAM 11GBを超えるとPCIe帯域がボトルネックになり、70Bだと 0.017倍（1/57） まで遅くなる
| 用途 | 推奨 |
|---|---|
| コード生成・補完 | 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（コスト・速度バランス最良） |
- クラウド優位：最新情報、最大モデル（Claude Opus、GPT-4 など）、Web検索連携、大規模マルチモーダル
- ローカル優位：機密性、コスト（API 料金ゼロ）、レイテンシ制御、オフライン、カスタマイズ性
- 実務では両者を併用するのが現実解。判断系・最新情報系はクラウド、定型処理・機密データはローカル
RTX 2080 Ti では大規模モデルは扱えないが、スイートスポット的なサイズのモデル（7B〜13B Q4 量子化）であれば、十分扱えることが分かった。
今回のテストに当たって、結果の取りまとめに Claude Cowork が大奮闘してくれたのでここに謝辞を示す。