スパースアテンションとは？疎なAttentionの仕組みとNSA・DSAの実装判断を解説

スパースアテンション（sparse attention）は、Transformerのアテンションで「全トークン対の総当たり」をやめ、各クエリが見る相手を一部に絞る仕組みです。狙いは長い入力での計算量とメモリの削減にあります。この記事では、疎にしてよい根拠、固定パターン・スライディングウィンドウ・動的選択という3系統の設計差、Gemma 3やDeepSeekの実装値、transformers・FlexAttention・vLLMで実際に触る設定キー、そして自社の推論基盤に入れてよい条件と見送るべき場面までを、実装者の目線で整理します。

まとめ：スパースアテンションの仕組みと採用判断の結論

スパースアテンションは、L×Lのアテンションスコア行列のうち一部だけを計算する手法の総称です。系列長Lに対して計算量はO(L²)からO(Lk)（kは各クエリが見る相手の数）まで下がり、DeepSeek-V3.2の実装ではk=2048で128Kトークンの文脈を扱います。

設計は3系統に分かれます。窓や間引きを固定で決める方式、局所の窓と全域層を層ごとに配置する方式、そしてクエリごとに見る先を選ぶ動的選択方式です。後者ほど長文精度は保ちやすく、そのぶん学習と推論基盤の要求が上がります。

採用判断の結論は明快です。入力トークン数の実測中央値が32Kを下回り、同時実行数も逼迫していないなら、疎化は入れないほうがよい結果になります。密なアテンションのまま量子化とバッチ設計で詰めるほうが、精度と保守コストの両面で有利だからです。逆に、実測で64K前後の入力が常態化し、プリフィル時間が応答遅延の大半を占めているなら、疎化は検討に値します。

スパースアテンションが解く問題｜計算量O(L²)とKVキャッシュの内訳

疎化の議論に入る前に、密なアテンションで何が膨らむのかを分けて把握します。膨らむものは2つあり、対策も別々です。

系列長が2倍になるとスコア行列が4倍へ膨らむ計算量とメモリ負荷の構造

2017年の論文「Attention Is All You Need」が定義したアテンションは、Query・Key・Valueの内積を全トークン対で取ります。系列長がLならスコア行列はL×Lです。8Kトークンなら約6,400万ペア、128Kトークンなら約164億ペアに達します。系列長が2倍になれば計算量もメモリ帯域も4倍です。この二乗の壁が、長文脈モデルでプリフィル（入力の読み込み）時間を押し上げる主因になります。アテンションそのものの計算過程はTransformerの自己注意の仕組みで扱っているため、ここでは疎化の前提となる計算量だけを押さえます。見る相手を減らさず、厳密計算のままHBM往復だけを削る手法もあります。その仕組みとGPU世代別の実装判断はFlashAttentionの解説にまとめました。

計算量の削減とKVキャッシュの削減を切り分ける実装判断の基準

「疎にすればメモリも減る」という理解は、方式によっては成り立ちません。動的選択方式は、どのトークンが選ばれるか事前に決まらないため、KVキャッシュは全トークン分を保持したままです。減るのは計算量とメモリ帯域であって、キャッシュ容量ではありません。一方、スライディングウィンドウ方式は窓の外を捨てられるので、キャッシュ容量そのものが減ります。Gemma 3のテクニカルレポートは、32Kトークン時のKVキャッシュのメモリ増分が全域アテンションのみの構成で60%程度だったのに対し、局所層を挟む構成では15%未満に収まったと報告しました。自社のボトルネックがGPUメモリなのか演算時間なのかで、選ぶ系統が変わります。トークンではなくヘッドの方向でKVを削る手法はグループ化クエリアテンション（GQA）の仕組みと実装判断にまとめました。

アテンション重みが少数トークンへ偏る性質というモデル設計上の疎化根拠

