vLLM、TileRTと連携し遅延重視型推論を最適化

大規模言語モデルのスケール展開において、計算集約型のプリーフィルフェーズとメモリ帯域幅制約型のデコードフェーズを分離する「非統合型（Disaggregated）サービング」は、もはや標準的なパターンとなっています。vLLM はこのアーキテクチャを、ファーストクラスのコネクタインターフェースを通じてサポートしています。

このアーキテクチャの転換には、見落としがちな大きなメリットがあります。プリーフィルとデコードが分離されれば、デコード側はプラグイン可能になるのです。異なるサービング環境では、それぞれに最適なエンジン設計が求められます。プリーフィルプール、スケジューラ、キャッシュ層、そしてサービング API はその場所を維持したまま、デコードプールのみを意図的に選択して差し替えることが可能になります。

本日、私たちはまさにそのような選択肢を発表します。vLLM プリーフィルと TileRT デコードの組み合わせです。これは vLLM V1 のパブリックコネクタインターフェースを通じて統合され、TileRT 0.1.5 とともに提供されます。レイテンシがクリティカルなワークロードにおいて、この組み合わせはユーザーごとのネイティブなデコード速度を実現する TileRT の真価を発揮します。一方、デプロイの他の部分はすべて標準的な vLLM のままです。

なぜ第 2 のデコードオプションが必要なのか

vLLM のネイティブデコードは、依然として最適なデフォルトです。これは、広範なモデルとハードウェアにわたる高スループットバッチ処理のために設計されているからです。

しかし、アジェンティック・ループや対話型コーディングアシスタント、リアルタイム音声など、集計スループットではなく「個々のユーザーにトークンが到達するまでの速度」が重要となるワークロードのクラスが増えています。これらのワークロードはレイテンシに制約されており、まさにその領域のためにゼロから設計されたデコードエンジンが必要です。ネイティブデコードと TileRT は、同じスループット・レイテンシのフロンティア上の異なる点を指向しており、そのため両者は補完し合います。

TileRT はそのようなエンジンです。ハードウェアの限界までユーザーごとのデコード速度を押し上げるという単一の目標を中心に構築された、新しい推論ランタイムです。私たちは以前、なぜ「速度が新たなスケーリング次元になりつつある」のかについて述べてきました。

しかし、この記事で取り上げているのはエンジンそのものではありません。より実用的な問い、つまり OpenAI 互換 API やスケジューリング、プレフィックスキャッシング、ツール呼び出し、そして vLLM の運用成熟度など、あなたが依存しているエコシステムを手放すことなく、専門的なデコードエンジンを採用できるかどうかについてです。

この統合は、そのトレードオフを可能な限り小さくするために設計されています：

• プリフィル処理は vLLM が担当します。スケジューリング、チャンク化されたプリフィル、プレフィックスキャッシングもそのまま維持されます。
• サービングのインターフェースも vLLM です。同じ API、同じリクエスト形式、そして同じツールチェーンが利用可能です。

• デコード処理の変更は必要最小限に絞り、対象となるトラフィックのみを対象とします。TileRT と連携するスタックは、既存の vLLM 環境の横で並行して動作し、各ワークロードが適切なエンドポイントを選択します。

アーキテクチャ：設計段階での共存

中核となる設計原則は「vLLM への一切の変更を加えない」ことです。フォークもパッチ適用も、内部ワーカーをラップすることもありません。統合機能は vLLM V1 の公開拡張インターフェースの背後に完全に実装されています。具体的には KVConnectorBase_V1 の実装であり、これは MultiConnector として構成され、標準的な kv_connector_module_path メカニズムを通じてロードされます。

このアプローチが重要なのは、単なるエンジニアリング上の美しさのためだけではありません。TileRT デコードプールを追加しても、すでに稼働中の vLLM 環境を不安定化させることはなく、vLLM をアップグレードする際にも、フォークの移植作業が必要になることはありません。

