今回の論文
今回取り上げるのは、DeepSeek-AI による論文「DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model」です。2024年5月7日に arXiv で公開されたプレプリントで、公開元は arXiv、研究分野は大規模言語モデル、推論効率化、MoE アーキテクチャです。URL は https://arxiv.org/abs/2405.04434 です。
この論文を選んだ理由は、DeepSeek-V2 全体の紹介論文でありながら、現在の LLM 実装で重要なボトルネックである KV キャッシュ問題に対して、かなり実用的な設計を出しているからです。特に Multi-Head Latent Attention（MLA）は、モデルをただ量子化するのではなく、注意機構そのものを作り替えて推論を軽くする考え方で、長文対応や高同時実行の開発にそのまま示唆があります。この記事では論文全体のうち、特に MLA を中心に読み解きます。
どんな技術か
Multi-Head Latent Attention は、Transformer の attention で毎トークン保存しておく Key と Value を、そのままキャッシュするのではなく、より小さな潜在ベクトルに圧縮して保持する技術です。
通常の Multi-Head Attention では、過去トークンぶんの Key と Value を各層・各ヘッドごとに持ち続ける必要があり、文脈が長くなるほど GPU メモリを強く圧迫します。MLA では、Key と Value を別々に大きく持つ代わりに、まず共有の latent 表現へ落とし込み、必要な計算はその latent から復元できるように設計します。
要するに、MLA は「attention の情報量をできるだけ保ちつつ、保存のしかたを賢く変える」技術です。これにより、長いコンテキストを扱うときのメモリ負荷を減らし、同じハードウェアでもより大きいバッチや長い入力を扱いやすくします。
課題
この技術が解決しようとしているのは、LLM の推論でしばしば計算量より先にメモリが詰まる問題です。
何が難しいのかというと、自己回帰型の生成では、過去のトークンの Key と Value を毎回再計算すると遅すぎるため、通常は KV キャッシュとして保存しておきます。しかし、トークン数、層数、ヘッド数が増えると、このキャッシュ量が急激に大きくなります。長文対応モデルや同時接続が多い API サービスでは、ここが真っ先にコスト要因になります。
既存の方法としては、Multi-Query Attention（MQA）や Grouped-Query Attention（GQA）があります。これらは Key / Value を複数ヘッドで共有してキャッシュ量を減らしますが、論文では、性能面で標準的な Multi-Head Attention（MHA）に劣りやすい点が問題視されています。つまり、軽くはなるが、賢さを落としやすいということです。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは「少し速い」だけでは足りないからです。長い履歴を読むチャット、RAG、エージェント、コード補完、複数ユーザー同時利用では、推論メモリの削減がそのまま運用コスト、最大同時実行数、ユーザー体感速度に響きます。
特にプロダクト開発では、モデルの理論性能よりも「どのくらい安定して捌けるか」が重要になる場面が多いです。MLA はまさにそこを狙った技術です。
用語解説
- KVキャッシュ
- 生成済みトークンの Key と Value を保存しておく仕組みです。長文推論では再計算を避けるために必須ですが、LLM の実運用ではこの保存領域がメモリの大きなボトルネックになります。
- Multi-Head Attention（MHA）
- Transformer の標準的な attention です。複数ヘッドが別々の Key / Query / Value を持てるため表現力が高い一方、各ヘッドぶんの KV を保持するのでキャッシュが重くなります。MLA はこの強さをなるべく落とさず軽くする狙いです。
- MQA / GQA
- KVキャッシュ削減の既存手法です。MQA は全ヘッドで Key / Value をほぼ共有し、GQA はヘッドをグループ単位で共有します。どちらも軽量化には有効ですが、論文では性能低下とのトレードオフがある比較対象として扱われています。
- 低ランク圧縮
- 大きなベクトルを、より次元の小さい潜在空間に写して扱う考え方です。MLA では Key と Value を別々に大きく持たず、まず共有 latent に圧縮することでメモリを減らします。
- RoPE（Rotary Position Embedding）
- 位置情報を attention に組み込む方法です。MLA では圧縮と RoPE をそのまま混ぜると都合が悪いため、位置情報を担う成分だけを分離する decoupled RoPE が重要な工夫になります。
技術の仕組み
MLA のポイントは、MHA の計算を丸ごと捨てることではなく、どの情報をキャッシュし、どの情報を後で計算し直すかを再設計することです。
基本アイデア
標準的な MHA では、各トークンについて全ヘッド分の Key と Value をそのまま保存します。論文では、この方式だと 1 トークンあたり 2 × ヘッド数 × ヘッド次元 × 層数 の要素をキャッシュする必要があると整理しています。
MLA では、まず隠れ状態から Key と Value 用の共有 latent ベクトル c^KV を作ります。各ヘッドの Key / Value はその latent から射影して得られるように設計し、推論時には元の大きな Key / Value ではなく latent だけを保存します。これがメモリ削減の核です。
モデル構造
Key と Value を共同で圧縮する
論文では、Key と Value を別々に圧縮するのではなく、まず共通の latent ベクトルへ down-projection し、そこから Key 用と Value 用の up-projection をかける形をとります。これにより、保存対象は各ヘッドの大きなテンソルではなく、小さな latent だけで済みます。
ここで重要なのは、推論時には毎回 Key / Value を完全に復元しなくてもよいように、重み行列の一部を Query 側や出力側へ吸収できることです。論文では、この工夫によって「圧縮したが計算が増えすぎる」という事態を避けています。
Query 側も低ランク化する
MLA の主眼は KV キャッシュ削減ですが、論文では Query も別の latent に圧縮しています。これは KV キャッシュ削減そのものには効きませんが、学習時の activation メモリ削減に役立ちます。つまり MLA は、推論最適化だけでなく学習時のメモリ設計も意識した attention になっています。
RoPE を分離して扱う
低ランク圧縮だけだと、位置情報を入れる RoPE との相性が悪くなります。もし圧縮後に位置情報まで一緒に潰してしまうと、トークン内容の表現と位置の表現が干渉しやすくなります。
そこで論文は decoupled RoPE を導入します。内容情報を持つ圧縮 Key / Value 系とは別に、位置情報を担う Query と共有 Key を用意し、RoPE はそちらにだけ適用します。要するに、内容は圧縮してよいが、位置は雑に潰してはいけないという設計です。
この分離は、MLA を単なる圧縮手法ではなく、attention の情報の役割分担として成立させている重要な工夫です。
推論方法
推論時の流れは次のように考えると分かりやすいです。
1. 現在トークンの隠れ状態を受け取る
まず通常どおり、各層で現在トークンの hidden state を入力として受け取ります。
2. Key / Value を直接保存せず latent に落とす
その hidden state から、小さな c^KV を作ります。これがキャッシュ対象です。
3. 位置情報は分離した経路で与える
RoPE は別に持った Query / Key 成分へ載せます。これにより、圧縮された内容表現と位置表現を混線させにくくします。
4. Attention を計算して出力へ戻す
必要な attention 計算を行い、最終的に出力射影で元の表現空間へ戻します。重み吸収の工夫があるため、latent を使った軽量なキャッシュ設計でも実用的な計算ができます。
キャッシュ量はどれくらい減るのか
論文の Table 1 では、MHA の KV キャッシュ量を 2n_h d_h l、MLA を (d_c + d_h^R) l と整理しています。DeepSeek-V2 の設定では d_c = 4d_h、d_h^R = d_h / 2 なので、MLA のキャッシュ量は概ね 4.5 d_h l です。論文はこれを「GQA の 2.25 グループ相当の小ささ」と説明しています。
ここが面白いのは、MQA のように極端に共有して軽くしたわけではなく、表現力をある程度残したまま、保存形式だけを圧縮していることです。これが MLA の性能面の強さにつながっています。
実験と結果
論文では、MLA が本当に有効なのかを二段階で検証しています。ひとつは既存軽量 attention である MQA / GQA との比較、もうひとつは MHA と MLA を直接比べる比較です。
何を検証したのか
主な検証点は3つです。1つ目は、MQA や GQA が本当に性能を落とすのか。2つ目は、MLA が MHA より小さい KV キャッシュで同等以上の性能を出せるのか。3つ目は、モデル全体として実運用レベルの推論スループット改善につながるのかです。
どんなデータセットや評価指標を使ったのか
評価には BBH、MMLU、C-Eval、CMMLU などの難しめのベンチマークが使われています。モデル全体の比較では、HumanEval、MBPP、GSM8K、MATH、AGIEval なども用いられており、推論能力だけでなくコードや数理性能も見ています。
指標は、MMLU や C-Eval では Accuracy、BBH では Exact Match、HumanEval では Pass@1 のように、各タスクに応じた標準指標が使われています。論文全体としては「速いだけでなく、ちゃんと賢いか」を見にいっている構成です。
MQA と GQA は軽いが、MHA に及ばなかった
Appendix D.1 では、同規模の 7B dense モデルで MQA、GQA、MHA を比較しています。結果は、MMLU で MQA 37.9、GQA 41.2、MHA 45.2、C-Eval で MQA 30.0、GQA 37.7、MHA 42.9 でした。CMMLU でも MQA 34.6、GQA 38.4、MHA 43.5 となっており、標準 MHA の優位性がかなりはっきり出ています。
この結果は重要です。単純な KV 共有でメモリを減らすだけでは、難しい推論や知識タスクで性能を落としやすいことを示しているからです。MLA は、まさにこの欠点を避けるために設計されたと読めます。
MLA は MHA より小さいキャッシュで、むしろ高い成績を出した
Appendix D.2 では、同じ MoE 構成で attention だけを MHA と MLA に替えた比較が示されています。小規模 MoE では KV キャッシュ量が MHA の 110.6K 要素に対して MLA は 15.6K 要素でした。大規模 MoE では MHA 860.2K 要素に対して MLA 34.6K 要素です。
それでも性能は落ちていません。たとえば大規模 MoE では、BBH が MHA 46.6 に対して MLA 50.7、MMLU が 57.5 に対して 59.0、C-Eval が 57.9 に対して 59.2、CMMLU が 60.7 に対して 62.5 でした。論文では、小規模モデルで MHA 比 14%、大規模モデルで 4% の KV キャッシュ量で済みながら、性能は MLA のほうが高かったと報告しています。
これは単に「軽くなった」ではなく、「軽量化の仕方がうまい」と言うべき結果です。
モデル全体でも推論効率が大きく改善した
DeepSeek-V2 全体として見ると、論文は DeepSeek 67B 比で学習コストを 42.5% 削減し、KV キャッシュを 93.3% 削減し、最大生成スループットを 5.76 倍にしたと報告しています。実運用に近い評価では、8 枚の H800 GPU を載せた単一ノードで、生成スループットが毎秒 50K トークン超、入力スループットが毎秒 100K トークン超とされています。
もちろんこれは MLA 単独の効果ではなく、MoE や FP8 化、KV 量子化も含んだ全体最適化の結果です。ただし、その中でも MLA が「大量同時処理を可能にする基礎条件」を作っているのは明確です。
何に使える？
MLA の考え方は、巨大研究モデルだけでなく、実際の AI アプリや推論基盤設計にもかなり応用可能です。
長文チャットや社内ナレッジ検索
会話履歴が長いチャットボットや社内ドキュメント検索では、コンテキストが伸びるほど KV キャッシュが効いてきます。MLA 的な設計が入ったモデルを使えば、同じ GPU でもより長い履歴を維持しやすくなります。
これは RAG のユーザー体験にも効きます。検索結果を多めに入れたいがメモリが苦しい、という状況で、単にコンテキストを削る以外の選択肢になります。
エージェントの長い実行履歴保持
AI エージェントは、ツール呼び出し結果、途中の計画、観測ログなどを長く持ちがちです。ここで KV キャッシュが重いと、履歴を短く切るか、頻繁に要約する必要が出ます。
MLA に近い発想のモデルなら、より長い文脈を保持したまま推論を続けやすくなります。これはマルチステップの業務自動化や開発支援エージェントで特に有効です。
高同時実行の API サービス
SaaS や社内基盤では、1ユーザーの最高性能より、同時に何リクエスト捌けるかが重要です。KV キャッシュが小さければ、同じ GPU メモリでより大きなバッチを積みやすくなります。
論文が示すスループット改善は、まさにこの方向の価値です。モデル単体の精度ベンチマークだけでは見えない、プロダクト運用上の強みがあります。
推論基盤そのものの設計指針
MLA は「attention の重み付けはそのまま、保存形式を変える」という発想なので、量子化、MoE、ページング、speculative decoding といった他の最適化とも組み合わせやすいです。推論高速化を1つの魔法の手法で解くのではなく、メモリ・計算・並列度を分けて最適化する設計思想として参考になります。
開発や事業へのヒント
この論文から得られる実務的なヒントは、LLM の改善余地はモデルサイズだけではないということです。アーキテクチャの工夫で、同じ GPU 予算でもプロダクトの成立条件を変えられます。
まず見るべきは FLOPs ではなくメモリかもしれない
自分で AI アプリを作るとき、つい「このモデルは何 tokens/sec 出るか」を見がちですが、実際には KV キャッシュのせいで同時実行数や最大文脈長が制限されることが多いです。MLA の発想は、性能改善の対象を計算量だけに限定しない重要性を示しています。
小規模プロダクトでも、モデル選定時に「長文時のメモリ効率」「バッチが伸びるか」を比較する視点はかなり有効です。
圧縮は出力後ではなく内部表現にかける
多くの実務最適化は、プロンプト圧縮、ログ圧縮、回答短縮のように入出力まわりで行われます。一方 MLA は、モデル内部の表現設計を見直すことで、性能を保ったままコストを下げようとしています。
この考え方は、RAG の中間表現、エージェントの状態表現、マルチモーダル特徴量の保持方法にも応用できます。つまり「何を残すか」をタスク単位で再設計する発想です。
高性能モデルの差別化は運用効率でも起きる
事業面では、同じくらい賢いモデルでも、より低コストで長文や高負荷運用に耐えるなら、それ自体が大きな競争力になります。とくに API 提供、B2B ツール、社内基盤のように利用量が積み上がるサービスでは、推論メモリ効率はそのまま粗利に効きます。
MLA のような技術は、単なる研究上の工夫ではなく、モデル提供コストの構造を変えるレバーになりえます。
今後は「文脈をどう保存するか」が差別化点になる
今後注目したいのは、長文対応を単にコンテキスト長の数字で競うのではなく、どのような表現で履歴を持つかという方向です。MLA はその一例で、将来的には KV 圧縮、選択的保持、外部メモリ、階層記憶の設計がより重要になると考えられます。
これは推測を含みますが、長文エージェントや常時稼働アシスタントが一般化するほど、「全部をそのまま保存する」方式はコスト的に苦しくなります。その意味で MLA は、次の世代の文脈管理の入口として見る価値があります。
限界
まず、MLA はアーキテクチャ変更を伴うため、既存の一般的な Transformer 実装へそのまま差し込めるわけではありません。単なる推論ライブラリの設定変更ではなく、モデル設計段階から対応している必要があります。
次に、軽量化の恩恵は主に KV キャッシュの大きさに現れるため、短い入力や低同時実行の場面では効果が相対的に小さい可能性があります。つまり、どんなワークロードでも魔法のように速くなるわけではありません。
また、論文の高い実運用性能は MLA 単独ではなく、MoE、FP8、KV 量子化、クラスタ最適化まで含めた全体設計の結果です。したがって、MLA だけ真似しても同じスループットが出るとは限りません。
さらに、位置情報を分離する decoupled RoPE や重み吸収のような工夫は実装難度がそれなりに高いです。独自モデル開発なら価値がありますが、一般的なファインチューニングや小改造で気軽に導入するタイプの技術ではありません。
最後に、論文の比較は主に DeepSeek 系の設計文脈で行われています。他系列モデルや別スケールでも常に同じように有利かは、今後の追試を見ていく必要があります。
よくある質問
Q. MLA は GQA や MQA と何が違うのですか？
A. GQA や MQA は Key / Value を共有して数を減らす発想です。一方 MLA は、Key / Value を共有 latent に圧縮して保存し、必要な計算はそこから行えるようにします。共有のしかたが粗いのではなく、表現を圧縮している点が大きな違いです。
Q. MLA は既存の LLaMA 系モデルにそのまま導入できますか？
A. そのままは難しいです。MLA は attention の内部構造と位置エンコーディングの扱いを変えるため、通常は事前学習段階から前提にしたモデル設計が必要です。後付け変換の研究はありえますが、一般的な LoRA のような軽い導入ではありません。
Q. どんなサービスで特に効きますか？
A. 長文チャット、RAG、エージェント、コード支援、同時アクセスの多い API サービスで効きやすいです。理由は、これらの用途では 1 回の生成品質だけでなく、長い文脈保持と高同時実行が重要だからです。
Q. MLA があれば量子化や speculative decoding は不要ですか？
A. 不要にはなりません。MLA は主に KV キャッシュ問題を改善する技術で、重みメモリ、計算レイテンシ、デコード戦略の最適化とは別の軸です。実運用では、論文と同様に他の最適化と組み合わせる前提で考えるのが自然です。
Q. この論文から実務ですぐ学べる点は何ですか？
A. 推論最適化では「演算を減らす」だけでなく「何を保存するかを変える」ことが大きな武器になる、という点です。モデルの賢さだけでなく、履歴保持の表現設計がプロダクト性能を左右することがよく分かります。
今日の学び
この論文は、LLM の長文推論や高同時実行を難しくする KV キャッシュの重さを大きな課題として扱いました。そこに対して、Key と Value を共有 latent に圧縮し、位置情報は分離して扱う Multi-Head Latent Attention という注意機構で解こうとしました。
得られるヒントは明確です。AI プロダクトの性能は、モデルサイズやベンチマークの点数だけで決まるわけではありません。文脈をどう保持するか、どの内部表現を残すかまで含めて設計すると、同じ計算資源でも作れる体験が変わります。