NInfer-3090、ReplaySSMで投機的デコーディングの状態コストを削減――RTX 3090でQwen3.8-27Bの並行実行が可能に

NInfer-3090 v0.6は、もともと次世代GPU向けに設計された専用C++20／CUDA推論エンジンを、RTX 3090の`sm_86`へ移植し、Qwen3.8-27Bを最優先の対応モデルに位置付けた。中核となる新機能はReplaySSMだ。MTPによる投機的デコーディング中、ハイブリッドモデルの再帰状態をコミットまたはロールバック可能なトランザクションとして扱い、並行シーケンスごとに完全な一時状態を複数保持する必要をなくす。INT8 KV、paged KV、CUDA Graph、固定cohortと組み合わせることで、24GBのVRAM内で8件のリクエストが3 tokenのMTPドラフトを引き続き利用でき、状態の肥大化を理由に投機的デコーディングを無効化せずに済むとプロジェクトは主張している。

作者が公開した継続テストでは、各リクエストに1,024 tokenを生成させた。単一リクエストのエンドツーエンド・スループットは70.19 token／秒、平均TTFTは149ミリ秒だった。8並列では合計161.28 token／秒、デコードのみで165.33 token／秒に達し、ピークVRAM使用量は22,138 MiBだった。一方、MTP受理率は単一リクエスト時の61.13%から、8並列時には56.84%へ低下した。これは、リクエスト単位の待ち時間と引き換えに、主として全体スループットを高める構成であることを示している。8並列時の平均TTFTは1.215秒まで増加した。エンジンはOpenAI Chat Completions、Responses、Anthropic互換インターフェースも提供し、互換性のあるプロンプトプレフィックスを再利用できる。

モデルファイルはGGUFでもTransformers checkpointでもなく、量子化済みテキスト重み、ビジョンエンコーダー、MTP、proposal headを収録した16.96 GiBの専用`.ninfer`コンテナである。そのため、デプロイは特定のruntime revisionに結び付けられる。さらに重要なのは、公開ベンチマークが約29～34個の入力tokenと、8K／16Kの共有KV poolを使用している点だ。測定対象は短いprefillと長いdecodeの組み合わせであり、数万tokenのrepository contextを扱うコーディングエージェントの性能を直接推定することはできない。Linuxについても、現時点で完了しているのはコンパイルと起動の確認だけで、実モデルでの性能はまだ検証されていない。今後は、独立した再現検証、長いプロンプトでのTTFT、そして受理率が低い場合やツール呼び出しが頻発する場合でもReplaySSMがメモリを節約できるかどうかを確認する必要がある。