次の方法で共有


Azure API Management の AI ゲートウェイ機能の概要

適用対象: すべての API Management レベル

この記事では、Azure OpenAI Service によって提供される機能など、生成 AI API の管理に役立つ Azure API Management の機能を紹介します。 Azure API Management には、インテリジェント アプリを提供する API のセキュリティ、パフォーマンス、信頼性を強化するためのさまざまなポリシー、メトリック、その他の機能が用意されています。 これらの機能をまとめて、生成型 AI API の AI ゲートウェイ機能 と呼ばれます。

注記

  • AI ゲートウェイ機能を使用して、Azure OpenAI サービスによって公開される API、 Azure AI モデル推論 API を通じて利用できる API、またはサードパーティの推論プロバイダーを介して提供される OpenAI と互換性のあるモデルを管理します。
  • AI ゲートウェイ機能は、別の API ゲートウェイではなく、API Management の既存の API ゲートウェイの機能です。 API Management の詳細については、Azure API Management の概要に関するページを参照してください。

生成 AI API を管理する際の課題

生成 AI サービスで使用する主なリソースの 1 つは、"トークン" です。 Azure OpenAI Service では、1 分あたりのトークン数 (TPM) で表されるクォータをモデル デプロイに割り当てて、モデル コンシューマー (さまざまなアプリケーション、開発者チーム、社内の部門など) 全体に分配します。

Azure を使用すると、単一のアプリを Azure OpenAI Service に簡単に接続できます。つまり、モデル デプロイのレベルで TPM 制限を直接構成し、API キーを使用して直接接続できます。 ただし、アプリケーション ポートフォリオを拡大し始めると、従量課金制またはプロビジョニングされたスループット ユニット (PTU) インスタンスとしてデプロイされた 1 つまたは複数の Azure OpenAI Service エンドポイントを呼び出す複数のアプリが表示されます。 これにはいくつかの課題が伴います。

  • 複数のアプリケーション間でトークンの使用状況をどのように追跡しますか? Azure OpenAI Service モデルを使用する複数のアプリケーションまたはチームに対してクロスチャージを計算できますか?
  • 1 つのアプリで TPM クォータ全体が消費され、他のアプリで Azure OpenAI Service モデルを使用するためのオプションがなくならないようにするにはどうすればよいでしょうか?
  • どのようにして API キーを複数のアプリケーション間で安全に配布しますか?
  • 複数の Azure OpenAI エンドポイント間で負荷をどのように分散しますか? 従量課金インスタンスにフォールバックする前に、PTU のコミット済み容量が確実に使い果たされるようにすることができますか?

この記事の残りの部分では、Azure API Management がこれらの課題の解決にどのように役立つかについて説明します。

Azure OpenAI Service リソースを API としてインポートする

ワンクリック エクスペリエンスを使用して、Azure API Management に Azure OpenAI Service エンドポイントから API をインポートします。 API Management を使用すると、Azure OpenAI API の OpenAPI スキーマが自動的にインポートされてオンボード プロセスが効率化され、マネージド ID を使用して Azure OpenAI エンドポイントへの認証が設定されるため、手動による構成は必要ありません。 同じユーザー フレンドリなエクスペリエンス内で、 トークンの制限トークン メトリックの出力セマンティック キャッシュのポリシーを事前構成できます。

ポータルの Azure OpenAI API タイルのスクリーンショット。

トークン制限ポリシー

Azure OpenAI Service トークンの使用状況に基づいて API コンシューマーごとの制限を管理および適用するには、Azure OpenAI トークン制限ポリシーを構成します。 このポリシーを使用すると、1 分あたりのトークン数 (TPM) で表されるレート制限を設定できます。 また、時間単位、日単位、週単位、月単位、年単位など、指定した期間にわたってトークン クォータを設定することもできます。

API Management での Azure OpenAI Service トークンの制限を示す図。

このポリシーにより、サブスクリプション キー、送信元 IP アドレス、ポリシー式で定義された任意のキーなど、任意のカウンター キーにトークン ベースの制限を柔軟に割り当てることができます。 また、Azure API Management 側でプロンプト トークンを事前に計算できるため、プロンプトが制限を既に超えている場合、Azure OpenAI Service バックエンドへの不要な要求が最小限に抑えられます。

次の基本的な例は、TPM 制限をサブスクリプション キーあたり 500 に設定する方法を示しています。

<azure-openai-token-limit counter-key="@(context.Subscription.Id)" 
    tokens-per-minute="500" estimate-prompt-tokens="false" remaining-tokens-variable-name="remainingTokens">
</azure-openai-token-limit>

ヒント

他の LLM API のトークン制限を管理および適用するために、API Management には同等の llm-token-limit ポリシーが用意されています。

トークン メトリックの送信ポリシー

Azure OpenAI トークン メトリックの送信ポリシーは、Azure OpenAI Service API を介した LLM トークンの使用に関するメトリックを Application Insights に送信します。 このポリシーは、複数のアプリケーションまたは API コンシューマー全体での Azure OpenAI Service モデルの使用状況の概要を提供するのに役立ち、 チャージバックのシナリオ、監視、容量計画に役立つ可能性があります。

