NVIDIAとプリンストン大Dao AI Lab、ハイブリッドモデルの推論を速める「ReplaySSM（リプレイSSM）」を公開SSMカーネル1.46〜1.80倍、投機的デコードはvLLM比1.85〜2.10倍

NVIDIAとプリンストン大学のDao AI Labは2026年10月12日（米国時間）、Mamba系などSSM層を含む「ハイブリッドモデル」のデコードを速める手法 ReplaySSM（リプレイSSM）を、論文とコード付きで公開した。NVIDIAの技術ブログ（日本時間では10月13日午前1時ごろの公開）によると、H100とNVIDIA Blackwell Ultra B300で動かした4モデルでSSMカーネルが1.46〜1.80倍（バッチサイズ256）、B300で動かした120B級2モデルの投機的デコードのスループットがvLLMの投機的デコードの1.85倍と2.10倍になった。論文はarXivに10月9日付で投稿されている。

3行まとめ

1. NVIDIAとプリンストン大Dao AI Labが、SSMの状態を「チェックポイント＋直近入力のバッファ」で持つReplaySSMを公開（2026年10月12日・米国時間）。論文はarXiv 2610.13778、コードはGitHub。
2. NVIDIAの検証（バッチサイズ256）でSSMカーネル1.46〜1.80倍、デコード1ステップ全体は1.20〜1.47倍。120B級2モデルの投機的デコードは、バッチサイズ512でvLLMの1.85倍と2.10倍。
3. NVIDIAはTensorRT-LLM・vLLM・FlashInferへの統合とGLM-5.3-Flash・Kimi-K3での本番利用を説明。一方GitHubのREADMEでは、vLLM本家にマージ済みなのはMamba2の標準デコードのみ。

本記事の内容は、日本時間10月13日1時台に公式ページで確認したものです。

ReplaySSMは何をする手法か

ハイブリッドモデルは、SSM層（状態空間モデルの層）と少数のアテンション層を交互に重ねたモデルだ。NVIDIAの技術ブログは、NVIDIA Nemotron（ネモトロン）3、Qwen3.5からQwen3.8、Kimi-K3、GLM-5.3-Flash がこの作りで、SSM層にはMamba-2、Gated DeltaNet（GDN）、Kimi Delta Attention（KDA）が使われていると書いている。

SSM層は、文脈の長さに応じて増えるKVキャッシュの代わりに固定サイズの「状態」を持つ。この状態のせいで、バッチサイズの大きい実運用ではアテンションよりSSM層のほうが遅延の主因になりうる、とブログは言う。ブログによると、Nemotron-3-Super-NVFP4をB300 1基・バッチサイズ256で動かした場合、文脈100Kトークンまでは SSM層がデコード1ステップで最大の部分を占めた。

従来のデコードは、1ステップごとに状態を読み出して更新し、書き戻す。ReplaySSMはこれを次のように変える（NVIDIAの説明）。

• 状態を「チェックポイント」と「直近の入力の小さなバッファ」で表す
• 大半のステップでは、入力をバッファに足して、チェックポイントとバッファから出力だけを計算する（状態は書かない）
• バッファがL件たまったときだけ、入力をチェックポイントに畳み込み、HBM（高帯域メモリ）に1回書いてバッファを空にする

ブログによると、出力は浮動小数点の誤差を除けば従来のデコードと一致する。

何がどれだけ速くなったのか

NVIDIAは、Nemotron 3（Mamba-2層）とQwen3.5（GDN層）の2系列から4モデルを選び、vLLMで実装して、チューニング済みのvLLM自身のカーネルと比べている。

性能テストはSSM状態をFP32のまま、窓の長さL=16で行ったとブログは書いている。NVIDIAが挙げる効果は3つある。

1. 状態のメモリ通信が約半分になる

窓L個のトークンのあいだ、従来方式は状態をL回読んでL回書く。ReplaySSMは読みは毎回行うが、書くのは1回だけだ。NVIDIAの説明では、これで支配的な状態のメモリ通信がおよそ半分になる。

