GLM-5.3のスパースアテンションは計算量を削減するが、HBM需要は残る
GLM-5.3のスパースアテンションは、各アテンション演算が読み取るコンテキスト量を減らす。ただし、それだけでモデルのHBM容量問題が解消されるわけではない。9月28日の分析では、関連トークンを選別する際にも、コンテキスト履歴全体へのアクセスが必要になる可能性があると指摘された。この結果は、アテンション対象のトークンが減ればGPUメモリも比例して減る、という一見もっともらしい前提に疑問を投げかける。
この違いは、GLM-5.3がツール呼び出し、ファイル、テスト結果、改訂をまたいでコンテキストが蓄積する、長時間稼働のコーディングやエージェントタスクを対象としているため重要だ。スパースアテンションは、主要なアテンション計算内部の処理量を削減する。一方、以前のトークンから再利用可能なキーと値の表現を保存するKV cacheは、シーケンス全体に応じて増え続ける可能性がある。
DeepSeek Sparse Attentionは、アーキテクチャ上の基準点となる。そのindexerは、モデルが主要なアテンション計算を行う前に、有用なトークンを限定して特定する。GLM-5.3はこの手法に、圧縮されたキャッシュ表現、層をまたぐインデックスの再利用、非アクティブなキャッシュエントリをホストメモリへ移せるサービングソフトウェアを組み合わせている。
したがって、中心となる競争は単なるスパースアテンション対デンスアテンションではない。アルゴリズム上のスパース性と、長い会話を利用可能な状態で維持するという物理的要件のせめぎ合いである。この競争によって、メモリ節約がHBM容量の削減、帯域幅需要の低下、同時実行性の向上、あるいはGPUとシステムメモリの異なるバランスとして現れるかが決まる。
GLM-5.3のスパースアテンションが実際に変えるもの
GLM-5.3はトークン当たりの高コストなアテンション処理量を削減するが、履歴全体から関連情報を見つける手段は依然として必要である。
GLM-5.3は、mixture-of-expertsアーキテクチャを採用するZ.aiのGLM-5ファミリーに属する。mixture-of-expertsモデルは、各トークンに対して総パラメータの一部だけを活性化する。GLM-5 reportによると、このファミリーはルーティングされた計算と、DeepSeekの研究に由来する長コンテキスト向けアテンション設計を組み合わせている。
Z.aiによれば、GLM-5.3はGLM-5.2と同じベースモデルを使用する。報告された能力向上は、ベースモデルの再事前学習ではなく、ポストトレーニングによるものだ。この違いは、現在のメモリに関する議論が、新たに発明されたGLM-5.3のアテンション層ではなく、既存アーキテクチャが実際のサービング負荷でどのように振る舞うかに関するものであることを意味する。
関連する仕組みは、DSAことDeepSeek Sparse Attentionである。スパースアテンションは、過去のすべてのトークンを同じコストで処理するのではなく、選択された過去トークンの部分集合に完全なアテンションを限定する。DeepSeekは、この本番環境を意識した設計をV3.2 researchで導入した。
DSAはまず、lightning indexerと呼ばれる軽量コンポーネントを実行する。indexerは過去の位置をスコアリングし、現在のクエリに最も関連性が高いと判断された限定集合、すなわちtop-kトークンを選ぶ。続く主要なMulti-Head Latent Attention計算は、選択された位置で実行される。
MLAことMulti-Head Latent Attentionは、アテンションヘッドごとに完全なキーおよび値ベクトルを別々に保存する代わりに、圧縮された潜在表現を保存する。この圧縮により、トークンごとに保存するキャッシュ量が削減される。その後のスパース選択により、主要なアテンション演算が読み取るキャッシュ量も減る。
これらは異なる2種類の節約である。MLAは各トークンのキャッシュ状態のサイズを対象とし、DSAは高コストなアテンション計算で消費されるキャッシュ位置の数を対象とする。
この組み合わせにより、計算量と帯域幅のプロファイルは大きく変わる。中核となるアテンションは、コンテキスト全体にわたる関係の処理から、固定されたtop-k選択の処理へ移行できる。シーケンス長が長くなるほど、これは主要なアテンション負荷の増大を抑える。
ただし、lightning indexerは、保持された履歴全体で候補をスコアリングするために、十分な情報を必要とする。サービングシステムがあるトークンの利用可能な表現をすべて破棄していれば、モデルはその古いトークンを選択できない。
SemiAnalysis examinationは、これを決定的な制約として挙げている。スパースアテンションは、中核となるscaled dot-product attention演算中のメモリトラフィックを削減する。しかし、選択可能なコンテキストを保持するために必要な総メモリ容量を必ずしも削減するわけではない。
この制約は、スパース化の閾値を下回る場面でより明確になる。SemiAnalysisが取り上げた構成では、DSAは2,048位置のtop-k設定を使用する。これより少ない位置しかないシーケンスには削減対象となるより大きなプールがないため、アテンションはデンスのままとなる。
サービングエンジンも、シーケンス長やデプロイメントトポロジーに応じて異なる実行モードを選択する。実装は短いコンテキストでは低計算量モードを優先し、メモリトラフィックが支配的になるにつれて低メモリモードへ移行する場合がある。したがって、スパースアテンションはすべてのリクエストに対して一定の高速化をもたらすものではない。
意味のある変化は、より限定的でありながら有用だ。GLM-5.3のスパースアテンションは、長い履歴を参照し続けるための反復コストを削減する。履歴そのものを不要にするわけではない。
アテンショントラフィックの低下がHBM容量の低下を意味しない理由
HBMへの圧力は保持されたコンテキストから生じる一方、スパースアテンションが主に変えるのは、GPUが各演算で読み取る保持済みエントリである。
HBMことhigh-bandwidth memoryは、アクセラレータに直接接続された高速メモリである。その帯域幅はGPUによる大規模行列演算の実行を支える一方、限られた容量は各デバイスに収容できるモデル数とアクティブなリクエスト数を制約する。
自己回帰生成では、モデルはトークンを1つずつ生成する。KV cacheを通じて、以前のトークン向けに計算したキーと値を再利用する。このキャッシュがなければ、サーバーはそれまでのシーケンス全体を繰り返し再計算する必要がある。
そのため、アクティブな各リクエストはコンテキスト用のメモリを確保する。長時間のコーディングセッションには、リポジトリ内のファイル、コマンド出力、パッチの試行、テストログ、過去の推論が含まれる場合がある。エージェントは通常の質疑応答よりはるかに多くのトークンを生成しうる。
スパースアテンションは読み取りパターンを変える。過去のすべての位置を主要なアテンション演算へロードする代わりに、モデルは選択されたtop-k集合をロードする。これにより、メモリ帯域幅の消費と、選択後に行われる計算量を削減できる。
容量には別の原則が働く。過去のある位置が選択候補として残る限り、その表現はどこかでアクセス可能な状態を維持しなければならない。従来のサービング設計では、主要なアテンションカーネルがごく一部しか読み取らない場合でも、KV履歴全体をHBMに保持する。
その結果、システムは計算能力がボトルネックになる前に容量制約に直面する可能性がある。各リクエストが実行するアテンション処理は減っても、コンテキスト長に比例するメモリを依然として占有する。同時実行性を高めれば、同じデバイスにより多くの完全な履歴が配置される。
これが、スパースアテンションがHBM需要の同等な削減に直接つながらない理由である。システムはアクティブなトラフィックを節約する一方、常駐状態を必ずしも減らさない。各アテンションステップが選択的であっても、モデルの履歴に対する論理的な見方は完全なままである。
この違いは、高速な検索システムを備えた大規模アーカイブに似ている。検索が高速になれば、各質問で読む文書数は減る。しかし、古い文書が別の場所へ移されるか消滅しない限り、アーカイブ自体は縮小しない。
GLM-5.3のKV cache圧縮は依然として重要である。トークン当たりの表現が小さくなれば、所定のメモリ予算により多くのコンテキストを収容できる。また、選択されたエントリがアテンション演算に入る際に転送されるバイト数も減る。
ただし、圧縮された状態もシーケンス長とともに蓄積し続ける。より小さい線形メモリ曲線も、なお線形メモリ曲線である。長いコンテキストと多数の同時リクエストは、最終的に節約した容量を消費しうる。
同時実行性は、このトレードオフをすぐに明らかにする。SemiAnalysisは、同時リクエスト数を8から16に増やすと、GPUメモリからのプロンプトトークン再利用が低下した結果を報告した。GPU再利用率は90.3%から54.8%へ下がった。
同じ比較で、ホストメモリからの再利用率は6.0%から40.3%へ上昇した。報告されたすべての同時実行レベルで、合計キャッシュヒット率は95%を上回った。これらの結果は、有用なキャッシュ容量をアクセラレータの外へ拡張できることを示している。
ただし、ホストメモリがHBMと同等のレイテンシを持つことを意味するわけではない。CPU-GPU間でデータを移動するとI/Oコストが発生し、キャッシュミスは本来効率的なデコードパスを中断しうる。サービングシステムは、転送が生成時間を支配しないように、データを予測、取得、退避しなければならない。
メモリ市場への影響も、単純な需要減少よりはるかに複雑である。スパースアテンションは、アテンションステップ当たりのHBMトラフィックを減らせる。一方、低コスト化した長コンテキスト推論は、より長いセッションと高いリクエスト同時実行性を促す可能性がある。
このリバウンドは、インフラ計画において重要である。各リクエストの処理コストが下がると、事業者はより多くの同時作業を受け入れることが多い。節約されたメモリ帯域幅は、未使用のハードウェアではなく追加スループットに変わりうる。
したがって、アテンションがより選択的になっても、HBM需要は持続しうる。完全な履歴がより大きく低速なメモリ階層へ移るため、ホストDRAM需要も増加しうる。さらに大規模になると、ストレージシステムが再利用可能なプレフィックスや非アクティブなキャッシュデータを受け持つ場合がある。
実務上の問いは、もはやスパースアテンションが抽象的にメモリを節約するかどうかではない。GLM-5.3のKV cacheの各部分をどのメモリ階層が保持し、サービングエンジンがどの頻度で移動させるかである。
HiSparseは完全な履歴をGPUの外へ移す
HiSparseは、論理的なキャッシュ可用性と物理的なGPU常駐を分離することで、スパースアテンションの選択的読み取りを実際のHBM容量節約へ変える。
SGLangチームは、スパースアテンション向けサービングの階層型KV cacheとしてHiSparseを設計した。GPUには小さなワーキングセットを保持し、KV履歴全体はピン留めされたホストメモリに保存する。ピン留めメモリとは、アクセラレータへの予測可能な転送に備えたCPUメモリである。
この設計の下では、古いキャッシュエントリはGLM-5.3から見て論理的に利用可能な状態を維持する。だが、それらすべてがHBMに物理的に常駐するわけではない。indexerがある位置を選択した際、GPUにその位置がなければ、サービングシステムが取得できる。
HiSparseは、デバイスキャッシュにleast-recently-usedポリシーを用いる。選択されたトークンがHBMに存在しない場合、システムはホストメモリからそれらをロードする。GPUのワーキングセットを制限された範囲に保つため、最近使用されていないエントリを退避させる。
このアーキテクチャは、モデルレベルの特性をシステムレベルの節約へ変換する。スパースアテンションは、現在の演算に必要な小規模集合を特定する。HiSparseは、デコード中にHBMを占有する必要があるのが、限定された選択対象とワーキングバッファだけになるようにする。
HiSparse paperは、このシステムを正確かつindexer非依存と説明している。正確とは、モデルが選択したアテンション出力を意図的に近似することなく、キャッシュ配置を変更することを意味する。indexer非依存とは、メモリマネージャーが単一の選択アルゴリズムに依存しないことを意味する。
評価では、H200、B200、GH200プラットフォーム上で、DSA、Native Sparse Attention、Questを対象としている。著者らは、長コンテキストのワークロードでピーク生成スループットが最大4.7倍向上したと報告している。
これは、検証された構成におけるシステム上の結果であり、GLM-5.3の速度が必ず4.7倍になることを保証するものではない。ワークロード長、リクエスト同時実行性、インターコネクト帯域幅、選択の局所性、キャッシュミス率はすべて結果に影響する。
HiSparseは、転送と有用な計算も重ね合わせる。あるレイヤーの実行中に、システムは後続レイヤー向けに選択されたキャッシュエントリを準備できる。このレイヤー単位の重複によって、ホストからデバイスへの移動で生じるレイテンシの一部を隠蔽する。
レイヤー間の再利用により、このスケジューリングは容易になる。隣接するレイヤーが同じ位置を多く選択する場合、システムはキャッシュ需要の見込みを事前に把握できる。あるレイヤーのために取得したエントリは、後続レイヤーでも引き続き有用であり得る。
残るコストはI/Oだ。選択時のミスでは、データをCPUメモリからHBMへ移動する必要がある。ミスの頻発、分散した選択、あるいは限られたホスト・デバイス間帯域幅は、スループット向上の一部を打ち消し得る。
このリスクは、理論上のスパース性と本番環境での効率を分ける。スパースカーネルは、エントリが到着した後に読む量を減らせる。しかしシステム全体としては、対象エントリの発見、転送、利用可能なページへのマッピング、ライフサイクルの調整を依然として行わなければならない。
最初のトークンが返るまでの時間も、別の制約となる。初期プロンプトを処理するプリフィルは、トークンごとのデコードとは性質が異なる。HiSparseが主に対象とするのは、キャッシュがすでに存在し、生成の継続に伴って増大するデコード側である。
SGLangの実装では、HiSparseをプリフィル・デコード分離と組み合わせている。このアーキテクチャでは、プロンプト処理とトークン生成を別々のワーカーに割り当てる。これにより各フェーズは、そのワークロードに適したメモリレイアウトとハードウェア割り当てを利用できる。
この設計はインフラ需要も変える。HBMはアクティブな会話の唯一の保存先ではなく、ホットキャッシュとなる。より大きな履歴はホストDRAMに保持され、インターコネクトがクリティカルパスの一部となる。
これにより、各デコードリクエストに必要なHBM容量を減らせる可能性がある。会話を表現するバイト数そのものがなくなるわけではない。多くを別の場所に移し、適切なサブセットをGPU近くに維持するためのソフトウェアを追加するのである。
したがって運用者にとって重要な指標は、モデルサイズや最大コンテキスト長だけではない。現実的な同時実行数における、リクエスト当たりのHBMフットプリント、ホストメモリ割り当て、ミス率、転送量、出力トークンのレイテンシを把握する必要がある。
スパースアテンションは、この階層型設計を可能にする。HiSparseはそれを運用可能にする。どちらもメモリ管理を無料にするものではない。
IndexShareが関連トークンを見つけるコストを削減する
フルアテンションがスパース化されると、インデクサー自体が目立つボトルネックになる。そのためGLMの次の最適化では、レイヤー間で選択判断を再利用する。
標準的なDSAレイヤーには、それぞれ独自のlightning indexerがある。このコンポーネントは、メインのアテンション計算がtop-kセットを選択する前に、過去のトークンをスコアリングする。インデクサーはフルアテンションより軽量だが、それでもコンテキストを調べる必要がある。
コンテキストが長くなるにつれ、すべてのレイヤーで過去の各位置を繰り返しスコアリングするコストは大きくなる。メインアテンション経路が削減されることで、かつては小さく見えた処理が総レイテンシに占める割合を増す。
Z.aiはこの問題に、IndexCacheとしても公開されているIndexShareで対処する。各スパースアテンションレイヤーで独立したインデクサーを実行する代わりに、レイヤー群が共有の選択結果を再利用する。
このアプローチは、隣接するレイヤーが同じ過去トークンの多くを選ぶことが多いという観測パターンに基づく。IndexCache studyは、その分析において隣接レイヤーのtop-k選択間に70～100パーセントの重複があると報告している。
この重複は冗長性を生む。指定されたフルレイヤーがインデックスを計算し、後続の共有レイヤーが選択位置を再利用できる。GLM向けに議論されている本番パターンでは、4つのDSAレイヤーのグループに1つのインデクサーを割り当てる。
300億パラメータのDSAモデルで、研究者らは報告上ほとんど品質を低下させずに、インデクサー計算を最大75パーセント削減した。標準DSA比で、プリフィルは最大1.82倍、デコードは最大1.48倍高速化したと測定している。
論文では、予備的な本番規模のGLM-5結果も報告している。これらの結果は仕組みを支持するが、GLM-5.3のワークロードやサービングスタック全体にわたる幅広い独立検証の代わりにはならない。
選択の再利用には、独自の学習要件も生じる。共有インデクサーは、単一レイヤーのアテンション分布に一致するだけでなく、複数レイヤーに役立つトークンを特定しなければならない。IndexCacheは、保持されるインデクサーを、それらが支援するアテンション分布の平均に対して学習させる。
この調整が重要なのは、連続するレイヤーは関連していても同一ではないためだ。初期レイヤーは語彙的な詳細を優先する一方、後続レイヤーは中間処理で形成された依存関係を重視する可能性がある。グループ内の一員だけに必要なトークンを除外すれば、再利用は有害になる。
この手法は、第二のトレードオフを浮き彫りにする。共有を増やせば、追加のインデクサー処理を削減できる。共有を減らせば、よりレイヤー固有の選択挙動を維持できる。
IndexShareはHiSparseとも相互に作用する。レイヤーがインデックスを共有する場合、サービングエンジンはそれらのレイヤー間で取得済みのキャッシュエントリを再利用できる。共有選択はtop-k計算の繰り返しを減らし、ホストからデバイスへのフェッチをより予測可能にできる。
この組み合わせは、3つの異なるコストに対処する。
MLAは、各トークンについて保存される表現を圧縮する。
DSAは、フルアテンションを選択された過去の位置に限定する。
IndexShareは、各レイヤーで類似した選択を再計算することを避ける。
HiSparseは、非アクティブなKVエントリをHBMからホストメモリへ移動する。
これらの要素を、単一のメモリに関する主張へとまとめるべきではない。圧縮はトークン当たりのバイト数に影響する。スパースアテンションはアクティブな読み出しに影響する。インデックス共有は選択のオーバーヘッドに影響する。オフロードは物理的な配置に影響する。
最適化の各層は、ボトルネックを別の場所へ移し得る。より小さなキャッシュは計算オーバーヘッドを顕在化させる。安価になったメインアテンションはインデクサーのレイテンシを顕在化させる。オフロードは転送帯域幅を顕在化させる。より高い同時実行性はホストメモリ容量を顕在化させる。
どのボトルネックが最初に現れるかは、ハードウェア特性によって決まる。SemiAnalysisは、GLMのアテンション構成がDeepSeekのH800向けバランスとは異なることを示唆する演算強度プロファイルを推定した。また、GLMの設計を中国のアクセラレータベンダーMoore Threadsによるサポートと結び付けた。
このハードウェア解釈は、Z.aiが開示した設計目標ではなく、依然として推論にとどまる。GLM-5.3は複数のサービングフレームワークとアクセラレータプラットフォームをサポートしているため、運用者は自身のデプロイ経路でモデルを測定すべきだ。
より広い教訓は、GLM-5.3のスパースアテンションを単一のFLOP数で評価できないということだ。サービング性能は、インデクサー、圧縮キャッシュ、メモリ階層、カーネル、ワークロードの総合的な挙動から生まれる。
真の試験は本番環境におけるメモリ効率
GLM-5.3がそのメモリ設計を実証できるのは、運用者が許容できないコストをレイテンシ、DRAM、運用の複雑さへ転嫁せずに、長時間のエージェントセッションを維持できる場合に限られる。
最初に注目すべきシグナルは、長いコンテキストと高い同時実行性のもとで行われる独立したGLM-5.3ベンチマークである。単一リクエストのピーク速度だけでは、多数の永続的エージェントを処理するサービスについて分かることはほとんどない。テストでは、HBM使用量、ホストDRAM使用量、キャッシュミス、レイテンシ分布をまとめて報告すべきだ。
説得力のある結果は、GLM-5.3のKVキャッシュオフロードが、トークン当たりのレイテンシを安定させながら、より多くの同時リクエストを受け入れられることを示すだろう。大きなレイテンシスパイクを受け入れた場合にのみスループットが上がるなら、そのメモリ節約は対話型コーディングエージェントにとって限定的な価値しか持たない。
二つ目のシグナルは、HiSparseや類似のメモリマネージャーに対するより広範なデプロイ支援である。SGLangはHiSparseを統合しており、vLLMもこのアーキテクチャに関する取り組みを文書化している。エンジン間で一貫した挙動が得られれば、スパースモデルが本番環境でHBM常駐量を制限できるという主張はより強まる。
断片的なカーネルサポートは、その主張を弱める。スパースアテンションは、特殊な選択、ページ管理、キャッシュ形式、アテンションカーネルに依存する。モデルはオープンウェイトであっても、狭いソフトウェアスタックの外では効率的なサービングが難しいままであり得る。
三つ目のシグナルは、長期にわたるエージェント品質に関する証拠である。メモリ最適化に意味があるのは、モデルが以前の要件、コード上の判断、ツール結果を確実に取り出せる場合だけだ。セッションの後半で現れる選択エラーは、診断が難しい場合がある。
GLM-5.3のポストトレーニング戦略は、この点を特に重要にする。Z.aiは、同社の内部Z.ai Code Benchにおいて、モデルのコーディング能力がGLM-5.2に比べて50パーセント向上したとしている。これは依然として企業が報告した比較である。
Z.aiはまた、CyberGymで84.5パーセントを達成したと報告しており、GLM-5.2の77.2パーセントと比較している。CyberGymは、モデルがソースコードからソフトウェア脆弱性を発見し、検証できるかを測定する。GLM-5.3 releaseは、これらの向上を、より強力なエージェント機能とサイバーセキュリティ能力の証拠として提示している。
こうした能力は、有用性とリスクの双方を高める。より長いツール駆動型セッションは、リポジトリ分析、テスト、脆弱性調査を支援できる。同じ持続性が、エクスプロイト手順の自動化や、機密情報をサービングキャッシュ内に保持することにも役立ち得る。
その結果、メモリ配置にはセキュリティ上の側面もある。ホストDRAM、共有プレフィックスキャッシュ、分散キャッシュレイヤーは、会話状態が存在し得る場所を拡大する。運用者は、すべての階層にわたり、分離、退避、アクセス制御、可観測性を確保する必要がある。
モデルのSingle-Rollout Asynchronous Optimizationの取り組みは、この文脈に属する。ただし、推論メモリを直接削減するものではない。SAOは、プロンプト当たり1つのロールアウトで学習し、別の価値モデルを用いてトークンレベルのリターンを推定する。
SAO paperによると、この手法は非同期エージェント学習における不安定性とオフポリシー効果に対処する。これはGLM-5.2のエージェント学習パイプラインに導入され、GLM-5.3に至るポストトレーニングの系譜にも影響している。
SAOは、長く不均一なエージェント軌跡に対する学習効率を改善できる。一方で、価値モデルがポリシーモデルと並行して実行されるため、追加の学習オーバーヘッドも伴う。これは、別の場所でコストを受け入れることで一つのボトルネックを削減する、もう一つの例である。
エンタープライズチームにとって、当面の課題は規律ある評価だ。同一のワークロードにおいて、完全なプロンプト、選択されたコンテキスト、キャッシュ配置、ミス挙動、出力レイテンシ、タスク成功を追跡する必要がある。トークン毎秒の集計値は、多くのことを隠してしまう。
チームには、モデル構成とサービング実験に関する永続的な記録も必要だ。searchable knowledge baseは、ベンチマーク結果をカーネルバージョン、キャッシュ設定、デプロイ障害と結び付けられる。
GLM-5.3のスパースアテンションは、長いコンテキストを読む際の経済性を変える。それらを保持する必要性をなくすわけではない。このアーキテクチャはアクティブなアテンション通信量を減らし、IndexShareは選択のオーバーヘッドを低減し、HiSparseはGPU常駐量を制限する。
次のベンチマークの波に向けた問いは具体的だ。GLM-5.3は、ボトルネックをホスト転送や取得品質へ移すことなく、これらの節約を持続的な同時実行性へ転換できるのか。測定されたHBM占有率、キャッシュミス時のレイテンシ、長時間エージェントの精度に注目すべきである。これらのシグナルを合わせることで、スパースアテンションが単体でより優れたカーネルではなく、より優れたサービングシステムを実現するかどうかが分かる。
