ForeSight Voice Miningは, お客様とオペレータの通話を音声認識技術によって可視化し, 分析を行うことで, コンタクトセンターの業務改善・効率化を実現するサービスです。

多くのコンタクトセンターでは, 通話終了後にオペレータが通話内容を要約し, 顧客管理システムに登録して管理を行っています。
しかし, 通話の要約作業には以下のような課題がありました。

• ・長時間の通話の場合, 要約に時間がかかる
• ・オペレータごとに要約の粒度が異なる

これらを解決するために, ForeSight Voice Miningに生成AIを連携し, 通話内容を自動要約することで, 要約にかかる時間の削減と要約結果の均質化を実現しています。

通話の要約を生成AIで実施するにあたり, 当初のプロンプトは「この通話を要約してください」というシンプルなものでした。
最近では生成AIの性能が向上し, このような簡単なプロンプトでも適切に要約してくれます。
しかし, コンタクトセンターへの提案を進める中で, コンタクトセンターが求めているのは「通話をただ要約した結果」ではなく, 「顧客管理システムに登録し, 通話をしていない人でもそのコンタクトセンターにとって重要な内容がひと目で把握できる要約結果」であることがわかりました。

そのため, 要約を実施する際のファーストステップは, そのコンタクトセンターがどのような通話を受けていて, どのように顧客管理システムに登録していて, どのような人がその顧客管理システムを参照するのかを把握することです。
そのうえで適切な内容に通話を要約するプロンプトを試行し, 適切な要約結果になるように調整を行います。

生成AIの優れた点は, ある程度出力のフォーマットを指定することで, そのフォーマットに合った内容を通話の中から見つけて抽出し, まとめてくれることです。
通話の中で重要になる要素はコンタクトセンターごとに異なるため, 導入時にはまずそのコンタクトセンターの業務を理解することがポイントとなります。

連携の検討を始めた当初は, 生成AIの精度も低く, 音声認識の誤認識があると誤った要約になってしまうことがありました。
しかし, 連携を進めていく中で, 新たな生成AIが次々と発表され, 当初の想定を上回る効果を得ることができました。

○生成AIが誤認識を補正して要約してくれる

音声認識システムの課題として, 話者の周囲の環境, 声を収録するマイク, 通信環境などにより, 音声認識精度が向上したとしても, リアルタイムでの音声認識精度には限界があります。

しかし生成AIでは会話全体を理解することで, 音声認識システムが誤認識してしまった内容でも, ある程度は意味を推測して正しい音声認識結果として文章を要約してくれることが多いです。

○連続した発話でなくとも意味を理解して適切につなげてくれる

電話での会話では, 電話番号や名前を相手に正確に伝えるために, 連続して発話されずに「090の」「090ですね」「次が1234で」のような形で, 途切れ途切れだったり間にオペレータの復唱が入ることがほとんどです。

間違えて伝わらないようにするためには重要なことですが, 音声認識結果として見るときには, かなり見づらいものになります。

しかし, 生成AIの進化により, 名前や電話番号が途切れ途切れで認識されていたとしても, 生成AI側が内容を理解してくれることで, 名前や電話番号を人が読みやすいフォーマットに整形して出力してくれます。
そのため, どのお客様からの電話だったのかを把握することができ, 以前の問い合わせとの紐づけや今後のサービス提案方針をより個人にフォーカスしたものにすることができるようになりました。

導入効果としてはさまざまな声をいただきますが, 特に効果があったと考えているのは, 新人オペレータの要約についてです。
コンタクトセンターは人の入れ替わりが激しい業界です。
新人オペレータは応対後の要約を実施する際も, 要約ポイントなどのイメージがあまりついていない場合もあり, 要約をするということに大きなハードルを抱えていることが多かったそうです。

そこに生成AIによる要約を追加したことで, 一旦AIに通話を要約させることで, 自分の応対の中で顧客管理システムにどのようなことをポイントとして登録しなければならないかということがイメージできるようになり, 習熟が早まったとの声をいただきました。

