LLMハードウェア要件の算出方法
これらのページの数値はすべて、以下の計算式から導いています — 隠れたマジックも、スペック表の寄せ集めもありません。あくまで近似値であり、その限界もあわせて説明します。
量子化別のダウンロードサイズ
size_GB = params_B × bits_per_weight ÷ 8モデルのファイルサイズは「パラメータ数 × ビット/重み ÷ 8」です。ビット/重みの値にはGGUFフォーマットのオーバーヘッドを含みます — 例えばQ4_K_Mは実効4.85ビットなので、8Bモデルは8 × 4.85 ÷ 8 ≈ 4.9 GBです。実際のGGUFビルドは数%前後します。
最小システムRAM
min_RAM = size_GB × 1.25 + 1.5 → next standard tierQ4_K_Mのメモリ上のサイズに、25%のランタイムオーバーヘッド（アクティベーション、バッファ）とOS用の1.5 GBを加え、次の標準メモリ容量（8、12、16、24、32 GBなど）に切り上げます。この切り上げ後の値が、各表に表示される「必要RAM」です。
コンテキスト長別のKVキャッシュ
kv_bytes/token ≈ 131 072 × (params_B ÷ 8)^0.45KVキャッシュはコンテキスト長に比例して増えます。基準はgrouped-query attentionを使うLlama 3.1 8B — 32レイヤー × 8 KVヘッド × ヘッド次元128 × 2（KとV）× 2バイト ≈ 1トークンあたり約131 kB — とし、深さとKV幅は総パラメータ数より緩やかに増えるため、パラメータ数に対してべき乗0.45でスケールさせています。4Kコンテキストで収まるモデルが32Kではメモリ不足になるのはこのためです。
速度（tok/s）の推定
tok/s ≈ bandwidth_GBs × 0.85 ÷ active_size_GBトークン生成はメモリ帯域幅に律速されます：1トークンの生成には、アクティブな重み全体を1回読み込む必要があるためです。そのため tok/s ≈ 帯域幅 × 0.85 ÷ Q4でのモデルサイズ となります（0.85は素のコピーベンチマークに対する経験的な効率係数）。Mixture-of-Experts（MoE）モデルではアクティブなパラメータだけが計算に入ります — 30BのMoEが密な8Bより速いことがあるのはこのためです。
ブラウザ内帯域幅ベンチマーク
オプションのベンチマークは、大きなWebGPUバッファ間コピーを繰り返してGPUの実効メモリ帯域幅を計測します。所要時間は約1〜2秒。すべてブラウザ内で完結し、アップロードも保存も一切ありません。Apple Siliconでは、計測した帯域幅をもとにチップクラスの推定（無印 / Pro / Max / Ultra）も補正します。
既知の限界
これらは計画用の推定値であり、お使いのマシンそのものを計測したベンチマークではありません。実際の速度はランタイム（llama.cpp、MLX、vLLM）、コンテキスト長、バッチサイズ、発熱状況によって変わります。動作判定は推奨のQ4_K_Mビルドと、ほぼアイドル状態のマシンを前提としています — ギリギリのモデルでは、アプリを閉じるか量子化を1段階下げる必要があると考えてください。
実効ビット/重み
| 量子化 | ビット/重み | 品質 |
|---|---|---|
| Q2_K | 3.35 | 劣化が目立つ |
| Q4_K_M | 4.85 | 推奨 |
| Q5_K_M | 5.65 | 高品質 |
| Q8_0 | 8.5 | ほぼ原品質 |
| F16 | 16 | オリジナル |
サイズはパラメータ数×ビット/重みからの推定値です。実際のGGUFビルドとは多少異なります。 · データ更新日: 2026-06-11