LLM Maliyet Optimizasyonu 2026: Prompt Caching, Batching ve Akıllı Yönlendirme

TL;DR — 2026'nın en tuhaf paradoksu şu: token fiyatları 2025'ten bu yana yaklaşık %80 düştü (GPT-4 seviyesindeki performans 2023 başında milyon token başına ~30 dolarken bugün ~0,40 dolar), ama kurumsal LLM API harcaması 2025'te 8,4 milyar doları aştı ve artmaya devam ediyor. "Fiyatlar düşerken faturalar patlıyor." Sebebi net: çıkarım (inference) kurumsal AI bütçesinin ~%85'i; projelerin ~%60'ı maliyet tahminini %30-50 aşıyor; çıktı token'ları girdinin 4-6 katı pahalı. Bu yazıda faturayı gerçekten düşüren üç kaldıraç olan prompt caching (istem önbelleğe alma), batching (toplu işleme) ve akıllı yönlendirmeyi (smart routing) bir "LLM için FinOps" çerçevesine oturtuyorum: ölçüm/gözlemlenebilirlik, kararlı önekler, semantik önbellek, model kademelendirme, çıktı uzunluğu kontrolü ve bir tasarruf tablosu. Sonunda Türkiye'ye özel TL/kur riski ve KVKK/BDDK için self-hosting dengesine de değiniyorum.

Danışmanlık yaptığım şirketlerde son bir yılda en çok duyduğum cümle şu: "Fiyatlar düşüyormuş, o zaman biz neden her ay daha fazla ödüyoruz?" Bu soru haklı ve cevabı aslında yönetimin çok sevmediği bir yerde: sorun modelde değil, kullanımda. Bu yazıyı, o toplantılarda beyaz tahtaya çizdiğim maliyet haritasını ve uyguladığımızda gerçekten para kazandıran taktikleri bir araya getirmek için yazdım. Amacım size, faturayı %60-80 aralığında küçültebilecek somut bir oyun planı vermek.

Birim fiyat ve toplam harcama iki farklı şeydir. Birim fiyat düşer ama toplam harcama = birim fiyat × kullanılan token sayısıdır. Ve kullanılan token sayısı son iki yılda çok daha hızlı büyüdü. Bunun birkaç nedeni var.

Birincisi, model başına daha fazla token tüketiyoruz. Eskiden tek bir soru-cevap yeterken, bugün bir kullanıcı isteği bir ajan tarafından onlarca adıma bölünüyor; her adımda uzun sistem mesajları, araç şemaları, alınan belgeler ve akıl yürütme izleri (reasoning traces) yeniden yeniden modele gönderiliyor. İkincisi, muhakeme (reasoning) modelleri "düşünme" için görünür token üretiyor ve bu token'lar da faturaya yazılıyor. Üçüncüsü, başarı kendi talebini yaratıyor: LLM işe yarayınca daha çok yere koyuyoruz, kullanım katlanıyor.

Faturanızın nereden geldiğini bilmeden optimize edemezsiniz. Pratikte maliyet şu kalemlerden birikir: uzun sistem mesajlarının her istekte yeniden okunması, şişen sohbet geçmişi, RAG ile getirilen belgeler, araç şemaları (tool schemas), loglar, akıl yürütme izleri ve uzun çıktılar. Bunların çoğu tekrar eden, sabit içeriktir — ve tam da bu yüzden optimize edilebilir.

Frontier API'lerde çıktı token'ları girdi token'larının kabaca 4-6 katı pahalıdır. Bunu içselleştirmek, optimizasyon önceliklerinizi tamamen değiştirir. 10 bin token'lık bir istem gönderip 200 token'lık kısa bir cevap almak, çoğu zaman 2 bin token'lık bir istem gönderip 3 bin token'lık uzun bir cevap almaktan daha ucuzdur. "Modeli daha az konuştur" tek başına en yüksek getirili kaldıraçlardan biridir.

