LLM Tokenizer Vergisi: Dilin AI Maliyetini ve Bağlamını Nasıl Değiştirdiği

LLM tokenizer vergisi ölçülebilir bir maliyet ve bağlam cezasıdır. İki istem aynı anlama sahip olabilir, ancak farklı diller kullandıkları için çok farklı token sayıları tüketebilirler.

Temmuz 2026'da yapılan bir çalışma, altı tokenizer arasında 997 hizalanmış cümleyi test etti. OpenAI'nin eski `cl100k_base` kodlaması ile on Hint dilinin İngilizceye göre ortalama kelime verimliliği vergisi 8.0 katıydı. Malayalam 13.04 katına ulaştı. Daha yeni `o200k_base`, ortalamayı 2.1 katına düşürdü. Çalışma, tokenizasyonun tek başına daha kötü cevaplara neden olduğunu kanıtlamaz. Ancak fiyat ve kullanılabilir bağlamın, bir model akıl yürütmeye başlamadan önce farklılaşabileceğini gösterir.

Hedef kitle: Orta düzey

Doğrudan cevap: Çok dilli bir AI ürününü İngilizce token sayılarından tahmin etmeyin. Tam hizalanmış üretim metni üzerinde kesin tokenizer'ı test edin, tüm isteği ölçün, kaliteyi ayrı değerlendirin ve model veya tokenizer değiştiğinde testi yeniden çalıştırın.

LLM tokenizer vergisinin ölçtüğü şeyler

Dil modelleri token kimlikleri alır, kelimeleri veya karakterleri değil. Bir tokenizer metni token birimlerine böler ve bunları kimliklere eşler; bazı tokenizer'lar önce metni normalize eder. Ortak parçalar bir token içine sığabilir. Daha az temsil edilen yazı sistemleri veya kelime formları birkaç token veya byte'a bölünebilir.

Makalenin başlık metriği kelime verimliliğidir: boşlukla ayrılmış kelime başına token sayısı. Tokenizer vergisi, bir dilin kelime verimliliğinin, aynı tokenizer altında İngilizce kelime verimliliğine bölünmesiyle hesaplanır.

Bir üretim ekranı için, hizalanmış token sayısı oranı genellikle daha kolay kullanılır:

text hizalanmış token sayısı oranı dil L için = tokenler için hizalanmış içerik dil L'de ÷ tokenler için İngilizce versiyonu

Bu metrikler ilgili soruları yanıtlar, ancak birbirinin yerine geçmez. Rapor ettiğiniz metriği adlandırın. Her iki karşılaştırma da anlamsal olarak hizalanmış metin gerektirir. İlgisiz cümleleri saymak veya yaygın kelimeler listesini kullanmak, gerçek bir uygulama hakkında pek bir şey söylemeyen çekici bir sayı üretebilir.

Araştırmacılar ayrıca verimlilik kullanır; bu genellikle kelime başına token olarak tanımlanır. Kelime verimliliği sezgisel olsa da, kelime sınırları diller arasında eşit derecede net değildir. Bir boşluk olduğu zaman nedenini teşhis etmek için karakter verimliliğini, token başına byte sayısını ve birleştirilmemiş byte'ların payını ekleyin.

Bu ayrım önemlidir çünkü token sayısının birkaç farklı sonucu vardır:

Son satır, aşırı iddia etmek için en kolay olanıdır.

2026 araştırmasının bulguları

Yeni Tokenizer Vergisi çalışması, FLORES-200'den hizalanmış cümleler kullandı. On Hint dilini İngilizce, Arapça, İspanyolca ve Fransızca ile altı tokenizer arasında karşılaştırdı. Yazarlar kelime ve karakter verimliliğini, token başına byte sayısını, birleştirilmemiş tek byte tokenleri ve sabit bir bağlam bütçesini aşan kaynak metin miktarını ölçtü.

Mühendislik kararları için üç sonuç önemlidir:

