vLLM vs SGLang 2026: Kami Melakukan Benchmark Keduanya di H100

vLLM vs SGLang 2026: Kami Melakukan Benchmark Keduanya di H100

Hugging Face menempatkan TGI ke dalam mode pemeliharaan pada Desember 2025 dan kini mengarahkan tim menuju vLLM atau SGLang untuk penerapan baru. Jika Anda sedang membangun tumpukan inferensi hari ini, pertanyaan sebenarnya bukanlah "haruskah saya beralih dari TGI?", melainkan mesin mana dari kedua ini yang benar-benar sesuai dengan beban kerja Anda.

Ringkasan Cepat

Pilih vLLM jika Anda menginginkan dukungan perangkat keras terluas, komunitas terbesar, dan jalur teruji menuju produksi di AWS, GCP, dan Azure.

Pilih SGLang jika beban kerja Anda berat pada percakapan multi-putaran, output terstruktur, atau pipa berbasis prefiks seperti RAG, dan Anda nyaman dengan ekosistem yang lebih kecil.

Sekarang mari kita bedah di mana masing-masing mesin sebenarnya unggul.

Bagaimana Kita Sampai Di Sini? Mundurnya TGI

Text Generation Inference (TGI) telah menopang ekosistem Hugging Face selama bertahun-tahun, namun per Desember 2025 hanya menerima perbaikan bug, tanpa fitur baru. Inference Endpoints milik Hugging Face kini secara default menggunakan vLLM, dengan SGLang sebagai alternatif.

Hal ini menyisakan dua pesaing nyata untuk penyajian LLM yang di-host sendiri. Keduanya open-source, keduanya mendukung API OpenAI, dan keduanya berjalan di GPU NVIDIA. Perbedaannya muncul saat berada di bawah beban tinggi.

Kesimpulan: Baik vLLM maupun SGLang adalah pengganti TGI yang siap produksi. Jika Anda bermigrasi, salah satunya adalah pilihan yang aman, sisa panduan ini membantu Anda memilih mana yang tepat.

Benchmark Throughput dan Latensi

Benchmark bervariasi tergantung model, GPU, dan konkurensi, jadi berikut adalah angka dari tes independen pada perangkat keras yang sama. Data berikut berasal dari benchmark H100 Spheron menggunakan Llama 3.3 70B Instruct dalam FP8 dan tes PremAI dengan Llama 3.1 8B.

Llama 3.3 70B di H100 (FP8)

Llama 3.1 8B di H100

Pada model yang lebih kecil, kesenjangan melebar. PremAI mengukur SGLang sekitar 16.200 tok/dtk dibandingkan vLLM di 12.500 tok/dtk, sebuah keunggulan throughput 29% untuk SGLang. LMDeploy setara dengan SGLang di sini, tetapi itu pembahasan terpisah.

Apa Arti Angka-Angka Ini

Pada skala 70B, selisihnya sederhana (3-5%). Pada skala 8B, selisihnya signifikan. Pola ini masuk akal: RadixAttention milik SGLang lebih bermanfaat ketika prefill merupakan bagian yang lebih besar dari total biaya, yang terjadi pada model yang lebih kecil dan output yang lebih pendek.

Latensi ekor menceritakan kisah yang serupa. TTFT p95 SGLang secara konsisten 5-8% lebih rendah daripada vLLM di setiap tingkat konkurensi yang diuji. Jika Anda membangun antarmuka obrolan waktu nyata di mana setiap 50ms sangat berarti, celah tersebut akan berlipat ganda seiring jumlah pengguna.

Kesimpulan: SGLang menang dalam throughput mentah, terutama untuk model yang lebih kecil. vLLM sangat dekat pada skala 70B+. Untuk sebagian besar beban kerja produksi, perbedaannya berada dalam persentase satu digit, yang berarti pada skala besar, tetapi bukan penentu utama bagi kedua pihak.

Caching Prefiks: RadixAttention vs Automatic Prefix Caching