Sahada gördüğüm en yaygın israf: gereksiz uzun çıktılar. Model, istenmeden madde madde açıklama yapar, gerekçe döker, özür diler, tekrar eder. Sistem mesajınıza "yalnızca istenen JSON'u döndür, açıklama ekleme" gibi net bir çıktı sözleşmesi koymak faturayı hissedilir biçimde düşürür. Çıktı uzunluğunu bir maliyet değişkeni olarak görmeye başlayın.

Muhakeme modelleri özel bir dikkat gerektirir. Bu modeller cevaba varmadan önce uzun "düşünme" token'ları üretir ve bunlar çıktı fiyatından ücretlendirilir. Basit görevlere pahalı bir muhakeme modeli koşmak, görünmez bir maliyet kaynağıdır: kullanıcı üç cümlelik bir cevap görür ama arkada binlerce token'lık akıl yürütme yakılmıştır. Muhakeme derinliğini (düşük/orta/yüksek) göreve göre ayarlayın ve basit işlerde muhakeme modelini hiç kullanmayın; çoğu istek buna ihtiyaç duymaz.

Prompt caching, 2026'nın en yüksek getirili ve en az kullanılan tekniğidir. Mantık basit: bir isteğin başındaki uzun ve değişmeyen kısım (sistem mesajı, araç şemaları, sabit talimatlar) sağlayıcı tarafında önbelleğe alınır; bir sonraki istek aynı önekle başladığında model bu kısmı sıfırdan işlemez, önbellekten okur. Hem ucuzlar hem hızlanır.

Ocak 2026'da PwC'nin yaptığı bir çalışma çarpıcıydı: OpenAI, Anthropic ve Google modelleri üzerinde, 10 bin token'lık sistem mesajlarıyla 500'den fazla ajan oturumu incelendi. Sonuç: prompt caching API maliyetlerini %41-80 düşürdü ve ilk token'a kadar geçen süreyi (time-to-first-token) %13-31 iyileştirdi. Yani hem ucuz hem hızlı. Ama kritik bir şart var.

"

Önbellek yalnızca istem önekleri (prefixes) kararlı kaldığında işe yarar. Önbellek önekten eşleşir; önekin ilk karakteri bile değişirse eşleşme kırılır ve tüm avantaj kaybolur.

Bu şartın pratik sonuçları çok önemli. İstem tasarımınızı önbellek dostu yapmalısınız: değişmeyen her şeyi (sistem talimatları, araç tanımları, few-shot örnekleri, sabit politika metinleri) istemin başına, değişen her şeyi (kullanıcının o anki sorusu, zaman damgası, oturuma özgü değişkenler) sonuna koyun. Sık yaptığım bir hata uyarısı: sistem mesajının en başına dinamik bir tarih ("Bugün 24 Temmuz 2026") koymak, her istekte öneki değiştirir ve önbelleği tamamen işe yaramaz hale getirir. Dinamik değerleri sona taşıyın.

Önbelleğin bir de yaşam süresi (TTL) vardır; genelde birkaç dakika ile bir saat arası. Trafiğiniz seyrekse önbellek soğur ve isabet oranı düşer. Bu yüzden önbellek, sürekli ve benzer istek akışı olan üretim sistemlerinde en çok işe yarar. Az sayıda, dağınık istekte kazanç sınırlıdır. Önbellek isabet oranını (cache hit rate) bir metrik olarak panelinize koyun; bu oran, istem tasarımınızın önbellek dostu olup olmadığının en dürüst göstergesidir.

Prompt caching, aynı önekin yeniden işlenmesini önler. Semantik önbellek ise bir adım öteye gider: anlamca benzer soruların cevabını yeniden üretmemeyi hedefler. Kullanıcı "iade politikanız nedir?" diye sorduğunda cevabı önbelleğe yazarsınız; başka biri "ürünü nasıl geri gönderirim?" dediğinde, soru farklı kelimelerle olsa da anlamca yakın olduğu için önbellekteki cevabı sunarsınız. Model hiç çağrılmaz; maliyet sıfıra iner.