Yüksek vergiye sahip diller, tokenlerinin %27-43'ü için birleştirilmemiş tek byte tokenler üretti. Geçerli kelime sınırlarına sahip örneklenen diller arasında, bu oran kelime verimliliği vergisi ile `r = 0.89` olarak ilişkilendirildi. Yazarlar bu farkı, o yazılar için yetersiz kelime kapsamına atfeder.

Bir 2023 NeurIPS makalesi, diller arasında tokenizasyon uzunluğu farklarının 15 katına kadar çıkabileceğini buldu. Bir EMNLP 2023 çalışması 22 dilde maliyet ve faydayı ölçtü ve token tabanlı API fiyatlandırmasının bazı dil topluluklarından karşılaştırılabilir içerik için daha fazla ücret alabileceğini buldu.

Son çalışmalar ayrıca, bu farkın bir tasarım seçimi olduğunu, bir yazının kaçınılmaz bir özelliği olmadığını göstermektedir. Eşitlik farkındalığına sahip byte-pair kodlama (BPE), mevcut en kötü sıkıştırılmış dili desteklemek için birleştirme amacını değiştirir. Yazarları, az bir değişiklikle, küresel sıkıştırmada, çapraz dil Gini katsayısı ile ölçülen token maliyet eşitsizliğinde %89'a kadar bir azalma bildirmektedir. Ayrı bir 11 Güneydoğu Asya dili üzerinde kontrol edilen bir çalışma, eşitlik farkındalığına sahip BPE'yi karşılaştırılabilir 1.5 milyar parametreli temel modeller için verimlilik-eşitlik Pareto sınırında yerleştirdi. Bu sonuç, sınır ölçeğinde veya hizalamadan sonra aynı ticareti kurmadığını kanıtlamaz.

Doğruluk iddiası dikkat gerektirir

Temmuz çalışması, 13 dil noktası için verimlilik ile okuma-anlama doğruluğu arasında `r = -0.61` ham bir korelasyon buldu. Dil kaynak düzeyi için kontrol edildikten sonra, kısmi korelasyon `r = 0.25` oldu.

Neden bir nedensel başlıktan kaçınmak gerektiğine dair daha fazla sebep var: verimlilik sayıları ve doğruluk puanları farklı tokenizer/model ayarlarından geldi, örnek küçük ve çevrilen benchmark cümleleri bir üretim iş yükü değildir. Makale, token sayıları, bağlam ve token fiyatlı maliyetler hakkında güçlü iddiaları destekler. Token verimliliğini daha düşük cevap kalitesinin nedeni olarak izole etmez.

Kendi çok dilli token maliyetinizi ölçün

Araştırma bir uyarı verir, üretim oranınızı değil. Bir destek asistanı, geri alma sistemi veya kodlama ajanı kendi dil karışımına ve istem yapısına sahiptir.

Bu iş akışını lansmandan önce ve her model değişikliğinden sonra kullanın.

1. Hizalanmış bir örnek oluşturun

Başlangıç ekranı için, beklediğiniz iş yükünden 100-1,000 örnek toplayın:

Aynı anlamı taşıyan gözden geçirilmiş çevirileri kullanın. Her dil varyantını bağlayan bir ID tutun. Ayrı dil korpuslarından rastgele metinleri karşılaştırmayın. Bu tarama aralığı istatistiksel bir minimum değildir: gerekli örnek, dil sayısına, iş yükü varyansına ve kuyruk davranışını ne kadar kesin tahmin etmeniz gerektiğine bağlıdır.

Örneği JSON Satırları olarak saklayın:

{"id":"support-001","language":"en","text":"Gözden geçirilmiş İngilizce metin"} {"id":"support-001","language":"sv","text":"Gözden geçirilmiş İsveççe çeviri"} {"id":"support-001","language":"tr","text":"Gözden geçirilmiş Türkçe çeviri"}

2. Tokenizer'ı sabitleyin

