LLM Çıkarım Motorları: vLLM vs LMDeploy vs SGLang
NVIDIA H100 üzerinde 3 lider LLM çıkarım motorunu kıyasladık: vLLM, LMDeploy ve SGLang. Her motor, mimari tercihlerinin ve optimizasyon stratejilerinin gerçek performans etkisini yalıtmak için aynı iş yüklerini işledi: Llama 3.1 8B-Instruct kullanarak 1.000 ShareGPT prompt'u.
Motorlar | En iyi kullanım alanı |
|---|---|
vLLM | 100'den fazla model mimarisinde prototipleme ve deneme Çoklu GPU ortamları (NVIDIA, AMD, Intel) |
LMDeploy | Minimum karmaşıklıkla H100 performansı gerektiren üretim dağıtımları Kurulum basitliğini önceliklendiren ekipler (tek satır pip install) |
SGLang | Mutlak maksimum verimlilik gerektiren kuruluşlar (16.215 tok/s) Özel çıkarım kümeleri |
Çıkarım motorları kıyaslama sonuçları
İstatistiksel kararlılığı sağlamak için 10.000 toplam çıkarım işlemi (1.000 prompt × motor başına 10 çalıştırma) boyunca çevrimdışı toplu iş verimliliğini ölçtük.
- Verimlilik: Toplu çıkarım modunda saniyede üretilen çıktı token'ları. Her motorun H100'ün hesaplama yeteneklerini 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 hassasiyeti ve H100 80GB donanımda 0,8 GPU bellek kullanımı.
Verimlilik oranları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 limitleri ve ısınma protokolü. Bu yalıtım, her motorun mimarisinin gerçekten ne kattığını ortaya çıkarır.
Mimari fark %29: vLLM, SGLang ile 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'e (12.553 tok/s) karşı %29 avantaj sağlıyor. Bu, darboğazın artık matematiksel çekirdek değil, motorun dahili orkestrasyon yükü olduğunu gösteriyor.
SGLang ve LMDeploy etkin şekilde eşit: aralarındaki performans farkı %0,6'dan az ve bu da hata payı içinde kalıyor. Bu, 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 belleğinde %80 kullanımda "güvenli bölge": 80GB kapasiteye rağmen %95 GPU belleği ayırma girişimleri, tüm motorlarda CUDA Graph derlemesi sırasında anında çökmelere neden oldu. Temel neden, GPU bellek limitleri değil, graph yakalama sırasında sistem RAM'inin tükenmesi olarak belirlendi. 0,8 oranı, kararlılık ve toplu iş boyutu arasında optimum dengeyi sağladı.
Performans hiyerarşisini anlamak
Verimlilik farkları, H100 üzerinde motor mimarileri arasında net bir ayrım ortaya koyuyor:
SGLang & LMDeploy: Bu motorlar ~16.200 tok/s değerine ulaşıyor. SGLang bunu, karmaşık sunum desenleri için tasarlanmış özel bir bellek yöneticisi olan RadixAttention ile başarıyor. LMDeploy bunu, Python yükünü tamamen ortadan kaldıran özel bir C++ arka ucu olan TurboMind ile başarıyor.
vLLM: FlashInfer arka ucu etkinleştirildiğinde bile vLLM ~12.500 tok/s seviyesinde zirve yapıyor. Bu, standart yapılandırmalara göre büyük bir iyileştirme olsa da, kalan fark vLLM'in esnek, eklenti tabanlı mimarisinin (PagedAttention) liderlerin aşırı özelleşmiş tasarımlarına kıyasla maliyetini vurguluyor.
Mimari felsefe farkları: SGLang ve LMDeploy, dikkat mekanizmalarını çekirdek varsayımlarıyla birlikte tasarlıyor. vLLM, dikkat algoritmalarının çeşitli arka uçlarla çalışmasını gerektiren daha geniş bir uyumluluk katmanı sürdürüyor ve bu da en yeni donanımlarda belirli optimizasyonların derinliğini sınırlıyor.
Bellek erişim deseni optimizasyonu: %29'luk fark, SGLang ve LMDeploy'un özellikle H100'ün Tensor Memory Accelerator (TMA) özelliğini kullanma şekillerinde, bellek birleştirme, önbellek yerelliği ve toplu iş zamanlamasını vLLM'in zamanlayıcısının izin verdiğinden daha agresif şekilde optimize ettiğini gösteriyor.
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 etkin)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Veri seti ve iş yükü
Kaynak: Hugging Face'ten ShareGPT_Vicuna_unfiltered veri seti
Seçim kriterleri:
Neden bu veri seti: ShareGPT, doğal uzunluk varyasyonuna sahip gerçek kullanıcı-chatbot konuşmalarını içerir ve üretim chatbot iş yüklerini sentetik kıyaslamalardan daha doğru şekilde temsil eder.
Motor yapılandırmaları
Tüm motorlar, adilliği korurken maksimum performans için yapılandırıldı:
vLLM kurulumu (FlashInfer Arka Ucu):
LMDeploy kurulumu:
SGLang kurulumu:
Ölçüm prosedürü
Tüm motorlara uygulanan standart protokol:
- Model yükleme: Modeli bfloat16 hassasiyetiyle indir ve başlat.
- Isınma aşaması: JIT derlemesini tetiklemek ve GPU saatlerini dengelemek için 20 prompt işle.
- Kıyaslama çalıştırmaları: Tüm 1.000 prompt'un 10 tam geçişini yürüt.
- Zamanlama metodolojisi:
- Token sayımı: Motora özgü çıktı formatlarından gerçek token sayılarını çıkar.
- Verimlilik hesaplaması: toplam_çıktı_token'ları / süre.
İstatistiksel titizlik:
- 10.000 toplam çıkarım işlemi (1.000 prompt × motor başına 10 çalıştırma).
- Motor başına ~1,5 milyon token üretildi.
- Tüm motorlarda standart sapma sürekli olarak ortalamanın %1'inden az.
Sonuçların yorumlanması
Çıkarabileceğiniz sonuçlar:
H100 donanımda Llama 3.1 8B'nin çevrimdışı toplu çıkarımı için, kazananı mimari verimlilik belirler. Mümkün olan en iyi çekirdeklerle (FlashInfer) bile vLLM, SGLang veya LMDeploy'un verimliliğine yetişemez. %29'luk fark, Python orkestrasyonunun yerel C++ optimizasyonuna kıyasla maliyetini temsil eder.
Performans hiyerarşisi tam olarak bu senaryoya uygulanır: 1.000 prompt'un aynı anda toplu işlenmesi. SGLang ve LMDeploy, standart dağıtımlara göre GPU saati başına ~%45 daha fazla değer ve yüksek düzeyde optimize edilmiş vLLM dağıtımlarına göre ~%29 daha fazla değer sunan sağlam seçeneklerdir.
Genelleme yapamayacağınız noktalar:
- Farklı modeller: Sonuçlar Llama 3.1 8B'ye özeldir. Daha büyük modeller (ör. 70B) veya farklı mimariler (ör. Mixtral, Qwen) farklı ölçeklenme desenleri sergileyecektir.
- Farklı donanım: Bu sıralamalar H100 80GB için geçerlidir. A100 veya V100'de, vLLM'in taşınabilirliği SGLang'in uzmanlaşmasından daha ağır basabilir.
- Farklı metrikler: Bu yalnızca verimliliği ölçer. Çevrimiçi sunum, sonuçların önemli ölçüde farklılık gösterdiği TTFT ve gecikme yüzdeliklerini gerektirir.
- Farklı iş yükleri: Rastgele prompt'lar, ön ek önbelleklemenin faydalarını en aza indirir. Tekrarlanan sistem prompt'ları veya çok turlu konuşmalar, performans tablosunu SGLang lehine önemli ölçüdeğiştirir.
Geliştirici deneyimi karşılaştırması
Performans rakamları dağıtımın tam resmini yakalamaz. Her motor farklı geliştirici iş akışları sunar:
vLLM: Haklı sebeplerle endüstri standardı
Basitlik, geniş uyumlulukla buluşur. Tek pip install vllm, NVIDIA, AMD ve Intel donanımlarında 100'den fazla model mimarisini destekler. Büyük bir topluluk, Stack Overflow'da cevaplarınızın olması anlamına gelir. OpenAI-uyumlu API sunucusu dahildir.
- vLLM'i şunlar için seçin: Hızlı prototipleme, heterojen GPU ortamları, maksimum model kapsamı veya en büyük ekosistemden yararlanma.
LMDeploy: Minimum sürtünmeyle üretim sınıfı
Tek satır kurulum (pip install lmdeploy), H100 zirve 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 kuantization desteği (AWQ, GPTQ). Bağımlılık cehennemi yaşanmaz.
- LMDeploy'u kurulum basitliğinden veya kararlılıktan ödün vermeden maksimum H100 performansı gerektiren üretim dağıtımları için seçin.
SGLang: Karmaşıklık maliyetiyle performans tavanı
Mutlak zirve verimlilik (16.215 tok/s) bir bedelle gelir: FlashInfer kurulumunda hata ayıklamak için önemli çaba. Belirli bir PyTorch sürümü gerektirir. Bazı önceden derlenmiş wheel'lerle ikili uyumsuzluklar. RadixAttention, konuşma tabanlı iş yüklerinde parlıyor.
- SGLang'i şunlar için seçin: Uzman bir ekibin bağımlılıkları yönetebileceği ve verimliliğin her yüzde puanına ihtiyaç duyduğunuz özel çıkarım kümeleri.
Kurulum ve dağıtım zorlukları
Adil karşılaştırma, önemli mühendislik engellerinin aşılmasını gerektirdi:
Zorluk 1: FlashInfer bağımlılık çakışmaları
Sorun: SGLang'in FlashInfer wheel'leri belirli PyTorch sürümleri bekler, ancak H100 için optimize edilmiş konteynerler genellikle farklı sürümlerle gelir.
Çözüm:
Zaman yatırımı: Uyumlu sürümleri belirlemek için 6 saat.
Çıkarım: Önceden derlenmiş ML wheel'leri genellikle yalnızca çalışma zamanında ortaya çıkan sürüm kısıtlamalarını gizler.
Zorluk 2: vLLM'de FlashInfer'i etkinleştirme
Sorun: Standart vLLM sürümleri genellikle FlashInfer desteğinden yoksundur veya karmaşık kaynak derlemesi gerektirir.
Atılım: PyTorch 2.8 Nightly üzerinde vLLM 0.11.0 derlemesini kullandık. Bu, pip install "vllm[flashinfer]==0.11.0" aracılığıyla yerel FlashInfer desteğini başarıyla etkinleştirerek eski sürümlerin derleme engellerini aştı.
Etki: Bu, çekirdekler yardımcı olsa da mimari darboğazı çözmediklerini doğrulayarak mümkün olan en adil karşılaştırmayı sağladı.
Zorluk 3: Bellek kullanımı optimum noktasının keşfi
Sorun: 0,9 GPU bellek kullanımı şeklindeki standart öneri std::bad_alloc çökmelerine neden oldu.
Test ilerlemesi:
Keşif: CUDA Graph yakalama, GPU'nun bellek kullanımıyla orantılı geçici sistem RAM'i tahsis eder. 0,9 × 80GB = 72GB GPU tahsisinde, derleme sırasında sistem RAM'i tükenir.
Pratik limit: 80GB donanım kapasitesine rağmen 0,8 GPU kullanımı "güvenli bölge"dir.
Sonuç
H100 üzerinde Llama 3.1 8B toplu çıkarımı için, performans hiyerarşisinin iki net kademesi var: vLLM (FlashInfer ile optimize edilmiş) sağlam bir temel sağlarken, SGLang ve LMDeploy'un C++-yerel mimarileri verimlilikte ek bir %29 daha açığa çıkarıyor.
SGLang (16.215 tok/s) ve LMDeploy (16.132 tok/s) neredeyse aynı verimliliğe 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üdür.
Üretim dağıtımları için: LMDeploy, SGLang'in karmaşık bağımlılık çözümüne karşılık önemsiz kurulumla (pip install lmdeploy) SGLang'in zirve verimliliğinin %99,5'ini sunarak pratik kazanan olarak öne çıkıyor.
FlashInfer ile vLLM (12.553 tok/s) cazip bir orta yol sunuyor: tam donanım uyumluluğunu ve sektörün en büyük model destek matrisini korurken saygın bir performans. Ancak, özel H100 kümeleri için masada %29 performans bırakmak yüksek bir maliyettir.
Heterojen altyapıda standardizasyon veya hızlı model denemeleri için vLLM rasyonel seçim olmaya devam ediyor. Verimliliğin en önemli olduğu özel H100 dağıtımları için, LMDeploy'un zirve performans ve kurulum basitliği kombinasyonu rakipsizdir.
Tercih edilen kaynak olarak ekleSSS'ler
Bir LLM çıkarım motoru, büyük dil modellerinin yanıt üretme şeklini optimize eden özel bir yazılımdır. Modelleri temel PyTorch veya TensorFlow ile çalıştırabilirsiniz, ancak çıkarım motorları verimli bellek yönetimi, birden fazla isteği birlikte toplu işleme ve GPU çekirdek optimizasyonları gibi kritik iyileştirmeler ekler. Bu geliştirmeler verimliliği (saniyede üretilen token) önemli ölçüde artırabilir ve maliyetleri düşürebilir, aynı donanımda potansiyel olarak 3-5x daha iyi performans sunabilir.
Çevrimdışı toplu çıkarım, gerçek zamanlı gereksinimler olmadan birçok prompt'u aynı anda işler; binlerce belgeyi analiz etmek veya bir veri seti için embedding'ler oluşturmak gibi düşünün. Çevrimiçi sunum, İlk Token'a Kadar Geçen Süre (TTFT) gibi metriklerin ham verimlilikten daha önemli olduğu katı gecikme gereksinimleriyle bireysel kullanıcı isteklerini işler. Toplu verimlilikte kazanan motor, etkileşimli chatbot'lar için optimal olmayabilir, bu nedenle gerçek iş yükü deseninize göre seçim yapın
Bu araştırmayı kaynak gösterin
Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{LLM Çıkarım Motorları: vLLM vs LMDeploy vs SGLang}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/inference-engines}},
note = {AIMultiple. Erişim tarihi: 15 Nisan 2026}
}
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.