対象読者: ローカルLLMをこれから運用したい人、GPU選定で迷っている人
検証環境: NVIDIA RTX PRO 6000 Black Edition（VRAM 96GB）+ Ollama + Qwen3.5 シリーズ
1. はじめに — 3本の軸で考える
LLMを選ぶとき、多くの方がまず気にするのは「何Bモデルか」「何bitで動かすか」だと思います。
しかし実務では、もう1本 VRAM という軸が加わります。
この3つを 料理屋のたとえ で理解すると覚えやすいです。
| 軸 | ラーメン屋のたとえ | 意味 |
|---|---|---|
| パラメータ数 (B) | 店員の数 | 多いほど複雑な注文も捌ける。ただし厨房のスペースを食う |
| 量子化 (bit) | 各店員の料理道具の数 | 道具を減らすと省スペースだが仕上がりが雑になる |
| VRAM (GB) | 厨房の広さ | 店員と道具を全部置けるかの物理的な上限 |
核心: 店員が多い（パラメータ大）と色々な作業ができるが、厨房（VRAM）に入りきらなければ働けない。
量子化で店員の料理道具を減らせば厨房は広くなるが、その分仕上がりが雑になる。
空いたスペースはカウンター席（KVキャッシュ）に回せるので、より多くの客を同時に捌ける。
2. 最初に結論
- パラメータ数が増えると、一般に賢くなる
- 量子化をすると、軽く処理が速くなるが、品質が落ちる
- VRAMが足りないと、そもそも載らない／載っても遅い／並列に弱い →途端に実用性が無くなる
そして実務で最も大事なのは：
⚠️ 「載る」ことと「快適に使える」ことは別物
重みが入るだけでは足りず、KVキャッシュやワークスペースの余裕も必要。
3. パラメータ数とは何か
3.1 パラメータ数の意味
「7B」「35B」「122B」の数字は、モデル内部の重み（学習済みの数値）の総数です。
- 小さいモデル（0.8B〜4B）: 反応は速いが、複雑な全体像を見失いやすい
- 中型モデル（9B〜27B）: バランス型。多くの用途で実用的
- 大型モデル（35B〜122B）: 重いが、文脈や制約を保ちながら考える力が強い
3.2 パラメータ数が増えると良くなること
- 複数条件を同時に守る力
- 長い指示の保持力
- 複数ファイルにまたがる変更の影響範囲を読む力
- 修正の収束性（何回で正解にたどり着くか）
3.3 パラメータ数が増えると悪くなること
- VRAM/RAM消費が増える
- 推論速度が落ちる
- 同時実行数を取りにくくなる
3.4 Dense と MoE — 見かけのB数だけでは語れない
Qwen3.5シリーズでは、Dense型とMoE型が混在しています。
| 型 | モデル例 | 特徴 |
|---|---|---|
| Dense | 0.8B, 2B, 4B, 9B, 27B | 全パラメータを毎回使う。B数＝演算量 |
| MoE | 35B (A3B), 122B | 一部の専門家だけ活性化。総B数は大きいが演算は軽め |
実測で確認: Qwen3.5:35b（MoE/Q4_K_M）はVRAM 34GB で動き、Dense 27b（Q4_K_M）の 75GB より大幅に軽い。
これは35bがMoE構造で、重みファイル自体が23GBと小さいためです。
4. 量子化とは何か
4.1 量子化の意味
量子化とは、モデルの重みを低い精度で表現して軽くすること です。
| 量子化 | 1パラメータ | 精度イメージ | 用途 |
|---|---|---|---|
| BF16/FP16 | 2バイト | 原本そのまま | 品質最優先・研究用 |
| Q8_0 | 1バイト | ほぼ劣化なし | 品質と速度のバランス |
| Q4_K_M | 約0.56バイト | わずかに劣化 | 実用の主力 |
4.2 量子化で良くなること
- VRAM使用量が減る → より大きいモデルが載る
- 推論が速くなる場合がある
- 余ったVRAMをKVキャッシュや並列に回せる
4.3 量子化で悪くなること
- 微妙な条件の取りこぼし
- フォーマット崩れが起きやすくなる
- 複数ターンの一貫性が少し弱くなる
重要: 急激に全能力が半減する のではなく、細部の安定性がじわっと崩れる のが量子化の劣化パターンです。
5. 【実測】量子化による重みサイズの変化
5.1 理論値の計算式
重みサイズ ≒ パラメータ数 × 1パラメータあたりのバイト数5.2 Qwen3.5 実測データ — ファイルサイズ比較
以下は実際にOllamaにデプロイされている Qwen3.5 シリーズのファイルサイズです。
Dense モデル（全パラメータ毎回使用）
| パラメータ数 | BF16 | Q8_0 | Q4_K_M | 圧縮率(BF16→Q4) |
|---|---|---|---|---|
| 0.8B | 1.8 GB | 1.0 GB | — | — |
| 2B | 4.6 GB | 2.7 GB | 1.9 GB | 約41% |
| 4B | 9.3 GB | 5.3 GB | 3.4 GB | 約37% |
| 9B | 19 GB | 10 GB | 6.6 GB | 約35% |
| 27B | 55 GB | 29 GB | 17 GB | 約31% |
MoE モデル（一部専門家のみ活性化）
| パラメータ数 | BF16 | Q8_0 | Q4_K_M |
|---|---|---|---|
| 35B (A3B) | 71 GB | 38 GB | 23 GB |
| 122B | — | — | 81 GB |
💡 読み方: 27B Dense の BF16 は 55GB。Q4_K_M にすると 17GB。約3分の1 になる。
この差が、そのまま「空きVRAM = KVキャッシュと並列の余裕」に変わる。
6. VRAMとは何か
6.1 VRAMは「使い物になるかの境界線」
VRAMはGPU上のメモリです。不足は段階的な問題として現れます：
| 状態 | 症状 |
|---|---|
| ❌ 載らない | モデルがロードできない |
| ⚠️ 動くが苦しい | 短文は答えるが、長文脈や並列で落ちる |
| ⚠️ 動くが遅い | 一部をCPU/RAMへ逃がしているため激遅 |
| ✅ 余裕がある | 長文脈・複数リクエストにも耐える |
6.2 VRAMは重みだけでは決まらない
実際のVRAM使用量は以下の合計です：
実VRAM ≒ モデル重み + KVキャッシュ + アクティベーション + ランタイム予備実務では「重みが入る ≠ 運用できる」 です。
6.3 「載る」「動く」「余裕がある」の3段階
本番運用で狙うべきは 「余裕がある」 です。
特にコーディング用途では、テストログ・diff・ファイル抜粋が次々に積まれるため、KVキャッシュが急増します。
7. 【実測】VRAM使用量 — Qwen3.5 全モデル比較
以下は NVIDIA RTX PRO 6000（VRAM 96GB = 97,887 MiB）で実測した結果です。
各モデルを 単独ロード して nvidia-smi で計測しています。
7.1 Dense モデル
| モデル | 量子化 | ファイル | 実測VRAM | VRAM残り | tok/s |
|---|---|---|---|---|---|
| 0.8B | Q8_0 | 1.0 GB | 8,586 MiB | 89,301 | 333 |
| 0.8B | BF16 | 1.8 GB | 9,274 MiB | 88,613 | 309 |
| 2B | Q4_K_M | 1.9 GB | 9,468 MiB | 88,419 | 303 |
| 2B | Q8_0 | 2.7 GB | 10,222 MiB | 87,665 | 262 |
| 2B | BF16 | 4.6 GB | 11,948 MiB | 85,939 | 217 |
| 4B | Q4_K_M | 3.4 GB | 16,860 MiB | 81,027 | 188 |
| 4B | Q8_0 | 5.3 GB | 18,656 MiB | 79,231 | 157 |
| 4B | BF16 | 9.3 GB | 22,512 MiB | 75,375 | 118 |
| 9B | Q4_K_M | 6.6 GB | 19,380 MiB | 78,507 | 148 |
| 9B | Q8_0 | 10 GB | 22,796 MiB | 75,091 | 115 |
| 9B | BF16 | 19 GB | 30,076 MiB | 67,811 | 78 |
| 27B | Q4_K_M | 17 GB | 41,634 MiB | 56,253 | 56 |
| 27B | Q8_0 | 29 GB | 52,972 MiB | 44,915 | 41 |
| 27B | BF16 | 55 GB | 76,212 MiB | 21,675 | 26 |
7.2 MoE モデル
| モデル | 量子化 | ファイル | 実測VRAM | VRAM残り | tok/s |
|---|---|---|---|---|---|
| 35B (A3B) | Q4_K_M | 23 GB | 33,354 MiB | 64,533 | 126 |
| 35B (A3B) | Q8_0 | 38 GB | 47,248 MiB | 50,639 | 116 |
| 35B (A3B) | BF16 | 71 GB | 78,510 MiB | 19,377 | 100 |
| 122B | Q4_K_M | 81 GB | 91,534 MiB | 6,353 | 79 |
| 122B-unc | Q4_K_M | 74 GB | 75,944 MiB | 21,943 | 81 |
7.3 この表の読み方
注目ポイント①: ファイルサイズとVRAMは一致しない
2B Q4_K_M はファイル 1.9GB なのに VRAM は 9,468 MiB。
4B Q4_K_M はファイル 3.4GB なのに VRAM は 16,860 MiB。
→ KVキャッシュとランタイムの分が上乗せされるため。Ollamaのデフォルトコンテキスト長が影響。
注目ポイント②: MoE 35B Q4_K_M は Dense 27B Q4_K_M より軽い
35B MoE Q4_K_M: 33,354 MiB / 126 tok/s
27B Dense Q4_K_M: 41,634 MiB / 56 tok/s
→ MoEは総パラメータは多いが、実行時に使う部分が少ないため軽量かつ高速。
注目ポイント③: 122B Q4_K_M は96GB GPUでギリギリ
VRAM残り 6,353 MiB。長文脈や並列を使うと溢れるリスクが高い。
⚠️ 実測結果は nvidia-smi の表示です。97,887 MiB を超えると CPU/RAM へのオフロードが始まり、速度が急激に低下します。
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 590.48.01 Driver Version: 590.48.01 CUDA Version: 13.1 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
|=========================================+========================+======================|
| 0 NVIDIA RTX PRO 6000 Blac... Off | 00000000:DF:00.0 Off | Off |
| 30% 53C P1 244W / 300W | 91534MiB / 97887MiB | 85% Default |
+-----------------------------------------+------------------------+----------------------+↑ 122B Q4_K_M ロード時。97,887MiB 中 91,534MiB 使用。余裕は約 6GB しかない。
8. 重み以外にVRAMを食うもの
8.1 KVキャッシュ — 最大の伏兵
KVキャッシュは、過去の文脈を保持するためのメモリです。
- 文脈長が増える → KVキャッシュが増える
- 同時リクエスト数が増える → その分だけ増える
- つまり 長文脈 × 並列 で急膨張する
8.2 コーディング用途ではKVキャッシュが本命
短いチャットなら重みが支配的ですが、コーディングエージェントでは：
- リポジトリ抜粋、直前のdiff、エラーログ、テスト結果、指示の履歴…
が積み重なり、KVキャッシュのほうが苦しくなる ことが多い。
💡 コーディング用途では「モデルが載るか」だけでなく、長い文脈を何本並列に持てるか が極めて重要。
9. コンテキスト長とKVキャッシュの関係
9.1 コンテキスト長はKVキャッシュの天井
- コンテキスト長 = 設定上の上限（例: 262,144 トークン）
- KVキャッシュ = その上限を支える実メモリ
9.2 長文脈と高並列はトレードオフ
文脈を長く取るほどKVキャッシュが重くなり、並列数を取りにくくなります。
9.3 コーディング用途で長文脈が効く場面
- 複数ファイルを一気に読ませる
- テストログと実装を同時に見せる
- 複数ターンの履歴を保つ
ただし、その代償はVRAMです。
10. 並列処理とVRAMの関係
10.1 重みは共有、文脈は人数分
同じモデルに複数リクエストが来たとき：
- 重みは1個分（共有される）
- KVキャッシュは人数分増える
10.2 だから量子化が効く
量子化で重みを軽くすると、その分だけ文脈・並列・キャッシュに使える余地が増えます。
量子化の価値は「モデルを載せる」だけでなく、余ったVRAMを運用の余裕に変えられる こと。
10.3 実務で起きること
例: 122B Q4_K_M がVRAM 91,534 MiB で載った。残り約 6GB。
ここで 32k 文脈 × 同時3人 × テストログ付きで使うと… KVキャッシュ側で溢れる リスクが高い。
11. VRAMとRAMを混同しない
11.1 GPUに全部載せる系と、一部RAMへ逃がせる系
バックエンドによっては、GPUに載りきらない分をCPU/RAMへ逃がして動かせます。
この場合：
- 技術的には起動する
- 返答も返る
- しかし体感はかなり遅い
⚠️ 「24GB GPUで122Bが動いた」という話があっても、それが 実用的な速度か、辛うじて返しただけか は分けて考える必要がある。
11.2 サーバ用途では「全部GPUに乗りきる」が強い
複数リクエストを捌くなら：
- GPUにきれいに載る
- KVキャッシュもGPUで回せる
- CPU/RAMへ逃がさない
この構成のほうが圧倒的に安定します。
12. 【実測】同じ質問でモデルサイズによる品質差を見る
ここが目玉です。Qwen3.5 の全モデルに 同じ質問 を投げて、回答品質の変化を実測しました。
検証環境: Ollama API / think: false / num_predict: 512
12.1 テスト問題 — バグ発見（複数条件保持力）
以下のPython関数には 3つのバグ があります：
def safe_divide_all(numbers, divisor):
"""numbersリストの各要素をdivisorで割った結果を返す。
divisorが0の場合はNoneを返す。空リストの場合は空リストを返す。"""
if divisor == 0:
return [] # ← バグ1: Noneを返すべき
results = []
for i in range(1, len(numbers)): # ← バグ2: 0からでなく1から
results.append(numbers[i] / divisor)
return results
# ← バグ3: 例外処理がない（型エラー等）正解: ① return [] → return None、② range(1, → range(0,、③ 例外処理の欠如
12.2 モデルサイズ別の回答比較
Dense モデル
🔴 0.8B（Q8_0）— 333 tok/s、632ms
バグ1: divisor が0 として割り当てた場合、リストの元素が無限大になり、空リストとして誤りを出します。
バグ2: 空リストのリストの元素（1 行で）の処理として、空リストは 1 行で空リストを返すよう定義しています。
バグ3: divisor が 0 となってもリストの長さの計算式を利用し、空リストに返すべきではありません。
→ 3つとも的外れ。問題文を理解できていない。速いが役に立たない。
🔴 0.8B（BF16）— 309 tok/s、697ms
→ Q8_0版と同様に的外れ。量子化をBF16にしても0.8Bの地力では回答品質は改善しない。
🟠 2B（Q4_K_M）— 303 tok/s、475ms
バグ1: 除数（divisor）が0の場合、仕様（Noneを返す）とコード（空リストを返す）が矛盾している。
バグ2: ループの初期値が1になっているため、リストの第0要素が除算の対象外になっている。
バグ3: ループがrange(len(numbers))を使用しているため、索引がlen-1になる際にIndexErrorが発生する可能性がある。
→ バグ1, 2を正確に指摘。バグ3は的外れだがコードを読む力は出てきた。
🟠 2B（Q8_0）— 262 tok/s、721ms
→ Q4_K_M版と同等品質。バグ1, 2を指摘。品詞が中国語（「专有名词」「缩写」）で返る謎現象あり。
🟠 2B（BF16）— 217 tok/s、2,776ms
→ バグ1, 2を指摘。逆さ読みが「tnoybPy」「能知人古」と誤り — BF16でも2Bの文字操作力は弱い。
🟡 4B（Q4_K_M）— 188 tok/s、796ms
バグ1: 除数（divisor）が0の場合、仕様（Noneを返す）とコード（空リストを返す）が矛盾している。
バグ2: ループの初期値が1になっているため、リストの第0要素（最初の数）が除算の対象外になっている。
バグ3: ループがrange(len(numbers))を使用しているため、索引がlen-1になる際にIndexErrorが発生する可能性がある。
→ バグ1, 2を簡潔に指摘。バグ3は誤りだが、指摘の文体が安定してきた。
🟡 4B（Q8_0）— 157 tok/s、3,710ms
バグ1: ループの初期値が
1であるため、numbersリストの最初の要素（索引 0）を処理しない。
バグ2:divisorが0の場合、文書に書かれた「Noneを返す」代わりに空リスト[]を返している。
→ バグ1, 2は正確。512トークン使い切り — 冗長な自己反省が目立つ。
🟡 4B（BF16）— 118 tok/s、1,094ms
バグ1:
divisor == 0の場合、仕様通り None を返すべきであるが実際には空リスト[]を返している。
バグ2: ループの初期値が1であり、リストの最初の要素（インデックス0）を計算していない。
バグ3:divisorが 0 でない場合、除算エラー (ZeroDivisionError) になる可能性があるがチェックされていない。
→ バグ1, 2を正確かつ簡潔に指摘。BF16の精度向上が4Bサイズで見え始める。
🟢 9B（Q4_K_M）— 148 tok/s、1,172ms
バグ 1:
divisorが 0 かつnumbersが空リストのどちらでもNoneを返すべきですが、0 なら何であっても[]を返してしまいます。
バグ 2: リストの長さ 1 より大きい要素のみを処理するため、最初の要素（インデックス 0）が計算から除外されてしまいます。
バグ 3: 整数除算ではなく浮動小数点除算/を使用しているため、整数の結果も小数点付きで返ってしまい期待値と異なる場合があります。
→ バグ1, 2を正確に指摘。バグ3は「/と//の違い」を指摘する独自解釈。
🟢 9B（Q8_0）— 115 tok/s、1,333ms
→ バグ1の解釈がやや混乱（「条件のロジックが逆」）。バグ2は正確。バグ3でdocstringの問題を指摘（誤り）。
🟢 9B（BF16）— 78 tok/s、1,397ms
バグ 1:
divisorが 0 の場合はNoneを返すべきであるが、空リストが返されている。
バグ 2: 配列の先頭要素（index 0）がスキップされ、計算に含められていない。
バグ 3: 整数を割った際に除算零例外が発生する可能性がある場合、エラー処理がなされていない。
→ 3つとも的確で簡潔。BF16の精度が9Bサイズで効いている。
🟢 27B（Q4_K_M）— 56 tok/s、2,250ms
バグ1: divisorが0の場合はNoneを返すべきなのに空リストを返している。
バグ2: 最初の要素（インデックス0）をスキップして計算を行っている。
→ バグ1, 2を最も簡潔に指摘。27B以上は無駄がない。
🟢 27B（Q8_0）— 41 tok/s、2,205ms
→ Q4_K_M版と同等品質。JSON出力も完璧。
🟢 27B（BF16）— 26 tok/s、4,034ms
→ 品質は同等だが速度が半分以下。コーディング用途では辛い。
MoE モデル
🔵 35B MoE（Q4_K_M）— 126 tok/s、4,580ms
→ バグ1, 2を正確に指摘。512トークン使い切りで冗長な補足が多い。
🔵 35B MoE（Q8_0）— 116 tok/s、4,921ms
→ 同上。512トークン使い切り。品質は高いが出力制御が弱い。
🔵 35B MoE（BF16）— 100 tok/s、1,243ms
バグ1: 0除算時のリターン値が「None」ではなく空リスト「[]」になっている。
バグ2: 配列の先頭要素（添字0）をループ処理の対象から除外している。
バグ3: 空リストを渡した場合の処理が明示的に記述されておらず…
→ BF16で最も簡潔かつ的確。出力長も87トークンと無駄がない。速度も100超えなので良好。
🔵 122B（Q4_K_M）— 79 tok/s、1,779ms
バグ 1: divisor が 0 の場合にエラーを防ぐために
Noneを返すべきだが、空リスト[]を返している。
バグ 2:range(1, len(numbers))として最初の要素（インデックス 0）をスキップして処理している。
バグ 3: 除算でZeroDivisionErrorが発生するリスクがあるため、divisor が 0 のチェック以外に例外処理（try-except）が必要です。
→ 3つとも正確かつ簡潔。バグ3も実務的に妥当な指摘。最高品質。
🔵 122B-uncensored（Q4_K_M）— 81 tok/s、6,924ms
→ 品質は122Bと同等だが、512トークン使い切りで冗長。uncensored版は出力制御がやや弱い。
12.3 バグ発見テストのまとめ
| モデル | 量子化 | バグ1 | バグ2 | バグ3 | 総合 |
|---|---|---|---|---|---|
| 0.8B | Q8_0 | ❌ | ❌ | ❌ | 問題を理解できていない |
| 0.8B | BF16 | ❌ | ❌ | ❌ | BF16でも地力不足 |
| 2B | Q4_K_M | ✅ | ✅ | ❌ | 核心は捉えた |
| 2B | Q8_0 | ✅ | ✅ | ❌ | Q4と同等 |
| 2B | BF16 | ✅ | ✅ | ❌ | BF16でも改善なし |
| 4B | Q4_K_M | ✅ | ✅ | △ | 指摘が安定 |
| 4B | Q8_0 | ✅ | ✅ | △ | 冗長だが正確 |
| 4B | BF16 | ✅ | ✅ | △ | 簡潔さが向上 |
| 9B | Q4_K_M | ✅ | ✅ | △ | 独自解釈あるが方向性は正 |
| 9B | Q8_0 | ✅ | ✅ | ❌ | バグ3でdocstring誤指摘 |
| 9B | BF16 | ✅ | ✅ | ✅ | BF16の精度が効く |
| 27B | Q4_K_M | ✅ | ✅ | ❌ | 最も簡潔 |
| 27B | Q8_0 | ✅ | ✅ | ❌ | Q4と同等 |
| 27B | BF16 | ✅ | ✅ | ❌ | 遅いが品質は同じ |
| 35B MoE | Q4_K_M | ✅ | ✅ | △ | 冗長だが正確 |
| 35B MoE | Q8_0 | ✅ | ✅ | △ | 同上 |
| 35B MoE | BF16 | ✅ | ✅ | △ | 簡潔で的確 |
| 122B | Q4_K_M | ✅ | ✅ | ✅ | 全問正解・最高品質 |
| 122B-unc | Q4_K_M | ✅ | ✅ | △ | バグ1,2は正確だがバグ3で冗長な自問自答 |
💡 実測で見えた法則:
- 0.8B→2B: 問題理解の壁。2B以上でバグ1,2が見える
- 4B→9B: 安定性の壁。指摘の文体が安定する
- 9B→27B: 簡潔さの壁。無駄が消える
- 27B→122B: バグ3（例外処理の欠如）まで見抜けるのは122Bだけ
- 量子化の影響: 9B BF16 > 9B Q8_0 のように、同じB数でもBF16で品質が上がるケースがある
12.4 テスト問題 — JSON フォーマット遵守（指示遵守力テスト）
「Python, 人工知能, AI の品詞・文字数・逆さ読みをJSON形式で」と指示。
| モデル | 量子化 | JSON形式 | 文字数 | 逆さ読み | 品詞 | 総合 |
|---|---|---|---|---|---|---|
| 0.8B | Q8_0 | △ コードブロック付 | ❌ 5,1 | ❌ 意味不明 | △ 英語 | ❌ |
| 0.8B | BF16 | ✅ | ❌ “4” | ❌ “Nan” | △ 英語 | ❌ |
| 2B | Q4_K_M | ✅ | ✅ | ✅ | ✅ | ✅ |
| 2B | Q8_0 | ✅ | ✅ | △ | ❌ 中国語 | △ |
| 2B | BF16 | ✅ | ✅ | ❌ | △ 略語 | △ |
| 4B | Q4_K_M | ✅ | ✅ | ✅ | ✅ | ✅ |
| 4B〜122B | 全量子化 | ✅ | ✅ | ✅ | ✅ | ✅ |
💡 JSON遵守は4B以上で安定。2Bは量子化によって品詞が中国語になったり逆さ読みが壊れる。
0.8Bは文字の数え間違い（Python=5文字、AI=1文字）が頻発し、基本的な処理能力が不足している。
13. 【実測】推論速度の比較
同一GPU（RTX PRO 6000）での tok/s を量子化別に比較します。
Ollama内部計測値（eval_duration）を使用しており、外部干渉の影響を受けません。
13.1 Dense モデル — 量子化 vs 速度
| パラメータ | Q4_K_M | Q8_0 | BF16 |
|---|---|---|---|
| 0.8B | — | 333 tok/s | 309 tok/s |
| 2B | 303 tok/s | 262 tok/s | 217 tok/s |
| 4B | 188 tok/s | 157 tok/s | 118 tok/s |
| 9B | 148 tok/s | 115 tok/s | 78 tok/s |
| 27B | 56 tok/s | 41 tok/s | 26 tok/s |
13.2 MoE モデル — 量子化 vs 速度
| パラメータ | Q4_K_M | Q8_0 | BF16 |
|---|---|---|---|
| 35B (A3B) | 126 tok/s | 116 tok/s | 100 tok/s |
| 122B | 79 tok/s | — | — |
13.3 速度の体感速度
- 100 tok/s 以上: 体感サクサク。チャット・コーディングどちらも快適
- 50〜100 tok/s: 実用的。少し待つがストレスは少ない。長考すると長く感じる。
- 25〜50 tok/s: 長文生成はやや辛い。短い応答なら問題なし。
- 25 tok/s 以下: エージェント反復には厳しい。短い応答なら問題ないが、Thinkingモデルだとしんどい
💡 MoE 35B Q4_K_M（126 tok/s）は Dense 9B Q4_K_M（148 tok/s）に近い速度 で、しかも地力は上。MoEの効率の良さが光る。
14. GPU容量別のざっくり現実感
以下はすべて Qwen3.5 シリーズを Ollama デフォルト設定で実測した VRAM 値に基づく。num_ctx（コンテキスト長）を短くすれば VRAM は減るが、ここでは デフォルト設定の現実 を示す。
14.1 16GB 級（RTX 5060 Ti 等）— コスパ人気モデル。
| 候補 | ファイル | 実測VRAM | 判定 |
|---|---|---|---|
| 0.8B Q8_0 | 1.0GB | 8.6GB | ✅ 余裕あるが品質は実用外 |
| 2B Q4_K_M | 1.9GB | 9.5GB | ✅ 現実的な上限 |
| 4B Q4_K_M | 3.4GB | 16.9GB | ⚠️ num_ctx を削ればギリギリ |
| 9B Q4_K_M | 6.6GB | 19.4GB | ❌ 無理んご |
14.2 24GB 級（RTX 4090 等）
| 候補 | ファイル | 実測VRAM | 判定 |
|---|---|---|---|
| 4B Q4_K_M | 3.4GB | 16.9GB | ✅ 余裕あり |
| 4B Q8_0 | 5.3GB | 18.7GB | ✅ 品質重視でもOK |
| 9B Q4_K_M | 6.6GB | 19.4GB | ✅ おすすめ |
| 9B Q8_0 | 10GB | 22.8GB | ⚠️ ギリギリ |
| 27B Q4_K_M | 17GB | 41.6GB | ❌ 載らない |
⚠️ ファイル17GBの27Bが載りそうに見えるが、KVキャッシュ込みで実測41GBになるので注意。
14.3 32GB 級（RTX 5090 等）— 個人環境の最高峰
| 候補 | ファイル | 実測VRAM | 判定 |
|---|---|---|---|
| 9B Q4_K_M | 6.6GB | 19.4GB | ✅ 最もバランス良い。12GB余る |
| 9B Q8_0 | 10GB | 22.8GB | ✅ 品質重視で選べる |
| 9B BF16 | 19GB | 30.1GB | ⚠️ ギリギリ |
| 27B Q4_K_M | 17GB | 41.6GB | ❌ 載らない |
| 35B MoE Q4_K_M | 23GB | 33.4GB | ❌ ギリ載らない |
個人環境の限界。9B Q4_K_M〜Q8_0 が最適解。27B以上はクラウドAPIへ。
14.4 48GB 級（RTX A6000, RTX 6000 Ada 等）
| 候補 | ファイル | 実測VRAM | 判定 |
|---|---|---|---|
| 9B BF16 | 19GB | 30.1GB | ✅ 余裕あり |
| 27B Q4_K_M | 17GB | 41.6GB | ✅ ようやく載る |
| 35B MoE Q4_K_M | 23GB | 33.4GB | ✅ 快適。MoEの真価を発揮 |
| 35B MoE Q8_0 | 38GB | 47.2GB | ⚠️ ギリギリ |
| 27B Q8_0 | 29GB | 53.0GB | ❌ 載らない |
14.5 80GB 級（A100, H100 等）
| 候補 | ファイル | 実測VRAM | 判定 |
|---|---|---|---|
| 27B Q8_0 | 29GB | 53.0GB | ✅ 余裕あり |
| 27B BF16 | 55GB | 76.2GB | ✅ 品質最優先なら |
| 35B MoE BF16 | 71GB | 78.5GB | ⚠️ ギリギリ |
| 122B Q4_K_M | 81GB | 91.5GB | ❌ 載らない |
14.6 96GB 級（RTX PRO 6000 等）— 本検証環境
| 候補 | ファイル | 実測VRAM | 判定 |
|---|---|---|---|
| 35B MoE BF16 | 71GB | 78.5GB | ✅ 余裕あり、速度品質共に現実的 |
| 122B Q4_K_M | 81GB | 91.5GB | ⚠️ 載るが残り6GB。長文脈は厳しい |
14.7 Mac（Apple Silicon）— 載るけど遅い
Apple Silicon はCPUとGPUが ユニファイドメモリ を共有するため、いわゆるメインメモリ容量がそのままVRAMとして使える。
LLM推論は メモリ帯域幅がボトルネック になるため、帯域幅の差が速度差に直結する。
| Mac構成 | メモリ | 帯域幅 | 載せられるモデル例 |
|---|---|---|---|
| M5 MacBook Air | 16〜24GB | 〜150 GB/s | 9B Q4_K_M まで |
| M5 Pro Mac mini | 24〜48GB | 〜300 GB/s | 35B MoE Q4_K_M が快適 |
| M5 Max MacBook Pro | 36〜128GB | 〜550 GB/s | 122B Q4_K_M も載る |
| M3 Ultra Mac Studio | 192〜512GB | 819 GB/s | 122B BF16 も余裕で載る |
| M5 Ultra Mac Studio（予定） | 〜512GB? | 未発表 | 2026年中頃に登場予定との噂 |
Macの強み: メモリ容量
- M3 Ultra Mac Studio は最大 512GB。NVIDIA最上位の H100 (80GB) の 6倍以上
- 個人で購入可能な範囲で最大のメモリ容量を確保できる
- Qwen3.5 397B-A17B（MoE、総パラメータ397B / 実効17B）すら載る。
※だだし速度は実用に耐えない。1~5tok/s程度との情報も。
| 397B の量子化 | 推定VRAM | 512GB Mac |
|---|---|---|
| IQ2_XXS（2bit） | 〜120GB | ✅ 余裕。KVキャッシュも十分 |
| Q4_K_M（4bit） | 〜240GB | ✅ 載る。まだ半分余る |
| Q8_0（8bit） | 〜400GB | ⚠️ ギリギリ |
Macの弱み: 推論速度（帯域幅とコア性能の差）
| 環境 | メモリ帯域幅 | 9B Q4_K_M 参考速度 |
|---|---|---|
| M5 Max | 〜550 GB/s | 約 40〜60 tok/s |
| M3 Ultra | 819 GB/s | 約 60〜80 tok/s |
| RTX PRO 6000 | 1,792 GB/s | 148 tok/s（実測） |
- 最速の M3 Ultra でも NVIDIA の半分以下。「載るけど遅い」が基本
- エージェント反復（何十回もLLMを呼ぶ用途）には厳しい
💡 Mac の使いどころ: 大型モデルを「とりあえず試す」「品質を確認する」「出先でも動かしたい」用途には最適。
速度を求める本番運用には NVIDIA GPU が圧倒的に有利。
14.8 NVIDIA DGX Spark（128GB）— 個人向けAIスパコン
2025年発表の Grace Blackwell Superchip 搭載デスクトップ。約15cm角、1.2kgの小型筐体。
| 項目 | スペック |
|---|---|
| メモリ | 128GB ユニファイドメモリ（LPDDR5x） |
| 帯域幅 | 273 GB/s |
| AI性能 | 1 PFLOPS（FP4） |
| 対応モデル | 最大200Bパラメータ（単体）/ 405B（2台クラスタ） |
Mac との比較
- メモリ容量は M4 Max (128GB) と同等だが、Blackwell GPU のAI演算性能は Metal より圧倒的に高い
- ただし帯域幅 273 GB/s は RTX PRO 6000 (1,792 GB/s) の約 1/7。NVIDIA ディスクリートGPUほどは速くない
ポジション: Mac と NVIDIA GPU の中間
- Mac: メモリ大 × 速度遅い（帯域幅 200〜400 GB/s）
- DGX Spark: メモリ大 × 速度中（帯域幅 273 GB/s + Blackwell演算）
- NVIDIA GPU: メモリ制約あり × 速度速い（帯域幅 1,000〜3,000 GB/s）
💡 DGX Spark は「大型モデルを個人環境でそこそこの速度で動かす」唯一の選択肢。
ただし価格（約$3,000〜）と入手性を考えると、RTX 5090 + クラウドAPIの併用のほうが現実的なケースも多い。
⚠️ どれだけVRAMが増えても、余ったぶんを全部モデルサイズにつぎ込むと、また同じ問題が起きる
15. コーディング用途ではどこに差が出るか
15.1 単発コード生成
「この関数を書いて」「このSQLを修正して」程度なら、小さいモデルでもそこそこ戦える。
| 用途例 | 推奨モデル | 理由 |
|---|---|---|
| 関数1つの生成 | 4B Q4_K_M 以上 | 構文は正確。ロジックも概ね正しい |
| 正規表現・ワンライナー | 2B Q4_K_M でもOK | パターンマッチ程度なら小型で十分 |
| README/docstring 生成 | 9B Q4_K_M 以上 | 文脈に沿った自然な文章が必要 |
15.2 複数ファイル改修
API修正 → SDK修正 → テスト修正 → docs修正をまとめて見る必要がある場合、パラメータ数の大きさが効く。
| 用途例 | 推奨モデル | 理由 |
|---|---|---|
| 1ファイル内のリファクタ | 9B Q4_K_M | 関数間の依存を把握できる |
| API + クライアント同時改修 | 27B Q4_K_M 以上 | 複数ファイルの整合性を保てる |
| DB スキーマ変更の影響調査 | 35B MoE Q4_K_M | 広い文脈を保持しつつ高速 |
| 大規模リファクタ（10ファイル超） | 122B Q4_K_M | 変更の波及を正しく追える |
15.3 エージェント・AIコーディングアシスタント
Claude Code、Cursor、Cline 等のAIコーディングツールでローカルLLMを使う場合、ここで差が最も出る。
重要な指標:
- 前の修正意図を保てるか（文脈保持力）
- テスト失敗を正しく理解できるか（エラー解析力）
- 何回で収束するか（修正の収束性）
| ツール用途 | 推奨モデル | 注意点 |
|---|---|---|
| Copilot的な補完 | 4B〜9B Q4_K_M | 速度重視。100 tok/s以上が快適 |
| チャットで相談 | 9B〜27B Q4_K_M | バランス型。品質と速度の両立 |
| エージェント自律実行 | 35B MoE 以上 | 反復が多いので速度＋品質の両方が必要 |
| コードレビュー・バグ発見 | 122B Q4_K_M | 本教科書12章の実測通り、大型ほど正確 |
💡 エージェント用途では「1回の品質」より「10回の反復速度」が重要。
122B で1回正解を出すより、35B MoE で3回試行するほうが速い場合も多い。
15.4 ただしVRAM不足は全部を台無しにする
どれほど賢いモデルでも、文脈が入らない・並列で落ちる・CPUへ逃げて遅いとなれば実務では使えない。
| 症状 | 原因 | 対策 |
|---|---|---|
| 途中で回答が切れる | KVキャッシュ不足 | モデルを小さくするか num_ctx を下げる |
| 2つ目のリクエストで激遅 | VRAMに余裕がない | 並列不要なら問題なし。必要なら小型モデルへ |
| 推論がCPUに逃げて1 tok/s | モデル全体がVRAMに載っていない | 量子化を強くするか、モデルサイズを下げる |
性能の最大値 よりも そのGPUで安定して回る性能 を見るほうが大切。
16. 失敗しにくいモデル選定手順
Step 1: 用途を決める
└→ 単発補完？エージェント？社内チャットサーバ？
Step 2: 必要な文脈長を決める
└→ 短いやり取り？repo断片やログを大量に入れる？
Step 3: 必要な並列数を決める
└→ 1人用？少人数共有？複数ユーザー同時？
Step 4: 残ったVRAMに載る最大モデルを選ぶ
└→ ここで初めて「何B」「何bit」を決める
Step 5: 量子化レベルを調整する
└→ 欲しい頭脳サイズ → 量子化で現実的なサイズに → 余裕を残す⚠️ 最初からbit数だけで考えると、実務では失敗しやすい
17. まとめ （3行で覚える）
① 必ず VRAM に乗りきるモデルを使え
② なるべく大きいパラメータのモデルを使え
③ 最後に量子化でVRAMに乗りきるよう調整しろ。ただしQ4以下はNG
💡 この順番が大事。①を無視して②だけ追うと、CPUオフロードで一気に激遅になる。
②を無視して③だけ追うと、品質が出ない。
用語集
| 用語 | 意味 |
|---|---|
| B (Billion) | 10億。7B = 70億パラメータ |
| Dense | 全パラメータを毎回使うモデル構造 |
| MoE | Mixture of Experts。一部の専門家だけ活性化する構造 |
| BF16/FP16 | 16ビット浮動小数点。高精度だが重い |
| Q8_0 | 8ビット量子化。精度と軽さのバランス |
| Q4_K_M | 4ビット量子化（改良版）。実用の主力 |
| KVキャッシュ | 過去の文脈を保持するためのメモリ領域 |
| tok/s | 1秒あたりの生成トークン数。推論速度の指標 |
| VRAM | GPU上のビデオメモリ。モデル実行に必要 |
| Ollama | ローカルLLM実行ツール。モデル管理とAPIを提供 |
| nvidia-smi | NVIDIA GPU の状態を確認するコマンド |
コメントを残す