最近、取締役会や決算説明会、相次ぐ論説記事で、ある1つの考え方が盛んに語られています。それは、AIの経済性を次に大きく向上させるのは、チップの高速化だけではないというものです。
この主張は妥当ですが、そこから得られる教訓はさらに広範です。トークン当たりのコストが初めて大幅に低下したのは、シリコンとソフトウェアの両面で進歩が積み重なった結果です。具体的には、アクセラレーターの高速化、メモリシステムの改善、低精度フォーマット、PagedAttention、継続的バッチ処理、Key-Valueキャッシュの最適化、vLLMなどの推論フレームワークが挙げられます。業界では、各アクセラレーターから有用な処理能力を引き出す効率が飛躍的に向上しました。
次に業界は、同じ手法を適用できる新たな領域を探し、データパス、とりわけストレージに着目しました。この取り組みは不可欠ですが、それだけでは十分ではありません。
データパスだけでは不十分
AIファクトリーにおけるストレージは、もはや受動的な存在ではありません。モデルはストレージから読み込まれ、チェックポイントもストレージから復元されます。検索拡張生成は、厳しいレイテンシ要件の下でストレージに依存します。規模が十分に大きくなると、コンテキスト層とキャッシュ層がGPUやシステムメモリの外部にまで拡張される場合があります。すでに完了した処理を再計算することは、アクセラレーターの利用方法としてコストが高いためです。
しかし、AIの経済性は、相互に関連する2つのフローによって左右されます。1つは、モデルに供給されるデータの移動です。つまり、バイトデータがどこに保存され、どれだけ迅速に取得でき、どの程度の頻度で移動する必要があるかという点です。もう1つは、推論リクエストがたどる経路です。ユーザー、アプリケーション、またはエージェントから、トラフィック管理とポリシー適用を経てモデルサーバーに到達し、再び戻っていきます。
その2つ目のフローでは、転送中のデータが運ばれます。多くの本番環境では、コンピューティングやストレージと比べて、依然として測定も最適化も十分ではありません。次の段階で効率化が進むか、さらなる無駄が生じるかは、ここで決まります。
トークン税
GPUノードでは、ホストの中央処理装置（CPU）も稼働しています。ネットワーク処理、トランスポート層セキュリティ（TLS）の終端、ポリシーの適用、東西トラフィックの処理、テレメトリの生成、インターフェースとアクセラレーター間のデータ転送を担います。これらの処理はいずれも、トークンを直接生成するものではありません。CPUがボトルネックになると、有効な推論出力が減少します。
これを「トークン税」と呼びましょう。ホストリソースを消費するインフラストラクチャのオーバーヘッドが、気付かないうちにノードの経済的な生産性を低下させます。必ずしも、より高速なホストプロセッサが解決策になるとは限りません。大規模環境では、対象となるネットワーキング、暗号化、トラフィック管理、セキュリティの各機能を、すでに通信経路上にあるプログラマブルインフラストラクチャへ移行できます。
F5が委託したThe Tolly Groupによる独立テストでは、NVIDIA BlueField-3 DPU上に導入されたF5 BIG-IP Next for Kubernetesが、テスト対象のCPUホスト型代替製品と比較して、トークンスループットを最大40%向上させ、最初のトークンが生成されるまでの時間を61%短縮し、リクエストレイテンシを34%低減しました。
財務面への影響は明確です。一定規模のインフラストラクチャで、求められるサービスレベル目標を満たしながら販売可能なトークンを1.4倍生成できれば、トークン当たりのインフラストラクチャコストは約29%低下します。需要があれば、アクセラレーター当たりの収益も増加する可能性があります。これは、単にネットワークが高速であると述べるよりも、ビジネス上有用な訴求です。
ルーティングはスケジューリングへ
従来の負荷分散では、リクエストを振り分けます。この方法が機能するのは、各リクエストをおおむね同等に扱える場合です。大規模言語モデルの推論では、リクエストの処理コストがコンテキスト長、出力長、キャッシュの状態、モデルの選択、キューの深さ、現在のアクセラレーター負荷によって異なるため、この前提は成り立ちません。
- 短いプロンプトに対して短い応答を生成する場合、非常に長いコンテキストに対して長い応答を生成する場合よりも、コストが桁違いに低くなる可能性があります。
- ウォーム状態のキーバリューキャッシュに到達するリクエストでは、コストの高いプリフィルの再計算を回避できます。
- プリフィル負荷の高いリクエストとデコード負荷の高いリクエストが同じアクセラレーターに割り当てられると、互いに干渉する可能性があります。
- ステートレスなヘルスチェックでは、8件のリクエストがキューに入っているモデルサーバーも、キューが空のモデルサーバーも、同じように正常と判断される可能性があります。
こうした状況を把握できないトラフィックマネージャーは、その仕組み上、適切な配置判断を下せません。その代償は2つの形で現れます。1つは、ユーザーが最初のトークンを受け取るまでの時間として体感するレイテンシー、もう1つは、重複処理によってビジネス側に生じる再計算コストです。
したがって、AIファクトリーにおけるルーティングは、もはや単なるネットワーク機能ではありません。ネットワーク内で行われるスケジューリング判断です。モデルサーバーのリアルタイムの状態、キューの深さ、アクセラレーターのテレメトリ、キャッシュの局所性、推論フレームワークからのランタイムシグナルなど、あらゆるスケジューラーに必要な情報を活用できます。
セキュリティもコスト関数
AIファクトリーのセキュリティは通常、プロンプトインジェクション、データ漏えい、エージェントによる権限逸脱、規制上のリスクといった観点から論じられます。いずれも現実に存在するリスクです。F5の調査では、88%の組織がAIに関連する運用上またはセキュリティ上の課題を少なくとも1つ抱えていると回答しています。
ユニットエコノミクスの観点からも検討する必要があります。モデルの実行前にリクエストをブロックすれば、不要な推論コストを回避できます。一方、完全なレスポンスが生成された後にのみリクエストを評価する場合、ポリシーが適用されるまでにコンピューティングリソースが消費されます。スクレイピングトラフィック、リトライストーム、ループから抜け出せないエージェント、繰り返されるジェイルブレイクの試行などが重なると、制御を適用する位置がリスクだけでなくコストにも影響し始めます。
原則は、すべての制御を1か所に集約することではありません。保護対策によっては、アプリケーションレベルまたはモデルレベルでより詳細な評価が必要となり、それらの制御自体にもコンピューティングコストがかかります。目指すのは、実効性のある制御のうち最も低コストなものを実用上可能な限り早い段階で適用し、効果が見込める箇所でより詳細な検査を行うことです。
エージェント型トラフィックは、この問題をさらに深刻化させます。エージェントは再試行や処理の分岐を行い、モデルを呼び出すツールを呼び出し、そのモデルがさらに別のモデルを呼び出します。その結果、人間による利用を想定したレート制限では吸収できない、マシン速度のトラフィックが発生します。障害が必ずしも侵害として現れるとは限りません。単に請求額の増大として現れることもあります。
商用化レイヤーが欠けている
オペレーターがテナント、モデル、ユーザー、アプリケーション別にトークン数を集計できなければ、価格設定、使用量の計測、コストの配賦、公平性の確保、利益率の維持が難しくなります。インフラストラクチャでは、消費電力や稼働状態に関する優れたテレメトリを取得できても、収益の帰属については可視性が限られる場合があります。
マルチテナンシーは、この問題をさらに深刻化させます。効果的な分離とテナント単位の使用量計測がない共有GPUインフラストラクチャでは、あるテナントの突発的な負荷増大が、別のテナントのサービスレベル違反につながる可能性があります。AIクラスターにおけるノイジーネイバーは、単なるパフォーマンス上の問題ではありません。顧客離れにつながる可能性があります。
推論パスでは、ユーザー、アプリケーション、モデル、テナントを横断してリクエストとレスポンスを観測できるため、最も一貫性のある横断的な視点が得られます。モデルサーバーと課金システムも引き続き重要ですが、測定と制御を一貫して適用できるのは推論パスです。
推論サービスプレーン
これらの課題を総合すると、第3のアーキテクチャプレーンが見えてきます。コンピュートプレーンは、誰もが予算を割り当てるGPUとアクセラレーターです。データパスは、ストレージ、取得、キャッシュ、メモリを対象とします。推論サービスプレーンは、リクエストをアクセラレーターに到達させる方法、実際のシステム状態に基づくスケジューリング、不要なコンピューティングリソースを消費する前に停止する処理、計測対象、課金先を管理します。
このレイヤーはすでに存在しますが、多くの場合、ロードバランサー、APIゲートウェイ、サービスメッシュ、Webアプリケーションファイアウォール、テレメトリコレクター、そして最後にスプレッドシートといった個別の要素を寄せ集めた結果にすぎません。共有テレメトリ、一貫したポリシー、意図的に配置された適用ポイントを備えた、統合されたシステムとして設計されることはほとんどありませんでした。
F5 BIG-IP Next for Kubernetesは、ホストまたはNVIDIA BlueField DPU上で実行できます。推論パス全体にわたり、Kubernetesネイティブのトラフィック管理、セキュリティ、マルチテナントポリシー、オブザーバビリティ、インテリジェントな負荷分散、トークンガバナンスを提供します。
アプリケーションレイヤーでは、F5 AI Gatewayが、プロンプト、レスポンス、モデル、ツール全体にわたって、モデルとエージェントのガバナンス、ルーティング、キャッシュ、計測、セキュリティ制御、監査可能性を追加します。
個々の製品よりも重要なのは、アーキテクチャの方向性です。ポリシーを明確に定義し、最も効果的な場所で適用するとともに、インフラストラクチャ層とアプリケーション層の間でテレメトリを共有します。これにより、運用担当者は可視性の欠如を減らし、各チームが異なる制御を個別に維持する状況を防げます。
意図を持って経路を設計する
次回のAIインフラストラクチャレビューでは、3つの点を確認する必要があります。すでにプロビジョニングされているアクセラレーター容量から、どれだけの有用なトークンを生成できているでしょうか。トークン生成に直接つながらない処理に、ホストの処理能力がどれだけ消費されているでしょうか。適用制御が有効になる前に拒否対象のリクエストがモデル実行まで到達した場合、どれだけのコストが発生するでしょうか。
業界全体で、議論の焦点はキャパシティから変換効率へ、つまり、どのようなインフラを保有しているかではなく、そこからどれだけの価値を確実に引き出せるかへと移りつつあります。AIの経済性を次の段階へと大きく向上させるのは、チップの高速化やストレージの強化だけではありません。推論パスを経済システムとして捉えることが、その向上につながります。
コンピュートプレーンはすでに導入されています。データパスの最適化も進んでいます。一方、推論サービスプレーンでは、まだ主導権が確立されていません。
詳細については、AIパフォーマンスレポートをご覧ください。
著者について
関連するブログ記事
経営幹部が抱くAIに関する4つの誤解
AIに関する誤解は数多くあります。ここでは、組織が自社環境にAIを導入する際に見直す必要があるかもしれない4つの誤解を紹介します。
IT/OTコンバージェンスの現状と、セキュリティを最優先すべき理由
ITシステムとOTシステムの融合が進むにつれ、攻撃対象領域は拡大します。組織が安全に統合する方法と、F5 ADSPが大規模な運用の保護にどのように役立つかをご紹介します。
AIのレイテンシ：セキュリティを犠牲にできない理由
AIのレイテンシは、単なる速度の問題ではありません。パフォーマンス、セキュリティ、信頼性のバランスを考慮したシステム設計が重要です。
AIアプリケーションを大規模に提供する：ADCの役割
AIアプリケーションを確実に提供するには、高速なモデルや柔軟に拡張できるインフラストラクチャだけでは不十分です。AIアプリケーションの利用方法を管理するための制御レイヤーが必要です。
MCP：AI対応のアプリケーションデリバリを実現する鍵
Model Context Protocol（MCP）は、最新のアプリケーションにおける安全で低遅延なAI統合を可能にします。将来を見据えたアプリケーションデリバリ戦略にMCPが不可欠な理由をご覧ください。
AIガードレールとは？基盤モデルプロバイダーの枠を超えて進化する安全対策
急速に変化する組織の脅威領域におけるリスクをより包括的に捉えるために、AIガードレールの進化が必要な理由をご覧ください。