Semantik önbellek, sık tekrar eden ve cevabı zamanla değişmeyen sorularda müthiş çalışır: SSS, ürün bilgisi, politika soruları. Uygulaması bir gömme (embedding) modeli ve bir benzerlik eşiğiyle yapılır: gelen soruyu vektöre çevirin, önbellekte yeterince benzer bir soru varsa onun cevabını verin. Dikkat: eşiği çok gevşek tutarsanız yanlış cevap sunma riski doğar; kişiye/bağlama özel soruları önbelleğe almaktan kaçının. Kişiselleştirilmiş ya da zamana duyarlı cevapları semantik önbellekten muaf tutmak için bir izin listesi (allowlist) kurun.

Her isteği en güçlü (ve en pahalı) modele göndermek, konforlu ama savurgan bir alışkanlıktır. Gerçek trafik heterojendir: gelen isteklerin büyük kısmı basittir ve küçük, ucuz bir modelle mükemmel biçimde cevaplanabilir; yalnızca küçük bir azınlık gerçekten frontier bir modelin muhakemesini gerektirir. Akıllı yönlendirme, her isteği zorluğuna göre doğru modele gönderme sanatıdır.

İki temel desen var. Birincisi yönlendirme (routing): hafif bir sınıflandırıcı (kural tabanlı ya da küçük bir model) isteğin zorluğunu tahmin eder ve doğrudan uygun modele gönderir. İkincisi kademe (cascade): önce ucuz modeli deneyin; cevabın güven skoru ya da bir doğrulama testi yeterliyse orada durun, değilse pahalı modele yükseltin (escalate). Kademe, ucuz modelin çözebildiği her isteği ucuza çözer ve yalnızca zorları pahalıya devreder.

Sahadan bir gözlem: müşteri destek ve iç bilgi-getirme (RAG) yüklerinde isteklerin çoğu şaşırtıcı derecede basittir. Bir e-ticaret destek botunda trafiğin büyük bölümü "kargom nerede", "iade nasıl yapılır" gibi sorulardı; bunları küçük bir modele yönlendirip yalnızca karmaşık şikayetleri büyük modele bırakmak, kalite kaybı olmadan faturayı ciddi biçimde düşürdü. Anahtar, yönlendirici kararını sürekli ölçmek ve yanlış yönlendirmelerin (küçük modelin batırdığı istekler) oranını izlemektir.

Yönlendirmeyi kurarken sık düşülen bir tuzak, yönlendiricinin kendisinin pahalı olmasıdır. Zorluk tahmini için büyük bir modeli çağırırsanız, tasarruf etmeye çalışırken her isteğe bir ek maliyet bindirirsiniz. Yönlendiriciyi olabildiğince ucuz tutun: önce kural tabanlı sinyalleri (istem uzunluğu, anahtar kelimeler, araç gereksinimi) deneyin; ancak bunlar yetmezse küçük bir sınıflandırıcı modele başvurun. Yönlendirici, koruduğu maliyetten çok daha ucuz olmalıdır.

Gerçek zamanlı olması gerekmeyen işler için toplu işleme (batch) API'leri genelde belirgin bir indirim sunar. Gece toplu özetleme, büyük veri kümesini etiketleme, e-posta sınıflandırma, geriye dönük analiz gibi işleri anlık uç noktalar yerine batch uç noktalarına verin. Kullanıcı bir ekran başında beklemediği her iş, batch adayıdır.

Batching'i mimarinize yerleştirirken işleri iki kovaya ayırın: etkileşimli (kullanıcı bekliyor, düşük gecikme şart, anlık API) ve arka plan (kimse beklemiyor, gecikmeye toleranslı, batch API). Bu ayrımı erken yapmak, hem maliyeti düşürür hem de anlık kapasitenizi gerçekten gecikmeye duyarlı işlere ayırmanızı sağlar. Ek olarak, çok sayıda küçük isteği tek çağrıda birleştirmek (request-level batching) sabit ek yükleri azaltır.

