Sade anlatım
İstek sınırı, kalabalık bir istasyondaki turnikeler gibi çalışır: dışarıdaki kuyruk ne kadar uzun olursa olsun, peron taşmasın diye insanlar belirli bir tempoyla içeri alınır. Sağlayıcının GPU'larını bütün müşterileri paylaşır; bu yüzden her hesaba bir pay verilir: örneğin dakikada şu kadar istek ve şu kadar token. Payın içinde kaldığınızda hiçbir şey olmaz. Aştığınızda fazla istekler bir hatayla geri çevrilir ve biraz sonra yeniden gönderilmeleri gerekir.
Neden önemli
İstek sınırı, fiyat listesinde görünmeyen bir kapasite tavanıdır. Pilot aşamasında fark edilmez. Bütün şirkete açılış, ay sonu yoğunluğu ya da on bin belgeyi işleyen tek bir ajan ise ona dakikalar içinde ulaşabilir; kullanıcılar da hata ya da uzun bekleme görür. Sınırlar harcama geçmişiyle, talep üzerine ya da sözleşmeyle yükselir; bu zaman alabilir. Yayına çıkmadan önce sınırlarınızı beklenen en yoğun yükle karşılaştırın, tıpkı başka bir tedarikçinin kapasitesini kontrol eder gibi; ürünün “bekle” yanıtı aldığında ne yapacağına da karar verin.
Örnek
Bir sigorta şirketinin hesabı dakikada 1.000 isteğe ve 400.000 girdi token'ına izin veriyor. Hasar asistanı istek başına yaklaşık 5.000 token gönderdiği için token sınırı dakikada 80 istekte, istek sınırından çok önce doluyor. Bir fırtınanın ardından gelen pazartesi günü trafik dakikada 130 isteğe çıkıyor. Dakikada yaklaşık 50 istek 429 hatasıyla reddedilip kısa bir bekleme sonrasında yeniden deneniyor; sınır yükseltilene kadar eksperler gecikme yaşıyor.
Bununla en çok karıştırılan kavram
Rate Limit ve Harcama limiti arasındaki fark
İstek sınırı tempoyla ilgilidir ve saniyeler ya da dakikalar içinde kendiliğinden açılır; kısa bir bekleyişten sonra yeniden denemek doğru tepkidir. Harcama limiti, yani kota ise ayın toplamıyla ilgilidir: dolduğunda dönem yenilenene ya da biri limiti yükseltene kadar her istek başarısız olur; yeniden denemek işe yaramaz. İkisi çoğu zaman aynı hata kodunu döndürür; nasıl tepki vereceğinize karar vermeden önce hata mesajını okuyun.
Teknik katman
Sınırlar genellikle dakikadaki istek (RPM) ve dakikadaki token (TPM) olarak ifade edilir; bazen girdi ve çıktı token'ları için ayrı sınırlar ve günlük tavanlar da bulunur. Model ya da model ailesi bazında, kuruluş ya da proje düzeyinde uygulanırlar. Sağlayıcılar hesapları, ödeme geçmişiyle yükselen kullanım kademelerine yerleştirir; büyük müşteriler sınırları pazarlıkla belirler ya da ayrılmış kapasite satın alır. Birçoğu token bucket algoritmasını kullanır: pay sürekli dolar, bu yüzden ani bir yığılma dakikalık sınırı saniyeler içinde tüketebilir. Aşılan sınır HTTP 429 döndürür; çoğunlukla bir retry-after başlığı ve kalan payı gösteren başlıklar eşlik eder. Sağlayıcının kendisinin aşırı yüklendiğini ise ayrı bir hata bildirir. Standart istemci davranışı: rastgele sapma (jitter) eklenmiş üstel geri çekilme (exponential backoff), deneme sayısına üst sınır ve retry-after değerine uymak. Tasarım önlemleri: trafiği kuyruğa alıp düzleştirmek, gerçekçi bir en fazla çıktı uzunluğu belirlemek, prompt caching kullanmak (bazı sağlayıcılar önbellekten okunan token'ları sayıma katmaz), bekleyebilecek işleri kendi sınırları olan toplu işleme arayüzüne göndermek ve yükü bir gateway üzerinden modellere ya da sağlayıcılara yaymak. Gateway'ler ortak bütçeyi korumak için ekip bazında kendi sınırlarını da koyar.