Hugging Face, VocabX ile çıkarım maliyetini yüzde 77 düşüren tokenizer yöntemini tanıttı

Hugging Face, küçük dil modellerinin kelime dağarcığını (tokenizer) alan ve göreve özel olarak yeniden kurarak temel modeli değiştirmeden ölçülen çıkarım maliyetini yüzde 77 azaltan bir yöntem geliştirdi. Şirketin blog yazısına göre VocabX adı verilen bu yaklaşım, Portekizce kompozisyonları otomatik değerlendiren üretim sisteminde test edildi ve sonuçlar henüz hakem değerlendirmesinde olan bir makalede paylaşılacak.

Hugging Face, makalenin mevcut sürümündeki rakamların yayımdan önce değişebileceğini belirtiyor. Çalışmanın özü, tokenizer'ı temel modelin değiştirilemez bir özelliği olarak görmek yerine, eğitimden önce ayarlanabilen en büyük maliyet kaldıraçlarından biri olarak ele almak.

VocabX nedir, hangi sorunu çözüyor?

Genel amaçlı modellerin tokenizer'ları kaynak koddan sözleşmelere, Çinceden farklı dillere uzanan geniş metin koleksiyonlarıyla eğitiliyor. Bu, genel bir model için mantıklı bir tercih. Ancak tek bir alana özelleşmiş bir modelde iki tür israf doğuruyor.

Birincisi parçalanma: tokenizer, alanın en çok tekrarladığı dizileri tam da en çok parçalıyor. Değerlendiricide her yanıt aynı JSON zarfıyla, aynı yetkinlik adlarıyla ve aynı değerlendirme ifadeleriyle başlıyor. Sözleşmelerde bu, standart maddeler; kodda ise tanımlayıcılar oluyor. Tek token'a sığabilecek diziler birkaç token'a bölünüyor ve model her istekte bunun bedelini ödüyor.

İkincisi fazlalık: kelime dağarcığı, alanın hiç kullanmadığı on binlerce girdi taşıyor ve model ürettiği her token'da bunların tümü için puan hesaplıyor. Amerikan lise biyoloji sınavlarını değerlendirmek üzere ayarlanmış bir model neredeyse hiç Çince yazmayacak, yine de her adımda her Çince token'ın olasılığını hesaplıyor.

Neden üretmek okumaktan pahalı?

Hugging Face'e göre token sayısını azaltmak tek başına faturayı düşürmüyor. Çıkarım iki aşamada gerçekleşiyor. Ön doldurma (prefill) aşamasında model girdinin tamamını tek geçişte işliyor; GPU belleğinden okunan her ağırlık tüm girdi token'ları için yeniden kullanılıyor ve sınır hesaplama gücü oluyor. Kod çözme (decode) aşamasında ise yanıt tek tek token üretilerek yazılıyor; her token tam bir geçiş gerektiriyor ve GPU zamanının çoğu bellekten veri gelmesini beklemekle geçiyor.

Şirketin ölçümüne göre değerlendiricide üretilen bir token, okunan bir token'ın 7,4 katı maliyete sahip. Bu oran donanıma, probleme, toplu iş boyutuna ve bağlam uzunluğuna göre değişebiliyor, hatta daha da büyüyebiliyor; ancak yön aynı kalıyor: üretmek okumaktan daha pahalı.

Faturaya üçüncü bir kalem daha ekleniyor: kelime dağarcığının kendisi. Modelin son katmanı LM head, iç durumu her olası token için bir puana çevirirken kelime dağarcığındaki her girdi için bir parametre satırı tutuyor. Qwen3-4B boyutundaki bir modelde bu matris, parametrelerin neredeyse yüzde 10'unu oluşturuyor. Girdi katmanı yalnızca okunan token'ın satırına bakarken LM head her üretilen token için matrisin tamamını okuyup çarpıyor. Alanın hiç kullanmadığı bir girdi, sık kullanılanla tamamen aynı maliyeti doğuruyor.

Mevcut yöntemler neden yetersiz kaldı?

Hugging Face, kelime dağarcığını uyarlamanın yeni bir fikir olmadığını kabul ediyor. Literatürdeki fast vocabulary transfer (FVT), multi-word tokenization (MWT) ve Liquid AI'nın yerinde tokenizer genişletmesi (in-place BPE) gibi referans yöntemler parçalanmayı zaten azaltıyor. Ancak şirket, bu yöntemleri kendi probleminde test ettiğinde iki sınırlamayla karşılaştı.

Bu yöntemler token'ları maliyete göre değil sıklığa göre seçiyor; girdide sık görünen bir ifade, yanıtta daha seyrek görünen ama sunulması daha pahalı olan bir ifadeden daha değerli sayılıyor. Ayrıca tek katmanda çalışıyorlar: ya kelimelerin nasıl parçalandığını ayarlıyorlar ya da tam ifadeleri tek token'da birleştiriyorlar. Hiçbiri ikisini aynı ölçüt altında yapmıyor. Değerlendiricideki en büyük israf ise tam olarak JSON zarfı gibi uzun, tekrarlayan aralıklarda ortaya çıkıyor.

