Geçen sonbahar — henüz danışmanlık tarafındayken — bir müşterim panik halinde aradı. Müşteri destek süreçlerine yapay zeka asistanı entegre etmişlerdi; pilot ayında her şey güllük gülistanlıktı, fatura da makuldü. Sonra sistemi bütün müşteri tabanına açtılar ve ay sonunda gelen model faturası, bütçelediklerinin tam sekiz katıydı. İlk cümleleri şuydu: "Bu iş böyle sürdürülemez, kapatacağız." Kapatmadılar. Üç haftalık bir optimizasyon çalışmasının sonunda aynı sistemi, aynı kalitede, eski faturanın çeyreğine çalıştırır hale geldiler. O süreçte yaptıklarımız bu yazının konusu — çünkü aynı hikâyeyi farklı dekorlarla defalarca izledik.
Temel gerçek şu: yapay zeka pilotu ucuzdur, ölçeklenen üretim sistemi ise fatura sürprizleriyle doludur. Pilotta günde elli istek atarsınız, kimse maliyete bakmaz. Üretimde günde elli bin istek atarsınız ve pilotta zararsız olan her savurganlık, bin katsayıyla çarpılıp önünüze gelir. LLM maliyeti yönetilebilir — ama ancak mimariyle yönetilir, pazarlıkla değil.
Sekiz katlık faturanın anatomisi
Önce mekanizmayı netleştirelim. Token, modelin okuduğu ve yazdığı her parçanın ölçü birimidir; faturanız kabaca "okunan token + yazılan token" üzerinden kesilir (ve yazılan token genellikle okunandan pahalıdır — bu detay birazdan önem kazanacak).
O müşteride faturayı şişiren kalemleri tek tek çıkardık ve tablo ders niteliğindeydi. Her istekte, dört bin kelimelik dev bir sistem prompt'u yeniden gönderiliyordu — asistanın bütün kuralları, örnek diyaloglar, ürün kataloğu özeti, hepsi her seferinde. Konuşma geçmişinin tamamı "ne olur ne olmaz" diye her istekte modele taşınıyordu; kırk mesajlık bir destek yazışmasının kırk mesajı da, kullanıcı sadece "teşekkürler" yazdığında bile. Modele veri, ham haliyle boca ediliyordu: sipariş sorgusunda ilgili üç alan yerine sipariş nesnesinin tüm JSON'u, iade politikası sorusunda ilgili madde yerine dokümanın tamamı. Ve son klasik: en basit selamlama mesajı bile, en karmaşık analiz isteğiyle aynı, en pahalı modele gidiyordu.
Dikkat ederseniz bunların hiçbiri "yapay zeka pahalı" sorunu değil. Hepsi mimari tembelliği — ve hepsi düzeltilebilir.
Bir de 2026'ya özgü bir çarpan var: agentic akışlar. Kullanıcının tek sorusu, arka planda araç çağıran, sonucu değerlendiren, gerekirse tekrar deneyen bir modelin on-yirmi zincirleme çağrısına dönüşebiliyor. Ajan mimarileri muazzam işler başarıyor, ama maliyet gözlüğüyle bakınca her ajan adımı ayrı bir fatura satırı. Zincirin uzunluğunu sınırlamak, ara sonuçları taşırken budamak ve "bu adım gerçekten modele mi sorulmalı, yoksa düz kodla mı çözülür?" sorusunu her adımda sormak, ajan çağının yeni maliyet disiplini. Deterministik işi modele yaptırmak, hesap makinesiyle çivi çakmaya benziyor — olur ama pahalı olur.
Faturayı düşüren beş kaldıraç
- Model katmanlaması (cascade): İstekleri önce sınıflandırın; deneyimimizde trafiğin %70'e yakını ucuz ve hızlı bir modelle çözülür, yalnızca gerçekten zor olanlar büyük modele yükselir. Tek başına en büyük kazanç genellikle budur — o müşteride de öyle oldu.
- Prompt önbelleği: Değişmeyen sistem talimatı ve sabit bağlam, sağlayıcıların cache mekanizmalarıyla kat kat ucuzlar. Ön koşul basit bir düzen: sabit blok önce, değişken içerik sonra. Prompt'u yeniden sıralamak gibi banal bir işin faturada yüzde onlarla ifade edilen karşılığı var.
- Bağlam diyeti: Modele veriyi değil, verinin ilgili özetini verin. RAG kurulumlarında top-3 doküman yeterliyken top-20 göndermek hem pahalıdır hem de — bu kısmı çokları atlıyor — cevap kalitesini düşürür; model alakasız bağlam içinde boğulur.
- Çıktı disiplini: Yapılandırılmış ve kısa çıktı isteyin. "Detaylı açıkla" alışkanlığı, zaten daha pahalı olan çıktı token'ını katlar. Sınıflandırma isteyip paragraf alan her sistem, para yakıyordur.
- Kendi önbelleğiniz: Aynı girdiye aynı cevabı veren işlerde (sınıflandırma, özetleme, çeviri) sonucu kendi cache'inizde tutun. Aynı soruyu modele iki kez sormak, aynı taksiye iki kez binip iki kez ödemek gibidir.
Bu beşi birbirinin alternatifi değil, katmanları. O sekiz katlık faturada dördünü birden uyguladık; kalemler tek tek küçüldü ve toplam etki çarpılarak geldi.
"Bu özellik ayda kaç lira yakıyor?" testi
Şimdi işin bence asıl kritik kısmı: ölçüm olmadan bunların hiçbiri kalıcı olmaz. İstek başına maliyeti; özellik, müşteri ve model kırılımında loglayın. Hangi ekran, hangi otomasyon, hangi müşteri segmenti ne yakıyor — bu tablo elinizde olmalı.
Basit bir test öneriyorum: "Bu özellik ayda kaç lira yakıyor?" sorusuna 10 saniyede cevap veremiyorsanız, optimizasyon değil tahmin yapıyorsunuz demektir. Ve tahminle yönetilen maliyet, büyümez sanılırken büyür. Kurduğum sistemlerde bu görünürlük katmanı, daha ilk ay içinde ortalama %50-70'lik tasarruf fırsatını kendiliğinden ortaya çıkardı; çünkü savurganlık, görünür olduğu anda savunulamaz hale geliyor. Aynı disiplini bugün platformumuzdaki asistan ve ajan akışlarında da işletiyoruz. (En sevdiğim örnek: o dönem bir müşteride gece çalışan bir toplu iş, kimsenin okumadığı bir raporu her gece en pahalı modelle yeniden üretiyordu. Aylık maliyeti, bir junior geliştiricinin maaşına yaklaşmıştı. Loglama açılana kadar kimsenin haberi yoktu.)
Görünürlüğün üstüne bir de emniyet kemeri takın: özellik bazında aylık bütçe eşikleri ve eşik aşımında otomatik uyarı. Sekiz katlık faturanın asıl acısı tutarı değil, ay sonuna kadar kimsenin fark etmemesiydi. Eşik uyarısı olsaydı aynı sorun üçüncü gün yakalanacak, hikâye bir blog yazısı değil, sıradan bir bakım notu olacaktı.
Bir de sözleşme tarafı var: model fiyatları ve cache indirimleri sağlayıcıdan sağlayıcıya ciddi farklılaşıyor, üstelik yıl içinde değişiyor. Mimarinizi tek modele kaynaklamak yerine, model katmanını soyutlayıp fiyat değişimlerinde geçiş yapabilir olmak, 2026'da başlı başına bir maliyet stratejisi.
Ucuzlaşan modeller sizi kurtarmayacak
"Modeller zaten her yıl ucuzluyor, beklesek?" itirazını sık duyuyoruz. Birim fiyat gerçekten düşüyor; ama kullanım ondan hızlı artıyor. Asistana bir yetenek eklediğinizde kullanıcılar onu daha çok kullanıyor, agentic akışlar tek soruya karşılık onlarca model çağrısı zincirliyor. Faturanın yönü, birim fiyatın değil mimarinin fonksiyonu. Savurgan mimari, ucuz modelle de savurgandır — sadece felaketin tarihi ötelenir. Buna karşılık disiplinli mimari, her fiyat indirimini doğrudan kâra çevirir; indirim geldiğinde faturası düşen de yine aynı ekipler oluyor.
Yapay zeka entegrasyonunuz büyürken faturası da kontrolden çıkıyorsa ya da daha kurarken bu tuzaklardan kaçınmak istiyorsanız, işe kullanımınızı kırılımlarıyla çıkaran ve nerede ne yakıldığını gösteren bir analizle başlayın — deneyimim o ki daha analiz aşaması, faturayı düşürmeye yetecek ilk üç aksiyonu ortaya koyuyor. Sekiz katlık sürprizi yaşamadan önlemek, yaşadıktan sonra söndürmekten her zaman ucuz. Token ekonomisi sohbetini severim; iletişim sayfası açık.