什麼是速率限制（Rate Limiting）？應用程式建構者嘅白話指南
速率限制係一條規則，限制某人喺指定時間內可以向系統提出幾多次請求，例如每分鐘最多 5 次登入嘗試，或者每小時最多 100 次 API 調用。一旦達到上限，之後嘅請求會被拒絕（通常返回錯誤碼 429 Too Many Requests），直至時間窗口重置為止。佢可以保護應用程式免受濫用、防止單一大量使用者拖慢所有人嘅速度，亦可以阻止成本失控。
你會從兩方面接觸速率限制：你調用嘅服務會限制你，而你自己嘅應用程式亦應該限制佢嘅用戶。
用 AI 建造嘢時，點解速率限制重要
用 AI 建造嘅應用程式，經常會連接到收費服務，例如 AI 模型、電郵、短訊、地圖，而每次調用都要花錢。咁樣，速率限制同時係保安功能同預算功能。
- 成本控制。 如果你嘅應用程式有一個「問 AI」嘅輸入框，但冇限制，一個機械人可以喺一晚之間送出數千次請求，每一次你都要付費。
- 保安。 如果登入表格冇限制，攻擊者可以對一個帳戶嘗試數千個密碼。設定每分鐘只準幾次嘗試，就令呢種攻擊變得唔切實際。
- 保持運作。 一個行為異常嘅腳本（有時係你自己嘅程式碼卡喺迴圈入面）就可能令資料庫超負荷，令應用程式停擺。
- 尊重其他服務嘅限制。 當你嘅應用程式太頻密咁調用外部 API，係你會收到 429 錯誤，而用戶嘅功能就會壞咗。
AI 建構器會建造你要求嘅嘢。如果你冇提及限制，佢哋通常就唔會加入。
日常生活比喻
諗一諗咖啡店嘅免費續杯政策：「每位顧客每次到店可免費續杯一次。」
- 佢並唔阻止任何人享用咖啡。
- 佢阻止咗一個人成日企喺櫃檯，為成間辦公室續杯。
- 當有人要求第四次續杯，店員會禮貌咁講「而家唔得」，呢個就係
429。
好嘅速率限制，對正常顧客嚟講係睇唔到嘅，只會被做奇怪嘢嘅人察覺。
速率限制點運作
一個速率限制器需要三樣嘢：
| 部分 | 回答咩問題 | 例子 |
|---|---|---|
| 邊個 | 計算邊個嘅請求？ | 每個用戶帳戶、每個 IP 位址、每條 API 金鑰 |
| 幾多 | 限額係幾多？ | 5、60、1,000 次請求 |
| 以咩時間計 | 喺邊個時間窗口之內？ | 每秒、每分鐘、每小時、每日 |
當請求到達，應用程式會檢查嗰個「邊個」嘅計數。未超過限額：請求通過，計數加一。超過限額：請求被拒絕。
常見嘅計數方式有以下幾種：
| 方法 | 運作方式 | 取捨 |
|---|---|---|
| 固定窗口 | 計數按鐘錶重置，例如每分鐘正點重置 | 簡單，但喺兩個窗口交接處可能容許一陣爆發式請求 |
| 滑動窗口 | 睇由而家開始計嘅過去 60 秒 | 較平滑，計算上稍為複雜 |
| 令牌桶（Token bucket） | 每位用戶有一個桶，以穩定速度注入；每次請求消耗一個令牌 | 容許短時間爆發，同時維持平均速率穩定 |
計數需要儲存喺一個快速而且可以共用嘅地方。如果只係一部細型伺服器，放喺記憶體就得。但當應用程式跑喺多部機器上，計數器通常要放喺 Redis 之類嘅共用儲存，或者資料庫入面；否則每部機器各自計數，真正嘅限額就會變成原本嘅好幾倍。
被限制嘅回應係點樣嘅
當請求超過限額，設計良好嘅 API 會回應：
- 狀態碼
429 Too Many Requests。 - 通常會有
Retry-After標頭，說明要等幾多秒。 - 有時會有標頭顯示你嘅限額，以及呢個窗口內仲剩幾多次請求（名稱視乎供應商而定）。
你嘅應用程式收到 429 時，應該等一陣再試，最好採用指數退避（exponential backoff），即每次失敗後等待嘅時間愈來愈長（1 秒、然後 2 秒、然後 4 秒），而唔係不斷狂撳服務。
實例：AI 寫作助手
假設你建造咗一個應用程式，用戶貼上文字，然後由 AI 改寫。
冇限制： 有人寫咗一個腳本，一晚之間送出 20,000 次請求。你嘅 AI 供應商帳單急升，你嘅帳戶又撞到供應商自己嘅速率限制，結果真正嘅用戶成個早上都見到錯誤。
有合理嘅限制：
- 每位已登入用戶： 免費計劃每小時 30 次改寫，付費計劃 300 次。超過限額時，用戶會見到：「你已達到呢個小時嘅上限。請 12 分鐘後再試，或者升級。」
- 註冊表格上每個 IP 位址： 每小時最多 5 次註冊，防止機械人建立數千個免費帳戶去繞過每位用戶嘅限制。
- 喺 AI 供應商嘅儀表板設定消費上限，作為所有其他方法都失效時嘅最後防線。
- 處理供應商嘅限制： 如果 AI 供應商返回 429，你嘅伺服器會等待並重試一兩次，然後顯示友善嘅「而家繁忙，請稍後再試」訊息。
限制應該喺伺服器上檢查。只存在於瀏覽器嘅限制（例如撳咗 30 次之後就停用按鈕）可以俾任何直接調用你 API 嘅人繞過。
主要名詞
| 名詞 | 意思 |
|---|---|
| 速率限制（Rate limit） | 一個時間窗口內允許嘅最大請求數。 |
| 配額（Quota） | 較大嘅額度，通常以日或者月計，有時同付費計劃掛鈎。 |
| 429 | 「請求過多」嘅 HTTP 狀態碼。 |
| Retry-After | 一個回應標頭，說明再試之前要等幾耐。 |
| 節流（Throttling） | 放慢或者拒絕超過限額嘅請求。常被當作同義詞使用。 |
| 指數退避（Exponential backoff） | 每次重試之間等待時間逐步加長。 |
| 爆發（Burst） | 短時間內大量請求同時湧入。 |
| 暴力破解攻擊（Brute-force attack） | 嘗試大量密碼或驗證碼，直至其中一個成功。 |
常見誤解
- 「速率限制只係大型應用程式先需要。」 細型應用程式同樣係目標，因為機械人會掃描整個互聯網，尋找開放嘅表格同 AI 端點。濫用嘅成本唔取決於你嘅規模。
- 「隱藏按鈕就夠。」 瀏覽器端嘅限制只係一種禮貌，唔係保護。真正嘅限制必須喺伺服器上執行。
- 「每個 IP 嘅限制一定公平。」 好多人可能共用同一個 IP 位址，例如一間辦公室、一間學校，或者同一個流動網絡。用戶登入之後，按用戶設定限制會更公平。
- 「429 即係服務壞咗。」 其實即係你調用得太頻密。檢查你嘅程式碼有冇迴圈，並且將唔常變動嘅結果快取起嚟，參閱什麼係快取。
- 「速率限制可以取代消費上限。」 兩者都要用。應用程式入面嘅限制可能有錯誤；供應商嘅消費上限就係你嘅後備保障。
要問你嘅 AI 建構器嘅嘢
- 「為登入、註冊、重設密碼同 AI 端點加入伺服器端嘅速率限制，並建議合理嘅限額。」
- 「限制每位已登入用戶每小時最多 [N] 次 AI 請求；觸發限制時，顯示清楚嘅訊息並附上需要等候嘅時間。」
- 「外部 API 返回 429 時，以指數退避最多重試 3 次，然後顯示友善嘅錯誤訊息。」
- 「速率限制嘅計數器儲存喺邊度？如果應用程式跑喺多部機器上，佢哋仲會正常運作嗎？」
- 「每當用戶或 IP 觸發限制時都記錄下來，等我可以發現濫用行為。」
- 「呢個應用程式會調用邊啲外部服務？佢哋嘅速率限制係幾多？」
Mythex 中嘅速率限制
Mythex 嘅文件對 AI 功能嘅呢點講得好直接：你建造嘅應用程式入面嘅速率限制、安全同成本控制，都由你自己設計，詳情可以睇建構 AI 應用程式。你可以喺要求功能嗰一條訊息入面，同時要求代理加入限制。喺 Pro 計劃下，流量大嗰陣，已發布嘅服務最多可以跑喺三部機器上（參閱託管限制），所以要求計數器儲存喺資料庫，而唔係某一部伺服器嘅記憶體入面。
相關閱讀：什麼係 API、點樣使用 LLM API，以及 AI 建造應用程式嘅保安清單。
常見問題
簡單嚟講，什麼係速率限制？
速率限制係一條規則，限制某個用戶、裝置或者應用程式喺指定時段內最多可以提出幾多次請求，例如每分鐘最多 5 次登入嘗試，或者每小時最多 100 次 API 調用。超過限額嘅請求會被拒絕，直至時段重置為止。
429 Too Many Requests 錯誤係咩意思？
HTTP 狀態碼 429 表示你喺太短時間內發出太多請求，觸發咗速率限制。回應通常會包括 Retry-After 標頭，說明要等幾耐。解決方法係放慢速度、等一段時間後再試，或者減少你嘅應用程式呼叫該服務嘅次數。
我嘅 AI 應用程式點解需要速率限制？
每次 AI 請求都會以 token 計算費用。如果冇限制，一個用戶或者一個機械人可以送出數千次請求，令帳單大幅上升，或者用盡你嘅供應商配額，令功能對所有人都無法使用。按用戶設定限制，可以令成本更可以預測。
速率限制同節流（throttling）係咪一樣？
兩者關係密切，經常互換使用。速率限制通常指拒絕超過限額嘅請求，而節流則可以指放慢請求速度，或者將請求排隊等候，而唔係直接拒絕。
速率限制可以阻止 DDoS 攻擊嗎？
對於小型洪水式攻擊，以及個別用戶或 IP 位址發出嘅濫用，速率限制有幫助；但大型分散式攻擊會同時來自大量位址。防禦呢類攻擊通常喺網絡或 CDN 層面進行，喺流量到達你嘅應用程式之前就攔截。