法人向けChatGPTにおける Azure OpenAI Serviceの課題解決の過程と現在

主にQuota対策の話です。
2023-11-30 Azure AI Hub #1 のLT資料です。

Transcript

1. 法人向けChatGPTにおける Azure OpenAI Serviceの課題解決の過程と現在 株式会社Algomatic シゴラクAIカンパニー CTO takuya kikuchi
2. 自己紹介 Algomatic シゴラクAIカンパニー CTO 菊池 琢弥 / Takuya Kikuchi X: @_pochi フィンテックスタートアップにおいて開発リードや VPoEとして開発 組織構築を担当したほか、モバイルオーダープラットフォームを手 がけるShowcase GigではVPoTとして技術領域全般を管掌。 2023年、AlgomaticにカンパニーCTOとして参画。ソフトウェア開 発、設計、ドット絵が好き
3. 本日の内容 • 会社紹介 • シゴラクAIのご紹介 • OpenAIとAOAI • Quota制限の実情 • 負荷分散戦略 • シゴラクAIにおける結論 • 今後の見通し
8. OpenAI と Azure OpenAI Service
9. OpenAI と Azure OpenAI Service OpenAI AOAI モデル 最新のモデルが利用可能 やや遅れて追従 （Turbo早かった...！） SLA なし 99.9% データ保存場所 米国および世界中のサービスプロバイダー のシステム * リージョン選択可能 コンテンツフィルタ Moderation APIを提供 自動的に適用（フィルタはカスタマイズ可 能） その他 GPT-4の返答がややカクつく *: https://help.openai.com/en/articles/7039943-data-usage-for-consumer-services-faq • 細かい挙動の違いはあれど、基本的にはOpenAIと同じ感覚で利用可能 • SLAがあることでのプロダクション利用への安心感 • （すべてではないが）任意のリージョンにモデルをデプロイできるところも嬉しい ◦ 新しい、あるいはPreviewのモデルは対応リージョンが少ないことも多いので注意
10. 今日はこれの話をします Requests to the Creates a completion for the chat message Operation under Azure OpenAI API version XXXXX have exceeded token rate limit of your current OpenAI XX pricing tier. Please retry after XX seconds
11. AOAI Quota制限の実情 参考: https://learn.microsoft.com/ja-jp/azure/ai-services/openai/quotas-limits TPM 利用可能リージョン数 GPT-4 20k ~ 40k 最大12リージョン GPT-4-32k 60k ~ 80k 最大12リージョン GPT-4-Turbo 80k ~ 150k 最大10リージョン GPT-3.5-Turbo 240k ~ 300k 最大12リージョン （参考）OpenAI GPT-4 300k TPM　(Tier5) - 公式ドキュメントに記載されている、モデルごとのTPM（Token per minutes） 個別申請による緩和が可能なこともある (Provisioned Throughputモデルは今回議論から外していますが、有効な選択肢なはず ) 参考: GPT-4: 最大8kトークン利用可能　GPT-4-Turbo: 128kトークン
12. リージョンとモデルとデプロイ リージョンA モデル GPT-3.5 TPM: 240k GPT-4 TPM: 40k GPT-4-Turbo TPM: 150k リージョンB モデル GPT-3.5 TPM: 200k リージョンごとに利用可能なモデルおよびQuotaが設定さ れている アプリケーションからモデルを呼び出すには、デプロイが必 要 1リージョンに複数モデルをデプロイすることもできるが、 リージョンに設定されたQuotaを超えることはできない デプロイ GPT-3.5 GPT-4 デプロイ GPT-3.5 GPT-3.5 アプリケーション
13. リージョンとモデルとデプロイ リージョンA モデル GPT-3.5 TPM: 240k GPT-4 TPM: 40k GPT-4-Turbo TPM: 150k リージョンB モデル GPT-3.5 TPM: 200k リージョンごとに利用可能なモデルおよびQuotaが設定さ れている アプリケーションからモデルを呼び出すには、デプロイが必 要 1リージョンに複数モデルをデプロイすることもできるが、 リージョンに設定されたQuotaを超えることはできない デプロイ GPT-3.5 GPT-4 デプロイ GPT-3.5 GPT-3.5 アプリケーション
14. つまり... リージョン1 リージョン2 デプロイ GPT-4 デプロイ GPT-4 アプリケーション リージョンN デプロイ GPT-4 … 40k TPM 40k TPM 40k TPM N個のリージョンを駆使すれば、TPMは実質N倍！
15. 負荷分散戦略を考えた どうやって分散させるか • アプリケーションコードで頑張る • Azureサービスを活用する ◦ Azure API Management ◦ Azure Application Gateway ◦ Azure Front Door 観点 • コスト • セキュリティ • 柔軟性 • 運用性
16. 負荷分散に使えそうなAzureのサービス
17. API Management APIの展開、セキュリティ、監視、利用状況の分析、および 開発者とのコラボレーションを一元的に管理できるクラウ ドベースのサービス。 APIエンドポイントを（外部などに）公開するためのサービ スで、認証認可、APIドキュメンテーション、流量制御など などを利用できるマネージドサービス。 エンドポイントごとに XMLによってポリシーを指定可能で、 リトライなどかなり凝った指定も可能
18. Application Gateway ウェブトラフィックの負荷分散、 SSL終端、およびウェブア プリケーションのセキュリティを提供する L7ロードバラン サ。 主な機能 • HTTPロードバランシング • オートスケーリング • URLベースルーティング • WAF • SSL/TLS終端 などなど
19. Front Door ウェブトラフィックのグローバルなルーティングと加速、 並びにWAF機能によるセキュリティ保護を提供する L7 ロードバランサー。 CDNを活用した高速なコンテンツ配信と SSL/TLSオフ ロードをサポート。 Azure Application Gatewayは、特定のリージョン内で のウェブアプリケーションに対するトラフィック管理に焦 点を当てている点に対し、こちらはグローバルな負荷 分散を目的としている。また、 CDN機能も統合されて おり、レイテンシーを最小限に抑える設計となっている
20. 具体的なアプローチ
21. 1. アプリケーションコードでやる 一番シンプルなアプローチ 長所: 　柔軟性、コスト 短所: 　アプリケーションコードが複雑化する 　APIキーの管理が煩雑 　　→　リージョンごとにAPIキーが払い出される 　　→　10リージョンあれば10個のキーを管理することにな る...
22. 2. API Management API ManagementをPublicに使う構成 長所 　負荷分散＆冗長化、比較的安い 短所 　ポリシーが複雑 コスト 　APIMの時間課金のみ
23. 3. API Management (Private) API ManagementをVnet統合する構成 長所 　負荷分散＆冗長化、セキュリティ 短所 　ポリシーが複雑、コスト コスト 　APIM + Private Endpoint 　　APIM Premium: $3.83/時間（$2757.6/月） 　　Private Endpoint: $0.01/時間 　　• 受信データ処理量…$0.01/GB (0-1PB) 　　 • 送信データ処理量…$0.01/GB (0-1PB)
24. 4. API Management + Application Gateway 負荷分散をApplication Gatewayに寄せる 長所 　負荷分散＆冗長化、セキュリティ 短所 　コスト コスト 　案3 + Application Gateway 　Application Gateway 　　固定…$0.29/ゲートウェイ時間 　　容量ユニット…容量ユニット時間につき $0.008
25. 5. APIM + Front Door APIM + Front Door 長所 　負荷分散＆冗長化 短所 　Vnetを使えない コスト 　APIM + Front Door 　Front Door 　　標準…$35 　　　使用した時間数に対して課金 　　　（一般論として、 Application Gatewayより安価）
26. シゴラクAIとしての結論
27. シゴラクAIとしての結論 「アプリケーションコードで頑張る」ことを選んだ • 「負荷分散をアプリケーションレイヤーの関心ごとから分離したい」という要求はあるが、こちらはアプリ ケーションレイヤーの設計上の工夫で十分吸収可能 ◦ 開発チームのスキルセットとして現状はアプリケーションレイヤーを得意とするメンバーが多い ◦ APIキーの管理問題も、アプリケーションサーバを Azureに移管すれば解決する • 負荷分散戦略も今後変わってくる可能性がある ◦ たとえば、Quotaの制限緩和 ◦ 開発メンバーの拡充 所感: GPT-4 Turbo新モデルのリリース直後など、「このモデルは今は OpenAIにしかない」といったイレギュラーケー スも多く、現時点においてはこの判断は間違ってなかったように思われる ...
28. まとめ • OpenAI / AzureOpenAIのQuota制限には頭を悩まされがち • そこは、複数リージョンを使うことである程度拡大可能 • 負荷分散戦略は多くパターンがありうるが、開発チームの状況や事業の方向性などから総合的に決定す べき ◦ インフラ周りを任せられるチームが存在すれば、負荷分散の関心ごとをインフラレイヤーで行うこと は十分合理的である ◦ Azure大好きなエンジニア求 • 状況は目まぐるしく変わるので、この正解が半年後も引き続き正解とは限らない ◦ 常に見直し続ける必要がある