image設計による共存：遅延がクリティカルなトラフィックは TileRT PD ルーターによってマークされ、TileRT コネクターによって引き受けられます。一方、一般的なトラフィックはネイティブの分離パスを流れます。これらはすべて、MultiConnector として構成された単一の標準 vLLM プリフェルプールによって処理されます。

ルーティング。 TileRT プールの前面には軽量なルーターが配置されています。各リクエストに対して max_tokens=1 が設定され（vLLM がプリフェルを実行し、最初のトークンを生成）、ターゲットとなるデコードノードは標準のパススルーフィールドに付与されます。具体的には kv_transfer_params = {"tilert_host": ..., "tilert_ctrl_port": ...} のように指定します。ネイティブプール向けのトラフィックは、変更を加えず通常の分離プロキシを経由して流れます。

Claim filtering. TileRT コネクタは、特定のマークを付与されたリクエストのみを対象とし、それ以外は厳格に何もしない（no-op）動作を行います。このため、2 つのデコードプールは 1 つのプレフィルインスタンス（単一のフォワードバッチでも可）を共有できます。一部のトラフィックで TileRT を採用しても、残りの処理には一切影響しません。

A pure producer. このコネクタは KV プロデューサーとしてのみ機能し、スケジューリングやサンプリングには一切関与しません。プレフィル完了後に状態情報を抽出して転送するだけです。それ以外の点では、プレフィルインスタンスは標準的な vLLM サーバーと変わりません。

How the handoff works

クロスエンジン間のディスアグリゲーションを実用的なものとするためには、3 つの条件が満たされている必要があります。まず転送速度が速いこと、次にプレフィルノードの処理を遅延させないこと、そしてデコードエンジンがプレフィルが中断した位置から正確に引き継ぐことです。

Data plane. プレフィル完了後、リクエストのアテンション状態（圧縮された KV、スパースアテンションインデックスキャッシュ、および少量のメタデータ）は、RDMA のワンサイド書き込みによってプレ登録済みの GPU バッファへ転送されます。転送エンジンには Mooncake または NIXL が使用され、中間シリアライズやホストメモリを経由するステージングは一切行われません。ハンドオフプロトコル自体は基盤となる転送エンジンに依存せず、その役割は単にバイト列を移動させることに限定されています。

プリフェッチと完全に重畳。状態抽出はフォワードウィンドウ内で行われます。リクエストの状態はキャッシュブロックが再利用される前にステージングバッファにコピーされ、バックグラウンドの送信者が実際のネットワーク転送を実行します。TileRT 宛てのリクエストは、次のプリフェッチ反復をブロックしません。同じバッチを共有するネイティブプール要求であっても同様です。

稼働中のエンジンへの注入。到着した状態は TileRT のネイティブレイアウトに変換され、実行中のエンジンに直接注入されます。デコーディングは即座に開始され、最初のステップからマルチトークン推論デコーディングが有効になります。

評価

image8× NVIDIA B200 環境における GLM-5.1-F8 のトークン生成速度（TileRT v0.1.5）。出力長は 1K、入力長は 1K〜192K。棒グラフは、MTP なし、平均受容長が 3.2 の MTP あり、ベストケースの MTP 受容長が 4.0 の場合のピークを比較しています。

デコードプールの選択

ユーザーごとのトークン速度がボトルネックとなる場合は、TileRT デコードへルーティングしてください。具体的には対話型エージェント、リアルタイムアシスタント、遅延時間 SLO を満たす推論などが該当します。また、モデルが TileRT がサポートするものである必要があります。

最大のスループット、高並度バッチ処理、および汎用デコードがカバーする多数のモデルや機能への対応を優先する場合は、ネイティブ vLLM デコードのまま維持してください。

両方のスタックは同じ OpenAI 互換インターフェースを提供するため、ワークロードを切り替える際はルーティングの変更だけで済み、クライアント側の変更は不要です。

現在の制限事項

今回のリリースでは、TileRT のデコードノードは一度に 1 つの進行中のリクエストのみを処理します。ルーターがゲート付きディスパッチとバックプレッシャーを提供しています。モデル対応状況は GLM-5/5.1 と DeepSeek-V3.2 で、今後さらに追加予定です。

