---
title: "速率限制（Rate Limiting）"
slug: rate-limiting
language: zh-TW
source: https://aiterms.tw/learning/what-is-rate-limiting
updated_at: 2026-07-04
tags: [MLOps, AI應用, 模型部署, 最佳化, source:ipas]
ipas_term: true
type: deep-dive
---

# 速率限制 是什麼？

> 一種控制請求頻率的機制，防止系統過載或濫用，確保服務穩定性與資源公平分配。

## 核心概念
速率限制（Rate Limiting）是資訊系統中一項關鍵的流量管理策略，其核心目標是控制特定實體（例如用戶、IP位址、應用程式）在特定時間範圍內發出請求的頻率。這項技術的引入，旨在維護系統的穩定性、可用性和公平性。在沒有速率限制的情況下，惡意攻擊者可能會發動拒絕服務（DoS）或分散式拒絕服務（DDoS）攻擊，透過洪水般的請求耗盡伺服器資源，導致合法用戶無法存取服務。即使是無意的程式錯誤或用戶行為，也可能因過度請求而使系統不堪重負。因此，速率限制不僅是防禦性措施，也是確保服務品質（QoS）和資源有效分配的基礎。它透過設定明確的閾值，如「每分鐘最多100個請求」，來規範流量，一旦請求量超過這些閾值，系統將採取相應措施，例如拒絕額外請求、延遲處理、或暫時封鎖來源。

## 運作原理
速率限制的運作原理通常涉及計數和時間窗的概念。最常見的演算法包括：
1.  **固定窗口計數器 (Fixed Window Counter)**：這是最簡單的實現方式。系統將時間劃分為固定的窗口（例如，每分鐘），並為每個窗口維護一個計數器。當請求到達時，計數器增加。如果計數器在當前窗口內超過預設閾值，則拒絕請求。窗口結束時，計數器重置。其缺點是在窗口邊界處可能出現「雙倍請求」問題，即在一個窗口結束前和下一個窗口開始後立即發出大量請求，導致在短時間內處理的請求量超過實際限制。
2.  **滑動窗口日誌 (Sliding Window Log)**：這種方法記錄每個請求的時間戳。當新請求到達時，系統會移除所有超出當前時間窗（例如，過去一分鐘）的舊時間戳，然後計算剩餘時間戳的數量。如果數量超過閾值，則拒絕請求。這種方法更精確，但需要儲存大量時間戳，記憶體開銷較大。
3.  **滑動窗口計數器 (Sliding Window Counter)**：這是固定窗口和滑動窗口日誌的折衷方案。它將時間劃分為多個固定窗口，並為每個窗口維護一個計數器。當請求到達時，它會根據當前時間點，按比例計算前一個窗口的剩餘請求數，並加上當前窗口的請求數。這種方法在精度和記憶體效率之間取得了較好的平衡。
4.  **令牌桶 (Token Bucket)**：系統以固定速率向「桶」中添加令牌。每個請求需要消耗一個令牌。如果桶中沒有令牌，請求必須等待或被拒絕。桶的大小限制了可以突發處理的最大請求量。這種方法允許一定程度的請求突發，同時平滑平均速率。
5.  **漏桶 (Leaky Bucket)**：請求像水一樣進入桶中，並以固定速率從桶中「漏出」。如果桶滿了，新的請求將被丟棄。這種方法強制請求以恆定速率處理，即使輸入速率波動很大。
無論採用哪種演算法，速率限制通常部署在反向代理、API閘道器、負載平衡器或應用程式層。當請求被拒絕時，通常會返回HTTP 429 Too Many Requests狀態碼，並可能包含Retry-After頭部，指示客戶端何時可以再次嘗試。

## 實際應用
速率限制在現代網路服務和AI應用中無處不在：
1.  **API管理**：對於提供給第三方開發者的API，速率限制是必不可少的。它防止單一應用程式耗盡API資源，確保所有用戶都能獲得服務，並有助於實施基於使用量的計費模型。例如，Google Maps API、Twitter API等都有嚴格的速率限制。
2.  **防止惡意攻擊**：有效抵禦暴力破解密碼嘗試、爬蟲抓取、DDoS攻擊等。透過限制來自單一IP地址或用戶的請求頻率，可以顯著降低這些攻擊的成功率和影響。
3.  **資源保護**：保護後端資料庫、計算資源、記憶體等免受過度請求的壓力。當系統資源有限時，速率限制可以作為一種過載保護機制，防止系統崩潰。
4.  **公平使用策略**：確保所有用戶都能公平地使用共享資源。如果沒有速率限制，少數活躍用戶可能會佔用大部分資源，影響其他用戶的體驗。
5.  **成本控制**：在雲端環境中，許多服務是按使用量計費的。實施速率限制可以幫助控制API調用、資料庫查詢或計算資源的使用成本，避免意外的費用激增。
6.  **AI模型部署**：在部署大型語言模型（LLM）或其他AI模型作為服務時，速率限制尤為重要。推理請求可能消耗大量GPU或CPU資源。限制每個用戶或每個應用程式的請求頻率，可以確保模型服務的穩定性，防止單一用戶的請求洪水導致服務品質下降，同時也能優化硬體資源的利用率。

