AI FinOps: Üretimde LLM Token Maliyetini Kaliteyi Bozmadan Kontrol Etmek

TL;DR — Yıllardır kurumlarda yapay zeka projeleri yürütürken en çok şu soruyla karşılaşıyorum: "Demo harika çalışıyor da, bu iş üretime çıkınca faturaya ne olacak?" İşte bu yazının konusu tam olarak bu: AI FinOps, yani üretimdeki büyük dil modeli (LLM) uygulamalarında token maliyetlerini kaliteyi öldürmeden kontrol altına almak. Size sahadan öğrendiğim üç ana kaldıracı — token optimizasyonu, model yönlendirme ve semantik önbellekleme — anlatacağım; maliyeti neden LLMOps dünyasında birinci sınıf bir metrik olarak ele almanız gerektiğini gösterecek; ve Türkiye'ye özgü boyutları — TL oynaklığı, self-hosted ile API arasındaki denge, KVKK/BDDK veri yerleşimi — masaya yatıracağım.

Geleneksel makine öğrenmesi projelerinde maliyet eğrisi tanıdıktı: Ağır maliyet modeli eğitmekteydi. Büyük bir GPU kümesinde günlerce, haftalarca eğitim yapardınız, model bir kez hazır olduğunda ise çıkarım (inference) görece ucuzdu. Yani "bir kez öde, uzun süre kullan" mantığı hakimdi.

LLMOps bu ekonomiyi tam tersine çevirdi. Çünkü çoğu şirket artık kendi temel modelini sıfırdan eğitmiyor; hazır bir modeli API üzerinden ya da self-hosted olarak kullanıyor. Eğitim maliyeti — sizin açınızdan — neredeyse sıfır. Ama asıl yük, sürekli devam eden çıkarım maliyetinde. Her istek token bazında ölçülüyor, her token para. Uygulama ne kadar çok kullanılırsa, fatura o kadar büyüyor.

Bu, benim için çok önemli bir zihniyet değişimi. MLOps'ta maliyet çoğunlukla proje başında bir kez düşünülen bir kalemdi. LLMOps'ta ise maliyet, üretim boyunca her gün, her saat nefes alan canlı bir metrik. Kullanıcı sayınız arttıkça, prompt'larınız uzadıkça, model seçiminiz ağırlaştıkça fatura da büyüyor. Yani başarı — daha fazla kullanım — aynı zamanda daha fazla maliyet demek. Bu paradoksu yönetmek, işte AI FinOps'un kalbi.

Pazarın kendisi de bu gerçeği yansıtıyor. LLMOps pazarı 2024'te yaklaşık 1,97 milyar dolar seviyesindeyken, 2028'e doğru yaklaşık 4,9 milyar dolara ulaşması bekleniyor; bu, kabaca yıllık yüzde 42 bileşik büyüme demek. Bu rakamlar bana şunu söylüyor: LLM'leri üretime taşımak ve orada verimli işletmek, önümüzdeki yılların en büyük operasyonel disiplinlerinden biri olacak. Ve bu disiplinin merkezinde maliyet var.

MLOps dünyasında bir modeli değerlendirirken konuştuğumuz metrikler doğruluk, kesinlik, geri çağırma, gecikme gibi şeylerdi. Maliyet vardı ama çoğu zaman ikinci plandaydı; altyapı ekibinin bir yerde takip ettiği bir kalem. LLMOps'ta bu değişti. Maliyet, artık doğruluk ve gecikme kadar merkezi bir metrik.

Neden? Çünkü LLM maliyeti doğrudan kullanım hacmiyle ölçekleniyor ve kolayca kontrolden çıkabiliyor. Bir mühendis, kaliteyi biraz artırmak için prompt'a birkaç örnek daha ekler; kimse fark etmez ama her istekte fazladan yüzlerce token yakılır. Bir başka mühendis, "ne olur ne olmaz" diye en güçlü ve en pahalı modeli varsayılan yapar; basit sorular için bile o pahalı model çalışır. Bunlar tek tek masum görünen kararlar, ama üretim ölçeğinde çarpıldığında faturayı katlar.

