LLM Çıkarım Maliyetini %80 Düşürmek: Üç Katmanlı Optimizasyon (2026)

TL;DR — Büyük dil modellerinde asıl para eğitimde değil, çıkarımda (inference) yanıyor. Bir modeli bir kez eğitirsiniz ama milyonlarca kez çağırırsınız; her çağrı GPU saniyesi ya da token başına ücret demektir. Sahada gördüğüm kadarıyla maliyeti kalıcı olarak düşürmenin yolu tek bir sihirli ayardan değil, üç katmanı üst üste optimize etmekten geçiyor: model katmanı (kuantizasyon, budama, damıtma), sistem katmanı (sürekli batching, PagedAttention, spekülatif kod çözme) ve uygulama katmanı (bağlam sıkıştırma, prompt/semantik caching, akıllı routing). Bu üç katmanı birlikte kurgulayınca çıkarım maliyetini %80 ve üzeri düşürmek gerçekçi bir hedef. Bu yazıda her katmanı somut tekniklerle, bir karşılaştırma tablosuyla, gözlemlenebilirlik ve maliyet dağıtımı (cost attribution) yaklaşımıyla ve Türkiye'ye özel TL/kur ve KVKK açısıyla anlatıyorum. Sonunda da doğrudan uygulayabileceğiniz adım adım bir maliyet düşürme oyun planı var.

Kurumlarla çalışırken en sık yaptığım düzeltme şu oluyor: "Model eğitmek pahalı, o yüzden hazır API kullanalım, böylece maliyetten kurtuluruz." Bu cümlenin ilk yarısı doğru, ikinci yarısı yanıltıcı. Evet, sıfırdan bir temel model eğitmek astronomik bir yatırım. Ama sizin gibi çoğu kurum zaten model eğitmiyor; hazır bir modeli kullanıyor. Sizin için maliyet kalemi eğitim değil, çıkarım. Yani modeli her çalıştırdığınızda, her kullanıcı isteğinde, her token üretiminde ödediğiniz bedel.

