Yapay Zekada Token Nedir, Nasıl Hesaplanır?

Yapay zeka modellerinde token, metin tabanlı verilerin matematiksel vektörlere dönüştürülmeden önce ayrıştırıldığı en temel anlamsal yapı birimidir. Doğal dil işleme mimarilerinde kelimeler, heceler, karakter öbekleri ve hatta noktalama işaretleri doğrudan işlenemez; bunun yerine özel algoritmalarla parçalanarak sayısal dizilere dönüştürülür. İşletmeler, yazılım ekipleri ve dijital karar vericiler için token kavramı, yalnızca teknik bir veri birimi olmanın ötesinde doğrudan operasyonel maliyeti, API bütçesini, model gecikme süresini (latency) ve bağlam penceresi (context window) kapasitesini belirleyen kritik bir metriktir. Bu rehberde, büyük dil modellerinde (LLM) token mekanizmasının teknik arka planını, dil farklılıklarının getirdiği maliyet çarpanlarını, API hesaplama formüllerini ve kurumsal bütçe optimizasyon stratejilerini tüm operasyonel boyutlarıyla inceleyeceğiz.

Yapay Zeka Modellerinde Token Kavramının Teknik Çerçevesi

Büyük dil modelleri (LLM), insan dilini metin formatında doğrudan okuyup anlayamaz. Sinir ağları özünde devasa matris çarpımları ve olasılıksal hesaplamalar yürüten matematiksel motorlardır. Bu nedenle, bir kullanıcı sisteme bir prompt girdiğinde, sistem ilk olarak ham metin akışını "token" adı verilen ayrık veri parçalarına böler. Tokenizasyon (tokenization) adı verilen bu işlem, metinsel girdiyi sayısal bir kimliğe (Token ID) eşler. Modelin sözlüğünde (vocabulary) kayıtlı olan her bir token ID, daha sonra çok boyutlu bir gömme vektörüne (embedding vector) dönüştürülerek yapay sinir ağının derin katmanlarına iletilir.

