Google Gemini Provisioned Throughput がレスポンス速度安定性に与える効果を検証する
こんにちは、PKSHA Communication ソフトウエアエンジニアの松下です。
この記事では、Google Gemini モデルを Google Cloud Vertex AI 経由で利用する際に活用できる「Provisioned Throughput」機能について、主にレイテンシへの影響を検証した結果をご紹介したいと思います。
松下 裕｜PKSHA Communication Voicebot 事業部 ソフトウエアエンジニアグループ リーダー
大学院修了後に入社した企業で、クラウド ERP のバックエンド・フロントエンド開発に従事。その後転職を経て、業務車両の位置情報を活用して課題解決をはかる企業向け SaaS のソフトウエアエンジニア、SRE 等を幅広く経験。PKSHA グループには 2021 年に参画し、PKSHA Voicebot のシステム開発全般を担当。現在は新たなユースケースの検証や機能の企画にも染み出しながら、プロダクトの進化の方向性を探求している。
検証の概要
Gemini モデルと Provisioned Throughput
私が担当している「PKSHA Voicebot」は、様々なお客様企業にお問い合わせの電話をかけて頂いた方と直接音声で対話することで、コンタクトセンターの業務を円滑化する音声ボットサービスです。 音声ボットでは人間の “ことば” を音声やテキストで扱う特性上、LLM 活用の可能性が様々な部分にあり、私たちも日々、進化や改善に繋がるアイディアの検証や開発を続けています。
API 経由で気軽に利用できる LLM の選択肢はますます豊富となってきていますが、Google の Gemini モデルファミリーは特に、音声ファイルを含むマルチモーダル入力を気軽に扱いやすいもののように思います。 一方 Gemini では、音声等のバイナリファイルを入力として扱う場合、テキストのみを扱う場合と比べてかなり多くのキャパシティを消費しますので、利用量のコントロールにはより配慮が必要となるでしょう。
Provisioned Throughput は、ユーザー専用のキャパシティを事前に購入することで、モデルのパフォーマンスを安定化させ、レイテンシを削減できる機能です。
今回はこの Provisioned Throughput を利用して、音声ファイルを扱うリクエストがどのように安定化できるか検証してみることにしました。ちなみに、Azure OpenAI Service にて似た機能の検証を行った記事もありますので、是非こちらも併せてご覧下さい。
実験の設定
Provisioned Throughput を利用する主なメリットとしては、以下のようなものが挙げられます。
安定した低レイテンシ：予測可能なパフォーマンスで、アプリケーションの応答性を向上
コスト効率の最適化：ワークロードに合わせてスループットを調整し、コストを削減
スケーラビリティの向上：需要の増加に合わせて自社専用のスループットでスケール可能
今回の実験では１つ目の点に注目し、レイテンシの特性に絞って検証を行うため、「日本語の発話を含む 10 秒前後の短い音声ファイルの書き起こしを依頼する」というシンプルなユースケースで実験を行いました。データとしては、私のチームで音声認識のテスト用として持っている 935 件の音声ファイルを利用しています。なるべく生成出力の長さによらない比較を行うため、ストリーミング方式の API を用い、リクエストを送信してから生成内容の最初のチャンクを受信するまでの時間を計測対象としました。また、レイテンシや Provisioned Throughput の効果は API 側の混雑状況や負荷の影響を受けると考えられますので、日や時間を変え、同じデータで 14 回分の測定実験を行っています。
Vertex AI では通常、Provisioned Throughput を購入していても、専用に確保したキャパシティを優先的に利用し、不足分が従量課金制（On-demand Throughput）のキャパシティから補われるという動作となります。今回は両者の安定性の違いを見るのが目的となりますので、ドキュメントに従い、REST API 経由で X-Vertex-AI-LLM-Request-Type ヘッダを指定することで、「Provisioned のみを利用するリクエスト」、「On-Demand のみを利用するリクエスト」をそれぞれ実施し、比較しました。なお、実験はすべてモデルとして gemini-1.5-pro-002 を用いて実施しています。
実験結果と考察
実験データ全体の概観
以下は、全実験データにおけるレイテンシ（最初のチャンク受信までの経過時間）分布のヒストグラムを、Provisioned のみ / On-Demand のみのそれぞれの条件下でのデータについて描いたものです。裾の重い分布であるため、横軸は対数スケール表示としています。
分布を比較すると、中央値については Provisioned / On-Demand ともに約 1.8 秒とほとんど差がなかったものの、テール部分では Provisioned の優位性が見られる結果となりました。 具体的な数値で見ると、たとえばユーザーへの応答をリアルタイムで返すアプリケーションの中で利用するにあたって、かなり体験の劣化に繋がると思われるレイテンシ 3 秒以上のサンプルの割合は、On-Demand では 6.5 % に対し、Provisioned では 1.2 % と 5 分の 1 以下に抑えられていることがわかります。
一方今回の実験では、Provisioned / On-Demand ともにレイテンシが日・時間によってかなり変動することがわかりました。以下は 14 回分の実験に対して、それぞれの実施結果に含まれるレイテンシの分布を箱ひげ図として描いたものです。
上記より、実験のうち 3 回 （12/5 19 時、12/5 23 時、12/6 23 時）、他と比較してレイテンシ中央値の明確に増加したタイミングがあったことが伺えます。 Provisioned Throughtput はこういった状況下でこそ最も効果を発揮する機能と思われますので、以下ではこれらのタイミングに絞って、レイテンシの比較をしてみることにします。
高レイテンシ下での実験データの比較
以下は、レイテンシが特に高い傾向のあった 3 回分の実験データについて、Provisioned のみ / On-Demand のみそれぞれの条件下でのレイテンシ分布をヒストグラムとして描いたものです。
※ こちらは横軸も線形軸表示になります
図からも見て取れますが、これらのデータでは Provisioned / On-Demand の差がより顕著に現れる結果となりました。レイテンシの中央値を全データの場合と比較すると、On-Demand では約 2.6 秒と 1.4 倍の増加であるに対し、Provisioned では約 2.2 秒と 1.2 倍の増加に抑えられています。
また、こちらでもレイテンシ 3 秒以上のサンプル割合を見てみると、On-Demand 36 % に対し Provisioned では 5 %と、On-Demand の場合の 7 分の 1 以下に抑えられています。さらにレイテンシ 4 秒以上の割合を見てみると、On-Demand 17 % に対して Provisioned では 0 % となりました。
考察
今回の実験では、以下のようなことがわかりました。
API が十分高速に結果を返す時間帯において、Provisioned / On-Demand の平均レイテンシにはほぼ差がないが、最大レイテンシは Provisioned で若干低くなる
全体的にレイテンシが高まるような時間帯では、Provisioned Throughput を利用すると実行時間のばらつきが大きく改善され、安定したレスポンスが得ることができる
上記より、Gemini の Provisioned Throughput はレイテンシの安定性が重要となるような用途での活用が期待できると考えられ、特に今回のサンプルで扱った、音声のような大きめな入力をリアルタイムに処理するようなユースケースにおいて有力な選択肢となりそうです。
まとめ
本記事では、短い音声ファイルの内容を書き起こすシンプルなタスクを題材に、Gemini モデルの Provisioned Throughput / On-Demand Throughput をそれぞれ単体で利用した際のレイテンシの比較検証を行いました。実験結果から、Provisioned Throughput 利用時は API が混雑あるいは高負荷の状況下でも安定したパフォーマンスを得ることができ、リアルタイム性が再重要なワークロードが定常的に発生するようなユースケースでは大きな価値を発揮できそうなことが分かりました。
ちなみに本記事では詳しく扱いませんでしたが、Provisioned Throughput のコスト面のメリットは、購入分のキャパシティが定常的に、かつ長期に渡って必要となるようなユースケースで発揮されやすいものとなっています。Provisioned Throughput を実際に利用する際には、対象となるリクエストのボリュームと推移を見積もり、購入するユニット数や期間を最適化することが求められるでしょう。 実際の活用シナリオとしては、十分に事業価値の実証されたユースケースについて極めて高い安定性のもと提供したいような場合か、もとより大規模なキャパシティ消費が見込まれる実験やバッチ処理を行う計画があり、そのコストとパフォーマンスを最適化したいような場合、といったところかと思います。
今回の検証では Provisioned Throughput の性質を実証する形で把握できましたので、上記のような実装を行う際の有力な選択肢として心に留めておきたいと思います。
―INFORMATION―
PKSHA Technology では推薦に限らず様々なタスクにおいて AI の社会実装を進めており、共に社会実装を加速させる仲間を募集しています。採用サイトや Wantedly から応募が可能ですので、是非ご覧ください！
▼ アルゴリズムエンジニア【26 新卒】
※ スプリングインターンは 2/28（金）エントリー締め切り
▼アルゴリズムエンジニア【中途採用】
▼カジュアル面談も受付中です！Wantedly はこちら