私自身も資格勉強の際, 小論文が出てきたとき, 正解がイメージできず, うまく進めることができなかった経験があります。
参考書などを開いても, 自分の今の状態と一致しているものではなく, 思うように理解が進みませんでした。
しかし自分の回答を生成AIに添削してもらうことで, 自分の経験や状況をベースに課題などを教えてもらうことができ, 一気に理解が進みました。

生成AIにはさまざまな魅力があると思いますが, 私は自分に寄り添った回答をしてくれることが一番の魅力だと感じています。
何か新しいことを始めるとき, 生成AIは最初の一歩の道しるべになってくれると実感しました。

○推論フェーズにおける分散処理

推論フェーズについて, サービス利用ユーザが限定される, またはあまり多くない場合はネットワーク観点では問題となることはほぼないと考えられるため, 不特定多数のユーザを持つサービスの場合で考えます。

生成AIの推論はマシンパワー次第ですが, 多数の推論を同時に行うと処理が遅くなる, つまり生成AIからの回答が遅くなるリスクがあります。
回答が遅くなることはユーザストレスとなり, サービス品質が低下してしまいます。

○学習フェーズにおける分散処理

学習のフェーズについては, 生成AIとして代表的なLLM（大規模言語モデル）のモデルサイズはその性能に比例して増加傾向にあり, 1台のサーバに搭載可能なGPUでは学習が不可能, あるいは膨大な時間を要する場合が多いです。

そのため, 学習/推論ともに複数のサーバ/GPUに跨った分散処理の技術が用いられています。

○Megatron-DeepSpeedの紹介

今回は分散処理に用いられる代表的なフレームワークであるMegatron-DeepSpeedをご紹介します。

Megatron-DeepSpeedはMicrosoftが管理している以下を組み合わせたフレームワークです。
学習/推論両方で活用可能な分散処理が提供されています。

• ・Megatron-LM：NVIDIAが開発した大規模Transformerモデルをマルチノードで学習するための基盤
• ・DeepSpeed：Microsoftが開発した大規模モデルの学習/推論効率化のためのソフトウェア

○推論の効率化/高速化

Megatron-DeepSpeedに含まれるDeepSpeedの代表的な効率化/高速化技術をご紹介します。

・DeepSpeed Inference

学習済みモデルを使用して高速に推論を行うための以下のような最適化が含まれています。

• ・DeepFusion：生成AIの計算時には高速化のためにGPUが用いられます。このGPUとホスト側の計算の際にそれぞれのカーネル起動回数を減らし高速化するための技術です。
• ・SBI-GeMM：推論時の小さいバッチサイズにおいてメモリからパラメータの読み取りを高速化する技術です。
• ・モデル並列：Tensor Parallelism/Pipeline Parallelismなどがあります（詳細は以下「学習の効率化/高速化」で解説）。
• ・ZeRO-Inference：GPUメモリの利用を効率化するため, 必要なときに必要なレイヤーのみDRAMやNVMeからGPUメモリにロードして計算する技術です。
• ・Blocked KV Caching：Transformerモデルの計算に必要なKey Valueの値をブロックに分割してキャッシュすることで, 連続したメモリを確保する必要がなくなりメモリ効率を向上させる技術です。

○学習の効率化/高速化

Megatron-DeepSpeedに含まれるMegatron-LMの代表的な効率化/高速化技術をご紹介します。

・3D Parallelism

大規模なLLMを学習する際にGPU1つではモデルがGPUメモリに収まらず学習することができない場合があります。こういった場合に複数のGPUメモリにデータやモデルを分割して分散処理するための技術が3D Parallelismです。

3D ParallelismはData Parallel（学習データの分割）+ Tensor Parallel（モデルの分割）+ Pipeline Parallel（モデルのtransformerブロック方向の分割）のことを指します。

