グループ化クエリアテンションとは？GQAの仕組みとKVキャッシュ削減・実装判断を解説

グループ化クエリアテンション（GQA・Grouped Query Attention）は、複数のクエリヘッドで1組のキーとバリューのヘッドを共有させ、KVキャッシュの容量を分母ごと縮めるアテンション構造です。Llama 3やMistralをはじめ、2026年8月時点で公開されている主要なオープンモデルは、ほぼこの構成を採っています。この記事では、MHA・MQAとの構造差、KVヘッド数から必要メモリを逆算する式、Hugging Face TransformersやvLLMで実際に効いてくる設定値、そしてGQAのモデルを選んでよい条件とMLA系へ切り替える境界までを、実装者の目線で整理します。

まとめ：GQAの仕組みとKVヘッド数から決めるモデル選定の結論

GQAは、h個のクエリヘッドをg個のグループに割り、グループごとに1組のキー・バリューヘッドを共有する構造です。KVキャッシュの容量はクエリヘッド数ではなくKVヘッド数に比例するため、32ヘッドを8グループにまとめれば容量は4分の1に落ちます。GQAを提案した論文（arXiv 2305.13245・EMNLP 2023）は、この構成が全ヘッド独立のMHAに近い品質を保ちながら、全ヘッド共有のMQAに近い推論速度を出したと報告しました。

実務でのGQAは「選ぶ技術」ではありません。事前学習の時点で構造として決まっているため、推論側で後から切り替えられないからです。エンジニアが実際にやるのは、使うモデルのKVヘッド数を読み、そこからGPUメモリの必要量を逆算し、テンソル並列の分割数と噛み合うかを確かめる作業になります。

判断の結論を先に置きます。2026年8月時点で新規に推論基盤を組むなら、GQA構成のモデルを既定に据えてよい状況です。KVキャッシュをさらに1桁削りたい場合の選択肢はMLA系ですが、乗り換えの判断はモデル自体の品質とバックエンド対応で決まり、アテンション構造の優劣だけでは決まりません。

GQAが解く問題｜KVキャッシュがデコード速度を縛る構造と内訳

GQAの効き所を理解するには、生成中のGPUで何が帯域を食っているのかを先に切り分けます。膨らむのは演算量ではなく、読み出す量です。

デコード1トークンごとに全KVを読み直すメモリ帯域律速の構造

自己回帰生成では、1トークン出すたびに、それまでの全トークン分のキーとバリューを読み直してアテンションを計算します。演算そのものは行列とベクトルの積で軽い一方、読み出すデータ量は文脈長に比例して増え続けます。この段階で律速するのはGPUの演算性能ではなく、HBMからの読み出し帯域です。だからKVキャッシュの容量を減らすと、そのまま1トークンあたりの待ち時間が縮みます。アテンションそのものの計算過程はTransformerの自己注意の仕組みで扱っているため、ここでは読み出し量の問題だけを追います。

Llama 3 8Bで128Kトークンが16GBに達するKV容量の実測式

KVキャッシュの容量は次の式で求まります。2（キーとバリューの2種類）× 層数 × KVヘッド数 × ヘッド次元 × 精度のバイト数、これに文脈長とバッチ数を掛けた値です。Llama 3 8Bは32層・KVヘッド8個・ヘッド次元128で、fp16なら1トークンあたり131,072バイト、つまり128KBになります。128Kトークンの文脈を1本抱えると16GBです。仮に同じモデルがMHA構成（KVヘッド32個）だったなら、1トークン512KB・128Kトークンで64GBに達し、80GBのGPU1枚でバッチ1本すら苦しくなります。KVキャッシュ全体の削減手段はKVキャッシュの仕組みとメモリ削減に整理しました。

MQAが招いた品質劣化と学習不安定というGQA登場前の行き詰まり

KVヘッドを1個まで削り切る方式がMQA（Multi-Query Attention・2019年提案）です。容量は理論式で示せる比率どおり、確実に減ります。32ヘッドなら32分の1です。ただしGQA論文は、MQAが品質の劣化と学習の不安定さを伴い、特に長い入力の要約タスクで差が開いたと指摘しました。MHAとMQAの二択では、メモリを取るか品質を取るかの排他選択になってしまう。この行き詰まりに中間点を置いたのがGQAで、削減率と品質のどちらも捨てない設計として2023年に提案されました。

MHA・MQA・GQAの構造差｜KVヘッド共有比が精度と容量に効く境目

3方式の違いは、キーとバリューの射影を何個持つかという1点に集約されます。クエリ側のヘッド数はどの方式でも変わりません。

クエリヘッドをg個の群に割りKV射影を共有するGQAの構造定義

h個のクエリヘッドをg個のグループに分け、各グループに属するh/g個のクエリヘッドが、同じ1組のキーヘッド・バリューヘッドを参照します。g=hならMHAと一致し、g=1ならMQAと一致するため、GQAは両者を端点に持つ連続的な設計だと捉えると扱いやすくなります。計算の実体としては、共有されたKVをクエリヘッド数ぶん複製してから通常のアテンションを回す形です。ここで複製されるのは計算グラフ上のテンソルであって、キャッシュに保存するのは共有された少数のKVヘッドだけ。この非対称が、容量削減の正体になります。