Token kavramını yalnızca "kelime" olarak tanımlamak teknik açıdan eksik ve yanıltıcıdır. Bir token; tam bir kelimeyi, bir kelime kökünü, bir eki, tek bir noktalama işaretini, boşluk karakterini veya programlama dillerindeki bir parantez sembolünü temsil edebilir. Model mimarisinin kelime dağarcığı büyüklüğü (genellikle modern LLM'lerde 32.000 ile 128.000 benzersiz token arasında değişir), bir metnin kaç parçaya bölüneceğini doğrudan belirler. Kelime dağarcığı ne kadar optimize edilmişse, model metinleri o kadar az sayıda token ile temsil edebilir; bu da işlem verimliliğini artırır.

İşletmeler ve teknik karar vericiler açısından tokenizasyonun çalışma prensibini anlamak, yapay zeka tabanlı iş süreçlerindeki maliyet ve performans dalgalanmalarını öngörmenin ilk adımıdır. Yapay zeka servis sağlayıcıları altyapı kaynak tüketimini (GPU/TPU bellek bant genişliği ve FLOPs hesaplama gücü) harcanan token miktarı üzerinden ölçer. Dolayısıyla, sisteme giren ve çıkan her bir token, doğrudan bulut bilişim faturasına ve yanıt süresine etki eden temel bir operasyonel değişkendir.

Tokenizasyon Süreci: Kelimeler, Heceler ve Karakterler

Tokenizasyon işlemi üç temel seviyede kurgulanabilir: karakter tabanlı, kelime tabanlı ve alt-kelime (subword) tabanlı. Karakter tabanlı yaklaşımda her harf bir token kabul edilir; bu yöntem kelime dağarcığını çok küçük tutsa da modellerin anlamsal bağ kurmasını zorlaştırır ve girdi dizilerini aşırı uzatır. Kelime tabanlı yaklaşımda ise her bağımsız sözcük bir token olarak tanımlanır; ancak bu durum dillerdeki milyonlarca çekim ekini, yazım hatasını ve yeni türetilen terimleri karşılayabilmek için yönetilemez boyutta devasa sözlükler gerektirir.

Modern LLM mimarileri, bu iki ucun avantajlarını birleştiren "alt-kelime" (subword) tokenizasyon algoritmalarını kullanır. Sık kullanılan sözcükler (örneğin İngilizcedeki "the", "market", "software") tek bir token olarak saklanırken; daha nadir kullanılan veya karmaşık ekler almış sözcükler 2, 3 veya daha fazla alt parçaya bölünür. Bu sayede model, daha önce hiç karşılaşmadığı bir sözcükle karşılaştığında dahi bunu bilinen kök ve eklere bölerek anlamlandırabilir ve "sözlük dışı" (out-of-vocabulary) kalma riskini ortadan kaldırır.

Aşağıdaki liste, metin türlerine göre token ayrıştırma dinamiklerini özetlemektedir:

• Sık Kullanılan Temel Kelimeler: Model sözlüğünde doğrudan yer aldıkları için tek bir token (1 Token) olarak işlenir.

• Bileşik ve Eklemeli Kelimeler: Kök ve ek yapısına göre 2 ila 5 farklı alt-kelime tokenına parçalanır.

• Noktalama İşaretleri ve Semboller: Virgül, nokta, tırnak, JSON parantezleri (@@CODE0@@, @@CODE1@@) ve matematiksel semboller genellikle ayrı birer bağımsız token oluşturur.

• Boşluklar ve Satır Sonları: Sözcüklerin başındaki veya sonundaki boşluk karakterleri (@@CODE0@@, @@CODE1@@ veya kelime önü boşluk) çoğu modern tokenizer tarafından sözcükle birleşik bir alt-parça olarak sayılır.

• Programlama Kodu ve Özel Formatlar: Kod bloklarındaki girintiler (indentation), değişken isimlerindeki CamelCase veya snake_case kullanımları her alt öge için ayrı token tüketimine yol açar.

Doğal Dil İşlemede (NLP) Byte-Pair Encoding (BPE) Standartları

Büyük dil modellerinde en yaygın kullanılan alt-kelime algoritması Byte-Pair Encoding (BPE) ve bunun bayt düzeyindeki türevi olan Byte-level BPE'dir. OpenAI (GPT serisi), Anthropic (Claude serisi) ve Meta (LLaMA serisi) gibi önde gelen sağlayıcılar bu algoritmanın optimize edilmiş varyasyonlarını (örneğin OpenAI'ın @@CODE0@@ kütüphanesindeki @@CODE1@@ veya o200k_base şablonları) kullanır. BPE algoritması, eğitim veri setinde en sık yan yana gelen karakter veya bayt çiftlerini yinelemeli olarak birleştirerek sözlüğünü inşa eder.

Ham Karakterler: [ "t", "o", "k", "e", "n" ]
1. Birleştirme Adımı: "to" + "k" -> "tok"
2. Birleştirme Adımı: "tok" + "en" -> "token" (Tek bir sözlük girdisi)

Byte-level BPE mimarisinin en kritik avantajı, metinleri Unicode karakter dizileri yerine ham baytlar üzerinden işlemesidir. Bu sayede dünya üzerindeki tüm alfabeler, özel emojiler ve semboller herhangi bir veri kaybı olmadan tokenleştirilebilir. Ancak bu durum, sözlükte yeterince temsil edilmeyen diller veya karakter setleri için ciddi bir işlem hacmi dezavantajı doğurur.

Diller Arası Token Oranları: Türkçe ve İngilizce Arasındaki Maliyet Farkları