Kedua mesin menyimpan komputasi KV untuk prefiks yang berulang, tetapi mekanismenya berbeda dengan cara yang penting untuk beban kerja tertentu. Jika Anda sudah familiar dengan caching prompt di tingkat API, anggap ini sebagai versi sisi server.

vLLM menggunakan hashing tingkat blok. Ini membagi cache KV menjadi blok berukuran tetap, melakukan hash, dan mencari kecocokan pada permintaan baru. Dapat diprediksi, efisien, dan mudah dipahami, tetapi Anda memerlukan batas blok yang konsisten untuk mendapatkan hit cache.

SGLang menggunakan pohon radix yang diindeks pada tingkat token. Ini secara otomatis menemukan prefiks bersama di seluruh permintaan tanpa konfigurasi manual. Jika 50 pengguna mengirim pesan dalam utas percakapan yang sama, SGLang menemukan dan menggunakan kembali prefiks umum secara otomatis.

Di Mana Ini Benar-Benar Penting

RunPod melakukan benchmark pada percakapan multi-putaran dan menemukan SGLang memberikan ~30-31 tok/dtk secara konsisten di bawah konkurensi tinggi, sementara vLLM turun dari 22 menjadi 16 tok/dtk saat tekanan cache meningkat. Itu adalah kesenjangan yang berarti untuk beban kerja chatbot dan agen.

Untuk inferensi batch pada prompt templat, di mana setiap permintaan menggunakan prompt sistem yang sama, pendekatan vLLM bekerja dengan baik. Batas cache sejalan secara alami dengan struktur templat Anda.

Kesimpulan: SGLang menang untuk beban kerja dinamis dan multi-putaran. vLLM sepenuhnya memadai untuk inferensi batch dan prompt templat di mana prefiks dapat diprediksi.

Output Terstruktur

Jika Anda memerlukan penegakan skema JSON atau generasi terkendala, bagian ini sangat penting. Kedua mesin mendukung output terstruktur melalui backend tata bahasa seperti XGrammar dan LLGuidance, tetapi cerita kinerjanya sangat berbeda.

SqueezeBits menjalankan benchmark mendetail dan menemukan bahwa vLLM menunjukkan penurunan throughput yang signifikan dengan decoding terpandu yang diaktifkan, terutama pada ukuran batch 8 ke atas. Sebaliknya, SGLang menumpangkan pembuatan masker dengan langkah inferensi GPU, menjaga overhead tetap minimal.

Skema Repetitif vs Dinamis

Pilihan backend juga penting:

Tanpa penegakan terstruktur, output jatuh ke ~61% kebenaran pada skema kompleks. Dengan itu, kebenaran melonjak 20-25 poin persentase. Jadi ini bukan opsional untuk alur kerja agen produksi, dan mesin yang Anda pilih menentukan berapa banyak throughput yang Anda korbankan.

Kesimpulan: SGLang menang untuk output terstruktur. Jika pipa Anda bergantung pada penegakan skema JSON (dan sebagian besar alur kerja agen melakukannya), pendekatan tumpang tindih SGLang berarti Anda tidak membayar pajak throughput.

Penyajian Model Multi-LoRA dan Fine-Tuned

Kedua mesin mendukung penyajian beberapa adaptor LoRA dari satu model dasar, yang sangat penting jika Anda menyetel halus model untuk penyewa atau tugas yang berbeda.

SGLang memperlakukan multi-LoRA sebagai fitur kelas satu dengan batching native, permintaan yang menargetkan adaptor berbeda dapat berbagi batch yang sama. vLLM juga mendukungnya, tetapi implementasi SGLang sedikit lebih halus dalam rilis terbaru.

Perbedaan praktisnya? Jika Anda menyajikan 5-10 adaptor LoRA dari satu model dasar Llama 70B, keduanya bekerja. Jika Anda menjalankan 50+ adaptor dengan pola lalu lintas heterogen, batching native SGLang menangani penjadwalan dengan lebih lancar.

