😺
Azure OpenAIを使う際のインフラ観点でのポイント
はじめに
AOAIについてセミナを受講する機会があったため、そこで学んだことを残しておく。
トークン
- モデルが学習・推論を行うためのデータの最小分割単位。
- 英語だと１トークンが３～４文字、日本語だと約1.1文字
クォーター制限
- モデル×リージョン毎にクォーター制限が存在する。GPT3.5であれば、300kのトークンのクォーター制限がある。
- レートリミットにかかると、1分間の待ちが強制的に発生する。
- 別のリージョンに作成すれば、クォーター制限としての分散は可能になる。（開発環境は別リージョンなど）
- ゾーンを考慮しないので、指定したゾーンにデプロイされるとは限らない。
データ保持
- MicrosoftではAOAIに対して厳しい倫理ハードルを持っているため、プロンプトが30日間保持される。承認されたMS社員のみがレビューを行い、AIが悪用されていないかをチェックできる。
- オプトアウトによってチェックの省略は可能だが、内部で厳格なチェック体制を持っている必要がある。
AOAIでの権限制御で使われるサービス
AOAIへのアクセスにはRBACを使った認証認可が推奨されている。ここではApp Serviceが接続元なのでマネージドIDが推奨される。クライアントがAzureサービス以外の場合は、
(TIPS)権限制御で使われるサービス
Azure Policyの場合は、VMのプラン制限だったり、デプロイ先のリージョンを制限するときなどのガバナンスを効かせるときに利用される。
RBACはホワイトリスト方式なので、権限を付与しないと何もできない。
ログ取得について
Azure Open AIのログを有効化しただけでは、プロンプトログは取得できない。API Managementから取得するのがよくあるケースである。
NW面で選択される方式について
PaaSはみんなで使うことでコストメリットを享受するので、Vnetへの専用デプロイはコストがかかる。例えば、API Managementの仮想ネットワークデプロイはPremiumプランか、SLAのないDeveloperプランしか利用できない。
API Managementを使った冗長化構成
API Managementは本職の負荷分散装置ではないので、バックエンドに対しての死活監視は存在しない。
プレビューでは、サーキットブレーカーといった、使い過ぎであったり・障害応答（500コード）を返したときに、呼び出しを遮断するロジックが存在する。
もしくは、Application Insightsなどと連携して、ログベースによるエラー監視という方法も？
AI Searchの共有プライベード
AI SearchがAzure PaaSリソースとプライベードで連携するときの接続方法。
Discussion