Yapay Zeka Uygulamasında Token Bütçesi Nasıl Planlanır?

Yapay zeka uygulamalarında token bütçesi; LLM API maliyetlerini optimize etmek için bağlam penceresi, girdi-çıktı oranları ve model seçimi parametreleriyle planlanır.

Yapay zeka sistemlerini bir fikir prototipinden canlı üretim (production) ortamına taşırken karşılaşılan en kritik operasyonel bariyer, öngörülemeyen altyapı maliyetleridir. Büyük Dil Modelleri (LLM) ile çalışan kurumsal yazılımlarda kârlılığı korumak, doğrudan doğruya token tüketiminin matematiksel ve mimari düzeyde kontrol edilmesine bağlıdır. Teknik yöneticiler, ürün sahipleri ve girişimciler için Yapay Zeka Uygulamasında Token Bütçesi Nasıl Planlanır? sorusunun yanıtı; yalnızca API birim fiyatlarını çarpmaktan ibaret değildir; prompt mühendisliği, model hiyerarşisi, anlamsal önbellekleme (semantic caching) ve telemetri mekanizmalarının entegre bir FinOps disipliniyle kurgulanmasını gerektirir. Bu rehber, token bütçeleme sürecini temel dinamiklerinden kurumsal simülasyon senaryolarına kadar tüm hatlarıyla incelemektedir.

1. Token Kavramı, Fiyatlandırma Mimarisi ve Finansal Riskler

Büyük dil modellerinde hesaplama birimi karakter veya kelime değil, "token" adı verilen anlamsal parçacıklardır. Modeller metni doğrudan okuyamaz; metin önce tokenizer algoritması (çoğunlukla Byte-Pair Encoding - BPE tabanlı) tarafından sayısal vektörlere dönüştürülür. İngilizce metinlerde ortalama 1 token yaklaşık 0.75 kelimeye (veya 4 karaktere) denk gelirken, Türkçe gibi eklemeli (agglutinative) dillerde morfolojik yapı sebebiyle aynı ifade 1.5 ila 2.5 kat daha fazla token tüketebilmektedir. Örneğin, İngilizce "I am going to the office" cümlesi 6 token üretirken, Türkçe "Ofisime gidiyorum" ifadesi kök ve eklerin parçalanması sonucunda 4 ila 6 token arasında işlenebilmektedir. Bu durum, yerelleştirilmiş veya çok dilli kurumsal projelerde bütçe hesaplamalarının doğrudan dil katsayısıyla çarpılmasını zorunlu kılar.

Token tüketimini optimize etmek için OpenAI tarafından geliştirilen açık kaynaklı tiktoken gibi kütüphanelerle geliştirme aşamasında kesin ölçümler yapılmalıdır. cl100k_base veya o200k_base gibi sözlük (vocabulary) kodlamalarında, modellerin kelime dağarcığı genişledikçe token başına düşen karakter verimliliği artar. Geliştiricilerin üretim ortamına kod göndermeden önce kullanıcı girdilerini bu kütüphaneler aracılığıyla tokenize ederek harcanacak muhtemel token miktarını milisaniyeler içinde hesaplaması, beklenmedik faturaların önüne geçen ilk savunma hattıdır.

Kontrolsüz Token Tüketiminin Finansal Etkisi ve Birim Maliyet Analizi

Kurumsal yapay zeka projelerinde en sık karşılaşılan finansal tuzak, "kullanıcı başına sabit maliyet" yanılgısıdır. Geleneksel SaaS mimarilerinde bir kullanıcının sisteme yüklediği marjinal maliyet ihmal edilebilir düzeydeyken, LLM destekli sistemlerde marjinal maliyet doğrudan kullanıcının sorgu karmaşıklığına, bağlam boyutuna ve sistemle girdiği etkileşim sıklığına bağlı olarak katlanarak artar. Kontrolsüz bir sohbet robotunda döngüye giren bir ajan (AI Agent), tek bir oturumda şirkete onlarca dolarlık API faturası çıkarabilir.

