レート制限は、指定された期間内に MongoDB AIからリクエストできるトークンの頻度と数の制限です。レート制限の詳細については、「 ベストプラクティス 」を参照してください。
Atlas はモデルAPIキー の使用量（1 分あたりのリクエスト数（RPM）と 1 分あたりのトークン数（TPM））に基づいてレート制限を適用します。直近 1 分間のリクエストまたはトークンの数を超えると、 API は後続の追加リクエストを拒否し、429 （レート制限を超え） HTTPステータス コードを返します。
レート制限の管理
次のセクションでは、 Atlas UIでレート制限を管理する方法について説明します。
必要な権限
Project Ownerプロジェクトレベルでレート制限を設定およびリセットするには、Atlas への 以上のアクセス権が必要です。
レート制限を表示するには:
Organization Read Only組織レベルとプロジェクトレベルで、Atlas への 以上のアクセス権が必要です。Project Read Onlyプロジェクトレベルのみで、Atlas への 以上のアクセス権が必要です。
レート制限の設定
プロジェクトレベルでは、プロジェクトごとに異なる制限を設定できます。プロジェクト レベルのレート制限は、組織のレート制限を超えることはできません。プロジェクトレベルで設定されたレート制限は、プロジェクトのすべてのモデルAPIキーに適用されます。
Atlas にログインします。
レート制限の表示
レート制限は、組織とプロジェクトレベルで表示できます。
Atlas にログインします。
ページには、次の情報が表示されます。
名前 | 説明 |
|---|---|
Model | 投票AI埋め込みモデルのリスト。 |
Tokens Per Minute (TPM) | 埋め込み API エンドポイントおよび再ランク付けAPIエンドポイントから 1 分以内にリクエストできるトークンの数。 |
Requests Per Min (RPM) | 埋め込み API エンドポイントと再ランク付けAPIエンドポイントに 1 分以内に送信できるAPIリクエストの数。 |
Atlas にログインします。
Rate Limits左側のナビゲーションから [ を選択します。
ページには、レート制限に関する次の情報が表示されます。
列名 | 列の説明 |
|---|---|
Model | 投票AI埋め込みモデルのリスト。 |
Tokens Per Minute (TPM) | 要求APIAIポイントから 1 分以内にリクエストできるトークンの数。 |
Requests Per Min (RPM) | 1 分以内に MongoDB AI埋め込みと検索APIエンドポイントに送信できるリクエストの数。 |
Actions | 実行可能なアクション。ここでは、次の作業が可能です。
|
カスタム制限を設定している場合、 ページにはすべてのカスタムレート制限を組織のデフォルトに戻すための Reset all limits ボタンも表示されます。
すべてのレート制限をリセット
プロジェクトに設定したすべてのカスタム制限はいつでもリセットできます。制限をリセットすると、プロジェクトのレート制限は組織のデフォルトのレート制限に戻ります。
Atlas にログインします。
使用階層
レート制限は階層化されたシステムに従い、上位階層では制限が大きくなります。階層の資格は、請求使用量（無料トークンを除く）に基づいています。 Atlas は各モデルに対して 20000 万の無料トークンを提供します。マルチモーダル モデルには、15000 億の無料ドットも含まれています。一度階層の資格を取得すると、ダウングレードされることはありません。使用量と支出が増加すると、Atlas は自動的に次の使用階層に引き上げ、すべてのモデルでレート制限を引き上げます。
詳細については、「 レート制限と使用状況階層 」を参照してください。
デフォルトのレート制限
このセクションでは、組織レベルで適用される各使用階層のデフォルトのレート制限について説明します。また、 各プロジェクトに対して設定できるレート制限について説明します。
組織レート制限
次の表は、各投票AI埋め込みモデルの使用階層に基づくデフォルトのレート制限（ TPM と RPM ）を示しています。
モデル | Tokens Per Min (TPM) | 1 分あたりのリクエスト数（RPM） |
|---|---|---|
| 16,000,000 | 2,000 |
| 8,000,000 | 2,000 |
| 3,000,000 | 2,000 |
| 3,000,000 | 2,000 |
| 2,000,000 | 2,000 |
| 4,000,000 | 2,000 |
| 2,000,000 | 2,000 |
使用階層 2 のレート制限は、使用階層 1 の 2 倍です。
モデル | Tokens Per Min (TPM) | 1 分あたりのリクエスト数（RPM） |
|---|---|---|
| 32,000,000 | 4,000 |
| 16,000,000 | 4,000 |
| 6,000,000 | 4,000 |
| 6,000,000 | 4,000 |
| 4,000,000 | 4,000 |
| 8,000,000 | 4,000 |
| 4,000,000 | 4,000 |
使用階層 3 のレート制限は、使用階層 1 の 3 倍です。
モデル | Tokens Per Min (TPM) | 1 分あたりのリクエスト数（RPM） |
|---|---|---|
| 48,000,000 | 6,000 |
| 24,000,000 | 6,000 |
| 9,000,000 | 6,000 |
| 9,000,000 | 6,000 |
| 6,000,000 | 6,000 |
| 12,000,000 | 6,000 |
| 6,000,000 | 6,000 |
プロジェクト レートの制限
デフォルトでは 、プロジェクトは組織のレート制限に基づいてレート制限を継承します。ただし、プロジェクトレベルではプロジェクトごとに異なる制限を設定できます。プロジェクト レベルのレート制限は、組織のレート制限を超えることはできません。プロジェクトレベルで設定されたレート制限は、プロジェクトのすべてのモデルAPIキーに適用されます。ただし、組織のレート制限に最初に達した場合、プロジェクトはより低いレートに制限される可能性があります。これは、すべてのプロジェクトレート制限の合計が組織の制限を超える場合に発生する可能性があります。
例
レート制限 P1 、P2 、P3 を持つ 3 つのプロジェクトを持つ組織レート制限 O を検討します。以下の表は、プロジェクトのレート制限の合計が組織のレート制限以下であるか、組織のレート制限より大きい 3 つのシナリオを示しています。各シナリオごとに、組織の制限に達できるかどうか、およびプロジェクトの使用が別のプロジェクトに影響かどうかを示します。
Scenario 1 P1 + P2 + P3 < O | Scenario 2 P1 + P2 + P3 = O | Scenario 3 P1 + P2 + P3 > O | |
|---|---|---|---|
シナリオの説明 | すべてのプロジェクトレート制限の合計が組織の制限より小さいです。 | すべてのプロジェクトレート制限の合計は、組織の制限と等しくなります。 | すべてのプロジェクトレート制限の合計が組織の制限を超えています。 |
組織の制限に達できますか。 | いいえ、すべてのプロジェクトがレート制限に達した場合でも、組織のレート制限は超えることはありません。 | はい、すべてのプロジェクトがレート制限に達すると、組織の制限にも達します。 | はい、すべてのプロジェクトレート制限の合計が組織の制限を超えるため、個々のプロジェクトが自分の制限に達する前に組織の制限に達する可能性があります。 |
あるプロジェクトの使用は、他のプロジェクトに影響を与えますか。 | No. | No. | はい。プロジェクトが個別の制限に達する前に、組織の制限に達するのに十分な使用量を消費する場合、プロジェクトは個々の制限よりも低いレートに制限できます。 |
ベストプラクティス
レート制限により、 APIのリソースのバランスの取れた効率的な使用が確保され、サービス全体のパフォーマンスとアクセスに影響可能性のある過剰なトラフィックを防ぎます。具体的には、レート制限は次の重要な目的で役立ちます。
レート制限により、すべてのユーザーがAPIに均等にアクセスできるようになります。 1 つの個人または組織が過剰な量のリクエストを生成すると、他のユーザーのAPIのパフォーマンスが影響を受ける可能性があります。レート制限により、より多くのユーザーがパフォーマンスの問題が発生することなくAPIを利用できるようになります。
レート制限により、投票AI はインフラストラクチャ上のワークロードを効果的に管理できるようになります。およびAPIリクエストの大幅な急増により、サーバーのリソースに負担がかかり、パフォーマンスの低下につながる恐れがあります。レート制限を設定することで、投票AI はすべてのユーザーに対して一貫性と信頼性の高いエクスペリエンスを効果的に維持できます。
これらはAPIの潜在的な誤使用または誤使用を防ぐために機能します。インスタンス、悪意のあるアクターは、過剰なリクエストでAPIを埋め込み、過剰な負荷を与えたり、そのサービスを中断しようとしたりする可能性があります。レート制限を設定することで、投票AI はこのような望ましくないアクティビティを回避できます。
レート制限エラーを回避および管理するために、次のベストプラクティスを使用することをお勧めします。
大きなバッチを使用する
埋め込むドキュメントが多い場合は、リクエストごとに埋め込むドキュメントの数を増やし、より大きなバッチを送信することで全体的なスループットを向上させることができます。 「バッチする」は 1 回のリクエストに埋め込むドキュメントのコレクションであり、「バッチするサイズ 」はバッチする内のドキュメントの数、つまりドキュメントのリストの長さを意味します。
例
512ドキュメントをベクトル化するとします。1 512のバッチするサイズを使用した場合、これには リクエストが必要になり、RPM 制限に達する可能性があります。ただし、 のバッチするサイズを使用した場合は、128 4リクエストのみが必要になり、RPM 制限に達することはありません。リクエストで提供するドキュメント数を変更することでバッチするサイズを制御できます。バッチするサイズを使用すると、特定のドキュメント数の全体的な RPM が削減されます。
バッチするサイズを選択する際には、 API の最大バッチするサイズとトークンを考慮する必要があります。 API の最大バッチするサイズを超えることはできません。より長いドキュメントがある場合、リクエストあたりのトークン制限によって小さなバッチするサイズに制約される可能性があります。
待機期間の設定
リクエストの頻度を減らします。リクエストをページ分割することで、これを実現できます。最も簡単なアプローチとして、各リクエストの間に待機期間を挿入する方法があります。
指数バックオフの実行
レート制限に達したら、バックオフします（つまり、429 エラーを受け取ります）。レート制限エラーを受け取った後、再度試行する前に、時間が指数的に増加するのを待ってください。リクエストが成功するまで、または最大再試行回数に達するまで待機します。
例
最初の待機時間が 1 秒で、成功する前に 3 回連続でレート制限エラーが発生した場合は、リクエストを再送信する前に、それぞれ 1 秒、2 秒、4 秒後に待機します。