← Blog'a dön

vLLM ve Transformers Backend: Native Hızda Çalışan Yeni Nesil LLM Çıkışı

Transformers modeling backend artık vLLM'de el ile yazılmış implementasyonlar kadar hızlı. Qwen3 benchmark sonuçları, tek bir bayrakla native performans elde edildiğini gösteriyor.

vLLM ve Transformers Backend: Native Hızda Çalışan Yeni Nesil LLM Çıkışı

vLLM ve Transformers Backend: Native Hızda Çalışan Yeni Nesil LLM Çıkışı

Üretken yapay zeka modellerini production ortamında çalıştırırken en büyük darboğaz inference hızıdır. Transformers kütüphanesi 450'ten fazla mimariyi desteklerken, vLLM de sürekli batching ve özel attention çekirdekleriyle yüksek throughput sunuyor. Şimdi bu iki güç birleşiyor: transformers modelleri, vLLM'de tek bir bayrakla, el ile yazılmış özel implementasyonlar kadar hızlı çalışabilir hale geldi.

Bu yazıda transformers modeling backend'in vLLM'deki son güncellemesini, nasıl çalıştığını, Qwen3 modelleriyle elde edilen benchmark sonuçlarını ve üretim ortamına etkilerini inceleyeceğiz.

Sorun: Her Model İçin Ayrı vLLM Implementasyonu

ML ekosisteminde yeni bir model yayımlandığında, topluluk o modeli farklı çerçevelerde çalışır hale getirmek için büyük çaba harcar. Bir model transformers'a eklendikten sonra, vLLM'de de yüksek performansla çalışması için ayrı bir implementasyon yazılması gerekirdi. Bu süreç haftalar sürebiliyordu ve her güncellemeyle birlikte bakım maliyeti de artıyordu.

Model yazarları için bu durum özellikle can sıkıcıydı. Bir modeli transformers'a eklemek zaten başlı başına bir işti. Üstüne vLLM için de özel optimizasyonlarla yeniden yazmak gerekiyordu. Her framework kendi kod tabanını sürdürürken, hata düzeltmeleri ve iyileştirmeler senkronize edilmeliydi.

Eski pipeline: transformers ve vLLM için ayrı ayrı entegrasyon

Görseldeki eski akışı görüyoruz: model yazarı önce transformers'a entegre ediyor, sonra vLLM için özel optimizasyonlarla ayrı bir implementasyon yazmak zorunda kalıyordu. Bu, hem zaman hem de bakım maliyeti anlamına geliyordu. Özellikle son dönemde haftada ortalama 3 yeni modelin eklendiği bir ekosistemde, bu maliyet katlanarak büyüyor.

Çözüm: Tek Entegrasyon, Çift Performans

Hugging Face ekibi transformers modeling backend'i vLLM'de o kadar geliştirdi ki, artık transformers'a eklenen herhangi bir model doğrudan vLLM'de çalıştırılabilir ve el ile yazılmış vLLM implementasyonlarıyla aynı (veya daha iyi) performansı verir.

Yeni pipeline: transformers entegrasyonu ile vLLM'de native hız

Yeni akışta model yalnızca transformers'a ekleniyor ve vLLM'de otomatik olarak native hızda çalışıyor. Model yazarının ekstra bir şey yapmasına gerek kalmıyor. Bu, transformers'ın 450+ mimari desteğinin vLLM ekosistemine otomatik olarak aktarılması demek.

Geçmiş: İlk Entegrasyon ve Sınırlılıkları

Transformers ve vLLM entegrasyonu aslında geçen yıl başlamıştı. O dönemde transformers model implementasyonlarının vLLM'de çalışması için bir köprü kurulmuştu. Ancak bu köprü yalnızca attention mekanizmasını optimize ediyordu. Yani transformers modelleri vLLM'de çalışabiliyordu ama el ile yazılmış implementasyonlar kadar hızlı değildi.

Model yazarları en iyi performansı istediklerinde yine özel vLLM implementasyonları yazıyordu. Bu durum, transformers backend'in "iyi ama yeterince iyi değil" algısına yol açmıştı. Yeni güncelleme bu algıyı tamamen değiştiriyor.

Nasıl Çalışıyor? torch.fx ve AST Manipülasyonu

Bu güncellemenin temelinde iki Python teknolojisi yer alıyor:

  • torch.fx: PyTorch'un graf analiz aracı. Modelin hesaplama grafiğini statik olarak analiz ediyor ve optimize edilebilir kalıpları tespit ediyor. Bu araç, model kodunu çalıştırmadan önce yapısını anlayabiliyor.
  • AST (Abstract Syntax Tree): Python'un soyut sözdizim ağacı. Belirlenen kalıpları kaynak kod üzerinde yeniden yazmak için kullanılıyor. Kaynak kod manipülasyonu sayesinde model kodu orijinal yapısını koruyor ama runtime'da optimize edilmiş versiyona dönüşüyor.

