速率限制是一種關(guān)鍵的控制機制，用于管理 API 的請求流，非常類似于調(diào)節(jié)器。速率限制不僅僅是控制請求的總數(shù)，它還關(guān)系到如何以及在哪里應(yīng)用這些限制。根據(jù) API 的需要，可以根據(jù)各種因素(如用戶 ID、 IP 地址或特定類型的 API 調(diào)用)來實現(xiàn)速率限制。

例如，一個社交平臺可能實施嚴(yán)格的速率限制，以防止發(fā)布垃圾郵件，同時允許更頻繁的請求閱讀內(nèi)容。類似地，服務(wù)可以對來自已知用戶和匿名流量的請求應(yīng)用不同的限制，使用用戶 ID 或 IP 地址來區(qū)分。這種靈活性使得速率限制成為一種通用的工具，不僅可以防止過載，而且可以創(chuàng)造一種公平和平衡的用戶體驗。

1. API限速的主要作用

API 速率限制能夠防止DoS攻擊，確保API對合法用戶開放；同時，它還能公平分配資源，降低運營成本，并有效管理第三方API的計費和配額，避免意外費用。

• 防止拒絕服務(wù)(DoS)攻擊: 正如商場可能會限制進入以防止過度擁擠一樣，速率限制可以防止惡意用戶用過多的請求淹沒 API，從而導(dǎo)致拒絕服務(wù)攻擊。這使得 API 對合法用戶可用。
• 資源公平分配: 它確保 API 的資源在所有用戶之間均勻分配。如果沒有速率限制，少數(shù)重度用戶可能會消耗超過其合理份額的資源，從而降低其他用戶的服務(wù)質(zhì)量。
• 管理運營成本: 特別是在基于云的環(huán)境中，處理大量 API 請求的成本可能很高。利率限制有助于控制這些成本，防止過度使用。
• 第三方 API 計費: 當(dāng) API 作為第三方服務(wù)的一部分使用時，速率限制對于管理計費和使用配額是至關(guān)重要的。它確保用戶保持在分配的使用限制內(nèi)，避免意外的費用。

那么， 我們常用的API 限速方法有哪些呢？

2. 令牌桶（Token Bucket）

令牌桶是一種用于管理網(wǎng)絡(luò)流量的方法，其中的令牌按規(guī)則的間隔添加。對 API 的每個請求都需要一個令牌。如果 bucket 沒有令牌，請求將被拒絕，從而確保 API 不會過載。

圖片

每個令牌表示發(fā)送一定數(shù)量數(shù)據(jù)的權(quán)限(如 API 請求)。當(dāng)請求到達(dá)時，只有當(dāng)令牌可用時才能處理該請求，然后將令牌從 bucket 中刪除。如果 bucket 為空，則請求必須等待，直到添加新標(biāo)記。例如， bucket 每秒添加5個令牌，并且每個令牌允許一個 API 請求，則最多可以處理每秒5個請求。如果請求的活躍度較低，令牌會累積，只要有足夠的令牌，每秒可以處理5個以上的請求，這就允許偶爾的爆發(fā)。

通過令牌桶，我們可以控制用戶在給定時間段內(nèi)可以發(fā)出的請求數(shù)，從而防止服務(wù)器過載。并且，可以幫助在用戶或應(yīng)用程序之間分配可用帶寬，確保公平使用和防止擁塞。

令牌桶的局限性如下：

• 高速網(wǎng)絡(luò)中的復(fù)雜性: 在極高速或復(fù)雜的網(wǎng)絡(luò)環(huán)境中，維護令牌存儲桶的開銷可能很大。
• 不對流量進行優(yōu)先排序: 它平等對待所有請求，在某些請求應(yīng)該具有優(yōu)先級的系統(tǒng)中，這可能并不理想。
• 突發(fā)處理不夠靈活: 設(shè)置正確的令牌速率和桶大小需要理解典型的流量模式，這可能并不簡單。

3. 漏桶（leak bucket）

漏桶也是一種用于網(wǎng)絡(luò)流量管理和 API 速率限制的方法，重點是保持一致的輸出速率。我們可以將 Bucket 想象為以穩(wěn)定的速度不斷泄漏請求。如果請求(水)來得太快，而桶被填滿，多余的請求就會溢出并丟失，類似于被拒絕或排隊。