• ・DP（Data Parallel）：各GPUにロードされたモデルに対してデータセットを分割し渡すことで, 学習時間は論理的には1/N（データ並列数）となり学習時間が高速化できます。
  　一方でモデル自体の分割は対象としないため, Data Parallelだけでは大規模なLLMには対応できないと考えられます。
• ・TP（Tensor Parallel）：行列×行列の演算を並列化し, 各GPUは1/N（テンソル分割数）のテンソルだけを持つ分散処理です。
  　GPUメモリ制約の解消に役立ちメモリ使用を効率化できますが, 計算グラフに影響しない形で分割する必要があります。
• ・PP（Pipeline Parallel）：モデルをレイヤーの束で分割する分散処理です。例として, 32レイヤーあるモデルを4個に分割する場合は1GPUに8レイヤー割り当てられます。
  　TPと同様にGPUメモリ制約の解消に役立ちメモリ使用を効率化できます。
  　ただし, 各GPUごとに担当するレイヤーが異なるため, バッチサイズによってはGPU使用率が下がる可能性があります。
• 
• (出典：A Deep Dive into 3D Parallelism with Nanotron⚡️ | TJ Solergibert)

・ZeRO（Zero Redundancy Optimizer）

Megatron-DeepSpeedに含まれるDeepSpeedの代表的な効率化/高速化技術です。

通常データ並列では重複して持つ学習パラメータについて, 重複がないように各GPUに格納することでメモリ使用量を大幅に削減し効率化します。

(出典：ZeRO & DeepSpeed: New system optimizations enable training models with over 100 billion parameters - Microsoft Research)

生成AIに活用されるLLMの学習には, 上記でご紹介した通り複数のノード/GPUに跨った学習や推論が必要となります。
こういった環境にはデータセンターのような大規模な設備が必要となり, 一般的にそのネットワークはDCN（DataCenter Network）と呼ばれます。

○DCNの一般的なネットワーク構成

DCNは大きく以下のようなネットワークで構成されます。

・フロントエンドネットワーク

主にCPU処理がメインとなり外部との通信に用いられるLossyなネットワークです。

• ・推論時には外部から推論用のAPIが呼ばれ, 応答を返却する等に用いられます
• ・学習時にはHugging FaceやS3等の外部ストレージからのモデルやデータセットのダウンロード等に用いられます

・バックエンドネットワーク

主に分散学習等のGPU処理がメインとなり, GPU間通信が行われるLosslessが要求されるネットワークです。

○バックエンドネットワークの高品質化技術

分散処理のような大規模で高速な通信を行う際にはRDMA（Remote Direct Memory Access）という技術が用いられます。

RDMAはメモリから異なるサーバのメモリにOSを経由せずデータ転送を行う技術であり, 高スループット, 低レイテンシの通信を行うことができる技術です。

こういったRDMAを実現する技術ではGo-back-Nというパケットドロップが発生した際にドロップしたパケットのリクエストまで遡って通信を再開する方式が採用されています。
このGo-back-Nは通信負荷が高く性能影響が大きいため, パケットロスによる分散処理への影響が大きくなることから, バックエンドネットワークではLosslessなネットワークが条件として求められています。

分散処理のためのネットワーク高速化の技術として以下の観点でご紹介します。

• ・同一ノード内のネットワーク高速化技術
• ・ノードを跨ったネットワーク高速化
• ・ネットワーク機器での負荷分散による高速化

(出典：InfiniBand RDMA and RoCE Explained: Protocols, Messages, and Network Architecture | by NADDOD | Medium)

○同一ノード内のネットワーク高速化技術

NVIDIAが開発した「NVIDIA® NVLink™」「NVIDIA® NVSwitch」をご紹介します。

・NVIDIA® NVLink™

NVIDIAが開発した同一ノード内のGPU間でのデータ通信を効率化する通信規格です。

従来, 同一ノードに存在する複数GPUはPCI Express（PCIe）を用いていましたが, AI学習等の広帯域を要求するアプリケーションのボトルネック解消のため開発されました。

例としてPCIeとNVLinkの帯域幅には以下のような性能差があります。

