サービスのクォータと制限

このコンテンツの適用対象: checkmarkv4.0 (プレビュー) | 以前のバージョン: blue-checkmarkv3.1 (GA)blue-checkmarkv3.0 (GA)

このコンテンツの適用対象: checkmarkv2.1 | 最新バージョン: blue-checkmarkv4.0 (プレビュー)

この記事には、すべての価格レベルの Azure AI Document Intelligence サービスのクォータと制限に関するクイック リファレンスと詳細な説明の両方が記載されています。 また、要求のスロットリングを回避するためのベスト プラクティスについても説明します。

モデルの使用法

サポートされているドキュメントの種類 既読 Layout 事前構築済みのモデル カスタム モデル
PDF ✔️ ✔️ ✔️ ✔️
画像 (JPEG/JPG)、PNG、BMP、TIFF、HEIF ✔️ ✔️ ✔️ ✔️
Office ファイルの種類 DOCX、PPTX、XLS ✔️ ✖️ ✖️ ✖️
サポートされているドキュメントの種類 既読 Layout 事前構築済みのモデル カスタム モデル
PDF ✔️ ✔️ ✔️ ✔️
画像 (JPEG/JPG)、PNG、BMP、TIFF、HEIF ✔️ ✔️ ✔️ ✔️
Office ファイルの種類 DOCX、PPTX、XLS ✔️ ✔️ ✖️ ✖️
Quota Free (F0)1 Standard (S0)
1 秒あたりのトランザクション数の制限 1 15 (既定値)
調整可能 いいえ はい 2
ドキュメントの最大サイズ 4 MB 500 MB
調整可能 いいえ いいえ
ページの最大数 (分析) 2 2000
調整可能 いいえ いいえ
ラベル ファイルの最大サイズ 10 MB 10 MB
調整可能 いいえ いいえ
OCR json 応答の最大サイズ 500 MB 500 MB
調整可能 いいえ いいえ
テンプレート モデルの最大数 500 5000
調整可能 いいえ いいえ
ニューラル モデルの最大数 100 500
調整可能 いいえ いいえ

カスタム モデルの使用

Quota Free (F0) 1 Standard (S0)
Compose モデルの制限 5 200 (既定値)
調整可能 いいえ いいえ
トレーニング データセット サイズ * ニューラル 1 GB 3 1 GB (既定値)
調整可能 いいえ いいえ
トレーニング データセット サイズ * テンプレート 50 MB 4 50 MB (既定値)
調整可能 いいえ いいえ
ページの最大数 (トレーニング) * テンプレート 500 500 (既定値)
調整可能 いいえ いいえ
ページの最大数 (トレーニング) * ニューラル 50,000 50,000 (既定値)
調整可能 いいえ いいえ
カスタム ニューラル モデルのトレーニング 1 か月あたり 10 1 か月あたり 20
調整可能 いいえ はい 3
ページの最大数 (トレーニング) * 分類子 10,000 10,000 (既定値)
調整可能 いいえ いいえ
ドキュメントの種類 (クラス) の最大数 * 分類子 500 500 (既定値)
調整可能 いいえ いいえ
トレーニング データセット サイズ * 分類子 1GB 1GB (既定値)
調整可能 いいえ いいえ
クラスあたりの最小サンプル数 * 分類子 5 5 (既定値)
調整可能 いいえ いいえ

カスタム モデルの制限

Quota Free (F0) 1 Standard (S0)
Compose モデルの制限 5 200 (既定値)
調整可能 いいえ いいえ
トレーニング データセット サイズ 50 MB 50 MB (既定値)
調整可能 いいえ いいえ
ページの最大数 (トレーニング) 500 500 (既定値)
調整可能 いいえ いいえ