Kesimpulan: SGLang memiliki keunggulan tipis untuk multi-LoRA dalam skala besar. Untuk segelintir adaptor, kedua mesin bekerja sama baiknya.

Decoding Spekulatif

Kedua mesin mendukung decoding spekulatif, yang menggunakan model "draft" kecil untuk memprediksi token yang kemudian diverifikasi oleh model utama secara paralel. Hasilnya adalah inferensi 2-3x lebih cepat untuk skenario yang dibatasi memori.

vLLM baru-baru ini memperkenalkan Unified Parallel Drafting, dan decoding spekulatif kini bekerja bersamaan dengan output terstruktur. Implementasi SGLang memiliki kemampuan serupa, dengan kinerja sedikit lebih baik pada tingkat konkurensi sedang.

Pembeda sebenarnya bukanlah mesinnya, melainkan apakah decoding spekulatif cocok dengan beban kerja Anda. Ini paling membantu dengan output panjang dari model besar di mana kemacetan adalah bandwidth memori, bukan komputasi.

Kesimpulan: Seri. Kedua mesin memberikan peningkatan kecepatan decoding spekulatif yang sebanding.

Dukungan Perangkat Keras dan Penerapan

Di sinilah vLLM unggul secara signifikan.

vLLM

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI250, MI300X)
• GPU Intel (melalui vllm-xpu-kernels)
• AWS Trainium dan Inferentia
• Google TPUs
• Dokumentasi Kubernetes matang dengan chart Helm, probe startup/readiness/liveness
• Integrasi NVIDIA Container Toolkit langsung dari kotak

SGLang

• GPU NVIDIA (A100, H100, H200, B200)
• GPU AMD (MI300X, via ROCm)
• Penerapan berbasis Docker
• Kubernetes memungkinkan tetapi kurang terdokumentasi

Jika Anda menerapkan di apa pun selain NVIDIA atau AMD, vLLM adalah satu-satunya pilihan Anda. Khususnya di AWS, dukungan Trainium berarti Anda dapat mengurangi biaya inferensi secara signifikan, dan SGLang tidak dapat menyentuh perangkat keras tersebut.

Untuk tim yang beroperasi pada GPU NVIDIA standar, cerita penerapannya serupa. Keduanya menyediakan image Docker dan endpoint yang kompatibel dengan OpenAI. vLLM hanya memiliki lebih banyak panduan produksi yang teruji dan chart Helm yang dikontribusikan komunitas.

Jika Anda menjelajahi alat untuk menjalankan LLM secara lokal atau ingin pandangan lebih luas tentang inferensi yang di-host sendiri, kedua mesin juga mendukung penerapan lokal pada GPU konsumen, meskipun mereka dirancang untuk perangkat keras pusat data.

Kesimpulan: vLLM menang dalam kelengkapan perangkat keras dan kematangan penerapan. SGLang baik-baik saja jika Anda menggunakan NVIDIA atau AMD. Di tempat lain, vLLM adalah satu-satunya pilihan.

Penyajian Terpisah (Disaggregated Serving)

Kedua mesin mendukung pemisahan prefill (berat komputasi) dari decode (berat memori) ke dalam kumpulan pekerja yang berbeda. Ini memungkinkan Anda menskalakan setiap fase secara independen, lebih banyak pekerja prefill selama lonjakan yang berat prompt, lebih banyak pekerja decode untuk generasi panjang.

SGLang mendukung Mooncake dan NIXL sebagai backend transfer untuk disagregasi dan telah menerbitkan hasil yang menunjukkan throughput decoding 2,7x lebih tinggi pada kluster NVIDIA GB200 NVL72. Penyajian terpisah vLLM juga fungsional, meskipun kurang terdokumentasi secara mencolok.

Fitur ini paling penting pada skala yang sangat besar (96+ GPU). Jika Anda menjalankan segelintir GPU, Anda mungkin belum membutuhkannya.

Kesimpulan: SGLang memiliki keunggulan tipis dalam kematangan penyajian terpisah. Keduanya mendukungnya; SGLang telah menerbitkan lebih banyak hasil dunia nyata.