• ・PCIe5.0が提供する帯域幅：最大で64GB/s
• ・第5世代NVIDIA® NVLink™が提供する帯域幅：最大で1.8TB/s

また, 上記NVLinkを物理的に接続する接続部品はNVIDIA® NVLink™ブリッジとして提供されています。

・NVIDIA® NVSwitch

こちらも同様にNVIDIAが開発した同一ノード内のGPU間でのデータ通信を効率化するための技術で, NVLink専用のスイッチチップです。
NVLinkより多くのGPU接続を可能とし, 大量のGPUの相互接続の面で優れています。

○ノードを跨ったネットワーク高速化

NVIDIAが開発した「NVIDIA® NVLink Switch」, およびRDMAプロトコルの観点でご紹介します。

・NVIDIA® NVLink Switch

NVLink Switchは後述のInfiniBandのスイッチの設計を活用し, NVSwitchチップをベースにしたスイッチングデバイスです。ノードを跨ったGPU間の高性能通信を目的として設計されています。

NVLink Switchは, 単一ネームスペースでの分散処理におけるネットワーク内のGPUを接続するために特別に設計されており, スイッチとして機能します。
NVLink SwitchはMellanoxが開発したSHARP（Scalable Hierarchical Aggregation and Reduction Protocol）プロトコルを利用して最適化とアクセラレーションを行います。

・RDMAプロトコル

DCNでの利用が想定されているRDMAプロトコルをご紹介します。

・InfiniBand

InfiniBandはIBTA（InfiniBand Trade Association）で管理されているネットワーク通信規格です。
超並列のスーパーコンピュータなどで使われるネットワーク技術であり, 分散処理が必要なAI基盤としても用いられています。

InfiniBandはSDN（ソフトウェア定義ネットワーキング）向けに設計されています。
SM（サブネットマネージャ）にSMA（サブネット管理エージェント）によって構成されており, SMがトポロジの検出から最短経路でのルーティング/ロードバランシングまでを自動で行います。

また, RDMAによるメモリ転送が可能でありAI学習といった高スループットを要求する処理のパフォーマンス向上が期待できます。

InfiniBandはEthernetベースのプロトコルとは仕組みが異なっているため, 専用のNIC/ネットワーク機器を調達しネットワーク構築する必要があります。

・RoCE

RoCE（RDMA over Converged Ethernet）はInfiniBand同様IBTA標準に準拠したネットワーク通信規格です。
InfiniBandと異なりEthernetのネットワーク上でRDMAを可能とした技術です。

単一ブロードキャストドメインで動作するイーサネットフレームベースのRoCEv1とIP/UDP上で動作するRoCEv2があります。

InfiniBand同様にRDMAをサポートし高性能な伝送が可能です。
既存のネットワーク機器を流用することも可能ですが, RoCEv2ではDCB（Data Center Bridging）で定義される以下の技術を用いてLosslessネットワークを実現するため（DCQCN）, 専用ネットワーク機器を導入することが望ましいです。

• ・PFC（Priority-based Flow Control）：IEEE802.1Qbbで定義される仮想リンクの優先度ベースのフロー制御技術
• ・CN（Congestion Notification）：IEEE802.1Qauで定義されるネットワーク機器の輻輳通知と通信抑制技術

また, NICについてはRDMAのためのオフロードが必要なためRoCE対応NICを導入する必要があります。

・Ultra Ethernet

UEC（Ultra Ethernet Consortium）で検討されているネットワーク通信規格です。
RDMAや既存のRoCEよりもHPCやAIネットワークに最適化されたトランスポート層を提供することを目的としています。

マルチパスでのパケットスプレー/セキュリティ等の技術要素が盛り込まれる予定です。
また, InfiniBandやRoCEと異なり, 複雑なチューニングを要しないテレメトリベースの輻輳制御を盛り込む予定です。

物理層は専用のデバイス, L2/L3は既存のEthernet/IPをベース, L4は独自プロトコルを想定しています。
ソフトウェアに関しては既存のCCL/MPIといった並列/分散アプリケーションをサポートする予定です。