1Free (F0) 価格レベルについては、価格ページで月額料金に関するページを参照してください。
2ベスト プラクティスおよび [調整手順 (#create-and-submit-support-request)] に関するセクションを参照してください。
3 ニューラル モデルのトレーニング数は暦月ごとにリセットされます。 サポート リクエストを提出し、毎月のトレーニング制限を引き上げます。

4 この制限は、ラベル付け関連の更新の前にトレーニング データセット フォルダー内で見つかるすべてのドキュメントに適用されます。

詳細な説明、クォータの調整、およびベスト プラクティス

クォータの引き上げを要求する前に (該当する場合)、それが必要であることを確認します。 Document Intelligence サービスでは、自動スケーリングを用いて必要なコンピューティング リソースをオンデマンドで提供すると同時に、顧客のコストを低く抑えるために、過剰なハードウェア容量を維持しないようにして未使用のリソースをプロビジョニング解除します。

アプリケーションから応答コード 429 ("要求が多すぎます") が返され、ワークロードが定義された制限内である場合、原因として最も可能性が高いのは、サービスが要求に対応するようにスケールアップされた一方で、必要なスケールに達していないということです。 このため、サービスには、要求に対応するための十分なリソースがすぐには準備されません。 この状態は一時的なものであり、長くは続かないはずです。

自動スケーリング時のスロットリングを緩和するための一般的なベスト プラクティス

スロットリングに関連する問題 (応答コード 429) を最小限に抑えるには、次の手法を使用することをお勧めします。

  • アプリケーションで再試行ロジックを実装します。
  • ワークロードが急激に変化しないようにします。 ワークロードは徐々に増やします
    例。 アプリケーションで Document Intelligence が使用されており、現在のワークロードは 10 TPS (1 秒あたりのトランザクション数) です。 次の 1 秒間で、負荷を 40 TPS (4 倍以上) に増やしたとします。 この新しい負荷に対応するため、サービスでは直ちにスケールアップが開始されますが、おそらく 1 秒以内に処理することはできないため、一部の要求では応答コード 429 が返されます。

次のセクションでは、クォータを調整する特定のケースについて説明します。 Document Intelligence: 同時要求の制限を引き上げる方法に移動

1 秒あたりのトランザクション数に関する要求の制限を引き上げる

既定では、1 秒あたりのトランザクション数は、Document Intelligence リソースに対して 1 秒あたり 15 トランザクションに制限されます。 Standard 価格レベルでは、この数を増やすことができます。 要求を送信する前に、こちらのセクションの資料について理解していること、およびこれらのベスト プラクティスを把握していることを確認してください。

同時要求の上限を上げても、コストに直接影響することはありません。 Document Intelligence サービスでは、"使用した分だけ支払う" モデルを使用しています。 この制限によって、要求のスロットリングが開始される前に、サービスをどの程度スケーリングできるかが定義されます。

同時要求の上限パラメーターの既存の値は、Azure portal、コマンドライン ツール、または API 要求では表示されません。 既存の値を確認するには、Azure サポート リクエストを作成します。

1 秒あたりのトランザクション数を増やす場合は、リソースの自動スケーリングを有効にすることができます。 このドキュメントに従って、リソースの自動スケーリングを有効にします * 自動スケーリングを有効にする。 TPS の増加サポート要求を送信することもできます。

以下の必要な情報を準備します

  • Document Intelligence リソース ID

  • リージョン

  • 情報を取得する方法 (ベース モデル) :

    • Azure ポータル
    • トランザクションの上限を引き上げる Document Intelligence リソースを選択します
    • プロパティ (リソース管理グループ) を選択します
    • 次のフィールドの値をコピーして保存しておきます。
      • リソース ID
      • 場所 (エンドポイントのリージョン)

サポート リクエストの作成と送信

サポート リクエストを送信して、リソースの 1 秒あたりのトランザクション数 (TPS) の制限を引き上げる手順を開始します。

  • 必要な情報があることを確認します
  • Azure ポータル
  • TPS の上限を引き上げる Document Intelligence リソースを選択します
  • [新しいサポート リクエスト] ( [サポート + トラブルシューティング] グループ) を選択します
  • Azure サブスクリプションと Azure リソースに関する情報が自動的に入力された新しいウィンドウが表示されます
  • "概要" を入力します (「Document Intelligence TPS の上限を引き上げる」など)
  • [問題の種類] で、[クォータまたは使用状況の検証] を選択します
  • [次へ: ソリューション] を選択します
  • 要求の作成を進めます
  • [詳細] タブで、[説明] フィールドに次の情報を入力します。
    • 要求が Document Intelligence クォータに関するものであることを示すメモ。
    • TPS に関して希望するスケーリングの目標値を指定
    • 収集した Azure リソース情報
    • 必要な情報を入力して、[確認と作成] タブの [作成] ボタンを選択します
    • Azure portal 通知のサポート リクエスト番号をメモしておきます。 後続の処理のための連絡が間もなくして届きます

ワークロード パターンの例のベスト プラクティス

この例では、自動スケーリングが進行中であることによって発生する可能性がある要求のスロットリングを軽減するために、次のようなアプローチを推奨しています。 これは「正確なレシピ」ではなく、必要に応じて従い、調整するテンプレートにすぎません。

Document Intelligence リソースに既定の制限が設定されているとします。 ワークロードを開始して、分析要求を送信します。 応答コード 429 で頻繁にスロットリングが発生している場合、まず、GET 分析応答リクエストでエクスポネンシャル バックオフを実装します。 連続するエラー応答の再試行間で待機時間を徐々に長くします。たとえば、リクエスト間の遅延パターンを 2-5-13-34 にします。 一般に、対応する POST 要求に対して 2 秒に 1 回以上応答分析取得を呼び出さないことをお勧めします。

送信されるドキュメントの POST 要求の数が調整されていることがわかった場合は、要求間に遅延を追加することを検討してください。 ワークロードでより高度な同時処理が必要な場合は、サポート リクエストを作成して、1 秒あたりのトランザクションのサービス制限を引き上げる必要があります。

一般に、運用環境に移行する前にワークロードとワークロード パターンをテストしておくことをお勧めします。

次のステップ