圖片

對比而言，只要令牌桶中有令牌，它就允許流量進入，令牌隨時間積累，允許靈活處理突然增加的流量。而漏桶更加嚴(yán)格，它以恒定的速率泄漏請求。桶有多滿并不重要，目標(biāo)是輸出速率保持不變。這可能導(dǎo)致在低流量期間利用率不足，卻又無法容納突發(fā)的流量。例如，使用漏桶的 API 可能以每秒5個的固定速率處理請求，而不管有多少請求處于等待之中。相反，對于 令牌桶，如果有足夠的令牌，它可以在一秒鐘內(nèi)處理突發(fā)的20個請求，然后在令牌用完時返回較慢的速率。

漏桶對于需要一致數(shù)據(jù)流的網(wǎng)絡(luò)非常有用，可以用于網(wǎng)絡(luò)流量整形。雖然沒有令牌桶靈活，但是它適用于流量穩(wěn)定的 API。同時，避免了突發(fā)的流量高峰，有助于防止擁塞。

漏桶的局限性：

• 無突發(fā)處理: 不像令牌桶，它不能有效地處理突然的流量峰值。
• 潛在的利用率不足: 在低流量時可能導(dǎo)致容量冗余。
• 一致但不靈活: 雖然它確保了一個穩(wěn)定的速率，但它缺乏對不斷變化的流量的適應(yīng)性，而這對于某些應(yīng)用程序可能是必要的。

4. 固定窗口計數(shù)器

固定窗口計數(shù)器是一種用于管理 API 請求和網(wǎng)絡(luò)流量的速率限制策略，基于對在指定時間窗口內(nèi)可以發(fā)出的請求數(shù)量設(shè)置固定的限制。在這種方法中，將時間劃分為固定的間隔或窗口，并為每個窗口設(shè)置允許的最大請求數(shù)。一旦達(dá)到該窗口內(nèi)的限制，在下一個窗口啟動之前不會再接受任何請求。

圖片

令牌桶和漏桶允許在處理請求速率方面有一定的靈活性，而固定窗口計數(shù)器是更嚴(yán)格的意義上限制。如果請求快速地達(dá)到了限制，則在下一個窗口之前不會處理更多請求，而不管實際的容量或需求如何。考慮一個速率限制為每小時100個請求的 API。在固定窗口計數(shù)器下，如果在最初30分鐘內(nèi)收到100個請求，則不論服務(wù)器的實際容量或需求如何，在該小時的剩余30分鐘內(nèi)將不會處理進一步的請求。

在電子商務(wù)中，通過固定窗口計數(shù)器，我們可以限制用戶可以在設(shè)定的時間框架內(nèi)發(fā)起的交易數(shù)量來確保交易過程的安全性，從而增強防范欺詐的安全性。在云服務(wù)中，通過對啟動或停止虛擬機等操作的 API 調(diào)用設(shè)置限制來控制資源使用，從而確保公平的資源分配。我們還可以管理從物聯(lián)網(wǎng)設(shè)備到服務(wù)器的數(shù)據(jù)傳輸，這對于防止服務(wù)器過載和促進間隔數(shù)據(jù)分析至關(guān)重要。

固定窗口計數(shù)器的局限性：

• 流量突發(fā)的不靈活性: 與令牌桶不同，它不能適應(yīng)窗口內(nèi)流量的突然激增。
• 低效的可能性: 可能導(dǎo)致使用不足的周期，特別是如果在窗口的早期就達(dá)到了極限。
• “窗口重置”問題: 用戶可能會在新窗口開始時遇到突然涌入的允許請求，這可能會造成不均衡的服務(wù)器負(fù)載。
• 窗口邊緣突發(fā)問題: 一個重大缺陷是易受窗口邊緣流量突發(fā)的影響。考慮這樣一個場景: 在窗口重置之前有大量請求進入，并且在重置之后立即發(fā)生類似的激增。這可能導(dǎo)致在短時間內(nèi)處理的請求超過預(yù)期的配額，從而可能使系統(tǒng)不堪重負(fù)。這種“窗口邊緣”的突發(fā)可以在服務(wù)器負(fù)載中產(chǎn)生峰值，并降低速率限制策略的有效性。