Kapan Menggunakan Masing-Masing: Kerangka Keputusan

Jawaban jujur untuk banyak tim: coba keduanya. Keduanya open-source, keduanya mengekspos API OpenAI yang sama, dan beralih di antara keduanya hanyalah pertukaran kontainer. Jalankan beban kerja aktual Anda terhadap masing-masing selama sehari dan bandingkan metrik yang penting bagi Anda.

Jika Anda merutekan lalu lintas di beberapa backend inferensi, gateway LLM dapat duduk di depan mesin mana pun dan menangani failover, pembatasan laju, dan observabilitas.

Bagaimana Techsy Mendekati Pemilihan Server Inferensi

Ketika kami membantu tim menerapkan fitur bertenaga LLM, pilihan mesin inferensi bermuara pada tiga pertanyaan:

1. Perangkat keras apa yang mengunci Anda? Jika itu Trainium atau TPU, itu vLLM. Selain itu, keduanya bekerja.
2. Apa bentuk beban kerja Anda? Obrolan multi-putaran dan loop agen mendukung caching prefiks SGLang. Pemrosesan batch dan penyelesaian sederhana baik-baik saja di keduanya.
3. Berapa kapasitas ops yang Anda miliki? Komunitas vLLM yang lebih besar berarti lebih banyak jawaban StackOverflow dan chart Helm ketika sesuatu rusak pada pukul 3 pagi.

Kami telah menjalankan beban kerja produksi di keduanya. Mereka benar-benar dekat. Jawaban yang tepat bergantung pada kendala Anda, bukan pada satu yang "lebih baik" secara abstrak.

Butuh bantuan memilih atau menerapkan server inferensi? Hubungi kami, kami akan menilai beban kerja Anda dan merekomendasikan tumpukan yang tepat.

Memilih alat adalah bagian yang mudah. Membuatnya berjalan dengan andal di dalam produk nyata adalah di mana sebagian besar tim macet, dan itulah tepatnya yang dibangun oleh tim integrasi AI kami untuk klien, dari pipa RAG hingga agen kustom.

Pertanyaan yang Sering Diajukan

Apakah SGLang lebih cepat dari vLLM?

Pada model yang lebih kecil (7B-8B), SGLang menunjukkan throughput sekitar 29% lebih tinggi pada GPU H100. Pada model 70B+, kesenjangan menyempit menjadi 3-5%. SGLang juga memiliki latensi ekor (TTFT p95) yang lebih rendah di semua tingkat konkurensi yang diuji.

Bisakah saya menggunakan vLLM dan SGLang dengan format API OpenAI?

Ya. Keduanya mengekspos endpoint yang kompatibel dengan OpenAI langsung dari kotak. Anda dapat menukar satu dengan yang lain tanpa mengubah kode klien Anda. Panggilan /v1/chat/completions Anda bekerja secara identik di keduanya.

Mengapa Hugging Face menghentikan TGI?

TGI memasuki mode pemeliharaan pada Desember 2025. Hugging Face memutuskan untuk berkontribusi pada vLLM dan SGLang alih-alih mempertahankan mesin inferensi terpisah. TGI masih berfungsi untuk penerapan yang ada, tetapi tidak ada fitur baru yang akan datang.

Apakah SGLang mendukung GPU NVIDIA dan AMD?

SGLang mendukung GPU NVIDIA (A100, H100, H200, B200) dan GPU AMD (MI300X via ROCm). Ini tidak mendukung GPU Intel, AWS Trainium, Inferentia, atau Google TPUs. vLLM memiliki cakupan perangkat keras yang lebih luas.

Apa itu RadixAttention dan mengapa itu penting?

RadixAttention adalah mekanisme caching prefiks SGLang. Ini menyimpan entri cache KV dalam pohon radix yang diindeks pada tingkat token, secara otomatis menemukan prefiks bersama di seluruh permintaan. Ini membuat percakapan multi-putaran dan pipa RAG secara signifikan lebih cepat karena konteks yang berulang tidak perlu dihitung ulang.