バッチサイズ256では、カーネルが1.46〜1.80倍、デコード1ステップ全体が4モデルで1.20〜1.47倍になった。一方、バッチサイズ1では他の遅延要因が支配的で、「これらのテストでは速くならなかった」とブログは書いている。

2. 投機的デコードのやり直し（ロールバック）が軽くなる

投機的デコードは、ドラフトモデルが提案したT個のトークンをまとめて検証し、受理された所まで戻る方式だ。アテンションならKVキャッシュのポインタを動かせば戻れるが、SSMは状態に畳み込んだ後の更新を簡単に元に戻せない。ブログは、vLLMなどでは各ドラフトトークンの後に状態のスナップショットを保存する回避策が使われ、これがGPUメモリを圧迫して同時処理数の上限になると説明している。

ReplaySSMではドラフトの入力をバッファに足すだけで、受理分だけバッファのポインタを進める。スナップショットも、戻すべき状態もない。ブログのGSM8Kプロンプトでの測定（T=4、L=16、FP32状態、モデルごとにB300 1基）では、バッチサイズ512でvLLMの投機的デコードの1.85倍と2.10倍のスループットになり、受理長（acceptance length）は一致していたという。

3. 低精度の状態でも誤差がたまりにくい

SSMでは、量子化した状態が次の更新の入力にもなるため、丸め誤差が再帰のたびに入り込む。ReplaySSMは、再帰に使う高精度のチェックポイントと、出力の読み出し用の低精度コピーを分けて持つ。低精度コピーは再帰には戻されないので、その誤差は現在の窓の出力にしか影響しない、とブログは説明している。

ブログの測定では、Mamba-2でNVFP4の状態を読む非フラッシュのカーネルは、FP32の状態を読む場合の3.8倍速かった。精度面では、Qwen3.5-4Bで128Kトークン生成時のKLダイバージェンスが、NVFP4読み出し＋FP32再帰で0.136から0.0038に下がったと書かれている。GPQA-Diamondでの変化は次のとおり（FP32との差、ポイント）。

ブログは、4モデル中3モデルがFP32から約2ポイント以内に収まったとまとめている。Nemotron-3-Nano-4Bは分離しても5.6〜6.7ポイント下がっており、すべてのモデルで差が消えるわけではない。

誰がいつから使えるのか

コードはGitHub（Johnny-Liou/ReplaySSM）で公開されていて、ライセンスはApache-2.0と表示されている。リポジトリはvLLMのフォークで、Mamba2とGDNの標準デコードおよび投機的デコードの実装と、低精度のカーネルを含む。vLLMの統合では、標準デコードに --use-replayssm、投機的デコードに --use-replayssm-spec を使い、窓の長さは --replayssm-buffer-len 16 で指定するとREADMEに書かれている。

NVIDIAの技術ブログは、ReplaySSMがTensorRT-LLM、vLLM、SGLang、FlashInferに組み込まれ、GLM-5.3-Flashは ReplaySSMを使って提供されていると説明している。Z.aiのインフラ報告がKDAデコードカーネルへの追加を述べていること、Kimi-K3がKDA層でドラフトの入力をキャッシュして検証に使い、ReplaySSMを「並行する手法」として引用していることも、同じ節に書かれている。

日本での提供や料金について、今回取得したページには記載がない。コードとフレームワークの変更はオープンソースの形で公開されている。

一人称の観測：公開直後のブログとGitHubで食い違っていた点

日本時間10月13日1時台に公式ブログ、arXiv、GitHub、Tri Daoのブログ、TensorRT-LLMのPRの5ページを続けて取得して読んだが、ここで見つかった食い違いが3つある。製品を動かして確かめたものではなく、取得したページの文面を突き合わせた結果だ。