5. 滑動窗口日志

滑動窗口日志是一種復(fù)雜的 API 速率限制和網(wǎng)絡(luò)流量管理方法。與固定窗口不同，此方法考慮每個單獨請求的時間，提供了更動態(tài)的方法。它保存了每個傳入請求的時間戳的日志。然后根據(jù)當(dāng)前滑動窗口(一個連續(xù)移動的時間框架)中的請求數(shù)確定速率限制。如果此窗口中的請求數(shù)超過閾值，新請求將被拒絕或排隊。

圖片

固定窗口計數(shù)器對靜態(tài)時間窗口施加嚴(yán)格的限制，導(dǎo)致每個窗口邊緣的潛在爆發(fā)。滑動窗口日志提供了一個更動態(tài)的方法，隨著時間的推移不斷調(diào)整。這可以防止在固定窗口的重置點常見的突發(fā)流量。例如，一個 API 每分鐘限制100個請求。在滑動窗口日志中，此限制在過去一分鐘內(nèi)不斷進行評估。如果有請求進入，滑動窗口日志會在最后60秒內(nèi)檢查所有請求。如果該數(shù)字小于100，則允許請求; 否則，將拒絕請求。

滑動窗口日志的局限性：

• 資源密集型約束: 維護所有請求的日志可能需要計算，特別是對于大量請求。
• 復(fù)雜實現(xiàn): 與固定窗口計數(shù)器相比，其動態(tài)特性使實現(xiàn)更加復(fù)雜。
• 潛在延遲: 在流量極大的情況下，滑動窗口的連續(xù)計算會引入延遲。

6. 滑動窗口計數(shù)器

滑動窗口計數(shù)器結(jié)合了固定窗口計數(shù)器和滑動窗口日志方法的元素，旨在以更平衡的方式管理網(wǎng)絡(luò)流量和 API 請求。它跟蹤滾動時間框架內(nèi)的請求數(shù)，這與固定時間間隔不同。它計算當(dāng)前窗口中的請求，同時也考慮來自前一窗口的部分請求，從而在時間間隔之間提供更平滑的轉(zhuǎn)換。

圖片

滑動窗口日志維護了單個請求時間戳的日志，而該請求可能是資源密集型的。滑動窗口計數(shù)器通過對滾動窗口中的請求進行計數(shù)，減少了與記錄每個請求的時間戳相比的計算開銷，從而簡化了這一過程。滑動窗口計數(shù)器對于經(jīng)歷穩(wěn)定流量偶爾突發(fā)的 API 是理想的，因為它可以防止在管理峰值負(fù)載時突然拒絕。在請求速率可變的 CDN 中也非常有用，可確保有效的內(nèi)容分發(fā)而不會使網(wǎng)絡(luò)超載。

滑動窗口計數(shù)器的局限性：

• 稍微比固定窗口復(fù)雜: 雖然不像日志方法那樣耗費大量資源，但是它比基本的固定窗口計數(shù)器更復(fù)雜。
• 高估的可能性: 在某些場景中，由于窗口重疊，可能允許的請求比預(yù)期的要多一些。

7 大模型應(yīng)用中的限速特點和應(yīng)對

如果在大模型應(yīng)用中收到HTTP狀態(tài)碼429錯誤，說明我們受到了大模型API的限速約束。例如，Azure OpenAI 對“每分鐘令牌”(TPM)和“每分鐘請求”(RPM)施加了限制。理解和管理這些限制對于保持平穩(wěn)運行和避免中斷非常重要。

7.1 與大模型限速相關(guān)的基本概念

了解限速的原因，需要回顧一些大模型應(yīng)用中的基本概念（以Azure OpenAI 為例）。

