什麼是速率限制？應用程式建構者的白話指南

速率限制是一項規則，限制某人在一段固定時間內能對系統發出的請求數量，例如每分鐘 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 代表服務壞掉了。」 它表示你呼叫得太頻繁了。請檢查你的程式是否有迴圈，並快取不常變動的結果，參閱什麼是快取。
「速率限制可以取代花費上限。」 兩者都要用。應用程式中的限制可能有 bug，服務商的花費上限是你的最後防線。

可以向 AI 建構工具要求的事項

「在登入、註冊、重設密碼和 AI 端點上加入伺服器端的速率限制。請建議合理的上限。」
「限制每位登入使用者每小時最多 [N] 次 AI 請求，並在達到上限時顯示清楚的訊息，告知需要等待的時間。」
「當外部 API 回傳 429 時，以指數退避最多重試 3 次，之後再顯示友善的錯誤訊息。」
「速率限制的計數器儲存在哪裡？如果應用程式運行在多台機器上，它們還能正常運作嗎？」
「每當使用者或 IP 達到限制時就記錄下來，讓我能發現濫用行為。」
「這個應用程式呼叫了哪些外部服務？它們各自的速率限制是多少？」

Mythex 中的速率限制

Mythex 的文件對於 AI 功能說得很直接：你所建立應用程式中的速率限制、安全與成本控管，都由你自行設計，請參閱建立 AI 應用程式。請在要求 AI 功能的同一則訊息中，順便請 agent 加入限制。在 Pro 方案中，流量大時已發布的服務最多可在三台機器上運行（請參閱託管限制），因此請要求將計數器放在資料庫中，而不是單一伺服器的記憶體裡。

常見問題

簡單來說，什麼是速率限制？

速率限制是一項規則，限制使用者、裝置或應用程式在特定期間內能發出的請求數量，例如每分鐘 5 次登入嘗試，或每小時 100 次 API 呼叫。超過上限的請求會被拒絕，直到時間區間重置為止。

429 Too Many Requests 錯誤是什麼意思？

HTTP 狀態碼 429 表示你在很短的時間內發出了太多請求，觸發了速率限制。回應中通常會包含 Retry-After 標頭，說明需要等待多久。解決方法是放慢速度、暫停一段時間後再重試，或減少應用程式呼叫該服務的頻率。

為什麼我的 AI 應用程式需要速率限制？

每一次 AI 請求都要以 token 計費。如果沒有限制，一位使用者或一支機器人就可能送出上千次請求，造成龐大的帳單或耗盡你的服務商配額，讓所有人都無法使用該功能。依使用者設定的限制可以讓成本保持可預測。

速率限制和節流（throttling）是一樣的嗎？

兩者關係密切，常被混用。速率限制通常是指拒絕超過上限的請求，而節流也可能指放慢速度或排隊處理，而不是直接拒絕。

速率限制能阻擋 DDoS 攻擊嗎？

它能防範來自個別使用者或 IP 位址的小規模洪水攻擊與濫用，但大型分散式攻擊會同時來自大量位址。針對這類攻擊的防護通常發生在網路或 CDN 層，在流量抵達你的應用程式之前就先擋下。