モデルの大きさから必要メモリを見積もる:パラメータ数と量子化の掛け算

基本式:重みのサイズはパラメータ数×ビット数

Hugging FaceのTransformersの最適化ガイドは、Xビリオンのパラメータを持つモデルの重みを読み込むには、float32でおよそ4×X GB、bfloat16/float16でおよそ2×X GBのVRAMが必要という目安を示しています。1パラメータが4バイトか2バイトかという話です。これを一般化したのが次の式です。

重み(GB) ≒ パラメータ数(B) × ビット数 ÷ 8

「7B」は70億パラメータの意味で、名前の数字は丸められています。正確な数は配布ページで確認してください。

量子化の「ビット数」は名目より少し大きい

GGUF形式の量子化名(Q4_K、Q6_Kなど)は、ブロックごとのスケール情報を含むため、実効ビット数が名前の数字より大きくなります。Hugging FaceのGGUFのドキュメントには、種類ごとのbits-per-weightが載っています。

• F16 / BF16、計算に使うビット数：16、根拠：16ビット浮動小数点
• 8ビット系(Q8_0など)、計算に使うビット数：8.5、根拠：編集上の仮置き(下記注)
• Q6_K、計算に使うビット数：6.5625、根拠：GGUF文書の記載
• Q5_K、計算に使うビット数：5.5、根拠：同上
• Q4_K、計算に使うビット数：4.5、根拠：同上
• Q3_K、計算に使うビット数：3.4375、根拠：同上
• Q2_K、計算に使うビット数：2.625、根拠：同上

8ビット系は、上記ドキュメントに実効ビット数の記載が見当たらなかったため、スケール分を見込んで8.5と置いた私の仮定です。実ファイルは層ごとに量子化の種類が混在することがあるので、式の結果は目安です。最終的には、Hugging Faceのファイル一覧に表示される実際のファイルサイズが優先です。

規模別の重みサイズ早見表

上の式で計算した重みだけのサイズです(1GB=10億バイトで計算)。

• 7B、F16：14.0GB、8ビット系(8.5)：7.4GB、Q4_K(4.5)：3.9GB
• 14B、F16：28.0GB、8ビット系(8.5)：14.9GB、Q4_K(4.5)：7.9GB
• 32B、F16：64.0GB、8ビット系(8.5)：34.0GB、Q4_K(4.5)：18.0GB
• 70B、F16：140GB、8ビット系(8.5)：74.4GB、Q4_K(4.5)：39.4GB

70BはF16の重みだけで約140GB、Q4_Kでも約40GBです。これにKVキャッシュと余裕分が加わるため、GPU1枚で動かすなら、その合計を収められるVRAMが必要です。収まらない場合は、大容量のユニファイドメモリを使う構成や、CPU側のメモリへの一部配置、複数GPUへの分散などを検討します。

なお、Mixture-of-Experts型のモデルを使う場合は、名前の数字だけで計算せず、使用する重みファイルの合計サイズを重みの目安にしてください。

重みの次に効く:KVキャッシュ

会話が長くなるほど、過去のトークンのキーとバリューを覚えておくKVキャッシュが増えます。Transformersのガイドでは、あるモデルで16,000トークンを保持すると、float16でおよそ15GBになり、重みの約半分に相当すると説明されています。同じガイドによれば、MQAやGQAという設計のモデルは、キーとバリューの組の数を減らしてこのサイズを抑えています。

概算式は、ガイドの数え方とMQA/GQAの説明から、実際に保持するKVヘッド数を使って導いたものです。並列1で、全層のKVヘッド数とヘッド次元が同じで、各層が全トークンのKとVを同じ精度で保持する場合を想定します。キャッシュの解説にある固定長・スライディングウィンドウ型などでは、実際の確保量と異なる場合があります。

KV(バイト) ≒ 2 × トークン数 × 層数 × KVヘッド数 × ヘッド次元 × 1値のバイト数