Bu kaldıraçlar birbirini dışlamaz, çarpar. Prompt caching + batching + akıllı yönlendirmeyi birlikte uyguladığınızda, trafik karışımınıza bağlı olarak faturada %60-80 aralığında bir azalma gerçekçidir. Neden çarpım? Çünkü her kaldıraç farklı bir israf kaynağını hedefler: caching tekrar eden önekleri, routing gereksiz güçlü model kullanımını, batching ise anlık kapasite primini ortadan kaldırır. Aşağıdaki tablo kaldıraçları ve tipik etkilerini özetliyor.

Kaldıraç	Neyi hedefler	Tipik etki	En çok işe yaradığı yer
Prompt caching	Tekrar eden istem önekleri	API maliyeti %41-80 azalır, TTFT %13-31 iyileşir	Kararlı önekli, sürekli akan trafik
Semantik önbellek	Anlamca tekrar eden sorular	Önbellek isabetinde maliyet ~%100 azalır	SSS, statik bilgi, politika soruları
Akıllı yönlendirme	Aşırı güçlü model kullanımı	Basit istekleri 5-10x ucuza çözer	Heterojen, çoğu basit trafik
Batching	Anlık kapasite primi	Batch API indirimi	Gecikmeye toleranslı arka plan işleri
Çıktı uzunluğu kontrolü	Pahalı çıktı token'ları	Doğrudan çıktı maliyeti düşer	Uzun/gevşek cevap üreten her yer

Rakamları somutlaştırmak için basit, temsili bir senaryo kuralım (bunlar örnek amaçlı, sizin ölçümünüz farklı çıkacaktır). Diyelim ki günde 100 bin isteğiniz var, her biri 10 bin token sistem mesajı + 500 token kullanıcı girdisi + 800 token çıktı taşıyor ve hepsi frontier modele gidiyor. Önce prompt caching'i açıp öneki kararlı hale getirin: 10 bin token'lık sistem mesajının işlenmesi büyük ölçüde önbellekten karşılanır ve girdi tarafı belirgin biçimde ucuzlar. Ardından akıllı yönlendirmeyle isteklerin diyelim %70'ini küçük bir modele kaydırın; bu %70, birim maliyetin küçük bir kesrine iner. Son olarak gecikmeye toleranslı arka plan işlerini batch'e alın. Her adım bir öncekinin üzerine biner ve toplam etki, tek tek etkilerin toplamından fazladır. Kritik nokta şu: bu senaryoyu kendi telemetrinizle kurmadan hiçbir tahmine güvenmeyin; her iş yükünün karışımı farklıdır ve tasarruf, o karışıma bağlıdır.

Tekil taktikler güzel ama sürdürülebilir tasarruf bir disiplin gerektirir. Bulut dünyasındaki FinOps hareketini LLM'e uyarlıyorum. Üç aşamalı bir döngü: görünürlük → optimizasyon → yönetişim.

1. Görünürlük ve ölçüm

Ölçmediğiniz şeyi optimize edemezsiniz. En temel iki metrik: istek başına maliyet ve çözülen görev başına maliyet (cost per resolved task). İkincisi kritiktir çünkü ucuz bir model isteği ucuza cevaplayıp yanlış cevap verir, kullanıcı üç kez daha sorar ve toplam maliyet artar. "Görev başına maliyet", token değil sonuç odaklı düşünmenizi sağlar.

Her isteği; kullanılan model, girdi/çıktı token sayısı, önbellek isabeti, gecikme, kullanıcı/özellik etiketi ve iş sonucuyla loglayın. Bu telemetriyi bir gösterge paneline bağlayın. Hangi özelliğin, hangi ekibin, hangi müşteri segmentinin ne kadar yaktığını göremiyorsanız, kör uçuyorsunuz demektir. Maliyeti özellik ve takım bazında dağıtmak (chargeback/showback), davranışı değiştiren tek şeydir. Gözlemlenebilirliği baştan kurmak, sonradan eklemekten çok daha ucuzdur; çünkü optimizasyon kararlarınızın hepsi bu veriye dayanacak.