疎化が成立するのは、softmax後のアテンション重みが実際には少数のトークンへ集中するからです。全ペアを計算しても、寄与の大半は上位のごく一部が占めます。DeepSeek-V3.2はこの性質を使い、各クエリが選ぶKVトークンを2048個に絞ったうえで128Kの文脈長を維持しました。逆に言えば、重みが広く分散する種類のタスク（全文の均等な集約や網羅的な照合）では、この前提が崩れて精度が落ちます。疎化を入れる前に、自社タスクがどちらの性質かを評価データで確かめる手順が要ります。

疎パターンの3系統｜固定・スライディングウィンドウ・動的選択の設計差

疎パターンは「誰が見る先を決めるか」で系統が分かれます。固定パターンは設計者、ウィンドウ方式は位置関係、動的選択はモデル自身が決めます。

固定型＝Sparse Transformer・Longformer・BigBirdの構成

最初期の実装は、見る位置をあらかじめ決め打ちしました。OpenAIのSparse Transformer（arXiv 1904.10509・2019年）は、一定間隔で飛ばすstridedパターンと固定位置を見るfixedパターンを導入し、計算量をO(L√L)へ落としています。Longformer（arXiv 2004.05150・2020年）は局所の窓に加えて、全トークンから参照される少数のグローバルトークンを置きました。BigBird（arXiv 2007.14062・同年）は、窓とグローバルにランダムな参照先を足した3要素の構成です。いずれも系列長に対して線形に近い計算量へ抑えます。実務上の制約は、これらが事前学習の段階で組み込まれる前提の設計であり、既存の密なモデルへ後付けしても精度が戻らない点にあります。

スライディングウィンドウの実装値＝Gemma 3の窓1024と5対1の層配置

現行の公開モデルで最も広く使われているのは、局所の窓を持つ層と全域を見る層を交互に置く構成です。Mistral 7B（2023年）は窓4096のスライディングウィンドウを採用しました。Gemma 2も窓4096でしたが、Gemma 3（2025年3月公開）は窓を1024へ狭め、局所層5層に対して全域層1層という5対1の配置に変えています。位置埋め込みの基底も層で分け、全域層のRoPE baseを1,000,000、局所層を10,000としました。この設計変更が品質へ与えた影響は軽微だと同レポートは報告しています。位置埋め込み側の扱いはRoPEとコンテキスト長拡張の実装判断で詳述しています。

動的選択系＝NSAの3枝構成とDSAのライトニングインデクサ

2025年以降の主流は、クエリごとに見る先をモデルが選ぶ方式です。DeepSeekのNSA（Native Sparse Attention・arXiv 2502.11089、v1が2025年2月16日、v2が同月27日）は、粗く圧縮したトークン・細かく選び直したトークン・局所の窓という3つの経路を束ね、64k長の系列で順伝播・逆伝播・デコードのいずれも密なアテンションより高速化したと報告しています。Moonshot AIのMoBAは、文脈をブロックに割り、ゲート機構でクエリを関連ブロックへ振り分ける設計です。DeepSeek-V3.2のDSA（arXiv 2512.02556）は、少数ヘッドとReLUで構成しFP8でも実装できる軽量な索引器（lightning indexer）で関連度を先に見積もり、上位2048トークンだけに本計算を掛けます。コアのアテンションはO(L²)からO(Lk)へ下がる一方、索引器自体はO(L²)のまま残る点も同論文が明記しています。製品としての実装例はDeepSeek V4のCSA・HCAの仕組みにまとめました。

3系統の計算量・学習の要否・向く場面を実装条件別に一覧比較する

系統ごとの性質を、実装で効く軸だけに絞って並べます。

この表の要点は3列目と4列目です。メモリ容量を減らしたいならウィンドウ方式、長文脈での精度を保ちたいなら動的選択方式となり、両者は競合ではなく併用されます。NSAが局所窓を3経路の1つとして持つのはこのためです。

実装で触る場所｜transformers・FlexAttention・vLLMの設定対応

疎化は論文の図よりも、設定キーとカーネルの対応関係で詰まります。触る箇所は学習側と推論側の2つです。

transformersのsliding_windowとlayer_typesで層切替

