· kaynak dev.to (home feed)
%99 başarılı tek bir çağrı bile 100 çağrılık bir LLM işinin %63 olasılıkla başarısız olması demek
Bir dev.to yazısı, çok çağrılı LLM işlerinin neden olasılıksal olarak başarısız olduğunu gösteriyor: çağrı başına %99 başarı oranında 100 çağrılık bir pipeline çalıştırmaların yaklaşık %63'ünde ölüyor; checkpoint'ler ise yeniden çalıştırmaları ucuz tutuyor.

Sayfa 71'de ölen bir script
dev.to'da altrouter tarafından yazılan bir gönderi, bir model API'sine karşı script yazmış herkesin tanıyacağı bir senaryoyla açılıyor: 100 sayfalık bir PDF'i, sayfa başına bir çağrıyla özetleyen bir program 71. sayfada zaman aşımına uğruyor. Script'i yeniden çalıştırmak, halihazırda işlenmiş 70 sayfa için tekrar ödeme yapmak demek; ikinci deneme de ilkindeki kadar bir yerde ölme riski taşıyor. Yazarın argümanı, sistemde aslında bozuk bir şeyin olmadığı — sağlayıcının sadece kötü bir an geçirdiği — ve başarısızlığın, birçok çağrıyı zincirleme bağlamanın öngörülebilir bir özelliği olduğu.
Başarı oranları çarpılır
Gönderiye göre N çağrılık bir iş yalnızca her çağrı tamamlanırsa tamamlanıyor; bu da iş düzeyindeki başarı oranını p üzeri N yapıyor; burada p çağrı başına başarı oranı. Yazar, çağrı başına rakamların ölçüm değil varsayım olduğunu açıkça belirtiyor: %99 yalnızca ağ veya sunucu sorunlarından başarısız olan bir çağrıyı temsil ederken, %95 yanıtı ayrıca geçerli JSON olarak parse edilmesi gereken bir çağrıya yaklaşıyor.
İyimser oranlarda bile bileşik etki acımasız. %99'lik iki çağrı yaklaşık %98, beş çağrı hâlâ kabaca %95 oranında tamamlanıyor. Yüz çağrıda, çağrı başına %99 tüm işi %36,6'ya düşürüyor — yani iş çalıştırmaların yaklaşık %63'ünde başarısız oluyor; gönderinin manşetindeki rakam bu. Çağrı başına %95'te ise yüz çağrılık bir iş yalnızca %0,6 oranında tamamlanıyor.
Baştan başlamanın bedeli
Bahsi somutlaştırmak için gönderi bir sayfayı 1.000 input ve 250 output token olarak fiyatlıyor. Yazarın belirttiğine göre 29 Ekim 2026 tarihinde bir LLM gateway kataloğundan okınan GPT-5.6 liste fiyatlarıyla — milyon input token başına 2 dolar, milyon output token başına 12 dolar — bu sayfa başına 0,005 dolar, tüm belge için 0,50 dolar ediyor.
Her başarısızlıktan sonra birinci çağrıdan yeniden başlamak bu maliyeti ciddi şekilde katlıyor. Gönderideki hesaplı örnekte, çağrı başına %95 oranında 100 sayfalık iş ortalama yaklaşık 169 deneme gerektiriyor; her deneme kabaca 19. sayfada ölüyor ve 3.358 ücretli çağrı yapılıyor: 0,50 dolarlık bir iş için 16,79 dolar harcanıyor. Yalnızca başarısız olan çağrıyı yeniden denemek beklenen maliyeti p'ye bölünmüş N'e çeviriyor — 105 çağrı, yaklaşık 0,53 dolar — iş uzunluğundan neredeyse bağımsız. Çağrı başına %99'da karşıtlık daha yumuşak (yüz çağrıda 0,87 dolara karşı 0,51 dolar) ama aynı biçimi taşıyor.
Her yanıtı checkpoint'le, çağrıyı yeniden dene
Önerilen çözüm, çağrı başına yeniden denemeleri diskte bir checkpoint ile eşliyor. Başarısız olan tek çağrıyı artan bir beklemeyle birkaç kez yeniden dene ve tamamlanan her yanıtı, bir sonraki ücretli istekten önce depolamaya flush edilen bir JSONL dosyasına ekle. Sonraki çalıştırmada script dosyayı okur, halihazırda bitmiş sayfaları atlar ve önceki çalıştırmanın durduğu yerden devam eder; böylece bir çöküş en fazla devam eden tek çağrıya mal olur. Gönderi bunu uygulayan kısa bir Python fonksiyonu içeriyor.
Yazar, cazip bir kısayola karşı da uyarıyor: hatayı yakalayıp yoluna devam etmek. İş her zaman biter ve asla iki kez ödeme yapılmaz, ama çağrı başına %95 oranında yüz sayfadan kabaca beşi son özetten sessizce eksik kalır.
Yaklaşımın sınırları
Gönderi kendi sınırlarını da listeliyor. Model için çok uzun olan bir sayfa her denemede başarısız olur, bu yüzden iş durdurulmalı; checkpoint önceki her şeyi korur. Aritmetik başarısızlıkların bağımsız olduğunu varsayar, ama kesintiler patlamalar halinde gelir; örnek kodun üstel geri çekilme yapması ve sonunda vazgeçmesi bu yüzden. Yeniden denemeler yalnızca idempotent adımlar için güvenlidir — müşteriye e-posta da gönderen bir çağrı körü körüne tekrarlanmamalı. Ve hiçbir gateway, yazarın üzerinde çalıştığı gateway dahil (açıklanmış bir çıkar), bu checkpoint'lemeyi sizin adınıza yapamaz; çünkü bir gateway sizin işinizi değil, tek tek çağrıları görür.
Neden önemli
LLM kullanımı tek atımlık demolardan toplu pipeline'lara kaydıkça — belgeleri özetlemek, yapılandırılmış veri çıkarmak, binlerce satırı sınıflandırmak — toplu iş bilgisinin güvenilirlik alışkanlıkları gündelik script yazımının parçası haline geliyor. dev.to gönderisi bu aritmetiği görünür kılıyor: Tek başına sorun gibi görünmeyen bir çağrı başına başarı oranı ölçekte hızla çöküyor ve bir işi yeniden başlatmak ile sürdürmek arasındaki fark stilistik değil, maliyette bir büyüklük mertebesi. Çare küçük — geri çekilmeli bir retry döngüsü ve yalnızca ekleme yapılan bir sonuç dosyası — ve LLM olsun ya da olmasın, güvenilmez ağ çağrılarının herhangi bir uzun dizisine aktarılabilir.
- #llm
- #reliability
- #checkpointing
- #python
- #ai-pipelines