Büyük dil modellerinin eğitim veri setlerinin büyük çoğunluğu (genellikle %85-90'ın üzerinde) İngilizce metinlerden oluşur. BPE algoritmaları frekans tabanlı çalıştığı için, İngilizce sözcüklerin büyük bölümü model sözlüğüne tek bir token olarak kaydedilmiştir. Buna karşılık Türkçe, Macarca, Fince gibi sondan eklemeli (agglutinative) dillerde sözcükler çok sayıda yapım ve çekim eki alarak uzar. Model sözlüğünde bu ek kombinasyonlarının her biri tek parça olarak bulunmadığından, Türkçe bir kelime sıklıkla hecelerine ve harf gruplarına parçalanır.

Bu dilsel asimetri, küresel pazarda çok dilli yapay zeka uygulamaları geliştiren işletmeler için doğrudan bir birim maliyet farkı yaratır. Örneğin, 100.000 kelimelik bir kurumsal bilgi tabanını (knowledge base) RAG (Retrieval-Augmented Generation) mimarisiyle vektörleştirmek ve sorgulamak, Türkçe içeriklerde İngilizceye kıyasla yaklaşık %70 ila %110 arasında daha fazla token harcanmasına neden olur. Karar vericilerin kurumsal AI bütçelerini kurgularken bu çarpanı mutlaka matematiksel modellerine dahil etmeleri gerekir.

Kurumsal API Kullanımlarında Token Hesaplama Metodolojisi

Kurumsal düzeyde yapay zeka entegrasyonu gerçekleştiren şirketler için en temel bütçe kalemi, model sağlayıcılarının (OpenAI, Anthropic, Google Cloud, AWS Bedrock, Microsoft Azure) sunduğu kullanım bazlı (pay-as-you-go) API fiyatlandırma modelleridir. Geleneksel SaaS yazılımlarındaki kullanıcı başına sabit aylık lisans modelinden farklı olarak, LLM API'leri işlem hacmine, yani tüketilen 1 Milyon Token (1M Tokens) başına faturalandırılır. Bu faturalandırma modeli, doğru bir matematiksel hesaplama yapılmadığında kontrolsüz bütçe aşımlarına yol açabilir.

Token hesaplamasında dikkate alınması gereken en temel kural, sistemin iki yönlü bir tüketim yapısına sahip olmasıdır. Bir API çağrısı yapıldığında, modele gönderilen tüm bağlam (sistem talimatları, geçmiş sohbet kayıtları, RAG ile çekilen doküman parçaları ve kullanıcının prompt'u) Girdi (Input/Prompt) Tokenları olarak kaydedilir. Modelin bu girdiyi işleyerek ürettiği yanıt ise Çıktı (Output/Completion) Tokenları olarak adlandırılır.

Hesaplama sürecinde işletmelerin yaptığı en yaygın hata, yalnızca kullanıcının yazdığı soruyu ve modelin verdiği kısa cevabı hesaba katmaktır. Oysa kurumsal bir yapay zeka mimarisinde, arka planda çalışan onlarca sayfalık kurumsal yönerge (system prompt), birkaç örnekli öğrenme verileri (few-shot examples) ve harici veritabanlarından çekilerek bağlama enjekte edilen PDF/metin dökümleri toplam girdi token hacminin %80'inden fazlasını oluşturabilir.

Girdi (Prompt) ve Çıktı (Completion) Tokenlarının Fiyatlandırma Farkları

Yapay zeka sağlayıcılarının fiyat listeleri incelendiğinde, çıktı token birim maliyetlerinin girdi token maliyetlerine kıyasla genellikle 3 ila 5 kat daha pahalı olduğu görülür. Bu fiyat farkı, sinir ağlarının donanımsal çalışma prensibinden kaynaklanır:

1. Girdi İşleme (Parallel Processing): Modele iletilen tüm girdi tokenları GPU belleğine tek bir seferde yüklenir ve matris işlemleriyle paralel olarak hesaplanır. Bu süreç donanım açısından yüksek paralelleştirme verimliliğine sahiptir.

2. Çıktı Üretimi (Autoregressive Generation): LLM'ler çıktı üretirken sıralı (autoregressive) bir mantıkla çalışır. Yani model, bir sonraki kelimeyi/tokenı tahmin etmek için önceki tüm girdiyi ve o ana kadar ürettiği çıktı tokenlarını tekrar hesaplama döngüsüne sokar. 500 tokenlık bir çıktı üretmek, 500 ardışık hesaplama adımı demektir ve donanım kaynaklarını çok daha uzun süre meşgul eder.

Aşağıdaki tablo, kurumsal pazarda yaygın olarak kullanılan modern dil modellerinin standart API fiyatlandırma dinamiklerini ve girdi/çıktı maliyet çarpanlarını göstermektedir:

Örnek Vaka: 1000 Token Ortalama Kaç Kelimeye Karşılık Gelir?

Uygulamalı hesaplamalarda metin hacmini token karşılığına dönüştürmek için standart kurallar kullanılır. İngilizce metinlerde genel kabul görmüş kural şudur:

$$\text{1000 İngilizce Token} \approx 750 \text{ Kelime} \approx 3000 - 3500 \text{ Karakter}$$

Türkçe ve diğer eklemeli dillerde ise heceleme ve ek ayrışmaları nedeniyle bu katsayı değişir:

$$\text{1000 Türkçe Token} \approx 380 - 450 \text{ Kelime} \approx 2000 - 2400 \text{ Karakter}$$

Örnek Vaka Senaryosu:
Bir e-ticaret şirketinin müşteri hizmetleri için geliştirdiği yapay zeka asistanını ele alalım.

• Sistem Yönergesi (System Prompt): 400 kelime Türkçe (~900 token)

• RAG ile Veritabanından Çekilen İade Politikası: 600 kelime Türkçe (~1.350 token)

• Müşteri Sorusu: 30 kelime Türkçe (~65 token)

• Toplam Girdi Tokenı: $900 + 1350 + 65 = 2.315 \text{ Token}$

• Modelin Ürettiği Çözüm Mesajı: 120 kelime Türkçe (~270 token)

• Toplam Çıktı Tokenı: $270 \text{ Token}$

Bu senaryoda tek bir müşteri sorgusu için toplam 2.585 token tüketilmektedir. Günde 10.000 müşteri talebi alan bir operasyonda günlük tüketim yaklaşık 25,85 Milyon Token seviyesine ulaşacaktır.

Matematiksel Hesaplama ve Bütçe Öngörüsü Oluşturma

Kurumsal bir yapay zeka projesinde aylık operasyonel harcamaları (OpEx) tahmin etmek için aşağıdaki standart formülasyon kullanılır:

$$\text{Aylık Maliyet} = \left[ \left( \frac{\text{Günlük Çağrı} \times \text{Ort. Girdi Token}}{1.000.000} \times P{\text{girdi}} \right) + \left( \frac{\text{Günlük Çağrı} \times \text{Ort. Çıktı Token}}{1.000.000} \times P{\text{çıktı}} \right) \right] \times 30$$

Burada $P{\text{girdi}}$ ve $P{\text{çıktı}}$, seçilen modelin 1 Milyon token başına belirlediği liste fiyatlarıdır.

Dil Modellerinde (LLM) Token Sınırları ve Operasyonel Riskler

Her büyük dil modelinin, tek bir işlem döngüsünde (inference session) belleğinde tutabileceği ve aynı anda işleyebileceği maksimum bir veri sınırı vardır. Bu sınıra Bağlam Penceresi (Context Window) adı verilir. Bağlam penceresi, o anki API çağrısında yer alan girdi tokenları ile modelin üreteceği çıktı tokenlarının toplam tavan kapasitesini ifade eder.

Son model nesillerinde bağlam pencereleri 8.000 tokenden (GPT-4 ilk sürümleri) 128.000, 200.000 ve hatta 1 Milyon ile 2 Milyon tokene (Google Gemini serisi) kadar genişlemiştir. Ancak bağlam penceresinin devasa boyutlara ulaşmış olması, operasyonel risklerin ve teknik sınırların ortadan kalktığı anlamına gelmez. Kurumsal mimarilerde bağlam sınırlarının bilinçsizce zorlanması; performans düşüşlerine, aşırı maliyet faturalarına ve halüsinasyon risklerine zemin hazırlar.

Yazılım geliştiriciler ve ürün yöneticileri, bağlam penceresi kapasitesini bir "çöp kutusu" gibi kullanmamalıdır. Bir modele sağlanan veri miktarı arttıkça, modelin dikkat mekanizması (self-attention) matrisi karesel olarak ($O(N^2)$ veya optimize edilmiş dikkat mekanizmalarında $O(N)$) karmaşıklaşır. Bu durum yalnızca sunucu yanıt sürelerini uzatmakla kalmaz, aynı zamanda modelin kritik bilgileri gözden kaçırma riskini de beraberinde getirir.

Bağlam Penceresi (Context Window) Kapasiteleri ve Limitler

Bağlam penceresi iki bağımsız alt limitten oluşur: Toplam Bağlam Kapasitesi ve Maksimum Çıktı Token Sınırı (Max Generation Tokens). Bir modelin toplam bağlam penceresi 128.000 token olabilir; ancak bu model tek bir yanıtta en fazla 4.096 veya 8.192 token çıktı üretecek şekilde sınırlandırılmış olabilir.

Bu ayrımın anlaşılmaması, özellikle uzun rapor oluşturma, kod yazma veya kapsamlı doküman çevirisi yapan kurumsal otomasyonlarda sistemlerin yarıda kesilmesine (truncation) neden olur.

Aşağıdaki liste, farklı model sınıflarının tipik bağlam ve çıktı parametrelerini kategorize etmektedir:

• Standart Üretim Modelleri: 8K - 32K token toplam bağlam; hızlı müşteri destek botları ve sınıflandırma görevleri için uygundur.

• Genişletilmiş Kurumsal Modeller: 128K - 200K token toplam bağlam; çok sayfalı sözleşme analizi, RAG sistemleri ve geniş kod depoları için optimize edilmiştir.

• Ultra-Geniş Modeller: 1M - 2M token bağlam; tüm bir şirketin yıllık finansal dökümlerini veya saatlerce süren ses/video transkriptlerini tek seferde incelemek için kullanılır.

• Maksimum Çıktı Tavanı: Çoğu ticari modelde tek bir yanıtta 4.096 ile 16.384 token arasında sınırlandırılmıştır.

Kritik Uyarı: Kota Aşımı ve Veri Kaybı Riskleri

Bağlam penceresi sınırlarına yaklaşıldığında veya sınır aşıldığında sistemlerde üç ana operasyonel arıza meydana gelir:

1. Bağlam Kesilmesi (Context Truncation / Overflow): Eğer yazılım katmanında bir token sayacı ve yönetim algoritması yoksa, API sağlayıcısı context_length_exceeded hatası döndürerek isteği tamamen reddeder. Bu durum son kullanıcı tarafında uygulamanın çökmesine veya yanıtsız kalmasına yol açar.

2. Samanlıkta İğne Arama Kaybı (Lost in the Middle): Araştırmalar, LLM'lerin yüz binlerce tokenlık devasa bağlam pencerelerinin ortasında yer alan bilgileri hatırlamakta ve doğru analiz etmekte zorlandığını göstermektedir. Bilgi girdinin en başında veya en sonunda olduğunda model doğruluğu yüksekken, ortadaki veriler "unutulabilir" veya halüsinasyona uğrayabilir.

3. Maliyet Patlaması: Müşteri destek botunda her yeni mesajda tüm sohbet geçmişinin tekrar tekrar modele gönderilmesi, 10. mesajdan sonra her tekil sorgunun binlerce girdi tokenı tüketmesine sebep olarak faturaları geometrik olarak artırır.

Maksimum Çıktı Sınırlarına Ulaşıldığında Alınması Gereken Önlemler

Model maksimum çıktı limitine ulaştığında üretimi aniden keser (finish_reason: "length" durumu). Bu durumda kullanıcıya yarım kalmış bir kod, eksik bir JSON veri yapısı veya tamamlanmamış bir cümle döner. Bu operasyonel riski yönetmek için kurumsal mimarilerde şu teknik önlemler uygulanmalıdır:

• Finish Reason Kontrolü: API yanıtındaki @@CODE0@@ parametresi her çağrıda programatik olarak denetlenmeli; değer @@CODE1@@ olarak döndüğünde otomatik tamamlama döngüsü (continuation prompt) tetiklenmelidir.

• Yapılandırılmış Veri Çıktısı (Structured Outputs): JSON formatında veri üretiliyorsa, model sağlayıcılarının "JSON Mode" veya "Strict Schema Enforcing" özellikleri kullanılarak sözdizimsel bozulmalar engellenmelidir.

• Chunking ve Bölümleme: Üretilecek içerik çok uzunsa, görev bağımsız alt görevlere (örneğin: "Bölüm 1'i yaz", ardından "Bölüm 2'yi yaz") bölünerek paralel veya ardışık API zincirleriyle yönetilmelidir.

Kurumsal Ölçekte Token Maliyetlerini Optimize Etme Stratejileri

Aylık milyonlarca API çağrısı yapan büyük ölçekli işletmeler için token tüketimini %30 ila %60 oranında azaltmak, doğrudan binlerce dolarlık bulut tasarrufu ve daha düşük gecikme süreleri (latency) anlamına gelir. Token optimizasyonu, model kalitesinden ödün vermeden sistemin gereksiz veri yükünden arındırılması sürecidir.

Optimizasyon stratejisi tek bir yöntemle sınırlandırılmamalı; istem (prompt) tasarımından sistem mimarisine, önbellekleme mekanizmalarından dinamik model yönlendirmeye (model routing) kadar çok katmanlı bir yaklaşımla ele alınmalıdır.

İstem (Prompt) Mühendisliği ile Gereksiz Token Tüketimini Önleme

Prompt mühendisliği yalnızca modelden doğru yanıtı almayı değil, aynı zamanda bunu en az token sarfiyatıyla başarmayı hedefler. Uzun, tekrarlayan ve laf kalabalığı içeren sistem talimatları her API çağrısında maliyet hanesine yazılır.

• Negatif İstemler Yerine Doğrudan Kurallar: "Lütfen cevabınızda gereksiz giriş cümleleri kurmayınız, kibar olmaya çalışmayınız ve konuyu uzatmayınız" yerine "Doğrudan teknik cevabı ver. Giriş ve kapanış cümlelerini atla." gibi net direktifler girdi tokenını %70 oranında azaltır.

• Biçimlendirme Optimizasyonu: Modele iletilen verilerdeki gereksiz boşluklar, HTML etiketleri veya karmaşık Markdown yapıları temizlenmelidir. Özellikle JSON girdilerinde anahtar isimlerinin kısa tutulması (@@CODE0@@ yerine @@CODE1@@) binlerce çağrıda ciddi tasarruf sağlar.

• Few-Shot Örneklerinin Budanması: Modele ne yapacağını öğretmek için verilen 10 farklı örnek yerine, en kritik 2 temsilci örneğin seçilmesi girdi boyutunu dramatik şekilde küçültür.

Veri Önbellekleme (Prompt Caching) ve Sistematik Sistem Mesajı Kullanımı

2024 yılı itibarıyla modern model sağlayıcıları (Anthropic, OpenAI, Google) Prompt Caching (İstem Önbellekleme) özelliğini devreye almıştır. Bu teknoloji, değişmeyen büyük metin bloklarının (örneğin 20 sayfalık kurumsal yönetmelik veya 5.000 satırlık sistem prompt'u) model sunucularında belleğe alınmasını sağlar.

Standart İstek Akışı:
[Büyük Sabit Sistem Prompt (4.000 Token)] + [Kullanıcı Sorusu (50 Token)] = 4.050 Girdi Tokenı Ücretlendirilir.

Prompt Caching Aktif İstek Akışı:
[Önbellekten Okunan Sistem Prompt] (%90 İndirimli) + [Kullanıcı Sorusu (50 Token)] = Minimum Maliyet.

Önbelleğe alınan girdi tokenları, standart girdi fiyatına kıyasla %80 ila %90 arasında daha ucuzdur ve yanıt oluşturma süresini belirgin biçimde kısaltır. Kurumsal sistemlerde değişmeyen bağlam blokları istemin en başına yerleştirilmeli ve önbellek pencerelerinin bozulmaması için sabit tutulmalıdır.

Doğru Model Seçimi ve Akıllı Yönlendirme (Model Routing)

Her kurumsal görev için sektörün en pahalı amiral gemisi modelini (GPT-4o, Claude 3.5 Sonnet vb.) kullanmak ciddi bir kaynak israfıdır. Görevlerin karmaşıklığına göre modeller hiyerarşik olarak konumlandırılmalıdır:

1. Katman 1 (Hafif Modeller - GPT-4o-mini, Claude 3.5 Haiku): Duygu analizi, niyet tespiti (intent classification), basit metin özetleme ve veri formatı dönüştürme gibi görevleri amiral gemisi modellerin %5'i maliyetine tamamlar.

2. Katman 2 (Gelişmiş Modeller - Claude 3.5 Sonnet, GPT-4o): Çok adımlı mantık yürütme, karmaşık kod üretimi, hukuki sözleşme analizi ve stratejik karar süreçleri için devreye sokulur.

3. Akıllı Yönlendirici (Smart Router): Gelen kullanıcı sorusunu önce mikro bir sınıflandırıcı modelle analiz edip, basit soruları hafif modele, karmaşık görevleri büyük modele yönlendiren bir orkestrasyon katmanı kurulmalıdır.

Aşağıdaki kontrol listesi, kurumsal ölçekte token optimizasyonu uygulayacak ekiplerin teknik denetim adımlarını özetlemektedir: