Altyapı
LLM faturası nasıl öngörülebilir hâle gelir
Dil modeli maliyeti, işlenen metin miktarıyla doğru orantılı: girdi ve çıktı jetonları. Faturayı büyüten şey genelde istek sayısı değil, her istekte gereksiz yere taşınan bağlam ve gereğinden uzun cevaplar. Dördü birlikte uygulandığında maliyet çoğu projede yarıdan aşağı iniyor.
- Yayın
- Üreten
- Zero-Shot Team
- 2 dk okuma
Önce nereye gittiğini görün
Ölçmeden yapılan optimizasyon tahmin. İlk adım her isteğin girdi jetonu, çıktı jetonu, süre ve hangi özellikten geldiği bilgisiyle kaydedilmesi.
Bu kayıt tutulduğunda çıkan tablo hemen hemen her projede aynı: isteklerin küçük bir bölümü maliyetin büyük bölümünü üretiyor. Genelde tek bir özellik, genelde de en az kullanılanlardan biri.
Model kademelendirme
Bütün işleri aynı büyük modele yaptırmak, her yazıyı avukata yazdırmaya benziyor. Sınıflandırma, biçimlendirme, kısa özet ve veri çıkarma işleri küçük modellerde neredeyse aynı doğrulukla çıkıyor.
Uygulanabilir bir kural: önce küçük modelle dene, güven düşükse büyüğe yükselt. Yükseltme oranı ölçülüyor; oran yüksekse eşik yanlış ayarlanmış demektir.
Bu değişikliği yapmadan önce değerlendirme kümesi şart. Yoksa maliyeti düşürüp doğruluğu da düşürdüğünüzü fark etmeniz aylar sürüyor.
Prompt önbelleği
Çoğu uygulamada her isteğin başında aynı metin duruyor: sistem talimatı, biçim tarifi, örnekler, bazen bütün bir belge. Bu sabit bölüm her istekte yeniden ücretlendiriliyor.
Sağlayıcıların prompt önbelleği bu tekrarı belirgin biçimde ucuzlatıyor. Şartı şu: sabit bölüm prompt'un en başında ve gerçekten değişmeden duracak. Sistem talimatının içine kullanıcı adı ya da tarih koymak önbelleği tamamen devre dışı bırakıyor — sık yapılan ve pahalı bir hata.
Çıktı uzunluğu
Çıktı jetonu girdiden pahalı. Buna karşılık çoğu uygulama modelden serbest metin istiyor ve gelen cevabın yarısını kullanmıyor.
İki müdahale yeterli: cevabın biçimini bağlayın (yapılandırılmış çıktı ya da şema) ve üst sınır koyun. 'Kısa yaz' demek yerine alan alan ne istediğinizi söylemek hem ucuzlatıyor hem sonucu daha kullanılabilir hâle getiriyor.
Tavan ve alarm
Her özellik için istek başına bir jeton tavanı, kullanıcı başına bir günlük sınır ve toplam harcamada bir alarm eşiği bulunmalı. Bunlar performans ayarı değil, kaza önleyici.
Sonsuz döngüye giren bir ajan, kötü niyetli bir girdi ya da yanlış yapılandırılmış bir toplu iş, tavan yokken tek gecede aylık bütçeyi bitirebiliyor.
Kısaca
- Her isteği jeton, süre ve özellik kırılımıyla kaydedin; maliyet birkaç yerde yoğunlaşıyor.
- İşi küçük modelle deneyip gerektiğinde büyüğe yükseltin — ama önce değerlendirme kümesini kurun.
- Sabit talimatı prompt'un başına koyun ve içine değişken sokmayın; önbellek ancak öyle çalışıyor.
- Çıktıyı şemayla bağlayın ve uzunluğa sınır koyun; çıktı jetonu daha pahalı.
- İstek başına tavan, kullanıcı başına günlük sınır ve harcama alarmı kurun.
Sık sorulanlar
- Kendi sunucumuzda açık model çalıştırmak daha mı ucuz?
- Hacim yüksek ve sürekliyse evet, olabiliyor. Ama karşılaştırma jeton fiyatı üzerinden değil, toplam sahip olma maliyeti üzerinden yapılmalı: donanım, boşta geçen süre, ölçekleme, güncelleme ve bunları işletecek kişi. Düşük ya da dalgalı hacimde sağlayıcı API'si genelde daha ucuz kalıyor.
- Bağlam penceresi büyüdü, RAG'a gerek kalmadı mı?
- Teknik olarak sığıyor olması ekonomik olduğu anlamına gelmiyor. Her istekte yüz bin jeton taşımak, ilgili beş bin jetonu bulup taşımaktan kat kat pahalı — ve genelde daha az doğru, çünkü model ilgisiz metin arasında kayboluyor.
- Maliyeti düşürmek doğruluğu ne kadar düşürür?
- Bu sorunun cevabı ancak değerlendirme kümesiyle verilebilir. Uygulamada gördüğümüz: kademelendirme ve önbellek doğruluğu neredeyse hiç etkilemiyor; asıl risk çıktı uzunluğunu fazla kısmakta.