2. Optimizasyon

Görünürlük geldikten sonra kaldıraçları önceliklendirin. Genelde sıralama şu olur: önce çıktı uzunluğunu ve istem şişkinliğini kısın (bedava, hızlı), sonra prompt caching için önekleri kararlı hale getirin, sonra akıllı yönlendirmeyi kurun, en son batching ve semantik önbelleği ekleyin. Her değişikliği bir A/B testiyle doğrulayın: hem maliyet düştü mü hem de görev başarı oranı korundu mu? Maliyeti düşürüp kaliteyi bozan bir optimizasyon, gizli bir maliyet artışıdır.

3. Yönetişim

Tasarrufu kalıcı kılmak için korkuluklar (guardrails) gerekir: takım/özellik bazında bütçe limitleri, anormal harcama alarmları, yeni bir özelliğin üretime çıkmadan önce maliyet tahmini yapması zorunluluğu. Projelerin ~%60'ının maliyet tahminini %30-50 aştığını hatırlayın; bunun panzehiri, maliyeti tasarım aşamasında bir kabul kriteri haline getirmektir. "Bu özellik istek başına ne kadar yakacak?" sorusu, ürün gereksinim dokümanının standart bir satırı olmalı.

• İstek başına ve çözülen görev başına maliyeti ölçüyor muyuz?
• Her isteği model, token, önbellek isabeti ve iş sonucu etiketiyle logluyor muyuz?
• Maliyeti özellik/takım bazında dağıtıyor muyuz (showback)?
• Sistem mesajı ve araç şemaları istemin başında, kararlı bir önek olarak mı duruyor?
• Dinamik değerleri (tarih, oturum değişkenleri) istemin sonuna taşıdık mı?
• Prompt caching açık mı ve isabet oranını izliyor muyuz?
• Tekrar eden, statik sorular için semantik önbellek var mı ve eşiği güvenli mi?
• Basit istekleri küçük modele yönlendiren bir router / cascade kurduk mu?
• Yanlış yönlendirme oranını ölçüyor muyuz?
• Gecikmeye toleranslı işleri batch API'ye taşıdık mı?
• Çıktı uzunluğunu sistem mesajıyla ve max token limitiyle sınırlıyor muyuz?
• Muhakeme derinliğini göreve göre ayarlıyor muyuz?
• Takım/özellik bazında bütçe limiti ve anormal harcama alarmı var mı?
• Yeni özellikler üretime çıkmadan maliyet tahmini yapıyor mu?

Buraya kadar anlattıklarım evrensel; ama Türkiye'de çalışıyorsanız iki ek boyut var. Birincisi kur riski. Neredeyse tüm frontier LLM API'leri faturayı dolar üzerinden keser. Geliriniz TL ise, token fiyatı dolar bazında düşse bile TL bazında maliyetiniz kur hareketiyle artabilir. Yani "fiyatlar düşüyor" haberi sizin için kısmen kur tarafından yenebilir. Pratik öneriler: bütçeleri TL değil dolar bazında planlayın ve TL karşılığını bir tampon payıyla tutun; harcama alarmlarını dolar cinsinden kurun; ve mümkünse sağlayıcıyla yıllık taahhüt/indirim görüşerek birim maliyeti sabitleyin. Kur oynaklığı, maliyet optimizasyonunu Türkiye'de daha da acil kılar; çünkü verimlilikten kazandığınızı kurdan kaybetmek istemezsiniz.