Tokenizer bir model sürümüne aittir. Her ikisini de kaydedin. OpenAI'nin resmi `tiktoken` deposu `cl100k_base` ve `o200k_base`'yi açığa çıkarır; model eşlemesi ayrıca model ailelerinin farklı kodlamalar kullanabileceğini gösterir. Kapalı bir model için, bir tane varsa sağlayıcının resmi sayacını tercih edin. Örneğin, Google'ın Gemini API'si `countTokens` yöntemini açığa çıkarır. Açık bir model için, modelin belgelenmiş tokenizer hattı ile tam eseri yükleyin; örneğin, Hugging Face Tokenizers API ile tanımlananı.

Aynı satıcıdan iki modelin bir tokenizer paylaştığını varsaymayın. Dünkü bir modelin zaten bilindiğini varsaymayın.

3. Tek bir oran değil, bir dağılım hesaplayın

Sayacı yükleyin ve sabitleyin:

bash python -m pip install "tiktoken==0.13.0"

Sonra çalıştırın:

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} has no {BASELINE} baseline")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} has an empty baseline")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

Ortalama, bağlam penceresini aşan birkaç uzun isteği gizleyebilir. Bir kapasite planında sonucu kullanmadan önce p50 (medyan), p95 (95. yüzdelik) ve maksimumu kontrol edin.

*Dağıtımı kullanarak maliyet ve bağlam sınırlarını belirlemek için dağıtımcı tokenizer ile hizalanmış üretim metnini ölçün. Kalite ayrı bir değerlendirme olarak kalır.*

4. Tam isteği ölçün

Görünür kullanıcı mesajı, bir API çağrısının yalnızca bir parçasıdır. Şunları dahil edin:

Bu, özellikle ajanlar için önemlidir. Büyük bir JSON araç şeması, kısa bir kullanıcı isteğini domine edebilir. Yerelleştirilmiş bir RAG pasajı, İngilizce bir sistem istemini domine edebilir. Sağlayıcı bu temsili açığa çıkardığında nihai seri isteği ölçün.

5. Tokenleri işletim sınırlarına dönüştürün

Basit bir token fiyatlı API için:

text aylık girdi maliyeti = aylık çağrılar × ortalama girdi tokenleri × milyon token başına fiyat ÷ 1,000,000

Varsayalım ki varsayımsal bir API, milyon token başına 1 $ ücret alıyor. 1,000 girdi tokeni ile bir milyon istek 1,000 $ maliyet eder. Başka bir dilde hizalanmış isteklerin ortalaması 2,500 token ise, girdi kısmı önbellekleme veya indirimlerden önce 2,500 $ olur.

Bağlam ayrı bir hesaplama gerektirir:

text kullanılabilir girdi bütçesi = bağlam penceresi

Gözlemlenen dil oranını içerik kısmına uygulayın, tüm isteğe körü körüne değil.

AI akıl yürütme-token maliyet kılavuzu, token bütçelerinin yalnızca bir model sınırı değil, bir ürün sınırı gerektirdiğini açıklar. RAG ve kodlama sistemleri için, çapraz-repo bağlam tasarımı, daha fazla bağlam göndermenin otomatik olarak faydalı olmadığını gösterir. API seçimi hala açıksa, mevcut ücretsiz AI API vaka çalışması daha geniş bir karşılaştırma çerçevesi sağlar.

Çok dilli bir kabul kapısı belirleyin

Daha düşük bir token oranı, model hala ürün gereksinimini karşıladığı sürece faydalıdır. Dört ayrı kapı kullanın:

Çok dilli bir RAG sistemi için, paylaşılan bir karakter sayısı yerine dağıtımcı tokenizer ile parçalayın. Bir ajan için, ilk isteğin yanı sıra araç izlerini ve yeniden denemeleri ölçün. Bir destek ürünü için, çağrı başına maliyet değil, çözülen vaka başına maliyeti takip edin. Bu seçimler, token metriğinin bir gösteriş ölçütü haline gelmesini engeller.

