Postmortem: Çalışan Bir Bütçe Uyarısı 1.900 Dolarlık LLM Faturasını Durduramadı

Olay

dev.to'da yayınlanan bir postmortem, LLM destekli iş yükleri çalıştıran herkese tanıdık gelecek bir başarısızlığı anlatıyor. Aylık bütçenin %84'ünün kullanıldığını bildiren bir e-posta salı günü geldi. Yazar e-postayı okudu, daha sonra ilgilenmek üzere işaretledi ve bir batch işini yine de gece boyunca çalıştırdı. Perşembe sabahına kadar hesap, 600 dolarlık limite karşı 1.900 dolar harcamıştı.

Gönderiye göre rahatsız edici ayrıntı şu: hiçbir şey arıza yapmadı. Uyarı zamanında geldi, doğru kişiye ulaştı, okundu ve anlaşıldı. Başarısızlık yapılsaldı: uyarı hattı harcamayı yalnızca gözlemleyebiliyordu, asla kesemiyordu. Faturanın büyük kısmı, her turda büyüyen bir context window'u durmaksızın yeniden gönderen, tavanı olmayan bir retry döngüsünden geldi.

Uyarı neden hiçbir şeyi değiştirmedi

Yazar sorunun kısmen davranışsal olduğunu savunuyor ve Journal of Personality and Social Psychology'de yayınlanan, Worchel, Lee ve Adewole imzalı 1975 tarihli bir araştırmaya atıf yapıyor. O deneyde, 200 katılımcıyla, neredeyse boş bir kavanozdan alınan özdeş kurabiyeler, dolu bir kavanozdaki aynı kurabiyelerden daha değerli ve çekici olarak derecelendirildi — ve katılımcılara stoğun, başkaları kurabiyeleri istediği için azaldığının açıkça söylenmesi etkiyi zayıflatmak yerine güçlendirdi.

Yazarın çerçevesiyle, "bütçenin %16'sı kaldı" yazan bir panel banner'ı, yanında bir açıklama taşıyan aynı türden bir tükenme ipucudur. Limitin birinin yapılandırdığı keyfi bir sayı olduğunu bilmek, banner'ı nasıl tanımladığınızı değiştirir. Ama sonrasında ne yaptığınızı değiştirmez — ki bu genellikle işi yine de çalıştırmaktır.

Yazılımda soft limit kontrolleri nasıl başarısız olur

Tipik uygulama, ay başından bugüne harcamayı okur, bütçenin %90'ının üzerinde bir uyarı log'lar, ardından API çağrısını yapar ve kullanımı sonradan kaydeder. Gönderi bu örüntüdeki üç belirli başarısızlık modunu tespit ediyor:

• Ledger, asıl önemli çağrıların gerisinde kalıyor. Kullanım yalnızca bir yanıt döndükten sonra kaydediliyor; dolayısıyla bir patlama sırasında en çok görmeniz gereken harcama henüz işlenmemiş oluyor.
• Eşzamanlılık bayan toplamları okuyor. Aynı saniye içinde harcamayı sorgulayan on iki worker'ın her biri %92 görebilir, her biri kontrolden geçebilir ve her biri ateş edebilir — hiçbirinin tek başına aşmadığı bir limiti topluca aşarlar.
• Agent döngüleri agregasyonu geçer. Bozuk bir şemaya takılan bir tool-calling agent doksan saniyede kırk çağrı yapabilir; kullanım özetleri bir dakikalık bir cron üzerinde çalışıyorsa, döngü izleme grafiği kımıldamadan biter.

Yazarın yazdığı gibi ortak payda, kontrolün gözlemleyip sonra kenara çekilmesidir. Bu, çok pahalı bir log satırından ibarettir.

Harcamadan önce ayırın

Önerilen çözüm veritabanlarından ödünç alınıyor: bir bakiyeyi yalnızca kontrol etmek yerine ona karşı fon tutmak. LLM çağrısından önce bir transaction açın, bütçe satırını FOR UPDATE ile seçin ki eşzamanlı worker'lar aynı bayan toplamı okumak yerine sıralansınlar, ve input tokens artı max_tokens üzerinden üst sınır olarak hesaplanan bir tahmini ayırın. İşlenmiş harcama artı rezervasyonlar artı tahmit limiti aşıyorsa, herhangi bir ağ isteği yapılmadan önce tipli bir exception — bir 402 — fırlatın. Başarı durumunda gerçek maliyeti commit edin ve farkı iade edin; başarısızlık durumunda hold'u serbest bırakın.

Gönderiye göre hafif fazla ayırma bir yuvarlama hatasıdır. Az ayırmaksa 600 dolarlık limitin 1.900 dolarlık bir Perşembeye dönüşme biçimidir.

Yazar mevcut araçlara da işaret ediyor: rezervasyon örüntüsünü bir LLM client etrafında decorator olarak sarmalayan ve sağlayıcıyla temasa geçilmeden önce 402 fırlatan açık kaynak bir Python kütüphanesi olan baar-core ile, onun üzerine ekipler için kurulmuş, kullanıcı başına limitler ve bir ledger görünümü ekleyen noburn.dev.

Olaydan üç kural

• Tek bir sınırda zorlayın. Client etrafında tek bir wrapper; çağrı noktalarına dağılmış, aceleye getirilen ve en yeni olanında hiç kontrol bulunmayan yapılardan iyidir.

• Gözlemleyin değil, ayırın. Bir limit, güncellemesi başka bir sürece ait olan bir sayıyı okuyorsa, bu bir limit değil, gecikmeli bir göstergedir.

• Tipli ve gürültülü biçimde başarısız olun. Makine tarafından okunabilir bir 402, retry middleware'ının ve agent döngülerinin "bütçe tükendi" ile geçici bir hatayı ayırt etmesini sağlar; böylece geri çekilip yeniden harcamak yerine dururlar.

Neden önemli

LLM harcaması klasik bulut maliyetlerinden tehlikeli bir yönüyle ayrılır: otomatik bir agent, bir insanın bu konudaki e-postaya yanıt verebileceğinden çok daha hızlı harcama üretebilir. Ekipler LLM çağrılarını arka plan işlerine ve tool-calling döngülerine bağladıkça, birinin dakikalar içinde müdahale edeceğini varsayan bir uyarı hiçbir kontrol değildir. Daha derin ders LLM'lerin ötesine genellenir — olay sonrası gözlemle dayatılan herhangi bir bütçe tavsiye niteliğindedir ve onun karakteristik başarısızlığı, hiçbirinin tek başına aşmadığı bir limiti eşzamanlı isteklerin topluca aşması, fatura gelene kadar görünmez kalır. Zorlama, token'lar faturalandırılmadan önce istek yolunda olmalıdır; yoksa zorlama değildir.