LLM API'leri ilk gerçek trafikte neden bozulur? Hız sınırı, yeniden deneme ve zaman aşımı

Bir dil modeli API'sine ilk entegrasyonunuz büyük ihtimalle tek bir satırdır: isteği gönder, cevabı yazdır. Geliştirirken kusursuz çalışır, çünkü geliştirirken dakikada birkaç istek atarsınız ve sağlayıcı o saatte sakindir.

Yayına aldığınız ilk yoğun saatte aynı satır üç farklı biçimde bozulur. Bir kısım istek 429 döner. Bir kısmı hiç dönmez ve kullanıcı dönen bir çarka bakar. Bir kısmı da sağlayıcı tarafında geçici bir hatayla düşer. Kodunuz üçünü de aynı biçimde ele alıyorsa (çoğu ilk entegrasyonda olduğu gibi "hata oldu" diye) üçünü de yanlış ele alıyordur. Bu yazı bu üç durumu birbirinden ayırmayı ve her birine doğru cevabı vermeyi anlatıyor.

429 ile 500 hatası arasındaki fark nedir?

429 "çok hızlısın, biraz bekle", 5xx ise "sorun bizde" demektir; ikisi de yeniden denenebilir ama farklı sebeplerle.

429 Too Many Requests, hesabınızın dakikalık istek ya da token sınırını aştığınızı söyler. Sorun sizin trafiğinizdedir ve beklemek onu çözer. 500, 502, 503 ya da sağlayıcıya özgü "aşırı yük" hataları, sağlayıcının o an isteği işleyemediğini söyler; bunlar da genellikle geçicidir. Asıl ayrım bu ikisi ile 400 ailesi arasındadır: 400 (geçersiz istek), 401 (geçersiz anahtar) ya da bağlam penceresini aşan bir istek yeniden denenince düzelmez. Bunları yeniden denemek yalnızca aynı hatayı daha pahalıya, daha çok gecikmeyle almaktır. İlk yazmanız gereken kod, hatayı bu iki gruba ayıran koddur.

Yeniden deneme nasıl yapılmalı?

Artan bekleme süreleriyle, rastgelelik ekleyerek ve bir üst sınırla.

Hata alır almaz hemen yeniden denemek, sağlayıcı zaten yüklüyken ona daha fazla yük bindirir. Doğrusu üstel beklemedir: ilk denemeden sonra kısa bir süre, sonrakinde iki katı, sonrakinde yine iki katı. Buna rastgele sapma (jitter) eklemek de en az bekleme kadar önemlidir. Yüz istemci aynı anda hata alıp aynı anda aynı süre bekleyip yeniden denerse, sağlayıcıya yine aynı anda çarpar. Her bekleme süresine rastgele bir pay eklemek bu dalgayı dağıtır.

Sağlayıcı cevabında Retry-After başlığı gönderiyorsa, kendi hesabınız yerine ona uyun; ne zaman yeniden deneyebileceğinizi sizden iyi bilir. Ve mutlaka bir üst sınır koyun: üç ya da dört denemeden sonra vazgeçip kullanıcıya anlamlı bir mesaj göstermek, sonsuza kadar denemekten iyidir.

Zaman aşımı ne kadar olmalı?

Kullanıcının bekleyebileceği süreye göre, modelin ne kadar sürebileceğine göre değil.

Zaman aşımı olmayan bir istek, sağlayıcı cevap vermediğinde sonsuza kadar asılı kalır ve sunucunuzun bağlantılarını tüketir. Çoğu HTTP istemcisinin varsayılan zaman aşımı ya çok uzundur ya da hiç yoktur; bunu açıkça ayarlamak gerekir. Uzun cevaplar üreten bir uç noktada iki şeyi ayırmak işe yarar: bağlantının kurulma süresi (kısa olmalı) ve cevabın tamamlanma süresi (daha uzun olabilir). Cevabı akış (streaming) olarak alıyorsanız kullanıcı ilk kelimeyi hemen görür; bu durumda izlemeniz gereken sayı toplam süre değil, ilk token'a kadar geçen süredir.

