GPUメモリは「重み＋会話の記憶（KVキャッシュ）＋余裕」で見積もれる：電卓で計算できる式を、公式資料で確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。計算例の数字は、設定ファイルの値から僕らが計算したものです。

先に結論

GPUのメモリ（VRAM、グラフィックス用のメモリ）に必要な量の目安は、次の式です。

必要な量 ≒ 重みの大きさ × 1.0〜1.2 ＋ KVキャッシュ × 同時に扱う会話の数

• 重みの大きさ：パラメータ数（重みの数）×1つあたりのバイト数。BF16やFP16なら2バイト、8ビットなら1バイト、4ビットなら0.5バイト前後です。
• KVキャッシュ：AIが会話の途中で保持する計算結果です。1トークンあたり「2×層数×KVヘッド数×ヘッド次元×1要素のバイト数」で決まります。
• 1.0〜1.2：実行中の一時的な領域の余裕です。根拠は後の節に書きます。

見立てです。「モデルが載るか」と「長い文脈や複数人で使えるか」は別の問題です。重みだけなら載っても、KVキャッシュで足りなくなることが、長い文脈や同時利用ではよく起きると思います。

前提：用語

• 重みは、モデルの中の巨大な数の表です。「80億パラメータ」は、その数が約80億個、という意味です。
• KVキャッシュは、すでに読んだ文章について計算した結果（KeyとValue）を取っておく領域です。毎回計算し直さずに済みますが、会話が長いほど、そして同時に扱う会話が多いほど、大きくなります。Hugging Faceの文書は、KVキャッシュを「前の計算を再利用できるように保存するもの」と説明しています。
• GQA（グループ化されたクエリ注意）は、KeyとValueを持つ頭（ヘッド）の数を、質問側の頭より減らして、KVキャッシュを小さくする設計です。論文（Ainslieら、2023年、arXiv:2305.13245）は、品質が通常方式に近く、速さが単純な方式に近いと報告しています。
• BF16は、1つの数を16ビット（2バイト）で表す形式です。多くのモデルが、この形式で配布されています。
• コンテキスト長は、1回の会話で扱うトークン（文字の断片）の数です。

式を一つずつ見る

1. 重み

重みの大きさは、パラメータ数×バイト数です。EleutherAIの解説は、int8が1バイト、fp16とbf16が2バイト、fp32が4バイトと書いています。

量子化したときのバイト数は、形式ごとに違います。llama.cppのREADMEが示すLlama-3.1-8Bでは、Q8_0が1重みあたり8.5008ビット、Q4_K_Mが4.8944ビットです（形式の詳細は「量子化の形式を比べる」の記事にあります）。この記事の計算例では、この2つの値を他のモデルにも流用しました。実際のファイルでは少し違うので、確実なのはファイルの大きさです。

2. KVキャッシュ

1トークンあたりの要素数は、2（KeyとValue）×層数×KVヘッド数×ヘッド次元です。これに、1要素のバイト数（BF16なら2）を掛けます。

必要な数字は、モデルのconfig.jsonにあります。今回読んだ3つのモデルの値です。

Llama 3の論文の表3では、70Bの層数が80、注意ヘッドが64、KV/ヘッドが8、モデルの次元が8,192です。ヘッド次元は8,192÷64で128になります（僕らの計算です）。

僕らの計算です。

GBは10の9乗バイトです。GiB（2の30乗バイト）では、約7%小さい数字になります。

GQAの効果も計算できます。Qwen3-8Bは、注意ヘッドが32、KVヘッドが8です。もしKVヘッドが32あれば、1トークンあたり576KiBで、実際の144KiBの4倍です（僕らの計算です）。

3. 余裕（上乗せ）

Hugging Faceのaccelerateの文書は、「推論では、最大で約20%の追加を見込める」とEleutherAIを引いて書いています。EleutherAIの解説は、推論時のメモリを「モデルのメモリ×1.2」程度とする経験則を示しています。ただし、accelerateの文書は、この計算機が測るのは「モデルを読み込むのに必要なメモリ」で、推論を実行するための量ではない、とも書いています。

つまり、1.2は重みへの上乗せの目安で、KVキャッシュは別に足す必要があります。

計算例：32,768トークンの会話を1つ扱う場合

僕らの計算です。重み×1.2＋KVキャッシュ（BF16）を「安全側」の列にしました。

見立てです。この表を見ると、4ビット相当にしても、70Bモデルは24GBのGPU1枚には載りません。32Bモデルは、4ビット相当で重みが約20GBなので、24GBのGPUでは、KVキャッシュの余地がほとんど残らないと思います。8Bモデルなら、4ビット相当で10GB前後に収まります。