層数、KVヘッド数、ヘッド次元は、モデル配布ページのconfig.jsonで確認できます(項目名はモデルによって異なります)。見積もりでは、トークン数に生成分を含む予定のコンテキスト長を使い、式の結果を10億で割ってGBに直します。

説明用の例(実在のモデルではありません): 32層、KVヘッド8、ヘッド次元128、8,192トークン、f16(2バイト)なら、2×8192×32×8×128×2 ≒ 1.07GBです。

Ollamaで効く設定

Ollamaのコンテキスト長のドキュメントによると、既定のコンテキスト長はVRAM量に応じて決まり、大きくするほど必要メモリが増えます。確認にはollama psが使え、コンテキスト長とGPU/CPUの割り当てが表示されます。既定値は版で変わりうるので、手元で見てください。

OllamaのFAQには、次の記述があります。

• 同時リクエスト数(OLLAMA_NUM_PARALLEL)を増やすと、その分コンテキストが増える。
• KVキャッシュは既定でf16で、Flash Attentionが有効な場合にOLLAMA_KV_CACHE_TYPEで量子化できる。q8_0で約半分、q4_0で約4分の1になるが、応答品質に影響する場合がある。

つまり、同時に複数人が使うサーバー用途では、KVの見積もりに並列数を掛ける必要があります。

見積もり表:記入して合計する

次の表の空欄を埋めてください。「余裕」は公式の数値ではなく、私の提案する仮置きで、重みの10%+1GBとします。ランタイムの作業領域や他のアプリの分を見込むもので、実測で置き換える前提です。

• ① 重み、計算：パラメータ数(B)×ビット数÷8、自分の値：GB
• ② KVキャッシュ、計算：上のKV式(並列数があれば掛ける)、自分の値：GB
• ③ 余裕、計算：①×0.1+1、自分の値：GB
• 合計、計算：①+②+③、自分の値：GB
• 使えるメモリ、計算：GPUのVRAM、またはOSなどを引いた空き、自分の値：GB

記入例(説明用の仮の数字): 14BをQ4_Kで、8,192トークン、並列1で動かす場合です。層48、KVヘッド8、ヘッド次元128と仮定します。

• ① 重み、値：14×4.5÷8 ≒ 7.9GB
• ② KV(f16)、値：2×8192×48×8×128×2 ≒ 1.6GB
• ③ 余裕、値：7.9×0.1+1 ≒ 1.8GB
• 合計、値：約11.3GB

16GBのVRAMなら載りそうだ、という判断になります。

合計値の読み方と、実機での確認

合計と使えるメモリを比べるときの、私の目安です。

• 80%以下、判断：見積もり上は余裕がある。実際に読み込んで確かめる
• 80〜100%、判断：境界。量子化を一段下げるか、コンテキストを短くする
• 100%超、判断：この見積もりでは収まらない。小さいモデルか低ビットに変える

見積もりが外れる主な原因は、モデルごとの層構成の違いと、アプリ側の確保量です。最後は実際に読み込んで確かめます。Ollamaならollama psでGPU/CPUの割り当てを見ます。CPU/GPUの両方が表示されれば、重みはCPU側とGPU側に分かれて読み込まれています。

AIに計算を任せるときの依頼文

計算自体は電卓でできますが、config.jsonの読み取りと表の記入はAIに頼めます。次の形で、機密を含まない情報だけを渡してください。

次のモデル情報から、必要メモリを概算してください。
式: 重み=パラメータ数(B)×ビット数÷8、KV=2×トークン数×層数×KVヘッド数×ヘッド次元×バイト数、余裕=重み×0.1+1GB
モデル名: (例)〇〇-14B
量子化: Q4_K(4.5ビットとして計算)
config.jsonの該当部分: num_hidden_layers=…, num_key_value_heads=…, head_dim=…
コンテキスト長: 8192、並列数: 1
使えるメモリ: 16GB
計算過程を全部書き、不明な値は推測せず「不明」と答えてください。

人が確認する点は3つあります。数値がconfig.jsonと一致していること、単位(GBとGiB)の混在がないこと、AIが層数などを推測で補っていないことです。