Rate Limits, Concurrency और Timeouts

Requests और tokens पर कोटा

Providers प्रति मिनट requests और प्रति मिनट tokens सीमित करते हैं (मॉडल और account स्तर के अनुसार input और output के लिए अलग), और कभी-कभी समवर्ती requests भी। इन्हें पार करने पर 429 मिलता है। अच्छे clients: बचा कोटा देखने को rate-limit headers पढ़ते हैं, काम queue करते हैं और concurrency सीमित रखते हैं (1,000 requests एक साथ दागने की जगह worker pool), batch jobs को समय में फैलाते हैं, और ग़ैर-ज़रूरी बड़े काम के लिए provider का batch interface उपयोग करते हैं (आम तौर पर सस्ता)। हर call पर timeouts रखें (SDKs के configurable डिफ़ॉल्ट हैं, और generation वैध रूप से समय ले सकती है, ख़ासकर लंबे outputs के लिए), और user-सामने के अनुरोध के लिए समग्र deadline भी, ताकि धीमी calls ढेर होकर आपके threads खत्म न करें।

Worker-pool पैटर्न (उदाहरण)

सीमित concurrency आपको rate limit के नीचे रखती है। यहाँ चलाया नहीं गया क्योंकि यह असली API बुलाएगा।

from concurrent.futures import ThreadPoolExecutor

def summarise(doc):
    return client.messages.create(model=MODEL, max_tokens=200, timeout=30,
                                  messages=[{"role": "user", "content": f"Summarise: {doc}"}])

with ThreadPoolExecutor(max_workers=4) as pool:      # at most 4 requests in flight
    results = list(pool.map(summarise, documents))

Rate-limit headers पढ़ें

बचे-कोटा headers आपको 429 मिलने से पहले धीमा होने देते हैं।

त्वरित जाँच: सारे requests एक साथ भेजने की जगह concurrency क्यों सीमित करें?

• Tokens मुफ़्त करने के लिए
• क्योंकि HTTP इसे मना करता है
• Rate limits के नीचे रहने और 429 errors की दीवार से बचने के लिए
• Keys से बचने के लिए