İşte bu yüzden AI FinOps'ta maliyeti birinci sınıf metrik olarak ele almanız gerekiyor. Yani her dashboard'da doğruluk ve gecikmenin yanında token tüketimi ve dolar maliyeti de yer almalı. Ekipler bir özellik geliştirirken "bu ne kadar kaliteli" sorusunun yanında "bu istek başına ne kadara mal oluyor" sorusunu da sormalı. Maliyet görünmez olduğunda kontrol edilemez; görünür olduğunda ise şaşırtıcı derecede hızlı optimize edilebilir.

Sahada gördüğüm ilk ve en hızlı kazanç token optimizasyonundan geliyor. Deneyimlerime göre, dikkatli bir token optimizasyonu tipik olarak API maliyetinin yüzde 30 ila 50'sini kurtarabiliyor. Bu, hiçbir kalite kaybı olmadan, sadece israfı temizleyerek elde edilen bir kazanç.

Peki token nerede israf ediliyor? En yaygın yerler şunlar:

• Şişkin sistem prompt'ları: Aynı uzun talimat, her istekte baştan gönderiliyor. Çoğu zaman bu talimatın yarısı gereksiz tekrar veya asla tetiklenmeyen kenar durum açıklamaları.
• Gereksiz bağlam: Uygulama, ihtiyaç olmayan belgeleri veya konuşma geçmişini modele yığıyor. Model her seferinde bunları okuyor ve her okunan token faturaya yazılıyor.
• Aşırı örnek (few-shot) kullanımı: Prompt'a on örnek koymak üç örnekten daha iyi sonuç vermiyorsa, o yedi fazladan örnek saf israf.
• Kontrolsüz çıktı uzunluğu: Modele "kısa yanıt ver" demediğinizde uzun uzun konuşuyor; çıktı token'ları da girdi kadar para.

Ben token optimizasyonuna hep "prompt hijyeni" diyorum. Tıpkı kodu refactor eder gibi, prompt'larınızı düzenli olarak gözden geçirip gereksiz kısımları budamak gerekiyor. Bağlam penceresi kullanımını ölçmek burada anahtar: Bir isteğin bağlam penceresinin ne kadarını doldurduğunu görmezseniz, nerede israf ettiğinizi de bilemezsiniz. AI FinOps'ta "bağlam penceresi kullanımı" ve "prompt verimliliği" tam da bu yüzden ölçülmesi gereken metrikler.

İkinci büyük kaldıraç, akıllı model yönlendirme. Mantık son derece basit ama etkisi çarpıcı: Her isteği aynı pahalı modele göndermek yerine, isteğin zorluğuna göre uygun modeli seçin. Basit sorular ucuz ve hızlı modele, karmaşık akıl yürütme gerektiren sorular güçlü ve pahalı modele gitsin.

Düşünün: Kullanıcıların çoğu isteği aslında basit. "Şu bilgiyi özetle", "bu metni düzelt", "şu sınıfa ait mi" gibi işler için en güçlü modeli çalıştırmak, tıpkı ekmek almak için lüks bir spor araba kiralamak gibi. Oysa gerçekten zor bir işi — çok adımlı akıl yürütme, karmaşık kod üretimi, incelikli analiz — güçlü modele yönlendirirsiniz. Böylece pahalı modeli sadece gerçekten hak eden istekler için harcarsınız.

Bu yaklaşımın ölçülebilir tasarruf getirdiğini defalarca gördüm. İşin güzelliği, doğru kurulduğunda kaliteden feragat etmemesi; çünkü basit istekler ucuz modelde de gayet iyi yanıtlanıyor, zor istekler ise hâlâ güçlü modele gidiyor. Yani hem faturayı düşürüyor hem de kaliteyi koruyorsunuz.

Yönlendirmeyi kurarken dikkat edilecek nokta, sınıflandırma katmanının kendisinin de maliyet ve gecikme eklemesi. Bir isteği "basit mi zor mu" diye sınıflandırmak için ağır bir model kullanırsanız, tasarrufunuzu o katmanda yakarsınız. Bu yüzden yönlendirme kararı ya çok hafif bir modelle ya da kural tabanlı bir mantıkla verilmeli. Ben genellikle önce basit kurallarla (istek uzunluğu, anahtar kelimeler, görev türü) başlamayı, sonra gerekirse hafif bir sınıflandırıcıya geçmeyi öneriyorum.

Üçüncü kaldıraç, yüksek hacimli sistemlerde belki de en güçlüsü: semantik önbellekleme. Klasik önbellekleme birebir aynı isteği hatırlar; semantik önbellekleme ise anlamca benzer istekleri tanır. Yani kullanıcı "İstanbul'da hava nasıl" ile "İstanbul hava durumu ne" dediğinde, sistem bunların aynı şeyi sorduğunu anlayıp önceden hesaplanmış yanıtı döndürebilir.

