GLM の100万トークン文脈ウィンドウを解説

長文脈の素朴な問題はアテンションコストが二次で増えることであり、スパースアテンションは原理的にこれを解決します。各トークンが過去のすべてではなく選ばれた部分集合にだけ注意を向けるからです。ただしスパースアテンションにはインデクサ（どのトークンに注意すべきかを決める軽量な仕組み）が必要で、それを全層で走らせると、文脈長とともに増えるコストが再び生じます。200,000トークンではこのオーバーヘッドは許容範囲ですが、100万では許容できません。

第2の問題は、数十万トークンを超えるとボトルネックが計算ではまったくなくなることです。KV-cache の容量、長文脈カーネルの効率、CPU 側のオーバーヘッド、つまり数学ではなくメモリとシステムの問題になります。アーキテクチャ上は百万トークンのウィンドウに対応できても、キャッシュが収まらなかったりスケジューラが詰まったりすれば、配信できません。

IndexShare がそのアーキテクチャ上の答えです。transformer の全層がそれぞれ top-k インデックスを計算するのではなく、4層ごとに軽量なインデクサを1つ共有します。インデクサは4層の最初に置かれ、その top-k インデックスを残り3層が再利用するため、4層のうち3層からインデクサの内積計算と top-k 選択が取り除かれます。

公表された結果は、100万トークン文脈でのトークンあたりFLOPsが2.9分の1になり、長距離での品質低下は報告されていない、というものです。IndexShare は推論時に後付けされたのではなく、中間学習以降、系列長128K で使われました。これは重要な点です。配信時にだけ導入した共有方式は、学習時の挙動と実行時の挙動の間に不整合を生むからです。