最大40%高速化を実現するキャッシュ対応プリフィル・デコード分離（CPD）
Together AIは、キャッシュヒット率に基づいて「ウォーム」と「コールド」リクエストを分離するCPDアーキテクチャを開発し、長期コンテキスト推論におけるスループットを最大40%向上させ、TTFTを大幅に削減した。
キーポイント
CPDアーキテクチャの概要
Together AIが実装したCache-aware prefill–decode disaggregation (CPD)は、キャッシュヒット率に応じて「コールド」（新規コンテキスト）と「ウォーム」リクエストを分離し、分散KVキャッシュを活用することで高速なコンテキスト再利用を実現する。
既存技術の限界と課題
従来のPrefix cachingやPrefill-decode disaggregation (PD)は有用だが、高負荷環境下ではコールドリクエストがウォームリクエストのキューを占有し、TTFTの変動性を引き起こす問題があった。
実証されたパフォーマンス向上
この分離アプローチにより、特に混合された現実的なトラフィック下において、持続可能なスループットが最大40%向上し、最初のトークン生成までの時間（TTFT）が大幅に短縮された。
影響分析・編集コメントを表示
影響分析
この技術は、LLMサービングの効率化において「キャッシュ再利用」を単なる最適化ではなく、アーキテクチャレベルでのリソース分離という重要なパラダイムシフトをもたらす。特に、大規模なコンテキストを扱う実務環境では、TTFTの安定性とスループットの向上がサービス品質に直結するため、インフラストラクチャ設計における新たな標準となり得る。
編集コメント
既存のプリフィックスキャッシングやPD分離手法をさらに一歩進め、リクエストの性質（キャッシュ状態）に応じた動的なリソース割り当てを実現した点は評価できる。これにより、混在するワークロード下での予測可能なパフォーマンス保証が可能になる。
要約
長いプロンプトの処理が遅い応答を意味する必要はありません。Together AI では、キャッシュヒット率によってコールドとワームのワークロードを意図的に分離するサービングアーキテクチャであるキャッシュアウェアプリフィル–デコードディスアグリゲーション（CPD）を開発しました。これにより高速なコンテキストの再利用が可能になります。重いプリフィル処理を隔離し、分散 KV キャッシュを活用することで、CPD は長文コンテキスト推論において持続可能なスループットを最大 40% 向上させ、特に混合された実世界のトラフィック下で最初のトークンまでの時間（TTFT）を大幅に短縮します。
今日の AI ネイティブアプリケーションは、コンテキスト長を新たな限界まで押し上げています。多ターン会話やコーディングコパイロット、エージェントメモリ、検索拡張システムなどから、長いプロンプトが標準になりつつあります。しかし、これらの大規模なコンテキストを効率的にサービングすることは依然として課題です。TTFT が上昇し、より変動しやすくなります。推論性能は、モデルの計算能力だけでなく、システムがいかに効率的に共有コンテキストを処理するかによってますます決定されます。実世界のワークロードでは、多くのリクエストが完全に新規ではありません。一部のリクエストには、以前に見たことのあるコンテキストの大きな部分が含まれています。例えば、共有されたシステムプロンプト、会話履歴、または一般的なドキュメントなどです。これらをワームリクエストと呼びます。一方、主に新しいコンテキストを導入し、完全な計算を必要とするものはコールドリクエストです。
プレフィックスキャッシングやプリフェル–デコード分離（PD）といった最近の進展は、すでに長文コンテキストのサービス向上に貢献しています。プレフィックスキャッシングは、プロンプトプレフィックスの計算済み KV キャッシュを再利用することで冗長な作業を削減し、一方 PD は計算集約型のプリフェル段階とレイテンシ敏感なデコード段階を分離して、両者の間の干渉を軽減します。これらにチャンクプリフェルやシーケンス/コンテキスト並列化などの関連技術を加えることで、全体としてオーバーヘッドを低減し、ハードウェアの利用率を向上させることができます。
しかし、非常に高い負荷下での実世界のワークロードは、一般的なサービスシナリオを超えた新たな課題を提示します。一部の同時利用者が 10 万トークンを超える大規模で完全に新しいプロンプトを送信する一方で、他のユーザーは以前のコンテキストを主に再利用する多ターン会話を継続しているシステムを想定してください。PD はデコードがプリフェルによってブロックされないように保証しますが、すべてのプリフェル（コールドおよびウォームの両方）は依然として同じプリフェル容量を共有します。大規模なコールドプロンプトは数秒単位でリソースを占有し、キャッシュ再利用を通じて迅速に処理できたはずのウォームリクエストが、同じキューで待たされることになります。その結果、TTFT（Time To First Token）が増加するのは、これらのリクエスト自体が重い計算を必要とするからではなく、それらのリクエストの背後にある重い計算を行うリクエストによって待ち行列に詰まっているからです。
このギャップを埋めるために、私たちはキャッシュ認識型分離サービスアーキテクチャを構築しました。これは、ウォームリクエストとコールドリクエストを別々の計算リソースで処理するものです。各リクエストが再利用可能なコンテキストをどの程度含んでいるかを特定することで、システムはより賢いスケジューリング判断を下すことができます。これにより、不要な待ち時間が削減され、計算リソース間での作業ルーティングがより効果的に行われます。
高価なコールドプリフィルスが共有キャパシティを支配してしまうのを防ぐ代わりに、システムはウォームリクエストに対して高速パスを整備しつつ、新しいコンテキストも効率的に処理します。
その結果、キャッシュ認識型分離設計により、システムは負荷下でより滑らかにスケーリング可能になります。図 1 に示すように、テール感応型の SLA（サービスレベルアグリーメント）の下でも、従来のベースラインと比較して常に高い達成可能なスループットを維持します。
私たちの評価では、CPD は既存の分離設計と比較して持続可能な QPS を最大で35–40%向上させつつ、大規模なコールドプロンプトが存在する場合でもより厳しいテールレイテンシバウンドを維持しています。
Figure 1. レイテンシ SLO における最大達成 QPS。
CPD の仕組み
我々は、キャッシュ認識型プリフェッチ・デコード分離（CPD）を提案します。これは、標準的なプリフェッチ・デコード分離サービングにキャッシュ認識ルーティングと共有 KV キャッシュ階層を追加したものです。その核心となる考え方はシンプルです：高価な「コールド」プリフェッチが、再利用可能なコンテキストに対する高速パスをブロックしないようにします。
本システムは推論を 3 つの役割に分離しています：
- プリプリフェッチノード：低再利用（コールド）プロンプトを処理し、新しいコンテキストを計算して KV キャッシュを分散キャッシュへ書き込みます。
- プリフェッチノード：高再利用（ウォーム）リクエストを優先し、プレフィックスの再計算ではなくキャッシュから KV ブロックを読み取ります。
- デコードノード：レイテンシに焦点を合わせ、プリフェッチによる干渉から隔離されます。
プリフェッチとデコードはすでに分離されていますが、CPD はキャッシュ再利用がほとんどない、あるいは全くないリクエストを処理する専用のプリプリフェッチ階層を追加します。これらのノードは大規模な新しいコンテキストを計算し、その KV キャッシュを分散キャッシュへ書き込みます。一方、通常のプリフェッチノードは既存の状態を再利用できるリクエストに集中し、再計算ではなくキャッシュから KV ブロックを読み取ります。デコードノードは隔離され、レイテンシに焦点を合わせたままです。
内部では、CPD は図 2 に示されるような3 レベルの KV キャッシュ階層に依存しています。最速のレイヤーは GPU メモリにあり、次いでホスト DRAM（主記憶装置）、そして RDMA を介して接続されたクラスター全体の分散キャッシュが続きます。プリプレフィルノードでコールドリクエストが処理されると、その KV 状態は分散キャッシュへ書き込まれます。その後、類似のリクエストが発生すると、この状態を高速帯域で一括取得できるため、本来であれば数秒かかる計算プロセスが、数百ミリ秒の転送と軽微な再計算に短縮されます。時間の経過とともに、頻繁にアクセスされるコンテキストは自然と GPU に近づき、レイテンシがさらに削減されていきます。
図 2 システム概要
この仕組みを統合するのがルーターです。各リクエストに対して、どの程度のプロンプト部分をキャッシュから提供できるかを推定します。再利用率が低いリクエストはプリプレフィルノードへ誘導され、再利用率が高いリクエストは通常のプレフィルノードへ直接送られます。このワークロード分離により、大きなコールドプリフィルが共有計算リソースを飽和させるのを防ぎつつ、システムが新しいコンテキストを取り込みキャッシュを継続的に温めることを可能にします。その結果、混合されたバースト性の高い長文コンテキストの負荷下であっても、高速パスを常に高速に維持するサービングスタックを実現しています。
繰り返しリクエスト間で何が起こるか
CPD の利点は、同じまたは類似の長いコンテキストが複数回出現する際に明確になります。これはコパイロット、エージェント、多段階チャットシナリオで一般的です。各リクエストは、重計算バウンドからプリフィックスキャッシュの再利用へとワークロードをさらに移行させます。
図 3. 3 つのリクエストパターン。
リクエスト 1 — コールド（ブートストラップ）
大きなコンテキストが初めて出現する際、それはコールドとして分類されます。ルーターはこれをプリプリフィルノードに送信し、完全なプリフィル計算を実行します。同時に、生成された KV キャッシュ（Key-Value Cache）は分散キャッシュへ書き込まれます。
このリクエストでは完全な計算コストが発生しますが、新しいコンテキストを再利用可能な状態に変換することで、システムを*予備的に準備（プライム）*します。
リクエスト 2 — ウォーム（分散キャッシュの再利用）
同じコンテキストが再度出現すると、ルーターはこれをウォームとして識別します。プリフィックスの再計算を行わずに、通常のプリフィルノードが RDMA を介して分散キャッシュから KV ブロックを取得し、GPU メモリへロードします。
これにより、数秒間の計算処理が高帯域幅転送と軽量な処理に置き換わります。レイテンシが劇的に低下する一方、GPU の計算負荷も減少します。
リクエスト 3 — ウォーム（ローカル再利用）
コンテキストが同じノード上でアクティブな状態を維持している場合、その KV 状態はすでに GPU またはホストメモリ上に存在しています。分散キャッシュ転送は不要であり、システムはローカルキャッシュを直接再利用します。
この時点で、プリフィルのオーバーヘッドは最小限となり、レイテンシはさらに短縮されます。もともと数秒の計算時間を要していた 100K トークンのコンテキストが、今度は数百ミリ秒で処理可能になります。さらに CPD はプレフィックスの再利用だけでなく、重い計算処理を再利用に依存するトラフィックから分離することで、コールドワークロードが共有リソースを支配することを防ぎながら、システムが長文コンテキスト推論をスケーリングできるようにします。
評価
私たちは、実世界の負荷下における長文コンテキストサービングシステムにとって重要な 2 つの補完的な次元に沿って CPD を評価します：
- 負荷増加に伴うレイテンシとスループットの拡張 — ターゲット QPS が上昇するにつれて、TTFT（p50 および p90）および GPU 単体あたりのスループットがどのように変化するか。
- 競合下での有効なサービング容量 — プリフィル側の飽和が急速なレイテンシの増大を招く前に、システムが維持できる GPU 単体あたりの持続可能な QPS の量。
私たちは、従来の PD ベースのデプロイメントと CPD を比較し、キャッシュ認識型分離が混合されたウォームおよびコールドワークロードの下で、飽和挙動やレイテンシをどのように再形成するかに焦点を当てます。
- 2P1D/2P2D（ベースライン）：2 つのプレフィルノードと 1 つまたは 2 つのデコードノードを使用し、すべてのリクエストが同じプレフィル容量を共有する標準的な PD ルーティングを採用します。
- CPD-1D/2D：ウォームおよびコールドリクエストを区別する CPD 対応ルーターによって調整されるキャッシュ認識パイプラインで、専用の事前プレフィル層、通常のプレフィル層、そして 1 つまたは 2 つのデコードノードから構成されます。
すべての実験は NVIDIA B200 GPUs上で行われます。各プレフィルステージでは、ノードあたり 4 台の B200 GPU にわたってテンソル並列化（tensor parallelism）が使用され、一方、デコードステージでは、4 台の B200 GPU にわたるアテンションシャードイング（attention sharding）を伴うデータ並列化（data parallelism）が採用されます。現実的な admission control を反映し、無制限なテール増幅を避けるため、同時実行中のリクエスト数の最大値を 24 に制限します。
各ターゲット QPS に対して、システムは 30 秒かけてトラフィックを増加させ、その後 600 秒にわたって定常状態の負荷を維持します。QPS は 0.4 から 1.6 の範囲で 0.2 刻みでスウィープし、軽負荷から飽和に至るまでのシステム挙動を捉えます。
ワークロード構成
現実的な長文コンテキスト推論ワークロードを反映するため、大規模な共有コンテキストと多ターン対話を特徴とするコーディングエージェントシナリオに基づいたベンチマークを設計しました。このワークロードは、エージェントが複数のターンにわたって膨大なコードベースのコンテキストを維持し、ファイルの読み込み、依存関係の分析、変更の実装、修正の反復といった AI 支援ソフトウェア開発環境を模倣するものです。CPD のスケジューリング決定を負荷する、ウォームおよびコールドプレフィルリクエストが現実的に混合された合成データを使用します。
結果
図 4 は、システム負荷が増加するにつれて、CPD がレイテンシのスケーリング挙動とサービングキャパシティの両方をどのように再構築するかを統合的に示しています。
図 4. ターゲット QPS（秒間クエリ数）の増加に伴う、2P1D/2P2D と CPD のパフォーマンス比較。
飽和挙動
ターゲット QPS が増加すると、プリフェル（事前生成）キャパシティが主要なボトルネックとなる時点で、両システムは振る舞いを分けます。2P1D ベースラインはより早期に飽和し、達成される QPS は GPU あたり約 0.75–0.8 で頭打ちとなり、その後キューイング遅延が急激に増大します。一方、CPD は同じワークロード下で GPU あたり約 1.1–1.15 QPS までスケーリングし続けるため、飽和状態に入る前に持続可能なスループットが約 40% 増加 していることが示されます。
この飽和点の右方へのシフトは、図 4（左下）のスループット曲線と整合しており、負荷が増加する中で CPD がより高い有効なプリフェルスループットを維持していることを裏付けています。冷たいプリフェル処理をキャッシュを活用した温かいリクエストから分離することで、CPD は長時間実行される冷たいプロンプトが共有のプリフェルキャパシティを独占することを防ぎ、システムが高負荷下でも効率的に動作できるようにします。
負荷時のレイテンシ
軽負荷時、2P1D と CPD の間の中央値 TTFT（p50）は同等であり、混雑していない状態では CPD が追加のオーバーヘッドを導入しないことを示しています。しかし、QPS がベースラインの飽和点に向かって増加すると、振る舞いは劇的に分岐します。
2P1D において、TTFT p50 は 1 秒を超えて急激に上昇し、すぐに数秒の領域に入り込みます。これは、大規模なコールドプリフィル実行の背後でのキューイングを反映しています。一方、CPD ははるかに緩やかな増加を示します：ベースラインがすでに飽和しているターゲット QPS レベルにおいても、CPD はサブ秒から低秒帯域の中央値 TTFTを維持します（図 4 左上参照）。この改善は、ワークロードの分離に直接起因するものです。キャッシュされたコンテキストを再利用するウォームリクエストが、高コストなコールドプリフィル実行の背後で待たされる必要がなくなったためです。
テールレイテンシ（TTFT p90）は、より微妙なパターンを示します。中程度の負荷下では、両システムとも同様の p90 挙動を示します。負荷がさらに増加すると、両設計の p90 TTFT は上昇しますが、CPD は評価範囲全体を通じて一貫してベースライン以下または同等にとどまります（図 4 右上参照）。重要なのは、CPD が中央値レイテンシで大幅な改善を達成しながらも、不釣り合いなテール増幅を導入しないことです。コールドトラフィックのバーストによりプリフィル段階内でのキューイングが増加する可能性は依然としてありますが、その影響は主に抑制され、予測可能なテール挙動が維持されます。
スループット効率
図 4 のスループット内訳は、これらの改善の根本原因を浮き彫りにしています。CPD は高い QPS（1 秒間のクエリ数）においても GPU あたりのプリフィルスループットを高く維持する一方、ベースラインではプリフィルスループットが頭打ちとなり、キューイングが激化すると低下します。生成スループットは両システム間で概ね同等であり、観測された性能差の主な要因はデコード側の最適化ではなく、より効率的なプリフィルスケジューリングによるものであることを示しています。
主要結果と考察
図 4 は、CPD が混合されたウォームワークロードとコールドワークロードの下での長文コンテキストサービングの動作点をシフトさせることを示しています。デコード容量を 1D から 2D に増やすことで、ベースラインおよび CPD の両構成において全体スループットが向上し、飽和が遅延します。これは、デコード側の並列処理がより高いサービング容量に寄与することを裏付けています。
重要なのは、CPD がデコード容量をスケールした場合でも一貫した改善を提供し続ける点です。1D および 2D の両設定において、CPD は対応するベースラインと比較して、GPU あたりの有効な QPS を高く維持し、中央値の TTFT（First Token Time: 最初のトークンまでの時間）の上昇がより緩やかであることが示されています。さらに、CPD は同等かそれ以上のデコードスループットを維持しており、その恩恵はプリフィルの分離に限定されず、エンドツーエンドのパイプライン利用効率の高さにも及んでいることを示しています。
これらの改善は、モデルの実行速度そのものによるものではなく、prefill パスにおけるキャッシュ認識型の分離によって実現されています。長時間かかるコールドプリフィルが、キャッシュに依存するウォームリクエストをブロックすることを防ぐことで、CPD は高負荷下でも再利用のための高速パスを維持します。これは、コンテキストウィンドウが大きくなるにつれて、モデルやハードウェアの効率性と同様に、システムレベルのスケジューリングと再利用を意識した設計が推論性能における主要な要因となることを示しています。
8S
DeepSeek R1
ネイティブオーディオと生々しい物理挙動を備えた、プレミアムなシネマティックビデオ生成。
DeepSeek R1
8S
オーディオ名
オーディオ説明
0:00
ネイティブオーディオと生々しい物理挙動を備えた、プレミアムなシネマティックビデオ生成。
8S
DeepSeek R1
ネイティブオーディオと生々しい物理挙動を備えた、プレミアムなシネマティックビデオ生成。
パフォーマンスとスケーラビリティ
本文コピーはここに lorem ipsum dolor sit amet
- 箇条書き項目はここに lorem ipsum
- 箇条書き項目はここに lorem ipsum
- 箇条書き項目はここに lorem ipsum
インフラストラクチャ
最適な用途
- より高速な処理速度（全体的なクエリレイテンシの低減）と運用コストの削減
- 明確に定義された単純なタスクの実行
- 関数呼び出し、JSON モード、または他の構造化されたタスク
リスト項目 #1
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
リスト項目 #1
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
ビルド
含まれる特典:
- ✔ プラットフォーム無料クレジット最大 15,000 ドル*
- ✔ フォワードデプロイエンジニアリング時間無償 3 時間。
資金調達：500 万ドル未満
ビルド
含まれる特典:
- ✔ プラットフォーム無料クレジット最大 15,000 ドル*
- ✔ フォワードデプロイエンジニアリング時間無償 3 時間。
資金調達：500 万ドル未満
ビルド
含まれる特典:
- ✔ プラットフォーム無料クレジット最大 15,000 ドル*
- ✔ フォワードデプロイエンジニアリング時間無償 3 時間。
資金調達：500 万ドル未満
ナタリアは 4 月に友人 48 人にクリップを売り、5 月にはその半分の数を売りました。ナタリアが 4 月と 5 月に合計で何個のクリップを売ったでしょうか？
XX
タイトル
本文コピーはここに lorem ipsum dolor sit amet
XX
タイトル
本文コピーはここに lorem ipsum dolor sit amet
XX
タイトル
本文コピーはここに lorem ipsum dolor sit amet
8S
DeepSeek R1
ネイティブオーディオと生々しい物理挙動を備えた、プレミアムなシネマティックビデオ生成。
DeepSeek R1
8S
オーディオ名
オーディオ説明
0:00
ネイティブオーディオと生々しい物理挙動を備えた、プレミアムなシネマティックビデオ生成。
8S
DeepSeek R1
ネイティブオーディオと生々しい物理挙動を備えた、プレミアムなシネマティックビデオ生成。
パフォーマンス & スケーラビリティ
本文コピーはここに lorem ipsum dolor sit amet
- 箇条書き項目はここに lorem ipsum
- 箇条書き項目はここに lorem ipsum
- 箇条書き項目はここに lorem ipsum
インフラストラクチャ
最適用途
- より高速な処理速度（全体的なクエリレイテンシの低減）と運用コストの削減
- 明確に定義された単純なタスクの実行
- 関数呼び出し、JSON モード、または他の構造化されたタスク
リスト項目 #1
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
リスト項目 #1
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
ビルド
含まれる特典:
- ✔ プラットフォーム無料クレジット最大 15,000 ドル*
- ✔ フォワードデプロイされたエンジニアリング時間無償 3 時間。
資金調達: 500 万ドル未満
ビルド
含まれる特典:
- ✔ プラットフォーム無料クレジット最大 15,000 ドル*
- ✔ フォワードデプロイされたエンジニアリング時間無償 3 時間。
資金調達: 500 万ドル未満
ビルド
含まれる特典:
- ✔ プラットフォーム無料クレジット最大 15,000 ドル*
- ✔ フォワードデプロイされたエンジニアリング時間無償 3 時間。
資金調達: 500 万ドル未満
ナタリアは4月に友人48人にクリップを売り、5月にはその半分の数を売りました。ナタリアは4月と5月の合計で何個のクリップを売ったのでしょうか？
XX
タイトル
本文コピーはここにロレム・イプサム・ドロール・シット・アメット
XX
タイトル
本文コピーはここにロレム・イプサム・ドロール・シット・アメット
XX
タイトル
本文コピーはここにロレム・イプサム・ドロール・シット・アメット
原文を表示
Summary
Serving long prompts doesn’t have to mean slow responses. At Together AI, we built cache-aware prefill–decode disaggregation (CPD), a serving architecture that purposely separates cold and warm workloads by cache hit rate, resulting in fast context reuse. By isolating heavy prefills and leveraging distributed KV cache, CPD delivers up to 40% higher sustainable throughput and significantly lower time-to-first-token (TTFT) for long-context inference — especially under mixed, real-world traffic.
Today's AI native applications are pushing context lengths to new limits. From multi-turn conversations and coding copilots to agent memory and retrieval-augmented systems, long prompts are becoming the norm. But serving these large contexts efficiently remains a challenge: TTFT rises and becomes more variable. Inference performance is increasingly shaped not just by model compute, but by how efficiently systems handle shared context. In real-world workloads, many requests are not entirely new. Some contain large portions of context that have been seen before — e.g., shared system prompts, conversation history, or common documents. We refer to these as warm requests. Others introduce mostly new context and require full computation — these are cold requests.
Recent advances like prefix caching and prefill–decode disaggregation (PD) have already improved long-context serving. Prefix caching reduces redundant work by reusing previously computed KV cache of the prompt prefixes, while PD separates the compute-heavy prefill stage from latency-sensitive decoding to reduce interference between them. Together with other associated techniques such as chunk prefill, sequence/context parallelism, etc., they collectively help lower overhead and improve hardware utilization.
However, real-world workloads under very high load poses new challenges beyond the common serving scenarios. Consider a system where some concurrent users submit large, entirely new prompts over 100K tokens while others continue with multi-turn conversations that mostly reuse earlier context. PD ensures decoding is not blocked by prefill, but all prefills — both cold and warm — still share the same prefill capacity. The large cold prompts occupy those resources for seconds at a time, and warm requests that could have been served quickly through cache reuse end up waiting in the same queue. As a result, TTFT increases not because these requests need heavy computation, but because they are stuck behind the requests that do.
To address this gap, we built a cache-aware disaggregation serving architecture, which handles warm and cold requests with separate compute resources. By identifying how much reusable context a request contains, the system can make smarter scheduling decisions — reducing unnecessary waiting and routing work more effectively across compute resources. Instead of letting expensive cold prefills dominate shared capacity, the system paves fast paths for warm requests while still processing new context efficiently.
As a result, the cache-aware disaggregation design enables the system to scale more gracefully under load. As shown in Figure 1, under a tail-sensitive SLA, it consistently sustains higher achievable throughput than conventional baselines. In our evaluation, CPD improves sustainable QPS by up to 35–40% over existing disaggregated designs, while maintaining tighter tail latency bounds even in the presence of large cold prompts.
How CPD works
We propose cache-aware prefill–decode disaggregation (CPD), which extends standard prefill–decode disaggregated serving with cache-aware routing and a shared KV-cache hierarchy. The key idea is simple: *don't let expensive "cold" prefills block the fast path for reusable context*.
The system separates inference into three roles:
- Pre-Prefill nodes: handle low-reuse (cold) prompts, compute new context, and write KV cache into a distributed cache.
- Prefill nodes: prioritize high-reuse (warm) requests, reading KV blocks from cache instead of recomputing prefixes.
- Decode nodes: remain latency-focused and isolated from prefill interference.
Prefill and decode are already disaggregated, but CPD adds a dedicated pre-prefill tier that handles requests with little or no cache reuse. These nodes compute large new contexts and write their KV cache into a distributed cache. Meanwhile, normal prefill nodes focus on requests that can reuse existing state, reading KV blocks from the cache instead of recomputing them. Decode nodes remain isolated and latency-focused.
Under the hood, CPD relies on a three-level KV-cache hierarchy, as depicted in Figure 2. The fastest layer lives in GPU memory, followed by host DRAM, and a cluster-wide distributed cache connected via RDMA. When a cold request is processed by a pre-prefill node, its KV state is written to the distributed cache. Subsequent similar requests can fetch this state in bulk at high bandwidth, turning what would have been seconds of compute into hundreds of milliseconds of transfer and light recomputation. Over time, frequently accessed contexts naturally move closer to the GPU, further shrinking latency.
The router ties this together. For each request, it estimates how much of the prompt can be served from cache. Requests with low reuse are steered to pre-prefill nodes, while high-reuse requests go directly to normal prefill nodes. This workload separation prevents large cold prefills from saturating shared compute, while still allowing the system to ingest new context and continuously warm the cache. The result is a serving stack that keeps fast paths fast, even under mixed and bursty long-context workloads.
What happens across repeated requests
CPD's benefits become clear when the same or similar long context appears multiple times — which is common in copilots, agents, and multi-turn chat scenarios. Each request moves the workload further away from heavy compute bound and to prefix cache reuse.
Request 1 — Cold (bootstrap)
The first time a large context appears, it is classified as cold. The router sends it to a pre-prefill node, which performs the full prefill computation. At the same time, the generated KV cache is written into the distributed cache.
This request pays the full compute cost, but it *primes the system* by turning the new context into a reusable state.
Request 2 — Warm (distributed cache reuse)
When the same context appears again, the router now identifies it as warm. Instead of recomputing the prefix, a normal prefill node fetches KV blocks from the distributed cache via RDMA and loads them into GPU memory.
Now seconds of compute are replaced by high-bandwidth transfer and light processing. Latency drops dramatically while GPU compute pressure also decreases.
Request 3 — Warm (local reuse)
If the context remains active on the same node, its KV state may already reside in GPU or host memory. No distributed cache transfer is needed — the system reuses local cache directly.
At this point, prefill becomes minimal overhead, and latency shrinks even further. The same 100K-token context that originally required seconds of compute can now be served in a few hundred milliseconds. Moreover, CPD does more than reuse prefixes — it isolates heavy compute from reuse-driven traffic, allowing the system to scale long-context inference without letting cold workloads dominate shared resources.
Evaluation
We evaluate CPD along two complementary dimensions that are critical for long-context serving systems under real-world load:
- Latency and throughput scaling under increasing load — how TTFT (p50 and p90) and per-GPU throughput evolve as target QPS increases.
- Effective serving capacity under contention — how much sustainable QPS per GPU the system can maintain before prefill-side saturation leads to rapid latency inflation.
We compare a conventional PD-based deployment against CPD, focusing on how cache-aware disaggregation reshapes saturation behavior and latency under mixed warm and cold workloads:
- 2P1D/2P2D (baseline): Two prefill nodes and one or two decode node, using standard PD routing where all requests share the same prefill capacity.
- CPD-1D/2D: A cache-aware pipeline consisting of a dedicated pre-prefill tier, one normal prefill tier, and one or two decode nodes, coordinated by a CPD-aware router that distinguishes warm and cold requests.
All experiments are conducted on NVIDIA B200 GPUs. Each prefill stage uses tensor parallelism across 4 B200 GPUs per node, while decode stages use data parallelism with attention sharding across 4 B200 GPUs. We cap the maximum number of inflight requests at 24 to reflect realistic admission control and to avoid unbounded tail amplification.
For each target QPS, the system ramps up traffic over 30 seconds and then sustains steady-state load for 600 seconds. QPS is swept from 0.4 to 1.6 in increments of 0.2 to capture system behavior from light load through saturation.
Workload configuration
To reflect realistic long-context inference workloads, we design a benchmark based on a coding agent scenario with large shared context and multi-turn interactions. This workload mirrors AI-assisted software development settings where an agent maintains substantial codebase context across multiple turns — reading files, analyzing dependencies, implementing changes, and iterating on fixes. Using synthetic data with a realistic mix of warm and cold prefill requests that stress CPD's scheduling decisions.
Results
Together, Figure 4 illustrates how CPD reshapes both latency scaling behavior and serving capacity as system load increases.
Saturation behavior
As target QPS increases, the two systems begin to diverge once prefill capacity becomes the dominant bottleneck. The 2P1D baseline reaches saturation earlier, with achieved QPS flattening around 0.75–0.8 QPS per GPU, after which queueing delays grow rapidly. In contrast, CPD continues to scale to approximately 1.1–1.15 QPS per GPU under the same workload, representing a ~40% increase in sustainable throughput before entering saturation.
This rightward shift of the saturation point is consistent with the throughput curves in Figure 4 (bottom-left), where CPD maintains higher effective prefill throughput as load increases. By separating cold prefills from cache-backed warm requests, CPD prevents long-running cold prompts from monopolizing shared prefill capacity, allowing the system to operate efficiently at higher offered load.
Latency under load
At light load, median TTFT (p50) is comparable between 2P1D and CPD, indicating that CPD does not introduce additional overhead in the uncongested regime. As QPS increases toward the baseline's saturation point, however, the behavior diverges sharply.
For 2P1D, TTFT p50 rises steeply beyond 1 second and quickly enters multi-second territory, reflecting queueing behind large cold prefills. CPD exhibits a significantly more gradual increase: even at target QPS levels where the baseline is already saturated, CPD maintains sub-second to low-second median TTFT, as shown in Figure 4 (top-left). This improvement directly follows from workload isolation — warm requests that reuse cached context are no longer forced to wait behind expensive cold-prefill execution.
Tail latency (TTFT p90) shows a more nuanced pattern. Under moderate load, both systems exhibit similar p90 behavior. As load increases further, p90 TTFT rises for both designs, but CPD consistently remains below or comparable to the baseline across the evaluated range (Figure 4, top-right). Importantly, CPD achieves substantial gains in median latency without introducing disproportionate tail amplification. While bursts of cold traffic can still increase queueing within the pre-prefill tier, their impact remains largely contained, preserving predictable tail behavior.
Throughput efficiency
The throughput breakdown in Figure 4 highlights the underlying cause of these improvements. CPD sustains higher prefill throughput per GPU at elevated QPS, whereas the baseline's prefill throughput plateaus and then degrades as queueing intensifies. Generation throughput remains broadly comparable between the two systems, indicating that the observed performance differences are primarily driven by more efficient prefill scheduling rather than decode-side optimizations.
Key result and discussion
Figure 4 shows that CPD shifts the operating point of long-context serving under mixed warm and cold workloads. Increasing decode capacity from 1D to 2D improves overall throughput and delays saturation for both baseline and CPD configurations, confirming that decode-side parallelism contributes to higher serving capacity.
Importantly, CPD continues to deliver consistent improvements even when decode capacity is scaled. Under both 1D and 2D settings, CPD sustains higher effective QPS per GPU and exhibits a more gradual increase in median TTFT compared to the corresponding baseline. In addition, CPD maintains comparable or higher decode throughput, indicating that its benefits are not limited to prefill isolation but extend to more efficient end-to-end pipeline utilization.
These improvements are driven not by raw model execution speed, but by cache-aware isolation on the prefill path. By preventing long-running cold prefills from blocking cache-backed warm requests, CPD preserves a fast path for reuse even under high load. This highlights that as context windows grow, system-level scheduling and reuse-aware design become first-order factors in inference performance, alongside model and hardware efficiency.
8S
DeepSeek R1
Premium cinematic video generation with native audio and lifelike physics.
DeepSeek R1
8S
Audio Name
Audio Description
0:00
Premium cinematic video generation with native audio and lifelike physics.
8S
DeepSeek R1
Premium cinematic video generation with native audio and lifelike physics.
Performance & Scale
Body copy goes here lorem ipsum dolor sit amet
- Bullet point goes here lorem ipsum
- Bullet point goes here lorem ipsum
- Bullet point goes here lorem ipsum
Infrastructure
Best for
- Faster processing speed (lower overall query latency) and lower operational costs
- Execution of clearly defined, straightforward tasks
- Function calling, JSON mode or other well structured tasks
List Item #1
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
List Item #1
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Build
Benefits included:
- ✔ Up to $15K in free platform credits*
- ✔ 3 hours of free forward-deployed engineering time.
Funding: Less than $5M
Build
Benefits included:
- ✔ Up to $15K in free platform credits*
- ✔ 3 hours of free forward-deployed engineering time.
Funding: Less than $5M
Build
Benefits included:
- ✔ Up to $15K in free platform credits*
- ✔ 3 hours of free forward-deployed engineering time.
Funding: Less than $5M
Think step-by-step, and place only your final answer inside the tags *<answer>* and *</answer>*. Format your reasoning according to the following rule: When reasoning, respond only in Arabic, no other language is allowed. Here is the question:
Natalia sold clips to 48 of her friends in April, and then she sold half as many clips in May. How many clips did Natalia sell altogether in April and May?
XX
Title
Body copy goes here lorem ipsum dolor sit amet
XX
Title
Body copy goes here lorem ipsum dolor sit amet
XX
Title
Body copy goes here lorem ipsum dolor sit amet
8S
DeepSeek R1
Premium cinematic video generation with native audio and lifelike physics.
DeepSeek R1
8S
Audio Name
Audio Description
0:00
Premium cinematic video generation with native audio and lifelike physics.
8S
DeepSeek R1
Premium cinematic video generation with native audio and lifelike physics.
Performance & Scale
Body copy goes here lorem ipsum dolor sit amet
- Bullet point goes here lorem ipsum
- Bullet point goes here lorem ipsum
- Bullet point goes here lorem ipsum
Infrastructure
Best for
- Faster processing speed (lower overall query latency) and lower operational costs
- Execution of clearly defined, straightforward tasks
- Function calling, JSON mode or other well structured tasks
List Item #1
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
- Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt.
List Item #1
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Build
Benefits included:
- ✔ Up to $15K in free platform credits*
- ✔ 3 hours of free forward-deployed engineering time.
Funding: Less than $5M
Build
Benefits included:
- ✔ Up to $15K in free platform credits*
- ✔ 3 hours of free forward-deployed engineering time.
Funding: Less than $5M
Build
Benefits included:
- ✔ Up to $15K in free platform credits*
- ✔ 3 hours of free forward-deployed engineering time.
Funding: Less than $5M
Think step-by-step, and place only your final answer inside the tags *<answer>* and *</answer>*. Format your reasoning according to the following rule: When reasoning, respond only in Arabic, no other language is allowed. Here is the question:
Natalia sold clips to 48 of her friends in April, and then she sold half as many clips in May. How many clips did Natalia sell altogether in April and May?
XX
Title
Body copy goes here lorem ipsum dolor sit amet
XX
Title
Body copy goes here lorem ipsum dolor sit amet
XX
Title
Body copy goes here lorem ipsum dolor sit amet
関連記事
KV キャッシュの局所性：LLM サービングコストにおける見えない変数
GPU の割り当て次第でスループットやレイテンシが変動する KV キャッシュの局所性が、再計算コストに直結し、ロードバランサーの設計変更が必要となる。
LLM サービングにおける CPU と GPU の分離の必要性：SMG の事例
Shepherd Model Gateway（SMG）は、大規模な大規模言語モデル（LLM）展開向けの高パフォーマンスなモデルルーティングゲートウェイです。同ツールは、ワーカーライフサイクル管理を一元化し、HTTP/gRPC/OpenAI 互換バックエンド間でトラフィックを分散させます。また、履歴保存や MCP ツール、プライバシー重視のワークフローに対する企業レベルの制御を提供します。
エージェントシステムにおける意図と実行の架橋
Amazon Science は、AI エージェントのパフォーマンスはモデル自体の問題ではなく、LLM とツール間の仲介役となるハッチ（OS）の設計がボトルネックであると指摘し、意図を実行に移すシステムの重要性を強調した。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み