TokenOps: LLM Maliyetlerini FinOps Disipliniyle Yönetmek (2026)

TL;DR — 2026'da LLM projelerinin en sessiz ama en acımasız problemi, faturanın kontrolden çıkması. Ben sahada bunu defalarca gördüm: harika bir demo, mutlu bir yönetim, sonra ilk ciddi kullanım ayında gelen dolar bazlı fatura ve donan yüzler. TokenOps, FinOps prensiplerini (görünürlük, tahsis, optimizasyon) doğrudan token tüketimine uygulamaktır. Token'ı sıkı yönetilen bir kaynak gibi ele alır; prefill ve decode maliyetlerini tek tek ürün özelliklerine bağlarsınız. Semantik önbellekleme tekrar eden sorguların yaklaşık %31'ini API'ye hiç gitmeden eler, üretimde LLM çağrılarını %30–60 azaltabilir. Model kademelendirme ile basit sorguları ucuz modellere yönlendirmek (RouteLLM'de %85'e varan tasarruf) ve FinOps yaklaşımıyla tipik %38–68 maliyet düşüşü mümkün. Bu yazıda prefill/decode farkını, beş maliyet katmanını, chargeback/showback'i, bütçe ve alarmları, gözlemlenebilirlik araçlarını ve Türkiye'ye özgü (TL bütçe planlaması, USD'li API'ler, self-hosted için KVKV) pratikleri anlatıyorum.

Bir itirafla başlayayım. Birkaç yıl önce, danışmanlık yaptığım bir kurumda ekiple birlikte gerçekten güzel bir müşteri destek asistanı çıkardık. Demo günü herkes ayaktaydı. Modelin verdiği cevaplar akıcıydı, ürün ekibi mutluydu, üst yönetim "hemen canlıya alalım" dedi. Ben o gün bir şeyi söylemekte tereddüt ettim, sonradan pişman oldum: "Peki bunun aylık maliyetini kim, hangi metrikle takip edecek?" Sonuç malum. İlk ay fatura beklenenin birkaç katı geldi. Kimse şaşırmasın diye söylüyorum: sorun modelde değildi, bizim token'ı bir kaynak olarak hiç ciddiye almamamızdaydı. İşte o günden sonra ben LLM projelerine bakışımı değiştirdim ve bugün "TokenOps" dediğim disiplini her projenin ilk gününden itibaren masaya koyuyorum.

Bu yazıyı, geçmişte benim yaptığım hataları sizin yapmamanız için yazıyorum. İçinde teori de var, sahadan pratik de. Amacım, LLM faturasını "ay sonunda gelen sürpriz" olmaktan çıkarıp, tıpkı bulut maliyetleri gibi öngörülebilir, tahsis edilebilir ve optimize edilebilir bir kaleme dönüştürmeniz.

TokenOps'u tek cümleyle tanımlarsak: FinOps prensiplerini özel olarak LLM token tüketimine uygulamaktır. FinOps dünyasından üç temel kavramı ödünç alır ve bunları token bağlamına taşır: görünürlük (visibility), tahsis (allocation) ve optimizasyon (optimization).

Bunu neden bu kadar önemsiyorum? Çünkü çoğu ekip token'ı "bedava bir teknik detay" gibi görüyor. Oysa token, bulut projelerindeki CPU saati ya da GB depolama gibi, ölçülebilir ve ücretli bir kaynaktır. TokenOps'un özü şudur: token'ı sıkı yönetilen bir kaynak olarak ele almak ve granüler telemetri ile prefill ve decode çıkarım maliyetlerini belirli ürün özelliklerine atfetmek.

"Belirli ürün özelliklerine atfetmek" kısmının altını özellikle çiziyorum. Çünkü sahada gördüğüm en büyük eksik burada. Ekipler toplam faturayı görüyor ama "bu 100 bin liranın 40 bini hangi özellikten geldi?" sorusuna cevap veremiyor. Oysa gerçek kontrol, ancak her token harcamasını bir özelliğe, bir ekibe, hatta bir müşteri segmentine bağladığınızda başlar. Bunu yapamıyorsanız, optimize edeceğiniz yeri de bilemezsiniz; körlemesine kesinti yaparsınız ve genellikle yanlış yeri kesersiniz.

FinOps'un bulut dünyasında yaptığı devrimi hatırlayın. Bir zamanlar sunucu maliyetleri IT bütçesinin dibinde kaybolan tek bir kalemdi. FinOps geldi, her kuruşu bir ekibe, bir servise, bir ortama bağladı ve mühendisleri maliyetin sahibi yaptı. TokenOps, aynı kültürel dönüşümü LLM dünyasına taşıyor. Fark şu: LLM'de birim maliyet çok daha oynak, kullanım çok daha ani sıçrayabilir ve bir "retry" ya da bir "agent döngüsü" faturayı bir gecede ikiye katlayabilir.

Maliyeti yönetebilmek için önce onu doğru okumanız gerekir. LLM çıkarımı iki ayrı aşamadan oluşur ve bu ikisinin maliyet davranışı birbirinden çok farklıdır. Bunu anlamadan optimize etmeye çalışmak, motorun içini bilmeden yakıt tüketimini düşürmeye çalışmak gibidir.

Prefill (ön dolum) aşaması: Modelin sizin gönderdiğiniz girdiyi (prompt) okuduğu, işlediği aşamadır. Sistem prompt'unuz, konuşma geçmişiniz, RAG ile eklediğiniz bağlam, kullanıcının sorusu... hepsi burada işlenir. Prefill, paralel işlenebildiği için token başına genellikle daha ucuzdur ama girdi ne kadar uzunsa o kadar çok "input token" ödersiniz.

Decode (çözme/üretim) aşaması: Modelin cevabı token token ürettiği aşamadır. Bu aşama doğası gereği sıralıdır; her yeni token bir öncekine bağlıdır. Bu yüzden decode, token başına genellikle daha pahalıdır ve "output token" olarak faturalanır. Çoğu sağlayıcıda output token fiyatı, input token fiyatının birkaç katıdır.

Bu ayrımı bilmek neden hayat kurtarır? Çünkü optimizasyon stratejiniz tamamen buna göre şekillenir. Eğer maliyetinizin büyük kısmı prefill'den geliyorsa (uzun sistem prompt'ları, şişik RAG bağlamı, birikmiş konuşma geçmişi), önbellekleme ve bağlam budama işe yarar. Eğer maliyetiniz decode'dan geliyorsa (uzun, gereksiz detaylı cevaplar), o zaman çıktı uzunluğunu sınırlamak, modelden daha öz cevap istemek ana kaldıraçtır.

Ben müşterilerime hep şunu söylüyorum: faturanızı prefill/decode kırılımıyla göremiyorsanız, aslında hiçbir şey göremiyorsunuz demektir. Modern gözlemlenebilirlik araçları bu kırılımı size verir; bu yüzden bir sonraki bölüm çok kritik.

Sahada yüzlerce LLM iş akışını incelerken şunu fark ettim: token faturası her zaman aynı beş katmandan besleniyor. Bir faturayı kontrol altına almak istiyorsanız, bu beş katmanı tek tek masaya yatırmanız gerekir.

1. Sistem prompt'ları. Her isteğe eklenen o uzun talimat metni. "Sen yardımsever bir asistansın, şu kurallara uy, şu formatta cevap ver..." Kulağa masum geliyor ama unutmayın: bu metin her istekte yeniden prefill edilir. Günde yüz binlerce istek atan bir sistemde 800 token'lık bir sistem prompt'u, tek başına devasa bir maliyet kalemi olur. Ben birçok projede sadece sistem prompt'unu sadeleştirerek ciddi tasarruf sağladım.

2. Bağlam ve hafıza (context/memory). Konuşma geçmişi, RAG'den gelen dokümanlar, kullanıcı profili, önceki adımların çıktıları... Bunların hepsi bağlam penceresine yüklenir ve her turda tekrar tekrar işlenir. Özellikle uzun konuşmalarda hafıza katmanı sinsice büyür. "Neden faturamız her hafta artıyor?" sorusunun cevabı çoğu zaman burada gizlidir.

3. Model seçimi. Aynı işi gören iki model arasında token başına maliyet 10-20 kat farklı olabilir. En güçlü modeli her işe koşmak, çiviyi balyozla çakmaktır. Katman katman model seçimi (model tiering) bu yüzden en güçlü kaldıraçlardan biridir; birazdan ayrı bölümde ele alacağım.

4. Çıktı uzunluğu. Decode pahalıdır demiştik. Modelin gereksiz uzun, tekrar eden, "kibar dolgu" içeren cevaplar üretmesi doğrudan faturaya yansır. Çıktıyı sınırlamak (max_tokens), modelden özlü olmasını istemek ve gereksiz açıklamaları kesmek çoğu zaman göz ardı edilen kolay bir kazançtır.

5. Retry (yeniden deneme) yükü. İşte en sinsi katman bu. Bir istek başarısız olduğunda otomatik yeniden denenir; timeout, rate limit, geçersiz JSON çıktısı derken aynı pahalı prefill defalarca ödenir. Agent mimarilerinde bu durum katlanarak büyür.

Bu konuya ayrı bir başlık açıyorum çünkü 2026'nın en büyük maliyet tuzağı burada. Herkes "agentic AI" diyor, ajanlar birbirini çağırıyor, araçlar kullanıyor, kendi çıktısını kontrol ediyor. Muhteşem yetenekler, evet. Ama maliyet açısından bir tehlike var.

Basit bir soru-cevap uygulamasında bir kullanıcı sorusu bir LLM çağrısına denk gelir. Ama bir agent mimarisinde tek bir kullanıcı isteği; planlama çağrısı, birkaç araç çağrısı, her araç sonucunun yeniden değerlendirilmesi, bir öz-eleştiri (self-critique) turu ve nihai cevap üretimi olarak onlarca LLM çağrısına dönüşebilir. Üstelik her turda önceki tüm bağlam yeniden prefill edilir. Yani bağlam büyüdükçe her adım daha pahalı hale gelir. On adımlık bir agent zinciri, doğrusal değil, neredeyse üstel bir maliyet eğrisi çizebilir.

Retry'lar bu tabloyu daha da kötüleştirir. Model geçersiz bir JSON döndürdüğünde sisteminiz "tekrar dene" der ve o pahalı, uzun bağlamı bir kez daha gönderir. Üç deneme, üç kat prefill maliyeti demektir. Ben sahada, retry mantığı yanlış kurulmuş bir sistemin, gerçek trafiğin sadece iki katı kadar "hayalet trafik" ürettiğini gördüm. Kimse fark etmemişti, çünkü kimse retry'ları ayrı bir metrik olarak izlemiyordu.

Buradan çıkaracağınız ders şu: agent ve retry mimarilerinde her ekstra çağrının bir maliyeti vardır ve bu maliyet toplam telemetride görünür olmalıdır. "Kaç kullanıcı isteği geldi" değil, "kaç LLM çağrısı yapıldı ve bunların kaçı retry'dı" sorusunu sormalısınız.

FinOps'un birinci kuralı: göremediğinizi yönetemezsiniz. LLM dünyasında bu kural daha da acımasız işliyor. İyi haber şu ki 2026 itibarıyla bu alanda olgun bir araç ekosistemi var. Ben projelerde genellikle şu kategorilerden en az birini kuruyorum:

LLM ağ geçidi proxy'leri — Portkey ve Helicone. Bu araçlar, uygulamanızla model sağlayıcısı arasına bir proxy olarak girer ve her isteğe maliyet takibi enjekte eder. Tek bir satır yapılandırmayla, her isteğin kaç token harcadığını, hangi modele gittiğini, ne kadara mal olduğunu görürsünüz. Ağ geçidi mimarisinin güzelliği, uygulama kodunuzu neredeyse hiç değiştirmeden merkezi görünürlük ve kontrol sağlamasıdır.

Açık kaynak LLM tracing — Langfuse ve Traceloop. Eğer izlerin (trace) sizde kalmasını istiyorsanız, açık kaynak çözümler devreye girer. Langfuse ve Traceloop, her çağrıyı iz düzeyinde kaydeder, maliyet atfını (cost attribution) yapar ve bir agent zincirinin hangi adımının ne kadar tükettiğini gösterir. Türkiye'deki veri hassasiyeti olan kurumlar için bu "kendi altyapımızda tutabiliyoruz" özelliği çoğu zaman belirleyici oluyor.

Kurumsal maliyet izleme — Datadog LLM Observability. Zaten Datadog kullanan büyük kurumlar için, LLM gözlemlenebilirliğini mevcut izleme yığınına entegre etmek çok mantıklı. Datadog LLM Observability, kurumsal ölçekte maliyet izleme sunar ve LLM metriklerini uygulamanın geri kalan sağlık metrikleriyle aynı ekranda birleştirir.

