Macで動くモデルサイズの計算式──「コンテキスト窓が広い」の裏でVRAMが消えていく仕組み

クラウドAPIで「1Mトークン対応」と謳われるモデルを見て、自分のPCやMacで同じ長さのコンテキストを扱おうとすると、なぜかメモリが足りなくなる。この現象の正体は「KVキャッシュ」と呼ばれる仕組みにある。IT企業InventiveHQが2026年6月25日に公開した技術記事から、コンテキスト長とメモリ消費の関係を式で確認する。

• KVキャッシュのサイズは2 × 層数 × KVヘッド数 × head_dim × コンテキスト長 × 1要素あたりバイト数という式で決まる。70Bクラスのモデルでは128Kトークンで約40GB、1Mトークンでは約320GBに達する
• この記事の「70Bクラス」という想定パラメータ(層数80・KVヘッド数8・head_dim 128)は、実在するMeta-Llama-3-70Bの公式config.json（Hugging Face）と完全に一致することをこの記事で確認した。ただし同モデルのネイティブなコンテキスト長は8,192トークンで、1Mトークンという数字自体はあくまで計算上の延長にすぎない
• メモリ消費を抑える手段の1つ「PagedAttention」を最初に提案したvLLM公式ブログによると、従来方式はメモリの60〜80%をフラグメンテーションと過剰確保で無駄にしていた。GQA自体も2023年の論文(arXiv:2305.13245)で提案された、比較的新しい最適化手法だ

KVキャッシュとは何か、なぜ必要か

記事はまず、KVキャッシュが存在する理由をこう説明している。

"A decoder-only transformer generates one token at a time. To produce the next token, the attention mechanism needs the key and value vectors for every token that came before it. The naive approach would recompute those keys and values for the entire sequence on every single step — quadratic work that gets slower as the text grows."

デコーダ専用のトランスフォーマーは1トークンずつ生成する。次のトークンを作るには、それ以前のすべてのトークンのキー・バリューベクトルが必要になる。素朴な実装では、これを毎ステップ全シーケンス分再計算することになり、テキストが伸びるほど遅くなる二次関数的な処理量になってしまう。

これを避けるための最適化がKVキャッシュだ。モデルがあるトークンを処理する際、そのキー・バリューベクトルを1回だけ計算してGPUメモリに保存しておき、以降のステップではそれを再利用する。これにより生成処理は、シーケンス長に対して二次関数的ではなく、新規トークン数に対して線形になる。ただし、このキャッシュはタダではない。リクエストが生きている間ずっとVRAMに居座り、増え続ける一方だ。クラウドAPIを使う場合はこのメモリコストが見えないが（提供元がメモリを負担し、トークン単価で課金する）、自分のGPUで動かす場合は、大きなモデルに使いたかったVRAM予算を直接圧迫することになる。

メモリ消費の計算式

KVキャッシュのサイズは、アテンション層の形状から直接導かれる。

kv_bytes = 2 × n_layers × n_kv_heads × head_dim × seq_len × bytes_per_elem

各項の意味は次の通り。

• 2：キー（K）とバリュー（V）、2つのテンソル分
• n_layers：トランスフォーマーの層数（層ごとに個別のキャッシュを持つ）
• n_kv_heads × head_dim：1トークン・1層あたりのKV幅。通常のマルチヘッドアテンション（MHA）ではアテンション幅全体に等しいが、グループドクエリアテンション（GQA）ではこれよりずっと小さくなる
• seq_len：現在のコンテキスト内のトークン数（プロンプト＋これまでに生成した分）。この項が「動く変数」
• bytes_per_elem：FP16/BF16なら2、FP8/INT8のKVなら1、Q4のKVなら約0.5

具体例：Llama-3 70Bクラスのモデル

記事が示す計算例では、Llama-3 70Bクラス（層数80、KVヘッド数8＝GQA、head_dim 128、FP16のKV）で、1トークンあたりのコストは次の通りだ。

2 × 80 × 8 × 128 × 2バイト ＝ 327,680バイト ≒ 0.3125MB／トークン

一見小さな数字だが、実際のコンテキスト長を掛け合わせると事情が変わる。

同じ70Bモデルの重み自体は、Q4_K_M量子化でおよそ40GBだ。表からわかる通り、128Kトークンの時点でFP16のKVキャッシュ（約40GB）はすでにモデルの重みと同じ規模に達し、256Kトークンでは重みの2倍に達する。「コンテキスト窓」は、もはや単なる記憶力の機能ではなく、VRAM予算の中で最大の項目になる。

この記事の想定パラメータ（層数80・KVヘッド数8・head_dim 128）が本当に現実的な数字なのかを、実在するモデルの公式設定ファイルで確認した。Hugging Face上のMeta-Llama-3-70Bのconfig.jsonを直接取得すると、num_hidden_layers: 80・num_key_value_heads: 8・num_attention_heads: 64・hidden_size: 8192（head_dim = 8192 ÷ 64 = 128）となっており、InventiveHQ記事の想定パラメータとすべて一致する。つまりこの記事の計算例は架空の数字ではなく、実在する70Bモデルの実際のアーキテクチャそのものだ。ただし、同じconfig.jsonのmax_position_embeddingsは8,192で、このモデル本来のネイティブなコンテキスト長は8Kトークンにすぎない。128Kや1Mといった長さは、別途コンテキスト拡張の手法（RoPEスケーリング等）を適用した場合の計算上の延長であり、素のLlama-3-70Bがそのまま1Mトークンを扱えるわけではない。