VocabX bu sorunları nasıl aşıyor?

VocabX üç değişiklik öneriyor. İlk olarak soru değişiyor: aday bir token'ın kaç token tasarrufu sağladığı değil, ne kadar maliyet ve zaman kazandırdığı hesaplanıyor. Elenen her token, bulunduğu alanın fiyatıyla çarpılıyor — sistem istemi, kullanıcı mesajı ya da model yanıtı. Ölçülen durumda yanıtta kazanılan bir token, girdide kazanılanın 7,4 katı değerinde.

İkincisi, yöntem iki katmanda birden çalışıyor. Alt kelime katmanında alan sözcüklerinin nasıl parçalandığı yeniden kuruluyor; çok kelimeli katmanda ise kısa ifadelerden tam satırlara ve JSON zarflarına kadar tekrarlayan aralıklar aranıp her biri tek bir "makro token"a dönüştürülüyor. Her iki katman da aynı maliyet ölçütü altında, kendi bütçeleriyle seçiliyor.

Bu aralıkları bulmak için beş otomatik madenciden yararlanılıyor: uzun kelimeler, tam satırlar, ifadeler, tam cümleler ve JSON ile etiketler gibi noktalama içeren yapılar. Sekiz veri kümesi üzerinde ortalama alındığında en çok katkıyı sonuncusu sağlıyor; kodda tek başına 17,5 puanlık fark yaratıyor. Beşi birlikte kullanılmadığında değerlendiricideki token azaltımı 55,6 puan düşüyor.

Üçüncü adım, örneklemin göremediğini tahmin etmek. Maliyete göre seçim yapmak, her adayın önceden seçilenlerden sonra ne kadar tasarruf sağladığını bilmeyi gerektiriyor; bunu kesin ölçmek on binlerce kez tüm veri kümesini yeniden işlemek anlamına geliyor. Örneklem üzerinden yapılan ölçümde 50 bin belgede 37 kez geçen bir ifade, 400 belgelik örnekte yalnızca yaklaşık yüzde 26 oranında görünüyor. Sözleşme veri kümesinde adayların yalnızca yüzde 16,6'sı örnekte yer alıyor.

VocabX, adayın kazancını iki parçaya ayırıyor: tüm veri kümesi üzerinde sağladığı ve tam olarak sayılabilen tasarruf ile henüz seçilen token'lar tarafından karşılanmayan kısım. Örneklemin göremediği adaylar için sıfır yerine, görünenlerin davranışına dayalı istatistiksel bir tahmin kullanılıyor. Hugging Face'e göre bu değişiklik tek başına, aynı örneklem ve bütçeyle sözleşme veri kümesindeki token azaltımını yüzde 44,7'den yüzde 52,8'e çıkardı.

Değerlendirici üzerinde ne değişti?

Gerçek etkiyi ölçmek için ekip, aynı taban model, aynı veri, aynı eğitim tarifi ve aynı tohumla yedi farklı değerlendirici sürümü eğitti. Aralarındaki tek fark tokenizer. Tümü aynı test makinesinde, bir RTX 5090 GPU ve vLLM çıkarım sunucusuyla aynı 500 isteği çalıştırdı. Yöntemin çıktı katmanını yaklaşık 152 bin satırdan yaklaşık 65 bin satıra indirdiği belirtiliyor.

Neden önemli?

Hugging Face'in aktardığına göre tokenizer genellikle temel modelin değiştirilemez bir özelliği olarak görülüp olduğu gibi bırakılıyor. Oysa tek bir alana özelleşmiş bir modelde, herhangi bir eğitim adımından önce ayarlanabilen en büyük maliyet kaldıraçlarından biri olabiliyor. Bu, özellikle küçük modellerle ve orta düzeyde toplu işlerle çalışan ekipler için önem taşıyor; çünkü aynı donanım ve aynı modelle daha düşük sunum maliyeti anlamına geliyor.

Hugging Face, VocabX'in seçim ölçütüne kelime dağarcığı boyutu terimini dahil etmediğini, boyutu iki adımda kontrol ettiğini belirtiyor: alt kelime birleştirmesi temel kelime dağarcığını daha küçük ve alana özel bir dağarcıkla değiştiriyor, makrolar ise sabit bir bütçe altında giriyor.

Yöntemin ayrıntılarını ve sonuçların tamamını içeren VocabX makalesinin henüz hakem değerlendirmesinde olduğu ve yayımdan önce değişebileceği belirtiliyor. Türkiye'deki geliştiricilerin yöntemi kendi dillerine ve alanlarına ne zaman uygulayabileceğine dair bir açıklama ise henüz yapılmadı.