ProsGrow ने Qwen3 का बैच थ्रूपुट 132% कैसे बढ़ाया

समस्या: लंबी कतार, पर बहुत कम सक्रिय अनुरोध

व्यस्त अनुरोध कतार यह सुनिश्चित नहीं करती कि GPU अपनी उपलब्ध क्षमता के अनुसार उपयोगी काम कर रहा है। vLLM 0.25.1 पर Qwen3-30B-A3B के साथ, ProsGrow ने पाया कि प्रारंभिक सर्विंग कॉन्फ़िगरेशन छोटे प्रॉम्प्ट के बैच का एक साथ चल सकने वाला हिस्सा सीमित कर रहा था। कतार में पर्याप्त काम होने के बावजूद यह 17,961 आउटपुट टोकन/सेकंड देता था।

प्रोफ़ाइलिंग और शेड्यूलिंग व्यवहार में समायोजन से यह दर 41,651 आउटपुट टोकन/सेकंड हुई: 132% सुधार, यानी 2.32×। GPU, रनटाइम, चेकपॉइंट, परिशुद्धता, अनुरोध संख्या और प्रॉम्प्ट/आउटपुट विनिर्देश स्थिर रहे। यह ProsGrow के प्रारंभिक कॉन्फ़िगरेशन की तुलना में मापा गया सुधार है, सर्वोत्तम ढंग से ट्यून किए vLLM बेसलाइन की तुलना नहीं।

बेसलाइन → ProsGrow द्वारा ट्यून किया गया

इस नियंत्रित तुलना में अनुरोध विलंबता की माध्यिका भी 15.91 से 11.70 सेकंड हुई। यह बढ़त इस वर्कलोड में हासिल की जा सकने वाली क्षमता दर्शाती है; इससे अन्य इन्फ़रेंस इंजन या पूर्णतः अनुकूलित डिप्लॉयमेंट के मुकाबले सामान्य श्रेष्ठता सिद्ध नहीं होती।

शेड्यूलर महत्वपूर्ण क्यों था

ProsGrow ने प्रस्तुत लोड को इंजन द्वारा वास्तव में स्वीकार किए गए काम से अलग किया, फिर उसी वर्कलोड पर पूर्ण किए गए थ्रूपुट और अनुरोध विलंबता की तुलना की। प्रमाण शेड्यूलिंग बाधा की ओर इशारा करते थे: प्रारंभिक कॉन्फ़िगरेशन लंबी कतार को पर्याप्त समवर्ती निष्पादन में नहीं बदल पा रहा था। यह कर्नेल-स्तर की गति वृद्धि को अलग से नहीं मापता।

इंजीनियरिंग कार्य इस सर्विंग स्टैक के सीमित करने वाले हिस्से को पहचानना, नियंत्रित स्थितियों में उसका प्रभाव जाँचना और उपयोगी परिचालन बिंदु सत्यापित करना था। मॉडल एक GPU में समा जाता है, इसलिए स्वतंत्र रेप्लिका यह जाँचने का व्यावहारिक तरीका बने कि एक GPU से हासिल अतिरिक्त क्षमता पूरे नोड तक पहुँचती है या नहीं।

समझौता: अधिक समवर्ती अनुरोध अंततः इंतज़ार बढ़ाते हैं

एक अलग संतृप्ति कॉन्फ़िगरेशन ने दो स्वतंत्र रन में 45,941 और 46,701 आउटपुट टोकन/सेकंड दिए, और माध्यिका विलंबता लगभग 20 सेकंड रही। उसी स्वीप में उस परिचालन बिंदु से आगे लोड बढ़ाने पर थ्रूपुट केवल 0.91% बढ़ा, जबकि माध्यिका विलंबता 20.04 से 29.85 सेकंड हो गई। अतिरिक्त कतार अब सार्थक क्षमता नहीं दे रही थी।

मेमोरी ने भी चयन सीमित किया: सर्विंग ओवरहेड ने की/वैल्यू कैश के लिए उपलब्ध जगह घटा दी। छोटे प्रॉम्प्ट ने चुने कॉन्फ़िगरेशन के लिए पर्याप्त जगह छोड़ी। लंबे संदर्भ या इंटरैक्टिव विलंबता लक्ष्य के लिए अलग मूल्यांकन चाहिए।

एक ट्यून किए GPU से आठ-GPU बैच सेवा तक

आठ स्वतंत्र रेप्लिका के साथ दो समकालित रन ने 362,812 और 361,679 आउटपुट टोकन/सेकंड दिए। क्षमता अनुमान के लिए हम कम परिणाम इस्तेमाल करते हैं। हर रन में सभी 32,768 अनुरोध और 8,388,608 आउटपुट टोकन पूरे हुए, बिना किसी विफल या अपेक्षा से छोटे उत्तर के।

कम परिणाम वाले रन ने पहले क्लाइंट के शुरू होने से अंतिम पूर्णता तक 23.19 सेकंड की साझा वास्तविक समयावधि इस्तेमाल की। इस साझा अवधि में पूरा काम गिनने से स्वतंत्र समय माप वाली रेप्लिका दरों को जोड़कर नोड का परिणाम बढ़ा-चढ़ाकर दिखाने से बचते हैं।

132% स्थानीय बढ़त और 8.17% सार्वजनिक तुलना का संबंध

ऊपर की 132% बढ़त छोटे कतारबद्ध अनुरोधों पर शेड्यूलिंग समायोजन मापती है। हमारी क्षमता रिपोर्ट की 8.17% तुलना एक अलग प्रश्न का उत्तर देती है: लंबे, निश्चित अनुरोध विनिर्देश पर स्थानीय रन, सहेजे सार्वजनिक संदर्भ के मुकाबले कैसा प्रदर्शन करता है?

