Gateway logları: LLM API çağrılarının %12'si yanıt dönmüyor ve retry'lar maliyeti katlıyor

Production'da bir LLM gateway işletmecisi, API trafiğinin kayda değer bir kısmının hiçbir yanıt üretmediğini gösteren telemetri verilerini yayımladı. AltRouter'ın dev.to'daki yazısına göre gateway, 28 Haziran ile 10 Eylül 2026 arasında 5.087 chat completion isteği kaydetmiş ve bunların 622'si — %12,2'si — çağıran tarafa hiçbir yanıt ulaşmadan sonlanmış. Yazarın vurguladığı nokta, bir sağlayıcının çökmüş olması değil; bu hata oranının, LLM istemcilerini ölçekli biçimde çalıştıran herkes için sıradan bir arka plan koşulu olduğu ve neredeyse hiçbir fiyatlandırma hesabında yer almadığı.

Gerçekte ne başarısız oluyor

Yazıdaki döküm beş sonucun ağırlığında. En büyüğü, tüm çağrıların %6,88'iyle HTTP 503 — o anda istenen model için sağlayıcıda kapasite bulunmaması. İkinci en büyüğü %2,40 ile HTTP 400: hatalı biçimlendirilmiş bir istek, desteklenmeyen bir parametre veya uç noktanın kabul etmediği bir rol; yani kusur çağıran tarafın kendi kodunda. İstemci tarafından kapatılan bağlantılar (499) %1,51, timeout'lar (504) %0,94 ve kredi bitmesi hataları (402) %0,28 paya sahip.

Bu ayrım önemli, çünkü çoğu kod tabanının kopyaladığı retry kalıbı — hatayı yakala, bekle, üç kez yeniden dene — iki aileyi birbirinden ayırt etmiyor. Bir 503'ün sonraki bir denemede başarılı olma gerçek bir şansı var. Bir 400 ise her seferinde aynı şekilde başarısız olur. Kaydedilen 622 başarısızlığın 137'si bu anlamda terminaldi (400, 402 ve 404 yanıtları). Yazının hesabına göre her biri üç kez yeniden denenince, bu, çıktı üretmesi hiçbir koşulda mümkün olmayan 411 isteğin gönderilmesi demek.

Sayacak nerede çalışıyor

Hata türleri arasındaki maliyet asimetrisi, verinin sezgiye aykırı kısmı. Reddedilen bir istek fiilen bedava: bir 400 modele hiç ulaşmaz, bir 503 ise üretimin hiç başlamadığı anlamına gelir; iki durumda da token ücretlendirilmez. Kaybettiğiniz şey latency'dir.

Timeout'lar ve iptaller farklı. Bir 504, modelin üretim yaptığını ama çağıranın beklemeyi bıraktığını; bir 499, kullanıcının işlemi iptal ettiğini veya istemci süre sınırının, yanıt geri akmaya başladıktan sonra devreye girdiğini gösterir. Tokenlar hangi durumda olursa olsun var. Yazıya göre bu iki kategori tüm çağrıların %2,45'ini kapsıyor ve faturalandırmanın işlediği tek başarısızlık türleri onlar.

Fatura sonra retry üzerinde katlanıyor, çünkü ikinci deneme tüm girdiyi yeniden ödüyor — sistem mesajından aşağıya kadar tam prompt'u, yalnızca kalanı değil. Yazar, gpt-5.6'nın resmi fiyatı olan milyon girdi token'ı başına 2,50 doları referans vererek, medyan 1.290 token'lık prompt'larının deneme başına kabaca üçte bir sente mal olduğunu belirtiyor. Bu tek başına önemsiz; ama 40.000 token'lık bir bağlam taşıyan ve yük altında iki kez yeniden denenen bir iş, tek bir yanıt elde etmek için o bağlamı üç kez satın almış olur. Bu nedenle yazının takip edilmesini önerdiği metrik, çağrı değil yanıt başına deneme sayısı.

Önerilen düzeltmeler

Yazı, hacimden çok sınıflandırmaya odaklanan değişiklikler öneriyor. Birincisi, yalnızca 429 ve 5xx yanıtlarında retry yapın; 4xx aralığındaki diğer her şey isteğin kendisindeki bir kusuru gösterir ve beklemek hatalı JSON'u onarmaz. İkincisi, retry bütçesini deneme sayısıyla değil token cinsinden sınırlayın — 500 token'lık bir prompt'ta üç retry ile 40.000 token'lık bir prompt'ta üç retry, kodda aynı satırlar ama harcamada seksen kat fark demektir. Yazıdaki kısa bir kod örneği her iki kuralı da uyguluyor. Üçüncü, daha ucuz öneri ise streaming'i etkinleştirmek; böylece bir timeout, aynı harcama karşılığında hiçlik yerine gösterilebilecek veya kurtarılabilecek kısmi bir yanıt bırakır.

Ölçümdeki bir boşluk

Yazar, veri setinin bir kör noktası olduğunu açıkça söylüyor. Gateway, 622 başarısız olayın tamamı için sıfır token ve sıfır ücret kaydediyor; çünkü yalnızca yukarı akış sağlayıcısının döndürdüğü usage bloğunu ölçüyor — ve üretim ortasında ölen bir istek hiçbir zaman böyle bir blok döndürmüyor. Bu nedenle başarısızlık sıklığı iyi belgelenmişken, yarıda bırakılan üretimlerin gerçek yukarı akış maliyeti bilinmiyor. Yazar, çoğu işletmecinin loglarının aynı boşluğu paylaştığından şüpheleniyor.

Neden önemli

Çoğu LLM maliyet modellemesi temiz bir varsayımla başlar: bir istek, bir yanıt, fiyatla çarp. Bu veri seti, production'da kabaca sekiz çağrıdan birinin hiçbir şey döndürmediğini, saf retry mantığının asla düzeltmeyeceği hatalara yüzlerce istek harcadığını ve en pahalı başarısızlıkların üretimin çoktan başlamış olduğu durumlar olduğunu gösteriyor. LLM harcaması için bütçe planlayan veya güvenilirlik hedefi belirleyen ekipler için pratik çıkarımlar şunlar: retry yapmadan önce hataları sınıflandırın, retry'ları deneme sayısıyla değil token harcamasıyla sınırlayın ve yanıt başına deneme sayısını ölçün — çünkü yalnızca çağrı sayılarına dayanan her maliyet modeli, her iki yönde de sessizce yanılıyor.