すべてのGPUで販売可能なトークン数を増やす

推論を考慮したルーティングは、キューの深さ、KVキャッシュ使用率、GPU負荷など、サービングレイヤーからのリアルタイムのシグナルを利用し、各AIリクエストをその処理に最も適したモデルサーバーに送信します。一般的な負荷分散はリクエストを均等に振り分けますが、推論リクエストは処理コストが大きく異なるため、均等に振り分けても処理負荷に偏りが生じます。Kubernetes Gateway API Inference Extensionは、このパターンを標準化します。

最初のトークンが返されるまでの時間を短縮するには、まずキューイングを見直します。高負荷のGPUで長時間の生成処理の後ろにリクエストが並ぶと、モデルの速度にかかわらず、最初のトークンが返されるまでに時間がかかるためです。リクエストはキューが短く、キャッシュがウォームなエンドポイントにルーティングし、プロンプトのプレフィックスはすでにそれを保持しているサーバー上に維持します。また、非常に長いリクエストは、短い対話型リクエストと分離します。バッチ処理の設定や量子化など、モデル側の手法もさらなる短縮に役立ちます。

トークンあたりのコストは、おおむねGPUの1時間あたりのコストを、その1時間に生成される有用なトークン数で割った値です。ハードウェアを購入またはリースした後はコストがほぼ固定されるため、改善の鍵は出力量にあります。具体的には、使用率、キャッシュヒット率、バッチ処理効率、GPU間のリクエスト分散の均等性です。トークン価格が下落する中では、GPU時間あたりのトークン数のわずかな増加が、利益率の改善に直結します。

いいえ、推論を考慮したルーティングは、NVIDIA DynamoやvLLMに取って代わるものではありません。サービングフレームワークは、バッチ処理、キャッシュ、スケジューリングなど、GPU上でのモデルの実行方法を決定します。推論を考慮したルーティングは、リクエストの送信先サーバーと、適用するポリシーを決定します。BIG-IP Next for Kubernetesは、これらのシステムが公開するシグナルに基づいてルーティングするため、既存のサービングスタックはそのまま維持されます。

公開された結果は、DPUモードのNVIDIA BlueField-3 DPUで測定されたものであり、ホスト環境のデプロイにそのまま当てはまるわけではありません。BIG-IP Next for Kubernetesは、標準的なホストCPU上で同じルーティングロジックを使用して動作します。リースしたコンピューティングリソースを利用する推論企業の多くは、この構成から始めることになります。ホスト環境のデプロイのサイジングは、その環境でのテスト結果に基づいて行ってください。