Mesin mana yang lebih baik untuk output JSON terstruktur?

SGLang. Ini menumpangkan pembuatan masker tata bahasa dengan inferensi GPU, sehingga penegakan output terstruktur hampir tidak mempengaruhi throughput. vLLM menunjukkan penurunan yang terlihat pada ukuran batch 8 ke atas ketika decoding terpandu diaktifkan.

Bisakah saya menyajikan beberapa adaptor LoRA dari satu model dasar?

Kedua mesin mendukung penyajian multi-LoRA. SGLang memperlakukannya sebagai fitur native dengan batching di berbagai adaptor dalam batch permintaan yang sama. vLLM juga mendukungnya, tetapi penjadwalan SGLang lebih efisien pada jumlah adaptor yang tinggi.

Apa itu penyajian prefill/decode terpisah?

Ini berarti menjalankan fase prefill (memproses prompt) pada pekerja GPU yang terpisah dari fase decode (menghasilkan token). Prefill dibatasi komputasi; decode dibatasi memori. Memisahkannya memungkinkan Anda menskalakan masing-masing secara independen. Kedua mesin mendukung ini, dengan SGLang memiliki lebih banyak hasil produksi yang diterbitkan.

Bagaimana cara migrasi dari TGI ke vLLM atau SGLang?

Karena ketiganya mengekspos API yang kompatibel dengan OpenAI, migrasi sebagian besar adalah pertukaran kontainer. Arahkan deployment Docker Compose atau Kubernetes Anda ke image baru, sesuaikan flag pemuatan model, dan perbarui endpoint pemeriksaan kesehatan. Kode klien tetap sama.

Haruskah saya menggunakan vLLM atau SGLang untuk pipa RAG?

SGLang adalah pilihan yang lebih kuat untuk RAG. RadixAttention-nya secara otomatis menyimpan dan menggunakan kembali prompt sistem panjang dan konteks dokumen yang berulang kali dikirim oleh pipa RAG. Caching tingkat blok vLLM juga bekerja, tetapi Anda akan melihat tingkat hit cache yang lebih baik dengan pendekatan tingkat token SGLang ketika potongan dokumen sedikit bervariasi di seluruh permintaan.

Vonis Akhir

SGLang memenangkan lebih banyak kategori, tetapi keunggulan vLLM, kelengkapan perangkat keras dan kematangan ekosistem, adalah hal-hal yang penting pada pukul 3 pagi ketika sebuah node mati.

Jika Anda menggunakan perangkat keras NVIDIA dan beban kerja Anda melibatkan percakapan multi-putaran, agen dengan output terstruktur, atau pipa RAG dengan prefiks bersama, mulailah dengan SGLang. Anda akan mendapatkan throughput yang lebih baik dan latensi yang lebih rendah di tempat yang penting.

Jika Anda membutuhkan fleksibilitas multi-cloud, dukungan perangkat keras non-NVIDIA, atau kenyamanan dari komunitas penyajian LLM open-source terbesar, mulailah dengan vLLM. Ini adalah default yang lebih aman yang akan melayani sebagian besar tim dengan baik.

Bagaimanapun, kedua mesin sangat bagus dan berkembang pesat. Pilih satu, terapkan, ukur beban kerja aktual Anda, dan beralih jika angka-angkanya memberitahu Anda untuk melakukannya. API yang kompatibel dengan OpenAI membuat peralihan itu tidak menyakitkan.

Sumber

• Benchmark H100 Spheron: vLLM vs TensorRT-LLM vs SGLang
• PremAI: Benchmark vLLM vs SGLang vs LMDeploy
• SqueezeBits: Kinerja Decoding Terpandu pada vLLM dan SGLang
• RunPod: SGLang vs vLLM Penggunaan Ulang Cache KV
• Dokumentasi Resmi SGLang
• Dokumentasi Resmi vLLM