Etkisi çarpıcı: Yüksek hacimli sistemlerde semantik önbellekleme, çıkarım maliyetini yaklaşık yüzde 40 ila 73 oranında düşürebiliyor. Bu geniş aralık, sistemin tekrar oranına bağlı. Aynı ya da benzer soruların sık sık tekrarlandığı uygulamalarda — müşteri hizmetleri, sıkça sorulan sorular, ürün destek botları — önbellek isabet oranı çok yüksek olur ve tasarruf üst banda yaklaşır.

Semantik önbelleklemenin bir başka güzelliği, sadece maliyeti değil gecikmeyi de düşürmesi. Önbellekten dönen bir yanıt, modele gitmediği için milisaniyeler içinde teslim edilir. Yani hem daha ucuz hem daha hızlı. Ama dikkatli olunması gereken bir nokta var: Önbelleğin bayatlaması. Bilgi değiştiğinde eski yanıtı dönmemek için önbelleğe bir tazelik penceresi (TTL) koymak ve neyin önbelleklenebilir olduğuna dikkatle karar vermek gerekiyor. Kişiye özel, anlık veya sürekli değişen yanıtları önbelleklemek tehlikeli olabilir.

Şimdi bütün bu kaldıraçların altında yatan temele geliyorum: görünürlük. Optimize edemezsiniz eğer ölçemiyorsanız. Bu yüzden üretime çıkan her ciddi LLM uygulamasının granüler token ve maliyet atıfına ihtiyacı var.

Ne demek granüler atıf? Şu sorulara anlık yanıt verebilmek demek:

• Kullanıcı başına maliyet: Hangi kullanıcı ne kadar token yakıyor? Bir "power user" mı faturayı şişiriyor, yoksa maliyet tabana yayılmış mı?
• Özellik başına maliyet: Hangi ürün özelliği en pahalı? Belki nadiren kullanılan bir özellik, en çok token tüketen özellik.
• Model başına maliyet: Hangi model ne kadar harcıyor? Yönlendirme doğru çalışıyor mu, yoksa pahalı model gereğinden fazla mı devrede?
• Boru hattı aşaması başına gecikme: İsteğin süresi nerede geçiyor? Prompt oluşturma, çıkarım, son işleme aşamalarının her birinin gecikmesini ayrı ayrı görmek gerekiyor.

Bu ayrıştırma olmadan optimizasyon körlemesine olur. "Faturamız yüksek" demek yeterli değil; "faturamızın yüzde 60'ı şu özelliğin şu modeli yüzünden" diyebilmek gerekiyor. İşte o zaman doğru yere müdahale edersiniz. Ben bunu bir kan tahliline benzetiyorum: Genel bir "kendimi kötü hissediyorum" ifadesi tedavi için yeterli değil; hangi değerin bozuk olduğunu görmeniz lazım.

AI FinOps, klasik izleme metriklerinin ötesinde yeni bir metrik seti getiriyor. Ben bunları müşterilerimle konuşurken sık sık gündeme getiriyorum:

• Token hızı (token velocity): Birim zamanda ne kadar token tüketiyorsunuz? Bu, faturanızın gerçek zamanlı nabzı gibi. Ani bir sıçrama, ya bir hata ya da beklenmedik bir kullanım anlamına gelir.
• Bağlam penceresi kullanımı: Ortalama bir istek, bağlam penceresinin ne kadarını dolduruyor? Yüksek kullanım, ya gerçek bir ihtiyaç ya da bir israf sinyali.
• Prompt verimliliği: Çıktının değeri başına ne kadar girdi token'ı harcanıyor? Aynı işi daha az token'la yapabiliyor musunuz?

Bu metrikler, MLOps dünyasında hiç konuşmadığımız şeylerdi. Çünkü orada maliyet, token bazında ve gerçek zamanlı ölçeklenmezdi. LLMOps'ta ise maliyet, mimarinin doğasında olan birinci sınıf bir metrik. Bunu kabul etmek ve dashboard'larınıza yerleştirmek, olgun bir LLMOps pratiğinin işareti.

İyi haber şu: Bütün bu görünürlüğü sıfırdan kurmanıza gerek yok. Modern gözlemlenebilirlik (observability) araçları, OpenAI, Anthropic, Bedrock, LangChain gibi yaygın çağrıları otomatik olarak enstrümante ediyor. Yani kodunuza serpiştireceğiniz birkaç satırla, her LLM çağrısının token sayısını, maliyetini, gecikmesini ve içeriğini otomatik olarak izlemeye başlıyorsunuz.

Bu otomatik enstrümantasyon, AI FinOps'u pratik kılan şey. Çünkü elle her çağrıyı loglamaya kalksanız, hem çok emek harcar hem de tutarsız veri toplarsınız. Otomatik araçlar ise standart, karşılaştırılabilir ve granüler veri sunuyor. Ben bir LLM projesine başlarken gözlemlenebilirliği birinci günden kurmayı öneriyorum; sonradan eklemek her zaman daha zor ve eksik oluyor. "Önce çalıştıralım, sonra ölçeriz" yaklaşımı, üretimde pahalı sürprizlere yol açıyor.

Şimdi yazının bize özgü kısmına geliyorum. Bir Türk şirketi olarak LLM maliyetlerini yönetirken, herkesin yaşamadığı ekstra bir katmanla uğraşıyorsunuz: kur oynaklığı. API maliyetleri neredeyse her zaman dolar bazında faturalanıyor. Geliriniz TL, maliyetiniz dolar olduğunda, kur hareketleri doğrudan kâr marjınıza yansıyor.

Bu, benim müşterilerimle sürekli konuştuğum bir gerçek. Bir LLM uygulamasının birim ekonomisini hesaplarken, sadece "istek başına şu kadar token, şu kadar dolar" demek yetmiyor; o doların TL karşılığının oynaklığını da hesaba katmak gerekiyor. Kur bir anda hareket ettiğinde, dün kârlı olan bir özellik bugün zarar ettirmeye başlayabiliyor. Bu yüzden ben Türk şirketlerine, birim maliyet hesaplarını belirli bir kur tamponu ile yapmayı ve fiyatlamayı buna göre kurgulamayı öneriyorum.

Kur oynaklığı, aslında token optimizasyonunu daha da değerli kılıyor. Çünkü maliyetiniz doğrudan kontrol edemediğiniz bir değişkene (kura) bağlıysa, kontrol edebildiğiniz değişkeni (token tüketimini) sıkı yönetmek hayati önem kazanıyor. Her kurtardığınız token, hem dolar hem de kur riski açısından çift kazanç.

İkinci önemli yerel boyut, self-hosted (kendi altyapınızda barındırma) ile API kullanımı arasındaki denge. Bu, sadece teknik bir tercih değil; maliyet, kur riski ve veri yerleşimi kesişiminde stratejik bir karar.

API tarafının cazibesi belli: Altyapı derdi yok, ölçekleme sağlayıcının işi, başlangıç maliyeti düşük. Ama dolar bazında, token başına ödüyorsunuz ve hacim büyüdükçe fatura da büyüyor. Self-hosted tarafında ise ciddi bir başlangıç yatırımı (GPU altyapısı, uzmanlık) var, ama yüksek ve öngörülebilir hacimlerde birim maliyet düşebiliyor. Üstelik ödemeniz büyük ölçüde TL bazında (donanım amortismanı, elektrik, personel) olduğundan kur riskiniz azalıyor.

Ben bu kararı hacim ve öngörülebilirlik üzerinden veririm. Düşük ve değişken hacimde API neredeyse her zaman mantıklı. Ama yüksek, istikrarlı ve öngörülebilir bir hacme ulaştığınızda, self-hosted seçeneğinin toplam sahip olma maliyetini (TCO) ciddi biçimde hesaplamak gerekiyor. Ayrıca birçok şirket için en akıllısı hibrit bir yaklaşım: hassas ve yüksek hacimli işleri self-hosted, geri kalanı API. Bu, hem maliyeti hem de riski dengeliyor.

Üçüncü yerel boyut, belki de en kritik olanı: veri yerleşimi (data residency). KVKK ve — finans sektöründeyseniz — BDDK düzenlemeleri, kişisel ve hassas verinin nerede işlendiği ve saklandığı konusunda ciddi kısıtlar getiriyor. Bu, doğrudan çıkarımın nerede yapılacağını etkiliyor.