Yukarıdaki formülde görüldüğü üzere toplam harcama, her bir API çağrısının girdi ve çıktı hacimlerinin ilgili birim fiyatlarla ($P_{\text{input}}$ ve $P_{\text{output}}$) çarpımının toplamıdır. Şirketler için birim ekonomi (unit economics) analizi yapılırken "Müşteri Başına Aylık Token Maliyeti" (Cost per Active User - CPAU) metriği tanımlanmalıdır. Eğer bir SaaS platformu kullanıcıdan aylık 20$ abonelik ücreti alıyor ve ortalama bir kullanıcı ayda 15$ değerinde token tüketiyorsa; sunucu, bakım, personel ve müşteri kazanım maliyetleri (CAC) eklendiğinde bu ürün operasyonel olarak zarardadır.

+-----------------------------------------------------------------------------------+
|               KURUMSAL TOKEN MALİYET DAĞILIMI VE RİSK ANALİZİ                     |
+--------------------------+---------------------+----------------------------------+
| Bileşen                  | Ortalama Maliyet %  | Temel Risk Faktörü               |
+--------------------------+---------------------+----------------------------------+
| Girdi (Input Context)    | %40 - %55           | Şişirilmiş System Prompt & RAG   |
| Çıktı (Output Tokens)    | %35 - %45           | Sınırlandırılmamış Yanıtlar      |
| Embedding Modelleri      | %5 - %10            | Gereksiz Vektörleştirme          |
| İnce Ayar (Fine-Tuning)  | %5 - %15            | Verimsiz Eğitim Kümeleri         |
+--------------------------+---------------------+----------------------------------+

2. Token Bütçesi Planlamasında Temel Parametreler

Token bütçesi hazırlarken göz önünde bulundurulması gereken en temel dinamik, API sağlayıcılarının (OpenAI, Anthropic, Google Cloud Vertex AI, AWS Bedrock vb.) uyguladığı asimetrik fiyatlandırma politikasıdır. Üretken yapay zeka modelleri çıktıyı üretirken her yeni token için önceki tüm girdileri ve o ana kadar üretilen çıktıları otoregresif (autoregressive) olarak yeniden işlemek zorundadır. Bu donanımsal hesaplama yükü nedeniyle çıktı tokenlarının birim fiyatı, girdi tokenlarına oranla genellikle 3 ila 4 kat daha pahalıdır.

Bütçe modellerken, girdi tokenlarını azaltmak amacıyla sistem promptlarını aşırı kırpmak yerine; çıktının formatını sıkı kurallarla sınırlandırmak finansal açıdan çok daha yüksek getiri sağlar. JSON şeması zorunluluğu getirmek, gereksiz nezaket ve dolgu cümlelerini yasaklamak ve max_tokens parametresini katı bir üst sınıra bağlamak, pahalı çıktı token tüketimini anında kontrol altına alır.

+-----------------------------------------------------------------------------------+
|               MODEL TİPİNE GÖRE YAKLAŞIK MALİYET KARŞILAŞTIRMASI                  |
+--------------------+-----------------------+---------------------+----------------+
| Model Seviyesi     | Girdi Fiyatı (1M Tok) | Çıktı Fiyatı (1M Tok)| Tipik Kullanım|
+--------------------+-----------------------+---------------------+----------------+
| Amiral Gemisi (LLM)| $2.50 - $15.00        | $10.00 - $60.00     | Derin Muhakeme |
| Hafif Sıklet (SLM) | $0.15 - $0.60         | $0.60 - $2.40       | Sınıflandırma  |
| Açık Kaynak (Self) | Donanım/vLLM Amort.   | Donanım/vLLM Amort. | Yüksek Hacim   |
+--------------------+-----------------------+---------------------+----------------+

Bağlam Penceresi (Context Window) ve Bellek Yönetimi

