LLM Çıkarım Motorları: vLLM vs LMDeploy vs SGLang
NVIDIA H100 üzerinde önde gelen 3 LLM çıkarım motorunu kıyasladık: vLLM, LMDeploy ve SGLang. Her motor aynı iş yüklerini işledi: mimari seçimlerinin ve optimizasyon stratejilerinin gerçek performans etkisini izole etmek için Llama 3.1 8B-Instruct kullanarak 1.000 ShareGPT prompt'lar.
Motorlar | En iyi kullanım alanı |
|---|---|
vLLM | -100+ 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ğine öncelik veren ekipler (tek satırlık pip install) |
SGLang | -Mutlak maksimum verimlilik gerektiren kuruluşlar (20">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'lar × motor başına 10 çalıştırma) boyunca çevrimdışı toplu verimliliği ö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 hassasiyet 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 izolasyon, her motorun mimarisinin gerçekte ne kattığını ortaya çıkarır.
Mimari fark %29: vLLM, SGLang ile tamamen aynı çekirdeklerle (FlashInfer) optimize edildiğinde bile liderlerin önemli ölçüde gerisinde kalır. SGLang (16.215 tok/s) ve LMDeploy (16.132 tok/s), tamamen optimize edilmiş vLLM'e (12.553 tok/s) karşı %29 avantaj sağlar. Bu, darboğazın artık matematiksel çekirdek değil, motorun dahili orkestrasyon ek yükü olduğunu gösterir.
SGLang ve LMDeploy fiilen eşit: aralarındaki performans farkı %0,6'dan azdır ve bu hata payı dahilindedir. 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 performansa ulaşmak için eşit derecede geçerli stratejiler olduğunu gösterir.
%80 kullanımda GPU bellek "güvenli bölge": %95 GPU belleği ayırma girişimleri, 80GB kapasiteye rağmen tüm motorlarda CUDA Graph derlemesi sırasında anında çökmelere neden oldu. Temel neden, GPU bellek limitleri değil, grafik yakalama sırasında sistem RAM'inin tükenmesi olarak belirlendi. 0,8 oranı, kararlılık ve toplu iş boyutu arasında en uygun dengeyi sağladı.
Performans hiyerarşisini anlamak
Verimlilik farkları, H100 üzerindeki motor mimarileri arasında net bir ayrım ortaya koyar:
SGLang & LMDeploy: Bu motorlar ~16.200 tok/s değerine ulaşır. SGLang bunu, karmaşık sunum desenleri için tasarlanmış özel bir bellek yöneticisi olan RadixAttention ile başarır. LMDeploy bunu, Python ek yükünü tamamen ortadan kaldıran özel bir C++ arka ucu olan TurboMind ile başarır.
vLLM: FlashInfer arka ucu etkinleştirildiğinde bile vLLM ~12.500 tok/s değerinde zirve yapar. 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 vurgular.
Mimari felsefe farkları: SGLang ve LMDeploy, dikkat mekanizmalarını çekirdek varsayımlarıyla birlikte tasarlar. vLLM, dikkat algoritmalarının çeşitli arka uçlarla çalışmasını gerektiren daha geniş bir uyumluluk katmanı sürdürür ve bu da en son donanımdaki belirli optimizasyonların derinliğini sınırlar.
Bellek erişim deseni optimizasyonu: %29'luk fark, SGLang ve LMDeploy'un özellikle H100'ün Tensor Memory Accelerator (TMA) özelliğini nasıl işledikleri konusunda, bellek birleştirme, önbellek yerelliği ve toplu zamanlamayı vLLM'in zamanlayıcısının izin verdiğinden daha agresif bir şekilde optimize ettiğini gösterir.
Kıyaslama metodolojisi
Test ortamı
Donanım yapılandırması:
- GPU: NVIDIA H100 80GB HBM3
- Sistem: RunPod bulut örneği
- Docker temeli: 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:
Bu veri seti neden: ShareGPT, sentetik kıyaslamalardan daha doğru bir şekilde üretim chatbot'lar iş yüklerini temsil eden, doğal uzunluk değişimine sahip gerçek kullanıcı-chatbot'lar konuşmalarını içerir.
Motor yapılandırmaları
Tüm motorlar adaleti 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 hassasiyetle indir ve başlat.
- Isınma aşaması: JIT derlemesini tetiklemek ve GPU saatlerini dengelemek için 20 prompt'lar işle.
- Kıyaslama çalıştırmaları: Tüm 1.000 prompt'lar 10 tam geçişini gerçekleştir.
- Zamanlama metodolojisi:
- Token sayımı: Motora özgü çıktı formatlarından gerçek token sayılarını çıkar.
- Verimlilik hesaplaması: toplam_çıktı_token / süre.
İstatistiksel titizlik:
- 10.000 toplam çıkarım işlemi (1.000 prompt'lar × 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'i.
Sonuçların yorumlanması
Çıkarabileceğiniz sonuçlar:
H100 donanımında Llama 3.1 8B'in ç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 ulaşamaz. %29'luk fark, Python orkestrasyonunun yerel C++ optimizasyonuna karşı maliyetini temsil eder.
Performans hiyerarşisi tam olarak bu senaryo için geçerlidir: 1.000 prompt'lar aynı anda toplu işleme. SGLang ve LMDeploy, standart dağıtımlara kıyasla GPU saati başına ~%45 ve yüksek düzeyde optimize edilmiş vLLM dağıtımlarına kıyasla ~%29 daha fazla değer sunan sağlam seçimlerdir.
Genelleme yapamayacağınız noktalar:
- Farklı modeller: Sonuçlar Llama 3.1 8B'e özeldir. Daha büyük modeller (örn. 70B) veya farklı mimariler (örn. Mixtral, Qwen) farklı ölçekleme 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ılaştığı TTFT ve gecikme yüzdeliklerini gerektirir.
- Farklı iş yükleri: Rastgele prompt'lar, ön ek önbelleklemenin faydalarını en aza indirir. Tekrarlanan sistem istemleri veya çok turlu konuşmalar, performans manzarasını SGLang lehine büyük ölçüde değiştirir.
Geliştirici deneyimi karşılaştırması
Performans rakamları tam dağıtım resmini yakalamaz. Her motor farklı geliştirici iş akışları sunar:
vLLM: İyi bir nedenle sektör standardı
Basitlik geniş uyumlulukla buluşur. Tek bir pip install vllm, NVIDIA, AMD ve Intel donanımında 100+ 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ı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 ek yükü anlamına gelir. Daha fazla optimizasyon için birinci sınıf kuantization desteği (AWQ, GPTQ). Bağımlılık cehennemi yok.
- LMDeploy'u şunlar için seçin Kurulum basitliğinden veya kararlılıktan ödün vermeden maksimum H100 performansı gerektiren üretim dağıtımları.
SGLang: Karmaşıklık maliyetiyle performans tavanı
Mutlak en yüksek 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 parlar.
- SGLang'i şunlar için seçin: Uzman bir ekibin bağımlılıkları yönetebileceği ve verimliliğin her son yüzdelik puanına ihtiyaç duyduğunuz özel çıkarım kümeleri.
Tercih edilen kaynak olarak ekleKurulum ve dağıtım zorlukları
Adil bir 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ümlerini 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 üzerindeki vLLM 0.11.0 yapısını kullandık. Bu, eski sürümlerin derleme engellerini aşarak pip install "vllm[flashinfer]==10">0.11.0" aracılığıyla yerel FlashInfer desteğini başarıyla etkinleştirdi.
Etki: Bu, çekirdeklerin yardımcı olduğunu ancak mimari darboğazı çözmediğini doğrulayarak mümkün olan en adil karşılaştırmayı sağladı.
Zorluk 3: Bellek kullanımı ideal noktasının keşfi
Sorun: 0,9 GPU bellek kullanımı standart önerisi 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 vardır: vLLM (FlashInfer ile optimize edilmiş) sağlam bir temel sağlarken, SGLang ve LMDeploy'un C++-yerel mimarileri verimlilikte ek bir %29 daha fazlasını ortaya çıkarır.
SGLang (16.215 tok/s) ve LMDeploy (16.132 tok/s) neredeyse aynı verimliliğe ulaşır, bu da her iki motorun da H100'ün bellek bant genişliğini doyurduğunu gösterir. Aralarındaki minimum fark istatistiksel gürültüdür.
Üretim dağıtımları için: LMDeploy, SGLang'in en yüksek verimliliğinin %99,5'ini basit kurulumla (pip install lmdeploy) sunarken SGLang'in karmaşık bağımlılık çözümüne karşı pratik kazanan olarak öne çıkar.
FlashInfer'li vLLM (12.553 tok/s) ilgi çekici bir orta yol sunar: 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 denemesi için vLLM rasyonel seçim olmaya devam eder. Verimliliğin en önemli olduğu özel H100 dağıtımları için, LMDeploy'un en yüksek performans ve kurulum basitliği kombinasyonu rakipsizdir.
SSS'ler
Bir LLM çıkarım motoru, büyük dil modellerinin yanıtları nasıl ürettiğini 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 iyileştirmeler verimliliği (saniyede üretilen token) önemli ölçüde artırabilir ve maliyetleri düşürebilir, potansiyel olarak aynı donanımda 3-5 kat daha iyi performans sağlayabilir.
Çevrimdışı toplu çıkarım, gerçek zamanlı gereksinimler olmadan birçok prompt'lar 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 gereksinimleri olan 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.