Hız Sınırları
Normal kullanımı ölçmek için değil, kazara oluşan istek fırtınalarını yutmak için tasarlanmış, anahtar başına sabit bir istek sınırı.
Sınır
| Kapsam | Sınır |
|---|---|
| API anahtarı başına | dakikada 60 istek |
Sınır, çalışma alanı başına değil anahtar başına uygulanır; bu yüzden aynı çalışma alanındaki iki anahtar, bir havuzu paylaşmak yerine her biri kendi dakikada 60 istek hakkını alır. Bu bir token sayısı sınırı değil, bir istek sayısı sınırıdır: çok uzun bir yanıt üreten tek bir istek, çok kısa bir yanıt üretenle aynı şekilde sayılır ve streaming olup olmaması, bir isteğin nasıl sayıldığını değiştirmez.
Bu sınır, öncelikle meşru kullanım üzerinde anlamlı bir üst sınır olarak değil, kontrolden çıkan döngülere (geri çekilme olmayan bir yeniden deneme döngüsü, her tuş vuruşunda bir istek ateşleyen bir hata) karşı bir koruma olarak vardır. Sıradan uygulama trafiği, oldukça aktif bir sohbet kullanımı bile, bunun rahatlıkla altında kalır.
Sınırı aşmak
Sınırı aşan bir istek, kuyruğa alınmadan veya geciktirilmeden, diğer her hatayla aynı hata zarfında anında bir 429 alır:
HTTP/1.1 429 Too Many Requests
{"error": {"message": "Rate limit exceeded. Please slow down and retry.", "type": "rate_limit_error"}}
Pencere kayan bir esasta sıfırlanır, bu yüzden bir 429'a doğru tepki, farklı bir anahtara geçmek veya bir şeylerin bozuk olduğunu varsaymak değil, yeniden denemeden önce kısa bir bekleme yapmaktır. Yoğun bir etkinlik patlamasının ortasında tek bir 429 normal ve beklenendir; birçok ayrı patlamada tekrar eden 429'lar, isteğin kendi deseninin aşağıda ele alınan bir geri çekilme stratejisine ihtiyacı olduğunun bir işaretidir.
Doğru şekilde geri çekilmek
Bir 429'u sıkı bir döngüde anında yeniden denemek, durumu daha iyi değil daha kötü yapar: istek oranını tam olarak sınırın üzerinde tutmaya devam eder, bu yüzden her yeniden deneme aynı şekilde başarısız olur. Denemeler arasında kısa, tercihen artan bir gecikme (birkaç yüz milisaniye, her ardışık başarısızlıkta ikiye katlanarak, makul bir üst sınıra kadar), normal bir isteğin kullanıcıya görünen gecikmesini anlamlı şekilde etkilemeden neredeyse her 429'u bir veya iki yeniden denemede çözer.
# Python: minimal retry with exponential backoff import time for attempt in range(4): try: response = client.chat.completions.create(model="tai-4.1", messages=messages) break except Exception as e: if attempt == 3: raise time.sleep(0.5 * (2 ** attempt))
Resmi OpenAI SDK'ları, tam olarak bu tür geçici hatalar için varsayılan olarak geri çekilmeli yeniden deneme davranışını zaten uygular; bunlardan birini kullanıyorsanız bu muhtemelen sizin için ekstra kod gerekmeden zaten halledilmiştir ve yalnızca kendi yeniden deneme bütçesi tükendikten sonra bir istisna görürsünüz.
Dakikada 60 gerçekten yetersizse
Çoğu uygulama için istek hacmi, doğal olarak bir insanın veya bir ajan döngüsünün fiilen ne kadar hızlı istek üretebildiğiyle sınırlıdır ve dakikada 60, nadiren gerçek bir kısıtlama olur. Meşru bir kullanım senaryosu sürekli olarak sınıra takılıyorsa, kontrol edilmeye değer ilk şey, sınırın kendisinin değişmesi gerektiğini varsaymadan önce, aynı temel görev için çok sayıda küçük istek yerine daha az, daha büyük istekler göndererek isteklerin toplu hale getirilip getirilemeyeceği veya birleştirilip birleştirilemeyeceğidir.