Hugging Face Transformers（v5.14系・2026年8月時点）では、ウィンドウ方式の設定は2つのキーに集約されています。sliding_windowが窓の幅で、Gemma3Configでの既定値は4096、Noneを渡すと窓が無効になります。層ごとの割り当てはlayer_typesで、各層のインデックスに全域型か窓型かを明示的に対応づけるリストです。未指定なら他の設定値から自動生成されます。ここで見落としやすいのは、窓の設定を入れてもattn_implementationで選んだカーネルが窓に対応していなければ、実行時には密なアテンションとして走る点です。設定値と実行経路は別に確認します。

FlexAttentionのmask_modとブロック単位のスキップが効く条件

任意の疎パターンを自前で書く場合、PyTorchのFlexAttention（2.5系・2024年10月に導入）が実装の起点になります。マスクの判定関数をmask_modとしてPythonで書くと、torch.compileがそこから疎性の構造を読み取り、融合されたTritonカーネルを生成します。速度が出るのは、判定が全て偽になるブロックを丸ごとスキップできるからです。裏を返せば、ブロックの粒度に満たない散発的な疎性では計算がスキップされず、理論上の削減率が実測に現れません。ブロック境界に揃う疎パターンを設計することが、実装側の前提条件になります。

vLLMの疎対応バックエンドとモデル側の噛み合わせを確認する

推論サーバ側では、疎なアテンションに対応するバックエンドが限られます。vLLM公式ドキュメントのAttention Backend Feature Support（2026年8月3日時点）を見ると、FLASH_ATTN・FLASHINFER・TRITON_ATTN・FLEX_ATTENTIONといった標準バックエンドは、疎（Sparse）列がいずれも非対応です。疎に対応するのはMLA系の派生で、FLASHMLA_SPARSE、FLASH_ATTN_MLA_SPARSE、FLASHINFER_MLA_SPARSEなどが該当します。MiniMax M3の索引器層向けにはブロック疎GQAのMINIMAX_M3_SPARSEが用意され、これはモデル側から直接指定される扱いで自動選択の対象外です。つまり、疎なモデルを持ってきても推論エンジン側のバックエンドが噛み合わなければ効果は出ません。サーバ構成の全体像はvLLMの仕組みと使い方で解説しています。

スパースアテンションを採用してよい3条件と、密なままに留める場面

ここは判断を言い切ります。疎化は「長文を扱うなら入れる」ものではなく、実測に裏づけられた条件を満たしたときだけ入れる改造です。

採用してよい3条件＝入力長・スループット律速・精度許容幅の実測

第1の条件は、本番リクエストの入力トークン数を実測し、中央値が32Kを超えていることです。平均ではなく中央値で見ます。長い入力が少数の外れ値なら、疎化ではなく入力の切り詰めで解決します。第2の条件は、遅延の内訳を測り、プリフィル時間が支配的だと確認できていることです。デコードが律速なら、疎化よりKVキャッシュの量子化やバッチ設計が効きます。第3の条件は、精度の許容幅を自社の評価データで数値化してあることです。疎化は近似であり、無損失ではありません。3条件のいずれかが未測定なら、測るところから始めます。

採用を見送るべき3場面＝短文中心・厳密再現・後付けだけの改造

見送るべき場面も明確です。第1に、入力が4K前後で収まる業務チャットや分類タスク。ここで疎化を入れても速度差は測定誤差に埋もれ、保守対象のカーネルだけが増えます。第2に、監査対応などで出力の厳密な再現性が要る用途。疎化は選択されるトークンが実行条件で揺れうるため、再現性の担保コストが上がります。第3に、既存の密な学習済みモデルへ設定変更だけで疎化を被せようとする場面。DeepSeek-V3.2はV3.1-Terminusのチェックポイントから、本体を凍結して索引器を密なアテンションの出力に合わせる準備段階を挟み、そのうえで継続学習を行っています。学習工程を伴わない後付けは、長文脈での精度低下として跳ね返ります。

長文脈基盤の構築を外部へ委託するとき見積書で確認する技術要件5項目

疎なアテンションを含む推論基盤を外注する場合、見積書で確認すべき項目は次の5つです。