Şöyle düşünün: Bir müşterinizin kişisel verisini içeren bir prompt'u yurt dışındaki bir API'ye gönderdiğinizde, o veri sınırı geçiyor. KVKK açısından yurt dışına veri aktarımının kendine özgü koşulları var; her durumda serbest değil. Finans sektöründe BDDK'nın veri yerleşimi beklentileri daha da sıkı; hassas verinin belirli koşullarda yurt içinde işlenmesi ve saklanması gerekebiliyor.

Bu düzenleyici gerçek, self-hosted seçeneğine yeni bir boyut ekliyor. Bazı durumlarda self-hosted, sırf maliyet için değil, veri yerleşimi zorunluluğu için tercih ediliyor. Yani çıkarımı Türkiye içinde, kendi kontrolünüzdeki altyapıda yapmak, bir maliyet kararı olmaktan çıkıp bir uyum kararına dönüşüyor. Ben bu yüzden AI FinOps'u hiçbir zaman salt bir mühendislik meselesi olarak ele almam; her zaman hukuk ve uyum ekipleriyle birlikte kurgularım. Çünkü "en ucuz çıkarım" ile "hukuka uygun çıkarım" her zaman aynı yerde durmuyor.

Yazının başlığında verdiğim sözü hatırlatayım: kaliteyi öldürmeden. Çünkü maliyet optimizasyonunun en büyük tuzağı, tasarruf uğruna kaliteyi feda etmek. Prompt'ları aşırı budarsanız, model bağlamı kaybeder ve yanlış yanıt verir. Her isteği en ucuz modele yönlendirirseniz, zor sorularda kalite çöker. Her şeyi önbelleklerseniz, bayat ve yanlış yanıtlar dönmeye başlar.

Bu yüzden AI FinOps, kör bir kesinti operasyonu değil; dengeli bir mühendislik disiplini. İşin sırrı, her optimizasyonu kalite metrikleriyle birlikte izlemek. Bir değişiklik yaptığınızda — prompt'u budadınız, modeli değiştirdiniz, önbelleği açtınız — sadece maliyetin düştüğünü değil, kalitenin korunduğunu da doğrulamanız gerekiyor. Ben buna "çift göz" prensibi diyorum: bir göz maliyette, bir göz kalitede. İkisini birlikte izlemezseniz, tasarruf ettiğinizi sanırken aslında müşteri deneyimini erozyona uğratıyor olabilirsiniz.

Pratikte bunu şöyle kuruyorum: Her optimizasyon değişikliğini, üretimin bir bölümünde (örneğin trafiğin küçük bir yüzdesinde) test ederim ve hem maliyet hem kalite metriklerini yan yana izlerim. Kalite düşmeden maliyet düşüyorsa, değişikliği yaygınlaştırırım. Kalite düşüyorsa, geri alırım ya da eşiği ayarlarım. Bu disiplinli döngü, tasarruf ile kalite arasındaki dengeyi korumanın tek sağlam yolu.

Eğer bugün AI FinOps yolculuğuna başlayacak olsanız, size şu sıralamayı öneririm. Önce görünürlük: bir gözlemlenebilirlik aracını devreye alın ve token/maliyet/gecikme verisini granüler biçimde toplamaya başlayın. Ölçmeden hiçbir şey yapmayın; birkaç hafta sadece izleyin ve nerede para yaktığınızı anlayın.

Sonra en büyük israf kaynağına yönelin. Genellikle bu, birkaç şişkin prompt ya da her şeye koşan pahalı bir varsayılan model olur. Prompt hijyeni ile başlayın; en hızlı ve en risksiz kazanç orada. Ardından model yönlendirmeyi kurun; basit istekleri ucuz modele kaydırın. En son, tekrar oranı yüksek yüzeylerde semantik önbelleklemeyi devreye alın. Her adımda kaliteyi izleyin; tasarruf uğruna deneyimi bozmayın.

Ve tüm bu süreç boyunca, yerel gerçekleri unutmayın: birim ekonomiyi kur tamponuyla hesaplayın, veri yerleşimi kısıtlarını hukuk ekibinizle netleştirin, yüksek hacimde self-hosted seçeneğini masada tutun. AI FinOps'u tek seferlik bir tasarruf projesi gibi değil, sürekli işleyen bir disiplin gibi kurun. Çünkü modelleriniz değişecek, fiyatlar değişecek, kullanımınız büyüyecek. Maliyeti birinci sınıf metrik olarak izlemeyi kurumsal alışkanlık haline getirdiğinizde, üretimdeki yapay zeka faturanız artık bir sürpriz değil, yönettiğiniz bir kaldıraç olacak. Ve işin en güzel yanı, iyi kurgulanmış bir AI FinOps pratiği sadece parayı korumaz; sistemi daha hızlı, daha öngörülebilir ve daha dayanıklı hale getirerek ürününüzün kendisini de iyileştirir.