Tam puan kartını iyileştirdiğinde yalnızca dil spesifik bir yol kullanın. Daha ucuz bir tokenizer, daha zayıf bir modelle eşleştirildiğinde girdi tokenlerini tasarruf ettirebilir ve yeniden denemeleri artırabilir. Daha büyük bir bağlam penceresi, fatura büyüyene kadar kötü parçalamayı gizleyebilir. Doğru birim, tamamlanmış kullanıcı görevidir.

Takımların değiştirebileceği şeyler

Uygulama ekipleri, ticari bir modelin tokenizer'ını yeniden eğitemez, ancak yine de seçenekleri vardır:

Kendi modellerini eğiten ekipler daha derin bir seçeneğe sahiptir. Eşitlik farkındalığına sahip BPE sonuçları, bir tokenizer amacının, genel sıkıştırmadan çok fazla fedakarlık etmeden çapraz dil eşitsizliğini azaltabileceğini önermektedir. Güneydoğu Asya çalışması, adalet ve verimliliğin zıt yönlere hareket etmek zorunda olmadığını kontrol edilen kanıtlar ekler.

Tokenizer'ı model sözleşmesinin bir parçası olarak ele alın. Sürümünü belirleyin, kıyaslayın ve geçiş incelemelerine dahil edin.

Kanıtların sınırları

En yeni çalışma bir ön baskıdır. Çevrilen FLORES-200 cümlelerini, mütevazı bir dil setini ve her yazı sistemine eşit derecede uymayan boşluk tabanlı bir kelime metriğini kullanır. Byte tespit yöntemi tokenizer'a özgüdür.

En güçlü sonuç model bağımsızdır: bir hizalanmış dil daha fazla token ürettiğinde, sabit bir token penceresine daha az metin sığdırır. Maliyet sonucu, bir sağlayıcı bu ekstra tokenleri aynı birim fiyatla faturalandırdığında geçerlidir. Önbellek politikaları ve hacim indirimleri nihai faturayı değiştirebilir.

Doğruluk kendi testini gerektirir. Eğitim verisi kapsamı, model mimarisi, eğitim sonrası, değerlendirme tasarımı ve kültürel bağlam sonuçları etkiler. Token verimliliği bir fark yaratabilir, ancak Temmuz makalesi bu nedensel etkiyi izole etmez.

Çok dilli tokenizer kontrol listesi

Sıkça sorulan sorular

Neden bazı diller daha fazla LLM tokeni kullanıyor?

Alt kelime kelime dağarcıkları, eğitim verilerini ve birleştirme kurallarını yansıtır. Yaygın İngilizce parçaları genellikle verimli bir şekilde temsil edilirken, daha az temsil edilen yazı sistemleri daha küçük parçalara veya byte'lara bölünebilir. Farkın büyüklüğü, tam tokenizer'a ve metne bağlıdır.

Daha yüksek bir token sayısı daha kötü bir cevap mı demektir?

Hayır. Bu, token fiyatlı maliyeti ve bir token penceresine sığan metin miktarını doğrudan etkiler. Daha düşük cevap kalitesini kanıtlamaz. Her dilde gözden geçirilmiş örneklerde kaliteyi ayrı test edin.

API çağrısından önce tokenleri nasıl sayabilirim?

Mümkünse sağlayıcının resmi sayım uç noktasını kullanın. OpenAI kodlamaları için, `tiktoken` yerel olarak sayabilir. Açık modeller için, modelle birlikte gönderilen tam tokenizer eserini yükleyin. Daha sonraki bir güncellemenin ölçümü sessizce değiştirmemesi için sürümleri sabitleyin.

Modelleri değiştirmek tokenizer vergisini kaldırabilir mi?

Farkı azaltabilir. Temmuz çalışması, `cl100k_base` ile `o200k_base` arasında büyük bir iyileşme buldu. Bir model değişikliği ayrıca kaliteyi, çıktı maliyetini, önbellekleme, gecikme ve operasyonel davranışı değiştirir, bu nedenle yalnızca token sayıları yerine tam iş yükünü karşılaştırın.

Kaynaklar

İddia kontrolleri