MHA・MQA・GQAをKVヘッド数と容量比・品質で並べた比較表

方式ごとの性質を、モデル選定で効く軸だけに絞って並べます。

読み取るべきは2列目と3列目の関係です。容量はKVヘッド数だけで決まり、モデルの総パラメータ数とは連動しません。70Bのモデルが8Bのモデルより多くのKVを抱えるのは層数が増えるからであって、ヘッド共有の比率は同じ8グループのまま据え置かれることが多くあります。

Llama 3・Mistral 7Bが揃ってKVヘッド8個を選んだ設計理由

Llama 3は8B・70B・405Bのすべてで、KVヘッド数を8個に固定しました。8Bはクエリヘッド32個に対して8個、70Bは64個に対して8個です。Mistral 7B（arXiv 2310.06825）も32ヘッドに対してKVヘッド8個で、値が偶然一致しているわけではありません。8という数字は、推論時のテンソル並列でモデルを分割する枚数と揃えやすい値だからです。GPU8枚に分けるとき、KVヘッドがちょうど8個あれば1枚に1個ずつ配れて、複製が発生しません。アーキテクチャの数値が推論基盤の構成を先読みして決められている例といえます。

MHA済みチェックポイントを5%の追加学習でGQA化する変換手順

既存のMHAモデルを後からGQAへ寄せる経路も、論文が実証しています。手順は3段階です。

1. 各グループ内にあるKV射影行列を平均プーリングし、1組へ畳み込んで初期値にする
2. 元の事前学習に要した計算量の5%分だけ追加学習（uptraining）を回して馴染ませる
3. 長い入力の要約など劣化の出やすい評価データで、変換前の密構成と比較する

5%という数字が示すのは、ゼロから学習し直す必要はないという事実です。とはいえ数百GPU日規模のモデルなら、その5%でも自社で賄える量ではありません。研究機関やモデル提供者が行う工程であって、受託開発の現場で実施する作業ではないと割り切るのが現実的な線引きになります。

実装で触る設定値｜KVヘッド数とテンソル並列数が噛み合う条件

GQAは学習時に決まる構造ですが、推論側にも読むべき値と踏みやすい落とし穴があります。触る場所は設定ファイルと並列構成の2つです。

num_key_value_headsが決めるMHA・MQA・GQAの切り替わり

Hugging Face Transformersでは、この1つのキーが方式を決めます。LlamaConfigのnum_key_value_headsがnum_attention_headsと同値ならMHA、1ならMQA、その間ならGQAです。未指定の場合はnum_attention_headsと同じ値が入り、MHAとして動きます。制約として、クエリヘッド数はKVヘッド数で割り切れなければなりません。モデル内部ではrepeat_kvにあたる処理が共有KVをクエリヘッド数ぶん展開し、形状を揃えてからアテンションへ渡します。使うモデルのconfig.jsonでこの値を確認すれば、前述の式にそのまま代入してメモリ見積もりが立ちます。

テンソル並列数がKVヘッド数を超えたときに起きるKV複製の無駄

ここが本番で最も詰まる箇所です。テンソル並列はアテンションヘッドをGPU間で分割しますが、KVヘッドが8個しかないモデルを16枚のGPUへ分ける場合、分割しきれないKVヘッドは複製されて各シャードへ配られます。vLLMなどの推論エンジンはこの複製を自動で処理して動かしてくれるものの、複製された分だけKVキャッシュが二重に載るため、GPUを増やしたのに1枚あたりのKV使用量が減らないという結果になります。並列数はKVヘッド数以下に収めるか、割り切れる関係に整えるのが原則です。サーバ側の構成全体はvLLMの仕組みと使い方にまとめています。

KVキャッシュ量子化とGQAを重ねるときのVRAM見積もりの順序

GQAによる削減とKVキャッシュの量子化は、掛け算で効きます。fp16のKVをint8へ落とせばバイト数が2から1になり、GQAで8分の1になっている容量がさらに半分です。見積もりの順序を間違えないでください。先にKVヘッド数で削り、その後に精度のバイト数を掛ける。逆順で計算しても答えは同じですが、削減の余地がどちらに残っているかの判断を誤ります。KVヘッド数が既に8個まで絞られたモデルで、さらに容量を削りたいなら、残る手は量子化と文脈長の見直しの2つだけです。

GQAモデルを選ぶ判断基準と、MLA採用モデルへ切り替える境界

ここは判断を言い切ります。GQAは既定として受け入れてよい構造で、悩む価値があるのは「その先へ進むか」のほうです。

GQAモデルを選んでよい2条件＝長文脈の常態化と同時実行数の逼迫

第1の条件は、本番リクエストの入力トークン数を測り、中央値が8Kを超えていることです。数百トークンのやり取りが中心なら、KVキャッシュはそもそもGPUメモリを圧迫しません。第2の条件は、同時に捌きたいリクエスト数が二桁に乗っていることです。KV容量が4分の1になる意味は、同じGPUで同時実行数を4倍近くまで引き上げられる点にあります。逆に言えば、社内数十人が断続的に使う程度の負荷では、GQAかMHAかの差は体感に出ません。2026年8月時点では主要モデルがすでにGQA構成のため、この2条件は「GQAを選ぶ理由」というより「KV容量を評価軸に入れるかどうか」の閾値として機能します。

