使用限制
為了減少濫用並管理我們 API 的容量,我們對組織使用 Claude API 的程度實施了限制。
我們有兩種限制:
- 費用限制設定組織每月 API 使用的最高成本。
- 速率限制設定組織在特定時間內可以發出的最大 API 請求數。
我們在組織層級執行服務配置的限制,但您也可以為組織的工作區設定使用者可配置的限制。
關於我們的限制
- 限制旨在防止 API 濫用,同時最大限度地減少對常見客戶使用模式的影響。
- 限制由使用層級定義,每個層級都有不同的費用和速率限制。
- 當您在使用 API 時達到某些閾值,您的組織將自動提升層級。 限制設定在組織層級。您可以在 Anthropic Console 的限制頁面中查看您組織的限制。
- 您可能在較短的時間間隔內達到速率限制。例如,每分鐘 60 個請求(RPM)的速率可能會被執行為每秒 1 個請求。短時間內大量的請求可能會超過速率限制並導致速率限制錯誤。
- 以下概述的限制是我們的標準限制。如果您需要更高的自定義限制,請通過 Anthropic Console 聯繫銷售團隊。
- 我們使用令牌桶算法來進行速率限制。這意味著您的容量會持續補充到最大限制,而不是在固定時間間隔重置。
- 此處描述的所有限制代表最大允許使用量,而不是保證的最低限制。這些限制旨在減少意外超支並確保用戶之間資源的公平分配。
費用限制
每個使用層級對您每個日曆月可以在 API 上花費的金額都有限制。一旦您達到當前層級的費用限制,在符合下一層級資格之前,您需要等到下個月才能再次使用 API。
要符合下一層級的資格,您必須滿足存款要求。為了最大限度地降低超額資金的風險,您不能存入超過每月費用限制的金額。
提升層級的要求
使用層級 | 信用購買 | 每月最大使用量 |
---|---|---|
第 1 層 | $5 | $100 |
第 2 層 | $40 | $500 |
第 3 層 | $200 | $1,000 |
第 4 層 | $400 | $5,000 |
月度開票 | 不適用 | 不適用 |
速率限制
我們對 Messages API 的速率限制是按每分鐘請求數(RPM)、每分鐘輸入令牌數(ITPM)和每分鐘輸出令牌數(OTPM)來衡量的,這些限制針對每個模型類別。
如果您超過任何速率限制,您將收到一個 429 錯誤,說明超過了哪個速率限制,以及一個 retry-after
標頭,指示需要等待多長時間。
ITPM 速率限制在每個請求開始時進行估算,並在請求期間根據實際使用的輸入令牌數進行調整。
最終調整會將 input_tokens
和 cache_creation_input_tokens
計入 ITPM 速率限制,而 cache_read_input_tokens
則不計入(但仍會收費)。
在某些情況下,cache_read_input_tokens
會計入 ITPM 速率限制。
OTPM 速率限制在每個請求開始時根據 max_tokens
進行估算,並在請求結束時根據實際使用的輸出令牌數進行調整。
如果您比預期更早達到 OTPM 限制,請嘗試減少 max_tokens
以更好地估算完成的大小。
速率限制分別應用於每個模型;因此,您可以同時使用不同的模型,直到達到各自的限制。 您可以在 Anthropic Console 中查看您當前的速率限制和行為。
模型 | 每分鐘最大請求數 (RPM) | 每分鐘最大輸入令牌數 (ITPM) | 每分鐘最大輸出令牌數 (OTPM) |
---|---|---|---|
Claude 3.7 Sonnet | 50 | 20,000 | 8,000 |
Claude 3.5 Sonnet 2024-10-22 | 50 | 40,000* | 8,000 |
Claude 3.5 Sonnet 2024-06-20 | 50 | 40,000* | 8,000 |
Claude 3.5 Haiku | 50 | 50,000* | 10,000 |
Claude 3 Opus | 50 | 20,000* | 4,000 |
Claude 3 Sonnet | 50 | 40,000* | 8,000 |
Claude 3 Haiku | 50 | 50,000* | 10,000 |
標有星號(*)的限制將 cache_read_input_tokens
計入 ITPM 使用量。
Message Batches API
Message Batches API 有其自己的速率限制,這些限制在所有模型之間共享。這包括所有 API 端點的每分鐘請求數(RPM)限制,以及同時在處理佇列中的批次請求數量限制。這裡的「批次請求」指的是 Message Batch 的一部分。您可以創建包含數千個批次請求的 Message Batch,每個請求都計入此限制。當批次請求尚未被模型成功處理時,它被視為處理佇列的一部分。
每分鐘最大請求數 (RPM) | 處理佇列中的最大批次請求數 | 每批次的最大批次請求數 |
---|---|---|
50 | 100,000 | 100,000 |
為工作區設置較低限制
為了保護組織中的工作區免受潛在過度使用,您可以為每個工作區設置自定義費用和速率限制。
例如:如果您組織的限制是每分鐘 40,000 個輸入令牌和每分鐘 8,000 個輸出令牌,您可能會將一個工作區限制為每分鐘總共 30,000 個令牌。這可以保護其他工作區免受潛在過度使用,並確保組織內資源的更公平分配。剩餘未使用的每分鐘令牌(或者如果該工作區未使用限制,則更多)則可供其他工作區使用。
注意:
- 您不能對預設工作區設置限制。
- 如果未設置,工作區限制與組織限制相同。
- 即使工作區限制加起來更多,組織範圍的限制始終適用。
- 未來將為工作區添加輸入和輸出令牌限制的支持。
回應標頭
API 回應包含顯示強制執行的速率限制、當前使用情況和限制重置時間的標頭。
返回以下標頭:
標頭 | 描述 |
---|---|
retry-after | 在可以重試請求之前需要等待的秒數。提前重試將會失敗。 |
anthropic-ratelimit-requests-limit | 在任何速率限制期間內允許的最大請求數。 |
anthropic-ratelimit-requests-remaining | 在被速率限制之前剩餘的請求數。 |
anthropic-ratelimit-requests-reset | 請求速率限制將完全補充的時間,以 RFC 3339 格式提供。 |
anthropic-ratelimit-tokens-limit | 在任何速率限制期間內允許的最大令牌數。 |
anthropic-ratelimit-tokens-remaining | 在被速率限制之前剩餘的令牌數(四捨五入到最接近的千)。 |
anthropic-ratelimit-tokens-reset | 令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。 |
anthropic-ratelimit-input-tokens-limit | 在任何速率限制期間內允許的最大輸入令牌數。 |
anthropic-ratelimit-input-tokens-remaining | 在被速率限制之前剩餘的輸入令牌數(四捨五入到最接近的千)。 |
anthropic-ratelimit-input-tokens-reset | 輸入令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。 |
anthropic-ratelimit-output-tokens-limit | 在任何速率限制期間內允許的最大輸出令牌數。 |
anthropic-ratelimit-output-tokens-remaining | 在被速率限制之前剩餘的輸出令牌數(四捨五入到最接近的千)。 |
anthropic-ratelimit-output-tokens-reset | 輸出令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。 |
anthropic-ratelimit-tokens-*
標頭顯示當前生效的最嚴格限制的值。例如,如果您已超過工作區每分鐘令牌限制,標頭將包含工作區每分鐘令牌速率限制值。如果工作區限制不適用,標頭將返回剩餘的總令牌數,其中總數是輸入和輸出令牌的總和。這種方法確保您能夠看到當前 API 使用的最相關限制。