AWSはvLLMの入力処理と生成処理を分離する構成向けに、プッシュ型KV転送を紹介しました。転送準備を並行させ、最初の応答までの待ち時間を短縮します。 推論基盤の運用者は、ネットワークとメモリの制約を含めて効果を検証する必要があります。公開された改善幅は、特定モデルと負荷条件の測定結果です。 入力処理の後に残る転送待ちを減らす AWSは2026年10月19日、vLLMの分離推論で使うプッシュ型のKV転送を解説しました。大規模言語モデルの推論には、入力を読み込む段階と、出力を順に生成する段階があります。この二つを別の計算環境で動かすと、各段階を個別に増強できます。一方、生成を始めるには入力側で作った計算状態を渡す必要があります。従来の取得型の構成では、入力処理後の調整や領域確保が待ち時間に加わっていました。今回の説明は、その準備を並行して行い、データが用意できた段階で送る仕組みです。モデルの回答内容を変える手法ではなく、生成を始めるまでの経路を改善する内容です。 高い要求頻度で転送の調整が制約になる 原文は、NIXLという転送ライブラリーを使う接続部分の変更を紹介しています。生成側が転送先の領域を先に登録し、入力側が準備できた計算状態を送ります。転送の設定を背景の処理へ移すことで、生成側の時間を使いにくくする設計です。AWSはTrainiumで構築と検証を行い、機器に依存しない機能としてvLLMへ貢献したと説明しています。掲載された測定は、EFAで接続したEC2 P5enとQwen3-32Bを使う条件です。影響を受けるのは、複数のサーバーへ推論処理を分けて配置するサービスの運用者だと見られます。要求が増えたときに最初の応答が遅くなる場合、モデルの計算量だけでなく、転送前の調整も調査対象になることを示す事例です。機器の追加で解決できる待ち時間と、処理順序の変更で減らせる待ち時間を分けて見ることが重要だと考えられます。 平均速度に加えて負荷時の待ち時間を測る 実務では、測定結果の改善率を自社の構成へそのまま当てはめず、入力長と同時要求数をそろえて比較する必要があると見られます。転送先のメモリを早く確保する設計は、利用できる領域や要求の取り消し方とも関係する可能性があります。入力側と生成側の台数配分、ネットワークの混雑、長い入力の比率も評価条件です。費用面では、速度だけでなく、同じ応答水準を維持できる設備量が論点になります。切り替え前には、転送の失敗や処理の中断を記録し、既存方式へ戻せる運用を検討することが重要だと見られます。応答開始までの時間と、一文字ずつ生成する速さを分けて観測すれば、どの待ち時間が改善したかを確認しやすくなります。遅い要求が集中する時間帯も含めて観測し、平均値だけでは見えない利用者の待ち時間を把握することが論点です。運用開始後も同じ観測条件を保つ必要があると見られます。