Yeniden denemek ne zaman tehlikelidir?

İsteğin bir yan etkisi olduğunda.

Düz bir metin üretme isteğini yeniden denemenin bedeli en fazla iki kez token ödemektir. Ama model bir araç çağırıyorsa (bir e-posta gönderiyor, bir sipariş oluşturuyor, bir ödeme başlatıyorsa) ilk istek aslında başarılı olup cevabı size ulaşmadan zaman aşımına düşmüş olabilir. Bu durumda yeniden denemek işlemi iki kez yapar. Çözüm, yan etkisi olan her işleme bir idempotency anahtarı vermek ve aynı anahtarla gelen ikinci isteği yeniden işlemek yerine ilk sonucu döndürmektir. Ödeme sistemlerinin yıllardır uyguladığı bu kural, araç kullanan her yapay zeka sistemi için de geçerlidir.

Sağlayıcı tamamen çöktüğünde ne olmalı?

Ürün çökmemeli; bir özellik geçici olarak devre dışı kalmalı.

Bütün sağlayıcıların kesintileri olur. Asıl soru o sırada kullanıcının ne gördüğüdür. İyi tasarlanmış bir sistemde yapay zekaya bağlı olan özellik "şu an kullanılamıyor" der ve uygulamanın geri kalanı çalışmaya devam eder. Bir adım ötesi, art arda hata aldığınızda bir süre sağlayıcıya hiç istek atmamaktır (devre kesici): böylece hem kullanıcılar her seferinde uzun bir zaman aşımı beklemez hem de toparlanmaya çalışan sağlayıcıya yük bindirmezsiniz. İkinci bir sağlayıcıya geçmek de mümkündür, ama yalnızca o sağlayıcıyla aynı soru kümesinde ölçüm yaptıysanız; aksi hâlde kalitesini bilmediğiniz bir modele sessizce geçmiş olursunuz.

Hangi bilgileri kaydetmelisiniz?

Her istekte en az şunları: hangi model, kaç girdi ve çıktı token'ı, ne kadar sürdüğü, kaçıncı denemede başarılı olduğu ve hata aldıysa hangi kodu.

Bu kayıt olmadan "neden yavaş", "neden pahalı" ve "neden bazen hata veriyor" sorularının hiçbiri cevaplanamaz. Token sayıları özellikle önemlidir: fatura onlarla hesaplanır ve bir uzun konuşmanın maliyetinin nasıl katlandığını görmenin tek yolu, istek başına token'ı zaman içinde izlemektir. Bu konuşma maliyetinin neden mesaj sayısından hızlı büyüdüğünü maliyet oyununda kendiniz deneyebilir, gerçek bir sistemin yoğun trafikte nasıl bozulduğunu arıza vakalarında adım adım izleyebilirsiniz.

Kullanıcı başına sınır neden gerekir?

Çünkü hesabınızın hız sınırı bütün kullanıcılarınızın ortak bütçesidir.

Tek bir kullanıcının (ya da bir botun) dakikada yüzlerce istek atması, hesabınızın sınırını herkes için tüketir ve diğer kullanıcılar 429 almaya başlar. Dil modeli çağıran her uç noktaya kullanıcı başına bir sınır ve bir harcama tavanı koymak, hem bu ortak bütçeyi korur hem de faturanızı başkasının eline vermenizi engeller. Bu, bir yapay zeka uygulamasının güvenlik önlemlerinin de ilk adımıdır.

Kaynaklar

• Anthropic: errors and rate limits: hangi hata kodunun ne anlama geldiği ve hangilerinin yeniden denenebileceği. (eklenme: 2026-08)
• AWS Architecture Blog: exponential backoff and jitter: rastgele sapmanın neden gerektiğini ölçümlerle gösteren klasik yazı. (eklenme: 2026-08)
• MDN: Retry-After header: sunucunun ne zaman yeniden denenebileceğini nasıl bildirdiği. (eklenme: 2026-08)
• OWASP: API Security Top 10: Unrestricted Resource Consumption: kullanıcı başına sınır olmayan bir API'nin nasıl kötüye kullanıldığı. (eklenme: 2026-08)