İkinci boyut self-hosting ve veri yerleşimi (data residency). KVKK'nın yurt dışına veri aktarımına ilişkin kuralları ve bankacılık için BDDK'nın bulut/dış hizmet düzenlemeleri, bazı sektörlerde hassas verinin yurt dışındaki bir API'ye gönderilmesini zorlaştırır ya da ek yükümlülüklere bağlar. Bu durumda açık ağırlıklı (open-weight) bir modeli kendi altyapınızda ya da Türkiye'deki bir bulutta barındırmak gündeme gelir.

Ama self-hosting'i bir maliyet çözümü sanmak yaygın bir yanılgıdır. Karşılaştırmayı dürüst yapın: GPU kirası ya da satın alımı, ölçekleme ve boşta kalan kapasite, MLOps ekibi, model güncelleme ve güvenlik yükü sabit ve yüksek maliyetlerdir. Self-hosting genelde ancak yüksek ve istikrarlı bir hacimde birim maliyette API'yi geçer; düşük ya da dalgalı hacimde API neredeyse her zaman daha ucuzdur. Karar kriteriniz saf maliyet değil, üç eksenin birleşimi olmalı: uyum zorunluluğu (KVKK/BDDK veriyi içeride tutmayı gerektiriyor mu?), hacim (birim maliyet başabaşı geçiyor mu?) ve kalite (açık model göreviniz için yeterli mi?). Çoğu kurum için sağlıklı orta yol hibrittir: hassas ve yüksek hacimli iş yükleri için içeride barındırılan açık bir model, geri kalan her şey için frontier API. Bu ayrım, hem uyumu hem faturayı aynı anda yönetmenizi sağlar.

Sahada "maliyet düşürüyoruz" diye yapılan ama tersine çalışan birkaç klasik hata var; bunları önceden bilmek size hem para hem zaman kazandırır. En sık gördüklerimi buraya topladım.

• Kaliteyi ölçmeden model küçültmek. Sırf ucuz diye tüm trafiği küçük bir modele taşımak, ilk faturada sevindirir ama görev başarı oranı düşerse kullanıcılar aynı işi tekrar tekrar dener; toplam maliyet ve memnuniyetsizlik artar. Her küçültmeyi görev başarısıyla birlikte ölçün.
• Önbelleği açıp öneki kararsız bırakmak. Prompt caching'i etkinleştirip sistem mesajının başına her seferinde değişen bir değer (tarih, oturum kimliği, kullanıcı adı) koymak, önbelleği hiç açmamakla aynı kapıya çıkar. İsabet oranı sıfıra yakın kalır ve neden tasarruf edemediğinizi anlayamazsınız.
• Gözlemlenebilirliği en sona bırakmak. "Önce çalışsın, maliyeti sonra bakarız" yaklaşımı, üç ay sonra kimsenin faturanın nereden geldiğini bilmediği bir kara kutu yaratır. Ölçüm ilk gün kurulmalı.
• Retry fırtınaları. Zaman aşımı ya da hata durumunda agresif yeniden deneme (retry) mantığı, sessizce token'ı ikiye üçe katlayabilir. Üstel geri çekilme (exponential backoff) ve bir üst sınır koyun.
• Bağlamı çöp tenekesi gibi kullanmak. Her belgeyi, her logu, tüm sohbet geçmişini "ne olur ne olmaz" diye isteme doldurmak, hem context rot'a hem şişkin faturaya yol açar. Bağlamı küratörlükle yönetin.

Bu anti-desenlerin ortak paydası şu: hepsi kısa vadede kolay, uzun vadede pahalıdır. Maliyet disiplinini bir seferlik bir proje değil, sürekli bir alışkanlık olarak kurmak, bu tuzakların çoğunu baştan eler.

Maliyet asla tek başına optimize edilmez; her zaman iki komşusuyla, gecikme (latency) ve kaliteyle birlikte hareket eder. Bu üçgeni görmezden gelen her optimizasyon, bir yerde gizli bir bedel yaratır. Örneğin çıktıyı sıkıştırmak maliyeti ve gecikmeyi birlikte düşürür — nadir görülen bir kazan-kazan. Ama modeli küçültmek maliyeti düşürürken kaliteyi riske atabilir; kademeli (cascade) yönlendirme ise maliyeti düşürür ama zor isteklerde ikinci bir çağrı ekleyerek gecikmeyi artırır.