Şimdiye kadar hep dolar cinsinden maliyetten konuştum. Ama sahada bir şey daha öğrendim: gecikme (latency) de bir maliyettir, sadece farklı bir para birimindedir. Kullanıcı bir yanıt için üç saniye beklerse, o bekleme kullanıcı deneyiminden, dolayısıyla dönüşümden ve sadakatten ödediğiniz bir bedeldir. Bu yüzden AI FinOps'ta gecikmeyi doların yanında ikinci bir maliyet ekseni olarak izliyorum.

Gecikmenin nerede biriktiğini anlamak için boru hattını aşamalara ayırmak şart. Bir isteğin toplam süresi genellikle üç ana bölümden oluşur: prompt oluşturma (bağlamın toplanması, belgelerin getirilmesi, şablonun hazırlanması), çıkarım (modelin yanıt üretmesi) ve son işleme (yanıtın ayrıştırılması, doğrulanması, biçimlendirilmesi). Bu üç aşamayı ayrı ayrı ölçmezseniz, "sistem yavaş" der durur ama nedenini bulamazsınız. Çoğu zaman şaşırtıcı biçimde, darboğaz çıkarımda değil, prompt oluşturma aşamasındaki yavaş bir veri getirmede ya da son işlemedeki ağır bir doğrulamada olur.

Gecikme ile maliyet arasında bazen bir gerilim, bazen bir uyum vardır. Örneğin semantik önbellekleme hem maliyeti hem gecikmeyi düşürür; bu bir uyum. Ama daha uzun ve daha zengin bir bağlam bazen kaliteyi artırırken hem maliyeti hem gecikmeyi yükseltir; bu bir gerilim. İşin ustalığı, bu dengeleri her özellik için ayrı ayrı, veriye bakarak kurmakta. Genel bir reçete yok; her uygulamanın kendi profili var.

Gecikme konusunda küçük ama etkili bir taktikten bahsetmeden geçemem: akış (streaming). Model yanıtı token token üretilirken, tamamının bitmesini beklemek yerine üretildikçe kullanıcıya göstermek, algılanan hızı dramatik biçimde artırır. Gerçek toplam süre aynı kalsa bile, kullanıcı ilk kelimeleri hemen gördüğü için sistem çok daha hızlı hissedilir.

Bunu neden AI FinOps bağlamında anıyorum? Çünkü algılanan hız, kaliteyi öldürmeden maliyeti yönetmenin sıkça atlanan bir parçası. Bazen daha ucuz ama biraz daha yavaş bir model, akış sayesinde kullanıcı için kabul edilebilir hale gelir. Yani akış, sizin daha ekonomik seçimler yapabileceğiniz bir alan açar. Kullanıcı deneyimini korurken maliyet esnekliği kazandığınız bir kaldıraç olarak görüyorum bunu.

Teknik kaldıraçlar önemli ama onları sürdürülebilir kılan şey yönetişim. Sahada gördüğüm en yaygın hata, maliyet optimizasyonunu bir kerelik bir "temizlik" projesi gibi ele almak. Ekip bir hafta uğraşır, faturayı düşürür, sonra herkes başka işe döner ve altı ay sonra fatura yine tavan yapmıştır. Çünkü kullanım büyümüş, yeni özellikler eklenmiş, kimse maliyeti izlememiştir.

Bu yüzden ben AI FinOps'u bir yönetişim çerçevesiyle kurgulamayı öneriyorum. Bunun üç ayağı var. Birincisi bütçe: her ekip veya her özellik için bir token/maliyet bütçesi tanımlayın. İkincisi uyarı: bütçe aşıldığında ya da token hızında ani bir sıçrama olduğunda otomatik uyarı kurun. Bir hatalı döngü ya da beklenmedik bir kullanım, siz fark etmeden binlerce dolar yakabilir; uyarılar bu tür felaketleri erken yakalar. Üçüncüsü sahiplik: maliyetin net bir sahibi olsun. "Herkesin işi" olan maliyet, "kimsenin işi" olur.