2024年12月11日にSynopsysより「Ultra Ethernet IP」/「UALink IP」ソリューションの提供が開始され, 今後も開発が継続する予定です。

・各プロトコルの構造

プロトコル構造としては以下の通りです。InfiniBandは慣れ親しんだEthernetの構造とは異なっていることがわかります。
Ultra EthernetはInfinibandのBTH+を用いず独自構造を検討しているのが特徴となります。

プロトコル	L2	L3	L4	Payload	CRC
InfiniBand	LRH	GRH	BTH+	IB Payload	ICRC/VCRC
RoCEv1	MAC/ET	-	BTH+	IB Payload	ICRC/VCRC
RoCEv2	MAC/ET	IP/UDP	BTH+	IB Payload	ICRC/VCRC
Ultra Ethernet	MAC/ET	IP	UET	Payload	-

○ネットワーク機器での負荷分散による高速化

一般的にネットワークにおいてはルーティングプロトコルによるルート設定, およびECMP等でのマルチパス設定上でのフローによる負荷分散を実施しています。
これは上記で紹介したInfiniBand/RoCEにも一部当てはまる仕組みです。

一方で, DCNにおけるAI学習等ではマウスフローとエレファントフローが混在しており, フローベースの負荷分散では特定のエレファントフローの偏りによる輻輳が発生する可能性があります。
このためAdaptive routingやPacket sprayといったパケットベースの負荷分散の仕組みが検討されています。

・InfiniBand Adaptive Routing

ネットワーク機器において負荷が一番少ないポートからトラフィックを転送することで特定のリンクの輻輳を回避する技術です。
ただしOut-of-Orderが発生するためNICでリオーダーをする必要があります。

・Packet-spray-based LB

RoCE等のEthernetベースプロトコルにおいてもパケットスプレーによる負荷分散技術が存在しています。
InfiniBand同様, パケットの順序性担保には対処が必要であり, ベンダごとにその規格は異なっています。

これまでご紹介したようにLLMの学習/推論で用いられるネットワークはLosslessが求められており, 通信の分散処理に与える影響は大きいものとなっています。
そのため, 市中ではDCNのネットワークを監視し運用に役立てる仕組みが提案されています。

○Juniper Apstra

データセンターネットワークの構築/運用/監視が自動化できるサービスです。
AIデータセンターネットワークの運用監視化/自動化/監視ソリューションで, RoCEv2に対応しECN/PFCといった設定をGUIから投入可能です。

フロー監視を実施し, ヒートマップやインシデントベースの解析を通じて輻輳を検知します。
RoCEv2を用いたLosslessネットワークの構築にはDCQCNにおけるECN/PFCのデリケートな調整が必要となります。
そのため, ApstraはRoCEv2の混雑メトリックを継続的に監視しスイッチのDCQCNを再設定してDCNを数分間で自動調整しパケットロスを回避します。

○Cisco Nexus Dashboard Insights

データセンター向けのネットワーキングプロビジョニングやインフラストラクチャ管理のサービスです。
アラート, 分析/予測アルゴリズムが組み込まれており, ネットワーキング/コンピューティングコンポーネントから取得したテレメトリデータを利用してネットワークの動作を詳細に把握することができます。

ECNおよびPFCカウンタを使用して, RoCEv2トラフィックの輻輳とパフォーマンスを経時的に可視化することができます。

これまでご紹介させていただいたように, 生成AIを活用する上でDCNの高品質化が重要となります。
特にRoCEv2ネットワークにおいてはDCQCNといったLosslessネットワークを担保するため環境に合った設定が要求されます。

また, 輻輳発生時にはGo-back-Nによる高負荷状態となり学習/推論に大きな影響を与えることが想定されます。

そのため, 弊社ではDCNを高品質に運用するために必要なAIの分散処理への遅延影響評価作業, およびDCN監視技術の検討作業に取り組んでおります。