なぜ「1Mトークン対応」が個人のGPUでは非現実的なのか

記事は、この式を1Mトークンまで伸ばした場合の結論も示している。

"At 1M tokens, our 70B GQA model needs: 1,048,576 tokens × 0.3125 MB/token ≈ 320 GB of FP16 KV cache. That is the cache alone — before the ~40 GB of weights, before activation buffers, before the 1–2 GB of CUDA runtime overhead."

70BのGQAモデルで1Mトークンのコンテキストを扱うには、KVキャッシュだけで約320GBが必要になる。これはモデルの重み（約40GB）を含まない、キャッシュ単体の数字だ。320GBというのは、80GBのデータセンター向けGPUを4枚つなげて、ようやくキーとバリューを保持できる規模。FP8にKVを量子化しても約160GBで、依然として大型カード2枚分に相当する。記事は、当時（2026年6月）のクラウド版モデルであるGPT-5.5・Claude Opus・Gemini Proを例に挙げ、『100万トークン対応』は、FP8 KVとPagedAttentionを備えたH100/H200クラスのクラスタインフラの産物であり、デスクトップGPUが到達できる領域ではない、と結論づけている。

メモリ消費を抑える4つのレバー

記事は、KVキャッシュの消費を実際に動かせる4つの手段を挙げている。

記事は特にGQAの重要性を強調している。「70Bの例は64のクエリヘッドに対しKVヘッドは8だけで、フルMHA比で8倍の削減になっている。GQAがなければ、同じモデルは表の8倍の数値が必要になり、128Kトークンには320GBのFP16 KVが必要になる（40GBではなく）」という。GQAは単なるチューニングオプションではなく、「長いコンテキストがそもそも実現可能である理由」だと位置づけられている。

実践的な指針

記事が最後にまとめる実践的な指針は次の通りだ。

• 実際に使うコンテキスト長を選ぶこと。モデルが許す最大値ではなく。多くのコーディング・文書タスクは32K未満で十分収まる
• ローカルでの長文コンテキスト用途には、GQA/MQA対応モデルを優先する
• 大きなGPUに手を伸ばす前に、FP8/INT8のKV量子化を有効にする
• ハードウェアを買う前に、重み＋KV＋オーバーヘッドの全体予算をモデル化する

実務上の含意

Mac Studio M5 Ultraのような大容量統合メモリマシンでも、この計算式は変わらない。512GBのメモリがあっても、大きなモデルの重み＋長いコンテキストのKVキャッシュ＋OS・アプリのオーバーヘッドを同時に賄う必要がある点は同じだ。メモリ帯域幅がトークン生成の「速度」を決める話についてはメモリ帯域幅1.2TB/sは何を意味するのか、GGUF・MLXといったフォーマットの違いはGGUFとMLX、Macで動かすならどっちを選ぶべきか、ローカルLLMの基礎知識全般はローカルLLMとは何かも参照してほしい。

確認したのは1つの技術メディアの記事だけ

• 本記事はInventiveHQという1つの技術メディアの記事を主な一次資料とし、加えてHugging Face上のMeta-Llama-3-70B公式config.json・vLLM公式ブログ・GQA論文(arXiv)の3点を追加で確認した。記事内の数値例（層数80・KVヘッド数8・head_dim 128）が実在するLlama-3-70Bの公式設定と一致することは確認できたが、それ以外の点（GQAの4〜8倍という圧縮率の一般性、Q4量子化の約4倍という数字の根拠論文）までは個別に検証していない。
• KVキャッシュの計算式はモデルアーキテクチャによって変わる。特にGQAの採用有無・KVヘッド数はモデルごとに異なるため、本記事の数値をそのまま別のモデルに当てはめることはできない。実際に使うモデルの正確な数値は、そのモデルの公式設定ファイル（config.json等）で確認する必要がある。
• 「1Mトークン対応」を謳うクラウドモデルが実際にどのようなハードウェア構成（H100/H200クラスタ、PagedAttentionの実装詳細など）で動いているかについて、記事は一般論として言及しているが、OpenAI・Anthropic・Google各社の具体的なインフラ構成は公表されておらず、本記事でも確認できていない。
• 本記事で紹介した数値・計算式は、あくまで見積もりのための目安であり、実際のメモリ消費量は推論エンジン（vLLM、llama.cpp、MLXなど）の実装、アクティベーションメモリ、CUDAランタイムのオーバーヘッドなどによって変動する。
• 引用元記事（InventiveHQ、2026年6月25日付）が「100万トークン対応」の例に挙げたGPT-5.5は、記事公開時点でのOpenAIの主力モデルである。その後OpenAIは2026年7月9日にGPT-5.6（Sol/Terra/Luna）を、2026年9月3日にGPT-6 Astraを公開しており、2026年9月4日時点でGPT-5.5は同社の最新モデルではない。