F5 AIロードバランシング、ラボで3.24倍を記録。ただし極限の負荷下に限る
F5がスポンサーとなったラボ見学での最も厳しいテストにおいて、F5 AIロードバランシングはEnvoyベースのゲートウェイと比べ、完了処理量が3.24倍に達したと報じられている。この結果は、NVIDIA BlueField-3データ処理ユニット（DPU）上で稼働するBIG-IP Next for Kubernetesによるものだ。ただし、より軽いワークロードでは差ははるかに小さかった。この対比は、見出しの数値以上に重要である。
テストには、それぞれNVIDIA H100 GPUを8基搭載したSupermicroサーバーが使われた。各GPUはFP8数値精度でQwen3-32Bモデルを提供した。BIG-IP Next for KubernetesはDPU経由でトラフィックを管理し、比較対象のゲートウェイはホストプロセッサー上で動作した。
これは、すべてのKubernetesゲートウェイや推論クラスターに対する包括的な判定ではない。スポンサー付き訪問後にServeTheHomeが報じた、管理された条件下での特定の比較である。それでも、アクセラレーターのリアルタイムな状態に基づくトラフィックルーティングと、アクセラレーターの状態から大部分が切り離されたルーティングとの間で、ますます重要になる競争を浮き彫りにしている。
中心となる問いは、クラスターが十分なGPUを所有しているかどうかではなくなった。リクエストが長く、同時実行数が多く、配置が難しい状況で、その高価なアクセラレーターをソフトウェアが生産的に稼働させ続けられるかどうかだ。
F5 BIG-IP Next for Kubernetesテストはルーティングに負荷をかけた
報告された優位性は、より容易なベースライン時ではなく、クラスターのキー・バリューキャッシュが過剰割り当てになったときに現れた。
このラボテストでは、同じQwen3-32Bモデルを提供する2つの経路を比較した。F5の制御コンポーネントとEndpoint PickerコンポーネントはBlueField-3 DPU上で動作した。代替案では、後にAgent Routerへ改称されたEnvoy AI Gatewayをホスト上で使用した。
テストでは、60分間の実行にわたるP90レイテンシーを追跡した。NVIDIAのAI Perf Toolが、異なる同時実行レベルとプロンプト長でリクエストを生成した。トラフィックパターンは、共有プレフィックスなし、マルチターン会話、混合トラフィック、プレフィックス再利用が多いケースの4種類を対象とした。
ベースラインでは、同時リクエスト数150件と、リクエスト当たり10,000入力トークンを組み合わせた。ServeTheHomeによると、このケースでは2つのゲートウェイの性能は比較的近かった。クラスターは利用可能なキー・バリューキャッシュ容量の46%を使用していた。
通常KVキャッシュと略されるキー・バリューキャッシュは、モデルがトークン生成時に再利用できるアテンションデータを保存する。推論速度を向上させる一方で、大量のGPUメモリを消費する。長いプロンプトと多数の同時ユーザーにより、このメモリ資源は容易に余裕のある限界を超えうる。
厳しいテストでは、同時実行数を150から200へ、33%増加させた。また、各リクエストの入力長を20,000トークンへ倍増させた。その結果生じたワークロードは、クラスターで利用可能なKVキャッシュ容量の1.24倍を必要とした。
この過剰割り当てが結果を変えた。ServeTheHomeは、F5経路が難しいワークロードをより効果的に分散したため、3.24倍の向上を報告した。同サイトが公開したグラフでは、完了リクエスト数、毎秒の出力トークン数、最初のトークンまでの時間も検証している。
したがって、3.24倍という数値は高圧的な負荷下での結果として読むべきだ。F5ソフトウェアを導入すれば、すべてのクラスターが3.24倍のトラフィックを処理できるという意味ではない。同じ報告は、その数値をテスト環境内の極端な条件と位置付けている。
この留保によってテストの意義が失われるわけではない。本番の推論システムは、ピーク負荷、長いコンテキスト、不均一なアクセラレーター負荷を乗り切らなければならない。低い利用率では同様に振る舞うゲートウェイも、飽和に近づくほど価値が大幅に高まる可能性がある。
重要な変化はアーキテクチャーにある。ロードバランシングは、キューの深さ、GPU利用率、キャッシュ圧力を含むモデル提供の状態へと近づいている。ゲートウェイはもはや、ネットワーク接続だけを基に意思決定しているわけではない。
F5は、BIG-IP Next for Kubernetes、すなわちBNKをAIサービスプレーンと呼んでいる。これはクライアントとGPUインフラの間に配置され、トラフィック管理、セキュリティ、ルーティング、利用量制御を組み合わせる。この製品はホストプロセッサーまたは対応するBlueField-3 DPU上で稼働できる。
DPUに配置することで、ネットワーキングとセキュリティのタスクをサーバーのメインプロセッサーから移せる。DPUは、ネットワーキング、ストレージ、セキュリティの処理を担うよう設計されたプログラマブルなインフラプロセッサーだ。これによりホストのリソースは、モデル提供とクラスター運用に利用できる。
したがって、このテストは関連する2つの考え方を測定した。1つはGPUメモリ圧力下でのルーティング品質、もう1つはインフラ処理をホスト外で処理するよう設計されたハードウェアへ移すことだ。
F5 AIロードバランシングが高負荷時に改善する理由
F5の仕組みは、従来のネットワーク指標では表せないアクセラレーターの状態を把握することに依存している。
従来のロードバランサーは、ラウンドロビン、接続数、固定優先度を通じてトラフィックを分散できる。これらの手法は、バックエンドサーバーの容量が予測可能な場合に有効だ。大規模言語モデルの推論は、その前提を崩す。
あるリクエストには短い質問だけが含まれるかもしれない。別のリクエストには、20,000トークン分の文書と会話履歴が含まれる可能性がある。さらに別のリクエストは、1つのGPUのKVキャッシュにすでに保存されたプレフィックスを再利用するかもしれない。
これらのリクエストは、同じGPUに到達しても処理時間が異なりうる。モデルがリクエストをバッチ処理し、メモリを割り当て、生成トークンをストリーミングすることで、キューも急速に変化する。ネットワークエンドポイントが健全でも、次のプロンプトの送り先としては不適切な場合がある。
F5のロードバランシング文書では、GPUとモデル提供のテレメトリーを監視するAnalyzerコンポーネントを説明している。これは各バックエンド向けに新しいトラフィックウェイトを推奨する。F5のTraffic Management Microkernelは、そのウェイトをデータプレーンに適用する。
文書化されている入力には、推論レイテンシー、キューの深さ、GPUメモリ消費量、熱状態、エラー率が含まれる。F5はNVIDIA Inference Microservices、NVIDIA Data Center GPU Manager、vLLMからのテレメトリーにも対応している。
このフィードバックループにより、圧力下で差が広がる理由を説明できる。静的ポリシーは、どのGPUがメモリ限界に近づいているかを直接把握できない。テレメトリー対応コントローラーは、キューがクラスターのボトルネックになる前に、苦戦しているエンドポイントへのトラフィックを減らせる。
F5は、ルーティングをプレフィックス認識およびKVキャッシュ認識と説明している。プレフィックス認識は、再利用可能なコンテキストをすでに保持するバックエンドに関連プロンプトを送ろうとするものだ。不必要なキャッシュ再構築を避けることで、計算処理とメモリの入れ替わりを抑えられる。
負荷認識は別の目的を担う。すべてのエンドポイントが等しく準備できていると仮定するのではなく、利用可能な容量に応じてリクエストを分散する。最も強い結果は、こうした前提が乖離する場合に現れるはずであり、ラボの過剰割り当てワークロードはまさにその状況を作り出した。
このソフトウェアがH100 GPUそのものを本質的に高速化するわけではない。利用可能な処理時間の無駄を減らそうとするものだ。GPU性能に関する主張を評価する際、この区別は不可欠である。
スケジューリングの改善により、モデルの重みやアクセラレーターのシリコンを変更せずに、クラスター全体のスループットを高められる。また、特に高コストなプロンプトの後ろで滞留するリクエストを減らすこともできる。ただし、効果はワークロードの多様性とテレメトリーの品質に依存する。
短いプロンプトで構成される均一なバッチでは、ルーティングが効果を発揮する機会は少ない。変動が大きいストリームでは、インテリジェントな配置が重要になる機会が増える。ラボ結果もこの傾向に沿っており、より軽い条件では差が小さかった。
F5の公開文書では、ラウンドロビンルーティングに対してスループットが30～40%向上するとしている。これとは別にF5は、The Tolly Groupによる検証を受けたテストで、トークンスループットが最大40%向上したと述べた。同じ発表では、最初のトークンまでの時間が61%短縮され、全体のリクエストレイテンシーが34%低下したとしている。
これらの数値は別のテストを説明しているため、3.24倍よりも控えめだ。また、外部テスト機関が測定を実施した場合であっても、依然としてベンダーが公表した性能主張である。購入者は、割合を比較する前に基礎となる構成を精査すべきだ。
F5のシステムは、LiteLLM、RouteLLM、NVIDIA Routerなどの外部モデルルーターの前段に配置できる。選択されたバックエンドの仮想アドレスへ振り向ける前に、モデル選択レイヤーを通してリクエストを送ることができる。
これは、BNKが必ずしもすべてのルーティングコンポーネントを置き換えるわけではないことを意味する。BNKはそれらを取り囲むトラフィックおよびポリシー層になりうる。このより広い位置付けにより、F5はGPU配置をセキュリティ、メータリング、ネットワーク適用と接続できる。
このアーキテクチャーが重要なのは、推論ゲートウェイが希少なリソースの制御点になりつつあるためだ。どのモデルがリクエストを処理するか、どのユーザーに容量を配分するか、いつトラフィックを抑制すべきかを決定できる。不適切な判断は、ネットワーク帯域幅以上のものを浪費する。
本当の競争はGPU認識ルーティングと不透明なバックエンドの間にある
すべての利用可能な推論エンドポイントを交換可能なサーバーとして扱うゲートウェイに圧力がかかる。
F5の主な競合相手は1社ではない。それは、接続は認識しても各アクセラレーターの内部状態を把握しない、古いトラフィック管理モデルだ。ラボでは、Envoy AI Gatewayを代表的な比較対象として用いた。
進化するクラウドネイティブエコシステムに関連するAgent Routerプロジェクトは、AI向けに特化したルーティングへのより広範な動きを反映している。名称とプロジェクトの構図は変化を続けており、単純な製品比較を難しくしている。
Envoy自体は、依然として広く利用されるプロキシの基盤である。F5のテストは、Envoyがよりスマートな推論ルーティングをサポートできないことを立証するものではない。特定の実装、配置場所、ポリシー、構成を比較したものだ。
F5の差別化は複数の層を組み合わせている。Endpoint Pickerはバックエンド選択にライブテレメトリーを使用する。DPU配置はトラフィック処理をホストの外部に置く。より広範なプラットフォームは、セキュリティ、テナント分離、トークン消費のための制御を追加する。
これらの機能をBlueField-3へ移すことで、第2の競争軸が生まれる。ホストベースのゲートウェイは、サーバーのCPUサイクルとメモリ帯域幅を消費する。DPUベースのゲートウェイは、ワークロードに物理的に近い位置を保ちながら、専用プロセッサーを使用する。
NVIDIAのAIファクトリーガイドは、プロキシ、ロードバランシング、暗号化、ファイアウォール、API保護をオフロードする選択肢の1つとしてF5の統合を挙げている。同ガイドは、FortinetやPalo Alto Networksを含むセキュリティベンダーの統合も示している。
この文脈は、市場がF5対Envoyという構図に収束しない理由を示している。インフラサプライヤーは、セキュリティとトラフィックインテリジェンスをDPU層に配置しようと競争している。オープンソースプロジェクトもモデル認識ルーティング機能を追加している。
実務上の判断は所有権に関わる。一部の運用者は、統合サポートとポリシーを備えた商用サービスプレーンを望む。他方で、プラットフォームチームが検査、変更、運用できる、構成可能なオープンソースコンポーネントを好む者もいる。
商用統合は、テレメトリー、ルーティング、ネットワーキング、セキュリティの接続に必要な作業を減らせる。一方で、特定ベンダーのコントロールプレーンと対応ハードウェアマトリクスへの依存を深める可能性もある。このトレードオフは大規模なフリート全体で重要になる。
オープンコンポーネントは柔軟性とポータビリティを提供できる。一方で、エンジニアリングチームは可観測性、ポリシー適用、ルーティングロジック、ライフサイクル管理を組み合わせる必要がある。その作業コストは、単純なスループットチャートにはほとんど現れない。
F5の立場が最も強いのは、GPUフリートが負荷のばらつく多数のテナントにサービスを提供する場合だ。共有インフラでは、分離、レート制限、使用量計測、予測可能なサービスレベルの必要性が高まる。また、非効率なリクエスト配置のコストも大きくなる。
小規模または低負荷のクラスターでは、その優位性はそれほど明確ではない。エンドポイントが制限に近づくことがほとんどなければ、静的ルーティングやより単純なルーティングでも十分な場合がある。追加インフラは、その運用上の負担を正当化しなければならない。
F5は、自社のルーティングとDPUオフロードにはモデル変更が不要だとしている。チームが既存のモデルサーバーを維持できるため、これは導入上の障壁を一つ下げる。ただし、デプロイには依然として新たなインフラコンポーネント、テレメトリパイプライン、ポリシー、障害モードが伴う。
同社のドキュメントによると、AIロードバランシングはデフォルトで無効化されている。運用担当者は機能とそのデータパスを設定しなければならない。組み込みアナライザーを使用する場合は、Prometheusおよび互換性のあるテレメトリも必要となる。
現行ドキュメントで組み込みプラグインをサポートしているのは、NVIDIA GPUメトリクスのみだ。他のアクセラレーターを利用する組織では、カスタムロジックが必要になる可能性がある。NVIDIA環境であっても、モデルサーバー、ネットワーク構成、オーケストレーションの運用方法は異なり得る。
ハードウェア要件も具体的だ。F5のDPU requirementsでは、サポート対象のBlueField-3ハードウェア、最低メモリ、デュアルネットワークインターフェース、必須ソフトウェアコンポーネントが示されている。
同じ要件では、DPUをBNK専用にする必要があるとしている。他のDPUソフトウェアがパフォーマンス上の問題やKubernetesの不安定化を引き起こす可能性があると警告している。この文書化された構成では、BNK向けにサポートされるDPUはシャーシ当たり1基のみだ。
これらの制約により、購入判断は単なるゲートウェイのベンチマークを超えるものとなる。チームはDPUの割り当て、ファームウェア管理、ネットワーク統合、障害コンポーネントの復旧方法を決めなければならない。その作業を、節約できるホスト容量と比較する必要がある。
3.24倍のパフォーマンス主張が立証していないこと
このラボ結果は有用なストレスシグナルだが、普遍的な本番環境での優位性を独立して証明するものではない。
ServeTheHomeは、F5がカリフォルニアのラボ訪問をスポンサーしたことを明確に開示している。この透明性は読者によるレポート解釈に役立つが、独立した再現検証の必要性をなくすものではない。
ハードウェア、モデル、精度、プロンプトサイズ、リクエストパターンは厳密に定義されていた。これらの変数はいずれもルーティング動作を変え得る。異なるモデルやサービングエンジンでは、キャッシュ負荷の扱い方が異なる可能性がある。
最も強い結果は、同時実行数200、20,000トークンという条件で得られた。このワークロードでは、利用可能なKVキャッシュの1.24倍が必要だった。意図的にクラスターを快適なリソース境界の外側へ置いた条件である。
このような過負荷は、スケジューラーの挙動を明らかにするうえで価値がある。一方で、製品の最良条件における差別化を増幅することもある。購入者には、通常利用率、ピーク利用率、持続的な過負荷のそれぞれにわたる結果が必要だ。
この比較では、ルーティングの配置場所とルーティングインテリジェンスも組み合わされていた。F5はDPU上で動作し、代替手段はホスト上で動作した。そのため、このテストは各設計判断によるパフォーマンスへの寄与を分離していない。
より示唆的な評価では、複数の構成を比較すべきだ。F5は同一ポリシーでホストとDPUの両方で動作させられる。競合ゲートウェイも静的ルーティングとテレメトリ対応ルーティングの両方で動作させられる。その上でクラスターは、オフロードとスケジューリングの寄与を個別に示せる。
公開記事には多くのチャートがあるが、再現に必要なすべての生ログや構成詳細は提供されていない。ログを視覚表示へ変換する際に人工知能が使われたことにも言及している。この提示方法により、機械可読な結果を公開する重要性が高まる。
F5の2026年3月のperformance announcementは、別のエビデンスポイントを提供している。そこでは別のテストにおけるより低い改善率を報告し、検証はThe Tolly Groupによるものとしている。
同じ方向性を示す複数のテストは、その仕組みの妥当性を強める。ただし、それによって各パーセンテージを相互に置き換えられるわけではない。ベースライン、ワークロード、成功指標が異なれば、見出しとなる改善率も大きく異なり得る。
完了リクエスト数、トークンスループット、レイテンシは、それぞれ異なる問いに答える。あるシステムは総トークン数を増やしながら、一部のユーザーの初期応答を遅くする可能性がある。平均レイテンシを下げつつ、テールレイテンシが不安定なままということもあり得る。
ラボでは、スループットとともに平均およびP99の最初のトークンまでの時間を検証した。本番環境の購入者は、失敗リクエスト、再試行率、応答品質、テナント間の公平性も調べるべきだ。これらの指標により、望ましくない優先順位付けを通じて高スループットが実現されていないかを明らかにできる。
モデルサービングの最適化は、出力の一貫性にも影響し得る。プロンプトをより小さなモデルへルーティングすれば、リソース使用量を減らせる一方で品質が変わる可能性がある。F5は大規模モデルと小規模モデルの間でのポリシーベースルーティングを説明しているが、この機能は今回の比較の中核ではなかった。
セキュリティ機能は、別の測定上の問題を生む。暗号化、ファイアウォールルール、トークン制御、検査を処理するゲートウェイは、最小限のルーターよりも多くの作業を行う。公正な比較では、有効化する機能を揃えるか、その運用上の価値を説明しなければならない。
DPUオフロードはホストリソースを温存できるが、DPUは無料の容量ではない。電力を消費し、管理を必要とし、サーバーアーキテクチャの一部を占有する。関連する経済指標は、総インフラコストに対するクラスター全体の出力である。
「GPUサイクルを解放する」というベンダーの主張にも、慎重な表現が求められる。ネットワークサービスは、GPUそのものではなく、ホストCPUリソースと直接競合することが多い。より優れたルーティングはGPU利用率を高め得るが、DPUが新たなアクセラレーターコアを生み出すわけではない。
3.24倍という結果は、極端な一つのシナリオにおけるボトルネック管理の優位性を示す証拠として最も信頼できる。容量計画で一律の倍率として扱うべきではない。ServeTheHomeも、これを観測された利益の上限に近いものとして説明している。
レポートはより控えめな例も示した。1.25倍の改善は、4基のGPUをベースラインとして5基分の出力を得ることに似ている。この比喩は経済的な重要性を伝えるが、本番環境での改善幅は各クラスターに依存する。
チームは独自のプロンプト長分布、同時実行数の曲線、キャッシュ再利用、モデル構成、サービス目標を再現すべきだ。その後、一貫した構成で長時間にわたり比較する必要がある。短時間のデモでは、すべての運用障害を捉えられない。
信頼できるパイロットには、テレメトリ障害と古いメトリクスも含めるべきだ。ルーティングコントローラーがGPUの状態を見失った場合、運用担当者は問題をどれほど迅速に検知するかを知る必要がある。予測可能なフォールバックポリシーも必要となる。
テストでは、DPU障害、コントロールプレーンの中断、ネットワーク分断を扱うべきだ。アクティブなリクエストが維持されるか、新規トラフィックが安全に移行するかを示す必要がある。完全に正常な稼働時のパフォーマンスは、本番運用の準備状況の一部にすぎない。
ラボでの優位性が実運用へ持ち込めるかを示す三つのシグナル
次の検証課題は、F5が説得力のある過負荷時の結果を、通常の本番ワークロード全体で再現可能な改善へ転換できるかどうかだ。
第一のシグナルは、独立したワークロード再現だ。購入者には、複数のモデル、サービングフレームワーク、プロンプト分布にわたり、生データと完全な構成を公開するテストが必要である。結果では、DPUオフロードとテレメトリ駆動スケジューリングを分離すべきだ。
中程度の負荷でも一貫した改善が得られれば、F5の主張はより強くなる。意図的なキャッシュ過剰割り当て時にのみ効果が現れるなら、対象となるユースケースは狭まる。どちらの結果も、容量計画に役立つ情報を提供する。
第二のシグナルは、より広範なデプロイ実績だ。F5とNVIDIAはエンタープライズおよびGPUサービスプロバイダーを対象ユーザーとしているが、名前を明かした本番事例があれば、運用モデルはより明確になる。有用な事例では、クラスター規模、トラフィック変動、観測された障害モードを説明すべきだ。
本番環境の証拠では、完全なセキュリティ制御を有効化した後も、チームが約束された容量向上を維持できるかも示すべきである。トークンガバナンス、暗号化、テナント分離、監査はいずれも作業を追加する。それらを合わせた影響は、機能を削ぎ落としたベンチマーク以上に重要だ。
第三のシグナルは、オープンなゲートウェイおよび推論ルーティングプロジェクトからの反応だ。これらのプロジェクトが、同等のGPUテレメトリ、プレフィックス認識、キャッシュ認識型配置を追加すれば、F5のルーティング優位性は標準的な機能になる可能性がある。
その結果、競争の焦点は運用統合、DPUサポート、セキュリティポリシー、ベンダーサービスへ移るだろう。また、より多くのデプロイモデルを通じてAI対応トラフィック管理を利用可能にし、ユーザーにも利益をもたらす。
F5はすでにこれらの層を組み合わせているため、有意義な立場を維持している。同社のplatform overviewでは、BNKをアプリケーションデリバリー、セキュリティ、ポリシーを横断する統合Kubernetesトラフィック管理として位置付けている。DPUオプションは、このモデルをAIインフラへ拡張する。
それでも、プラットフォームの幅広さが立証責任を取り除くわけではない。クラスター運用者は、イングレスとサービスプレーンを再設計する前に、ワークロード固有の測定を求めるべきだ。ピーク時の毎秒トークン数だけでなく、完了リクエスト当たりのコストを測定すべきである。
開発者にとって、この動向は、モデルコードだけではもはや推論パフォーマンスを決定しないことを示している。リクエスト配置、キャッシュの局所性、キュー管理、インフラ分離は、同一GPUが完了できる作業量を大きく変え得る。
エンタープライズの購入者にとって、この話の本質は拡張前の利用率にある。電力、ラック容量、納入スケジュールが成長を制約する場合、よりスマートな制御層は追加アクセラレーターの導入より実用的になり得る。
F5のAIロードバランシングの結果は、クラスターが最も厳しい局面にあるときに最も強い主張を展開する。ピーク時の負荷は、容量購入とユーザー体験を左右することが多いため、これは価値がある。同時に、慎重な検証が最も重要になる局面でもある。
3.24倍という数値を採用する前に、それを生んだ条件を再現するべきだ。自社のモデルとポリシーを用いて、通常トラフィック、持続的なピーク、障害復旧を比較する。そして決定的な問いを投げかけるべきだ。よりスマートなルーティングは、解消する以上の運用リスクを増やすことなく、次のハードウェア購入を先送りできるのか？