def kv_bytes_per_token(layers, kv_heads, head_dim, bytes_per=2):
    return 2 * layers * kv_heads * head_dim * bytes_per

def need_gb(params, bits, layers, kv_heads, head_dim, ctx, users=1):
    w = params * bits / 8
    kv = kv_bytes_per_token(layers, kv_heads, head_dim) * ctx * users
    return (1.2 * w + kv) / 1e9

print(need_gb(8.19e9, 16, 36, 8, 128, 32768))  # 約24.5

実測との突き合わせ

Appleの機械学習研究の記事（2025年11月19日）の表に、Qwen3-8B（BF16）のメモリが17.46GBとあります。条件は、入力4,096トークン＋生成128トークンです。

僕らの計算です。重み16.38GBに、4,224トークン分のKV（約0.62GB）を足すと約17.0GBで、近い値です。ただし、記事の「Memory (GB)」が何を測ったものか（GBかGiBか、一時領域を含むか）は読んだ範囲で確認できていません。偶然の一致かもしれないので、傍証程度に見てください。

判断の基準

見立てです。

1. まず重みを計算する。載らなければ、より小さい量子化か、複数のGPUか、より小さいモデルへ。
2. 次に、使いたい最大の文脈長と同時利用者数で、KVキャッシュを足す。
3. 足りなければ、文脈長を短くする、同時数を減らす、KVキャッシュをFP8にする、GPUを増やす（vLLMの文書は、tensor_parallel_sizeでモデルを複数のGPUに分けられる、と案内しています）。
4. ぎりぎりに詰めず、余裕を残す。

よくあるつまずき

• 重みだけで計算して足りなくなる：長い文脈や同時利用でKVキャッシュが膨らみます。
• モデルの種類を見落とす：Hugging Faceの文書は、スライディングウィンドウ注意（見る範囲を区切る方式）を使うモデルでは、キャッシュが一定のサイズで増えなくなる、と書いています。上の式は、全部を見る標準の注意が前提です。
• MoE（専門家混合）モデルを「動く部分」だけで見積もる：Appleの記事の表では、30Bの4ビットのMoE（3B相当が動く）が17.31GBです。動く部分だけの3B相当の大きさではありません。全体の重みを載せる前提で見るのが無難です（見立てです）。
• GBとGiBを混ぜる：約7%の差が出ます。
• 1枚のGPUの「80GB」を全部使えると考える：vLLMの既定は0.92です。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。式は設定ファイルとHugging Faceの文書から組み立てた、僕らの計算です。
• 量子化後のビット数は、Llama-3.1-8Bの表の値を他のモデルに流用しました。実際は、ファイルの大きさを確認してください。
• 一時領域（活性化）の大きさは、バッチの大きさや実装で変わります。「1.2倍」は目安で、上限ではありません。
• Llama 3.1 70Bのパラメータ数は、Hugging Face上の複製のモデルの情報から取りました。公式配布の数と、わずかに違う可能性があります。
• 設定ファイルの値は、モデルのバージョンで変わります。使う前に、実際のconfig.jsonを確認してください。
• Qwen3-8Bの文脈長は、モデルカードでは標準32,768トークン、YaRNで131,072トークンです。上の表の131,072は、計算上の数字です。
• vLLMの既定値などは、バージョンによって変わります。この記事はmainブランチのソースを読みました。

出典

• Qwen3-8B config.json（Hugging Face、Qwen、2026年10月8日確認）
• Qwen3-8B モデルカード（Hugging Face、Qwen、2026年10月8日確認）
• Qwen3-32B config.json（Hugging Face、Qwen、2026年10月8日確認）
• Llama-3.1-70B（Hugging Face上の複製、unsloth、2026年10月8日確認）
• The Llama 3 Herd of Models（arXiv:2407.21783、Meta、2026年10月8日確認）
• GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints（arXiv:2305.13245、Ainslieら、2026年10月8日確認）
• Model memory estimator（Hugging Face Accelerate Docs、Hugging Face、2026年10月8日確認）
• KV cache strategies（Hugging Face Transformers Docs、Hugging Face、2026年10月8日確認）
• Transformer Math 101（EleutherAI、2026年10月8日確認）
• Engine Arguments（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• cache.py（vLLMのソースコード、vLLMプロジェクト、2026年10月8日確認）
• Conserving Memory（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• Quantized KV Cache（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
• llama-quantize README（llama.cpp、ggml-org、2026年10月8日確認）
• Exploring LLMs with MLX and the Neural Accelerators in the M5 GPU（Apple Machine Learning Research、Apple、2025年11月19日、2026年10月8日確認）

更新履歴

• 2026年10月25日 書き方を直しました。
  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した