LLM Çıkarım Motorları: vLLM, LMDeploy ve SGLang Karşılaştırması
NVIDIA H100 üzerinde 3 önde gelen LLM çıkarım motorunu (vLLM, LMDeploy ve SGLang) karşılaştırmalı olarak test ettik. Her motor, mimari seçimlerinin ve optimizasyon stratejilerinin gerçek performans etkisini izole etmek için Llama 3.1 8B-Instruct kullanarak 1.000 adet ShareGPT istemini içeren aynı iş yüklerini işledi.
Motorlar | En iyisi |
|---|---|
vLLM | - 100'den fazla model mimarisi üzerinde prototipleme ve deneme çalışmaları -Çoklu GPU ortamları (NVIDIA, AMD, Intel) |
LMDeploy | -Minimum karmaşıklıkla H100 performansı gerektiren üretim ortamlarında yapılan dağıtımlar -Kurulum basitliğine öncelik veren ekipler (tek satırlık pip kurulumu) |
SGLang | - Mutlak maksimum verim gerektiren kuruluşlar (16.215 tok/sn) -Özel çıkarım kümeleri |
Çıkarım motorlarının performans karşılaştırma sonuçları
İstatistiksel istikrarı sağlamak için toplam 10.000 çıkarım işlemi (motor başına 1.000 istem × 10 çalıştırma) üzerinden çevrimdışı toplu işlem verimliliğini ölçtük.
- Verim: Toplu çıkarım modunda saniyede üretilen çıktı belirteçleri. Her bir motorun H100'ün işlem gücünü ne kadar verimli kullandığını ölçer.
Tüm motorlar, maksimum teorik performansları için yapılandırıldı: Llama 3.1 8B-Instruct, bfloat16 hassasiyet ve H100 80GB donanımında 0.8 GPU bellek kullanımı.
Veri aktarım hızlarını nasıl hesapladığımızı anlamak için lütfen çıkarım kıyaslama metodolojimize bakın.
Temel bulgular
Yaklaşımımız, karıştırıcı değişkenleri en aza indirir: aynı model, donanım, veri seti, örnekleme yapılandırması, bellek sınırları ve ısınma protokolü. Bu izolasyon, her bir motorun mimarisinin gerçekte neye katkıda bulunduğunu ortaya çıkarır.
Mimari fark %29: vLLM, SGLang ile tamamen aynı çekirdeklerle (FlashInfer) optimize edildiğinde bile, liderlerin önemli ölçüde gerisinde kalıyor. SGLang (16.215 tok/s) ve LMDeploy (16.132 tok/s), tamamen optimize edilmiş vLLM'ye (12.553 tok/s) göre %29'luk bir avantajı koruyor. Bu, darboğazın artık matematiksel çekirdek değil, motorun dahili orkestrasyon yükü olduğunu gösteriyor.
SGLang ve LMDeploy neredeyse eşit performans sergiliyor: aralarındaki performans farkı %0,6'dan az ve bu da hata payı sınırları içinde kalıyor. Bu durum, hem "Python + Yerel Çekirdekler" yaklaşımının (SGLang) hem de "Saf C++ Motoru" yaklaşımının (LMDeploy) Hopper mimarilerinde en yüksek performansı elde etmek için eşit derecede geçerli stratejiler olduğunu gösteriyor.
GPU bellek "güvenli bölgesi" %80 kullanımda: %95 GPU bellek tahsis etme girişimleri, 80 GB kapasiteye rağmen tüm motorlarda CUDA Grafik derlemesi sırasında anında çökmelere neden oldu. Temel nedenin, GPU bellek sınırları değil, grafik yakalama sırasında sistem RAM'inin tükenmesi olduğu belirlendi. 0,8'lik bir oran, kararlılık ve toplu işlem boyutu arasında en uygun dengeyi sağladı.
Performans hiyerarşisini anlamak
Verim farklılıkları, H100'deki motor mimarileri arasında net bir ayrımı ortaya koymaktadır:
SGLang ve LMDeploy: Bu motorlar yaklaşık 16.200 tok/s hızına ulaşır. SGLang bunu, karmaşık sunucu modelleri için tasarlanmış özel bir bellek yöneticisi olan RadixAttention aracılığıyla başarır. LMDeploy ise bunu, Python yükünü tamamen ortadan kaldıran özel bir C++ arka ucu olan TurboMind aracılığıyla başarır.
vLLM: FlashInfer arka ucu etkinleştirilmiş olsa bile, vLLM saniyede yaklaşık 12.500 tok/s'ye kadar çıkıyor. Bu, standart yapılandırmalara göre büyük bir gelişme olsa da, kalan fark, vLLM'nin esnek, eklenti tabanlı mimarisinin (PagedAttention) liderlerin aşırı uzmanlaşmış tasarımlarına kıyasla maliyetini vurguluyor.
Mimari felsefe farklılıkları: SGLang ve LMDeploy, dikkat mekanizmalarını çekirdek varsayımlarıyla birlikte tasarlarlar. vLLM, dikkat algoritmalarının çeşitli arka uçlarla çalışmasını gerektiren daha geniş bir uyumluluk katmanına sahiptir; bu da en yeni donanımlarda belirli optimizasyonların derinliğini sınırlar.
Bellek erişim modeli optimizasyonu: %29'luk fark, SGLang ve LMDeploy'ın bellek birleştirme, önbellek yerelliği ve toplu işlem planlamasını, özellikle H100'ün Tensor Bellek Hızlandırıcısı (TMA) ile nasıl başa çıktıkları açısından, vLLM'nin planlayıcısının izin verdiğinden daha agresif bir şekilde optimize ettiğini göstermektedir.
Kıyaslama metodolojisi
Test ortamı
Donanım yapılandırması:
- GPU: NVIDIA H100 80GB HBM3
- Sistem: RunPod bulut örneği
- Docker tabanı: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Yazılım sürümleri:
- CUDA: 12.8.1
- PyTorch: 2.8.0
- vLLM: 0.11.0 (FlashInfer etkinleştirildi)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Veri kümesi ve iş yükü
Kaynak: Hugging Face'ten ShareGPT_Vicuna_unfiltered veri seti.
Seçim kriterleri:
Bu veri seti neden tercih edilmeli: ShareGPT, doğal uzunluk varyasyonuna sahip gerçek kullanıcı-chatbot konuşmalarını içerir ve sentetik kıyaslamalara kıyasla üretimdeki chatbot iş yüklerini daha doğru bir şekilde temsil eder.
Motor konfigürasyonları
Tüm motorlar, adaleti korurken maksimum performans gösterecek şekilde yapılandırılmıştır:
vLLM kurulumu (FlashInfer Arka Uç):
LMDeploy kurulumu:
SGLang kurulumu:
Ölçüm prosedürü
Tüm motorlara uygulanan standart protokol:
- Model yükleme: Modeli bfloat16 hassasiyetiyle indirin ve başlatın.
- Isınma aşaması: JIT derlemesini tetiklemek ve GPU saat hızlarını stabilize etmek için 20 komut istemini işleyin.
- Performans testi: 1.000 istemin tamamının 10 kez eksiksiz olarak çalıştırılması.
- Zamanlama metodolojisi:
- Token sayımı: Motora özgü çıktı biçimlerinden gerçek token sayılarını çıkarın.
- Veri aktarım hızı hesaplaması: toplam_çıktı_token sayısı / süre.
İstatistiksel titizlik:
- Toplam 10.000 çıkarım işlemi (motor başına 1.000 istem × 10 çalıştırma).
- Motor başına yaklaşık 1,5 milyon token üretildi.
- Tüm motorlarda standart sapma sürekli olarak ortalama değerin %1'inden az olmuştur.
Sonuçların yorumlanması
Şu sonuçlara varabilirsiniz:
H100 donanımında Llama 3.1 8B'nin çevrimdışı toplu çıkarımı için, mimari verimlilik kazananı belirliyor. En iyi çekirdeklerle (FlashInfer) bile, vLLM, SGLang veya LMDeploy'un verimliliğine ulaşamıyor. %29'luk fark, Python düzenlemesinin maliyeti ile yerel C++ optimizasyonunun maliyeti arasındaki farkı temsil ediyor.
Performans hiyerarşisi tam olarak bu senaryo için geçerlidir: 1.000 istemin aynı anda toplu işlenmesi. SGLang ve LMDeploy, standart dağıtımlara göre GPU saati başına yaklaşık %45 daha fazla değer ve yüksek düzeyde optimize edilmiş vLLM dağıtımlarına göre yaklaşık %29 daha fazla değer sağlayan sağlam seçeneklerdir.
Genelleştiremeyeceğiniz şeyler:
- Farklı modeller: Sonuçlar Llama 3.1 8B'ye özgüdür. Daha büyük modeller (örneğin, 70B) veya farklı mimariler (örneğin, Mixtral, Qwen) farklı ölçeklendirme modelleri sergileyecektir.
- Farklı donanım: Bu sıralamalar H100 80GB için geçerlidir. A100 veya V100'de, vLLM'nin taşınabilirliği SGLang'ın uzmanlaşmasının önüne geçebilir.
- Farklı ölçütler: Bu yalnızca veri aktarım hızını ölçer. Çevrimiçi sunuculuk, TTFT ve gecikme yüzdeliklerini gerektirir ve sonuçlar önemli ölçüde farklılık gösterir.
- Farklı iş yükleri: Rastgele istemler, önek önbelleklemenin faydalarını en aza indirir. Tekrarlanan sistem istemleri veya çok aşamalı konuşmalar, performans ortamını SGLang lehine önemli ölçüde değiştirir.
Geliştirici deneyimi karşılaştırması
Performans rakamları, dağıtımın tüm resmini yansıtmaz. Her motor, farklı geliştirici iş akışları sunar:
vLLM: İyi bir sebeple sektör standardı.
Sadelik, geniş uyumlulukla buluşuyor. Tek bir pip install vllm komutu, NVIDIA, AMD ve Intel donanımlarında 100'den fazla model mimarisini destekler. Geniş bir topluluk sayesinde Stack Overflow'da cevaplarınız mevcut. OpenAI uyumlu API sunucusu dahildir.
- Hızlı prototipleme, heterojen GPU ortamları, maksimum model kapsamı veya en büyük ekosistemden yararlanma gibi nedenlerle vLLM'yi tercih edin .
LMDeploy: Minimum sürtünmeyle üretim kalitesinde çözüm.
Tek satırlık kurulum (pip install lmdeploy), H100'ün en yüksek performansının %99,5'ini sunar. Yerel C++ arka ucu, sıfır Python yükü anlamına gelir. Daha fazla optimizasyon için birinci sınıf niceleme desteği (AWQ, GPTQ). Bağımlılık karmaşası yok.
- Kurulum kolaylığından veya istikrarından ödün vermeden maksimum H100 performansı gerektiren üretim ortamları için LMDeploy'u tercih edin .
SGLang: Karmaşıklık maliyetiyle performans tavanı
En yüksek verim (16.215 tok/s) bir bedel karşılığında geliyor: FlashInfer kurulumunun hata ayıklamasında önemli bir çaba gerektiriyor. Belirli bir PyTorch sürümü gerektiriyor. Bazı önceden oluşturulmuş paketlerle ikili dosya uyumsuzlukları mevcut. RadixAttention, diyalog tabanlı iş yüklerinde mükemmel performans gösteriyor.
- SGLang'ı şu durumlarda tercih edin: Bağımlılıkları yönetebilen uzman bir ekibin bulunduğu özel çıkarım kümeleri ve işlem hacminin her yüzde puanına ihtiyaç duyduğunuz durumlar.
Kurulum ve devreye alma zorlukları
Adil bir karşılaştırma, önemli mühendislik engellerinin aşılmasını gerektiriyordu:
1. Zorluk: FlashInfer bağımlılık çakışmaları
Sorun: SGLang'ın FlashInfer paketleri belirli PyTorch sürümlerini bekliyor, ancak H100 için optimize edilmiş konteynerler genellikle farklı sürümler içeriyor.
Çözünürlük:
Zaman yatırımı: Uyumlu sürümleri belirlemek için 6 saat.
Özetle: Önceden derlenmiş ML paketleri genellikle yalnızca çalışma zamanında ortaya çıkan sürüm kısıtlamalarını gizler.
2. Zorluk: vLLM'de FlashInfer'ı Etkinleştirme
Sorun: Standart vLLM sürümlerinde genellikle FlashInfer desteği bulunmamaktadır veya karmaşık kaynak kod derlemesi gerektirmektedir.
Çığır Açan Gelişme: PyTorch 2.8 Nightly üzerinde vLLM 0.11.0 sürümünü kullandık. Bu sayede, eski sürümlerin derleme engellerini aşarak, pip install “vllm[flashinfer]==0.11.0” komutuyla yerel FlashInfer desteğini başarıyla etkinleştirdik.
Etki: Bu, mümkün olan en adil karşılaştırmayı sağladı ve çekirdeklerin yardımcı olsa da mimari darboğazı çözmediğini doğruladı.
3. Zorluk: Bellek kullanımının en uygun noktasını bulma
Sorun: Standart öneri olan %0,9 GPU bellek kullanımı std::bad_alloc çökmeye neden oldu.
Test ilerlemesi:
Keşif: CUDA Grafik yakalama, GPU'nun bellek kullanımına orantılı olarak geçici sistem RAM'i tahsis eder. 0,9 × 80 GB = 72 GB GPU tahsisinde, derleme sırasında sistem RAM'i tükenir.
Pratik sınır: 80 GB donanım kapasitesine rağmen, %0,8 GPU kullanımı "güvenli bölge" olarak kabul edilir.
Çözüm
H100 üzerinde Llama 3.1 8B toplu çıkarımı için performans hiyerarşisinde iki belirgin kademe bulunmaktadır : vLLM (FlashInfer ile optimize edilmiş) sağlam bir temel sağlarken, SGLang ve LMDeploy'un C++ tabanlı mimarileri verimde ek %29'luk bir artış sağlar .
SGLang (16.215 tok/s) ve LMDeploy (16.132 tok/s) neredeyse aynı verim hızına ulaşıyor; bu da her iki motorun da H100'ün bellek bant genişliğini doyurduğunu gösteriyor. Aralarındaki minimal fark istatistiksel gürültüden kaynaklanıyor.
Üretim ortamlarına dağıtım için: LMDeploy, SGLang'in karmaşık bağımlılık çözümüne kıyasla, basit kurulumuyla (pip install lmdeploy) SGLang'in en yüksek veriminin %99,5'ini sağlayarak pratik açıdan kazanan olarak ortaya çıkıyor.
FlashInfer (12.553 tok/s) ile vLLM, cazip bir orta yol sunuyor: tam donanım uyumluluğunu ve sektörün en geniş model destek matrisini korurken saygın bir performans sağlıyor. Bununla birlikte, özel H100 kümeleri için %29'luk performans kaybı yüksek bir bedel anlamına geliyor.
Farklı altyapılar genelinde standardizasyon veya hızlı model denemeleri için vLLM mantıklı bir seçim olmaya devam ediyor. Veri aktarım hızının çok önemli olduğu özel H100 dağıtımları için ise LMDeploy'un en yüksek performans ve kurulum kolaylığının birleşimi rakipsizdir.
SSS'ler
Büyük dil modellerinin yanıt üretme biçimini optimize eden özel bir yazılım olan LLM çıkarım motoru, bu tür modellerle de çalıştırılabilir. Modelleri temel PyTorch veya TensorFlow ile çalıştırabilirsiniz, ancak çıkarım motorları verimli bellek yönetimi, birden fazla isteğin birlikte gruplandırılması ve GPU çekirdek optimizasyonları gibi kritik optimizasyonlar ekler. Bu iyileştirmeler, verimliliği (saniyede üretilen token sayısı) önemli ölçüde artırabilir ve maliyetleri düşürebilir; aynı donanımda potansiyel olarak 3-5 kat daha iyi performans sağlayabilir.
Çevrimdışı toplu çıkarım işlemleri, gerçek zamanlı gereksinimler olmadan birçok isteği aynı anda işler; örneğin binlerce belgeyi analiz etmek veya bir veri kümesi için gömme vektörleri oluşturmak gibi. Çevrimiçi sunum, katı gecikme gereksinimleriyle bireysel kullanıcı isteklerini ele alır; burada İlk Token'a Kadar Geçen Süre (TTFT) gibi metrikler, ham verimden daha önemlidir. Toplu verimde en iyi performansı gösteren motor, etkileşimli sohbet botları için en uygun olmayabilir, bu nedenle gerçek iş yükü modelinize göre seçim yapın.
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.