Modern modeller 128k, 1M ve hatta 2M token gibi devasa bağlam pencereleri sunmaktadır. Ancak bağlam penceresinin geniş olması, her sorguda bu alanın tamamen doldurulması gerektiği anlamına gelmez. Bağlam penceresi büyüdükçe iki temel sorun ortaya çıkar:

1. Doğrusal Maliyet Artışı: Her API çağrısında geçmiş sohbet geçmişi (conversation history) modele tekrar tekrar gönderilirse, $N$. adımdaki bir sorgunun maliyeti $O(N)$ karmaşıklığında katlanarak artar.

2. Dikkat Kaybı (Lost in the Middle): Modeller devasa metin bloklarının ortasında kalan talimatları gözden kaçırma eğilimindedir. Bu durum çıktı kalitesini düşürür ve hatalı çıktıların yeniden üretilmesi için ilave token harcanmasına yol açar.

Bellek yönetiminde "Kayar Pencere" (Sliding Window) ve "Kademeli Özetleme" (Hierarchical Summarization) stratejileri uygulanmalıdır. Kullanıcının önceki 20 mesajını ham metin olarak taşımak yerine, yalnızca son 3 mesaj tam metin olarak korunmalı; daha eski mesajlar ise ucuz bir model aracılığıyla 100 tokenlık bir özet haline getirilerek sistem promptuna enjekte edilmelidir.

3. Token Optimizasyonu İçin İleri Düzey Mimariler

Üretim seviyesindeki kurumsal yapay zeka sistemlerinde token bütçesini kontrol etmenin yolu, yalnızca prompt kısaltmaktan değil, mimari düzeyde optimizasyon katmanları inşa etmekten geçer. Bu katmanların en başında Retrieval-Augmented Generation (RAG) mimarisinin doğru kurgulanması gelir.

Klasik bir yanılgı, tüm kurumsal dokümanı bağlam penceresine yüklemektir. Oysa gelişmiş RAG sistemlerinde metinler mantıksal parçalara (chunks) bölünür, vektör veritabanlarında (Pinecone, Qdrant, Milvus, pgvector) saklanır ve yalnızca kullanıcının sorusuyla anlamsal olarak en yüksek benzerliğe (cosine similarity $\ge 0.82$) sahip olan ilk 3-5 parça modele beslenir. Ayrıca araya eklenecek bir Re-ranking (yeniden sıralama) modeli (örneğin Cohere Rerank veya BGE-Reranker), alakasız parçaları eleyerek girdi token hacmini %60 ila %80 oranında düşürür.

+-----------------------------------------------------------------------------------+
|               RAG VE CACHE OPTİMİZASYON AKIŞ ŞEMASI                               |
+-----------------------------------------------------------------------------------+
| [Kullanıcı Sorgusu]                                                               |
|        │                                                                          |
|        ▼                                                                          |
| [Semantic Cache (Redis / GPTCache)] ── (Benzerlik > 0.95) ──► [Anında Yanıt $0]   |
|        │ (Cache Miss)                                                             |
|        ▼                                                                          |
| [Vektör Veritabanı Arama] ──► Top 20 Chunks (Ham Veri)                            |
|        │                                                                          |
|        ▼                                                                          |
| [Re-Ranker Modeli] ────────► Top 3 En Alakalı Chunk (Filtrelenmiş)                |
|        │                                                                          |
|        ▼                                                                          |
| [System Prompt Sıkıştırma] ─► Modele İletilen Minimal Token                       |
|        │                                                                          |
|        ▼                                                                          |
| [LLM Yanıt Üretimi] ────────► Kullanıcıya Teslim & Cache'e Yazma                  |
+-----------------------------------------------------------------------------------+

Anlamsal Önbelleğe Alma (Semantic Caching) ile Maliyetleri Sıfırlama

Geleneksel web önbellekleri anahtar-değer (key-value) eşleşmesiyle çalışır; sorgudaki tek bir harf değiştiğinde önbellek ıskalanır (cache miss). Yapay zeka uygulamalarında ise Redis veya açık kaynaklı GPTCache gibi araçlar kullanılarak Semantic Caching altyapısı kurulmalıdır.