Hangisini seçeceğiniz bağlamınıza bağlı. Küçük ve hızlı başlangıç için bir ağ geçidi proxy'si; veri egemenliği önemliyse açık kaynak tracing; zaten büyük bir gözlemlenebilirlik yatırımınız varsa kurumsal çözüm. Ama seçim ne olursa olsun ilke aynı: her isteğin maliyetini, modelini, gecikmesini ve token kırılımını görebilmelisiniz. Bunu göremeyen bir ekip, gözü kapalı araba kullanıyor demektir.

Şimdi gelin en sevdiğim optimizasyon tekniğine. Semantik önbelleklemeyi (semantic caching) neden bu kadar seviyorum? Çünkü hem maliyeti düşürüyor hem de gecikmeyi azaltıyor; yani hem cebinizi hem kullanıcı deneyiminizi aynı anda iyileştiriyor.

Mantığı şu: klasik önbellek birebir aynı metni arar. Ama kullanıcılar aynı şeyi yüzlerce farklı şekilde sorar. "İade politikanız nedir?", "Ürünü nasıl iade ederim?", "Parayı geri alabilir miyim?" — üçü de aynı cevabı ister ama karakter karakter farklıdır, klasik önbellek üçünü de "yeni soru" sanır. Semantik önbellekleme ise vektör benzerliği kullanır. Soruyu bir embedding'e çevirir, daha önce sorulmuş anlamca eşdeğer sorularla karşılaştırır ve yeterince yakınsa önbellekteki cevabı döndürür — API'ye hiç gitmeden.

Rakamlar iddialı değil, gerçekçi ve etkileyici: semantik önbellekleme, herhangi bir API çağrısı yapılmadan tekrar eden sorguların yaklaşık %31'ini eler. Üretim ortamında ise LLM çağrılarını %30–60 oranında azaltabilir. Bir düşünün: faturanızın yarısı, birbirinin anlamca aynısı olan sorulardan geliyor olabilir ve siz aynı cevabı defalarca satın alıyorsunuz. Semantik önbellek bu israfı doğrudan durdurur.

Sahadan bir not: semantik önbellekte "benzerlik eşiği" (similarity threshold) ayarı hayati. Eşiği çok gevşek tutarsanız, aslında farklı olan iki soruya aynı cevabı verirsiniz ve kalite düşer. Çok sıkı tutarsanız önbellek nadiren isabet eder ve tasarruf kaybolur. Ben bu eşiği her zaman gerçek trafikle kalibre ederim, asla varsayılan değerde bırakmam. Ayrıca dinamik, kişiye özel cevapların (örneğin "benim siparişim nerede") önbelleğe girmemesi için mutlaka bir muafiyet mantığı kurarım.

İkinci en güçlü kaldıraç, doğru işi doğru modele vermektir. Buna model kademelendirme (model tiering) ya da yönlendirme (routing) diyoruz. Fikir basit ama etkisi büyük: her sorgu en güçlü ve en pahalı modeli hak etmez.

Kullanıcı "merhaba" dediğinde ya da basit bir sınıflandırma yaptığınızda, en üst düzey modeli çalıştırmak resmen para yakmaktır. Bunun yerine bir yönlendirici (router), sorgunun karmaşıklığını değerlendirir ve basit olanları ucuz, hızlı bir modele; karmaşık olanları güçlü modele gönderir. Kullanıcı farkı çoğu zaman hissetmez bile, ama fatura ciddi biçimde düşer.

Rakamlar burada da konuşuyor: RouteLLM gibi yönlendirme yaklaşımları maliyette %85'e varan tasarruf sağlayabiliyor. Daha geniş ölçekte, LLM için FinOps yaklaşımları tipik olarak %38–68 arasında maliyet düşüşü getiriyor. Bu bir "belki" değil, sahada tekrar tekrar doğrulanmış bir aralık.

Ben model kademelendirmeyi kurarken şu adımları izliyorum. Önce mevcut trafiği analiz edip sorguları karmaşıklık seviyelerine göre ayırıyorum. Sonra her seviye için "yeterince iyi" olan en ucuz modeli belirliyorum. Ardından bir yönlendirme katmanı kuruyorum — bu bazen basit kurallar, bazen küçük bir sınıflandırıcı model oluyor. En kritik adım ise kalite ölçümü: yönlendirmeden sonra kalitenin düşmediğini gerçek metriklerle doğrulamadan bu değişikliği asla canlıya almam. Çünkü maliyeti düşürüp kaliteyi bozarsanız, kimseye bir faydanız olmaz.

