Azure OpenAI サービス を使用すると、OpenAI の強力な言語モデルにアクセスできます。 この記事では、マルチテナント ソリューションに役立つ Azure OpenAI の主な機能について説明します。 推奨リソースを確認して、アプローチの計画と Azure OpenAI の使用に役立ててください。
分離モデル
Azure OpenAI を使用するマルチテナント システムがある場合は、テナントに必要な分離レベルを決定する必要があります。 分離モデルは、次の要因に基づいて設計する必要があります。
- 持つ予定のテナントの数
- テナントに、ネットワークまたはインフラストラクチャの分離を必要とするコンプライアンス要件があるかどうか
- テナントが独自のデータを使用して微調整されるモデルを必要とするかどうか
- テナントに異なるモデル バージョンまたはモデル ライフ サイクルが必要かどうか
次の表は、マルチテナント システムで Azure OpenAI を使用するときに実行できるデプロイ方法をまとめたものです。
| 考慮事項 | 専用の Azure OpenAI サービス | 各テナントの専用モデル展開が可能な共用のAzure OpenAIサービス | 共有 Azure OpenAI サービス、共有モデルのデプロイ | テナント提供の Azure OpenAI サービス |
|---|---|---|---|---|
| データの分離 | 高 | 中程度 | 低 | 高 |
| パフォーマンスの分離 | 高 | 高 | テナントごとのトークン/分 (TPM) の使用状況に応じて、低から中。 | 高 |
| 配置の複雑性 | テナントの数に応じて、低から中。 | ミディアムでは、デプロイ名とクォータを管理する必要があります。 | 低 | 適用されず、顧客によって管理されます。 |
| 操作の複雑さ | 低 | 中程度 | 高 | プロバイダー側では低いです。 テナントにとって中程度から高程度。 |
| サンプル シナリオ | 他のテナントからのネットワーク分離を必要とするシングル テナントデプロイ。 | 特定のモデルのライフ サイクルまたは微調整の要件を持つテナント。 | 共有アプリケーション層を持つ大規模なマルチテナント ソリューション。 | 特定のコンプライアンスまたは微調整要件を持つテナント。 |
専用の Azure OpenAI サービス
サービス プロバイダーの場合は、Azure サブスクリプション内のテナントごとに Azure OpenAI インスタンスをデプロイすることを検討してください。 このアプローチでは、テナントごとにデータが分離されます。 テナントの数を増やすにつれて、Azure OpenAI リソースの数を増やして管理する必要があります。
テナントごとに個別のアプリケーションデプロイがある場合、またはクォータや 1 分あたりの要求などの制限を回避する必要がある場合は、この方法を使用します。 詳細については、 Azure OpenAI のクォータと制限に関する記事をご覧ください。
次の図は、プロバイダーのサブスクリプション内のテナントごとの Azure OpenAI モデルを示しています。
共有 Azure OpenAI サービス
複数のテナント間で Azure OpenAI のインスタンスを共有することもできます。 Azure OpenAI リソースは、(サービス プロバイダーの) Azure サブスクリプションにデプロイされます。 管理する責任はユーザーにあります。 このソリューションは実装が最も簡単ですが、提供されるデータ分離とパフォーマンスの分離は最小限です。
Azure OpenAI リソースを共有しても、各モデル デプロイのセキュリティ セグメント化は提供されません。 テナントは、使用が許可されていないモデルを使用できる場合があります。 このため、微調整されたモデルを使用する場合は、Azure OpenAI インスタンスの共有を避けてください。 機密情報を公開し、テナント固有のデータまたはリソースへの未承認のアクセスを許可する場合があります。
複数のテナント間で Azure OpenAI のインスタンスを共有すると、ノイズの 多い近隣の 問題が発生する可能性もあります。 これにより、一部のテナントで待機時間が長くなることがあります。 また、アプリケーション コードをマルチテナント対応にする必要もあります。 たとえば、共有 Azure OpenAI インスタンスの従量課金コストを顧客に請求する場合、アプリケーション内のテナントごとにトークンの合計数を追跡するロジックを実装します。
複数の共有 Azure OpenAI インスタンスをデプロイすることもできます。 たとえば、 デプロイ スタンプ パターンに従う場合、各スタンプ内に共有 Azure OpenAI インスタンスをデプロイします。 複数のリージョンにソリューションをデプロイする場合は、各リージョンに次の Azure OpenAI をデプロイする必要があります。
- リージョン間トラフィックの待ち時間を回避する。
- データ所在地の要件をサポートする。
- 同じリージョン デプロイを必要とする他のサービス内でリージョン Azure OpenAI を使用できるようにする。
共有 Azure OpenAI インスタンスがある場合は、その 制限 を考慮して、 クォータを管理することが重要です。
次の図は、共有 Azure OpenAI モデルを示しています。
共有 Azure OpenAI サービスをデプロイする場合は、サービス内のモデル デプロイを共有するか、特定の顧客専用にするかを決定できます。
テナント間での共有モデルのデプロイ
テナント間でモデルデプロイを共有すると、管理するデプロイが少なく、追跡するモデルバージョンが少なくなるため、運用上の負担が軽減されます。可能であれば共有モデル デプロイの使用を計画し、提供される機能が必要な場合にのみ専用のモデル デプロイを作成します。
各テナントの専用モデルデプロイ
共有モデル デプロイを使用して、各テナントまたは満たできない特別な要件を持つテナントに対して、モデルデプロイを作成できます。 テナントに専用モデルデプロイを使用する一般的な理由は次のとおりです。
クォータとコスト管理。 専用モデルデプロイでは、各モデルで使用されるトークンの数を追跡することで、テナント固有の TPM 割り当てが容易になります。 この数を使用すると、コストを正確に割り当て、各テナントの使用状況を管理できます。 プロビジョニング済みスループット ユニット (PTU) を使用する場合は、特定の顧客に PTU を割り当て、他の顧客に対して他の課金モデルを使用できます。
コンテンツ フィルタリング ポリシー。 特定のテナントで、許可されていない単語のテナント固有のブロックリストなど、一意のコンテンツ フィルタリング ポリシーが必要になる場合があります。 コンテンツ フィルター ポリシーは、モデルのデプロイのスコープで指定します。
モデルの種類とバージョン。 テナントごとに異なるモデルまたはモデル バージョンを使用する必要がある場合があります。 テナントには、独自のモデル ライフサイクル管理プロセスが必要な場合もあります。
テナント固有の微調整。 テナントごとに個別の微調整されたモデルを作成する場合は、微調整されたモデルごとに個別のモデル デプロイを作成する必要があります。
ほとんどのユース ケースでは、微調整は必要ありません。 通常は、 Azure OpenAI On Your Data または別の取得拡張生成 (RAG) アプローチを使用してモデルを接地することをお勧めします。
データ所在地。 このアプローチでは、個別のデータ所在地要件がサポートされます。 たとえば、厳密なデータ所在地のニーズを持ち、他のテナントにグローバル モデル デプロイを使用するテナントに対して、リージョン モデルのデプロイを提供できます。
各モデル デプロイには一意の URL がありますが、基になるモデルは他の Azure のお客様と共有されていることを覚えておく必要があります。 モデルは、Azure インフラストラクチャも共有します。
Azure OpenAI では、各モデル デプロイに対してアクセス制御が適用されないため、アプリケーションは、どのテナントがどのモデル デプロイに到達できるかを制御する必要があります。
テナント提供の Azure OpenAI リソース
一部のシナリオでは、テナントが独自の Azure サブスクリプションに Azure OpenAI インスタンスを作成し、アプリケーションにアクセス権を付与することがあります。 この方法は、次のシナリオで適切な場合があります。
テナントには、さまざまなモデルへのアクセス、定義されたコンテンツ フィルター ポリシー、プロビジョニングされたスループットの使用状況など、Microsoft からの特定のクォータとアクセス許可があります。
テナントには、ソリューションから使用する必要がある微調整されたモデルがあります。
テナントでは、処理のために、顧客が管理する Azure OpenAI インスタンスを介してデータを処理および送信するために、環境内のコンポーネントが必要です。
テナントのサブスクリプション内の Azure OpenAI インスタンスにアクセスするには、テナントがアクセス権をアプリケーションに提供する必要があります。 アプリケーションは、その Microsoft Entra インスタンスを介して認証する必要があります。 1 つのアプローチは、マルチテナント Microsoft Entra アプリケーションを発行することです。 次のワークフローでは、このアプローチの概要を示します。
テナントは、マルチテナント Microsoft Entra アプリケーションを独自の Microsoft Entra テナントに登録します。
テナントは、マルチテナント Microsoft Entra アプリケーションに Azure OpenAI リソースへの適切なレベルのアクセス権を付与します。 たとえば、テナントは、ロールベースのアクセス制御を使用して 、アプリケーションを Azure AI サービスのユーザー ロールに割り当てることができます。
テナントは、作成する Azure OpenAI リソースのリソース ID を提供します。
アプリケーション コードで、独自の Microsoft Entra インスタンスのマルチテナント Microsoft Entra アプリケーションに関連付けられているサービス プリンシパルを使って、テナントの Azure OpenAI インスタンスにアクセスできます。
または、各テナントに、サービスで使用するサービス プリンシパルを作成し、その資格情報を提供するように求めることもできます。 この方法では、潜在的なセキュリティ責任である各テナントの資格情報を安全に格納および管理する必要があります。
テナントが Azure OpenAI インスタンスに対するネットワーク アクセス制御を構成する場合、それらにアクセスできることを確認します。
次の図は、テナントのサブスクリプション内のテナントごとの Azure OpenAI モデルを示しています。
マルチテナントをサポートする Azure OpenAI の機能
Azure OpenAI には、マルチテナントをサポートする次の機能が用意されています。
アシスタント API
Assistants API は、AI アシスタントの作成に適した機能を Azure OpenAI サービスに追加します。 これには、ツールと API を呼び出し、ファイルを検索して、モデルによって生成される回答を取得する機能が含まれています。 これにより、サービスは永続的な会話スレッドを管理できます。 API は、サンドボックス環境内でコードを生成して実行することもできます。 これらの機能をサポートするには、Assistants API にデータを格納する必要があります。
マルチテナント ソリューションで Assistants API を使用する場合は、1 つのテナント専用のアシスタントを作成するか、複数のテナント間でアシスタントを共有するかを選択できます。 特に共有アシスタントの場合は、格納されているすべてのデータでテナントの分離を検討することが重要です。 たとえば、会話型スレッドがテナントごとに個別に格納されるようにする必要があります。
Assistants API では、関数呼び出しがサポートされています。これは、呼び出す関数と含める引数に関するアプリケーション命令を送信します。 行う関数呼び出しがマルチテナント対応であることを確認します。 1 つの方法は、ダウンストリーム システムへの呼び出しにテナント ID を含める方法です。 アプリケーション内のテナント ID を確認し、言語モデルに依存してテナント ID を伝達しないでください。
あなたのデータを用いた Azure OpenAI
Azure OpenAI On Your Data 機能を使用すると、大規模な言語モデルは、言語モデルからの応答の生成の一環として、インデックスやデータベースなどのナレッジ ソースに直接クエリを実行できます。
要求を行うときは、クエリを実行するデータ ソースを指定できます。 マルチテナント ソリューションでは、データ ソースがマルチテナント対応であり、要求にテナント フィルターを指定できることを確認します。 テナント ID をデータ ソースに適切に伝達します。 たとえば、Azure AI Search に対してクエリを実行するとします。 1 つのインデックスに複数のテナントのデータがある場合は、取得した結果を現在のテナントの ID に制限するフィルターを指定します。 または、テナントごとにインデックスを作成する場合は、現在のテナントに適切なインデックスを指定してください。
バッチ デプロイ
一部のモデルは 、バッチ デプロイを使用して Azure OpenAI にデプロイできます。 バッチデプロイでは、個別の バッチ クォータを使用して、グループ化された要求の非同期処理を有効にします。 バッチ デプロイに送信される要求の目標所要時間は 24 時間で、コストは標準デプロイよりも低くなります。 標準のデプロイとは異なり、バッチ クォータでは、TPM ではなくエンキューされたトークンの数が制限されます。
この展開の種類は、即時応答が不要で、大量の要求を処理してリアルタイムの応答を中断できないシナリオに最適です。
たとえば、ユーザー フィードバックのセンチメントを分析するシステムでは、バッチデプロイを使用して、他のアプリケーションでリアルタイムの対話を実行するために必要な標準のデプロイ クォータの調整を回避できます。 この方法では、処理コストも削減されます。
マルチテナント ソリューションでは、バッチ デプロイをすべてのテナント間で共有したり、テナントごとに個別に作成したりできます。
テナントごとに個別のバッチ デプロイ:
各テナント固有のバッチデプロイにトークン クォータを割り当てることで、単一のテナントがリソースを独占するのを防ぐことができます。 この方法では、テナントごとのトークン使用量の追跡も可能になり、コストの割り当てに役立ちます。
共有バッチデプロイ:
共有バッチデプロイでは、複数のテナントからの要求を、結合されたバッチ ジョブまたは個別のバッチ ジョブで処理できます。 複数のテナントからの要求を 1 つのバッチ ジョブに結合する場合は、応答を適切なテナントに正しくマップできることを確認します。
バッチジョブはジョブレベルで管理されるため、テナントごとに分けることが望ましいです。 この方法では、各テナントのジョブをキャンセルまたは削除できます。 バッチ内の個々の要求を取り消したり削除したりすることはできません。
バッチ デプロイを慎重に管理することで、テナントの分離と運用の柔軟性を維持しながら、コスト効率とリソース割り当てのバランスを取ることができます。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主執筆者:
- Sofia Ferreira |ソフトウェア エンジニア、ISV & DN CoE
その他の共同作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Landon Pierce | カスタマー エンジニア、ISV & DN CoE
- Paolo Salvatori | プリンシパル カスタマー エンジニア、ISV & DN CoE
- ダニエル・スコット=レインズフォード |パートナー ソリューション アーキテクト
- Arsen Vladimirskiy | プリンシパル カスタマー エンジニア、ISV & DN CoE
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。