Önce API’nin döndürdüğü hata gövdesini ve response header’larını güvenli logda inceliyorum. Kullanıcıya anahtar veya ayrıntılı iç sistem bilgisi göstermeden hata türünü ayırmak gerekiyor.
Kontrol listem:
- API projesinde kullanılabilir kredi veya faturalandırma aktif mi?
- Seçilen model için hesap erişimi var mı?
- Dakika başına istek veya token sınırı aşılıyor mu?
- Aynı anahtar birden fazla sunucuda yoğun kullanılıyor mu?
- Queue olmadan yüzlerce paralel istek mi açılıyor?
- Başarısız istekler kontrolsüz biçimde tekrar mı deneniyor?
- Prompt ve çıktı limitleri gereğinden büyük mü?
Geçici rate limit durumlarında exponential backoff uygulanabilir. Basit mantık:
$delays = [1, 2, 4, 8];
foreach ($delays as $delay) {
$result = callOpenAI();
if ($result->status !== 429) {
break;
}
sleep($delay + random_int(0, 1));
}Bu yalnızca fikir vermek için kısa örnek. Üretimde maksimum deneme sayısı, timeout, idempotency gereksinimi ve hangi hata kodlarının tekrar edileceği açıkça belirlenmeli. Her 4xx hatasını tekrar denemek gereksiz trafik oluşturur.
Yoğun uygulamalarda istekleri queue üzerinden geçirmek, aynı kullanıcı için eşzamanlı iş sayısını sınırlamak ve sonuçları mümkün olduğunda cache’lemek ciddi fark yaratıyor. Kullanıcı butona art arda bastığında aynı işin beş kez kuyruğa girmesini de frontend ve backend tarafında engellemek lazım.
Token tüketimini azaltmak için tüm konuşma geçmişini her istekte göndermek yerine gerçekten gerekli bağlamı seçmek, uzun metinleri bölmek ve uygun model kullanmak faydalı. Kullanım ekranındaki metrikleri düzenli takip etmek, sorun çıkmadan kapasiteyi görmeyi sağlıyor.
429 hatası kullanıcı deneyimini bozmamalı. “Sistem bozuk” mesajı yerine isteğin sıraya alındığını veya kısa süre sonra tekrar denenebileceğini söylemek daha doğru.
İstekleri ölçmeden yalnızca limit yükseltmeye çalışmak maliyeti büyütebilir. Endpoint bazında istek sayısı, ortalama input-output token miktarı ve kullanıcı başına tüketim tutulursa darboğaz daha net görünür. Arka plandaki toplu işler için düşük trafikli saatleri seçmek, etkileşimli kullanıcı isteklerine kapasite bırakır. Retry sırasında kullanıcı isteğini benzersiz bir iş kimliğiyle izlemek çift işlem riskini azaltır.
Sizde 429 hatası sürekli mi geliyor, yoksa trafik yükseldiğinde mi başlıyor? Hata gövdesindeki `type` ve `code` alanlarını anahtar bilgisi olmadan paylaşabilir misiniz?
Cevaplar
0 yanıt