• 採用する疎方式と、その根拠となる入力長の実測データが示されているか
• 推論バックエンドの名称が明記され、モデル側の実装と対応づけられているか
• 疎化前後の精度比較を、自社の評価データで行う工程が含まれているか
• KVキャッシュ容量の見積もりが、方式ごとの差を踏まえて算出されているか
• 索引器や継続学習が必要な方式の場合、その学習コストが分離計上されているか

この5項目が埋まらない見積書は、疎化の効果を検証せずに実装だけを納めるものになりがちです。自社に検証環境がない段階での判断が難しい場合は、機械学習・AI開発の受託で入力長の実測と方式選定から相談できます。

よくある質問

スパースアテンションの導入検討で実際に問い合わせの多い論点を5つ挙げます。

スパースアテンションを使うと精度は必ず下がるのですか？

必ず下がるわけではありません。NSAの論文は、一般ベンチマーク・長文脈タスク・指示追従のいずれでも密なアテンションと同等以上の結果を報告しています。ただしこれは、疎な構造を前提に最初から学習したモデルでの話です。既存の密なモデルへ後から疎化を被せた場合は、長い入力で情報の取りこぼしが起きやすくなります。精度が保たれるかどうかは方式ではなく、学習工程を伴っているかで決まると考えてください。

既存の学習済みモデルに後から疎なアテンションを入れられますか？

技術的には可能ですが、学習工程が要ります。DeepSeek-V3.2はV3.1-Terminusのチェックポイントを起点に、本体を凍結して索引器だけを密なアテンションの出力へ合わせる準備段階を置き、その後に疎な状態での継続学習を行いました。設定ファイルを書き換えるだけで済む改造ではありません。学習リソースを用意できない場合は、最初から疎な構造で公開されているモデルを選ぶほうが現実的です。

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

疎にする対象の層が違います。スパースアテンションはアテンション層で、各クエリが見るトークンを絞ります。MoEはフィードフォワード層で、トークンごとに使うエキスパートを絞る仕組みです。両者は排他ではなく、DeepSeekの各モデルのように同時に採用されます。削減対象も異なり、疎なアテンションは系列長に依存する計算量を、MoEは総パラメータに対する演算量を減らします。詳細はMoEの疎活性化とルーターの仕組みを参照してください。

KVキャッシュはスパース化でどれだけ減りますか？

方式によります。動的選択方式では原則として減りません。どのトークンが選ばれるか事前に確定しないため、全トークン分のKVを保持する必要があるからです。減るのは演算量とメモリ帯域です。一方、スライディングウィンドウ方式は窓の外を破棄できるため容量そのものが減り、Gemma 3のレポートでは32Kトークン時のメモリ増分が60%程度から15%未満へ下がったと示されています。GPUメモリが逼迫している場合は、方式選定の段階でこの違いを見ます。

自社で疎なアテンションのモデルを動かすには何から始めればよいですか？

まず本番相当の入力を集め、トークン数の分布を測るところからです。中央値が32Kを下回るなら、疎化の検討自体を保留してよい段階です。超えている場合は、既存の疎対応モデルをvLLMなどの推論サーバで動かし、疎対応バックエンドが選択されているかログで確認します。自前の疎パターンを書くのは、公開モデルと既製バックエンドの組み合わせで要件を満たせないと確認できてからで間に合います。

関連記事

• Transformerとは？自己注意の仕組みとBERT・GPTの違いを実装目線で解説：疎化する前の密なアテンションの計算過程を扱っています
• RoPEとは？回転位置埋め込みの仕組みとコンテキスト長拡張・実装判断を実装者向けに解説：長文脈を扱うもう一方の軸である位置埋め込みの設計です
• MoE（Mixture of Experts）とは？疎活性化とルーターの仕組み・VRAM要件と採用判断を実装者向けに解説：フィードフォワード層側の疎化との違いが分かります
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説：疎対応バックエンドを選ぶ推論サーバ側の全体像です
• DeepSeek V4とは｜CSA・HCAの仕組みとPro・Flashの性能・料金・移行期限を解説：動的選択方式が製品へ実装された具体例です