## 常見誤區
1.  **過於寬鬆或過於嚴格**：設定不當的速率限制閾值會帶來問題。過於寬鬆可能無法有效保護系統，而過於嚴格則可能阻礙合法用戶的正常使用，導致用戶體驗下降。閾值應基於對系統容量、預期流量和用戶行為的深入理解來設定。
2.  **僅在邊緣實施**：雖然在API閘道器或負載平衡器層實施速率限制是常見做法，但僅在這些地方實施可能不足。惡意用戶可能會繞過這些外部防禦，直接攻擊內部服務。因此，在應用程式層甚至微服務層實施更細粒度的速率限制也是必要的。
3.  **缺乏用戶通知**：當請求被速率限制時，如果沒有清晰的錯誤訊息或重試建議（例如HTTP 429狀態碼和Retry-After頭），用戶或客戶端應用程式可能會感到困惑，並可能導致不必要的重試，進一步加劇系統壓力。
4.  **未考慮分散式環境**：在分散式系統中，簡單的單一計數器無法有效工作。需要使用分散式緩存（如Redis）來同步不同服務實例之間的計數器狀態，確保速率限制在整個系統中保持一致。
5.  **未考慮突發流量**：某些速率限制演算法（如固定窗口）對突發流量的處理不佳。如果業務場景允許短時間內的突發流量，應選擇令牌桶或漏桶等演算法，或在固定窗口基礎上增加突發容量。

## 與相關技術的比較
1.  **負載平衡 (Load Balancing)**：負載平衡旨在將傳入流量分發到多個伺服器實例，以提高系統的吞吐量和可用性。它關注的是流量的「分發」，而速率限制關注的是流量的「控制」。兩者通常協同工作，負載平衡器可以在分發流量之前或之後應用速率限制。
2.  **防火牆 (Firewall)**：防火牆主要基於IP地址、埠號或協定來過濾網路流量，提供網路層的安全保護。速率限制則更側重於應用層的請求頻率控制。防火牆可以阻止惡意IP，而速率限制可以防止合法IP的濫用。
3.  **斷路器 (Circuit Breaker)**：斷路器是一種容錯模式，用於防止應用程式在呼叫失敗的遠端服務時持續重試，從而導致資源耗盡或級聯故障。它關注的是「下游服務的健康狀況」，當服務故障時，斷路器會「打開」以阻止進一步的請求。速率限制關注的是「上游請求的頻率」，即使下游服務健康，也會限制請求。兩者都是保護系統穩定性的重要機制。
4.  **流量整形 (Traffic Shaping)**：流量整形是一種網路流量管理技術，用於延遲或丟棄某些資料包，以確保網路流量符合預定義的速率。它通常在網路層或資料鏈結層操作，目標是平滑流量模式，減少網路擁塞。速率限制則更常在應用層操作，針對的是請求的邏輯頻率。

## iPAS 考試出題分析

屬於未分類考範圍。

## 常見問題

### 速率限制對AI模型部署有何具體好處？

速率限制對於AI模型部署至關重要，特別是對於那些資源密集型的大型模型。首先，它能防止單一用戶或應用程式發送過多推理請求，導致GPU或CPU資源耗盡，從而確保所有用戶都能獲得穩定的服務品質。其次，透過限制請求頻率，可以有效避免服務器過載，降低因資源不足而導致的延遲增加或服務中斷風險。此外，對於按量計費的雲端AI服務，速率限制有助於控制成本，避免因意外的請求激增而產生高額費用。它還能抵禦惡意攻擊，如透過大量請求進行的服務拒絕攻擊，保護AI模型的安全與穩定運行。

### 如何選擇適合的速率限制演算法？

選擇速率限制演算法需根據具體應用場景的需求。如果需要簡單且對精度要求不高的場景，固定窗口計數器可能足夠，但需注意窗口邊界問題。若對精度要求高且能接受較高的記憶體開銷，滑動窗口日誌是個好選擇。滑動窗口計數器則在精度和效率間取得平衡。如果應用需要處理一定程度的突發流量，同時又希望平滑平均速率，令牌桶演算法會是理想選擇，它允許在短時間內處理更多請求。而漏桶演算法則能強制請求以恆定速率處理，適用於需要嚴格控制輸出速率的場景。綜合考量系統資源、流量模式和業務需求，才能做出最佳決策。

### 實施速率限制時有哪些常見的挑戰？

實施速率限制面臨多重挑戰。首先是閾值的設定，過高或過低都會影響用戶體驗和系統保護效果，需要精確評估系統容量與業務需求。其次，在分散式系統中，如何確保所有服務實例的計數器同步且一致，是一個複雜的問題，通常需要依賴分散式緩存（如Redis）。此外，如何處理被限制的請求也是一個考量，是直接拒絕、延遲處理還是返回特定錯誤碼，這會影響客戶端的行為。最後，速率限制的監控和調整也至關重要，需要實時監控流量模式和系統性能，並根據實際情況動態調整策略，以應對不斷變化的負載和威脅。

---

深度解說頁：https://aiterms.tw/learning/what-is-rate-limiting
快查頁：https://aiterms.tw/terms/rate-limiting
最後更新：2026/07/04