Sondanız arızanın kendisi olduğunda: bir monitör kendi yükünü nasıl ölçer
Durum sayfamız 23 modelin çoğunu dalgalı gösterdi. Platform çalışıyordu. Sonda kendini ölçüyordu — üç kez, üç ayrı sebeple.
2026-08-31 tarihinde kendi durum sayfamız, yirmi üç modelden oluşan bir kataloğun çoğunu dalgalı olarak raporladı. Müşteriler aynı modellere istek gönderiyor ve cevap alıyordu. Sayfa yalan söylemiyordu — sondasının ölçtüğü şeyi dürüstçe raporluyordu. Sonda kendini ölçüyordu.
Bu üç ayrı kez, üç farklı sebeple oldu ve her seferinde ilk refleks bozuk bir sağlayıcı aramak oldu. Her seferinde cevap kendi kodumuzdaydı. Kontrol etmediğiniz bir API için monitör yazıyorsanız, size yalan söyleyeceği üç yol bunlar — karşılaştığımız sırayla.
- Ölçülen katalog
- 23 sohbet modeli
- Zirve sahte arıza oranı
- modellerin ~%65’i dalgalı gösterildi
- Gerçek sebep, üçünde de
- sondanın kendi istek deseni
- Ölçüm tarihi
- 2026-08-30 – 2026-08-31
Bir: tek bir modele karşı eşzamanlılık
İlk sürüm modelleri paralel ölçüyordu; taramayı kısa tutmanın akla gelen yolu bu. Altı modeli aralıklı olarak başarısız diye raporladı.
2026-08-30’de, tek seferde tek model olarak ölçüldü:
| Aynı modele eşzamanlı istek | Başarılı |
|---|---|
| 1 (tamamen seri) | 30’da 30 |
| 4 eşzamanlı | 4’te 3 |
| 8 eşzamanlı | 8’de 5 |
Sonra aynı test, dört eşzamanlı isteği dört farklı modele dağıtarak: on ikide on iki. Tavan model başınaydı, global değil. Sondamız her modele milisaniyeler arayla iki istek gönderiyordu — bir sohbet tamamlaması ve bir akış çağrısı — ve ikincilerin kabaca dörtte biri reddediliyordu.
Ders bu platformun ötesine geçer. Bir hız sınırlayıcı servisin gerçek bir parçasıdır, ama bir şeye göre kapsanır: anahtara, modele, hesaba, rotaya. Neye göre kapsandığını bilmeden çalışan paralel bir sonda, sınırlayıcıyı ölçüp ona erişilebilirlik der.
İki: sağlayıcının kendi kuyruğundan kısa bir zaman aşımı
İkinci arıza tamamen farklı görünüyordu ve aynı kategoriden bir hataydı. Bir model %25 erişilebilir olarak yayınlandı. Model her isteği yanıtlıyordu; cevaplar gelmeden sonda telefonu kapatıyordu.
Zaman aşımı 20 saniyeydi. O modelin medyan yanıt süresi 16. Kesme noktasını 45 saniyeye çıkarmak o modeli düzeltti ve anında iki başka modeli bozdu; kayıtlı örnekler sebebini gösterdi. Akışsız gecikmeleri iki kutupluydu — 2026-08-30’de max_tokens: 8 ile dört ardışık çağrı 4,0s, 11,9s, 40,3s ve 19,0s sürdü — oysa aynı istemde akışın ilk baytı her seferinde 1,4s ile 2,6s arasında kaldı.
Tamamlama, çağıranın hiç görmediği bir akıl yürütmeyi bekliyordu. max_tokens sınırlamak bunu kısaltmaz, çünkü üretilen token’lar sayılan token’lar değildir.
Bu, o modeller hakkında gerçek ve yararlı bir bilgi. Gecikme hakkında bir bilgi, ve sağlayıcının kendi kuyruğunun altındaki bir kesme onu erişilebilirlik hakkında bir kurguya çevirir. İkisi ayrı sütunlara aittir ve ikisini ayıramayan bir monitör yavaşı arıza diye yayınlamaya devam eder.
Üç: tek bir patlama hâline gelmiş tarama
Üçüncüsü, en kötü sayfayı üreten oldu. Sonda saatte bir uyanıp bütün kataloğu tarıyordu — yirmi üç model, model başına iki istek, dört yüz milisaniye arayla. Platformun tarafından bakınca bu yirmi üç küçük kontrol değildir. Tek bir anahtardan gelen, kabaca kırk altı ardışık çıkarım isteğinden oluşan kesintisiz bir akış, ardından elli yedi dakika sessizliktir.
Hiçbir gerçek istemci böyle davranmaz ve platform bu desene 503 system_cpu_overloaded ile cevap verdi. Sayfa sonucu kataloğun çoğunun dalgalı olduğu şeklinde yayınladı; oysa ara sıra istek gönderen her müşteri cevap alıyordu.
Bunu pahalı yapan şey teşhisti. Aynı isteği dört farklı giriş noktasından denedik — mağaza alan adı, doğrudan platform ve iki ayrı bölgesel host — ve 503’ü dördünde de tekrarladık. Bu kesin görünüyordu ve hiçbir şey kanıtlamıyordu, çünkü her test aynı anahtarı kullanıyordu ve sınır host adını değil anahtarı takip ediyor.
Kendi yükünüzü onların arızasından nasıl ayırırsınız
Dört kontrol, en ucuzundan başlayarak:
- Gerçek sessizlikten sonra tek istek. En bilgilendirici test, ve çalıştırmaya değmeyecek kadar basit hissettirdiği için sürekli atladığımız test.
- Çıkarım dışı yollar. Model kataloğunu isteyin veya bilerek yetkisiz bir çağrı yapıp 401’i okuyun. 2026-08-31’de bunlar 0,27–0,45 saniyede cevap verirken çıkarım yolu 503 döndürüyordu; bu, sorunu platformun web katmanı yerine model kapasitesine yerleştirdi.
- Susun ve yeniden deneyin. Kendi trafiğinizi iki dakika durdurmak hiçbir şeyi değiştirmiyorsa tetikleyici trafiğiniz değildi. Her şeyi değiştiriyorsa öyleydi.
- Normal bir çağıranın ne yaptığına bakın. Bizim taramamız kırk altı ardışık istek gönderiyordu. Bir müşteri bir tane gönderir, düşünür, bir tane daha gönderir. İki desen farklı sonuç veriyorsa, müşterilerinizin yaşadığı şeyi ölçmüyorsunuz demektir.
Arıza olmayan iki şey
Trafik biçiminin ötesinde, bir monitörün başka iki tür başarısızlığı ölçtüğü şeye atfetmeyi reddetmesi gerekir.
Kendi bakiyeniz. Sonda anahtarımızın kredisi bitti ve katalogdaki her model aynı anda kırmızıya döndü. Yanıt, kota mesajı taşıyan bir HTTP 403’tü — platform kusursuz çalışıyor ve *bize* hizmet vermeyi reddediyordu. Faturalandırmayı reddetmek cüzdanınız hakkında bir bilgidir. Artık hiç örnek yazmıyor ve sayfaya sondanın kredisi olmadığını söyleyen bir bant koyuyor; bu, yirmi üç modelin arızalı olmasından farklı bir cümle.
Başarısız olmak yerine geri çevrilen istekler. Sistemin aşırı yüklendiğini söyleyen bir 503, platformun kendini koruması demektir ve genellikle anında geçer. Bunun erişilebilirlik rakamınıza girip girmemesi tamamen sondanızın ona sebep olup olmadığına bağlıdır — ki bu bütün tartışmayı yine trafik biçimine getirir.
Sonda patlama yapmayı bıraktıktan sonra bunları tekrar saymaya başladık. Müşterinin de karşılaşacağı bir reddetme gerçek bir başarısızlıktır ve onu daha dostane bir kategorinin arkasına saklamak, aynı hatanın ters yönde tekrarı olurdu.
Örnekleri yöntemle damgalayın
Bütün bunları telafi edilebilir kılan pratik güvence, saklanan her örneğin üzerindeki tek bir tamsayı: onu üreten ölçüm yönteminin sürümü.
Bir sondayı düzelttiğinizde, bozuk sürüm altında toplanan geçmiş sadece eski değildir — farklı bir soruyu cevaplar. Altı aylık “bir istek başarılı oldu mu” verisini “yeniden deneyen bir istemci cevap aldı mı” verisiyle ortalamak, ikisi de olmayan bir sayı üretir. Bu yüzden her örnek bir sürüm taşır ve sürümü yükseltmek altındaki her şeyi atar.
Bu pahalıdır: sayfa “ölçülüyor” hâline döner ve dolması bir saat veya daha fazla sürer. İki günde üç kez ödedik ve her seferinde, kirlenmiş okumaların sayfayı boyamaya devam etmesinden ucuzdu. Ayrıca her seferinde şu soruyu sormaya zorluyor — *bu değişiklik sayının anlamını mı değiştiriyor, yoksa yalnızca ne kadar hassas ölçüldüğünü mü?* — ki bu, sorulmaya zorlanmaya değer bir soru.
Baştan başlasak neyi farklı yapardık
- Taramayı yazmadan önce hız sınırlayıcıyı bulun. Neye göre kapsandığını ölçün — anahtar, model, rota — çünkü eşzamanlılığın nerede bedava, nerede zehir olduğunu bu belirler.
- Zaman aşımını makul hissettiren süreden değil, sağlayıcının ölçülmüş kuyruğundan türetin. Ve akışın ilk baytını ayrı ölçün: iki sayı birbirinden ayrışır ve istemci zaman aşımının yarıştığı yalnızca biridir.
- Normal bir çağıran gibi görünün. Gerçek aralıklarla küçük dilimler, toplamda daha az istek gönderse bile saatlik tek taramayı yener.
- Örnekleri ilk günden sürümleyin. Sürüm damgasını sonradan eklemek, ilk yükseltmenin hiçbir yöne atfedemeyeceğiniz bir geçmişi atması demektir.
- Her durumun neyi iddia edebileceğini yazın ve özeti satırlarla aynı tabana bağlayın. Bizimki, tablonun kendi uyguladığı örnek eşiğini henüz geçmemiş modeller üzerinden ortalama erişilebilirlik yayınlıyordu.
Bunların hiçbiri egzotik değil. Ölçüm aracınızın ölçtüğü şeye katılmasına izin vermemenin sıradan disiplini — ve atlanması kolay, çünkü hata raporlayan bir monitör çalışıyormuş gibi görünür.
Devamı
- AI API relay’leri, açıklandı — isteğinizle model arasında ne var ve bir relay’in izlemeye değer hangi durumu var.
- Bir AI API relay’ini canary ile test etmek — tamamlayıcı yöntem: bir model cevap verdi mi değil, cevap veren model istediğiniz miydi.
- İstemciniz yeniden denerken erişilebilirlik ne demek — tek denemelik erişilebilirliğin neden kullanıcılarınızın neredeyse hiçbirinin yaşamadığı bir deneyimi anlattığı.
Kendi ölçümlerimiz durum sayfasında, şu anda olağan erişilebilirliğinin altında olan modeller dahil. Bu yazının amacı şu: o rakamlar ancak, kendimizi ölçmediklerini iki gün uğraşıp tespit ettiğimiz için okunmaya değer.
Bu rehberdeki rakamlar yanlarında yazan tarihlerde okundu. Fiyatlar değişir; bir iddia sağlayıcının yayınlanmış fiyatına dayanıyorsa bağlantı o sağlayıcının kendi sayfasına gider, böylece bizimkine güvenmek yerine kontrol edebilirsiniz. Bu rehber 2026-11-30 tarihine kadar gözden geçirilecek.
Sayıları kendiniz kontrol edin
Bu istasyondaki her model, token başına fiyatı ve sağlayıcının yayınlanmış liste fiyatı, okumak için hesap gerekmeden fiyat sayfasında duruyor.