Küçük Dil Modellerinin (SLM) Kelime Dağarcığını Özelleştirmek Gerçek Uygulamalarda Çıkarım Maliyetini Nasıl %77 Düşürebilir?

Qwen ve Gemma gibi genel amaçlı açık kaynaklı modelleri ince ayar (fine-tuning) ile belirli bir alana veya göreve özelleştirdiğimizde, bu modeller çok sayıda alan ve genel uygulama için oluşturulmuş bir kelime dağarcığını (vocabulary) miras alır. Canlı ortamda (production) çalıştırdığımız otomatik bir kompozisyon değerlendirme sisteminde, bu genel kelime dağarcığı modelin en sık yazdığı metinleri çok sayıda parçaya (token) bölüyordu. Yakında yayımlanacak olan VocabX makalesinin ilk sonuçlarını incelediğimiz bu yazıda; kelime dağarcığını token sıklığı yerine her bir tokenın maliyetine göre özelleştirerek, temel modeli değiştirmeden ölçülen çıkarım (inference) maliyetini nasıl %77 oranında düşürdüğümüzü ele alıyoruz.

Genellikle tokenizer (jetonlaştırıcı), temel modelin değişmez bir özelliği olarak kabul edilir; olduğu gibi miras alınır ve dokunulmaz. Oysa tek bir alanda uzmanlaşmış bir model için tokenizer, eğitim adımından önce ayarlanabilecek en büyük maliyet kaldıraçlarından biridir.

Canlı ortamda yürüttüğümüz sistemlerden biri, Qwen3-4B üzerine inşa edilmiş, Portekizce kompozisyonları değerlendiren otomatik bir puanlayıcıdır. Bu sistem; kompozisyonu, yönergeyi ve destekleyici metinleri alır, ardından her bir yetkinlik için puan ve yorum içeren bir JSON değerlendirmesi döndürür. Modelimiz 4 milyar parametre ile zaten küçüktü ve görev için eğitilmişti. Ancak tokenizer'ı hâlâ birçok dil ve metin türü için oluşturulmuş orijinal Qwen3-4B tokenizer'ıydı. Puanlayıcıda yalnızca tek bir dil (Portekizce) ve tek bir yanıt formatı (JSON) için kullanılıyordu. Bu durum iki temel maliyet yaratıyordu:

• Puanlayıcının her istekte yazdığı metin, gerektiğinden çok daha fazla token harcıyordu.
• Üretilen her tokenda model, bu görevin neredeyse hiç kullanmadığı girişler de dahil olmak üzere 151.669 öğelik bir kelime dağarcığını puanlıyordu (skorluyordu).

Aynı temel modeli, aynı veriyi ve aynı eğitim tarifini koruyarak, VocabX adını verdiğimiz yöntemle bu kelime dağarcığını yeniden inşa ettik. (Bu makaledeki veriler henüz inceleme aşamasında olan makalenin güncel sürümünden alınmıştır ve yayın öncesinde değişebilir.)

Herkes İçin Oluşturulmuş Bir Kelime Dağarcığı#

Önde gelen dil modelleri metinleri tokenlar halinde okur ve yazar; metnin nasıl tokenlara dönüşeceğine ise tokenizer karar verir. Genel amaçlı modellerin tokenizer'ları; kaynak kodlarından sözleşmelere ve Çince metinlere kadar pek çok alan ve dilden oluşan devasa veri kümeleri üzerinde eğitilir. Genel amaçlı bir model için bu mantıklı bir seçimdir. Ancak tek bir alanda kullanılan bir model için aynı anda iki tür israfa yol açar:

• Parçalanma (Fragmentation): Tokenizer, ilgili alanın en çok tekrar ettiği ifadeleri birçok küçük parçaya böler. Bizim puanlayıcımızda her yanıt aynı JSON zarfı, aynı yetkinlik adları ve aynı değerlendirme kalıplarıyla başlar. Sözleşmelerde bu standart maddelerdir; kodlamada ise tanımlayıcılardır (identifiers). Tek bir tokenın yeteceği bu dizilerin her biri birkaç tokena mal olur ve model her istekte bunların bedelini öder.
• Fazlalık (Excess): Kelime dağarcığı, ilgili alanın asla kullanmadığı on binlerce girişi barındırır ve model ürettiği her tokenda bunların tamamı için bir olasılık skoru hesaplar. Örneğin, Amerikan okul biyoloji sınavlarını puanlamak için ince ayar yapılmış bir model neredeyse hiçbir zaman Çince yazmayacaktır; ancak yine de her adımda her bir Çince tokenın olasılığını hesaplamaya devam eder.

Yazılım Geliştirme ve Pratik Çıkarımlar#

Yapay zeka mühendisliği ve Ölçeklendirme ve Optimizasyon süreçlerinde genellikle model boyutunu küçültmeye (quantization, pruning) veya yalnızca Structured Output ve JSON Modu kullanımına odaklanılır. Ancak bu vaka analizi, üretim ortamındaki dar kapsamlı uygulamalarda asıl darboğazın tokenizer katmanında olabileceğini göstermektedir:

• Şablon Maliyetini Azaltın: Sürekli tekrar eden JSON şemaları ve alan (domain) terimleri tekil tokenlara dönüştürüldüğünde, üretilen toplam token sayısı ve gecikme süresi (latency) dramatik biçimde düşer.
• Çıkarım Hesaplamasını Hafifletin: Son katmandaki (lm_head) gereksiz dil ve sembol tokenlarını budamak, her üretim adımındaki matris çarpımı yükünü doğrudan azaltır.