64K-token प्रॉम्प्ट्सवर vLLM ने SGLang ला मागे टाकले, परंतु 8-GPU B300 सर्व्हरवर कॉन्टेक्स्ट 200K वर पोहोचताच SGLang पुढे जाते. टोकन विंडो विस्तारत असताना, प्रीफिल (prefill) कामापेक्षा डिकोड-स्टेजमधील (decode-stage) अडथळे (bottlenecks) कामगिरी ठरवतात, हे या बदलावरून दिसून येते.

हा बेंचमार्क का महत्त्वाचा आहे

चॅट असिस्टंट्स, कोड असिस्टंट्स आणि मेमरीमध्ये लाखो टोकन्स ठेवणे आवश्यक असलेल्या कोणत्याही ॲपसाठी 'लाँग-कॉन्टेक्स्ट इन्फरन्स' (long-context inference) खर्च ठरवते. Kimi-K3, हे एक लार्ज-पॅरामीटर मॉडेल आहे, जे अशा विंडो सहज हाताळू शकणाऱ्या पहिल्या ओपन-वेट LLMs पैकी एक आहे, परंतु ते चालवणारे इंजिन हे ठरवते की विनंती (request) सेकंदात पूर्ण होईल की मिनिटांत.

vLLM आणि SGLang दोन्ही हाय-थ्रूपुट इन्फरन्सचे (high-throughput inference) आश्वासन देतात, तरीही ते डिकोड स्टेजसाठी परस्परविरोधी दृष्टिकोन अवलंबतात. vLLM डिकोड पाथ सोपा ठेवते, ज्यामुळे Decode Context Parallelism (DCP) मुळे येणारे अतिरिक्त सिंक्रोनाइझेशन टाळले जाते. SGLang, DCP वापरून की-व्हॅल्यू (KV) कॅशे रीड्स (cache reads) अनेक GPUs मध्ये विभागते; ही एक अशी पद्धत आहे जी अतिरिक्त कम्युनिकेशनच्या बदल्यात मेमरी बँडविड्थचा (memory bandwidth) वापर कार्यक्षमतेने करू शकते.

टेस्टबेड (The testbed)

  • Hardware: आठ NVIDIA B300 GPUs असलेला एक सिंगल सर्व्हर, ज्यातील प्रत्येकाची मेमरी समान आहे.
  • Workloads: दोन कॉन्टेक्स्ट-लेन्थ सेटिंग्ज – 64K टोकन्स ("long context" ची खालची मर्यादा) आणि 200K टोकन्स (अनेक रिसर्च डेमोमध्ये वापरली जाणारी वरची मर्यादा).
  • Metrics: प्रॉम्प्ट्सच्या एका ठराविक बॅचवर प्रक्रिया करण्यासाठी लागणारा एकूण वेळ; थ्रूपुट (throughput) वेळेतील फरकावरून काढला जातो.

आम्ही बॅच साइज, मॉडेल वेट्स आणि मेमरी-युटिलायझेशन टार्गेट्स स्थिर ठेवले. रन दरम्यान आम्ही बदललेला एकमेव घटक म्हणजे इन्फरन्स इंजिन.

आकडेवारी

कॉन्टेक्स्ट इंजिन वेळ (s) सापेक्ष वेग
64 K vLLM 100.5 –
SGLang 150.8 vLLM ≈ 1.5× वेगवान
200 K vLLM 295.2 –
SGLang 225.3 SGLang ≈ 1.31× वेगवान

कॉन्टेक्स्ट वाढल्यावर vLLM चा थ्रूपुट (प्रति सेकंद टोकन्स) मोठ्या प्रमाणात कमी झाला: 64K पासून 200K पर्यंत 3.29× घट झाली. SGLang चा थ्रूपुट त्याच रेंजमध्ये केवळ 1.25× कमी झाला.

हा फरक का निर्माण होतो

