AI・信頼性・評価

BeamのスライディングウィンドウアテンションとKVキャッシュの計算方法

2026/10/27 （更新: 2026/11/3）

🤖 AIを使用して執筆

4 枚の B200 に 1M トークンの入力が何本入るか

この増え方は config.json の値だけから計算できる。Reflection が Inferact・NVIDIA と共著した vLLM のブログも、全履歴の KV を持つのは 9 層だけで、1 トークンあたり BF16（bfloat16）で 36 KiB、FP8（8-bit floating point）で 18 KiB だと書く³。1M トークンでは FP8 で約 18 GiB（GPU 間の分割前）になる³。

この量から、GPU の台数の上限が計算できる。重みは NVFP4 で約 280 GB、BF16 で約 1 TB である。B200 は 1 枚 180 GB なので、2 枚（360 GB）でも NVFP4 の重みは収まるが、残りは約 80 GB になる。Hugging Face のブログは、B200 を 4 枚（720 GB）で計画するよう勧める¹。本稿の計算では、720 GB から重みの約 280 GB だけを引くと約 440 GB が残る。36 GiB を GB に換算すると約 38.7 GB なので、1M トークンの入力は上限で 11 本入る。全層が全履歴を持つ場合の 208 GiB（約 223 GB）なら 1 本しか入らない。この上限は重み以外の全てを KV キャッシュに使うと仮定した値で、実際の本数は活性化の分とサーバーの設定によってこれより少なくなる。

この見積もりは、推論サーバーが窓の層の古い key と value を捨てて扱うことを前提にしている。SGLang のブログは、Beam によって推論の仕組みが二つの KV の寿命を扱う必要が生じたと書く。一つはグローバルアテンションの完全な履歴、もう一つは窓の層の直近の窓である⁴。同じ入力の冒頭を再利用して続きを計算するときも、SGLang は両方の状態を揃えて復元する⁴。vLLM も、Beam に初日から対応した実装のブログを同じ日に出した³。

収まることと品質が保たれることは別で、1M の品質は独立した測定がまだ無い

1M トークンの KV キャッシュが GPU に収まることは config.json と Hugging Face のブログの値から確かめられるが、1M で品質が保たれることは確かめられない。グローバルアテンションの層を通って遠いトークンの情報が届く経路があることは、その情報を正しく使えることを保証しない。Beam の品質を示す資料は、公開時の設計の説明と作り手の測定に限られる。

Hugging Face と vLLM のブログは、遠い位置でもアテンションが働くための設計を二つ説明する。一つ目は位置の与え方である。窓の層は、クエリと key の組に位置の差を回転として埋め込む RoPE（Rotary Position Embedding）を使う。Hugging Face のブログは、窓の中では相対的な位置が最も重要なので窓の層に RoPE を使うと説明する¹。グローバルアテンションの層は位置の符号化を持たず、config.json でも RoPE の設定は窓の層だけにあり、グローバルアテンションの層は null である²。

二つ目は、グローバルアテンションの層のクエリに掛ける SSMax（Scalable-Softmax）と呼ばれる倍率である。位置の符号化が無いと、key の数が増えるにつれてアテンションの重みが平坦になる、と vLLM のブログは書く³。これを防ぐために、グローバルアテンションの層は、処理中のトークンの位置を $\mathrm{pos}$ として、クエリに $(1 + (\mathrm{pos} + 1) / 2048)^{0.1}$ を掛ける。この倍率は位置が後ろほど大きい。クエリを大きくすると、アテンションの重みは内積の大きい key に集まる。Hugging Face のブログは、この倍率が温度として働き、コンテキストが伸びても重みが平坦にならないと説明する¹。どちらも設計の理由であり、1M での測定ではない。

作り手の測定も、独立した再現ではない。Hugging Face のブログは、Reflection が提供した長いコンテキストのベンチマークとして、BF16 で LongBench v2 が 67.5%、AA-LCR が 78.2% と載せる¹。Beam の 1M トークンでの検索や推論の品質を第三者が測った評価は、本稿が調べた範囲では、2026年10月23日の時点で見つかっていない。

近い構成の Gemma 3 の技術報告は、perplexity を 512K まで測り、128K までは保たれるが、それより延ばすと急速に悪くなると書く⁵。Google DeepMind が 2025 年に出したこの報告は、長いコンテキストでは推論中の KV キャッシュのメモリが爆発的に増えるという課題を挙げ、その対策として局所層を全体層の間に挟み、局所層の幅を 1024 トークンにした⁵。局所層と全体層の比は、Gemma 3 が 5 対 1、Beam が 43 対 9 で、近い。ただし Gemma 3 の全体層は位置の符号化に RoPE を使い、128K まで延ばすときにその周期を伸ばしている⁵。位置の符号化を持たない Beam の全体層とは長さを延ばす仕組みが違うので、この劣化がそのまま Beam に当てはまるとは言えない。

報告は、局所層と全体層の比を 7 対 1 まで変えても影響は最小だと書くが、その影響は 2B と 9B のモデルの検証セットの perplexity で測られている⁵。perplexity は、モデルが次のトークンを予測する難しさを表す指標で、小さいほど予測が当たる。遠い位置の事実を取り出す力を直接測る指標ではない。遠い位置の事実を取り出す力を測る RULER では、Gemma 3 27B の指示チューニング版が 32K で 91.1、128K で 66.0 に下がる⁵。RULER は、長い入力に埋めた情報をモデルが取り出せるかを測るベンチマークである。報告はこの低下の原因を切り分けておらず、局所層の影響とは言えない。

グローバルアテンションの層の数が同じでも、置く位置で品質が変わるという実験がある。つまり、品質はグローバルアテンションの層の数だけからは予測できない。Databricks Mosaic AI の Rajput らは、窓の層と層をまたぐ KV の共有を組み合わせた構成を比べた。グローバルアテンションの KV キャッシュを最初の層にだけ持つ構成は 32,000 トークンの RULER で成績が悪く、深い層にも持つ構成は成績が良かった⁶。著者らは、少数のグローバルアテンションの層を持つことが長いコンテキストを扱う能力に欠かせないと書く⁶。Beam はグローバルアテンションの層を 6 層ごとと最終層に置くので、深い層にも全履歴を持つ。ただし、この実験は 1 トークンあたり 1.64B のパラメータを使う 24 層のモデルを 32,000 トークンで測ったもので、Beam の 1M での品質を保証しない。

短い長さでの成績から 1M での成績は推せない。26 個のモデルを 8K から 1M で測った ATLAS は、8K から 128K で見た順位と 8K から 1M で見た順位が入れ替わり、7 個のモデルで順位が 2 つ以上変わったことを報告する⁷。窓が 1M に届かないモデルは入力の中央を切り詰めて測られているので、入れ替わりには窓の長さの差も混ざる⁷。ATLAS は査読前の論文で、Beam は対象に入っていない。したがって、Beam の 1M についても、その長さでの独立した測定が要る。

ほかのモデルの KV キャッシュも、同じ数え方で見積もれる。config.json からグローバルアテンションの層の数 $L_\mathrm{global}$、KV ヘッド数 $H_\mathrm{kv}$、ヘッドの次元 $d_\mathrm{head}$ を読み、1 値のバイト数を $b$ とする。窓が埋まった後の 1 トークンあたりの増加は $2 L_\mathrm{global} H_\mathrm{kv} d_\mathrm{head} b$ である。ただし、層によって KV ヘッド数や次元が違うモデルでは、層ごとに数えて足す。品質のほうは、公称の長さでの第三者の測定があるかを別に確かめる。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。