ReplaySSMとは？Nemotron・Qwenサーバーの生成を速くする仕組み

SSM層は新しいトークンを処理すると、過去の状態へ情報を反映します。同時リクエストが増えると、会話ごとの状態を読み書きする量も増えます。ReplaySSMは基準状態のcheckpoint²を持ち、最近の入力を小さなbufferへためます。両方から出力を計算し、bufferがいっぱいになると入力をまとめてcheckpointへ反映します。

NemotronやQwenのハイブリッドモデルにはSSMとattention³が共存します。ReplaySSMが減らすのはSSM状態の読み書きです。重みの量子化⁴と併用できますが、ファイル容量を減らす設定は別に選びます。

MTP⁵や別のdrafterが複数候補を出すと、本モデルは先頭から採用できる部分を決めます。残りを捨てた後は会話の状態も採用トークンへ合わせます。ReplaySSMは最近の入力bufferの末尾を調整して採用部分だけを残し、候補ごとに大きな状態のコピーを保存する負担を減らします。

これはエンジン内部の状態計算と保存を変える最適化です。LiLiCorrは採用されやすい候補を作る側を改善します。候補の採用長と状態検証のコストを分けて記録すると、どの変更が役立ったか分かりやすくなります。

NVIDIAとPrincetonの研究者はMamba-2とGDNを使う4モデルをvLLMで比較しました。表はspeculative加速なしの通常decode⁶です。kernel単体とdecodeステップ全体の改善を分けて読むと、サーバーでの効果を把握しやすくなります。

4BはH100×1、120B級はB300×1・tensor並列なし・FP32⁷ SSM状態・window L=16・tuned vLLM基準

公開実験の通常decodeではBatch 1で速度向上がなく、Batch 256で改善がありました。個人PCでは1リクエストのTTFT⁸と生成速度を先に測ります。チームのサーバーでは実際の同時数を再現し、各要求の遅延と総処理量を比べます。

ReplaySSMはTensorRT-LLM・vLLM・FlashInferに統合されています。使用版が対象モデルのSSM処理に対応するか調べ、テストサーバーで始めます。モデル、入出力長、状態精度、drafterの設定を固定して現在のエンジンを記録し、変更後に同じ要求でTTFT、完了時間、最大メモリ、失敗回数を比較します。

個人PCの高速化なら、まず対応するMTP・DFlashや効率的な量子化を比べてください。複数エージェントが使うサーバーではReplaySSMも候補にし、混雑時の要求がどれだけ早く終わるかまで確認してから移行します。