自前でKVヘッドを削る改造を見送るべき3場面と精度低下の出方

見送るべき場面を挙げます。第1に、公開済みモデルのnum_key_value_headsを設定ファイル上で書き換えて容量を減らそうとする場面。重みの形状と噛み合わずロード時点で落ちるか、無理に通しても出力が壊れます。第2に、追加学習の予算を確保しないままMHAモデルをGQA化しようとする場面。平均プーリングだけで済ませると、長い入力の要約や複数文書の照合で先に劣化が現れます。第3に、GPUメモリではなく応答遅延が課題になっている短文チャットの用途。この場合に効くのはKV容量ではなく、バッチ設計とカーネル側のIO削減で、FlashAttentionのGPU世代別の実装判断のほうが直接の打ち手になります。

LLM推論基盤を外注するとき見積書でKV構成を確認する5項目

GQAを含む推論基盤を外部に発注する場合、見積書で確認したい項目は次の5つです。

• 採用モデルのKVヘッド数と層数が明記され、KV容量の算出根拠になっているか
• 想定する最大文脈長と同時実行数から、必要VRAMが数値で示されているか
• テンソル並列数がKVヘッド数と割り切れる関係に設定されているか
• KVキャッシュの量子化を行う場合、精度への影響を評価する工程があるか
• モデル差し替え時にKV構成が変わる前提で、再見積もりの条件が書かれているか

この5項目が埋まらない見積書は、GPU台数の根拠が推測のまま積まれている可能性があります。自社に検証環境がない段階で判断しづらい場合は、機械学習モデル開発の受託で入力長の実測とモデル選定から相談できます。

よくある質問

GQAの検討で実際に問い合わせの多い論点を5つ挙げます。

GQAを使うとモデルの精度は落ちるのですか？

GQA論文の実験では、変換したT5モデルがMHAとほぼ同等の品質を保ち、MQAを上回る結果が論文内で報告されました。理論上は近似なので情報は落ちていますが、グループ数を2〜8程度に取る限り、ベンチマーク上の差は測定誤差に近い水準に収まります。品質が明確に落ちるのはKVヘッドを1個まで削ったMQAの側で、特に長い入力の要約タスクで差が開きます。GQAが事実上の標準になったのは、この折り返し地点を実験で押さえたからです。

使っているモデルのKVヘッド数はどこで確認できますか？

Hugging Face Hubで配布されているモデルなら、リポジトリ内のconfig.jsonにあるnum_key_value_headsが該当します。この値がnum_attention_headsと同じならMHA、小さければGQAです。GGUF形式で配布されているモデルの場合は、メタデータのattention.head_count_kvが同じ役割を持ちます。どちらも公開情報なので、モデルをダウンロードする前にメモリ見積もりを立てられます。

GQAとMLAはどちらを選ぶべきですか？

アテンション構造だけで選ばないでください。MLAはキーとバリューを低ランクの潜在ベクトルへ圧縮する方式で、KV容量はGQAよりさらに1桁近く小さくなります。ただしMLAを採用しているのは主にDeepSeek系のモデル群で、推論エンジン側も専用バックエンドが要ります。選定はモデル自体のタスク性能・ライセンス・バックエンド対応で行い、KV容量はその中の1変数として扱うのが妥当です。

GQAとスパースアテンションは何が違うのですか？

削る方向が直交しています。GQAはヘッドの方向で、KVの射影を何組持つかを減らします。スパースアテンションはトークンの方向で、各クエリが見に行く相手の数を絞る仕組みです。両者は排他ではなく、実際の長文脈モデルでは同時に採用されています。トークン側の削減についてはスパースアテンションの仕組みと実装判断で扱いました。

GQAのモデルなら文脈長を伸ばしても安心ですか？

安心とまではいえません。KV容量は文脈長に正比例するため、GQAで4分の1になっていても、文脈を4倍に伸ばせば元の水準へ戻ります。128Kトークンを謳うモデルでも、その長さをフルに使うバッチを複数走らせればGPUメモリはすぐ尽きます。公称の最大文脈長ではなく、自社の実リクエストの長さの分布と同時実行数から必要量を計算し、そこから逆算して台数を決める順序で見てください。

関連記事

• Transformerとは？自己注意の仕組みとBERT・GPTの違いを実装目線で解説：ヘッド共有の前提となるマルチヘッド自己注意の計算過程を扱っています
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】：GQAが縮める対象そのものの全体像が分かります
• スパースアテンションとは？疎なAttentionの仕組みとNSA・DSAの実装判断を解説：トークン方向の削減との違いを整理しています
• FlashAttentionとは？仕組みとFA2・3・4の違い・GPU世代別の実装判断を解説：カーネル側のIO削減という別軸の高速化手法です
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説：KVヘッド数と並列構成を突き合わせる推論サーバ側の話です