Teknik optimizasyon tek başına yeterli değil. FinOps'un kalbinde kültürel bir dönüşüm yatar: maliyeti mühendislerin ve ekiplerin sahiplenmesi. Bunun iki temel mekanizması var: showback ve chargeback.

Showback (gösterim): Her ekibe, her ürün özelliğine ait token maliyetini şeffaf biçimde raporlarsınız ama bütçelerinden düşmezsiniz. Amaç farkındalık yaratmaktır. "A ekibinin özelliği geçen ay 60 bin TL token harcadı" cümlesini gördüğünde, o ekip aniden prompt'larını sadeleştirmeye başlar. İnsan doğası: görünür olan iyileşir.

Chargeback (geri yükleme): Bir adım öteye gidip, bu maliyetleri fiilen ilgili ekibin ya da departmanın bütçesine yansıtırsınız. Bu, maliyeti gerçek bir sorumluluğa dönüştürür. Chargeback'in ön koşulu, sağlam bir maliyet atfıdır — yani her token'ı doğru sahibine bağlayabilmektir. Bu yüzden başta anlattığım "granüler telemetri" olmadan chargeback yapamazsınız.

Ben genellikle kurumlara önce showback ile başlamalarını öneririm. Chargeback güçlü bir araç ama erken uygulanırsa ekipler savunmaya geçer, inovasyondan çekinir. Önce şeffaflık kültürünü oturtun, ekipler kendi tüketimlerini görsün, sonra kademeli olarak bütçe sorumluluğuna geçin. Bu, insani ve sürdürülebilir bir yol.

FinOps'un vazgeçilmezi bütçeler ve alarmlardır. LLM dünyasında bunlar hayat kurtarır çünkü buradaki maliyet, bulut kaynaklarından bile daha ani sıçrayabilir. Kötü bir kod dağıtımı, sonsuz bir agent döngüsü ya da bir kötüye kullanım senaryosu, faturayı saatler içinde uçurabilir.

Benim her projede kurduğum katmanlı alarm yapısı şöyle. Öncelikle her ürün özelliği ve ekip için aylık token bütçesi belirlerim. Sonra bu bütçenin %50, %80 ve %100'üne gelindiğinde tetiklenen kademeli uyarılar kurarım. %100'de sadece uyarı değil, mümkünse otomatik bir fren mekanizması (rate limiting ya da daha ucuz modele düşürme) devreye girer. Ayrıca "anomali tespiti" eklerim: normal günlük tüketimin belirgin biçimde üzerine çıkıldığında anında bildirim gider. Bu sayede ay sonunu beklemeden, sorun büyümeden müdahale ederiz.

Şunu özellikle vurgulamak isterim: alarm kurmak yetmez, alarma kimin cevap vereceğini de baştan belirlemek gerekir. Sahipsiz alarm, susturulan alarmdır. Her bütçe uyarısının bir sahibi olmalı ve bu kişi harekete geçme yetkisine sahip olmalı.

Şimdi Türkiye'de çalışan bir profesyonel olarak, bu konunun bizim coğrafyaya özgü tarafına gelmek istiyorum. Çünkü global kaynaklar bu boyutu hiç konuşmuyor ama bizim için hayati.

TL bütçe, USD maliyet ikilemi. LLM API'lerinin neredeyse tamamı dolar bazlı fiyatlanıyor. Sizin bütçeniz ise TL. Bu, kur oynaklığının doğrudan maliyet oynaklığına dönüşmesi demek. Yıllık bir bütçe planı yaparken sabit bir kur varsaymak, sizi yıl ortasında açıkta bırakabilir. Ben müşterilerime, LLM maliyet planlamasında mutlaka bir kur tamponu bırakmalarını öneriyorum. Token bazında sabit görünen bir maliyet bile, TL karşılığında yıl içinde ciddi biçimde artabilir. Bu yüzden token optimizasyonu, Türkiye'de sadece bir mühendislik konusu değil, bir kur riski yönetimi konusudur. Token tüketimini %40 düşürdüğünüzde, kur artışının etkisini de büyük ölçüde emmiş olursunuz.