Pratik tavsiyem, her iş yükü için bu üç eksende bir öncelik sırası belirlemek. Kullanıcının canlı beklediği bir sohbet arayüzünde gecikme kraldır; orada streaming (akışlı yanıt) ve prompt caching'in ilk-token süresini iyileştiren etkisi öne çıkar. Arka planda çalışan bir toplu işte gecikme neredeyse önemsizdir; orada en ucuz yolu seçer, batch ve en küçük yeterli modeli tercih edersiniz. Yüksek riskli, hatanın pahalıya patladığı bir kararda ise kalite kraldır; orada tasarruf uğruna model küçültmek yanlış ekonomidir. Aynı sistemde farklı iş yükleri için farklı denge noktaları seçmek, olgun bir LLMOps pratiğinin işaretidir.

Bir noktanın altını çizeyim: bu üçgende "her şeyi aynı anda en iyi yapan" bir ayar yoktur. İyi mühendislik, hangi ekseni ne zaman feda edeceğinize bilinçli karar vermektir. Ölçüm olmadan bu kararı veremezsiniz; bu yüzden gözlemlenebilirlik her şeyin temelidir.

Mühendislik kaldıraçları kadar önemli ama sık ihmal edilen bir alan da ticari müzakeredir. Yüksek ve öngörülebilir bir hacme ulaştığınızda, sağlayıcılarla taahhütlü kullanım karşılığında indirim, ayrılmış kapasite (provisioned throughput) ya da özel fiyat görüşmek çoğu zaman mümkündür. Birim maliyeti sözleşmeyle sabitlemek, hem bütçe öngörülebilirliğini artırır hem de Türkiye özelinde kur dalgalanmasının etkisini kısmen yumuşatır. Ayrıca birden fazla sağlayıcıyla çalışmak (multi-provider), hem pazarlık gücü verir hem de tek bir fiyat artışına ya da kesintiye karşı sizi korur. Maliyet optimizasyonunu yalnızca kod tarafında değil, satın alma masasında da düşünün; en iyi sonuç ikisinin birlikte çalışmasından çıkar.

Son olarak, bu ticari kararları da telemetriye bağlayın: hangi sağlayıcının hangi iş yükünde birim maliyet ve kalite açısından öne çıktığını ölçün. Böylece pazarlık masasına sezgiyle değil, kendi verinizle oturursunuz ve indirim taleplerinizi somut hacim taahhütleriyle desteklersiniz. Veriyle konuşan taraf, her müzakerede avantajlıdır.

Somut bir başlangıç planı istiyorsanız, ilk ayı şöyle geçirin. İlk hafta yalnızca ölçün: her isteği loglayın, istek başına ve görev başına maliyeti bir panele çıkarın, en çok yakan üç özelliği tespit edin. İkinci hafta bedava kazanımları toplayın: çıktı sözleşmelerini sıkın, istem şişkinliğini kırpın, dinamik değerleri sona taşıyıp önekleri kararlı hale getirin ve prompt caching'i açın; bu tek başına çoğu ekipte iki haneli tasarruf getirir. Üçüncü hafta akıllı yönlendirmeyi pilot edin: en yüksek hacimli, en basit istek türünü küçük bir modele yönlendirin ve görev başarı oranını izleyin. Dördüncü hafta yönetişimi kurun: bütçe limitleri, harcama alarmları ve yeni özellikler için maliyet tahmini zorunluluğu. Bu döngüyü kurduğunuzda, fiyatların düştüğü ama faturaların büyüdüğü paradoks sizin lehinize döner: kullanım büyürken bile maliyetiniz kontrol altında kalır, çünkü artık her token'ın nereye ve neden gittiğini görüyor ve yönetiyorsunuz.