सार्वजनिक विनिर्देश वाले रन में कतारबद्ध सिंथेटिक अनुरोध और TensorRT-LLM 1.3.0rc24 इस्तेमाल हुआ, जबकि सहेजे NVIDIA संदर्भ में 1.1 था। उस लंबी कतार में औसत अनुरोध विलंबता 173.04 सेकंड थी। 17 अगस्त 2026 को सहेजे 9,938 आँकड़े का स्रोत NVIDIA संदर्भ पेज है; बाद की स्रोत समीक्षा में वह पंक्ति उपलब्ध नहीं थी। हम इसे दिनांकित तुलना के रूप में रखते हैं, और वर्कलोड सार्वजनिक प्रदर्शन विधि से परिभाषित है।

+8.17% अलग एक-GPU परिणाम का है। न यह और न ही 85,409 तथा 361,679 नोड टोकन/सेकंड का अंतर केवल सॉफ़्टवेयर सुधार को अलग करता है: बाद वाली तुलना में रनटाइम और अनुरोध लंबाइयाँ बदलती हैं। ये दरें बैच क्षमता बताती हैं; इंटरैक्टिव सेवा को अपना विलंबता लक्ष्य चाहिए।

ग्राहक के लिए क्या बदलता है

निजी जनरेशन कतार और सिंथेटिक-डेटा जॉब मौजूदा क्षमता पर काम जल्दी पूरा करने से लाभ पा सकते हैं। अधिक GPU सुझाने से पहले ProsGrow हासिल की जा सकने वाली अतिरिक्त सर्विंग क्षमता माप सकता है।

चुना थ्रूपुट कॉन्फ़िगरेशन लंबी कतार चाहता है और लगभग 20-सेकंड माध्यिका विलंबता स्वीकार करता है। डिप्लॉयमेंट की योग्यता जाँच में ग्राहक का मॉडल, अनुरोध-लंबाई वितरण, गुणवत्ता जाँच और ट्रैफ़िक ट्रेस इस्तेमाल होना चाहिए। इंटरैक्टिव सहायकों को अपना विलंबता लक्ष्य चाहिए।

कार्यप्रणाली और सीमाएँ

• हार्डवेयर और सॉफ़्टवेयर: परीक्षण 18 अगस्त 2026 को आठ-GPU NVIDIA RTX PRO 6000 Blackwell Server Edition नोड पर हुए। नियंत्रित स्वीप में एक GPU इस्तेमाल हुआ। रनटाइम vllm/vllm-openai:v0.25.1 था, जिसमें ModelOpt NVFP4 वेट और FP8 की/वैल्यू कैश था।
• मॉडल और अनुरोध: निश्चित NVIDIA Qwen3-30B-A3B-FP4 चेकपॉइंट ने रिविज़न 2538ded2a4edb247b4d2b4a8ba24e44bd4c017c3 इस्तेमाल किया। बदलते अनुरोध पहचानकर्ता के साथ दोहराए तकनीकी-गाइड प्रॉम्प्ट से API द्वारा बताए 63–66 इनपुट टोकन बने। तापमान शून्य था, थिंकिंग बंद थी और हर उत्तर 256-टोकन सीमा तक पहुँचा।
• मापन: थ्रूपुट, पूर्ण हुए आउटपुट टोकन को क्लाइंट द्वारा देखे गए बीते समय से भाग देकर निकाला जाता है, जिसमें प्रॉम्प्ट प्रसंस्करण और स्थानीय HTTP ओवरहेड शामिल हैं। 132% तुलना में प्रत्येक कॉन्फ़िगरेशन का एक माप है। चुने संतृप्ति कॉन्फ़िगरेशन के दो स्वतंत्र दोहराव और दो समकालित नोड दोहराव हैं; बाद वाले हर बार केवल लगभग 23 सेकंड लंबे हैं।
• गुणवत्ता और संचालन: निश्चित आउटपुट लंबाई उत्पन्न काम की मात्रा जाँचती है, कार्य की गुणवत्ता नहीं। ये पुराने Qwen3 चेकपॉइंट पर स्थानीय संतृप्ति माप हैं, न कि दीर्घकालीन प्रोडक्शन परीक्षण, ग्राहक SLA या गुणवत्ता-समानता परीक्षण। प्रतिनिधि प्रॉम्प्ट, p95/p99 विलंबता, नेटवर्क ओवरहेड, विफलताएँ और डोमेन गुणवत्ता अभी भी प्रोडक्शन स्वीकृति के मानदंड हैं।

ऐतिहासिक vLLM 0.23 तुलना भी शीर्षक की बढ़त से बाहर रखी गई है क्योंकि उसके मूल कच्चे प्रॉम्प्ट अनुरोध सहेजे नहीं गए थे। समान संस्करण की स्थानीय तुलना नियंत्रित बेसलाइन देती है।

निजी Qwen3 डिप्लॉयमेंट और vLLM बैच इन्फ़रेंस

निजी Qwen3 डिप्लॉयमेंट की योजना बनाने वाली टीमें इस बेंचमार्क से बैच इन्फ़रेंस क्षमता, GPU उपयोग और स्वीकार्य कतार समय पर चर्चा कर सकती हैं। प्रति सेकंड आउटपुट टोकन पूरे हुए जनरेशन का थ्रूपुट मापते हैं, जबकि अनुरोध विलंबता बताती है कि जॉब कितनी देर प्रतीक्षा करता और चलता है। vLLM डिप्लॉयमेंट का आकार ग्राहक के अनुरोध मिश्रण और डिलीवरी लक्ष्य के आधार पर तय होना चाहिए।