Skip to content
Published on

アテンションの変種 — MHA から MLA まで、KV キャッシュはどう縮むか

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに

長い文脈を扱うモデルを配信したことがある人なら、KV キャッシュがどれほど速くメモリを食うか知っています。重みは固定ですが、KV キャッシュは利用者数と文脈長に比例して増えます。ここ数年のアテンションの変種は、事実上この一つの問題を解く歴史です。

この記事では MHA から MQA、GQA を経て MLA に至る流れを、実際の config 値で追います。すべての計算は前の記事で確認した公開設定ファイルから出ています。

数値は 2026-08-12 に論文・公式レポート・config.json で直接確認しました。モデルは更新されるため、原典を再度確認してください。

なぜ KV キャッシュが問題なのか

自己回帰生成では、トークンを一つ作るたびに先行するすべてのトークンのキーと値が必要になります。毎回計算し直す代わりに保存しておくのが KV キャッシュです。大きさは次の式で決まります。

KV キャッシュのバイト数
  = 2 x 層数 x キー・値ヘッド数 x head_dim x 文脈長 x 要素あたりバイト数

先頭の 2 はキーと値の二組を意味します。

このうちモデル設計者が現実的に動かせる項は事実上一つ、キー・値ヘッド数だけです。層数とヘッド次元は品質に直結し、文脈長は利用者が決めます。

MHA から MQA へ、そして GQA

もとのトランスフォーマーはクエリヘッドごとにキー・値ヘッドを一つずつ持っていました。これが MHA です。MQA は反対の極端に振れ、すべてのクエリヘッドがキー・値ヘッド一つを共有します。キャッシュはヘッド数の分だけ縮みますが、表現力の損失が大きくなります。

GQA はその中間です。GQA 論文はこの手法を、クエリヘッドより少なく 1 より多い中間的な数のキー・値ヘッドを使う多クエリアテンションの一般化と定義し、既存の多ヘッドチェックポイントを変換するには元の事前学習計算量の 5 パーセントが必要だと報告しています(Ainslie et al., arXiv:2305.13245)。

現在出ている密なモデルのほとんどが GQA を使います。実際の config で確認した比率は次のとおりです。

モデル                   クエリヘッド / キー・値ヘッド   比
Qwen3-8B                      32 / 8                    4:1
Qwen3-32B                     64 / 8                    8:1
Qwen3-235B-A22B               64 / 4                   16:1
Qwen2.5-7B                    28 / 4                    7:1
Mixtral-8x7B                  32 / 8                    4:1
GLM-4.5                       96 / 8                   12:1
Llama 3.1 (8B/70B/405B)   32,64,128 / 8          4:1, 8:1, 16:1

Llama 3 系の値は技術レポートの表 3 から取りました(arXiv:2407.21783)。表を見ると、モデルが大きくなるほど比率を積極的に上げています。大きなモデルほどクエリヘッドが多く、キャッシュの圧迫が強いためです。

MLA: キャッシュする対象そのものを変える

DeepSeek-V2 が導入し DeepSeek-V3 と Kimi K2 が引き継いだ MLA は、別のアプローチを取ります。ヘッド数を減らす代わりに、キーと値を低次元の潜在ベクトルへまとめて圧縮し、その潜在ベクトルだけをキャッシュします。

DeepSeek-V3 レポートのハイパーパラメータを見ると、アテンションヘッドは 128 個、ヘッド次元は 128、KV 圧縮次元は 512、クエリ圧縮次元は 1536、分離されたクエリ・キーのヘッド次元は 64 です(arXiv:2412.19437)。キャッシュに残るのは圧縮された潜在ベクトルと分離されたキーだけです。

MLA キャッシュ要素/トークン = 層数 x (kv_lora_rank + qk_rope_head_dim)
DeepSeek-V3                 = 61 x (512 + 64) = 35,136

同じモデルを MHA で作った場合
                            = 2 x 61 x 128 x 128 = 1,998,848

比 = 1,998,848 / 35,136 = 約 56.9 倍

DeepSeek-V2 論文は、この設計により DeepSeek 67B に対して KV キャッシュを 93.3 パーセント削減し、最大生成スループットを 5.76 倍に高めたと報告しています(arXiv:2405.04434)。

一つの表で比べる

fp16 基準、文脈 32,768 トークン分をキャッシュしたときの大きさです。すべて上の式に config の値を代入して計算しました。

モデル            方式   要素/トークン   MHA 比   32K キャッシュ(fp16)
Qwen3-8B          GQA         73,728    4.0 倍       4.50 GiB
Qwen3-32B         GQA        131,072    8.0 倍       8.00 GiB
Qwen3-235B-A22B   GQA         96,256   16.0 倍       5.88 GiB
Mixtral-8x7B      GQA         65,536    4.0 倍       4.00 GiB
GLM-4.5           GQA        188,416   12.0 倍      11.50 GiB
DeepSeek-V3       MLA         35,136   56.9 倍       2.14 GiB
Kimi K2           MLA         35,136   28.4 倍       2.14 GiB

注目すべき点が二つあります。第一に、Qwen3-235B-A22B は 2350 億パラメータのモデルなのに、80 億の Qwen3-8B より KV キャッシュがわずか 30 パーセント大きいだけです。キー・値ヘッドを 4 個にまとめているからです。第二に、DeepSeek-V3 と Kimi K2 のトークンあたりキャッシュは完全に同じです。両者の層数と圧縮次元が一致するためです。ただし MHA 比の削減倍率は異なります。Kimi K2 はアテンションヘッドが 64 個で、比較対象となる MHA の基準線がそもそも半分だからです。

何を差し出すのか

ここが肝心です。キャッシュを縮めれば必ず何かを差し出します。

GQA は表現力を差し出します。複数のクエリヘッドが同じキー・値を見るため、ヘッドごとに異なる情報へ注目する能力が減ります。GQA 論文がこれを品質と速度のあいだの折衷と位置づけるのはそのためです。

MLA は計算と複雑さを差し出します。圧縮と復元のための行列が追加され、位置情報を扱うためにクエリとキーの一部を分離して別に処理する必要があります。DeepSeek-V3 レポートが、圧縮された潜在ベクトルの後に追加の RMSNorm を置き、幅が狭まる箇所でスケーリング係数を掛けると述べているのも、この構造がただでは手に入らないことを示しています。

ヘッド数そのものを減らすという選択

Kimi K2 は別の軸を動かしました。レポートの表 2 によると、DeepSeek-V3 のアテンションヘッド 128 個を 64 個へ半減させています。理由は同じ節に具体的に書かれています。シーケンス長 128k において、全専門家数を 384 に固定したままアテンションヘッドを 64 から 128 に増やすと、推論の演算量が 83 パーセント増加するというものです。

反対側の利得も測定しています。同じレポートは、ヘッド数を二倍にしたときの検証損失の低下が約 0.5 パーセントから 1.2 パーセントにとどまったと報告し、その程度の利得は推論コストを正当化しないと結論づけています(arXiv:2507.20534)。設計判断がどんな根拠の上で下されるかを示す良い例です。

おわりに

アテンションの変種の読み方は簡単です。config で num_attention_heads と num_key_value_heads の比を見て、kv_lora_rank があれば MLA と判断すればよいのです。そして式に入れてトークンあたりのキャッシュを自分で計算してみてください。そのモデルが長い文脈にどう向き合うつもりかは、その一つの数字に収まっています。

参考資料

試してみる

シリーズ

Discuss on Twitter • View on GitHub