LLM tokenlerinin gerçekte maliyeti nedir ve daha azı için nasıl ödeme yapılır?

Bir dil modeli için her API faturası, belirteçler için bir faturadır ve neredeyse hiç kimsenin belirli bir metin parçasının kaç jeton olduğuna dair bir sezgisi yoktur. Sonuç ayda iki kez aynı sürprizdir: Test sırasında ucuz görünen bir özelliğin üretim maliyeti kırk kat daha fazladır veya "uyması gereken" bir bağlam penceresi isteği reddeder. Her ikisi de aritmetik problemleridir ve aritmetik bir kez öğrenilmeye değerdir.

Belirteç bir kelime değil

Modeller karakterleri veya kelimeleri okumaz. Eğitim sırasında hangi dizilerin kendi sembollerini hak edecek kadar sık meydana geldiğini öğrenen bir bayt çifti kodlayıcı tarafından üretilen tokenleri (belirteçleri) okurlar. Yaygın İngilizce kelimeler bir simgedir. Nadir olanlar bölünüyor. Bu yüzden token bir ve tokenization üç, rastgele bir dize ise x7Qp2 beşe mal olabilir.

Taşımaya değer temel kurallar:

• İngilizce düzyazı: jeton başına kabaca dört karakter veya kelime başına yaklaşık 0,75 jeton. Bin kelimelik bir makale yaklaşık 1.300 jetona denk geliyor.
• Kod: oldukça kötü. Girinti, noktalama işaretleri ve camelCase tanımlayıcılarının tümü parçalıdır. Token başına üç karaktere yakın bir bütçe ayırın ve küçültülmüş kodu kendi felaketi olarak değerlendirin; olağandışı olduğu için tam olarak kötü bir şekilde tokenize edilir.
• Latince olmayan alfabeler: yine çok daha kötü. Çince, Japonca ve Korece genellikle bir veya iki karakter başına bir jetonun yakınında bulunur; dolayısıyla Japonca'daki aynı içerik, İngilizce sürümün maliyetinden birkaç kat daha pahalı olabilir. Kiril ve Yunanca arada yer alır.
• JSON: noktalama işareti gerçek paradır. Her tırnak işareti, kaşlı ayraç, iki nokta üst üste ve virgül en azından bir belirtecin parçasıdır ve uzun anahtar adlarına sahip derinlemesine iç içe geçmiş yapılar, değerlerden çok söz dizimine harcayabilir.

Temel kurallar tahmin etmeye yöneliktir. Önemli olduğunda sayın: LLM jetonu ve maliyet hesaplayıcısı yapıştırdığınız şeyi simgeleştirir ve sayımı yazdırır ve ayrıca metni belirteç sınırları işaretlenmiş halde gösterebilir; bu, istemlerinizden birinin neden beklenmedik derecede pahalı olduğunu anlamanın en hızlı yoludur. Kendi tanımlayıcı adlarınızın her birinin dört parçaya bölündüğünü görmek çok şey açıklıyor.

Çıktı maliyeti girdiden birkaç kat daha fazla

İnsanların gözden kaçırdığı fiyatlandırma ayrıntısı: Sağlayıcılar, gönderdiğiniz tokenlar ve modelin ürettiği tokenlar için ayrı ayrı ücret alır ve çıktı genellikle giriş oranının dört ila sekiz katıdır. 10.000 jetonluk bağlam ve 200 jetonluk yanıt içeren bir istemde girdi hakimdir. 4.000 jetonluk bir makale üreten 500 jetonluk talimat istemine, ağırlıklı olarak çıktı hakimdir.

Bu, birçok optimizasyon içgüdüsünü tersine çevirir. Model her çağrıya uzun yanıtlar yazıyorsa, bir sistem isteminin 900'den 600'e düşürülmesi çok az tasarruf sağlar. Modele üç paragraf yerine üç cümleyle yanıt vermesini söylemek büyük tasarruf sağlar. Yanlış tarafı optimize etmeden önce, iş yükünüzün aslında işlemin hangi tarafında olduğunu sorun.

Hesap makinesi, tablosundaki her model için aynı metni hem girdi hem de çıktı oranlarında fiyatlandırır; böylece işin tamamını yapan ucuz bir modeli, işin bir kısmını yapan pahalı bir modelle karşılaştırabilirsiniz. Referans fiyatlar yerel olarak saklanır ve sağlayıcı sayfalarıyla periyodik olarak kontrol edilir; bunları bir planlama yardımcısı olarak değerlendirin ve bir bütçe taahhüdünde bulunmadan önce, oranlar değiştiği için sağlayıcının kendi fiyatlandırma sayfasıyla karşılaştırarak onaylayın.

Sohbet ikinci derecedendir ve bütçelerin öldüğü yer burasıdır

