Yapay zekâ token sayacı ve bağlam sınırı kontrolü
Herhangi bir metni yapıştırın; kaç token'a dönüşeceğini, belirli bir bağlam penceresine sığıp sığmadığını ve kendi API ücretlerinizle ne tutacağını görün. Her şey tarayıcınızda çalışır — metniniz hiçbir yere gönderilmez.
Bağlam penceresine sığıyor mu?
| Bağlam penceresi | Metniniz | Sığar mı? |
|---|
Bağlam penceresini girdiğiniz metin, modelin yanıtı ve uygulamanın perde arkasında eklediği her şey (sistem prompt'u, getirilen belgeler, sohbet geçmişi) paylaşır. Pay bırakın: pencereyi ağzına kadar doldurursanız yanıtlar yarıda kesilir.
Maliyeti ne olur?
Girdi maliyeti için yukarıya yapıştırdığınız metin gerekir — hesaplamak için bir şey yapıştırın.
Bu tahmin nasıl yapılır (ve neden birebir doğru değildir)
Gerçek tokenleştirme, metninizin üzerinde modele özgü bir BPE sözlüğü çalıştırır — ve her model ailesi farklı bir sözlük kullandığı için “doğru” sayı modelden modele değişir. Bunu tarayıcıda düzgün yapmak, her aile için birkaç megabaytlık bir sözlüğü sayfaya indirmek demektir; yalnızca yaklaşık olarak ihtiyaç duyduğunuz bir sayı uğruna sayfayı yavaşlatırdı.
Bunun yerine burada karakter ve sözcük sayısına dayanan, boşluk, noktalama ve rakamlara göre ağırlıklandırılmış bir tahmin yöntemi kullanılıyor; sıradan İngilizce düzyazıda hata payı %10–15 civarında kalıyor. Bilinen iki sapma var: kod ve yoğun noktalama içeren metinler tahminin gösterdiğinden daha yoğun token üretir; Latin alfabesi dışındaki yazılar (Çince, Japonca, Arapça, Hintçe) ise karakter başına İngilizceden hayli fazla token harcar — çoğu zaman 2–3 kat.
Faturalandırma için kesinlik gerekiyorsa sağlayıcınızın kendi tokenizer uç noktasını kullanın. “Bu sığar mı” ve “kabaca ne kadar tutar” soruları içinse doğru araç bir tahmindir.
Token aslında nedir
Modeller ne karakter ne de sözcük okur — token okur; ikisinin arasında duran parçalar. Yaygın sözcükler genelde tek token olur; daha uzun ya da alışılmadık sözcükler birkaça bölünür. “Unbelievable” üç token olabilir, “the” tektir. İngilizce düzyazıda bir token ortalama dört karakter, yani kabaca bir sözcüğün dörtte üçü kadardır.
Her şey token cinsinden fiyatlandırılır ve sınırlanır: gönderdikleriniz, size geri dönenler ve modelin bir seferde tutabildiği miktar.
Metniniz neden sandığınızdan daha yoğun
- Kod verimsiz tokenize olur — girintiler, parantezler ve camelCase'in hepsi token harcar. 500 satırlık bir dosya, karakter sayısına bakarak beklediğinizden çok daha fazla token tutabilir.
- İngilizce olmayan metin pahalıdır. Latin alfabesi kullanmayan diller karakter başına çoğu zaman 2–3 kat daha fazla token harcar; aynı istemin Japoncada İngilizceye göre kat kat pahalıya gelmesinin nedeni budur.
- Tekrar ucuzdur, yapı ucuz değildir. JSON ve Markdown'ın yapısal işaretleri çok sayıda çağrıda hızla birikir.
Bağlam penceresi ≠ bütçeniz
Bir milyon token'lık pencere, bir milyon token göndermeniz gerektiği anlamına gelmez. Çok uzun girdilerde dikkat kalitesi ortalara doğru düşer, gecikme artar, maliyet doğrusal olarak artar. Retrieval — yalnızca ilgili pasajları çekmek — pencereyi tıka basa doldurmaktan genellikle daha iyi sonuç verir, üstelik daha ucuza gelir.
SSS
Bu sayaç ne kadar isabetli?
Sıradan İngilizce düzyazıda hata payı yaklaşık %10–15. Kod ve Latin dışı yazı sistemlerinde gerçek sayı tahminin üzerinde kalır. Kesin faturalandırma rakamları için sağlayıcınızın tokenizer'ını kullanın.
Metnim bir yere yükleniyor mu?
Hayır. Hesaplama tarayıcınızda çalışır. İstek yok, kayıt yok, saklama yok.
Model fiyatlarını neden göstermiyorsunuz?
Çünkü fiyatlar değişiyor ve güncelliğini yitirmiş bir fiyatı kesinmiş gibi göstermek, hiç fiyat göstermemekten daha kötü. Sağlayıcınızın güncel ücretlerini girin, hesabı araç yapsın.
Görseller ve ses token harcar mı?
Evet — multimodal girdiler de token'a dönüştürülür; oranlar sağlayıcıya ve çözünürlüğe göre değişir. Bu araç yalnızca metni kapsar.
İlgili: RAG nedir? · Hangi görev için hangi yapay zekâ modeli · Tüm ücretsiz araçlar