Long Context（長い文脈を一度に扱う能力）は、単に「入力欄へ多くの文字を入れられる」という意味ではありません。長いsequenceを計算できること、各位置を区別できること、KV Cacheを保持できること、そして遠く離れた情報を実際に利用できることが必要です。
context windowの公称値だけを見ると、この違いが隠れます。128K tokenを受け付けるmodelでも、文書のどこにある情報でも同じ精度で使えるとは限りません。また、同じ最大長でも、Attention、位置表現、推論memoryの設計はmodelごとに異なります。
- 3行で分かるLong Context
- context windowとは何か
- Switch Transformerの疎性とは別物
- Long Contextを難しくする5つの壁
- Dense Attentionはなぜ二乗で増えるのか
- Longformerは見る相手を絞る
- Sparse AttentionとFlashAttentionは何が違うのか
- RoPEは位置を回転としてAttentionへ入れる
- Position Interpolationは位置を学習範囲へ圧縮する
- prefillとdecodeでは重い場所が違う
- 128K tokenのKV Cacheを計算する
- 長さの設定だけではLong Contextにならない
- Needleテストだけでは何が足りないのか
- 全文投入、Sparse Attention、RAGをどう選ぶか
- Long Contextを設計・評価するchecklist
- まとめ
- 参考文献
3行で分かるLong Context
- 標準的なDense Attentionはtoken数\(n\)に対して\(n^2\)個の関係を調べるため、長文化すると計算量と中間memoryが急増します。
- LongformerのSparse Attention、RoPE Scaling、FlashAttention、GQA/MQAは別の問題を解きます。どれか一つでLong Contextの全課題が消えるわけではありません。
- 最大context長は「入力可能な上限」、実効context長は「必要な情報を取り出し、推論へ使える長さ」です。長文能力は複数taskで評価する必要があります。
この記事では、Longformer原論文を出発点に、Long Contextを支える仕組みを数式と具体例で分解します。
context windowとは何か
context window（modelが一度の処理で参照できるtoken列の範囲）は、入力だけの枠ではありません。一般的な生成では、system instruction、user input、tool result、会話履歴、生成中のoutputが同じtoken budgetを使います。
たとえば最大長が128K tokenでも、120K tokenの資料を入れた後に必ず8K tokenを生成できるとは限りません。prompt用の固定情報やmodel固有の予約領域も考慮し、入力と出力へ予算を配分します。
ここでは三つの「長さ」を分けます。
| 用語 | 意味 | これだけでは分からないこと |
|---|---|---|
| 最大context長 | interfaceまたはmodel設定が受け付けるtoken上限 | 遠い情報を正しく利用できるか |
| 学習context長 | pretrainingや追加学習でmodelが経験した長さ | 個々のtaskでの実効性能 |
| 実効context長 | task上、必要情報を安定して利用できる範囲 | 別taskでも同じ長さを使えるか |
「投入できた」「errorにならなかった」は、長文を理解できた証明ではありません。検索、複数箇所の照合、集計、推論では必要な能力が異なります。
Switch Transformerの疎性とは別物
前回のSwitch Transformerもsparse（疎）という言葉を使いました。しかし、疎にする軸が違います。
| 手法 | 疎にする軸 | 選ばないもの | 主に変わるcost |
|---|---|---|---|
| Switch / MoE | FFNのExpert | そのtokenで使わないExpert | active parameter、FFN計算、Expert通信 |
| Sparse Attention | token間の接続 | 計算しないquery-key pair | Attention計算とscore領域 |
MoEで1 tokenが1 Expertだけを通っても、その前のAttentionが全token pairを見るなら、Attentionは依然としてdenseです。反対にSparse Attentionを使っても、FFNがDenseなら全tokenが同じFFNを通ります。
Long Contextを難しくする5つの壁
Long Contextは、少なくとも次の5問に分けると整理できます。
- Attention計算：何個のtoken pairを比較するのか
- 位置表現：学習範囲を超える位置をどのように表すのか
- 推論memory：過去tokenのKeyとValueをどれだけ保持するのか
- 学習：長文dataと長い依存関係を十分に経験したか
- 評価：離れた情報を検索するだけでなく、統合して使えるか
解決策も一対一ではありません。たとえばRoPE Scalingは位置表現を拡張しますが、Dense Attentionのpair数もKV Cacheも減らしません。FlashAttentionはmemory trafficを減らしますが、算術上のpair数はdenseのままです。
Dense Attentionはなぜ二乗で増えるのか
Self-Attentionでは、各query tokenが各key tokenとのscoreを計算します。sequence長を\(n\)、head次元を\(d\)とすると、score matrixは\(n\times n\)です。
score要素数は\(n^2\)なので、sequence長を2倍にすると4倍になります。
| sequence長 | 1 head当たりのscore pair数 | 4,096との比 |
|---|---|---|
| 4,096 | 16,777,216 | 1倍 |
| 8,192 | 67,108,864 | 4倍 |
| 16,384 | 268,435,456 | 16倍 |
これは1 layer、1 headのpair数です。実際には複数headと複数layerで計算します。Causal Attention（未来tokenを見ないAttention）では上三角をmaskしますが、一般的なdense実装の計算・storage設計は依然として二乗の影響を強く受けます。
Attention scoreをbf16の2 bytesで単純保持すると、8,192 tokenで約128 MiB/headです。ただし実際のmemory量は実装、softmax用buffer、backward、checkpointing、FlashAttentionの利用で大きく変わります。この値は「素朴にscore matrixをmaterializeした場合」の目安です。
Longformerは見る相手を絞る
Longformerは、すべてのtoken pairを計算せず、二種類の接続を組み合わせます。
- sliding-window attention：各tokenが近傍の一定範囲を見る
- global attention：task上重要な一部tokenが広い範囲と双方向に接続する
各tokenが合計\(w\)個の近傍を見る単純化した場合、local pair数はおよそ\(n w\)です。\(n=8,192\)、\(w=512\)なら次の値になります。
Dense Attentionの\(67,108,864\) pairと比べると16分の1です。境界部分やglobal tokenを無視した教育用の概算ですが、固定windowなら\(n\)を2倍にしてもlocal部分はおよそ2倍で済むことが分かります。
global token数を\(g\)とすると、全体は概念的に次の規模です。
実装ではlocalとglobalの重複や双方向接続をどう数えるかで定数が変わります。重要なのは、\(w\)と\(g\)を\(n\)より十分小さく固定すれば、\(n^2\)ではなく\(n\)にほぼ比例することです。
global tokenは自動的な「重要token」ではない
global attentionは、modelが後から自由に発見する万能枠ではありません。原論文ではtaskに応じてglobal attentionを付ける位置を決めます。分類なら先頭の特別token、question answeringならquestion tokenなど、広域情報を集約・配布すべき場所を設計します。
global tokenを増やせば遠距離接続は増えますが、\(ng\)のcostも増えます。少なすぎれば必要な情報がlocal windowだけでは結び付かず、多すぎればsparsityの利点が弱くなります。
layerを重ねると届く範囲が広がる
1 layerのsliding-window attentionでは、tokenは近傍しか直接見ません。しかしlayerを重ねると、隣から受け取った情報を次のlayerでさらに外へ伝えられます。
各側へ\(r\) tokenを見るなら、単純なreceptive field（出力へ影響できる入力範囲）は\(L\) layer後に概ね各側\(Lr\)まで広がります。ただし「間接的に届く」ことと、「遠い二点を1回のAttentionで直接比較する」ことは同じではありません。長い経路では情報が薄まる可能性があります。
Longformerは長文encoderとして提案・評価されたmodelです。後にLED（Longformer Encoder-Decoder）も示されましたが、現在のdecoder-only chat LLMすべてがLongformerを使うわけではありません。ここで重要なのは、局所接続と少数の広域接続を組み合わせる設計原理です。
Sparse AttentionとFlashAttentionは何が違うのか
名前が似た技術を、解決するcostで比較します。
| 方法 | token pair数 | Attention結果 | 主な狙い | 主なtrade-off |
|---|---|---|---|---|
| Dense Attention | \(O(n^2)\) | 全pairを利用 | 柔軟なtoken間接続 | 長文で計算・memoryが重い |
| Sparse Attention | \(O(nw)\)など | 選んだpairだけ | 算術量と接続数を削減 | pattern外の直接接続を失う |
| FlashAttention | \(O(n^2)\) | exact dense attention | memory trafficと中間storageを削減 | 二乗の演算量自体は残る |
| Context Parallelism | 全体では方式依存 | dense/sparseのまま | sequence方向にdeviceへ分散 | 通信と同期が増える |
FlashAttentionは、Attentionをtileへ分け、HBMとon-chip memory間のdata移動を減らします。全pairを計算するexact attentionなので、「Sparse Attentionの一種」ではありません。詳しい処理はFlashAttentionとは？Attentionを高速化する仕組みで解説しています。
Context Parallelism（sequenceを複数deviceへ分割する並列化）も、1 device当たりのmemoryを減らす有力な方法です。ただし、全体の演算量を自動で消すわけではなく、Attentionに必要なKey/Valueや部分結果をdevice間で通信します。
RoPEは位置を回転としてAttentionへ入れる
Attentionはtokenの集合だけを見れば、順序を区別できません。多くのLLMで使われるRoPE（Rotary Position Embedding：回転による位置埋め込み）は、queryとkeyの2次元成分を位置\(m\)に応じた角度\(m\theta\)で回転します。
位置\(m\)のqueryと位置\(n\)のkeyを回転すると、その内積には回転角の差\((n-m)\theta\)が現れます。
これにより、絶対位置\(m,n\)を使って回転しながら、Attention scoreへ相対的な位置差を反映できます。RoFormer原論文の中心的な性質です。
ただし、学習中に見た最大位置を大きく超えると、未経験の回転patternや相対距離を使うことになります。RoPEを採用しただけで、任意の長さへ品質を保ったまま外挿できるわけではありません。
Position Interpolationは位置を学習範囲へ圧縮する
元の学習context長を\(L\)、拡張後の長さを\(L’=sL\)とします。Position Interpolation（位置補間）は、拡張後のposition \(m\)を、およそ\(m/s\)へ縮小してRoPEへ渡します。
たとえば4,096から32,768へ8倍に拡張するなら、位置32,767は約4,095.9へ写ります。未学習の巨大positionへそのまま外挿する代わりに、学習済みのposition範囲へ押し込みます。
Position Interpolation原論文は、LLaMAを最大32,768 tokenへ拡張し、1,000 step未満のfine-tuningで評価しました。これは同論文のmodelと条件で得られた結果で、任意のmodelを設定変更だけで同じように延長できるという意味ではありません。
補間にもtrade-offがあります。広い位置範囲を狭い角度範囲へ圧縮するため、近いposition同士の角度差も小さくなります。長距離を範囲内へ収める一方、短距離の位置分解能を変えてしまいます。
YaRN（Yet another RoPE extensioN）は、RoPEの周波数帯ごとの扱いとAttentionのscaleを調整し、context拡張を安定させる方法です。重要なのは、RoPE Scalingが位置の写し方を変える技術だということです。
RoPE Scalingだけでは次は変わりません。
- Dense Attentionの\(n^2\) pair
- autoregressive生成で保持するKV Cacheのtoken数
- 長文taskを学習dataで経験したか
- 遠い情報を実際に使えるかという評価結果
prefillとdecodeでは重い場所が違う
LLM推論は大きく二段階に分かれます。
- prefill：入力prompt全体をまとめて処理し、各layerのKey/Valueを作る
- decode：新しいtokenを1個ずつ生成し、過去のKey/Valueを再利用する
長いpromptではprefillのAttention計算が大きくなります。decodeでは1 stepの新しいqueryは1個ですが、過去\(T\) token分のKey/Valueを読みます。生成が進むほどcacheは長くなり、memory bandwidthと容量が効いてきます。
そのため「長文が遅い」という現象も一種類ではありません。
| 症状 | 主な段階 | 関係する要因 |
|---|---|---|
| 最初のtokenが出るまで長い | prefill | 入力長、Attention方式、kernel、並列化 |
| 生成中の1 tokenが遅い | decode | KV読出し量、batch、memory bandwidth |
| 長い入力を載せられない | 両方 | activation、workspace、KV Cache、device memory |
128K tokenのKV Cacheを計算する
KV Cache（過去tokenのKeyとValueを保持する領域）の概算は、batch sizeを1とすると次の式です。
- \(2\)：KeyとValue
- \(L\)：layer数
- \(T\)：cacheするtoken数
- \(H_{KV}\)：Key/Value head数
- \(D_{head}\)：1 headの次元数
- \(b\)：1要素のbyte数
仮に\(L=32\)、\(T=128,000\)、\(H_{KV}=8\)、\(D_{head}=128\)、bf16で\(b=2\)とします。
2進単位へ直すと約15.6 GiBです。これは1 sequenceのKV本体だけの概算です。model weight、activation、temporary buffer、allocatorの余白、padding、metadataは含みません。
同じ構成でMHA（Multi-Head Attention）が32 KV headを持つなら、KV Cacheは4倍の約62.5 GiBです。GQA/MQAは複数のquery headでKey/Value headを共有し、\(H_{KV}\)を減らします。
ここでも解決対象を分けます。
| 方法 | KV Cache容量 | Dense Attention pair数 | 主なtrade-off |
|---|---|---|---|
| GQA / MQA | KV head数に比例して減る | 基本的に変わらない | Key/Value表現の共有が増える |
| KV quantization | 1要素のbyte数を減らす | 変わらない | 量子化誤差と変換cost |
| Paged KV Cache | 断片化と割当効率を改善 | 変わらない | page管理が必要 |
| Sparse Attention | 参照pattern次第 | pair数を減らせる | 接続制約が入る |
KV Cacheの生成と再利用は、KV Cacheとは？LLM推論を高速化する仕組みで詳しく扱っています。
長さの設定だけではLong Contextにならない
model configurationの最大positionを増やし、推論programが長いtensorを受け付けても、それだけでは遠距離依存を学べません。modelは学習dataの長さ分布とtaskから、どの距離の情報をどう使うかを学びます。
たとえば短い文書をpaddingで128Kへ広げても、128K離れた根拠を統合する学習にはなりません。長いsequenceを入れるだけでなく、遠く離れた情報がlossへ影響する学習例が必要です。
また、Lost in the Middleが調べたように、長文の途中にある情報が使いにくい位置依存も起こり得ます。先頭・末尾だけでなく、必要情報の位置を変えて評価することが重要です。これは同論文の対象modelとtaskで観察された傾向であり、すべてのmodelへ同じ形で現れるとは限りません。
Long Contextの準備状況は、少なくとも次の組み合わせで決まります。
位置表現、Attention/KVの実行可能性、長文training、taskに合うevaluationをそろえて初めて、利用可能な長文能力になります。
Needleテストだけでは何が足りないのか
Needle-in-a-Haystackは、長い無関係文の中へ目印となる事実を一つ埋め、modelが取り出せるかを測るtestです。位置ごとのretrieval能力を見るには有用ですが、複数情報の統合までは保証しません。
RULERは、この単純testだけでは不十分だとし、retrieval、multi-hop tracing、aggregation、question answeringの4 category、13 taskを用意しました。
| 評価 | modelが行うこと | 単一needleで代用できない理由 |
|---|---|---|
| Retrieval | 埋め込まれたkey-valueを探す | 基本的な検索能力を測る |
| Multi-hop tracing | 複数箇所の対応を順に辿る | 1箇所を見つけるだけでは解けない |
| Aggregation | 長文中の複数項目を集計する | 全体を漏れなく参照する必要がある |
| Question answering | 文脈から質問へ答える | 言い換え、選択、統合が必要になる |
RULERの2024年時点の評価では、多くの対象modelでcontextが長くなるほど性能が低下しました。ここから得るべき教訓はmodel順位ではなく、公称最大長とtask別の実効context長を分けて測ることです。
実際のsystemでは、自分のdocumentと質問形式で次を変えてtestします。
- 必要情報の位置：先頭、中間、末尾
- 必要情報の個数：1個、複数
- 操作：抽出、照合、順序追跡、集計、要約
- distractor：似ているが誤った情報の量
- output長：短い回答と長い生成
全文投入、Sparse Attention、RAGをどう選ぶか
長い文書を扱う方法は、「modelへ全部入れる」だけではありません。RAGは外部文書を検索し、質問に関係するchunkだけをcontextへ入れます。
| 方法 | 向く状況 | 強み | trade-off |
|---|---|---|---|
| Dense Long Context | 文書全体の関係を柔軟に見たい | retrieval前処理なしで全体を参照 | prefillとKVが重い |
| Sparse Attention | 局所性やglobal tokenを設計できる | pair数を構造的に削減 | pattern外の関係を直接見ない |
| RAG | 大規模・更新頻度の高い知識から関連箇所を探す | contextへ入れる量を絞れる | retrieval missで根拠を失う |
| 要約・階層処理 | 全体傾向や段階的統合が必要 | 各stepのcontextを小さくできる | 要約時に細部を失う |
| Hybrid | 検索後も複数chunkの広い関係が必要 | retrievalとlong contextを補完 | pipelineと評価が複雑 |
全文投入は検索indexを作らず始められますが、同じ長い文書を質問ごとにprefillするとcostが重なります。RAGは入力を絞れますが、検索で落とした情報をgeneratorは利用できません。長いcontextとRAGは競合する二者択一ではなく、検索後の候補を広めに入れる組み合わせもあります。
Long Contextを設計・評価するchecklist
1. 必要長をtokenで測る
文字数ではなく、実際に使うtokenizerでdocument、instruction、想定outputを数えます。日本語、code、表、JSONでは文字数とtoken数の比が異なります。
2. ボトルネックを段階別に測る
- time to first token：prefillの影響
- time per output token：decodeの影響
- peak device memory：weight、activation、KV、workspaceを含む
- end-to-end cost：同じ文書を再利用できるかも含む
3. 数式でmemory上限を先に見積もる
\(L,T,H_{KV},D_{head},b\)をmodel設定から取得し、batch sizeと同時sequence数も掛けます。15.6 GiBという先ほどの値は、batch size 4ならKV本体だけで約62.5 GiBになります。
4. task別に実効長を測る
最大長まで一度通すだけでなく、4K、8K、16Kのように段階を切り、情報位置と必要hop数を変えます。accuracyだけでなく、根拠の引用位置や未回答率も記録します。
5. 品質とcostを同じ表で比較する
低latencyでも回答を誤れば意味がなく、高精度でも運用memoryを超えれば使えません。次のように判断します。
| 確認項目 | 質問 |
|---|---|
| 品質 | 必要情報を抽出・統合できるか |
| latency | prefillとdecodeのどちらが支配的か |
| memory | KV Cacheとweightが同時実行数に収まるか |
| cost | 質問ごとに全文を再処理するか |
| 更新性 | 文書更新時に再学習、再index、再prefillのどれが必要か |
| security | 不要な機密情報までcontextへ入れていないか |
まとめ
Long Contextは、最大positionを増やす一つのtrickではありません。
- Dense Attentionは\(n^2\) pairを持ち、Longformerはlocal windowとglobal tokenで接続を疎にする
- FlashAttentionはexact dense attentionのIOを改善し、Sparse Attentionとは別の軸で効く
- RoPE Scalingは位置の写し方を拡張するが、Attention計算やKV Cacheを減らさない
- decodeではKV Cacheがtoken数、layer数、KV head数、head次元、precisionに比例して増える
- 公称最大長と実効context長は異なり、retrievalだけでなくmulti-hopやaggregationでも評価する
重要なのは、「どの技術が長いか」ではなく、自分のtaskでどの壁が支配的かを切り分けることです。
次回は、Attention自体を別のsequence mixerへ置き換え、長いsequenceを線形時間で扱うことを目指すMamba / SSM（State Space Model：状態を更新しながらsequenceを処理するmodel）を解説します。
参考文献
- Longformer: The Long-Document Transformer
- RoFormer: Enhanced Transformer with Rotary Position Embedding
- Extending Context Window of Large Language Models via Positional Interpolation
- YaRN: Efficient Context Window Extension of Large Language Models
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness
- RULER: What’s the Real Context Size of Your Long-Context Language Models?
- Lost in the Middle: How Language Models Use Long Contexts
コメント