Bütçeyi token cinsinden düşünmek. Bir tavsiyem: bütçenizi sadece TL cinsinden değil, aynı zamanda "aylık token" cinsinden de planlayın. Token bütçesi kur oynaklığından bağımsızdır; böylece mühendislik ekibi, kurun ne olacağından bağımsız net bir hedefe (ör. "istek başına ortalama token'ı şu seviyenin altında tut") kilitlenebilir. Finans ekibi TL/USD tarafını yönetirken, mühendislik token tarafını yönetir. Bu ayrım çok işe yarıyor.

KVKK ve self-hosted senaryosu. Veri hassasiyeti yüksek sektörlerde (finans, sağlık, kamu) verinin yurt dışındaki bir API'ye gönderilmesi başlı başına bir KVKK meselesi. Bu kurumlar giderek daha çok self-hosted (kendi altyapısında barındırılan) açık modellere yöneliyor. Burada maliyet denklemi değişiyor: artık token başına API ücreti ödemiyorsunuz ama GPU altyapısı, elektrik, bakım ve mühendislik maliyeti üstleniyorsunuz. TokenOps disiplini burada da geçerli — sadece "maliyet" artık token fiyatı değil, GPU kullanım verimliliği oluyor. Self-hosted bir modelde de görünürlük, tahsis ve optimizasyon aynen geçerlidir; sadece metrikler değişir. KVKK uyumu için verinin nerede işlendiğini, nerede saklandığını ve semantik önbelleğe alınan içeriğin kişisel veri içerip içermediğini mutlaka denetlemek gerekir. Önbelleğe kişisel veri koyuyorsanız, o önbellek de KVKK kapsamındadır; bunu atlamayın.

Sahada uyguladığım taktikleri, etki seviyeleriyle birlikte bir tabloda topladım. Bu tabloyu bir kontrol listesi gibi kullanabilirsiniz. "Yüksek" etki, doğru uygulandığında ciddi ve ölçülebilir tasarruf demek; "orta" hızlı kazançlar; "düşük" ise küçük ama birikince anlamlı iyileştirmeler.