• 令牌（token）: OpenAI 模型處理的文本單元，用于測量輸入和輸出文本，影響使用和計。英語中的1個token≈4個字符。不同的 OpenAI 模型有不同的令牌輸入限制，如 GPT-3.5 Turbo、 GPT-4等。
• 配額（quota）: 這些是 OpenAI API 用戶在特定時間范圍內(nèi)可以使用的請求、令牌或計算資源的最大數(shù)量。
• TPM (每分鐘的token數(shù)量) : 基于請求在接收時被請求處理的token計數(shù)的速率限制。這對于速率限制是至關(guān)重要的，但是不同于計費所使用的計數(shù)，計數(shù)是在處理后計算出來的。
• RPM (每分鐘的請求數(shù)) : RPM 依賴于 TPM，每1000 TPM 的轉(zhuǎn)換為6 RPM。
• 計費模型：有兩種——在PAYG (Pay-As-You-Go)這種模式下，用戶是根據(jù)實際使用情況收費的，它具有靈活性，并且對于不同的工作負(fù)載具有成本效益；PTU (規(guī)定吞吐量單元) :這種預(yù)付費模式為用戶分配一定級別的容量，非常適合可預(yù)測的大容量使用。

如果大模型應(yīng)用需要大的令牌或高完成令牌，即使不能滿足 RPM，服務(wù)器也會節(jié)流。如果工作負(fù)載需要短時間的完成或提示，但是需要大量的 API 請求，那么服務(wù)將會節(jié)流。TPM 評估因素如下：

• 提示文本: 提示中發(fā)送的令牌已知數(shù)量。
• Max_Tokens: 令牌數(shù)量的約束，較高的值可能導(dǎo)致錯誤代碼429。
• Best_of: 需要從 LLM 得到的答案數(shù)量。

7.2 限速的預(yù)期計算

假設(shè)TPM 配額為 每分鐘100,000個token，RPM 配額為每分鐘600個請求(基于每1000 TPM約為 6 RPM 的轉(zhuǎn)換度量)，那么

（1）對于大量使用token的場景：

應(yīng)用程序處理大型文檔，每個請求需要大量token。如果每個請求使用大約1,000個token，使用假設(shè)中TPM 配額，則最多可以每分鐘發(fā)出100個請求(100,000個token/每個請求1,000個token)。如果應(yīng)用程序試圖在前10秒內(nèi)處理所有100個請求，服務(wù)器將限制請求，從而導(dǎo)致 HTTP 429錯誤。這是因為速率限制是在較短的時間(1或10秒)內(nèi)計算的，以確保均勻分布。

(2) 對于大量請求的場景：

應(yīng)用程序處理簡短的提示，每個請求所需的token較少，每個請求使用大約100個token。如果 TPM 配額為100,000，那么每分鐘最多可以發(fā)出1,000個請求(每個請求100,000個令牌)。盡管請求的數(shù)量很多，但 RPM 配額將限制為每分鐘600個請求[每1000 TPM 為6 RPM ]。如果應(yīng)用程序超過了這個限制，即使令牌的總使用量在 TPM 配額之內(nèi)，服務(wù)器也會限制請求。

7.3 限速的應(yīng)對

面向大模型API 的限速，一般的應(yīng)對方法如下：

• 設(shè)置“ max_tokens”和“ best_of”參數(shù)為較小值。如果預(yù)期響應(yīng)較小，則避免使用較大的 max _ tokens 值。
• 配額管理: 針對高流量部署增加 TPM，針對有限的需求減少 TPM。
• 實現(xiàn)重試邏輯: 確保 LLM 應(yīng)用程序能夠處理重試。
• 流量逐漸增加: 避免工作量的劇烈變化，逐漸增加。

而且，我們可以使用類似 LangChain 的 SDK 在客戶端級別實現(xiàn)負(fù)載平衡。這種方法將 API 請求分布在多個客戶機上，減少了達(dá)到速率限制的可能性。另外，使用 Azure API 管理(APIM)創(chuàng)建自定義策略，以更有效地管理和分配負(fù)載。您可以在這里了解如何使用 APIM 實現(xiàn)負(fù)載均衡。

8. 小結(jié)

在快節(jié)奏的 API 世界中，速率限制就像節(jié)奏設(shè)定器一樣，確保一切順利而有效地運行。關(guān)鍵在于選擇正確的方法，無論是固定窗口的一致性、滑動窗口日子的精度，還是滑動計數(shù)器的平衡，簡單而有效，正確的速率限制策略是一個順利的數(shù)字體驗的關(guān)鍵，保持服務(wù)快速可靠，并為未來做好準(zhǔn)備。同樣， 我們在大模型應(yīng)用中要完善對API限速的應(yīng)對。