Sistem şu adımları izliyor:

  1. Modelin graf yapısı torch.fx ile analiz ediliyor ve hesaplama akışı çıkarılıyor.
  2. Bilinen optimizasyon kalıpları (örneğin birleştirilebilir doğrusal katmanlar, MoE uzman katmanları) tespit ediliyor.
  3. AST ile kaynak kod manipüle ediliyor ve operasyonlar yerinde yeniden yazılıyor.
  4. Dönüştürülen model, vLLM'in özel çekirdekleriyle uyumlu hale geliyor ve derleme aşamasına geçiyor.

Bu süreç runtime'da, yani model yükleme sırasında gerçekleşiyor. Model kodunda elle değişiklik yapılmasına gerek yok. Kullanıcı açısından tamamen şeffaf.

Hangi Optimizasyonlar Uygulanıyor?

Fused Operations (Birleştirilmiş Operasyonlar)

vLLM'in (ultra) optimize edilmiş çekirdekleriyle eşleştirilen birleştirilmiş operasyonlar uygulanıyor. Bunların en önemlileri:

  • MergedColumnParallelLinear: Birden fazla doğrusal katmanı tek bir paralel operasyonda birleştiriyor. Bu, GPU bellek erişimlerini azaltıyor ve hesaplama verimliliğini artırıyor.
  • QKVParallelLinear: Query, Key ve Value projeksiyonlarını tek bir paralel blokta çalışıyor. Attention mekanizmasının en kritik kısmını optimize ediyor.
  • Expert Parallelization (EP): Mixture-of-Experts modellerinde uzman paralelizasyonu için özel çekirdekler. 235B parametreli gibi büyük MoE modellerinde kritik öneme sahip.

Paralelizasyon Planları

Birleştirilmiş operasyonlar sayesinde sistem otomatik olarak tensor paralel (TP) ve pipeline paralel (PP) planları çıkarabiliyor. Decoder blok listesi kolayca tanımlanabildiğinde, pipeline paralel planları da otomatik oluşturuluyor. Bu, çoklu GPU kurulumlarında elle yapılandırma ihtiyacını ortadan kaldırıyor.

Derleme Uyumluluğu

Dönüştürülen modeller tamamen torch.compile ve CUDA Graphs ile uyumlu kalıyor. Yani vLLM'in el ile yazılmış modelleri hangi derleme optimizasyonlarından yararlanıyorsa, transformers backend de aynısını alıyor. Bu, compile edilmiş modellerin ek %20-30 performans kazancı anlamına gelebiliyor.

Çift Yönlü Kullanım

Transformers model implementasyonları eğitimde de kullanılabilir. Aynı model koduyla eğitim, değerlendirme ve RL rollout'ları yapılabiliyor. vLLM model implementasyonları ise yalnızca inference'a yöneliktir. Bu, araştırma ekiplerinin tek bir kod tabanıyla hem eğitim hem de serving yapabilmesi anlamına geliyor.

Benchmark Sonuçları: Qwen3 ile Karşılaştırma

Hugging Face ekibi, transformers backend'i el ile yazılmış native vLLM implementasyonlarıyla karşılaştırmak için üç farklı Qwen3 modeli kullandı. Her model, yalnızca kod yolunun farklı olduğu, diğer her şeyin aynı olduğu üç koşulda test edildi:

  • native: --model-impl vllm, vLLM'in el ile yazılmış modeli (karşılaştırma referansı).
  • after: --model-impl transformers PR ile birlikte (yeni backend).
  • before: --model-impl transformers PR olmadan (eski backend).

Test edilen modeller:

  • Qwen3-4B: 4 milyar parametreli dense model, tek GPU üzerinde. Edge deployment senaryolarına yakın.
  • Qwen3-32B: 32 milyar parametreli dense model, tensor paralelizasyon ile 2 GPU üzerinde. Orta ölçekli kurumsal kullanım.
  • Qwen3-235B-A22B-FP8: 235 milyar parametreli Mixture-of-Experts modeli, veri + uzman paralelizasyonu ile 8xH100 düğümünde. Büyük ölçekli serving.

Qwen3 modelleriyle transformers ve native vLLM karşılaştırması

Sonuçlar açık: transformers modeling backend, her üç modelde de native throughput'u karşılıyor veya geçiyor. Üstelik bu, tek bir --model-impl transformers bayrağıyla elde ediliyor. Tekrarlanabilirlik için tüm test betikleri bir Gist olarak yayımlanmış durumda.

Kullanım: Tek Bayrakla Başlangıç

Herhangi bir Hugging Face modelini transformers backend ile çalıştırmak için tek bir bayrak yeterli:

# vLLM pip paketini yükseltin
uv pip install --upgrade vllm --torch-backend auto

# Tek GPU ile serving
vllm serve Qwen/Qwen3-4B --model-impl transformers

Çoklu GPU kurulumları için paralelizasyon seçenekleri aynı şekilde çalışır:

# 2 GPU ile tensor paralel
vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2

# 8 GPU ile veri + uzman paralel
vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel

