Bir AI uygulamasını yayına almak: maliyet tavanı, önbellek, izleme ve model değişikliği

Bir uygulamanın ilk ayında her şey yolunda görünüyor: sunucu ayakta, hata oranı düşük, sayfalar hızlı. Ayın sonunda gelen model faturası ise beklenenin birkaç katı. Kayıtlara bakınca sebep çıkıyor: kullanıcıların küçük bir kısmı çok uzun konuşmalar yapmış, bir tanesi de uygulamayı bir betikle sürekli çağırmış. Sunucu izleme panelinde bunların hiçbiri görünmüyordu, çünkü sunucu açısından her şey yolundaydı.

Bir AI uygulamasını yayına almak, sıradan bir web uygulamasını yayına almanın bütün işlerini içerir. Üstüne bir tane ekler: her isteğin maliyeti değişkendir ve kontrol edilmezse büyür.

Bir AI uygulamasını yayına almak neden farklıdır?

Çünkü her istek, uzunluğuna ve içeriğine göre farklı bir para tutar ve bu maliyet kullanıcının davranışıyla doğrudan büyür.

Sıradan bir uygulamada bir sayfanın sunulması aşağı yukarı sabit bir maliyettir. Bir dil modeli çağrısında ise maliyet gönderilen ve üretilen token sayısına bağlıdır. Uzun bir konuşma, büyük bir belge ya da bir görsel, tek bir isteğin maliyetini kat kat artırabilir. Bu yüzden altyapı izlemesi tek başına yetmez; isteklerin token ve maliyet dağılımını da izlemek gerekir. Bir konuşmanın maliyetinin neden mesaj sayısından hızlı büyüdüğünü maliyet oyununda deneyebilirsiniz.

Maliyet tavanı nasıl kurulur?

Kullanıcı başına bir harcama sınırı, hesap düzeyinde bir bütçe uyarısı ve tek bir isteğin büyüklüğüne bir üst sınır koyarak.

Üç katman birlikte çalışır. Kullanıcı başına sınır, tek bir kullanıcının ya da bir botun bütçenin tamamını harcamasını önler. Sağlayıcının panelinde ya da kendi kayıtlarınızda kurulan bir bütçe uyarısı, toplam harcama beklenmedik biçimde arttığında sizi ay sonundan önce haberdar eder. Tek istek sınırı (girdinin uzunluğu, konuşma geçmişinin kaç tur tutulacağı, cevabın en fazla kaç token olabileceği) ise tek bir isteğin beklenmedik biçimde pahalı olmasını engeller. Kolay istekleri daha küçük ve ucuz bir modele, zor olanları büyük modele yönlendirmek de maliyeti düşürmenin en etkili yollarından biridir; ama yalnızca küçük modelin o istekler için yeterli olduğunu ölçtüyseniz.

Önbellek ne zaman işe yarar?

İki farklı yerde: sabit prompt'un sağlayıcı tarafında önbelleğe alınmasında ve aynı soruların cevaplarının sizin tarafınızda saklanmasında.

Sağlayıcıların çoğu, her istekte aynı olan prompt başlangıcını önbelleğe alıp daha ucuza ve daha hızlı işleyebilir. Bunun işe yaraması için sistem talimatları ve örnekler gibi sabit kısımlar başta, değişen kısımlar sonda olmalıdır. İkinci tür önbellek, birebir aynı soruların cevabını saklamaktır; sıkça sorulan sorularda maliyeti ve gecikmeyi büyük ölçüde düşürür. Ama burada ciddi bir tuzak vardır: önbellek anahtarı kullanıcıyı ya da müşteriyi ayırmıyorsa, bir müşterinin sorusuna verilen ve onun verilerini içeren bir cevap, başka bir müşteriye gösterilebilir. Bu, tek kullanıcıyla yapılan hiçbir testte görünmeyen bir veri sızıntısıdır.

Ne izlenmelidir?

Hata türleri, ilk token'a kadar geçen süre, kullanıcı başına token ve maliyet ve cevap kalitesine dair sinyaller.

Hataları türüne göre ayırın: hız sınırı, sağlayıcı hatası, zaman aşımı ve geçersiz biçimde gelen cevap ayrı sayılar olarak izlenmelidir, çünkü her birinin çözümü farklıdır. Gecikmede toplam süre kadar ilk token'a kadar geçen süreye de bakın; kullanıcının gerçekten hissettiği gecikme odur. Maliyeti kullanıcı ve özellik bazında izleyin; böylece harcamanın nereden geldiğini görürsünüz. Kalite için de en azından olumsuz kullanıcı geri bildirimlerini ve modelin "bilmiyorum" dediği oranı takip edin. Uyarıları ise yalnızca birinin bir şey yapması gereken durumlar için kurun; her şeye uyarı kurmak, hiçbirine bakılmamasıyla sonuçlanır.

Sırlar ve ayarlar nerede durmalıdır?

Koddan ayrı, ortam değişkenlerinde ya da bir sır yönetim sisteminde; her ortam için ayrı değerlerle.

API anahtarları, veritabanı adresleri ve model adları koda yazılmamalıdır. Geliştirme, test ve yayın ortamlarının her biri kendi değerlerini kullanmalıdır; böylece test ortamındaki bir deneme yayındaki bütçeyi harcamaz ve yayındaki anahtar bir geliştiricinin bilgisayarında durmaz. Model adını bir ayar olarak tutmak, ileride modeli değiştirmeyi de kod değişikliği gerektirmeyen bir işleme çevirir.

Sağlayıcı bir modeli emekliye ayırdığında ne olur?

Belirli bir tarihten sonra o modele yapılan istekler çalışmaz; hazırlıksızsanız ürün durur.

Barındırılan modeller belirli aralıklarla yenilenir ve eskileri kullanımdan kaldırılır. Kurduğunuz her şey, seçtiğiniz modelin iki yıl sonra bulunmayacağını varsaymalıdır. Bunun için iki şey gerekir: model adının kodda değil ayarda durması ve değerlendirme kümenizin hazır olması. Yeni bir modele geçmeden önce aynı test kümesini yeni modelle çalıştırıp sonuçları karşılaştırmak, geçişi bir tahminden bir ölçüme çevirir. Bu kümeyi nasıl kuracağınızı değerlendirme yazımızda, uç noktayı kötüye kullanıma karşı nasıl koruyacağınızı da güvenlik yazımızda anlattık.

Kaynaklar

• Anthropic: Prompt caching: sabit prompt başlangıcının önbelleğe alınması ve maliyete etkisi. (eklenme: 2026-10)
• MDN: HTTP caching: önbelleğin genel ilkeleri ve anahtarların nasıl kurulduğu. (eklenme: 2026-10)
• Google SRE Book: monitoring distributed systems: neyin izleneceği ve uyarıların neden az ve anlamlı olması gerektiği. (eklenme: 2026-10)
• The Twelve-Factor App: config: ayarların ve sırların koddan ayrı tutulması. (eklenme: 2026-10)