Taktik	Ne yapar	Uygulama zorluğu	Etki seviyesi
Semantik önbellekleme	Anlamca eşdeğer sorguları API'ye gitmeden yanıtlar (%30–60 çağrı azaltımı)	Orta	Yüksek
Model kademelendirme / yönlendirme	Basit sorguları ucuz modele yönlendirir (%85'e varan tasarruf)	Orta	Yüksek
Sistem prompt'unu sadeleştirme	Her istekte tekrar eden prefill yükünü azaltır	Düşük	Orta
Bağlam/hafıza budama	Konuşma geçmişini ve RAG bağlamını gerektiği kadar tutar	Orta	Yüksek
Çıktı uzunluğu sınırlama (max_tokens)	Pahalı decode maliyetini kontrol altına alır	Düşük	Orta
Retry mantığını optimize etme	Gereksiz yeniden denemeleri ve hayalet trafiği keser	Orta	Orta
Prompt caching (sağlayıcı önbelleği)	Sabit prefill bloklarını sağlayıcı düzeyinde önbelleğe alır	Düşük	Orta
Gözlemlenebilirlik kurulumu	Her token'ı görünür ve atfedilebilir kılar (optimizasyonun ön koşulu)	Orta	Yüksek
Bütçe ve alarmlar	Sürprizi ve kaçak harcamayı erken yakalar	Düşük	Yüksek
Chargeback / showback	Maliyeti ekiplere sahiplendirir, davranışı değiştirir	Orta	Yüksek
Batch/asenkron işleme	Aciliyeti düşük işleri indirimli toplu API ile yapar	Orta	Orta
Embedding ve çıktı yeniden kullanımı	Aynı hesaplamayı tekrar satın almayı engeller	Düşük	Düşük

Bu tablodaki taktikleri tek seferde değil, kademeli uygulamanızı öneririm. Ben genellikle önce gözlemlenebilirlikle başlarım (çünkü ölçmeden iyileştiremezsiniz), sonra en yüksek etkili iki kaldıraca (semantik önbellek ve model kademelendirme) geçerim, ardından prompt ve bağlam optimizasyonlarıyla ince ayar yaparım.

Teoriyi bir tarafa bırakıp, "yarın sabah ne yapayım" sorusuna cevap vereyim. Sahada işe yaradığını gördüğüm, kabaca 30 günlük bir başlangıç planı paylaşıyorum.

İlk hafta — görünürlük. Bir gözlemlenebilirlik katmanı kurun. Ağ geçidi proxy'si (Portkey/Helicone) ya da açık kaynak tracing (Langfuse/Traceloop) fark etmez, ama her isteğin maliyetini, modelini ve token kırılımını görebilir hale gelin. Bu hafta hiçbir şeyi optimize etmeyin, sadece ölçün. Çoğu ekip bu hafta sonunda "vay, en çok parayı bu özellik yiyormuş" diye şaşırır. O şaşkınlık, işin başlangıcıdır.

İkinci hafta — atıf ve tablo. Topladığınız veriyi ürün özelliklerine ve ekiplere göre kırın. Prefill/decode ayrımını çıkarın. En çok harcayan üç özelliği belirleyin. Bu, tüm optimizasyon çabanızı nereye odaklayacağınızı söyler. Aynı zamanda ilk showback raporunuzu hazırlayın; ekiplere kendi tüketimlerini gösterin.

Üçüncü hafta — yüksek etkili kaldıraçlar. En çok harcayan özelliklere semantik önbellekleme ve model kademelendirme uygulayın. Önce en büyük kalemi hedefleyin; Pareto ilkesi burada fazlasıyla geçerli, harcamanın büyük kısmı genellikle birkaç özellikten gelir. Her değişikliğin kaliteyi bozmadığını gerçek metriklerle doğrulayın.

Dördüncü hafta — kontrol ve süreklilik. Bütçeleri ve alarmları kurun. Her özellik için token bütçesi belirleyin, kademeli uyarılar tanımlayın. Retry mantığınızı gözden geçirin, hayalet trafiği kesin. Ve en önemlisi: bu süreci tek seferlik bir proje değil, sürekli bir disiplin haline getirin. TokenOps bir "kurulup unutulan" şey değildir; tıpkı FinOps gibi, sürekli gözden geçirme ve iyileştirme ister.

Bitirirken, sahada en sık gördüğüm hataları paylaşmak istiyorum; çünkü bunları bilmek, size aylar kazandırabilir.

Birincisi, önce optimize etmeye çalışmak. Ölçmeden kesinti yapan ekipler neredeyse her zaman yanlış yeri keser; kaliteyi bozar, tasarrufu da yakalayamaz. Önce görünürlük, sonra optimizasyon. Bu sıra tartışmasız.

İkincisi, retry ve agent maliyetini görmezden gelmek. Kullanıcı isteği sayısına bakıp "trafiğimiz az" diyen, ama gerçek LLM çağrısı sayısını hiç izlemeyen çok ekip gördüm. Hayalet trafik en pahalı trafiktir çünkü kimse ondan haberdar değildir.

Üçüncüsü, semantik önbelleği kalibre etmeden açmak. Yanlış eşikle kurulmuş bir önbellek, kullanıcıya alakasız cevaplar döndürür ve güveni zedeler. Tasarruf uğruna kaliteyi feda etmeyin; ikisi birlikte kazanılabilir.

Dördüncüsü, kültürü ihmal etmek. En iyi teknik kurulum bile, mühendisler maliyeti sahiplenmezse zamanla erir. Showback ile başlayın, farkındalık yaratın, sonra sorumluluğu kademeli verin.

Ve Türkiye özelinde beşinci bir hata: kur riskini token stratejisinden ayrı düşünmek. Sizin en güçlü kur kalkanınız, aslında token verimliliğinizdir. Tüketimi düşürdüğünüzde, dolar bazlı fiyatın ve kurun etkisini aynı anda azaltmış olursunuz.

TokenOps, 2026'da LLM projelerini "cool demo" olmaktan çıkarıp sürdürülebilir, öngörülebilir ürünlere dönüştüren disiplindir. Token'ı sıkı yönetilen bir kaynak olarak görün; her harcamayı bir özelliğe bağlayın; görünürlük, tahsis ve optimizasyon üçlüsünü kurun. Bunu yaparsanız, benim yıllar önce yaşadığım o "fatura şoku" sizin başınıza hiç gelmez. Gelirse de, artık nereye bakacağınızı ve neyi çevireceğinizi tam olarak bilirsiniz. Sahadan en samimi tavsiyem bu: ölçün, atfedin, optimize edin ve bu döngüyü asla durdurmayın.