SGLangのRadixAttentionは、2枚のRTX 3090を搭載した構成において、ウォームアップ時のTime-to-First-Token（TTFT）を68msまで短縮しました。一方、vLLMのPagedAttentionは184msにとどまり、その**82.9%**ものレイテンシの差が、マルチターンのエージェント対話において顕著なスムーズさの違いを生んでいます。
両プロジェクトとも大規模言語モデル（LLM）の推論高速化を目指していますが、今回のベンチマークが対象としたのは、自律型アシスタントを支えるワークロード、すなわち長いシステムプロンプト、ツール呼び出し（tool-calling）のスキーマ、そしてユーザーとアシスタントのやり取りが積み重なる履歴です。これらの繰り返されるトークンはGPUメモリ内に保持されますが、キャッシュが効率的に管理されていないと、計算のボトルネックとなり会話を停滞させてしまいます。
勝敗を分けたワークロード
従来のLLMサーバーは、ユーザーのプロンプト、モデルの回答、終了、という単発のやり取りに最適化されています。しかし、現代のエージェントは数十ターンに及ぶ「会話状態」を保持し、各ターンで数百ものトークンがキャッシュに追加されます。テストスイートでは、2枚のRTX 3090を使用してこのようなマルチターンのループを再現し、以下の指標を測定しました。
- ウォームアップ時のTime-to-First-Token (TTFT) – 新しいターンが始まってから最初のトークンが表示されるまでの遅延。
- 全体的なレイテンシ – ループ全体を通じたトークンあたりの平均時間。
- 持続的なスループット – ループが継続的に実行されている際の、1秒あたりの処理トークン数。
- キャッシュヒット率 – 再計算される代わりに、Key-Value (KV) キャッシュから再利用されたトークンの割合。
SGLangはすべての指標でvLLMを上回りました。TTFTは68ms対184ms、レイテンシは**82.9%削減、スループットは39.8%向上、そしてキャッシュヒット率はvLLMの84.2%**に対し、**96.8%**を記録しました。
PagedAttention vs RadixAttention
両エンジンとも中間的なKVペアをGPUメモリに保存しますが、そのメモリの構成方法は異なります。
- PagedAttention (vLLM) は、キャッシュを固定サイズのブロックに分割します。プロンプトがブロックの途中で終わる場合、ブロックの一部だけを再利用することはできないため、末尾のトークンはターンごとに再計算する必要があります。この手法はシンプルであり、プロンプトがブロックの境界と一致する場合は有効ですが、エージェントのループ内で最も頻繁に変化する「エッジ」部分のトークンに対して計算リソースを浪費してしまいます。
- RadixAttention (SGLang) は、キャッシュをツリー構造として扱います。ブロックの制限に関係なく、現在のプロンプトと既にキャッシュされている内容との間で最長共通接頭辞（longest common prefix）を見つけ出し、使用されていないリーフ（葉）を削除します。これにより、巨大なシステムプロンプトをGPUメモリに固定したまま、最新のターンのみを処理することが可能になり、キャッシュヒット率の向上と冗長な計算の削減を実現しています。
各エンジンの得意分野
| シナリオ | 推奨エンジン |
|---|---|
| マルチターンの自律型エージェント、頻繁なツール呼び出し、Tree-of-Thought推論 | SGLang (RadixAttention) |
| 幅広いハードウェアサポート（AMDやGaudiアクセラレータを含む）、投機的デコーディング（speculative decoding）、視覚言語モデル（VLM） | vLLM (PagedAttention) |
この違いはパフォーマンスだけではなく、エコシステムにも及びます。vLLMはハードウェアの互換性が広いため、異種混合の計算クラスターを持つ組織にとっては、より安全なデフォルトの選択肢となります。また、複数のトークン候補を並列に生成する「投機的デコーディング」機能は、単発の生成を加速させることができます。これは、RadixAttentionのツリーベースのキャッシュがそれほど優位性を発揮できない領域です。
結論
長いプロンプトや逐次的な更新を扱うマルチターンエージェントを構築する開発者にとって、SGLangのRadixAttentionは、コンシューマー向けGPUにおいて著しく高速でキャッシュ効率の高い体験を提供します。一方で、幅広いハードウェアへの対応が必要なチームや、単発の生成を専門とするチームは、引き続きvLLMを利用することになるでしょう。今後の選択は、ワークロードが「エージェント重視」か、それとも「ハードウェアの多様性重視」かによって決まります。