दोन्ही इंजिन प्रीफिल स्टेजवर (prefill stage) – म्हणजेच प्रॉम्प्टला KV कॅशेमध्ये लोड करण्यासाठी – सारखाच वेळ घालवतात. फरक डिकोड स्टेजमध्ये दिसून येतो, जिथे मॉडेल एक-एक करून टोकन्स तयार करते.

  • 64K टोकन्स: inter-GPU कम्युनिकेशन प्रभावी ठरते. vLLM चा सिंगल-GPU डिकोड पाथ DCP साठी आवश्यक असलेले अतिरिक्त सिंक्रोनाइझेशन टाळतो, ज्यामुळे तो सुमारे 1.5× वेगाने काम पूर्ण करतो.
  • 200K टोकन्स: KV कॅशे इतका मोठा होतो की तो वाचणे (reading) हा अडथळा (bottleneck) बनतो. SGLang चे DCP, ज्याचा आकार 8 सेट केला आहे, ते हे रीड्स आठही GPUs मध्ये विभागते. यामुळे मिळणारा बँडविड्थचा फायदा कम्युनिकेशन पेनल्टीपेक्षा जास्त असतो, ज्यामुळे SGLang ला स्पष्ट आघाडी मिळते.

मेमरी प्रेशरबाबत एक दुय्यम, व्यावहारिक निरीक्षण समोर आले आहे. दोन्हीपैकी कोणतेही इंजिन 0.95 मेमरी-युटिलायझेशन टार्गेटवर चालवल्यास B300 वर 'आउट-ऑफ-मेमरी' (OOM) रिट्रायज (retries) सुरू झाले. टार्गेट 0.92 पर्यंत कमी केल्यामुळे हे रिट्रायज थांबले आणि रनटाइम स्थिर झाले, जरी यामुळे लॅटन्सीमध्ये (latency) थोडी वाढ झाली.

कोणाचा फायदा, कोणाचे नुकसान

  • लहान ते मध्यम कॉन्टेक्स्ट असलेले डेव्हलपर्स (≤ 64K टोकन्स) vLLM च्या लीन (lean) डिकोड पाथचा अधिक फायदा घेतात. जलद रिस्पॉन्समुळे क्लाउड-कंप्युट बिल कमी होते आणि युजर-एक्सपिरियन्स अधिक चांगला होतो.
  • डीप-ॲनालिसिस किंवा रिसर्च टूल्स बनवणारी टीम्स, ज्यांना कॉन्टेक्स्टमध्ये लाखो टोकन्स ठेवण्याची गरज आहे, त्यांनी DCP सक्षम असलेल्या SGLang कडे वळावे. त्याचा स्थिर थ्रूपुट टाइम-आउटचा धोका कमी करतो आणि मेमरीची मागणी वाढली तरी GPU युटिलायझेशन उच्च ठेवतो.
  • हार्डवेअर प्लॅनर्सना हे लक्षात येते की केवळ GPU ची संख्या रेषीय स्केलिंगची (linear scaling) हमी देत नाही. जेव्हा KV बँडविड्थ हा अडथळा बनते, तेव्हा DCP किंवा भविष्यातील मेमरी-सबसिस्टम अपग्रेडद्वारे कॅशे रीड्स समांतर (parallelize) करू शकणारी आर्किटेक्चर एकाच सिलिकॉनमधून अधिक मूल्य मिळवू शकतील.

प्रतिवाद: vLLM हा फरक कमी करू शकेल का?

जोपर्यंत नवीन डेटा समोर येत नाही, तोपर्यंत सध्याचे आकडे सर्वोत्तम सार्वजनिक तुलना म्हणून मानले जातील.

पुढे काय पाहावे

  • मोठ्या कॉन्टेक्स्ट विंडोजमुळे KV बँडविड्थवर अधिक ताण येईल, ज्यामुळे SGLang ची आघाडी अधिक वाढण्याची शक्यता आहे.

थोडक्यात

जेव्हा तुम्हाला B300-आधारित क्लस्टरवर लाँग-कॉन्टेक्स्ट विनंत्या हाताळायच्या असतील, तेव्हा तुमच्या टोकन विंडोला साजेसे इंजिन निवडा. 64K-टोकन वर्कलोडसाठी, vLLM सुमारे 1.5× वेगाने इन्फरन्स देते. 200K टोकन्सच्या पुढे गेल्यास, SGLang चे DCP-चालित डिकोड अधिक कार्यक्षम पर्याय ठरते, कारण त्याचा थ्रूपुट vLLM च्या 3.29× घटीच्या तुलनेत केवळ 1.25× ने कमी होतो. OOM रिट्रायज टाळण्यासाठी मेमरी युटिलायझेशन 0.92 वर सेट करा आणि लक्षात ठेवा की "सर्वोत्तम" इंजिन हे कॉन्टेक्स्टवर अवलंबून असते, ते सर्वांसाठी एकसारखे (one-size-fits-all) नसते.