分散 AI 推論：通信サービスプロバイダーのリーダーが知っておくべきこと

現在、すべての通信サービスプロバイダーが AI の運用を開始しています。ユースケースには、カスタマーケア用チャットボット、ネットワーク運用のコパイロット、外部企業の顧客向けのマネージド AI-as-a-Service (AIaaS) などがあります。 

厄介なのは、ユースケースとビジネスケースの相関関係です。この場合、鍵となる要素は、グラフィックス・プロセッシング・ユニット (GPU)、テンソル・プロセッシング・ユニット (TPU)、ニューラル・プロセッシング・ユニット (NPU) などの AI アクセラレーターのコストです。推論あたりのコストによって、これらの AI アクセラレーターが利益率を向上させるか、低下させるかが決まります。コストを抑えるためには、選択する AI モデルが、そのモデルをデプロイして分散した地域規模でサービスを提供する方法と同じくらい重要になります。

最近の記事で言及しているように、Red Hat の担当者は、モデルのサイズだけでなく、トラフィックとスケールによって引き起こされるアーキテクチャの問題として、推論のデプロイの課題に取り組んでいます。このブログ記事では、その調査結果をまとめています。

推論あたりのコストが損益に与える影響

各 AI リクエストには、同じハードウェア上に次の 2 つの異なるジョブがあります。 

• まず、請求履歴、トラブルチケット、ネットワークログ、あるいは処理が必要なその他の情報など、プロンプトや入力を読み込みます。 
• 次に、その入力に対する応答を一度に 1 トークンずつ生成します。

読み取りフェーズでは、ユーザーが最初の単語が表示されるまでの待ち時間を決定します。書き込みフェーズでは、会話が円滑に進むか、あるいは頻繁に停止と開始が繰り返されるかを決定します。これら 2 つのフェーズでは異なるリソースプロファイルと異なる最適化が必要であり、AI アクセラレーターのリソースを共有する場合、それらは競合します。

この対立関係は、AI のユースケースやワークロードの種類によって、損益に異なる影響を与えます。たとえば、カスタマーケアのチャットボットでは、ボットが停止してセッションがエージェントにエスカレーションされると、コンタクトあたりのケアコストが上昇します。エンタープライズ AI のオファリングでは、レイテンシーに関するコミットメントを満たさなかった場合、サービスレベル契約 (SLA) のペナルティが発生します。また、クエリあたりのコストが契約で定められた価格を超える場合、企業間 (B2B) AI 製品のマージンが減少します。 

デプロイに関するミスの多くはトレードオフに関するミスであり、チームが自社製品の販売にはつながらない指標を最適化しようとしたときに発生します。AI が収益を生み出す具体的な方法をいくつか検討することで、ワークロードの種類ごとに適切な導入方法を明らかにすることができます。

カスタマーケア

カスタマーケアは最も分かりやすい例です。ケアトラフィックは、数千件もの短いチャットセッションが同時に発生するもので、各通話で同じ料金プランとポリシーのプリアンブルが再利用されます。Red Hat の担当者は、Red Hat の vLLM ベンチマークから以下のことを特定しました。

• 読み取りプールと書き込みプールを分割して適切なサイズに設定すると、このトラフィックパターンにおいてコストが 25 - 40% 削減されます。
• オープンソースの llm-d プロジェクトによって実装されているスケジューリング手法であるキャッシュ対応ルーティングでは、プロンプトの再利用率が高い場合に、GPU あたりのトークン数が 2 - 3 倍に増加し、トークンあたりのコストが 3 - 5 倍に低減しました。

本番システムではこのレベルの改善は見られませんが、測定したすべてのワークロードでその傾向は見られました。毎月数千万件のケア対応が発生する場合、推論コストを数ポイント削減するだけで、新たなアクセラレーターの設備投資 (CapEx) を行わずに、次の製品サイクルに必要な費用を確保することができます。

ネットワーク運用

ネットワーク運用はそれとは逆のパターンになります。ユーザー数が少なく、処理されるドキュメントは非常に長くなります。インシデント分析では、同じランブック、トポロジーレコード、ベンダーマニュアルが継続的に読み込まれるため、主要なコスト抑制手段は、すでに処理された内容をキャッシュすることです。その結果として、診断までの時間が短縮され、シニアエンジニアへのエスカレーションが減少します。

エンタープライズ向けマネージド AI

AI をエンタープライズ顧客に販売することで、多数のテナント、階層化された SLA、急増する需要という第 3 の側面が加わります。このようなシナリオでマージンを保護するには、次の 2 つのメカニズムを利用できます。

• モデルのカスケード化により、定型的なクエリを小規模モデルに送信し、処理が困難なクエリのみをエスカレーションすることで、単純なクエリが大部分を占める場合のクラスタコストを 40 - 60% 削減できます。
• サービスレベル目標（SLO）に連動したアクセス制御は、SLA に違反する可能性のあるリクエストをキューに格納して失敗に回すのではなく、即座に拒否します。これにより、負荷がかかっている状況下でも契約における信頼性を維持することができます。

表 1 に示すように、これら 3 つのユースケースを組み合わせることで、1 つの共有 AI アクセラレータープールに賭けるよう強いるのではなく、ゴールド、シルバー、ブロンズの各価格帯のモデルとして活用することができます。しかし、さらに 2 つの制約条件が、サービスプロバイダーにとっての全体像を補完するとともに、AI サービスを特定の顧客に合わせてカスタマイズする方法を示しています。 