Servis kurulumunuzda başka hiçbir şey değişmiyor. Mevcut paralelizasyon ayarlarınız, OpenAI uyumlu API'niz ve batching stratejiniz aynı kalıyor. --max-model-len parametresiyle bellek kısıtlı düğümlerde context uzunluğunu da ayarlayabilirsiniz.

Ekosistem Bağlamında Bu Ne Anlama Geliyor?

Transformers kütüphanesi son birkaç yıldır ML ekosisteminin referans modelleme kütüphanesi haline geldi. Resmi blog yazısında belirtildiği gibi, transformers artık bir "model tanımlama kütüphanesi" olarak konumlanıyor: bir model transformers'da destekleniyorsa, tüm ekosistemde (vLLM, SGLang, MLX, llama.cpp) kullanılabilir olması hedefleniyor.

Bu güncelleme o vizyonun somut bir adımı. Artık model yazarları:

  1. Modelini transformers'a ekliyor.
  2. vLLM'de --model-impl transformers ile native hızda inference alıyor.
  3. Ekstra vLLM implementasyonu yazmak zorunda kalmıyor.
  4. Aynı kodla eğitim ve değerlendirme de yapabiliyor.

Bu, kurumsal LLM dağıtımı yapan ekipler için de önemli. Yeni modelleri production'a almak için geçen süre dramatik şekilde kısalıyor. Bir model transformers'a eklendiği gün vLLM'de de native hızda çalışabilir hale geliyor.

vLLM'in Büyük Ölçekli Serving Optimizasyonları

Bu transformers backend güncellemesi, vLLM'in genel performans yolculuğunun bir parçası. vLLM'in büyük ölçekli serving yazısına göre, DeepSeek tarzı MoE modellerinde 2.2k tok/s/H200 throughput'a ulaşılmış durumda. Wide-EP, Dual-batch Overlap (DBO), Expert Parallel Load Balancing (EPLB) ve ayrıştırılmış serving gibi optimizasyonlar, inference maliyetlerini düşürüyor.

Transformers backend'in bu optimizasyonlarla uyumlu çalışması, model yazarlarının bu avantajlardan otomatik olarak yararlanabileceği anlamına geliyor. MoE modellerindeki Expert Parallelization desteği, DeepSeek benzeri büyük modellerin bile transformers backend ile verimli şekilde çalıştırılabileceğini gösteriyor.

Kısıtlamalar ve Dikkat Edilmesi Gerekenler

  • Lineer attention modelleri şu anda desteklenmiyor, ancak yakında eklenecek. Bu, bazı araştırma amaçlı modellerin kapsam dışı kalmasına neden olabilir.
  • Hub üzerindeki özel modeller (kodları bir Hub reposunda yaşayan) uyumlu yazılmadıysa çalışmayabilir. Bu modellerin transformers uyumluluk kurallarına uyması gerekiyor.
  • Performans kazancı, modelin mimari yapısına bağlı. Bazı modellerde kazanç büyük, bazılarında daha az belirgin olabilir.
  • Tüm modeller için otomatik paralelizasyon planı çıkarılamayabilir, ancak desteklenen mimari sayısı sürekli artıyor.

Küçük dil modelleri konusunda da bu gelişme önemli: edge cihazlarında çalışacak modelleri optimize etmek için transformers backend + vLLM kombinasyonu kullanılabilir.

Sonuç

Transformers modeling backend'in vLLM'de native hıza ulaşması, ML ekosisteminde bir dönüm noktası. Model yazarları artık tek bir entegrasyonla hem transformers hem de vLLM desteğini alıyor. El ile yazılmış vLLM implementasyonlarına olan ihtiyaç azalıyor ve yeni modellerin production'a alınma süresi kısalıyor.

torch.fx ve AST manipülasyonu gibi tekniklerle runtime'da uygulanan optimizasyonlar, transformers kodunu vLLM'in özel çekirdekleriyle uyumlu hale getiriyor. Qwen3 modelleriyle elde edilen benchmark sonuçları, bu yaklaşımın pratikte de işe yaradığını gösteriyor. 4B'den 235B'ye kadar farklı ölçeklerdeki modellerde native performans elde edilmesi, bu teknolojinin olgunlaştığının kanıtı.

Eğer LLM inference performansını artırıyorsanız, transformers backend'i denemek için uv pip install --upgrade vllm --torch-backend auto komutuyla güncelleyin ve --model-impl transformers bayrağını ekleyin. Sonuçlar sizi memnun edecektir.

Bu konuyla ilgili sorularınız veya deneyimleriniz varsa yorumlarda paylaşabilirsiniz. Yapay zeka ve yazılım geliştirme dünyasındaki gelişmeleri takip etmek için blog sayfamıza göz atın.


Modelin çalışma prensipleri ve benchmark verileri Hugging Face resmi blogundan ve vLLM blogundan derlenmiştir.

Efe Hüseyin Özkan

Yazılım Mühendisi & AI Geliştirici

Yapay zeka sistemleri, full-stack geliştirme ve ölçeklenebilir ürün mimarisi üzerine çalışıyor. Daha fazla teknik yazı için blogu takip edebilirsiniz.