1. 論文リンク: ブログの「Get started」の節では、論文の項目が「ReplaySSM: Cache SSM Inputs, Not State [TODO: Link]」という未記入のプレースホルダーのままだった。ただし同じページの別の位置にはarXivへのリンクがあり、そのarXivページ（2610.13778）は取得できた。
2. vLLMへの統合状況: ブログは「vLLMに統合」と書く。GitHubのREADMEは、vLLM本家にマージ済みなのはMamba2の標準デコードのカーネルだけで、他の3つのデコード経路（GDN標準、Mamba2・GDNの投機的）は「このフォークにしかない」と書き、READMEの表でもvLLMの #48792・#49847・#49887 は open と表示されていた。ブログが挙げるvLLMのPR（48018、52506、52928）のうち、READMEの表に載るのは48018（merged）だけで、52506と52928の状態は今回確認していない。
3. 投機的デコードの倍率: ブログは1.85倍と2.10倍、arXivのアブストラクトは「120B級2モデルでvLLMの投機的デコードの約1.8倍のスループット」と書く。Tri Daoのブログは、標準デコードで最大1.48倍、投機的デコードで「vLLMの標準デコード比」1.87〜1.96倍と書く。比べる相手がvLLMの投機的デコードではなく標準デコードで、Nemotron-3-Ultra-550B（B300 2基、TP2）を含む別の構成の数字だ。

Tri Daoのブログの数字は比べる相手と構成が違うことがページ上に書かれているが、NVIDIAのブログ（1.85倍・2.10倍）とarXivのアブストラクト（約1.8倍）の差の理由はどちらのページにも書かれていない。本記事では推測せず、各ページの数字を出どころ付きで並べている。

数字を読むときの注意

• 速度の数字はすべてNVIDIAと論文著者らによる測定で、本記事では再現していない。比較対象は「チューニング済みのvLLM自身のカーネル」で、他の実装（TensorRT-LLMやFlashInferの既存カーネルなど）との直接比較は、今回読んだブログの本文には見当たらなかった。
• バッチサイズ1では速くならないとブログ自身が書いている。効果が出るのは、大きいバッチで動かすサービング用途だ。
• 速くなるのはSSM部分だけで、アテンションやGEMMは変わらない。Tri Daoのブログも、エンドツーエンドの伸びがカーネルより小さいのはそのためだと説明している。
• 評価した4モデルは、Nemotron 3とQwen3.5の2系列だけだ（Tri Daoのブログには550Bの結果もある）。GLM-5.3-FlashやKimi-K3での速度の数字は、今回読んだページには見当たらなかった。
• NVIDIAの技術ブログの冒頭の要約は、ページ自身が「AIによる要約」と注記している。本記事では本文側の数字を使った。

同じ日のNVIDIAの発表では、Vera Rubin（ベラ・ルービン）のラック設計をOCPに提供した件も出ている。こちらはハードウェア側の話で、ReplaySSMはソフトウェア（カーネル）側の話だ。

出典と確認時刻

• NVIDIA Technical Blog「ReplaySSM: Rethinking State Storage for Faster Hybrid-Model Decoding」（2026年10月12日付）: https://developer.nvidia.com/blog/replayssm-rethinking-state-storage-for-faster-hybrid-model-decoding/ （日本時間10月13日1時06分ごろ確認）
• arXiv:2610.13778「ReplaySSM: Cache SSM Inputs, Not State」（2026年10月9日投稿）: https://arxiv.org/abs/2610.13778 （同1時06分ごろ）
• GitHub Johnny-Liou/ReplaySSM: https://github.com/Johnny-Liou/ReplaySSM （同1時06分ごろ）
• Dao AI Labブログ: https://tridao.me/blog/2026/replayssm/ （同1時06分ごろ）
• NVIDIA/TensorRT-LLM PR #14203: https://github.com/NVIDIA/TensorRT-LLM/pull/14203 （同1時06分ごろ。ページ上の表示は Merged）

本記事は続報があり次第更新します。