LLMの推論速度を上げる枝刈りは、精度を落とさずに実運用へ載せるのが難しい課題です。Snowflake AI Researchとソウル大学の研究チームが発表したSpenseGPTは、疎行列と密行列の両方を既存ライブラリで処理するハイブリッド形式を使い、ファインチューニングなしのOne-shot枝刈りでB200 GPU上のデコードを最大1.2倍に高速化したと報告しています。
この記事では、SpenseGPTが解決する課題と、Spense形式・SpenseGPT+の仕組み、ベンチマーク結果を整理します。
- 2:4半構造化スパースの精度問題と、既存の緩和手法の限界
- Spense形式がcuSPARSELtとcuBLASをそのまま使える理由
- SpenseGPTとSpenseGPT+の密領域選択戦略の違い
- Qwen3-32B・Seed-OSS-36Bでの精度と速度の実測値
2:4スパースは速いが、50%制約が精度を落とす
半構造化2:4スパース（4つの重みのうち2つをゼロにする形式）は、NVIDIA GPUやAMD GPU、Meta MTIAなど多くのアクセラレータでハードウェア支援があります。理論上は最大2倍の高速化が見込めます。
GEMM（行列積演算）は、ニューラルネットの線形層で入力ベクトルと重み行列を掛け合わせる処理です。2:4形式ではゼロの計算をスキップできるため、GEMMがボトルネックになるLLM推論に向いています。
一方で、4つごとに必ず2つを残すという50%の制約は厳しく、学習なしの事後枝刈り（Post-training Pruning）では推論タスクで精度が大きく落ちます。論文の表2によると、Qwen3-32BでSparseGPTによる50% MLP枝刈りを行うと、AIMEスコアが75.56から68.89へ、平均スコアは71.68から60.27へ下がります。Seed-OSS-36Bでも平均が73.86から65.18に低下しています。
既存の緩和手法は実運用に向かない
50%制約を緩める研究は進んでいますが、論文は既存手法に実用上の壁があると指摘しています。
PATCHはタイル単位で密GEMMと疎GEMMを切り替えますが、専用のTritonコンパイラ対応が必要で、執筆時点ではAmpere GPU向けに限られています。SlideSparseは入力活性化を拡張して(2n-2):2nのスパースパターンを2:4に変換しますが、非GEMMのオーバーヘッドが大きく、25%スパース設定でもB200上のエンドツーエンド速度は最大1.04倍にとどまります。
つまり、精度を守るためにスパース率を下げても、既存手法では推論全体の速度改善に結びつきにくいのが現状です。
Spense形式：疎領域と密領域を1行列に共存させる
Spenseは、重み行列を2:4疎領域と密領域の2つに分割するハイブリッド形式です。密領域の割合をp%とすると、実効的なスパース率は50%未満に緩和されます。
重要なのは、NVIDIA GPUではcuSPARSELt（疎GEMM）とcuBLASLt（密GEMM）といった既存の最適化ライブラリをそのまま使える点です。専用コンパイラも、SlideSparseのような入力活性化の拡張も不要です。
実装には2つのバリアントがあります。Output-splitは出力テンソルを分割し、一方を疎GEMM・他方を密GEMMで計算します。Input-splitは入力を分割し、疎GEMMの結果に密GEMMを加算します。GLU型MLP（ゲート・上投影・下投影の3層構造）では、上投影とゲートにOutput-split、下投影にInput-splitを使い分けます。
SpenseGPT：One-shot枝刈りで疎密領域を決める
SpenseGPTは、SparseGPTをベースにしたOne-shot事後枝刈り手法です。SparseGPTは校正データ上で層の出力再構成誤差を最小化し、ファインチューニングなしで大規模モデルを圧縮します。
SpenseGPTの核心は「どの中間次元を密に残すか」です。GLU型MLPでは中間インデックスを並べ替えても出力は変わらないため、密に残すインデックスを自由に選び、実行時に連続領域へ並べ替えられます。
SpenseGPTの基本戦略は、中間次元の末尾p%を密領域として残し、残りにSparseGPTを適用する方法です。SparseGPTは列を左から右へ処理し、処理済み列の誤差を右側の未処理列で補正するため、密列を右側に置くと補正バッファとして機能します。
SpenseGPT+は、Wanda方式に着想を得た再構成損失の推定スコアで密インデックスを選びます。ゲート・上投影・下投影の3層それぞれの寄与を正規化して合算し、スコアの高いインデックスを密領域に残します。
密インデックスの選び方は精度に直結します。論文の表4では、Qwen3-32Bで同じスパース率でも、SparseGPT基準の選択ではAIMEが8.89、平均27.79に落ちる一方、SpenseGPT+ではAIME 76.67、平均70.76を維持しています。
B200で実測：精度を保ちながら1.2倍のデコード高速化
評価対象はQwen3-32BとSeed-OSS-36Bです。校正にはs1K-1.1から128サンプル（シーケンス長16384）を使用し、AIME・GPQA・IFEval・LiveCodeBenchで性能を測定しました。速度評価はB200 GPU、FP8精度、vLLM、バッチサイズ32、シーケンス長4096の条件です。
25% MLPスパース設定では、Seed-OSS-36BでSpenseGPT+の平均スコアが73.12と、密モデルの73.86にほぼ匹敵します。Qwen3-32BでもSpenseGPT+は平均70.76で、密モデルの71.68に近い値です。厳格な50% 2:4枝刈りと比べ、密領域の導入が推論品質の維持に有効であることが示されています。
速度面では、25%スパース設定でSpenseはエンドツーエンドのデコードを最大1.2倍に高速化しました。論文は、B200の半構造化スパーステンソルコアを使ったOne-shot枝刈りによる実運用レベルのデコード高速化を初めて示したと述べています。SlideSparseが同条件で速度改善に届かなかったのに対し、Spenseは非GEMMオーバーヘッドを抑えつつ疎テンソルコアの恩恵を活かせています。
枝刈り自体のコストも実用的です。B200 1枚で、Qwen3-32BのSpenseGPTは1.33時間、SpenseGPT+は1.87時間。Seed-OSS-36BでもSpenseGPT+が2.15時間で完了し、SparseGPTと同程度の時間です。
開発者にとどう意味するか
SpenseGPTは、LLM推論の高速化が「理論上のGEMM高速化」で終わらず、vLLM上のエンドツーエンドデコードに反映される道筋を示した研究です。既存のcuSPARSELtやcuBLASを活かす設計のため、カスタムコンパイラ開発なしで導入しやすい点も特徴です。
ただし論文は、速度はバッチサイズ・シーケンス長・ハードウェア・精度設定に依存するとも述べています。SpenseGPT+は校正データの分布に基づいて密インデックスを選ぶため、本番環境のデータ分布が大きく異なる場合は再評価が必要です。
半構造化スパースの精度と速度のトレードオフを、疎密ハイブリッド形式で実用的に解く方向性として、今後のLLM最適化研究の参考になるでしょう。