Oracle Cloud InfrastructureでGPUのパワーを活用して通信事業者のイノベーションを加速し、カスタマー・エクスペリエンスと運用効率を向上 (2024/04/17)
Oracle Cloud InfrastructureでGPUのパワーを活用して通信事業者のイノベーションを加速し、カスタマー・エクスペリエンスと運用効率を向上 (2024/04/17)
https://blogs.oracle.com/cloud-infrastructure/post/telco-innovation-gpus-oci-operational-efficiency
投稿者：Deepak Soni | AI Infra and GPU Specialist
Yuri Rassokhin | Distinguished Architect - HPC4Enterprise
Khalid Odeh | Master Principal Cloud Architect
通信(電気通信)企業は、ソーシャル・メディアの監視、顧客情報、ネットワーク・トラフィック、運用データなど、大量のデータを処理します。顧客満足度の向上、顧客ロイヤルティの強化、パーソナライズされたカスタマ・エクスペリエンスの提供という需要の高まりに伴い、通信事業者は、顧客ライフサイクルのどの時点においても、インテリジェントなコンタクト・センター、プロアクティブなソーシャル・メディア、ブランドの評判保護および健全な意思決定のための効率的なソリューションを必要としています。
通信事業者は、コール・センターの対話型音声応答(IVR)システムおよびソーシャル・メディアのインタラクションをカスタマ・サポートやマーケティングに使用する際に、いくつかの特定の課題に直面しています。まず、音声認識および自然言語処理(NLP)テクノロジが、必ずしも顧客の音声、アクセントまたは方言を正確に解釈するとは限らないため、コミュニケーションやフラストレーションが生じる可能性があります。ソーシャル・メディアでは、顧客からの問い合わせ、苦情、フィードバックに効果的に対応するために、リアルタイムの監視機能と対応機能が必要です。より広範なマーケティングのために、魅力的で視覚的に魅力的なコンテンツを開発するには、テキスト、画像、ビデオ、インタラクティブな要素を含むマルチモーダル形式の創造性と専門知識が必要です。
これらの課題やその他の課題に対処するために、通信事業者はOracle Cloud Infrastructure(OCI)上のGPUを使用して、ネットワークの最適化、不正検出、カスタマー・エクスペリエンス、パーソナライズされたマーケティングなど、さまざまなアプリケーションの機械学習(ML)と生成AIを強化できます。OCI上のGPUは、並列処理アーキテクチャによりディープ・ラーニング・モデルのトレーニングと導入に優れ、通信における複雑なMLタスクの処理に適しています。Generative AIは、ソーシャルメディアの投稿、マーケティング資料のコンテンツの生成を支援し、コールセンターのエージェント用のスクリプトを生成して、カスタマーサービスの応答を改善できます。
IVRパーソナライゼーションのユースケースをシミュレートすることで、パフォーマンスを向上させ、インサイトまでの時間を短縮し、効率性を高め、従業員の生産性を向上させます。顧客のクエリをより正確かつ会話的に解釈して対応することで、IVRシステムの自然言語理解能力を強化します。
AIモデルのインスタンスはいくつですか。
このユースケースでは、個別のAIモデルを使用し、相互に独立してリソースを消費します。さらに、このユースケースでは、アラビア語のJAISや、PyTorch、HuggingFaceなどの様々なMLライブラリなど、様々なAIモデルを適用できます。
ただし、受信問合せのスループットは、AIモデルごとに異なります。各AIモデルのリソースを適切に設計するために、予測スループットを個別に評価しました。AIモデルをこのAIモデルの必要な数のインスタンスにマッピングするIVRパーソナライゼーションの論理チェーンを、次の例で説明します。
IVRのパーソナライゼーション:
- 1か月あたり1,000万人の顧客の「対話」
- 10M/30/24/60 = 231の同時ダイアログが毎分開始します。
- 典型的な対話の3分を想定すると、231*3 = 693の対話が同時に行われます。
- お客様がすべての質問に3秒かかり、回答に6秒かかるとします。音声合成が顧客発話の終了から1秒以内に開始された場合、これらのダイアログは、10秒に1回、それぞれ= 0.1リクエスト/秒でLLMにリクエストを送信します。そのため、すべてのダイアログについて、693*0.1 = 70リクエスト/秒が発行されます。
- AIモデルのインスタンスが対話型レイテンシ予算内で3リクエスト/秒を処理できると仮定すると、IVRパーソナライズ・モデルの70/3 = 24インスタンスでリクエストのスループットが予測されるため、顧客はランダムな遅延なしで迅速なレスポンスを享受できます。
論理チェーンには、次のニュアンスが含まれます。
- 顧客とAIの対話は、一連の顧客要求とそれに続くAIからの応答で構成されていることを前提としています。これらの要求の間に、AIの観点からは何も起こっていない。事実上、AIは人間の次の要求を待つためにアイドル状態のままです。
- 推論は、AIモデルと基礎となるMLライブラリに大きく依存します。この例では、PyTorchでの経験に基づいて、持続的に最短のレイテンシを達成するために、一度に3つのリクエストを受け取りました。ただし、この見積りは異なる場合があります。
- いずれの場合も、信頼できる推定のために数値を切り上げます。
調査が完了した後、IVRパーソナライズのための単一のAIモデルの24のインスタンスをマップし、消費者の要求量を処理しました。
GPUデバイスはいくつですか?
IVRパーソナライゼーションのために最大24個のAIモデルのインスタンスを一度に実行する必要があることがわかりましたので、これらが消費するGPUデバイスの数を計算できます。
320GBのGPU RAMフットプリントでLLAMA2 70Bを使用すると、最大320GB * 24 = 7680GBのGPU RAMを消費します。
コンピュート・インスタンスはいくつですか。
コンピュート・インスタンスBM.GPU.H100.8、それぞれ640GB GPU RAMごとに8つのデバイスを使用する場合は、7680/(80GB*8) = 12のコンピュート・インスタンスをデプロイする必要があります。この構成は、IVRパーソナライズ・ユース・ケースで最大1000万件の推論リクエストを処理するために、本番層で行われます。
リソースの合計量
本番環境で1,000万件のリクエストに対して12のコンピュート・インスタンスを推定しているため、ここではリソースの合計量を最適化する機会があります。次の表では、プライマリ・サイトとDRサイトの間にストレージのリアルタイム・ミラー化があります。
| Tier | Primary Site | DR Site |
| PROD | 12x OCI BM.GPU.H100.8 | 1x OCI BM.GPU.A10.4 12x OCI BM.GPU.H100.8 |
| PREPROD | 9x of DR prod utilized | |
| QA | 2x of DR prod utilized | |
| DEV |
1x of DR prod utilized 1x OCI BM.GPU.A10.4 |
生産、生産前、品質保証(QA)および開発層をマスターおよびディザスタ・リカバリ施設に分散させることを目指しています。このレイアウトでは、ディザスタ・リカバリ・サイト上の本番層を迅速にスイッチオーバーできるように、完全に複製する必要があります。
重複した本番層は99%の時間アイドル状態になると予想されるため、残りのマスター層、本番前、QAおよび開発用にリソースを再利用できます。本番の唯一の差別化はリクエストの最大(本番)スループットですが、ハードウェアとソフトウェアの構成は変わりません。
そのため、ディザスタ・リカバリ本番層を再利用して、次のリソースを飽和させることができます。
- マスター開発の50%: 残りの50%はマスター・サイトにとどまり、失敗に関係なく、開発の50%を常に使用可能にしています。
- QAの100%は、QAが開発プロセスと同一であり、災害時にQAを使用できないことを前提としています。
- QA模倣品が本番スループットの75%(9/12)で生産された場合、本番前の100%
ソリューション・アーキテクチャ:
次の図は、このユースケースのソリューション・アーキテクチャを示しています。ヘッドノード1および2は、ログイン目的およびマスターフェイルオーバー構成で使用されます。サーバー・ノードは、AIモーダルのトレーニングのためにサーバー・ノードとともにローカルで使用可能なコンピュート・オプション(BM.GPU.A10.4、BM.GPU.4.8およびBM.GPU.H100.8)を備えたプライベート・ネットワーク内にあります。
オラクルでは、微調整のために2つのBM.GPU.A10.4コンピュート・インスタンスをデプロイし、これらをプライマリとDRにも分散しています。
このレイアウトでは、次の前提が適用されます。
- 災害からの復旧はわずか数キロです。配置が非同期モードでより長い範囲に展開され、スイッチオーバー待機時間が数十秒以下で測定される場合、これも実行できます。
- 試作は生産能力の75%を模倣します。
- QAは、災害時に利用できなくなる可能性があります。
多くの顧客にとって実用的ではありませんが、このような仮定により、QAの拡張などの顧客チューニングは、本番前の生産スループットのより少ないシェアを模倣するコストで、サイト全体で常に使用可能にできます。最終的に、このようなレイアウトにより、32%のコスト削減(37個ではなく25個のBM.GPU.H100.8コンピュート・インスタンス)が可能になり、同時に継続的な開発、スイッチオーバーのための数秒、データの損失ゼロが提供されます。
まとめ
Oracle Cloud Infrastructure上のGPUは、データ処理や分析からAI、ビデオストリーミング、仮想化、サイバーセキュリティまで、さまざまなタスクにわたって通信事業者に大幅なパフォーマンス向上、スケーラビリティ、コスト効率を提供できます。GPUテクノロジーをTelcoインフラストラクチャに統合することで、イノベーションを推進し、サービス品質を向上させ、最新の通信ネットワークとサービスの需要の高まりに対応することができます。
さらに学習するには、次のリソースを参照してください。
コメント
コメントを投稿