· kaynak dev.to (home feed)
Gerçek iş yüküyle LLM benchmark'ı: 5,8 kat pahalı amiral gemisi, orta segment bir model tarafından geçildi
Bir geliştirici, üretime hazır bir BaZi doğum haritası iş yükünde sekiz LLM'yi benchmark'tan geçirdi ve liste fiyatı 5,8 kat yüksek olan bir amiral gemisini eledi; rol yapma ince ayarlı modeller ise en çok halüsinasyon gördü.

Maliyeti ve doğruluğu karşı karşıya getiren bir benchmark
İki dilli bir BaZi hesaplayıcısı — auspiceoracle.com adlı, Çince "Dört Sütun" doğum haritası uygulaması — işleten bir geliştirici, dev.to'da yayımladığı bir benchmark'ta lansmandan önce sekiz LLM adayını uygulamanın gerçek üretim iş yüküne karşı test etti. Her yorum bir LLM çağrısı olduğundan ve ücretsiz katman bir pazarlama harcaması gibi işlediğinden, model seçimi hem bir kalite kararı hem de bir birim ekonomisi kararıydı. Ana bulgu: çağrı başına liste fiyatıyla orta segment bir modelin 5,8 katı fiyatlı amiral gemisi aday elendi; orta segment model ise çok daha düşük bir maliyetle hayatta kaldı ve geliştirici çıktılarını ayırt edemedi.
Doğru sayılan neydi
dev.to gönderisine göre genel leaderbord'lar burada işe yaramıyordu, çünkü alan hiçbir public benchmark'ın ölçmediği kısıtlar dayatıyor. Kabul kriterleri şunlardı: sıkı terminoloji doğruluğu (甲 karakterini Yin Wood yerine Yang Wood olarak yazmak derece değil kategori hatasıdır), kapalı bir kelime dağarcığına saygı (On Tanrı ve sabit yıldız adları — motorun hiç hesaplamadığı terimler uyduran bir model bir yük haline gelir) ve yorum başına maliyet.
Her aday nasıl başarısız oldu
Amiral gemisi önizleme modelinin reasoning modu kapatılamıyordu: API, enable_thinking bayrağını reddediyor ve yalnızca true değerine izin veriyordu. Tek bir stream'li istek, kullanıcının okuyabileceği ilk karakterden önce 286 reasoning olayı üretti; ilk reasoning token'ına ulaşmak 2,1 saniye, ilk görünür token'a ulaşmak 10,5 saniye sürdü. Bu reasoning token'ları, zaten daha yüksek olan liste fiyatının üzerine faturalanıyor; karşılaşında ise geliştirici farkı ayırt edemedi. Elenen.
Üç orta segment model alan doğruluğunda tamamen başarısız oldu ve İngilizce çıktıda element kutupluluklarını ters çevirdi. Karakter rol yapma ince ayarları ise tüm gruplar içinde en çok halüsinasyon gördü ve sistemde var olmayan On Tanrı ilişkileri uydurdu — persona için ayarlanan modeller, persona odaklı bir ürün için en az güvenli seçim çıktı. İyi bilinen iki open-weight model ise planlama ve test aşamaları arasında sağlayıcının uluslararası endpoint'inden sessizce kaldırılmıştı; bu da bir model bağımlılığının, sizin kontrolünüzde olmayan bir kullanım ömrü sonu tarihi taşıdığının hatırlatıcısıydı.
Hayatta kalanlar, ücretsiz katman için ucuz ve doğru bir küçük model ile ücretli kullanıcılar için orta segment bir model oldu — orta segmentin önceki neslinin daha düşük maliyetle aynı doğruluğu yakalaması ve doğal bir fallback olmasına çıkan sürprizle birlikte.
Hata yönetimi tek sorun değil, üç sorun
Benchmark sonuçları, fiyatların ve izinli modellerin tek bir dosyada yaşadığı bir routing katmanında derlendi: bir route, bir sağlayıcı, bir model ve o modelin liste fiyatıdır; her katmana sıralı bir fallback zinciri atanır. Zincir, kasıtlı olarak farklı bir modelle değil, yedek bir API anahtarıyla çalışan birincil modelle biter, çünkü hesap bakiyesinin tükenmesi aynı hesaptaki her modeli aynı anda düşürür.
İnce nokta, bir sonraki modele geçmenin ne zaman hiç yardımcı olmayacağını bilmektir. Gönderi her hatayı retry, next veya fatal olarak sınıflandırıyor: 401 ve 403 yanıtları fataldir, çünkü yeni bir model bozuk bir anahtarı düzeltmez; 5xx hataları ve ağ arızaları aynı route üzerinde yeniden denenir; modeli anan bir 400 veya 404 zinciri ileri taşır. Tek bir 429 iki farklı hata olabilir — yeniden denenmesi gereken geçici hız sınırı veya zincirin atlanmasını gerektiren kota tükenmesi — ve bunları ayırt etmek sağlayıcıya özgü bir şekilde yanıt gövdesini incelemeyi gerektirir.
Bir zincirin tamamı başarısız olduğunda uygulama, ok: false bayrağıyla işaretlenmiş yer tutucu bir metin döndürür ve bu bayrak veritabanı yazımını engeller. Gerekçe: önbelleğe alınan bir fallback çıktısı, ödeyen bir kullanıcıya her ziyarette gösterilir ve sistem asla yeniden denemezdi, çünkü önbellekte bir yorum zaten vardır.
İsteğe gerçekten hizmet edeni ölçmek
Tek bir yorum en fazla yedi paralel çağrı içerir ve her biri, düşünülen modelin değil isteğe gerçekten hizmet eden modelin karşısında hesaplanan maliyetle ve bir fell_back bayrağıyla birlikte bir usage olayı yayar. true olan bir fell_back değeri uyarı koşuludur, çünkü işçi modelin bozulduğu ve birim marjların sessizce kaydığı anlamına gelir. Çağrı başına yaklaşık 3,7k girdi ve 0,4k çıktı token'ıyla ölçülen rakamlar: ücretli modelde 0,0021 $ ve ücretsiz katman modelinde 0,0005 $; bu da iki çağrılık ücretsiz bir yorumu yaklaşık 0,001 $'a getiriyor.
Neden önemli
Uygulamanın kendisi niş ama çıkarımları her yere taşınıyor. Public leaderbord'lar bir alanın kapalı kelime dağarcığını göremez ve en yetenekli genel model, belirli bir iş yükünde hem en kötü performans göstiren hem de en pahalı olan olabilir. Maliyet kaldıraçları model yapılandırmasının içinde gizlenebilir — kapatılamayan bir reasoning modu, algılanabilir hiçbir kazanç yokken bir amiral gemisinin faturasını katladı. Operasyonel desenler, LLM'nin bütün ürün değil bir pipeline'ın bileşeni olduğu her yerde yeniden kullanılabilir: fiyatı routing verisi olarak ele alın, yeniden denemeden önce hataları sınıflandırın, fallback zincirlerini farklı bir hesapta bitirin, fallback çıktısını asla kalıcı hale getirmeyin ve gerçekten yanıt veren modeli ölçün. Bu uygulamada deterministik bir motor haritayı hesaplar ve LLM'ye yalnızca onu ifade etme izni verilir — model seçiminin tam da bu yüzden itibara değil ölçüme dayandırılabildiği nokta burasıdır.
- #llm
- #benchmarking
- #cost-optimization
- #model-routing
- #bazi
İlgili yazılar
- FineTune Studio, Qwen3-1.7B'yı yaklaşık 3,2 GB VRAM ile QLoRA üzerinden fine-tune ediyor
- Gemini 3.8 Flash değişmeyen fiyatlarla, 2027'de iki katına çıkacak tarifelerle ve erişim kısıtlı bir Cyber modeliyle geldi
- Runtime gateway'leri ve katmanlı savunmalar: ekipler yapay zeka agent'lerini üretimde nasıl yönetiyor