はじめに

TileRT 0.1.5 は PyPI（pip install tilert；Python 3.12、CUDA 13 のホイール対応）および TileRT リポジトリ で利用可能です。プリフェルとデコードの両ノードにインストールしてください。プリフェル側ではコネクタープラグインのために TileRT が必要です。

0. 初回設定：Hugging Face チェックポイントを TileRT の重み形式に変換

python -m tilert.models.preprocess.weight_converter \

--model_type glm-5 \

--model_dir /path/to/GLM-5.1 \

--save_dir /path/to/tilert-glm5.1-weights

1. TileRT デコードノードの起動

python -m tilert.pd_vllm.decode_server \

--engine tilert --model glm5 \

--model-weights-dir /path/to/tilert-glm5.1-weights \

--with-mtp --max-seq-len 202752 \

--kv-cache-dtype fp8 \

--ctrl-port 5556 --http-port 5557

2. vLLM プレフィル（標準版 vLLM；コネクタはプラグインとして読み込まれる）

MTP の推測設定が必要です。プレフィル段階で生成されたドラフト層の KV キャッシュを、デコード側の推論が引き継ぎます。

vllm serve /path/to/GLM-5.1 \

--served-model-name glm5.1 \

--port 8000 \

--tensor-parallel-size 8 \

--enforce-eager \

--trust-remote-code \

--return-tokens-as-token-ids \

--gpu-memory-utilization 0.8 \

--kv-cache-dtype fp8_ds_mla \

--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}' \

--kv-transfer-config '{

"kv_connector": "TileRTConnector",

"kv_connector_module_path": "tilert.pd_vllm.prefill_connector",

"kv_role": "kv_producer",

"kv_connector_extra_config":{

"tilert_host":"[TILERT_DECODE_SERVER_IP]",

"tilert_ctrl_port":5556,

"tilert_model":"glm5",

"tilert_max_seq_len":202752

}

}'

3. ルーター：TileRT プールへの OpenAI 互換入り口

python -m tilert.pd_vllm.pd_router \

--vllm-url http://prefill-node:8000 \

--decode decode-node:5556:5557 \

--model-path /path/to/GLM-5.1 \

--port 23333

TileRT プールとネイティブ vLLM デコードプールを、1 つの共有プリフェッチインスタンスの下で実行するには、両方のコネクタを MultiConnector として構成します。検証済みの設定では、NIXL をエンドツーエンドで使用しています（ネイティブプールには vLLM の標準 NixlConnector、TileRT プールには NIXL モードの TileRT コネクタを使用）。これにより、共有プリフェッチは単一の転送ライブラリのみを利用し、変更が必要なのはプリフェッチ側の --kv-transfer-config 設定だけです。

Looking ahead

我々は、 disaggregation（分離）が推論スタックの本質を静かに変えつつあると考えています。それはもはや単一のエンジンではなく、共有のサービング層の背後に複数の専門化されたエンジンが組み合わさったものへと進化しています。vLLM のコネクタインターフェースこそが、この構成を今日可能にする鍵であり、今回の統合はその具体的な事例です。また、これが TileRT のようなエンジンがこれほどまでに深い特化を実現できる理由でもあります。サービング層を共有し、インターフェースを開放することで、ある 1 つの側面への深掘りが、他のすべての部分を再構築することを意味しなくなるからです。

コミュニティからのフィードバックをお待ちしています。統合の仕組みや、このアプローチが特に効果を発揮するワークロード、そして次に対応すべきモデルなどについてのご意見をください。

Acknowledgements

ゼロ変更での統合を可能にした V1 コネクタインターフェースを設計した vLLM コミュニティ、RDMA 転送エンジンを提供した Mooncake および NIXL プロジェクトに感謝します。また、vLLM と TileRT の統合改善に向けた協力体制を構築してくれた Inferact Inc. [https://inferact.ai/] にも謝意を表します。