はじめに
生成AIブームの開始から１年以上経過し、OpenAIのAPIを利用して社内の業務の効率化を目指している企業や自社サービスをリリースしている企業も増えてきました。
各所で話を聞く限り、OpenAIのAPI利用で一番多いユースケースはRAG(Retrieval Augmented Generation)を利用した社内FAQの実装ですね。
RAGの実装でOpenAIのAPIを利用する場合、Embeddingではtext-embedding-ada,回答生成ではChatGPT(GPT-3.5‐Turbo),GPT-4を利用することが一般的です。
基本的にLLMの性能はモデルサイズに比例する関係上、高性能なモデルを使うとレスポンスが遅くなる傾向性があり、レスポンス速度と回答内容の正確性はトレードオフになります。
そして、GPT-4は非常に高性能ではあるのですが、回答生成の速度はGPT-3.5‐Turboに比べると大幅に遅くなります。
RAGは性質上、回答精度を高めようとすると回答生成に消費するToken数が多くなりがちなこともあって、この影響が顕著に出てきます。
弊社はBOTCHAN AIというオンライン接客を自動化するチャットボットをリリースしており、ここでRAGを活用しているのですが、RAGでGPT-4を利用した場合、回答精度は高くなるものの回答生成に時間がかかりすぎるという問題に悩まされていました。
この OpenAIのAPIのレスポンス速度と回答精度のトレードオフを解消、あるいは緩和する方法はないのか、その可能性を探るためにAzure OpenAI ServiceのPTU(Provisioned Throughput Units)を利用して検証してみました。
この検証には、現在各種SOTAベンチマークで世界最高峰の性能を誇るGPT-4oを利用しました。
記事執筆時点ではインターネット上にAzure OpenAI ServiceでPTUを実際に利用したケースの情報がほぼ存在していなかったため、これは非常に貴重なデータとなります。
あまりに情報が無いため、この記事の作成前にNDA(機密保持契約)でPTUのパフォーマンス情報の外部公開が禁止されているのかMicrosoft社に確認してしまうレベルで情報がありませんでした。
PTU(Provisioned Throughput Units)とは
PTUの定義
Microsoft Learnには以下のように記述されています。
プロビジョニングされたスループット機能を使用すると、デプロイで必要なスループットの量を指定できます。
その後、サービスは必要なモデル処理容量を割り当て、その準備が整っていることを確認します。
スループットは、デプロイのスループットを表す正規化された方法であるプロビジョニング スループット ユニット (PTU) という観点で定義されます。
各モデルバージョン ペアでは、デプロイして PTU ごとにさまざまな量のスループットを提供するために、さまざまな量の PTU が必要となります。
分かりやすくかみ砕くと、LLMを動かしているGPUサーバーの処理性能(スループット)をあらかじめ予約することによって、その予約範囲内においては、自社だけで排他的にOpenAIのLLMを使用できるというサービスですかね。
実質的にNVIDIA H100などの高額なGPUを複数台レンタルしている状態に近いので、それなりにお値段もします。
(最小単位でも個人が気軽に使えるレベルの金額感ではありません。)
それと引き換えに他社のトラフィックに起因したサーバーの混雑状況によってLLMのパフォーマンスが左右されなくなるため、LLMの本来の性能を引き出すことができます。
同様のサービスはOpenAIのAPIには存在しないので、OpenAIのAPIではなく、Azure OpenAI Serviceを利用する理由の一つにもなるかなと思います。
通常のAPIとの違い
実際にPTUを利用してみてわかった、通常のAPIとの大きな違いは以下の3点ですね。
なお動作性能の違いは次の章で詳細に実践検証しているため、ここでは触れません。
- 課金体系の違い
- Rate Limitの判定方法の違い
- 動作性能の違い
1. 課金体系の違い
通常版のAzure OpenAI ServiceのAPIは、モデル単位で設定された入力,出力のTokenあたりの料金表をベースに、APIコールで消費したTokenベースでの従量課金になります。
PTUは課金体系も変わり、消費Token数による従量課金ではなく、利用するLLMモデル x 購入したUnit単位での課金となります。
利用するLLMモデルによって最低利用Unit数や費用、購入可能なリージョンが異なります。
LLMモデルによって、消費するGPUサーバーのキャパシティが異なるので当然といえば当然ですね。
PTUは購入時点で課金され、その範囲内の利用であれば追加費用はかかりません。
また、1ヶ月単位で購入可能でした。
2. Rate Limitの判定方法の違い
Azure OpenAI ServiceのAPIには、Rate Limitという制限が設定されており、1分間あたりの制限リクエスト数(Requests per Minute RPM)、または制限消費Token数(Tokens per Minute TPM)を超過した場合、一時的にAPIリクエストが失敗するようになり、レスポンスコード:429が返されるようになります。
(制限値は違っても同様の制限がOpenAIでもあります)。
経験則上、OpenAIのAPIのRate Limitとしては、リクエスト数側の制限(RPM)では無く、消費可能Token数の制限(TPM)で苦しむことが圧倒的に多いですね。
従量課金型のAPIの場合はRate Limitに到達すると即レスポンスコード:429が返却されるようになります。
PTUの場合、購入済みのUnitのUtilization(利用率)が100%を超えたときにRate Limit超過と判定され、その後Utilizationが100%以下に回復するまでレスポンスコード:429が返却されるようになります。
このUtilizationベースの流入制御はFlyWheelというシステムで行われており、短時間のバーストであればリクエストを受け付けてくれるのですが、Utilizationが100%を超えてから回復したと判定されるまでにはややラグが発生するため、注意が必要です。
FlyWheel上Utilizationが回復したと判定されるまで、しばらくRate Limitの超過としてレスポンスコード:429が返り続けます。
なお、FlyWheelに関しては、Microsoft Build 2024でAzure CTOのセッションの中で触れられていたので、詳しく知りたい方は下記Youtubeをご覧ください。
動画の30:00前後でFlyWheelに関して説明されています。
動作性能の実践検証
ただAPIをサンプルデータでコールするだけでは実践検証としては不十分という認識のもと、より精緻なデータを取得するため、以下の前提条件で検証を行いました。
前提条件
-
現在「BOTCHAN AI」を導入中の顧客体験にこだわりが強いお客様に許可をもらったうえで、実際に本番環境で利用する予定のデータを利用してRAGで検証を行いました。
オンライン接客向けのチャットボットである関係上、回答内容が正しいだけでは不十分で、言い回し、言葉遣い等も要件に入っており、プロンプトも重量級となっています。(約2000 ~ 4000 token) -
Japan EastリージョンにPTUの空きがなかったので、最寄りのKorea CentralリージョンでPTU 100 Unitを購入し検証しました。
比較対象はデプロイの種類 : [グローバル標準] でEast USリージョンにデプロイしたGPT-4oのモデル(10000k TPM)とAPI Managementでグローバルに負荷分散したGPT-3.5-Turbo-1106です。
それ以外の要素は完全に同一条件で検証しました。 -
検証時のRAGアーキテクチャとしては、本番環境と同様にAzure AI SearchでSemantic Rankerを利用したHybrid Searchでの回答データ参照とAzure API Managementを経由したPrivate EndpointからAzure OpenAIにデプロイしたモデルへのアクセスで検証しました。
現状、割とAzure上でのベストプラクティスに近い構成かなと思います。 -
自社開発したLLM Ops用のツールを利用して、約1100個の別々の質問と回答セットを12workerでの並列処理で確認しました。
検証結果
1. 処理時間のヒストグラム
約1100個の質問に対する回答時間(Time taken)を図表にプロットしてみました。
その結果、検証前の想定よりも明確に差が出ました。
PTUを利用したほうが、グローバル標準のGPT-4oよりも明らかにレスポンスが速いだけでなく、レイテンシの安定性も高いものとなりました。
明確にヒストグラムの値が 3.33 sec ~ 5.00 secに収束しているのがわかります。
レイテンシの安定性で見れば、グローバル標準のGPT-4o、API Managementで負荷分散したGPT-3.5-Turbo-1106よりも明らかにGPT-4oのPTUのほうが優れています。
2. 統計情報
| GPT-4o(PTU) | GPT-4o(グローバル標準) | GPT-3.5-Turbo-1106 | |
|---|---|---|---|
| 中央値 | 4.76 sec | 7.78 sec | 5.85 sec |
| 平均値 | 11.97 sec | 11.99 sec | 11.97 sec |
| 最頻値 | 4.09 sec(11 times) | 6.65 sec(7 times) | 5.56 sec(10 times) |
| 最小値 | 2.96 sec | 3.25 sec | 3.21 sec |
| 最大値 | 51.93 sec | 39.99 sec | 44.44 sec |
GPT-4 32kなど従前のモデルと比べるとグローバル標準のGPT-4oもかなり速度的に善戦していますが、中央値の回答時間でいえば、基本的にはPTUのほうが安定して3秒ほど速いという結果になりました。
中央値でいえばAPI Managementで負荷分散したGPT-3.5-Turbo-1106よりも約1秒早いレベルだったことには驚きました。
ただ最大値と平均値の結果を見ればわかる通り、Rate Limitに引っかかったときに明確にPTUのほうが遅くなる結果、平均値は大差ない状態になっています。
PTUの利用時には、そもそもRate Limitに引っかからないようにキャパシティプランニングをきちんと行うか、Rate Limitにひっかかったときだけグローバル標準の方にリクエストを分散する等の制御を加えるかして対応する必要がありそうです。
今回は検証目的でLLM Ops用のテストツールで短時間で集中的に負荷をかけた結果、Rate Limitが頻発していますが、きちんとキャパシティプランニングをしていれば本番環境でここまでRate Limitに引っかかることはありません。
この検証の目的となっている「PTUの利用によって、回答精度とレスポンス速度のトレードオフを解消または緩和することは可能か」という問いに対しては検証の結果、「Rate Limitに引っかからない範囲においてはPTUの利用によって達成が可能」という答えになりそうです。
想定されるPTUのユースケース
今回PTUの利用によって得られた検証データや公式ドキュメントを斟酌すると、PTUのユースケースとしては以下の5つが考えられるかなと思います。
なお、Azure OpenAI ServiceではGPT-4o以外のOpenAIのLLMモデルでもPTUを利用できます。
- 国外にデータを出してはいけないという情報セキュリティ上の制約がある場合
- 24x7で予測可能な一定のトラフィックがかかり続ける場合
- 回答品質の高さと回答速度の速さが売り上げに直結する場合
- プログラムの性質上、レイテンシ/会話品質を安定させる必要がある場合
- APIのコストパフォーマンスよりもユーザー体験を重視する場合
1. 国外にデータを出してはいけないという情報セキュリティ上の制約がある場合
エンタープライズや政府機関では情報セキュリティ上の理由から「特定リージョンの外にデータを出してはいけない」という縛りが存在するケースがそれなりにあります。
この場合、グローバル標準での負荷分散やAPI Managementを利用してグローバルにOpenAIのモデルをデプロイして負荷分散をすることができないので、PTUの利用がかなり有力な選択肢となりそうです。
政府機関の場合は政府リージョンにPTUでのホスティングという構成になりそうですね。
2. 24x7で予測可能な一定のトラフィックがかかり続ける場合
前述のとおり、PTUは課金体系が変わり、利用したTokenベースの従量課金では無く、購入したUnit単位での課金になります。
夜間日中問わず常時高トラフィック状態が続くのであれば、PTUを購入したほうが安上がりになるケースもあるかなと思います。
特にGPT-4 32kや GPT-4 Turbo with Vision等、比較的Tokenあたりの料金が高いAPIを利用したワークロードだとこのユースケースとしてハマりそうです。
事実、Microsoft社の公式ドキュメントにも以下のように記載してあります。
コスト削減: 高スループット ワークロードは、トークンベースの使用と比較したときのコスト削減につながる場合があります。
3. 回答品質の高さと回答速度の速さが売り上げに直結する場合
商品の購入や不動産/保険の商談設定等のコンバージョン系のオペレーションをチャットボット経由で行う場合、動作速度の速さはCVR(コンバージョン率)に直結します。
PTUの購入料金よりもコンバージョン率の向上による利益のほうが上回るなら、PTUを利用する価値はありそうです。
ただ約3秒早くなることでPTUの料金を上回るだけのCVR向上効果が出るケースがどれだけ存在するのかはまだ未知数です。
4. プログラムの性質上、レイテンシを安定させる必要がある場合
APIの実装をプロンプトだけでレスポンスを返却させる方式で対応している場合やFunction callingを利用している場合など、プログラムの中心部分でOpenAIのAPIコールをしているケースではレイテンシを安定させないとプログラム自体が安定しない状態となります。
その場合にはPTUによって、他社のトラフィックに左右されないかたちでレイテンシを安定化できるので一定ニーズはあるのかなと思います。
5. APIのコストパフォーマンスよりもユーザー体験を重視する場合
コストパフォーマンスよりもユーザー体験を重視する場合には、絶対にPTUを利用したほうがいいですね。
キャパシティプランニングを適切に行えば確実にレイテンシの高速化と安定化が実現できます。
このケースは事業資金が潤沢なエンタープライズの社内FAQでのユースケースとしてハマりそうですね。
さいごに
本件検証によって、PTUを利用することで安定したレイテンシのもとでGPT-3.5-Turbo以上の速度でGPT-4oを利用できるということが明らかになりました。
PTUは高性能なLLMモデルの回答速度と回答品質のトレードオフを解消する手段として、有力な選択肢の一つとなりそうです。
ユースケースによってはレイテンシの安定化/高速化だけでなく、コスト削減につながる余地もあります。
弊社では「3.回答品質の高さと回答速度の速さが売り上げに直結する場合」に当たらないかGPT-4oを利用して検証を行っています。
この記事が皆様にとって少しでも参考になれば幸いです。