跳到正文
土土金API

開始

限流說明

請求過於密集時會返回 429。本站和模型服務商都會限制請求頻率,額度隨線路和負載變化。本頁說明怎麼用退避重試、併發控制、平滑流量和多把 Key 避免與應對限流。

請求太密集時會返回 429。限流可能來自兩處:本站對帳戶和 Key 的保護性限制,以及模型服務商對每條線路的速率限制。具體額度會隨線路和負載調整,本頁不列固定數字,只講怎麼設計呼叫方式,讓業務在限流時也能平穩執行。

限流從哪裡來

來源表現
本站的保護性限制單個帳戶或 Key 在短時間內請求過多時返回 429
模型服務商的限制每條線路都有自己的速率和併發上限,超出後返回 429
高峰期繁忙模型服務負載高時可能返回 429 或 503

不同分組走不同線路,所以同一個模型換個分組,限流情況也可能不同。

遇到 429 怎麼辦

  1. 退避重試:等待一段時間再試,每次等待翻倍並加隨機抖動,最多重試幾次。響應帶 Retry-After 時按它等待。程式碼示例見錯誤碼與重試。
  2. 不要立刻無限重試。連續重試只會讓請求更密集,限流持續得更久。
  3. 重試幾次仍然失敗,就把任務放回佇列稍後處理,或者切到備用 Key。

控制併發

批次任務最容易觸發限流。給客戶端設一個併發上限,同一時刻只有固定數量的請求在跑,其餘排隊:

import asyncio
import os

from openai import AsyncOpenAI

client = AsyncOpenAI(base_url="https://www.tutujin.com/v1", api_key=os.environ["TUTUJIN_API_KEY"], max_retries=4)
limit = asyncio.Semaphore(8)  # 同时在跑的请求数,按自己的业务调整


async def summarize(text):
    async with limit:
        resp = await client.chat.completions.create(
            model="deepseek-v4.1-flash",
            messages=[{"role": "user", "content": f"用一句话总结:{text}"}],
        )
        return resp.choices[0].message.content


async def main(texts):
    return await asyncio.gather(*(summarize(t) for t in texts))

併發上限先從小值開始,觀察 429 出現的頻率再逐步調高。

讓流量更平滑

  • 批次任務勻速提交,不要一次性把幾萬條請求同時發出去。
  • 不著急的離線任務放到業務低峰時段跑。
  • 給關鍵請求和後臺任務分開排隊,後臺任務被限流時不影響使用者即時請求。

減少請求次數

  • 向量化時一次傳一組文本:/v1/embeddings 的 input 可以是字串陣列,一個請求處理多條。
  • 對相同的輸入快取結果,比如常見問題的回答、固定文件的向量。
  • 用一個請求完成能合併的步驟,比如讓模型一次輸出多個欄位的 JSON,而不是每個欄位問一次。

分散到多把 Key 和多個分組

  • 不同業務用不同的 Key,後臺批次任務的 Key 和線上業務的 Key 分開,互不搶額度。
  • 準備一把其他分組的備用 Key,主 Key 持續返回 429 或 5xx 時切換過去。分組說明見選擇分組。

需要更高的併發

如果業務長期需要更高的請求量,加客服微信 JsnonoChat,說明使用的模型、分組和預計的請求規模,我們評估後答覆。

沒找到答案?加客服微信 JsnonoChat,傳送報錯資訊裡的 request id,我們幫你排查。