Kullanıcı "Şifremi nasıl sıfırlarım?" diye sorduğunda üretilen yanıt önbelleğe alınır. Bir sonraki kullanıcı "Parolamı unuttum, ne yapmalıyım?" yazdığında, embedding modeli iki cümlenin anlamsal yakınlığını tespit eder. Eğer yakınlık belirlenen eşik değerin (ör. 0.96) üzerindeyse, LLM API'sine hiç çağrı yapılmadan doğrudan önbellekteki yanıt döndürülür. Bu yöntem, özellikle müşteri destek botlarında API maliyetlerini anında %30 ila %50 oranında sıfırlar.

4. Maliyet Güvenliği, Rate Limiting ve Operasyonel Risk Yönetimi

Kurumsal bir yapay zeka uygulamasında token bütçesinin planlanması kadar, bu bütçenin operasyonel risklere karşı korunması da şarttır. Kamuya açık veya çok kullanıcılı sistemlerde en büyük tehditlerden biri "Prompt Injection" veya "Denial of Wallet" (DoW) saldırılarıdır. Kötü niyetli bir kullanıcı, modele sonsuz döngüye girecek talimatlar verebilir veya bağlam penceresini anlamsız metinlerle doldurarak şirketin API kotalarını dakikalar içinde tüketebilir.

Bu riskleri bertaraf etmek için uygulama katmanında katı Rate Limiting ve bütçe tavanı politikaları uygulanmalıdır:

• Kullanıcı Başına Kota: Her kullanıcı veya API anahtarı için dakikalık, saatlik ve günlük maksimum token tüketim sınırları (Token Bucket algoritması) tanımlanmalıdır.

• Maksimum Çıktı Sınırı (max_tokens): Model çağrılarında bu parametre asla boş bırakılmamalı, uygulamanın amacına göre (ör. sınıflandırma için 50, özet için 300 token) sınırlandırılmalıdır.

• Otomatik Devre Kesiciler (Circuit Breakers): Aylık belirlenen bütçenin %80'ine ulaşıldığında teknik ekibe uyarı gönderilmeli; %100'e ulaşıldığında sistem otomatik olarak amiral gemisi modelden yedek SLM modeline veya statik hata mesajına geçiş yapmalıdır.

+-----------------------------------------------------------------------------------+
|              KURUMSAL GÜVENLİK VE BÜTÇE KORUMA MATRİSİ                            |
+----------------------+-----------------------------+------------------------------+
| Güvenlik Katmanı     | Uygulama Yöntemi            | Finansal Risk Engelleme      |
+----------------------+-----------------------------+------------------------------+
| Web Application FW   | IP ve Oturum Başı İstek Lim.| DDOS / Bot Kaynaklı Maliyet  |
| Token Gatekeeper     | Girdi Karakter/Token Kontrol| DoW (Denial of Wallet)       |
| PII / KVKK Maskeleme | Yerel Regex / NER Filtresi  | Veri Sızıntısı & Cezai Risk  |
| Human-in-the-Loop    | Kritik Çıktı Onay Mekanizması| Halüsinasyon Kaynaklı Tazminat|
+----------------------+-----------------------------+------------------------------+

Veri Gizliliği, KVKK/GDPR ve İnsan Denetimi (Human-in-the-Loop)

Token iletiminde veri gizliliği doğrudan maliyet ve yasal sorumlulukla bağlantılıdır. Genel amaçlı halka açık API'lere gönderilen her veri parçacığı, yasal düzenlemeler kapsamında risk doğurabilir. Müşteri kimlik bilgileri, kredi kartı verileri veya sağlık kayıtları genel bulut modellerine doğrudan gönderilmemelidir. Girdi tokenları modele iletilmeden önce yerel bir veri maskeleme katmanından (Presidio vb.) geçirilerek anonimleştirilmeli; böylece hem regülasyon uyumu sağlanmalı hem de gereksiz veri transferi engellenmelidir.

