Azure Government の Azure OpenAI Service と機能
この記事では、Azure Government での Azure OpenAI の使用について、商用クラウド オファリングと比較した場合の相違点を説明します。 Azure OpenAI Service 自体の詳細については、Azure OpenAI Service のドキュメントを参照してください。
Azure OpenAI のモデル
各モデルのさまざまな機能の詳細については、「Azure OpenAI Service モデル」を参照してください。 事業継続とディザスター リカバリー (BCDR) の考慮事項をご覧になるお客様は、すべてのモデルと種類の組み合わせを両方のリージョンで使用できるわけではないので、以下のデプロイの種類、リージョン、モデルの利用可能性に注意してください。
次のセクションでは、リージョンとデプロイの種類ごとにモデルの使用可否を示します。
標準の展開モデルの可用性
| リージョン | gpt-35-turbo、1106 | gpt-35-turbo、0125 | gpt-4、1106-Preview | gpt-4o、2024 年 5 月 13 日 | text-embedding-ada-002 |
|---|---|---|---|---|---|
| usgovarizona | - | ✅ | ✅ | ✅ | ✅ |
| usgovvirginia | ✅ | ✅ | ✅ | - | ✅ |
従量課金制消費モデルのクォータの引き上げを依頼するには、https://aka.ms/AOAIGovQuota に申請してください
プロビジョニング済みデプロイ モデルの可用性
| リージョン | gpt-35-turbo、1106 | gpt-35-turbo、0125 | gpt-4、1106-Preview | gpt-4o、2024 年 5 月 13 日 |
|---|---|---|---|---|
| usgovarizona | - | ✅ | - | ✅ |
| usgovvirginia | - | ✅ | ✅ | ✅ |
Note
プロビジョニング スループット ユニット (PTU) は、Azure OpenAI の標準クォータとは異なり、Azure Government の既定では利用できません。 このオファリングの詳細については、Microsoft アカウント チームにお問い合わせください。
Azure OpenAI の機能
| 機能 | 説明 |
|---|---|
| データの接続 | USGovVirginia と USGovArizona で使用できます。 仮想ネットワークとプライベート リンクがサポートされています。 Copilot Studio での Web アプリまたはコパイロットへのデプロイはサポートされていません。 |
| マネージド ID | はい。Microsoft Entra ID を使用 |
| 仮想ネットワークのサポートとプライベート リンクのサポート | はい。 |
| UI エクスペリエンス | Azure portal (アカウントとリソースの管理) モデル探索のための Azure OpenAI Studio |
| 不正使用の監視 | Azure Government の Azure OpenAI では、不正使用監視機能の一部は有効ではありません。 製品条件に違反するサービスの使用を検出して軽減するための合理的な技術的および運用上の措置は、お客様が実装する必要があります。 Azure Government の自動コンテンツ分類とフィルタリングは既定で有効なままです。 変更されたコンテンツ フィルターが必要な場合は、https://aka.ms/AOAIGovModifyContentFilter に申請してください |
| データ ストレージ | Azure Government では、現在、顧客の保存データを格納する Azure OpenAI 機能は有効になっていません。 ただし、Azure Government でカスタマー マネージド キー (CMK) を有効にして、パブリック クラウドと同じポリシーの使用を Azure Government でサポートすることができます。 また、今後、顧客データを格納する Azure OpenAI 機能が Azure Government で有効になった場合、その時点で既存の CMK デプロイがそのデータに適用されることにも注意してください。 詳細については、Azure OpenAI のデータ プライバシーに関する記事を参照してください。 |
| コンプライアンス | Azure Government における Azure OpenAI コンプライアンスの現在の状態については、Azure Government サービスの監査スコープに関する記事を参照してください |
| サービス エンドポイント | openai.azure.us |
| キー ポータル |
|
Azure Government でのプロビジョニング済みデプロイ
以下のガイドでは、Azure Government の Azure OpenAI Service リソースを使用するプロビジョニングされたデプロイを設定する手順について説明します。
前提条件
- Azure Government サブスクリプション
- Azure OpenAI リソース ID
- プロビジョニングされたデプロイのクォータが承認され、コミットメントを購入済みであること
プロビジョニング スループット コミットメントの管理
Azure Government の Azure OpenAI の場合、プロビジョニング スループットのデプロイには、Azure OpenAI Studio の [コミットメントの管理] ビューで作成および管理される、事前購入されたコミットメントが必要です。 このビューに移動するには、[クォータ] ウィンドウから [コミットメントの管理] を選択します。
[コミットメントの管理] ビューでは、いくつかの操作を実行できます。
- 新しいコミットメントを購入するか、既存のコミットメントを編集します。
- サブスクリプション内のすべてのコミットメントを監視します。
- 予期しない課金を引き起こす可能性のあるコミットメントを特定し、アクションを実行します。
| 設定 | メモ |
|---|---|
| リソースの選択 | プロビジョニングされたデプロイを作成するリソースを選択します。 コミットメントを購入すると、現在のコミットメントが期限切れになるまで、別のリソースでクォータを使用できなくなります。 |
| コミットメント期間を選択します | [プロビジョニング済み] を選択します。 (プロビジョニング済みは、プロビジョニング済みマネージドと同義です) |
| 現在コミットされていないプロビジョニング済みクォータ | このリソースにコミットするために現在使用できる PTU の数。 |
| コミットする量 (PTU) | コミットする PTU 数を選びます。 コミットメント期間中にこの数を増やすことができますが、減らすことはできません。 コミットメントタイプ "プロビジョニング済み" の場合、50 の増分で値を入力します。 |
| 現在の期間のコミットメント レベル | コミットメント期間は 1 か月に設定されます。 |
| 更新設定 | 現在の PTU での自動更新 下位の PTU での自動更新 自動更新しない |
重要
新しいコミットメントは、期間全体に対して事前に課金されます。 更新の設定が自動更新に設定されている場合、更新日のたびに更新の設定に基づいて再度請求されます。
重要
コミットメントに PTU を追加すると、現在の日付から既存のコミットメント期間の終了日までの期間分に応じて即時請求されます。 PTU を追加しても、コミットメント期間はリセットされません。
更新設定の変更
コミットメントの更新設定は、コミットメントの有効期限前ならいつでも変更できます。
重要
コミットメントを期限切れにしてしまうか、リソースのコミットメントよりも多い PTU をリソースのデプロイが必要とするほどサイズを小さくしてしまった場合、余分な PTU に対して時間単位の超過料金が発生します。 たとえば、デプロイの合計が 500 PTU でコミットメントが 300 PTUのリソースの場合、200 PTU に対して時間単位の超過料金が発生します。
コミットメント管理の一般的なシナリオ
プロビジョニング スループットの使用を終了する
プロビジョニング スループットの使用を終了し、コミットメントの有効期限が切れた後に時間単位の超過料金が発生しないようにするには、次の 2 つの手順を実行する必要があります。
- すべてのコミットメントの更新ポリシーを [自動更新しない] に設定します。
- クォータを使って、プロビジョニングされたデプロイを削除します。
コミットメントまたはデプロイを同じサブスクリプションまたはリージョン内の新しいリソースに移動する
Azure OpenAI Studio では、デプロイやコミットメントを新しいリソースに直接 "移動" することはできません。 代わりに、ターゲット リソース上に新しいデプロイを作成し、トラフィックをそこに移動する必要があります。 このプロセスでは、新しいリソースに対する新しいコミットメントの購入が必要です。 コミットメントは、30 日間分、前払いで課金されるため、新しいコミットメントとの重複と、重複期間中の "二重課金" を最小限に抑えるために、この移行のタイミングを元のコミットメントの期限切れに合わせる必要があります。
この移行を実装するには 2 つのアプローチがあります。
オプション 1: オーバーラップなしの切り替え
このオプションの場合、ある程度のダウンタイムが必要ですが、追加のクォータは必要なく、追加のコストも発生しません。
| 手順 | メモ |
|---|---|
| 既存のコミットメントの更新ポリシーを期限切れに設定します | このアクションにより、コミットメントの更新とさらなる課金を防ぐことができます |
| 既存のコミットメントが期限切れになる前に、そのデプロイを削除します | ダウンタイムはこの時点から始まり、新しいデプロイが作成され、トラフィックが移動されるまで続きます。 有効期限の日時にできるだけ近いタイミングで削除することで、この期間を最小限に抑えることができます。 |
| 既存のコミットメントが期限切れになったら、新しいリソースにコミットメントを作成します | 有効期限が切れた後すぐにこの手順と以下の手順を実行して、ダウンタイムを最小限に抑えます。 |
| 新しいリソース上にデプロイを作成し、そこにトラフィックを移動します |
オプション 2: 重複する切り替え
このオプションでは、既存のデプロイと新しいデプロイの両方が同時に稼働するため、ダウンタイムは発生しません。 この方法では、新しいデプロイを作成するために使用できるクォータが必要になるため、デプロイが重複している間は追加のコストが発生します。
| 手順 | メモ |
|---|---|
| 既存のコミットメントの更新ポリシーを期限切れに設定します | こうすることで、コミットメントの更新とさらなる課金を防ぐことができます。 |
| 既存のコミットメントの有効期限が切れる前: 1.新しいリソースにコミットメントを作成します。 2.新しいデプロイを作成します。 3.トラフィックを切り替えます 4.既存のデプロイを削除します |
既存のコミットメントが期限切れになる前にすべての手順を完了できる十分な時間を確保してください。そうしないと、オプションに対して超過料金が発生します (次のセクションを参照してください)。 |