Tek seferlik bir API çağrısının maliyeti, maliyeti kadardır. Bir konuşma her fırsatta tüm geçmişi yeniden gönderir, bu nedenle yirmi turluk bir sohbetin maliyeti bir turun yirmi katı değildir - kabaca büyüyen bir serinin toplamına mal olur. Yirmi dönemeç birden on dokuza kadar olan virajların ücretini öder.

İki sonuç. Birincisi, uzun süreli aracı döngüleri LLM kullanımının en pahalı şeklidir ve ölçülmeden prototiplenmesi en muhtemel olanıdır. İkincisi, istemi önbelleğe alma, herhangi bir ifade değişikliğinden daha önemlidir: sağlayıcılar, daha önce gördükleri bir öneki tekrarlayan belirteçlere indirim yapar; bu, kararlı içeriğinizi (sistem istemi, şema, örnekler) en öne ve değişken kısmı en sona koymak anlamına gelir. Aynı istemi, değişen zaman damgası en üstte olacak şekilde yeniden sıralayın ve başka hiçbir şeyi değiştirmeden her aramada önbelleği geçersiz kılmış olursunuz.

Bir istemi göndermeden önce küçültmek

Büyük boyutlu istemlerin çoğu, sıkıcı nedenlerden dolayı aşırı boyutlandırılmıştır: Birisi, üç işlev ilgiliyken bir dosyanın tamamını yapıştırmıştır ve dosya, yarım yorum ve boş satırlardan oluşmaktadır. Yüksek Lisans bağlam sıkıştırıcısı tam olarak bunu hedefliyor; kod yorumlarını sıyırıyor, boş satır dizilerini daraltıyor, girintileri kapatıyor ve düz yazıdan dolgu sözcüklerini kaldırıyor, ardından kesmenin kaç jeton kurtardığını rapor ediyor. Modelin ihtiyaç duyduğu hiçbir şeye dokunmadan rutin olarak %20-40 oranında çalışan gerçek bir kaynak dosyada.

Bundan önce yapmaya değer manuel kesimler:

1. Dosyaları değil, alıntıları gönderin. Model dikkati de bedava değil; ilgisiz bağlam, hem cevapları ölçülebilir şekilde bozar hem de paraya mal olur.
2. Günlükleri arızalı bölgeye soyun. On bin satırlık başarılı başlangıç çıktısı teşhise hiçbir katkı sağlamaz.
3. Tekrarlanan ortak metni bırakın. Lisans başlıkları, oluşturulan içe aktarmalar, her kayıtta aynı sorumluluk reddi beyanı.
4. Yeniden göndermek yerine özetleyin. Uzun bir konuşmada, birden on beşe kadar olan sıraları bir durum paragrafıyla değiştirmek, mümkün olan en büyük tasarruftur.

Giriş gerçekten uymadığında

Bağlam pencereleri artık büyük, ancak "büyük" hâlâ sınırlıdır ve bir kitap, bir yıllık günlükler veya tam bir transkript bir yılı aşacaktır. Bölme standart cevaptır ve nerede böldüğünüz önemlidir: cümlenin ortasında veya işlevin ortasında kesmek, modelin tahmin etmesi gereken parçalar üretir. istem ayırıcı metni, sınırlara saygı göstererek seçtiğiniz boyutta parçalara böler ve parçaları, her birine tutarlı bir talimat eklenerek sırayla besleyebilmeniz için numaralandırır.

Birimlerle ilgili bir not: belirteçler bayt değildir. UTF-8 bayt sayacı farklı bir soruyu yanıtlıyor - metnin tel üzerinde veya bir veritabanı sütununda ne kadar yer kapladığı - ve iki sayı, Latin olmayan metin için keskin bir şekilde ayrılıyor; burada karakter başına bayt artarken jeton başına karakter düşer. Depolama sınırları için baytları ve model sınırları için belirteçleri kullanın ve hiçbir zaman birini diğerinin yerine kullanmayın.

Çalışılmış bir örnek

Otuz sayfalık bir belgeye karşılık yirmi soruyu yanıtladığınızı varsayalım. Otuz sayfa yaklaşık 15.000 kelimeye, yani yaklaşık 20.000 jetona denk gelir. Safça, belgeyi her soruyla birlikte gönderirsiniz: 20 × 20.000 = 400.000 giriş jetonu, artı belki 20 × 300 çıkış jetonu.

Belgeyi ilk sıraya koyun ve çağrılar arasında onu bayt bakımından aynı tutun; çoğu sağlayıcı tekrarlanan öneki önbellekten çok daha düşük bir oranla sunar. Önce standart belgeyi kesin, taban da küçülür. Arama başına bir yerine beş soruyu toplayın ve belgeyi yirmi yerine dört kez gönderin. Aynı görev, aynı model ve dikkatsiz versiyon ile dikkatli versiyon arasındaki büyüklük sırası - göndermeden önce saymanın asıl amacı budur.

Hem sayaç hem de kompresör tamamen tarayıcınızda çalışır: fiyatlandırdığınız bilgi istemi ölçülecek herhangi bir yere yüklenmez.