Bunun yanı sıra, doğrudan işlem yapan yapay zeka ajanlarında İnsan Denetimi (Human-in-the-Loop - HITL) mekanizması bulunmalıdır. Yüksek maliyetli veya geri döndürülemez işlemler (veritabanı silme, toplu e-posta gönderimi, finansal mutabakat) öncesinde modelin ürettiği işlem özeti bir insan operatörün onayına sunulmalıdır. Bu yaklaşım, modelin halüsinasyon görerek gereksiz yüzlerce alt görevi tetiklemesini ve bütçeyi tüketmesini önler.

5. Token Bütçeleme Simülasyonu ve Kurumsal Senaryolar

Token bütçesi planlarken varsayımlar üzerinden değil, matematiksel simülasyon modelleri üzerinden hareket edilmelidir. Bir kurumsal destek asistanı senaryosunu ele alalım:

• Aktif Kullanıcı Sayısı (DAU): Günlük 2.500 kullanıcı

• Kullanıcı Başına Günlük Oturum: 1.5 oturum

• Oturum Başına Mesaj Sayısı: 4 soru - 4 cevap (Toplam 8 etkileşim)

• Ortalama Girdi Boyutu: 450 token (Sistem promptu + RAG bağlamı + kullanıcı sorusu)

• Ortalama Çıktı Boyutu: 150 token

• Aylık Çalışma Günü: 30 gün

Bu parametrelerle aylık toplam hacim hesaplandığında:

Aşağıdaki tabloda, bu simülasyonun farklı model mimarilerindeki aylık maliyet karşılığı gösterilmektedir:

+-----------------------------------------------------------------------------------+
|               AYLIK MALİYET SİMÜLASYON KARŞILAŞTIRMASI                            |
+-------------------------+--------------------+--------------------+---------------+
| Mimari Tercihi          | Girdi Maliyeti ($) | Çıktı Maliyeti ($) | Toplam ($/Ay) |
+-------------------------+--------------------+--------------------+---------------+
| Tam Amiral Gemisi (LLM) | $506.25 (@$2.50/M) | $675.00 (@$10.00/M)| $1,181.25     |
| Hibrit (Router + SLM)   | $101.25            | $162.00            | $263.25       |
| Hibrit + %40 Cache      | $60.75             | $97.20             | $157.95       |
+-------------------------+--------------------+--------------------+---------------+

Görüldüğü üzere, mimariyi amiral gemisi modelden hibrit bir yapıya geçirip üzerine Semantic Caching katmanı eklemek, aylık faturayı 1.181,25$ seviyesinden 157,95$'a düşürerek %86'nın üzerinde net tasarruf sağlamaktadır. Bu fark, uygulama ölçeklendikçe şirketin birim kârlılığını belirleyen temel unsurdur.

Fine-Tuning (İnce Ayar) ve RAG Arasındaki Maliyet Kırılımı

Sıkça düşülen bir diğer hata, token maliyetlerini düşürmek için hemen Fine-Tuning (ince ayar) yoluna gitmektir. Fine-tuning, modelin belirli bir çıktı formatını veya üslubunu öğrenmesi için mükemmeldir; ancak bilgi tabanı güncellemek için pahalı bir yöntemdir.

• RAG Yaklaşımı: Kurulum maliyeti düşüktür, ancak her sorguda doküman parçacıkları gönderildiği için girdi token maliyeti süreklidir.

• Fine-Tuning Yaklaşımı: Başlangıçta eğitim verisi hazırlama ve eğitim çalıştırma (training run) maliyeti yüksektir. Ancak sistem promptundaki uzun örnekleri (few-shot examples) ortadan kaldırdığı için girdi token hacmini kalıcı olarak düşürür.

Eğer sistem promptunuzda modeli eğitmek için her çağrıda 2.000 tokenlık örnek taşıyorsanız ve ayda milyonlarca istek alıyorsanız; küçük bir modeli fine-tune etmek, uzun vadede RAG tabanlı girdi maliyetinden çok daha kârlı hale gelecektir.