API Management を使用した Azure OpenAI Service トークンのメトリックの送信を示す図。

このポリシーは、プロンプト、入力候補、トークンの合計使用量のメトリックをキャプチャし、任意の Application Insights 名前空間に送信します。 さらに、定義済みのディメンションを構成または選択してトークンの使用状況のメトリックを分割できるため、サブスクリプション ID、IP アドレス、または任意のカスタム ディメンションごとにメトリックを分析できます。

たとえば、次のポリシーは、クライアント IP アドレス、API、ユーザーごとに分割されたメトリックを Application Insights に送信します。

<azure-openai-emit-token-metric namespace="openai">
    <dimension name="Client IP" value="@(context.Request.IpAddress)" />
    <dimension name="API ID" value="@(context.Api.Id)" />
    <dimension name="User ID" value="@(context.Request.Headers.GetValueOrDefault("x-user-id", "N/A"))" />
</azure-openai-emit-token-metric>

ヒント

他の LLM API のメトリックを送信するために、API Management には同等の llm-emit-token-metric ポリシーが用意されています。

バックエンドロードバランサーとサーキットブレーカー

インテリジェント アプリケーションをビルドする際の課題の 1 つは、アプリケーションがバックエンドの障害に対して耐性があり、高い負荷を確実に処理できるようにすることです。 Azure API Management でバックエンドを使用して Azure OpenAI Service エンドポイントを構成すると、エンドポイント間で負荷を分散できます。 また、Azure OpenAI Service バックエンドが応答しない場合に要求の転送を停止するサーキット ブレーカー ルールを定義することもできます。

バックエンド ロード バランサーでは、ラウンドロビン、重み付け、優先度ベースの負荷分散がサポートされており、特定の要件を満たす負荷分散戦略を柔軟に定義できます。 たとえば、ロード バランサーの構成内で優先順位を定義して、特定の Azure OpenAI エンドポイント (特に PTU として購入されたもの) が最適に利用されるようにします。

API Management でのバックエンド負荷分散の使用を示す図。

バックエンドのサーキット ブレーカーは、その特徴として、バックエンドが提供するRetry-Afterヘッダーの値を利用した動的なトリップ時間を備えています。 これにより、バックエンドの正確でタイムリーな復旧が保証され、優先バックエンドの使用率が最大化されます。

API Management でのバックエンド サーキット ブレーカーの使用を示す図。

セマンティック キャッシュ ポリシー

類似するプロンプトの入力候補を格納してトークンの使用を最適化するには、Azure OpenAI セマンティック キャッシュ ポリシーを構成します。

API Management のセマンティック キャッシュの図。

API Management で、Azure Redis Enterprise、Azure Managed Redis、または RediSearch と互換性のある別の 外部キャッシュ を使用してセマンティック キャッシュを有効にし、Azure API Management にオンボードします。 Azure OpenAI Service Embeddings API を使用すると、azure-openai-semantic-cache-store および azure-openai-semantic-cache-lookup ポリシーによって、意味的に類似したプロンプトの入力候補がキャッシュに格納され、そこから取得されます。 このアプローチにより、入力候補を確実に再利用できるため、トークンの消費量が削減され、応答パフォーマンスが向上します。

ヒント

他の LLM API のセマンティック キャッシュを有効にするために、API Management は同等 の llm-semantic-cache-store-policy ポリシーllm-semantic-cache-lookup-policy ポリシーを提供します。

トークンの使用状況、プロンプト、および入力候補のログ記録

API Management インスタンスで 診断設定 を有効にして、大規模言語モデル REST API のゲートウェイによって処理された要求をログに記録します。 要求ごとに、トークンの使用状況 (プロンプト トークン、完了トークン、および合計トークン)、使用されるモデルの名前、必要に応じて要求メッセージと応答メッセージ (プロンプトと完了) を含むデータが Azure Monitor に送信されます。 大規模な要求と応答は複数のログ エントリに分割され、必要に応じて後で再構築するために順番に番号が付けられます。

API Management 管理者は、次のようなシナリオで、LLM ゲートウェイ ログと API Management ゲートウェイ ログを使用できます。

  • 課金の使用量を計算する - 各アプリケーションまたは API コンシューマーによって消費されたトークンの数に基づいて、課金の使用状況メトリックを計算します (たとえば、サブスクリプション ID または IP アドレスでセグメント化)。
  • メッセージを検査 する - デバッグまたは監査に役立つには、プロンプトと完了を検査して分析します。

Azure Monitor を使用した API Management の監視の詳細について説明します。

コンテンツの安全性に関するポリシー

有害なコンテンツ、不快なコンテンツ、誤解を招くコンテンツからユーザーを保護するために、 llm-content-safety ポリシーを構成することで、LLM API に対するすべての受信要求を自動的にモデレートできます。 このポリシーでは、バックエンド LLM API に送信する前に、最初に それらを Azure AI Content Safety サービスに送信することで、LLM プロンプトにコンテンツの安全性チェックを適用します。

API Management ポリシーでの Azure AI Content Safety によるモデレート プロンプトの図。

ラボとサンプル

アーキテクチャと設計の考慮事項