Bu yönetişim ayrıca kültürel bir boyut taşıyor. Mühendisleri "maliyet bilincine" davet etmek, ama bunu bir korku kültürüne dönüştürmemek gerekir. Ben ekiplere hep şunu söylüyorum: Amaç en ucuz sistemi kurmak değil, en verimli sistemi kurmak. Verimlilik, aynı kaliteyi daha az kaynakla üretmek demek. Bu, mühendisler için aslında tatmin edici bir mühendislik problemi; onu bir kısıtlama gibi değil, bir zeka oyunu gibi sunmak çok daha iyi sonuç veriyor.

Son bir eğilime değinmek istiyorum, çünkü maliyet denklemini önümüzdeki dönemde ciddi biçimde değiştireceğine inanıyorum: küçük ama yetenekli modellerin yükselişi. Bir zamanlar "ne kadar büyük, o kadar iyi" diye düşünürdük. Ama artık belirli görevler için özelleştirilmiş, çok daha küçük modellerin, dev modellere yakın kalitede sonuç verebildiğini görüyoruz. Bu, model yönlendirme stratejisini daha da güçlendiriyor.

Küçük modeller hem daha ucuz hem daha hızlı hem de self-hosted için çok daha uygun. Bir Türk şirketi açısından bu üçlü kazanç: dolar bazlı API maliyetinden kurtulup TL bazlı kendi altyapınızda, düşük gecikmeyle ve veri yerleşimi zorunluluklarını da karşılayarak çalışabilmek. Elbette her görev küçük modele uygun değil; en zor akıl yürütme işleri hâlâ büyük modelleri gerektiriyor. Ama görevlerinizin ne kadar büyük bir kısmının aslında küçük bir modelle çözülebileceğini test etmek, önümüzdeki dönemin en değerli maliyet çalışmalarından biri olacak.

Ben müşterilerime her yeni özellikte şu soruyu sormalarını öneriyorum: "Bu işi yapabilecek en küçük, en ucuz model hangisi?" Varsayılan olarak en güçlü modele uzanmak yerine, en hafif çözümden başlayıp gerektiğinde yukarı tırmanmak, hem maliyet hem mimari açısından çok daha sağlıklı. Buna "aşağıdan yukarı model seçimi" diyorum: minimum yeterli modelden başla, kalite yetmezse büyüt.

Bütün bu anlattıklarımı tek bir çerçevede toplayayım. Üretimdeki bir LLM uygulamasını yönetirken aslında dört köşeli bir dengeyi sürekli kuruyorsunuz: maliyet, kalite, hız ve uyum. Bu dörtgenin herhangi bir köşesini görmezden gelirseniz, diğerleri bozulur. Sadece maliyete odaklanırsanız kalite düşer. Sadece kaliteye odaklanırsanız fatura patlar. Hızı ihmal ederseniz kullanıcı kaçar. Uyumu unutursanız, KVKK ya da BDDK kapınızı çalar.

AI FinOps, işte bu dörtgeni disiplinli biçimde yönetmenin adı. Token optimizasyonu, model yönlendirme ve semantik önbellekleme; bunlar maliyet köşesinin kaldıraçları. Kalite izleme, akış ve boru hattı gözlemlenebilirliği; kalite ve hız köşelerinin araçları. Veri yerleşimi kararları ve self-hosted seçenekleri ise uyum köşesinin dayanakları. Hepsini birlikte, granüler görünürlük üzerinden yönettiğinizde, yapay zeka uygulamanız hem ekonomik hem kaliteli hem hızlı hem de hukuka uygun olur.

Bugün başlayacaksanız, tek bir cümleyle özetleyeyim: önce ölçün, sonra optimize edin, hep dengeyi koruyun ve yerel gerçekleri asla unutmayın. Maliyeti görünmez bir gider olmaktan çıkarıp yönettiğiniz canlı bir metriğe dönüştürdüğünüz gün, üretimdeki yapay zekanız artık sizi geceleri uyandıran bir kaygı değil, güvenle ölçekleyebildiğiniz bir varlık haline gelir. Ve bu dönüşüm, teknik bir beceriden çok bir olgunluk göstergesi; yapay zekayı sadece kurabilen değil, onu sürdürülebilir biçimde işletebilen bir kurum olduğunuzun kanıtı.