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