LLM Çıkarım Maliyetini Düşürmek: Caching, Batching, Routing ve KV-Cache (2026)

TL;DR — LLM'lerde asıl fatura eğitimde değil, çıkarımda (inference) birikiyor. Token başına fiyatlar düşse de çağrı hacmi daha hızlı büyüyor; özellikle bir görevi 50-200 model çağrısına bölen agent'lı akışlarda "ucuz token" bir anda "pahalı görev"e dönüşüyor. İyi haber: maliyetin büyük kısmı ölçülebilir ve geri kazanılabilir. Prompt/yanıt önbelleği ve semantik önbellek (Redis LangCache yüksek tekrarlı yüklerde ~%73'e varan tasarruf gösterdi, isabetler saniyeler yerine milisaniyelerle geliyor), akıllı model yönlendirme, batching ve KV-cache teknikleri; üzerine de gözlemlenebilirlik (observability) ile maliyet atıfı. Token optimizasyonu tipik olarak API maliyetinin %30-50'sini kurtarır ve çoğu zaman tüm araç bütçenizi karşılar. Bu yazıda sahadan gözlemlerimle, ölçmeden başlamayın diyorum: her rota için önbellek isabet oranı metriği olmadan yaptığınız iyileştirmenin gerçek olup olmadığını bilemezsiniz.

Danışmanlık yaptığım ekiplerle ilk oturumlarda hep aynı sahne yaşanıyor. Bir PoC (kavram kanıtı) harika çalışıyor, demo herkesi büyülüyor, yönetim "hadi ölçekleyelim" diyor. Üç ay sonra aynı ekip bu sefer başka bir yüzle karşımda: "Fatura neden bu kadar yüksek?" Cevap çoğu zaman şaşırtıcı derecede basit ama görmesi zor. Çünkü LLM projelerinde alışık olduğumuz maliyet mantığı tersine dönüyor.

Klasik makine öğrenmesinde büyük para eğitimde harcanır; modeli bir kez eğitirsiniz, sonra ucuza tahmin üretirsiniz. LLMOps dünyasında ise denklem değişiyor. Hazır bir API'yi (OpenAI, Anthropic, Google, ya da yerli sağlayıcılar) kullandığınızda eğitim maliyeti sizin cebinizden çıkmıyor. Bunun yerine her çağrı, işlediği token kadar sayaç döndürüyor. Yani maliyet sürekli akan bir musluk gibi. Ve bu musluğun akış hızı, kullanım arttıkça yükseliyor.

Sektörün genel eğilimi şu: token başına fiyatlar zamanla düşüyor, evet. Ama çıkarım hacmi fiyatlardan çok daha hızlı büyüyor. Bir ürün başarılı olduğunda kullanıcı sayısı artıyor, kullanıcı başına çağrı sayısı artıyor, her çağrının bağlamı (context) zenginleştikçe token sayısı artıyor. Üç çarpanın hepsi aynı yöne bakıyor. Sonuç: birim fiyat düşse bile toplam fatura tırmanıyor. Ben buna "ölçek cezası" diyorum. Başarınızın bedelini çıkarım faturasıyla ödüyorsunuz.

Şimdi işin en yanıltıcı kısmına gelelim. Token başına fiyata bakıp "çok ucuz" diye rahatlamak, 2026'da en pahalı yanılgılardan biri.

Modern agent'lı iş akışları bir görevi tek çağrıyla bitirmiyor. Bir "araştır, planla, araç çağır, sonucu değerlendir, düzelt, tekrar dene" döngüsü kuruyor. Gerçek bir agent bir tek kullanıcı görevini tamamlamak için rahatlıkla 50 ila 200 arası LLM çağrısı yapabiliyor. Her adım bir öncekinin çıktısını bağlama ekliyor, yani token sayısı da adım adım şişiyor.

Küçük bir hesap yapalım. Diyelim ki tek bir çağrı size 0,01 dolara mal oluyor. Kulağa hiç dert değilmiş gibi geliyor. Ama bu çağrı bir görevde 120 kez tekrarlanıyorsa, görev başına maliyet 1,20 dolara çıkıyor. Günde 10.000 görev işleyen bir sistemde bu, günde 12.000 dolar, ayda 360.000 dolar demek. Aynı sistemi "token ucuz" diye planlayan bir ekip, bütçeyi 50 kat yanlış kurmuş oluyor.

Sahada bunu defalarca gördüm. Bir müşterim, müşteri hizmetleri için kurdukları agent'ın "basit bir soruya" ortalama 40 çağrı harcadığını fark ettiğinde yüzündeki ifadeyi unutamıyorum. Çünkü kimse görev başına maliyeti izlemiyordu; herkes token fiyatına bakıyordu. Ölçüm birimini yanlış seçmek, koca bir bütçeyi görünmez kılıyor.

"

Kural: Agent'lı sistemlerde maliyeti token başına değil, görev başına düşünün. Bir kullanıcı işini bitirmenin gerçek maliyeti, o işi oluşturan tüm çağrıların toplamıdır.

Bu çarpan etkisi, aslında müjde de içeriyor. Çünkü aynı çarpan, yaptığınız her optimizasyonu da büyütüyor. Tek bir çağrıda %30 tasarruf, 120 çağrılık bir görevde aynı %30 olarak katlanıyor. Yani optimizasyon çabası, agent'lı dünyada normalden çok daha yüksek getiri veriyor.

Maliyet optimizasyonunun en hızlı geri dönen aracı önbellekleme. Mantığı basit: aynı ya da benzer bir isteğin cevabını ikinci kez üretmek için modele para ödemeyin; ilk cevabı saklayın, tekrar gelince oradan verin.

Üç katmanda düşünmekte fayda var.

1. Tam eşleşme (exact-match) önbelleği. En basit hali. Girdi birebir aynıysa, saklanan cevabı döndürürsünüz. SSS tarzı, tekrar eden sorularda müthiş çalışır. Ama gerçek dünyada kullanıcılar aynı şeyi hiçbir zaman birebir aynı kelimelerle sormaz, o yüzden tek başına yetersiz kalır.

2. Semantik önbellek (semantic caching). İşte asıl güç burada. Girdiyi bir embedding'e (anlam vektörüne) çevirip, geçmiş isteklerle anlamsal benzerliğine bakarsınız. "Faturamı nasıl öderim?" ile "Ödeme nasıl yapılıyor?" farklı kelimeler ama aynı niyet. Semantik önbellek bunu yakalar ve ikisine de aynı hazır cevabı verir. Redis'in LangCache çözümü, yüksek tekrarlı iş yüklerinde ~%73'e varan maliyet düşüşü gösterdi. Ayrıca önbellek isabetleri (cache hit) taze çıkarımın saniyelerine karşılık milisaniyelerle dönüyor; yani sadece ucuzlamıyor, aynı zamanda hızlanıyorsunuz. Kullanıcı deneyimi ve fatura, aynı anda iyileşiyor.

3. Prompt (istem) önbelleği / prefix caching. Birçok sağlayıcının sunduğu bir özellik. Sistem talimatınız, uzun bir doküman ya da sabit bağlam her çağrıda tekrarlanıyorsa, bu ortak ön-eki (prefix) sağlayıcı tarafında önbelleğe alıp indirimli fiyatlandırabilirsiniz. Uzun sistem promptlarıyla çalışan agent'larda bu tek başına ciddi tasarruf getirir.

Ama bir uyarı: önbellek körlemesine iyi değildir. Kişiselleştirilmiş, zaman-duyarlı ya da güvenlik açısından hassas cevaplarda yanlış önbellek isabeti, yanlış kullanıcıya yanlış veri göstermek demektir. Semantik önbellekte benzerlik eşiğini (threshold) fazla gevşetirseniz, "yakın ama yanlış" cevaplar dönmeye başlar. Bu yüzden önbelleği her rotaya körü körüne açmayın; nerede güvenli olduğuna karar verin.

İkinci büyük tasarruf kalemi, her işe en pahalı modeli koşmamaktan geliyor. Sahada gördüğüm en yaygın israf bu: ekip en güçlü, en pahalı amiral gemisi modeli tüm istekler için varsayılan yapıyor. Oysa isteklerin çoğu o gücü hak etmiyor.

Akıllı yönlendirme fikri şu: gelen isteği önce sınıflandır, sonra uygun modele gönder. Basit bir niyet tespiti, kısa bir özet, format dönüşümü ya da sınıflandırma gibi işler küçük ve ucuz bir modelle mükemmel çıkıyor. Gerçekten muhakeme, çok adımlı planlama ya da hassas üretim gerektiren işleri pahalı modele saklayın.

Bir benzetme yapayım: her yolculuk için taksi çağırmazsınız. Yürünecek yeri yürür, kısa mesafeye otobüse biner, sadece gerçekten gerektiğinde taksiye binersiniz. Model yönlendirme de tam olarak bu. İşin "mesafesini" tahmin edip doğru aracı seçmek.

Pratikte yönlendirmeyi birkaç sinyalle kurabilirsiniz: isteğin uzunluğu, tespit edilen görev tipi, geçmişte benzer isteklerin hangi modelde başarılı olduğu, hatta önce ucuz modeli deneyip yetersiz kalırsa pahalıya yükseltme (escalation) stratejisi. Bu "önce ucuzu dene, gerekirse yükselt" yaklaşımı, çoğu iş yükünde faturayı gözle görülür düşürür çünkü isteklerin uzun kuyruğu aslında kolaydır.

Batching, birçok isteği tek seferde toplu göndermek demek. Gerçek zamanlı olmayan işlerde altın değerinde. Gecelik bir rapor üretimi, binlerce dokümanın etiketlenmesi, toplu embedding çıkarımı gibi senaryolarda anlık cevaba ihtiyacınız yoktur. Birçok sağlayıcı bu tür toplu işler için indirimli batch fiyatlandırması sunuyor, çünkü işi kendi boş kapasitelerinde planlayabiliyorlar.

Buradaki zihinsel ayrım şu: işlerinizi "senkron" (kullanıcı bekliyor) ve "asenkron" (kimse anlık beklemiyor) diye ikiye ayırın. Asenkron olan her şeyi batch'e taşıyın. Çoğu ekibin gözden kaçırdığı bu ayrım, tek başına ciddi bir kalem oluşturur çünkü aslında acil olmayan işleri gereksiz yere pahalı, anlık kanaldan geçiriyoruz.

Şimdi biraz kaputun altına bakalım, ama mühendis olmayanların da anlayacağı dilde. Transformer modelleri metni token token üretirken, o ana kadar gördükleri tüm tokenların "anahtar" (key) ve "değer" (value) temsillerini bellekte tutar. Buna KV-cache denir. Uzun bağlamlarda bu bellek dev boyutlara ulaşır ve hem hızın hem maliyetin gizli boğazı haline gelir. KV-cache'i iyi yönetmek, uzun bağlamlı ve agent'lı sistemlerde doğrudan çıkarım maliyetini etkiler.

Dell Technologies'in Mart 2026 tarihli bir taraması, KV-cache yönetimini beş kategoride topluyor. Her birini gündelik dille açıklayayım:

1. Önbellek boşaltma (cache eviction). Düşük önemli tokenları atmak. Modelin dikkatinin çoğu birkaç kritik tokena yoğunlaşır; geri kalan "gürültüyü" bellekten düşürerek yer açarsınız. Dolabınızdaki hiç giymediğiniz kıyafetleri çıkarıp yer açmak gibi.

2. Önbellek sıkıştırma (cache compression). Kuantizasyon (sayıları daha az bitle temsil etme) ve havuzlama (pooling) gibi tekniklerle KV-cache'i sıkıştırmak. Aynı bilgiyi daha az yerde tutarsınız. Bir fotoğrafı kaliteden ödün vermeden daha küçük dosyaya kaydetmeye benzer.

3. Hibrit bellek (hybrid memory). Sıcak veriyi hızlı GPU belleğinde tutup, daha az kullanılanı CPU belleğine ya da NVMe diske taşımak (offloading). Pahalı GPU belleği kıymetlidir; her şeyi orada tutmak israftır. Sık kullandığınız dosyaları masaüstünde, gerisini arşivde tutmak gibi.

4. Yeni dikkat mekanizmaları (novel attention). Doğrusal (linear) ya da log-doğrusal (log-linear) dikkat gibi, bağlam uzunluğuyla maliyetin daha yavaş büyüdüğü yaklaşımlar. Bunlar modelin mimarisiyle ilgilidir; genelde model seçimiyle gelir, sizin sonradan ekleyebileceğiniz bir şey değildir ama model seçerken farkında olmanız gereken bir kriterdir.

5. Kombinasyon stratejileri. Yukarıdakileri birlikte kullanmak. Gerçek dünyada tek bir teknik nadiren yeter; boşaltma + sıkıştırma + hibrit bellek birlikte devreye girer.

Peki bir uygulama sahibi olarak bunun neresindesiniz? Doğrudan API kullanıyorsanız bu tekniklerin çoğu sağlayıcının içinde gizlidir; sizin göreviniz uzun bağlamları gereksiz şişirmemek ve prompt önbelleğinden faydalanmaktır. Ama kendi modelinizi barındırıyorsanız (self-hosted), bu beş kategori doğrudan sizin optimizasyon araç kutunuzdur ve GPU faturanızı belirler.

Şimdi en çok atlanan ama bence en kritik parçaya geldik. Yukarıdaki tüm teknikler güzel; ama ölçmüyorsanız, hangisinin işe yaradığını asla bilemezsiniz. Sahadaki mottom şu: ölçmediğiniz maliyeti optimize edemezsiniz.

LLMOps'ta gözlemlenebilirlik dört ayak üzerinde durur:

• İzleme (tracing): Bir isteği çok adımlı bir hattın (pipeline) içinde uçtan uca takip etmek. Agent 120 çağrı yaptıysa, hangi adımın ne kadar token yaktığını görebilmelisiniz.
• Kayıt (logging): Promptları ve yanıtları kaydetmek. Hem hata ayıklama hem kalite denetimi için şart.
• Değerlendirme (evaluation): Çıktı kalitesini ölçmek. Ucuz modele geçtiğinizde kalite düştü mü? Bunu ancak sistemli değerlendirmeyle görürsünüz.
• Maliyet atıfı (cost attribution): Maliyeti kullanıcı, proje ya da özellik bazında ayrıştırmak. "Bu ay faturanın %60'ı hangi özellikten geldi?" sorusuna cevap verebilmek.

Maliyet atıfı özellikle önemli çünkü toplam faturaya bakmak bir şey anlatmaz. Faturayı özelliklere böldüğünüzde, çoğu zaman maliyetin %80'inin birkaç "obur" özellikten geldiğini görürsünüz. Optimizasyon çabanızı oraya yoğunlaştırırsınız. Ben buna "faturanın anatomisi" diyorum; toplam sayı bir semptomdur, atıf ise teşhistir.

Bir noktanın altını özellikle çizmek istiyorum çünkü sahada en sık burada tökezleniyor. Önbellek kurdunuz, "girdi maliyeti düştü" diye seviniyorsunuz. Ama gerçekten düştü mü, yoksa trafik mi değişti, bilmiyorsunuz.

Çözüm: her rota için önbellek isabet oranı (cache hit rate) metriği. Bu metrik olmadan, bir girdi-maliyeti düşüşünün gerçek olup olmadığını söyleyemezsiniz. Belki isabet oranınız aslında %5'te ve tasarruf sandığınız şey sadece o hafta gelen soruların daha kısa olmasından kaynaklanıyor. Belki de eşiği fazla gevşetmişsiniz, isabet oranı yüksek görünüyor ama yanlış cevaplar dönüyor.

İsabet oranını rota bazında ölçtüğünüzde şunları görürsünüz: hangi rotalar önbelleğe uygun, hangileri değil; benzerlik eşiğini nereye çekmeniz gerektiği; önbelleğin gerçekten para kazandırıp kazandırmadığı. Bu tek metrik, önbellek yatırımınızın gerçek mi hayali mi olduğunu söyleyen turnusol kağıdıdır.

Türkiye'deki ekiplerle çalışırken maliyet tartışması hiçbir zaman sadece dolar meselesi olmuyor; işin içine KVKK ve veri ikametgahı (data residency) giriyor. Ve bu, doğrudan mimari ve maliyet kararına dönüşüyor.

Kişisel veri işleyen bir uygulamada, verinin yurt dışındaki bir API'ye gitmesi KVKK açısından yurt dışına veri aktarımı demektir ve belirli koşullara tabidir. Bazı sektörlerde (finans, sağlık, kamu) bu iş neredeyse imkansız hale gelir. İşte tam burada "kendi modelini barındırma" (self-hosted) seçeneği masaya geliyor.

İki seçeneği maliyet ve uyum açısından karşılaştıralım:

Boyut	API (dışarıdan servis)	Self-hosted (kendi sunucun)
Başlangıç maliyeti	Düşük, hemen başlarsınız	Yüksek; GPU, kurulum, ekip
Marjinal maliyet	Token başına sürekli akar	GPU sabit; hacim artınca birim düşer
KVKK / veri ikametgahı	Yurt dışı aktarımı riski	Veri sizde kalır, uyum kolaylaşır
Bakım yükü	Sağlayıcı taşır	Sizin ekibiniz taşır
KV-cache optimizasyonu	Sağlayıcının içinde gizli	Beş kategori doğrudan sizin elinizde

Buradaki karar tek boyutlu değil. Düşük hacimli, veri hassasiyeti orta bir uygulama için API neredeyse her zaman daha ucuz ve hızlı başlar. Ama yüksek hacimli, sürekli çalışan, kişisel veri yoğun bir sistemde hem KVKK hem de birim maliyet, terazi zamanla self-hosted lehine döner. Kritik nokta şu: bu kararı duyguyla değil, ölçümle verin. Görev başına gerçek maliyetinizi ve gerçek hacminizi bilmeden "kendi sunucumuza geçelim" demek, çoğu zaman GPU'ları boş yere ısıtmakla sonuçlanır.

Bir de melez (hibrit) yol var ki Türkiye'de en pratik bulduğum bu: hassas kişisel veriyi işleyen rotaları yurt içinde barındırdığınız daha küçük bir modele, hassas olmayan genel işleri ise dış API'ye yönlendirmek. Yani "akıllı yönlendirme"yi sadece maliyet için değil, uyum için de kullanmak. Rota bazlı düşünmeye alıştığınızda, KVKK aslında maliyet mimarinizin bir boyutu haline geliyor, ayrı bir dert değil.

Sahada ekiplere bıraktığım pratik listeyi buraya koyuyorum. Sırayla gidin; en tepesi en yüksek getiriyi verir.

• Ölçüm önce gelir. Görev başına maliyet, özellik bazlı maliyet atıfı ve rota bazlı önbellek isabet oranını izlemeye alın. Ölçemediğinizi optimize edemezsiniz.
• Senkron/asenkron ayrımı yapın. Anlık beklenmeyen her işi batch'e taşıyın.
• Prompt/prefix önbelleğini açın. Uzun, tekrar eden sistem promptlarınız varsa bu ücretsiz kazançtır.
• Semantik önbellek kurun ama sadece güvenli rotalarda; benzerlik eşiğini ölçerek ayarlayın, isabet oranını izleyin.
• Akıllı yönlendirme ekleyin. Kolay işlere ucuz model, zor işlere pahalı model. "Önce ucuzu dene, gerekirse yükselt" stratejisini deneyin.
• Bağlamı diyete sokun. Her çağrıya gereksiz token doldurmayın; agent adımlarında bağlamı budayın.
• Self-hosted iseniz KV-cache kutusunu açın. Boşaltma, sıkıştırma, hibrit bellek kombinasyonunu değerlendirin.
• KVKK'yı mimariye gömün. Hassas veri rotalarını uyum açısından ayrı yönlendirin.
• Düzenli gözden geçirin. Faturanın anatomisini ayda bir çıkarın; obur özellikleri avlayın.

Teoriyi bırakıp yarın sabah ne yapacağınıza gelelim. Bir ekibe bu işi devraldığımda ilk iki haftayı genelde şöyle kurgularım.

1. Hafta — görünürlük. İlk beş gün tek bir hedefe adanır: ölçüm. Her isteğe izleme (trace) ekleyin, promptları ve yanıtları kaydedin, token sayısını ve maliyeti özellik ile kullanıcı bazında ayrıştırın. Bu haftanın sonunda tek bir soruya net cevap verebilmelisiniz: "Faturamın hangi özellikten, hangi kullanıcıdan, hangi adımdan geldiğini biliyor muyum?" Genellikle bu hafta hiçbir kod optimizasyonu yapmadan, sadece "bak, bu obur özellik tüm faturanın yarısı" tespitiyle bile büyük bir kazanç kapısı açılır.

2. Hafta — kaldıraçları çekmek. İkinci hafta ölçümün gösterdiği en obur iki-üç özelliğe odaklanın. Oralarda önce en ucuz kaldıracı deneyin: prompt önbelleği ve senkron/asenkron ayrımı. Sonra o rotalarda semantik önbelleği güvenliyse devreye alın ve isabet oranını izleyin. Ardından kolay isteklerde akıllı yönlendirmeyi test edin; kalite değerlendirmesini yanında tutun ki ucuz modele geçerken kaliteyi düşürmediğinizi kanıtlayabilesiniz.

Bu iki haftanın sonunda çoğu ekip, API maliyetinde tipik olarak beklenen %30-50 bandına ulaşır, ki bu tasarruf çoğu zaman kullandığınız tüm gözlemlenebilirlik ve önbellek araçlarının bütçesini tek başına karşılar. Yani optimizasyon araçları kendi parasını çıkarır, üstüne de kar bırakır. Sahada tekrar tekrar gördüğüm tablo bu.

Son bir düşünce olarak şunu bırakmak isterim: LLM maliyet optimizasyonu tek seferlik bir proje değil, sürekli bir disiplindir. Model fiyatları değişir, kullanım desenleri kayar, yeni özellikler yeni oburlar doğurur. Bu yüzden asıl kazandığınız şey şu ya da bu teknik değil; ölçen, atıf yapan, rota bazlı düşünen bir kültür. O kültürü kurduğunuzda, hangi yeni teknik çıkarsa çıksın, faturanızın kontrolü sizde kalır. Ve inanın, o kontrol hissi, herhangi bir tekil indirimden çok daha değerli.

Ekiplere anlattığımda en çok kaş kaldıran konu bu oluyor, çünkü kimse bağlamı bir maliyet kalemi olarak görmüyor. Oysa her LLM çağrısında ödediğiniz tokenların büyük kısmı çıktı değil, girdidir; yani modele gönderdiğiniz bağlamdır. Agent döngülerinde bu daha da vahim, çünkü her adım bir öncekinin tüm geçmişini taşıyarak büyür. Onuncu adıma geldiğinizde, model on turluk konuşmanın tamamını tekrar tekrar okuyup faturaya yazıyor.

Sahada gördüğüm en yaygın israf, "her ihtimale karşı" bağlama doldurulmuş devasa sistem promptları. Ekip modelin bir şeyi kaçırmasından korkuyor, ekliyor, ekliyor; sonunda her çağrı 4.000 tokenlık bir yükle başlıyor ve bunun belki 200'ü gerçekten o çağrı için gerekli. Bunu 120 çağrılık bir görevle çarpın; israfın büyüklüğünü görürsünüz.

Pratik reçetem şu: bağlamı bir diyet listesi gibi düşünün. Her adımda kendinize sorun, "Modelin bu görevi bitirmesi için gerçekten neyi görmesi lazım?" Konuşma geçmişini olduğu gibi taşımak yerine özetleyin (summarization). Alakasız araç çıktılarını budayın. Uzun dokümanları tümüyle göndermek yerine, ilgili parçaları getirip (retrieval) sadece onları koyun. Bu son nokta, RAG mimarilerinin neden sadece kalite değil maliyet aracı da olduğunu açıklar: doğru parçayı getirmek, koca dokümanı her seferinde okumaktan hem daha ucuz hem daha isabetlidir.

Bir uyarıyı özellikle vurgulamak istiyorum çünkü maliyet iyileştirmesi bazen sinsi bir bedelle gelir: kalite düşüşü. Ucuz modele geçtiniz, semantik önbelleğin eşiğini gevşettiniz, bağlamı budadınız. Fatura düştü, harika. Ama ya cevaplar da kötüleştiyse? Ölçmüyorsanız bunu ancak müşteri şikayetleri geldiğinde, yani en pahalı yerde öğrenirsiniz.

Bu yüzden her maliyet optimizasyonunu bir kalite değerlendirmesiyle (evaluation) çiftlemek şart. Önce bir referans (baseline) kalite ölçün, sonra optimizasyonu uygulayın, sonra aynı ölçümü tekrarlayın. Kalite kabul edilebilir bant içinde kaldıysa tasarruf gerçek. Düştüyse, tasarruf aslında borçlanmadır; ileride müşteri kaybı olarak faiziyle geri döner. Sahada gördüğüm en olgun ekipler, her maliyet değişikliğini küçük bir A/B testiyle devreye alıyor: trafiğin bir kısmını yeni ucuz yola, bir kısmını eski yola gönderip hem maliyeti hem kaliteyi yan yana izliyorlar.

Somutlaştırmak için gerçek hayattan damıtılmış bir örnek vereyim. Diyelim bir e-ticaret firmasısınız ve destek için bir agent kurdunuz. İlk kurulumda her soru, en pahalı modele gidiyor ve agent kargo takibi için 30-40 çağrılık bir döngü kuruyor. Aylık fatura tavan yapıyor.

Sırayla kaldıraçları çekelim. Önce ölçüm koyuyoruz ve görüyoruz ki isteklerin %70'i "kargom nerede", "iade nasıl yapılır", "bedenler nasıl" gibi tekrar eden basit sorular. Bunların çoğu semantik önbelleğe mükemmel uyuyor; eşiği ölçerek ayarlıyoruz, isabet oranı rota bazında %60'a çıkıyor ve bu rotalarda maliyet neredeyse sıfıra iniyor, üstelik cevaplar milisaniyelerle geliyor. Sonra basit soruları küçük ucuz modele yönlendiriyoruz; sadece gerçekten karmaşık, çok adımlı şikayet çözümlerini pahalı modele saklıyoruz. Kargo durumu sorgusu gibi araç ağırlıklı işleri, gereksiz muhakeme turlarını budayarak 40 çağrıdan 8 çağrıya indiriyoruz. Son olarak, kişisel veri içeren sipariş detaylarını KVKK gereği yurt içi barındırdığımız modele, genel bilgi sorularını dış API'ye yönlendiriyoruz.

Sonuç tablosu tanıdık: fatura tipik %30-50 bandında düşüyor, cevap süresi kısalıyor, KVKK riski azalıyor ve en önemlisi, artık her şeyi ölçtüğümüz için bir sonraki ay hangi rotaya dokunacağımızı biliyoruz. Bu senaryonun özeti aslında tüm yazının özeti: tek bir sihirli düğme yok; ölçüp, katman katman, rota rota kaldıraç çekmek var.

Kapanışta bir yanılgıyı daha dağıtmak istiyorum: "Nasılsa token fiyatları düşüyor, bekleyelim, kendiliğinden ucuzlar." Bu, sahada gördüğüm en pahalı bekleme stratejisi. Evet, birim fiyatlar düşüyor. Ama daha önce anlattığım üç çarpan (kullanıcı sayısı, kullanıcı başına çağrı, çağrı başına token) fiyat düşüşünden çok daha hızlı büyüyor. Fiyat yarıya inse bile hacminiz üçe katlanırsa, faturanız yine de büyür. Üstelik model yetenekleri arttıkça ekipler daha uzun bağlamlar, daha çok araç, daha derin agent döngüleri kuruyor; yani her fiyat indirimini yeni bir iştahla yiyip bitiriyoruz. Piyasanın ucuzlamasını beklemek, akan musluğun altında "su ucuzlayacak" diye beklemeye benziyor. Kontrol, sizin kurduğunuz ölçüm ve kaldıraç disiplininden gelir; piyasadan değil. Bugün ölçmeye başlayan ekip, altı ay sonra hangi fiyat ortamı gelirse gelsin, faturasının direksiyonunu elinde tutan ekip olur. Beklemek yerine ölçmeyi seçin; fark, tam olarak burada başlıyor: bekleyen değil, ölçen kazanır ve o disiplin bir kez kurulunca kalıcı olur.