LLMOps'un klasik MLOps'tan ayrıldığı en kritik nokta tam olarak burası. Geleneksel makine öğrenmesinde eğitim maliyeti yüksek, ama modeli bir kez ürettikten sonra çıkarım genellikle ucuzdur; küçük bir model bir CPU üzerinde milisaniyeler içinde tahmin üretir. Büyük dil modellerinde ise denklem tersine döner: eğitim maliyeti (sizin açınızdan) düşük ya da sıfırdır çünkü hazır modeli kullanırsınız, ama süregelen çıkarım maliyeti kalıcı ve büyüktür. Bu maliyet ya GPU tabanlıdır (kendi altyapınızda modeli barındırıyorsanız) ya da token sayaçlı API çağrılarıdır (bir sağlayıcının API'sini kullanıyorsanız).

Bunun pratikteki anlamı şu: Bir yapay zeka özelliğini geliştirip yayına aldığınızda maliyet bitmez, aslında yeni başlar. Kullanıcı sayınız arttıkça, her kullanıcı daha çok soru sordukça, her soruya daha uzun bağlam eklendikçe faturanız doğrusal, hatta bazen doğrusaldan hızlı büyür. Ben bunu müşterilerime şöyle özetliyorum:

"

Eğitim bir sermaye harcamasıdır, bir kez yaparsınız ve biter. Çıkarım ise bir kira gibidir; her ay, her istek, her token için ödemeye devam edersiniz. Bir yapay zeka ürününün gerçek toplam sahip olma maliyetini çıkarım belirler.

İşte bu yüzden maliyet optimizasyonunu bir "sonradan yapılacak iş" değil, mimarinin ilk gününden itibaren bir tasarım kısıtı olarak ele almanızı öneriyorum. Çıkarım maliyetini kontrol altına almazsanız, teknik olarak başarılı ama ekonomik olarak sürdürülemez bir ürün ortaya çıkar. Sahada gördüğüm en acı manzara, pilotu harika giden ama ölçeklenince birim maliyeti tutmadığı için rafa kaldırılan projelerdir.

Çıkarım maliyetini düşürmenin dağınık onlarca tekniği var ama ben bunları kafada net tutmak için üç katmana ayırıyorum. Bu ayrım hem hangi tekniğin nerede işe yaradığını hem de bunların birbirini nasıl tamamladığını görmenizi sağlıyor.

Model katmanı. Modelin kendisini daha ucuz çalışacak hale getirdiğiniz katman. Burada kuantizasyon (ağırlıkların daha düşük hassasiyetle temsil edilmesi), budama (pruning, gereksiz ağırlıkların atılması) ve damıtma (distillation, büyük bir modelin bilgisini daha küçük bir modele aktarma) devreye girer. Amaç: aynı işi daha küçük, daha hızlı, daha az bellek isteyen bir modelle yapmak.

Sistem katmanı. Modeli çalıştıran altyapının verimliliğini artırdığınız katman. Sürekli batching (continuous batching), PagedAttention ve spekülatif kod çözme (speculative decoding) burada yaşar. Amaç: aynı GPU'dan daha fazla iş çıkarmak, yani donanım kullanımını (utilization) yukarı çekmek. Bir GPU boşta beklerken de para yakar; onu tıka basa dolu tutmak birim maliyeti düşürür.

Uygulama katmanı. İsteğin modele gitmeden önce ve geldikten sonra ne kadar akıllı yönetildiğiyle ilgili katman. Bağlam sıkıştırma, prompt caching, semantik caching ve model routing burada devreye girer. Amaç: modele gereksiz iş yaptırmamak; tekrar eden işi bir daha yaptırmamak, kolay işi ucuz modele yönlendirmek, bağlamı gereksiz yere şişirmemek.

Bu üç katmanın birlikte kullanılmasının gücü çarpan etkisinde. Tek başına kuantizasyon size belki 3 kat verim sağlar; tek başına semantik caching maliyeti belki üçte iki azaltır. Ama bunları üst üste koyduğunuzda tasarruflar çarpılır, toplanmaz. İşte bu yüzden üç katmanı birlikte optimize edince çıkarım maliyetinde %80 ve üzeri düşüş ulaşılabilir bir hedef haline gelir.

Aşağıdaki tabloda temel teknikleri hangi katmana ait olduğu, tipik tasarruf aralığı ve getirdiği ödünleşme (trade-off) ile birlikte özetledim:

Teknik	Katman	Tipik tasarruf	Ödünleşme
Prompt / bağlam caching	Uygulama	Tekrar eden prompt'larda ~%90'a kadar	Yalnızca tekrar eden ön ekler için işe yarar; cache yönetimi gerekir
Semantik caching	Uygulama	Çıkarım maliyetinde ~%73'e kadar	Benzerlik eşiği yanlış kurulursa hatalı cache isabeti riski
Model routing	Uygulama	İş yüküne göre değişken, çoğu istekte yüksek	Yönlendirme mantığı ve kalite izleme yükü
Bağlam / RAG veri hijyeni	Uygulama	Bağlam penceresini 3–5 kat küçültme	İyi veri kürasyonu ve chunking disiplini ister
Kuantizasyon	Model	~3 kat throughput, daha ucuz donanım	Küçük doğruluk kaybı olabilir; doğrulama şart
Budama / damıtma	Model	Model boyutunda ve maliyette belirgin düşüş	Kalite kaybı riski; yeniden değerlendirme gerekir
Sürekli batching	Sistem	GPU kullanımında büyük artış	Kendi altyapınızı yönetmeyi gerektirir
PagedAttention	Sistem	Bellek verimliliği, daha çok eşzamanlı istek	vLLM gibi uygun servis altyapısı gerekir
Spekülatif kod çözme	Sistem	Gecikmede ve maliyette düşüş	Taslak model kurulumu ve uyum ayarı ister

Şimdi katmanları tek tek açalım.

Model katmanındaki temel fikir şu: çoğu iş için elinizdeki en büyük, en pahalı modele ihtiyacınız yok. Aynı sonucu daha küçük ve daha ucuz çalışan bir modelle üretebiliyorsanız, her istekte tasarruf edersiniz.

Kuantizasyon bu katmanın en yüksek getirili tekniği. Model ağırlıklarını 16 bit yerine 8 bit ya da 4 bit gibi daha düşük hassasiyetle temsil edersiniz. Bunun iki doğrudan etkisi var: model bellekte daha az yer kaplar, dolayısıyla daha ucuz donanımda çalışır; ve hesaplama daha hızlı olur. Pratikte kuantizasyonun yaklaşık 3 kat throughput artışı sağladığını, yani aynı donanımdan üç katı iş çıkarabildiğinizi görüyorum. Bunun bedeli küçük bir doğruluk kaybı olabilir, ama modern kuantizasyon yöntemleriyle bu kayıp çoğu iş için ihmal edilebilir düzeyde. Kritik olan, kuantize edilmiş modeli kendi görevinizde ölçmeden yayına almamak; her zaman bir doğrulama seti üzerinde kalite karşılaştırması yapıyorum.

Budama (pruning) modeldeki katkısı düşük ağırlıkları ya da nöronları atarak modeli küçültür. Damıtma (distillation) ise büyük bir "öğretmen" modelin davranışını taklit eden daha küçük bir "öğrenci" model eğitir. İkisi de sonuçta daha küçük, daha ucuz bir çıkarım motoru verir. Bu teknikler kuantizasyondan daha çok emek ister ve kalite kaybı riski daha yüksektir; bu yüzden bunları genellikle iyi tanımlanmış, dar kapsamlı ve yüksek hacimli görevler için öneriyorum. Dar bir görevde damıtılmış küçük bir model, genel amaçlı dev bir modele kıyasla hem daha ucuz hem de sıklıkla daha hızlı olur.

Model katmanının stratejik özeti şu: doğru işi doğru boyuttaki modele yaptırın. Bu prensip bizi doğal olarak uygulama katmanındaki routing konusuna bağlıyor, ama önce sistem katmanına bakalım.

Sistem katmanı, özellikle modeli kendi altyapınızda barındırıyorsanız kritik. Buradaki tüm teknikler tek bir amaca hizmet eder: GPU'yu boşta bekletmemek, onu mümkün olduğunca dolu ve verimli çalıştırmak.

Sürekli batching (continuous batching) bunun kalbinde yer alır. Klasik batching'de istekleri bir grup halinde toplar, hepsi bitene kadar beklersiniz; bu da bazı istekler erken bitse bile GPU'nun yavaş isteği beklemesine yol açar. Sürekli batching ise biten isteğin yerine anında yenisini alır, böylece GPU sürekli meşgul kalır. Bu, donanım kullanımını dramatik biçimde yukarı çeker ve dolayısıyla istek başına maliyeti düşürür.

PagedAttention, dikkat mekanizmasının anahtar-değer önbelleğini (KV cache) işletim sistemlerindeki sanal bellek mantığıyla, sayfalar halinde yöneten bir tekniktir. Bellek parçalanmasını (fragmentation) azaltır ve aynı GPU'da çok daha fazla eşzamanlı isteği ağırlamanızı sağlar. vLLM gibi modern servis altyapıları bu tekniği kullanır ve kendi modelini barındıran ekiplere neredeyse her zaman bunu öneririm.

Spekülatif kod çözme (speculative decoding) ise küçük ve hızlı bir "taslak" modelin birkaç token'ı önceden tahmin etmesine, ardından büyük modelin bu tahminleri tek seferde doğrulamasına dayanır. Doğru tahmin edilen token'lar için büyük modeli tek tek çalıştırmaktan kurtulursunuz; bu hem gecikmeyi hem de maliyeti düşürür. Kurulumu biraz emek ister çünkü taslak modelin ana modelle uyumlu olması gerekir, ama yüksek hacimli üretim ortamlarında getirisi net.

Sistem katmanının önemli bir gerçeği şu: bu teknikler ancak modeli kendiniz barındırdığınızda doğrudan sizin kontrolünüzdedir. API kullanıyorsanız bu optimizasyonları sağlayıcı sizin adınıza yapar; siz onların token fiyatına razı olursunuz. Bu da bizi kendi altyapı ile API arasındaki temel ödünleşmeye getiriyor ki buna Türkiye bölümünde döneceğim.

Sahada bir kuruma girdiğimde ilk baktığım yer neredeyse her zaman uygulama katmanıdır çünkü en hızlı ve en risksiz kazançlar burada saklıdır. Bir GPU'yu kuantize etmek ya da kendi servis altyapınızı kurmak zaman alır; ama akıllı bir caching katmanı eklemek çoğu zaman günler içinde faturaya yansır.

Caching konusunda ikisi arasındaki farkı çok net anlamanızı istiyorum çünkü karıştırılıyor: prompt caching ve semantik caching aynı şey değil.

Prompt (bağlam) caching, isteklerinizin tekrar eden ön eklerini önbelleğe alır. Çoğu LLM uygulamasında her istek uzun ve sabit bir başlangıçla gelir: sistem talimatı, şirket politikaları, örnek diyaloglar, döküman bağlamı... Bu ön ek istekten isteğe değişmez. Prompt caching, bu sabit kısmın modelde yeniden işlenmesini engeller; model onu bir kez işler, sonrasında hazır halden devam eder. Tekrar eden prompt'larda bu tekniğin %90'a varan tasarruf sağladığını görüyorum. Koşul şu: cache isabeti için ön ekin bire bir aynı olması gerekir. Bu yüzden prompt'larınızı, değişmeyen kısımlar başta, değişen kısımlar sonda olacak şekilde yapılandırmanızı öneriyorum.

Semantik caching ise bambaşka bir mantık üzerine kurulu. Burada birebir aynı metni değil, anlamca benzer istekleri yakalarsınız. Kullanıcı "iade politikanız nedir" diye sordu, biraz önce başka biri "ürünü nasıl iade ederim" diye sormuştu; bu iki soru farklı kelimelerle aynı şeyi ister. Semantik cache, gelen isteğin embedding'ini önceki isteklerle karşılaştırır ve yeterince benzer bir eşleşme bulursa modeli hiç çalıştırmadan kayıtlı yanıtı döner. Bu tekniğin çıkarım maliyetini %73'e kadar düşürdüğü raporlanıyor. Buradaki incelik benzerlik eşiğidir: eşiği çok gevşek tutarsanız alakasız soruları eşleştirip yanlış yanıt dönme riski doğar; çok sıkı tutarsanız cache neredeyse hiç isabet etmez. Bu eşiği kendi trafiğiniz üzerinde ölçerek ayarlamak şart.

Bu iki tekniği birbirinin alternatifi değil, tamamlayıcısı olarak düşünün. Prompt caching sabit bağlamın maliyetini yok eder; semantik caching tekrar eden soruların maliyetini yok eder. İkisi birlikte, tipik bir müşteri destek ya da dahili bilgi asistanı senaryosunda faturanın çok büyük bir kısmını tıraşlar.

Uygulama katmanının bir diğer güçlü kolu RAG veri hijyeni. Getirmeli üretim (RAG) mimarilerinde modele her istekte bir sürü doküman parçası eklenir. Eğer bu parçalar dağınık, tekrarlı ve alakasızsa, bağlam penceresi gereksiz yere şişer ve her token için para ödersiniz. Veriyi düzgün kürate edip, iyi parçalayıp (chunking), yalnızca gerçekten ilgili parçaları getirdiğinizde bağlam penceresini 3 ila 5 kat küçültebilirsiniz. Daha küçük bağlam demek, daha az giriş token'ı, daha az maliyet ve çoğu zaman daha isabetli yanıt demek. Yani veri hijyeni hem cebe hem kaliteye yarar.

Model routing'i ayrı bir başlık olarak vurgulamak istiyorum çünkü tek başına en yüksek getirili uygulama katmanı tekniklerinden biri. Fikir basit ama etkisi büyük: her isteği, o işi yeterli kalitede yapabilecek en ucuz modele gönderin.

Gerçek trafiğe baktığınızda isteklerin çok büyük bir kısmı aslında basit. "Bu cümleyi düzelt", "şu tarihi biçimlendir", "kısa bir özet çıkar" gibi işler için en pahalı, en büyük modeli çağırmak paranızı sokağa atmaktır. Bu işleri küçük ve ucuz bir model gayet iyi yapar. Buna karşılık karmaşık akıl yürütme, çok adımlı analiz ya da hassas üretim gerektiren istekler için büyük modeli saklarsınız.

Routing katmanı gelen isteği sınıflandırır ve doğru modele yönlendirir. Bu sınıflandırma kural tabanlı olabilir (belirli görev tipleri belirli modellere), bir sınıflandırıcı modelle yapılabilir, ya da kademeli (cascade) bir yaklaşım olabilir: önce ucuz model dener, yeterli güven yoksa büyük modele yükseltir. Sahada gördüğüm en iyi sonuçlar bu kademeli yaklaşımdan geliyor çünkü hem çoğu isteği ucuz katmanda tutuyor hem de zor işleri kaçırmıyor.

Routing'in bedeli, yönlendirme mantığını kurmak ve kaliteyi sürekli izlemektir. Yanlış yönlendirme kaliteyi düşürür; bu yüzden routing'i devreye aldığınızda mutlaka bir değerlendirme (eval) setiyle her modelin çıktısını izlemenizi öneriyorum. Ama bu ek yükü göze aldığınızda, routing çoğu kurumun en büyük ve en sürdürülebilir tasarruf kalemi oluyor.

Model katmanından kuantizasyonu ve sistem katmanından batching'i ayrı ayrı anlattım ama bunları birlikte kurgulamanın özel bir gücü var, özellikle kendi altyapınızı işletiyorsanız.

Kuantizasyon modeli küçültür ve hızlandırır; bu, aynı GPU'ya daha fazla eşzamanlı isteği sığdırabilmeniz anlamına gelir. Sürekli batching ve PagedAttention ise bu eşzamanlı istekleri verimli biçimde çalıştırır. İkisi bir araya geldiğinde GPU başına düşen iş hacmi katlanır. Yani kuantizasyonun sağladığı ~3 kat throughput ile batching'in sağladığı yüksek kullanım oranı çarpım etkisi yaratır; sonuçta istek başına donanım maliyetiniz belirgin biçimde düşer.

Burada dikkat edilmesi gereken şey şu: bu kazanç yalnızca kendi modelini barındıran ekipler için doğrudandır. API kullanıyorsanız sağlayıcı zaten bu optimizasyonları arka planda yapıyor ve size sabit bir token fiyatı sunuyor. O zaman sizin kaldıracınız model seçimi, routing ve caching üzerinden çalışır; batching ve kuantizasyon sizin elinizde değildir. Bu ayrım, altyapı kararınızı verirken çok önemli.

Şimdi belki de en çok ihmal edilen ama en belirleyici konuya geliyorum: gözlemlenebilirlik (observability). Sahada gördüğüm acı gerçek şu ki birçok kurum aylık koca bir LLM faturası ödüyor ama bu paranın hangi kullanıcıya, hangi özelliğe, hangi modele gittiğini bilmiyor. Toplam rakamı görüyor, kırılımı görmüyor. Böyle bir durumda optimizasyon körlemesine ilerler; neyi keseceğinizi bilemezsiniz.

Sağlam bir LLMOps kurulumunda şu granülerlikte ölçüm isterim:

• Token kullanımı ve maliyet dağıtımı, kullanıcı bazında, özellik bazında ve model bazında. Yani "bu ay X kullanıcısı Y özelliğinde Z modelini ne kadar kullandı ve ne kadara mal oldu" sorusunu yanıtlayabilmelisiniz.
• Gecikme kırılımı, boru hattının bileşenlerine göre: prompt oluşturma, çıkarımın kendisi ve son işleme (post-processing) ayrı ayrı ölçülmeli. Gecikmenin nerede biriktiğini görmezseniz yanlış yeri optimize edersiniz.

Bu ölçümler olmadan yaptığınız her optimizasyon bir tahmine dayanır. Bu ölçümlerle ise en pahalı özelliği, en savurgan kullanıcıyı, en gereksiz büyük model çağrısını tek tek görür ve önceliklendirirsiniz.

Olgun bir LLMOps disiplini bundan da ileri gider. Her yanıt sürümünü uçtan uca izlenebilir kılar; yani ürettiğiniz her çıktının hangi veriye, hangi prompt'a, hangi modele, hangi parametrelere, hangi değerlendirme (eval) setine, hangi sürüme (release) bağlı olduğunu, buna ek olarak gözlemlenebilirlik, maliyet ve hesap verebilirlik bilgisini bir arada tutar. Bunu şöyle özetliyorum:

"

Olgunluk, bir yanıtın maliyetini geriye doğru izleyip onu üreten prompt'a, modele ve karara bağlayabilmektir. Maliyeti bir kişiye, bir özelliğe, bir karara bağlayamıyorsanız, onu yönetemiyorsunuz demektir.

Bu izlenebilirlik hem maliyeti hem de kaliteyi yönetmenin ortak temelidir. Bir optimizasyon yaptığınızda (diyelim ki bir özelliği daha küçük bir modele taşıdınız) hem maliyetin düştüğünü hem de kalitenin bozulmadığını aynı gözlem altyapısı üzerinden doğrularsınız. Ölçüm olmadan optimizasyon, karanlıkta atış yapmaktır.

Şimdi tüm bunları uygulanabilir bir sıraya koyalım. Bir kuruma girdiğimde çıkarım maliyetini düşürmek için genellikle şu sırayı izliyorum. Bu sıra bilinçli; en hızlı ve en risksiz kazançları öne, en çok emek isteyenleri arkaya koyar.

1. Adım — Ölç ve görünür kıl. Hiçbir şey yapmadan önce gözlemlenebilirliği kurun. Token kullanımını ve maliyeti kullanıcı, özellik ve model bazında kırın. Gecikmeyi bileşenlerine ayırın. En pahalı üç özelliği ve en çok token yakan üç akışı tespit edin. Elinizde net bir harita olmadan optimize etmeyin.

2. Adım — Bağlamı temizleyin. En hızlı kazanç genellikle bağlam şişkinliğini gidermektir. Prompt'larınızı gözden geçirin, gereksiz talimatları, tekrarları ve alakasız doküman parçalarını atın. RAG kullanıyorsanız veri hijyenini düzeltin; bağlam penceresini 3–5 kat küçültmek çoğu zaman mümkün ve doğrudan faturaya yansır.

3. Adım — Caching ekleyin. Sabit ön ekler için prompt caching, tekrar eden sorular için semantik caching kurun. Semantik cache'in benzerlik eşiğini kendi trafiğinizle test ederek ayarlayın. Bu adım tipik olarak günler içinde ölçülebilir tasarruf getirir.

4. Adım — Routing kurun. İsteklerinizi sınıflandırın ve basit işleri ucuz modellere, zor işleri pahalı modele yönlendirin. Mümkünse kademeli (cascade) yaklaşımı kullanın: önce ucuz dener, gerekince yükseltir. Her modelin çıktısını eval setiyle izleyin ki kaliteden ödün vermeyin.

5. Adım — Modeli hafifletin. Yüksek hacimli ve iyi tanımlı görevler için kuantizasyonu değerlendirin; ~3 kat throughput ciddi bir kazanç. Gerekiyorsa budama ve damıtmayı dar görevlerde deneyin. Her hafifletilmiş modeli mutlaka doğrulama setiyle karşılaştırıp kalite kaybını ölçün.

6. Adım — Altyapıyı optimize edin. Kendi modelinizi barındırıyorsanız sürekli batching, PagedAttention ve spekülatif kod çözme ile GPU kullanımını yukarı çekin. vLLM gibi modern bir servis katmanı bu tekniklerin çoğunu hazır sunar.

7. Adım — Yönetişimi kurun. Bütçe alarmları, kullanıcı/özellik bazında maliyet tavanları ve düzenli maliyet gözden geçirme ritmi oturtun. Optimizasyon bir kerelik iş değildir; trafik değiştikçe, yeni özellikler geldikçe faturanın kırılımı değişir ve yeniden ayar gerekir.

Bu adımları sırayla uyguladığınızda, her adım bir öncekinin üzerine tasarruf ekler. Ve başta söylediğim çarpan etkisi burada devreye girer: temiz bağlam, üzerine caching, üzerine routing, üzerine hafif model, üzerine verimli altyapı üst üste geldiğinde toplam çıkarım maliyetinde %80 ve üzeri düşüş gerçekçi bir sonuç olur.

Bu oyun planını Türkiye'de uygularken göz önünde tutmanız gereken birkaç yerel gerçek var; bunları müşterilerimle her zaman ayrıca konuşuyorum.

Kur riski gerçek ve doğrudan. API fiyatları dolar cinsinden. Yani sizin geliriniz TL iken maliyetiniz dövize endeksli. Kur her yükseldiğinde, hiçbir şey değişmese bile TL cinsinden çıkarım faturanız artar. Bu, çıkarım maliyetini düşürmeyi Türkiye'de sadece bir verimlilik meselesi değil, aynı zamanda bir kur riski yönetimi meselesi yapıyor. Token tüketimini azaltan her teknik (caching, routing, bağlam temizliği) aynı zamanda dövize maruz kalmanızı azaltır. Bu yüzden bütçelemeyi TL değil, aylık token tüketimi ve buna karşılık gelen dolar maliyeti üzerinden yapmanızı, kuru ayrı bir değişken olarak izlemenizi öneriyorum.

Self-hosting ile API arasındaki ödünleşme. Kendi modelinizi barındırmak size sistem katmanı optimizasyonlarının tam kontrolünü verir (batching, kuantizasyon, PagedAttention) ve token başına dış ödeme yerine sabit bir donanım maliyetine geçirir. Ama karşılığında altyapı işletme yükü, uzmanlık ihtiyacı ve başlangıç yatırımı gelir. API ise sıfır işletme yüküyle başlar ama token başına ödersiniz ve dövize bağımlısınız. Genel önerim şu: düşük ve değişken hacimde API ile başlayın; hacim büyüyüp öngörülebilir hale geldiğinde ve birim maliyet kritikleştiğinde self-hosting'in matematiği anlam kazanır. Karar noktasını duygusal değil, gözlemlenebilirlik verinizle net biçimde belirleyin.

KVKK ve veri ikametgahı, bazen kararı sizin yerinize verir. Türkiye'de kişisel veri işliyorsanız KVKK yükümlülükleri ve veri ikametgahı (data residency) gereksinimleri devreye girer. Bazı sektörlerde ve bazı veri tiplerinde verinin yurt dışındaki bir API sağlayıcısına gönderilmesi hukuki ya da kurumsal açıdan kabul edilemez. Bu durumda self-hosting bir maliyet optimizasyonu tercihi olmaktan çıkar, bir uyum zorunluluğu haline gelir. İyi haber şu ki, uyum için zaten kendi altyapınızı kuruyorsanız, sistem katmanı optimizasyonları da otomatik olarak elinizin altına geçer; kuantizasyon ve batching ile bu zorunlu altyapıyı aynı zamanda ekonomik hale getirebilirsiniz.

Maliyet dağıtımı ve bütçeleme yaklaşımı. Türkiye'de kurumların çoğunda yapay zeka bütçesi henüz ayrı bir kalem olarak oturmamış durumda. Benim önerdiğim yaklaşım şu: her yapay zeka özelliğini bir maliyet merkezi gibi ele alın. Gözlemlenebilirlik altyapınızdan gelen kullanıcı/özellik/model bazlı token verisini alın, bunu dolar maliyetine, dolar maliyetini de güncel kurla TL'ye çevirin. Böylece her özelliğin size aylık gerçek maliyetini görürsünüz. Sonra bunun karşılığında o özelliğin ürettiği değeri (zaman tasarrufu, dönüşüm, memnuniyet) koyun. Bu tabloyu görünce hangi özelliği optimize edeceğiniz, hangisini büyüteceğiniz, hangisini kapatacağınız kendiliğinden netleşir. Maliyeti bir değere bağlamadan yönetmek, körlemesine kesinti yapmakla aynı şeydir ve genelde yanlış yeri keser.

Son olarak pratik bir hatırlatma: bu oyun planındaki her adım, ölçümle başlayıp ölçümle biter. Türkiye'nin kur oynaklığı ve düzenleyici çerçevesi göz önüne alındığında, çıkarım maliyetini yönetmek tek seferlik bir proje değil, süregelen bir disiplindir. Gözlemlenebilirliği bir kez kurun, üç katmanı sırayla optimize edin, yönetişimi oturtun ve trafiğiniz değiştikçe döngüyü tekrarlayın. Bu döngüyü kuran kurumlar, yapay zekayı hem teknik hem ekonomik olarak sürdürülebilir biçimde ölçekleyebiliyor; kurmayanlar ise güzel pilotları rafta çürütüyor.