アーキテクチャ対応 LLMメモリ & 帯域幅の算出メソドロジー
VRAMLabは固定倍率の概算ではなく第一原理のテンソル次元からLLM推論メモリをモデル化し、コストゼロの静的エッジ配信上で100%クライアントサイド実行します。
1. 重み量子化と実効ビット幅 (Effective bpw)
量子化フォーマットはパックされた整数重みに加えてブロック単位のスケール係数とゼロポイントを保持します。4bit GGUF の Q4_K_M はパラメータあたり平均 4.85 実効ビット（4.00ではない）、Q8_0 は平均 8.50 bpw を消費します。Mixture-of-Experts モデルではトークンごとのホストページングを防ぐため、ルーティング対象および共有エキスパートのすべてがメモリ上に常駐します。
| 精度 / 形式 | 実効 bpw | 32B Weights | 70B Weights | vLLM / Ollama / GGUF |
|---|---|---|---|---|
| FP16 / BF16 (16-bit Native) | 16.00 bpw | 61.09 GB | 131.50 GB | native · fp16 · F16 / BF16 |
| FP8 E4M3 (Hopper / Ada / Blackwell) | 8.50 bpw | 32.46 GB | 69.86 GB | fp8 · fp8 · FP8_E4M3 |
| INT8 SmoothQuant / bitsandbytes | 8.50 bpw | 32.46 GB | 69.86 GB | bitsandbytes · q8_0 · INT8 |
| GGUF Q8_0 (8.50 bpw) | 8.50 bpw | 32.46 GB | 69.86 GB | gguf · q8_0 · Q8_0 |
| GGUF Q6_K (6.56 bpw) | 6.56 bpw | 25.05 GB | 53.92 GB | gguf · q6_K · Q6_K |
| GGUF Q5_K_M (5.69 bpw) | 5.69 bpw | 21.73 GB | 46.77 GB | gguf · q5_K_M · Q5_K_M |
| GGUF Q4_K_M (4.85 bpw — Recommended) | 4.85 bpw | 18.52 GB | 39.86 GB | gguf · q4_K_M · Q4_K_M |
| AWQ / GPTQ INT4 (4.50 bpw) | 4.50 bpw | 17.18 GB | 36.99 GB | awq · q4_K_M · AWQ_4BIT |
| GGUF IQ4_XS (4.25 bpw Importance Matrix) | 4.25 bpw | 16.23 GB | 34.93 GB | gguf · iq4_XS · IQ4_XS |
| GGUF Q3_K_M (3.91 bpw) | 3.91 bpw | 14.93 GB | 32.14 GB | gguf · q3_K_M · Q3_K_M |
| GGUF Q2_K (3.35 bpw Extreme) | 3.35 bpw | 12.79 GB | 27.53 GB | gguf · q2_K · Q2_K |
2. アテンション別のKVキャッシュ数式（MHA・GQA・MLA・ハイブリッドSWA）
標準的な Grouped-Query Attention は全層で 2 × L × H_kv × d_head × S × B × bytes_kv を確保します。DeepSeek Multi-head Latent Attention (MLA) はKeyとValueを L × (d_kv_lora + d_qk_rope) × S × B × bytes_kv へ圧縮し、長文脈メモリを90%以上削減します。ハイブリッド・スライディングウィンドウはローカル層の消費を min(S, window_size) に抑えつつグローバル層のみ S に比例して拡張します。
- マルチヘッドアテンション (MHA) / グループ化クエリアテンション (GQA)
- 2 × L × H_kv × d_head × S × B × bytes_kv
- マルチヘッド潜在アテンション (MLA)
- L × (kv_lora_rank + qk_rope_dim) × S × B × bytes_kv
- ハイブリッド・スライディングウィンドウ (SWA)
- (L_global × S + L_local × min(S, W)) × 2 × H_kv × d_head × B × bytes_kv
- Mixture-of-Experts (MoE)
- Weights ∝ P_total · Decode tok/s ∝ BW / P_active
3. Apple Silicon 統合メモリ上限とデコード帯域幅の上界モデル
macOSのApple Silicon環境では、sysctl iogpu.wired_limit_mb で上書きしない限り既定のGPUワイヤード割当は物理統合RAMの約75%で頭打ちになります（OS安定性を保つ安全上限として最大88%までモデル化）。自己回帰デコード速度は実効外部メモリ帯域幅を1ステップあたりの有効パラメータ読出バイト数＋有効KVキャッシュ読出バイト数で割った上界で求まり、VRAMLabの12時間自動検証パイプラインにより継続検証されます。
| アクセラレータ / システム | 物理メモリ | Default Usable | Tuned Ceiling | メモリ帯域幅 |
|---|---|---|---|---|
| NVIDIA GeForce RTX 3090 (24 GB GDDR6X) | 24 GB | 22.1 GB (92%) | 23.0 GB (96%) | 936 GB/s |
| NVIDIA GeForce RTX 4090 (24 GB GDDR6X) | 24 GB | 22.1 GB (92%) | 23.0 GB (96%) | 1,008 GB/s |
| NVIDIA GeForce RTX 5090 (32 GB GDDR7) | 32 GB | 29.4 GB (92%) | 30.7 GB (96%) | 1,792 GB/s |
| Apple Silicon M-Series Max (64 GB Unified Memory) | 64 GB | 48.0 GB (75%) | 56.3 GB (88% sysctl) | 546 GB/s |
| Apple Mac Studio M4 Max (128 GB Unified Memory) | 128 GB | 96.0 GB (75%) | 112.6 GB (88% sysctl) | 546 GB/s |
| Apple Mac Studio M2/M3 Ultra (192 GB Unified Memory) | 192 GB | 144.0 GB (75%) | 169.0 GB (88% sysctl) | 800 GB/s |
| NVIDIA A100 SXM4 (80 GB HBM2e) | 80 GB | 73.6 GB (92%) | 76.8 GB (96%) | 2,039 GB/s |
| NVIDIA H100 SXM5 (80 GB HBM3) | 80 GB | 73.6 GB (92%) | 76.8 GB (96%) | 3,350 GB/s |
4. 連携する CodeAP Studio エンジニアリング・ワークベンチ
VRAMLab での容量設計とあわせて、DevToken の460以上の最新 LLM API 料金 & 429レート制限試算、LLMEOL の7大エコシステム廃止予定トラッキング、ToMarkdown の PDF/DOCX/HTML から Markdown へのトークン圧縮もご活用ください。
よくある質問
DeepSeek MLAは標準的なGQAと比べてどのようにKVキャッシュVRAMを削減しますか？
Multi-head Latent Attentionは、各層で 2 × H_kv × head_dim テンソルを保持する代わりに、KeyとValueを共有の低ランク潜在ベクトル（kv_lora_rank = 512 + qk_rope_head_dim = 64 など）へ射影します。これにより非圧縮MHA比で長文脈KVキャッシュメモリを90%以上削減します。
Mixture-of-Experts (MoE) モデルは大量のVRAMを要するのにデコードが速いのはなぜですか？
PCIeやSSDへのスラッシングを防ぐため全ルーティング対象エキスパートをGPUまたは統合メモリに常駐させる必要があり、VRAM容量は総パラメータ数（例：Qwen3-235B-A22Bなら235B）に比例します。一方、デコードのtok/sはトークンごとの有効パラメータ（22B）のメモリ帯域幅に律速されるため、メモリに収まれば32B密モデル並みの速度が出ます。
Apple SiliconのmacOSで統合RAMを100%使い切る前にOOMが発生するのはなぜですか？
macOSはカーネルおよびデスクトップ描画用に iogpu.wired_limit_mb で統合メモリを確保しているためです（初期値は物理RAMの約75%）。RAMの75%〜88%を使用するモデルでは、Ollamaやllama.cppの起動前に sysctl で iogpu.wired_limit_mb を引き上げる必要があります。
VRAMLabのアーキテクチャ寸法データはどこから取得していますか？
12時間周期の自動アーキテクチャ検証パイプラインが公式オープンウェイトリリースのTransformer設定数値を検証し、静的HTMLへ事前コンパイルしています。実行時の外部API通信やユーザーテレメトリは一切不要です。