AWS、vLLM（ブイエルエルエム）のprefill/decode分離推論にpush型のKV転送を追加P5enのQwen3-32Bで初回トークンまでの時間が最大約3倍、トークンあたり時間が最大30%改善と発表

AWSは2026年10月19日（米国時間。日本時間では10月20日1時台）、オープンソースの推論エンジン vLLM（ブイエルエルエム）で、prefill（入力の処理）とdecode（出力の生成）を別のインスタンスに分ける構成向けに、KVキャッシュの転送を「push型」にするNIXLコネクタを公式ブログで紹介しました。Amazon EC2 P5enをEFAでつないだ1P1D構成でQwen3-32Bを動かした測定で、標準のpull型に比べて初回トークンまでの時間（TTFT）が最大約3倍、トークンあたり時間（TPOT）が最大30%改善したと、AWSは説明しています。

3行まとめ

1. AWSは、vLLMのprefill/decode分離推論でKVキャッシュをprefill側から書き込む「push型」NIXLコネクタを紹介。設定はNixlPushConnectorを両サーバーで使う
2. P5en（EFA接続）の1P1D・Qwen3-32Bで、pull型比でTTFTが最大約3倍、TPOTが最大30%改善（AWS測定。入力16k・8 QPSでTTFTは約1,744msから約540ms）
3. decode側の選択を早めに決める必要があるため、負荷を見た振り分けを重視する構成ではpull型が向くとAWS自身が書いている

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

何が変わったのか：pull型からpush型へ

AWSのブログによると、prefill/decode分離は、2つの処理段階を別々のエンジンインスタンスで動かし、それぞれを独立に拡張・最適化できるようにする方式です。その代わり、decodeを始める前にprefill側で作ったKVキャッシュをdecode側へ渡す必要があり、この転送がTTFTを左右します。

vLLMがこの転送に使う手段の1つが、NVIDIA Inference Xfer Library（NIXL）のコネクタです。AWSによれば、これはAWS EFAのようなRDMA対応のネットワークでKVブロックを動かし、対応インスタンスではGPUやAWS Trainiumのデバイスメモリ間を、ホストメモリを経由せずに直接転送できます。

標準のpull型の流れは、AWSの説明では次のとおりです。

1. prefillが終わると、ルーターがprefillブロックのIDなどをdecode側に中継する
2. decode側が受け取り先のブロックを確保し、NIXL転送を準備する
3. decode側がNIXL READでprefill側からKVブロックを取りに行く

これらが直列に並ぶため、最初のトークンが出るまでの経路が長くなる、というのがAWSの指摘です。

push型はこの順序を入れ替えます。

もう1つの変更点はスレッドです。AWSによると、prefillの各ワーカーに転送専用のバックグラウンドスレッドを置き、ディスクリプタの準備と転送の投入をそこで行います。pull型ではこの作業がdecodeワーカーのエンジンループ内で同期的に走り、トークン生成を止めていたと説明しています。

どれくらい速くなったのか

測定条件はAWSの記述では、Amazon EC2 P5en・EFA接続の1P1D、モデルはQwen3-32Bです。転送性能だけを見るため--no-enable-prefix-cachingでプレフィックスキャッシュを無効にし、毎回decode側がKVキャッシュ全体を取りに行く状態にしています。入力長は1k〜16k、リクエストレートは1〜8 QPSで振っています。

低負荷・短いプロンプトでは両者はほぼ同じで、負荷と入力長が増えるほど差が開く、とAWSは書いています。数字はいずれも本文中の記述で、グラフの全点は図としてのみ載っています。

誰がどう使えるのか

AWSによると、この機能はまずAWS TrainiumのEFAクラスターで作って検証し、そのうえで加速器に依存しない機能としてvLLMに寄贈したとのことです。ブログの測定結果はTrainiumではなくP5en（GPU）のもので、AWSは「GPUでも効果が出る」ことを示すものと位置づけています。

使うには、prefillサーバーとdecodeサーバーの両方で、NixlConnectorの代わりにNixlPushConnectorを指定します。再現手順は、ブログからリンクされている「Reproducing our results」のガイドにまとまっているとのことです。他の構成でも動かせるが、性能はハードウェア・モデル・ワークロード・ネットワークで変わる、とAWSは断っています。

料金や提供リージョン、vLLMのどのバージョンから使えるかは、今回取得した公式ブログの本文には書かれていませんでした。vLLM側の設計文書として「Push-mode NIXL KV connector」のページがブログから案内されています。

前の記事の「双方向KV転送」とは何が違うのか

当サイトでは、AWSがvLLMに提供した双方向KV転送を双方向KV転送の記事で扱いました。今回のAWSのブログも、双方向KV転送についてはvLLMのブログ記事（URLの日付は10月12日）にリンクしており、push型とは別の話として扱っています。AWSは結論部で、双方向のKV転送が必要なワークロードや、prefill後に負荷を見てdecodeインスタンスを選びたいワークロードにはpull型のほうが向く、と書いています。つまり両者は置き換えではなく、構成に応じた使い分けという位置づけです。

筆者の観測：本文に出ている数字から確かめたこと

日本時間10月20日1時13分に公式ブログを取得して読みました。本文の数字から自分で割ってみると、TTFTは約1,744msと約540msで約3.2倍、TPOTは約10.4msと約7msで約33%の短縮になります。AWSの言う「最大約3倍」「最大30%」は、本文が挙げる高負荷・長い入力の条件の値とおおむね合います。一方で、グラフそのものは画像で、取得したテキストには軸の数値や全条件の点が入っていません。そのため本記事で書ける数字は、AWSが本文に書いたものに限っています。なお、私は実機でこの機能を動かしてはいません。

P5en・Qwen3-32B・1P1Dの外では分からないこと

• 測定はAWS自身によるもので、第三者の再現は今回確認していません。AWSが書いている測定条件はQwen3-32B・1P1D・出力128トークン・プレフィックスキャッシュ無効で、結果はワークロードと構成で変わるとしています。AWSによると、プレフィックスキャッシュが有効だと重なったプロンプトはdecode側のキャッシュを再利用して転送を通らないことがあり、実運用で同じ差が出るとは限りません
• 比較対象はpull型のNIXLコネクタです。他のKVコネクタや、他のモデル・複数台構成との比較は、今回取得した記事には載っていません
• Trainiumでの測定値は、今回取得した記事には載っていません
• push型はdecodeインスタンスの選択を早めるため、負荷を見た柔軟な振り分けは弱くなるとAWSは書いています。一方でprefill側は、転送が早く始まる分、同程度の負荷ならKVブロックを早く解放できるとも説明しています
• AWSは今後の改善として、バックグラウンドのNIXLスレッドの仕組みをpull型にも持ち込むことを検討しており、そのためのプルリクエストを出したと書いています。プルリクエストの中身と進み具合は、本記事では確認していません

参照した公式ページと確認時刻

• AWS Machine Learning Blog「Push-based KV transfer to improve TTFT and TPOT for disaggregated inference in vLLM」: https://aws.amazon.com/blogs/machine-learning/push-based-kv-transfer-to-improve-ttft-and-tpot-for-disaggregated-inference-in-vllm/（公開は米国時間2026年10月19日。日本時間2026年10月20日1時13分に取得して確認）

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