本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
速率限制最佳實務
本主題提供在閘道上有效設計、部署和操作速率限制的指引。
設計模式
- 分層存取
-
使用相同的維度索引鍵 (
$.context.jwt.sub或$.context.jwt.tier) 為每個層建立多個速率限制,但項目不同。使用已知進階使用者的確切項目,並將*項目作為預設層。 - 深度防禦
-
多個精細度的層率限制。例如,結合每個目標 RPS 限制 (保護後端容量) 與每個呼叫者 RPM 限制 (防止個別濫用) 和每個工具字符限制 (控制成本)。
- BatchPut 的基礎設施即程式碼
-
使用
BatchPutGatewayRateLimits宣告性管理您的速率限制組態。Batch put 使用 upsert 語意,因此可以從 CI/CD 管道或基礎設施範本重複執行。 - 逐步推展
-
從慷慨的速率限制開始,並根據觀察到的流量模式隨著時間的推移進行收緊。在降低限制之前,監控
aws.agentcore.gateway.throttle.customer.decisionOTEL 跨度屬性和 429 回應率。 - 緊急區塊
-
使用
rate: 0項目在事件期間封鎖特定呼叫者、目標或工具。一旦傳播完成 (最多 30 秒),區塊就會生效。
維度鍵選擇指引
選擇產生限制、可預測的速率儲存貯體數量的維度索引鍵:
| 維度鍵 | 基數 | 建議 |
|---|---|---|
|
|
低 (已知集合) |
絕佳的選擇。使用 進行每個目標的保護。 |
|
|
中低 |
使用已知工具集的 MCP 閘道的理想選擇。 |
|
|
低 (已知集合) |
非常適合推論閘道。 |
|
|
中高 |
適用於每個使用者限制。您的使用者群所限制的基數。 |
|
|
低 |
非常適合每個團隊配額。 |
|
|
中 |
適用於 IAM 驗證設定中的每個角色限制。 |
|
|
無限制 |
請勿使用。為每個字符建立唯一的儲存貯體。 |
|
|
無限制 |
請勿使用。為每個請求建立唯一的儲存貯體。 |
警告
無限制的維度索引鍵 (例如 $.context.jwt.jti或 請求範圍的宣告) 會建立無限數量的速率儲存貯體。這會浪費記憶體、降低效能,並有效地停用速率限制,因為每個請求都會取得自己的儲存貯體,而且永遠不會調節。
字符速率限制考量事項
由於以預算為基礎的強制執行模式,字符率限制需要特殊考量:
-
預算使用率:閘道會在轉送之前預估輸入字符,並在回應後記錄實際用量。短期爆量可能會暫時超過設定的速率。
-
串流選項:對於串流聊天完成請求 (
/v1/chat/completions),當字符速率限制處於作用中狀態且選項尚未存在時,閘道會自動"stream_options": {"include_usage": true}新增至請求內文。這可針對 TPM 強制執行啟用準確的權杖會計。 -
支援的路徑:字符速率限制僅適用於已知推論路徑 (
/v1/chat/completions、/v1/messages、) 上的請求/v1/responses。對其他路徑的請求不受字符限制。 -
傳遞目標:如果您的目標代理到模型提供者,但未使用已知的推論路徑,則字符速率限制不適用。考慮使用請求率限制或重組您的目標,以使用支援的路徑。
字符速率限制常見問答集
本節回答有關token-per-minute(TPM) 強制執行如何實際運作的常見問題。
- TPM 強制執行如何運作?
-
閘道使用以預算為基礎的強制執行模型。當請求送達時,閘道會估計輸入字符計數,並從您設定的 TPM 預算中保留該數量。如果預估超過剩餘預算,則會在請求到達模型之前,使用 HTTP 429 回應拒絕請求。成功請求完成後,閘道會將初始預估取代為模型提供者報告的實際字符用量 (輸入 + 輸出字符),以協調預算。
- TPM 如何使用提示快取?
-
閘道會根據模型提供者在推論回應中傳回的
input_tokens和output_tokens值來考慮權杖。閘道不會獨立追蹤或調整提示快取。快取字符是否包含在 中input_tokens,取決於模型提供者報告用量的方式 — 此行為因提供者而異。請參閱模型提供者的文件,以了解提示快取如何影響報告的字符計數和有效的 TPM 耗用。 - 如果我的 TPM 限制為 50,且權杖化器預估 51 個輸入權杖,請求是否受到調節?
-
是。在轉送請求之前,閘道會根據剩餘的 TPM 預算評估字符器的預估值。如果預估超過可用預算,則會使用 HTTP 429 回應拒絕請求。回應包含一個
retryAfter欄位,指出何時有足夠的預算可用。 - 如果長時間執行的請求耗用比最初預估更多的權杖,回應是否會受到調節?
-
否。一旦閘道接受並轉送請求,回應一律會完整交付。閘道會在請求時保留預估權杖,並在請求進行時繼續根據剩餘預算評估其他請求。回應完成時,閘道會將實際用量與預估值進行核對。如果實際耗用量較高,預算會調整,這可能會導致後續請求受到調節,但原始回應永遠不會中斷。
- 字符會計如何使用串流回應?
-
閘道使用最終回應區塊做為權杖對帳的事實來源。並非所有模型提供者都會報告每個串流區塊中的字符用量,有些只包含在最終區塊中。在調節 TPM 預算之前,閘道會等待完整的回應。對於 OpenAI 聊天完成串流,當字符速率限制處於作用中狀態且此選項尚未存在時,閘道會自動
"stream_options": {"include_usage": true}新增至請求內文,以確保在最終區塊中提供準確的字符計數。
營運考量事項
- 傳播時間
-
速率限制變更最多需要 30 秒才能傳播。在事件期間規劃此延遲 — 區塊項目 (
rate: 0) 不是立即的。 - 評分為零行為
-
0 的速率會封鎖所有相符的流量。刻意將此用於緊急封鎖。在設定 之前再次檢查項目維度值
rate: 0,以避免意外封鎖合法流量。 - 不可變維度索引鍵
-
您無法變更現有費率限制
dimensionKeys的 。如果您需要不同的維度,請刪除現有的速率限制並建立新的速率限制。在建立生產速率限制之前,規劃您的維度索引鍵結構。
重要
速率限制使用故障開啟行為。如果速率限制服務暫時無法使用,則允許透過 進行流量。請勿使用速率限制做為您的唯一安全機制。結合身分驗證、授權、閘道規則和 WAF 進行深度防禦。
監控
使用下列訊號來監控速率限制有效性:
調節回應訊號:
-
從閘道監控 HTTP 429 回應。
-
剖析調節回應中的
limitKey欄位,以識別觸發的速率限制。 -
使用
retryAfter值來了解強制執行時段。
OpenTelemetry 跨度屬性:
| 屬性 | 要監控的內容 |
|---|---|
|
|
限流請求的計數。意外尖峰警示。 |
|
|
識別哪些速率限制最作用中。尋找不平衡的強制執行。 |
|
|
判斷請求、權杖或連線是否為瓶頸。 |
|
|
識別哪些呼叫者或目標最常達到限制。 |
|
|
所有已檢查儲存貯體的排序清單。有助於了解套用至特定請求的限制。 |
監控查詢範例:
在aws/spans日誌群組上使用 Amazon CloudWatch Logs Insights 來查詢閘道的 OTEL 範圍。下列範例有助於識別限流模式。
依速率限制計算限流請求數:
filter attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled" | stats count(*) as throttle_count by attributes.`aws.agentcore.gateway.throttle.customer.limit_key` | sort throttle_count desc
識別哪些呼叫者受到節制:
filter attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled" | stats count(*) as throttle_count by attributes.`aws.agentcore.gateway.throttle.customer.matched_entry` | sort throttle_count desc | limit 20
比較一段時間內允許的請求與限流請求:
filter ispresent(attributes.`aws.agentcore.gateway.throttle.customer.decision`) | stats count(*) as total, sum(attributes.`aws.agentcore.gateway.throttle.customer.decision` = "throttled") as throttled by bin(5m)
如果單一速率限制考慮大多數調節事件,請考慮設定的速率是否太嚴格,或流量模式是否指出濫用。
從速率限制範圍建立警示
您可以將速率限制 OTEL 跨度屬性轉換為 CloudWatch 指標和警示,以主動監控限流行為。這需要啟用閘道可觀測性 (請參閱啟用 AgentCore 閘道資源的可觀測性)。
步驟 1:啟用閘道範圍
確保您的閘道已啟用可觀測性。閘道範圍會匯出至 CloudWatch,並可在 CloudWatch 交易搜尋和生成式 AI 可觀測性頁面中檢視。
步驟 2:建立 CloudWatch 指標篩選條件
在aws/spans日誌群組上建立指標篩選條件,以擷取節流事件做為自訂指標。下列範例會建立 指標,以計算每個速率限制的限流請求數:
{ "filterPattern": "{ $.attributes.aws\\.agentcore\\.gateway\\.throttle\\.customer\\.decision = \"throttled\" }", "metricTransformations": [ { "metricName": "GatewayRateLimitThrottleCount", "metricNamespace": "AgentCore/Gateway/RateLimits", "metricValue": "1", "defaultValue": 0, "dimensions": { "LimitKey": "$.attributes.aws\\.agentcore\\.gateway\\.throttle\\.customer\\.limit_key" } } ] }
步驟 3:建立 CloudWatch 警示
指標篩選條件到位後,請建立警示,在調節速率超過閾值時觸發。
範例
步驟 4:建置儀表板
建立 CloudWatch 儀表板,將一段時間內的調節速率視覺化。下列小工具組態顯示依速率限制分組的調節計數:
{ "metrics": [ [ "AgentCore/Gateway/RateLimits", "GatewayRateLimitThrottleCount", "LimitKey", "per-target-rps" ], [ "AgentCore/Gateway/RateLimits", "GatewayRateLimitThrottleCount", "LimitKey", "per-caller-rpm" ] ], "period": 60, "stat": "Sum", "title": "Rate Limit Throttles by Limit" }
提示
您也可以使用內建指標 Throttles (在閘道調用指標下預設為可用) 來計算總節流計數,而無每個限制的精細程度。當您需要每個限制或每個呼叫者可見性時,請在跨屬性上使用自訂指標篩選條件。