クラウドバースティング機能を備えたソブリン AI

ソブリンルールでは、サブスクライバーのデータは発生した国に留めることが求められます。このニーズに最も適したパターンは、ピーク時以外は停止状態を維持するクラウドバースティングを使用した、規制に準拠したオンプレミスのベースラインです。Red Hat OpenShift AI のような単一のコントロールプレーンが 2 つの環境の整合性を維持するため、コンプライアンスは設定管理の徹底のみに依存しません。

エッジコンピューティング

ネットワークエッジにおいて、同時セッション数がおよそ 100 以下である場合、適切な解決策は、アクセラレータ 1台につき 1 つのモデルを使用し、複雑なプーリングを行わないことです。  負荷の高いクエリはバックホール経由でエスカレーションすべきであり、これにより、トランスポートコストが処理量ではなく複雑さに比例して増加するようになります。

表 1ワークロードの種類が具体的なビジネス成果にどうつながるか

プロバイダーがこれらの各ユースケースを検討する際に問いかけるべき質問は以下のとおりです。

• カスタマーケア：現在、完全自動化されたケア会話にはどれくらいのコストがかかるのでしょうか。また、そのコストに最も大きな影響を与える単一の変更点は何ですか？適切な回答は、実際のトラフィックに基づいて測定された「1 件あたりのコンタクト処理コスト」を挙げ、1 つのテスト対象の施策と、その施策実施前後の数値を提示します。
• ネットワーク運用： エンジニアはインシデント記録から有用な回答を得るまで、どれくらいの時間を待たなければならないのでしょうか。また、毎回同じ文書が再処理されているのでしょうか。適切な回答は、ランブックやサイトレコードが再読み込みではなくキャッシュから提供される頻度と、最初の回答までの時間の傾向を示します。
• B2B サービス：ピーク負荷時に最初に違反となるエンタープライズ SLA はどの点ですか。また、その解決策はハードウェアを追加することですか、それともルーティングを改善することですか。適切な回答は、負荷テストで限界に達したティアを特定し、購入リクエストの前にルーティングやアクセスの修正が試行されたことを示します。
• 主権とピーク： データレジデンシーのルールを満たすためだけに、ピークイベント間でアイドル状態になっている容量はどのくらいありますか。適切な回答は、ベースラインの使用状況と、待機中のコストが発生しないバースト設計を報告します。
• エッジおよびフィールド： フィールドクエリのうち、どの程度の割合が中央クラスタに送り返され、その転送コストはどの程度になるのでしょうか？適切な回答は、サイトごとのローカルの解決率を示し、オンサイトモデルで処理できないクエリのみをエスカレーションするようにします。

投資パス

AI のユースケースを確立したら、次のステップは、効率的かつコスト効率の高い方法でそのユースケースを構築することです。目的地よりも順序が重要になります。各段階はロードマップの日付ではなく測定に基づいて開始され、それぞれが次の段階に進む前に費用を回収します。

1. 1 つのノードから開始する：実際のケアまたはネットワークトラフィックで、単一のサービングインスタンスを 1 週間実行します。そのベースラインが、その後のあらゆる決定の基準となります。合成されたラボトラフィックは誤解を招く可能性があります。
2. インテリジェントなルーティングを追加する：2 つ目のレプリカのスループットは、1 つのレプリカの 1.8 倍未満です。このギャップは、別のサーバーがすでに保持しているコンテキストを再読み込みする必要があるサーバーにリクエストが到達していることを意味します。これは容量不足ではなくルーティングの無駄であるため、ハードウェアを購入する前に修正してください。
3. 読み取りプールと書き込みプールを分離する：この措置は、測定の結果、一方のフェーズがもう一方のフェーズのリソースを著しく奪っており、運用の複雑さが増すデメリットを上回る効果が得られることが示された場合にのみ行います。
4. マルチテナントグリッドを導入する複数の製品や B2B 顧客がプラットフォームを共有する場合、階層化された SLA を保護するメカニズムはその複雑さに見合う価値を発揮します。しかし、その規模に達しない場合は、そのメカニズムに伴う労力の無駄になります。

各ステップでベースラインがリセットされます。AI 推論戦略は、一度限りのアーキテクチャの確定ではなく、慎重な判断に基づく一連の試行錯誤なのです。サービスプロバイダーは、すでに無線周波数帯域においてこの手法を実践しています。つまり、投資収益率（ROI）が見込める製品に容量を割り当て、継続的に測定を行い、アイドル状態にあるリソースを回収するというものです。AI アクセラレーターにも同様の対応が必要です。

まとめ

分散 AI 推論は、サービスプロバイダーの AI 製品がマージンを維持できるかどうかを左右します。このブログ記事で概説した内容のうち、予算をすべて投じるような大胆な取り組みを求められるものは一切ありません。どの仕組みも、次の段階に進む前にサービスプロバイダーのトラフィックでその有効性が実証される、慎重な段階を踏んだものです。表 1 には、まずどこを確認すべきかが示されています。

ケア、ネットワーク、または B2B ポートフォリオにおいてこれに取り組む準備ができたら、トラフィックデータを Red Hat アカウントチームにご提示ください。vLLM、llm-d、および Red Hat OpenShift AI は、Red Hat が現在サービスプロバイダーと共にこのパターンを実行している方法です。また対話は、一般的な設計図ではなく、お客様のニーズから始めることで迅速に進みます。