vLLM ने NVIDIA Blackwell GPU पर Kimi K3 के लिए एक वैकल्पिक, मॉडल-विशिष्ट डिकोड पथ को मर्ज किया है। अपने 16 अक्टूबर के विवरण में परियोजना ने सामान्य vLLM के प्रति सेकंड 488 टोकन के मुकाबले 842 टोकन बनने की बात कही है, यानी 1.73× बढ़ोतरी। इस तुलना का दायरा सीमित है: एक समय में एक अनुरोध, 16 GB300 GPU पर टेन्सर पैरेललिज़्म, सात ड्राफ्ट टोकन के साथ DSpark स्पेक्युलेटिव डिकोडिंग, छह की सिंथेटिक स्वीकृति लंबाई, एक टोकन का इनपुट और 1000 टोकन का आउटपुट। यह आँकड़ा प्रीफिल के बाद का कुल डिकोडिंग थ्रूपुट मापता है। यह नहीं मापता कि उपयोगकर्ता का पूरा अनुरोध कितनी जल्दी समाप्त होता है।

इस पथ का मूल्यांकन करने या न करने का निर्णय ले रहे इंजीनियरों के लिए उपयोगी बदलाव यह है कि डिकोड का उल्लेखनीय परिणाम और उसके लागू होने के दायरे का काफी स्पष्ट विवरण साथ में उपलब्ध हैं। मर्ज किए गए कार्यान्वयन को decode_backend: latency_specialized के ज़रिए खास तौर पर चालू करना होता है; डिफ़ॉल्ट auto सेटिंग सामान्य डिकोडिंग ही इस्तेमाल करती रहती है। vLLM के अनुसार विशेष पथ उन GB300 तैनातियों के लिए है जिनमें एक NVLink डोमेन में आठ या 16 GPU हों। प्रीफिल, मिले-जुले बैच और असमर्थित चरण सामान्य मॉडल फ़ॉरवर्ड पथ पर लौट जाते हैं।

समय कहाँ खर्च हो रहा था

Kimi K3 अपने मॉडल कार्ड के अनुसार एक बड़ा मिक्सचर-ऑफ़-एक्सपर्ट्स मॉडल है। डिकोडिंग के दौरान सर्विंग सिस्टम अगले टोकन बनाने के लिए बार-बार अटेंशन चलाता है, एक्सपर्ट चुनता है और GPU के बीच डेटा का आदान-प्रदान करता है। vLLM टीम ने एक CuTe DSL पथ बनाया जो अपेक्षित टेन्सर आकारों के लिए इन ऑपरेशनों को विशेष बनाता है। उसके विवरण में छोटे और बड़े बैच के लिए अलग अटेंशन प्रोजेक्शन कर्नेल; अटेंशन आउटपुट प्रोजेक्शन, GPU के बीच रिडक्शन और उसके बाद के रेज़िड्युअल काम का एकीकरण; हिस्सों में बाँटी गई राउटर गणनाएँ; साझा और रूट किए गए एक्सपर्ट के काम को ओवरलैप करना; तथा संचार के दौरान वेट पहले से लाना शामिल है। पोस्ट में दिखाए गए प्रति-लेयर ट्रेस में विशेष पथ 13 कर्नेल और 69 माइक्रोसेकंड इस्तेमाल करता है, जबकि सामान्य vLLM 23 कर्नेल और 130 माइक्रोसेकंड इस्तेमाल करता है। यह दिखाई गई कॉन्फ़िगरेशन का रिपोर्ट किया गया ट्रेस है, एप्लिकेशन की लेटेंसी का आँकड़ा नहीं।

कर्नेल के डिज़ाइन जितना ही दायरा भी मायने रखता है। पुल रिक्वेस्ट में TP8 और TP16 पर GB300 वैलिडेशन, बैच 64 तक नॉन-स्पेक्युलेटिव डिकोड, तीन से सात ड्राफ्ट टोकन के साथ DSpark सत्यापन और वैकल्पिक डिकोड कॉन्टेक्स्ट पैरेललिज़्म का विवरण है। उसमें कहा गया है कि प्रदर्शन सुधार के काम में FP8 KV कैश, FP32 SSM कैश और मॉडल प्रदाता के वेट इस्तेमाल हुए। यह पथ मॉडल वेट, शेड्यूलिंग, सैंपलिंग और DSpark ड्राफ्टर को नहीं बदलता। इससे सर्विंग टीम परिचित बाकी स्टैक के साथ बदले हुए डिकोड कार्यान्वयन की तुलना कर सकती है, लेकिन इसका अर्थ यह भी है कि यह अनुकूलन सर्विंग के हर हिस्से को तेज़ नहीं करता।

दोनों बेंचमार्क तालिकाएँ अलग-अलग पढ़ें

842 बनाम 488 वाले परिणाम में 16 GB300 GPU पर TP16, बैच 1, सात ड्राफ्ट टोकन वाला DSpark, छह की सिंथेटिक स्वीकृति लंबाई, DL=7, ISL=1 और OSL=1k इस्तेमाल हुए हैं। vLLM इस मेट्रिक को प्रति सेकंड कुल डिकोड टोकन कहता है और प्रीफिल को बाहर रखता है। सिंथेटिक स्वीकृति यह तय करती है कि बेंचमार्क कितने प्रस्तावित टोकन स्वीकार करेगा; यह उपयोगकर्ताओं के प्रॉम्प्ट से मापी गई स्वीकृति दर नहीं है। अलग प्रॉम्प्ट, स्वीकृति व्यवहार, बैच आकार या इनपुट लंबाई वाली तैनाती को अपना मापन करना होगा।

पोस्ट में एक नॉन-स्पेक्युलेटिव तालिका भी है। उदाहरण के लिए TP16 पर बैच 1 में प्रति सेकंड 256.4 टोकन और बैच 64 में 3606.1 टोकन बताए गए हैं, जो संबंधित सामान्य कॉन्फ़िगरेशन से क्रमशः 1.88× और 1.62× बेहतर हैं। ये स्पेक्युलेटिव डिकोडिंग के बिना पूरे TP समूह के कुल परिणाम हैं। इन्हें DSpark के आँकड़े के साथ जोड़कर बैच 64 में हर उपयोगकर्ता के लिए अधिक तेज़ अनुभव का दावा नहीं किया जा सकता।

पोस्ट का एक और आँकड़ा AgentX से जुड़ा है। यह ऐसा वर्कलोड है जो सिंथेटिक सामग्री के साथ कोडिंग एजेंट के ट्रैफ़िक पैटर्न दोबारा चलाता है। vLLM ने एक साथ एक अनुरोध होने पर प्रति उपयोगकर्ता प्रति सेकंड टोकन में P90 इंटरैक्टिविटी 403.2 बनाम 223.7 बताई है। अनुकूलित परिणाम 16 GB300 GPU पर चला, जबकि पिछली तुलना आठ GPU पर चली थी। कार्यान्वयन के साथ GPU की संख्या भी बदलती है, इसलिए यह 1.8× तुलना अकेले डिकोड पथ के सुधार को अलग नहीं करती। AgentX में लंबे कॉन्टेक्स्ट, संवाद के टर्न, विराम और कैश का दोबारा इस्तेमाल भी शामिल है, इसलिए उसकी मेट्रिक शुद्ध डिकोड बेंचमार्क से अलग सवाल का जवाब देती है।

सार्वजनिक पोस्ट और पहले की पुल-रिक्वेस्ट प्रदर्शन तालिका में थोड़ा अंतर है: दूसरी तालिका TP16, बैच 1, DSpark DL7 और छह की सिंथेटिक स्वीकृति के लिए प्रति सेकंड 838 बनाम 489 टोकन बताती है। यहाँ इस्तेमाल हुए 1.73× आँकड़े का स्रोत पोस्ट की 842 बनाम 488 तुलना है। पहले की तालिका मिलते-जुलते रन का उपयोगी साक्ष्य है, लेकिन दोनों जोड़ियों के आँकड़े मिलाने नहीं चाहिए। vLLM ने कोड और अपना वैलिडेशन प्रकाशित किया है; BIG CHANGE ने दोनों में से किसी रन को दोहराकर नहीं जाँचा है।

मूल्यांकन के लिए क्या चाहिए

सार्थक स्थानीय तुलना मर्ज की गई PR और उसमें बताई कॉन्फ़िगरेशन से शुरू होगी: Kimi K3 मॉडल प्रदाता के वही वेट, एक NVLink डोमेन में 16 GPU वाला GB300 सिस्टम, TP16, कैश फ़ॉर्मैट और मुख्य परीक्षण की सटीक DSpark सेटिंग। सामान्य auto और खास तौर पर चालू की गई latency_specialized सेटिंग को समान वर्कलोड पर चलाएँ। फिर डिकोड थ्रूपुट को प्रीफिल, पहले टोकन तक के समय, आउटपुट थ्रूपुट और अनुरोध-स्तरीय लेटेंसी से अलग दर्ज करें। कोई वर्कस्टेशन या छोटा GPU पूल 16-GB300 वाले मुख्य परिणाम को सीधे दोहरा नहीं सकता। पोस्ट उस सेटअप के किराये की लागत तय नहीं करती।

उस PR के वैलिडेशन विवरण में संख्यात्मक जाँच और मॉडल मूल्यांकन बताए गए हैं, जिनमें AIME25, GPQA-Diamond और लंबे कॉन्टेक्स्ट का MRCR परीक्षण शामिल है। वह विकास के दौरान मिली एक सिंक्रोनाइज़ेशन त्रुटि और लंबे आउटपुट वाले परीक्षणों में बदलाव भी बताता है। ये जाँच पाठकों को गति के चार्ट से अधिक चीज़ें परखने के लिए देती हैं, हालाँकि वे कार्यान्वयन करने वालों के ही साक्ष्य हैं। सर्विंग टीम को यह तय करना है कि उसका वास्तविक हार्डवेयर, बैचिंग, कॉन्टेक्स्ट की लंबाई और स्पेक्युलेटिव स्वीकृति समर्थित कॉन्फ़िगरेशन से इतने मिलते हैं या नहीं कि इस वैकल्पिक पथ को अपने ट्रैफ़िक पर मापना उचित हो।

बड़ा बदलाव

vLLM में मर्ज हुआ Kimi K3 पथ दस्तावेज़ीकृत बेंचमार्क और वैलिडेशन रिकॉर्ड के साथ एक विशेष, वैकल्पिक GPU डिकोड कार्यान्वयन उपलब्ध कराता है। सबसे प्रमुख सार्वजनिक परिणाम है 16 GB300 GPU पर TP16, बैच 1, DSpark के सात ड्राफ्ट टोकन और छह की सिंथेटिक स्वीकृति लंबाई के साथ प्रति सेकंड 842 बनाम 488 कुल डिकोड टोकन, यानी 1.73×। इसमें प्रीफिल शामिल नहीं है। किसी खास सेवा को लाभ होगा या नहीं, यह उस सेवा के हार्डवेयर और उसके अनुरोधों के पूरे वर्कलोड पर निर्भर करता है।

स्रोत और आगे पढ़ने के लिए

  • vLLM की 16 अक्टूबर की तकनीकी पोस्ट डिकोड बदलाव समझाती है और 842/488 सेटअप, नॉन-स्पेक्युलेटिव तालिका तथा AgentX तुलना देती है। परिणाम परियोजना और NVIDIA योगदानकर्ता Benjamin Chislett ने बताए हैं।
  • मर्ज की गई vLLM पुल रिक्वेस्ट #61867 वैकल्पिक सेटिंग, समर्थित कॉन्फ़िगरेशन, कार्यान्वयन का दायरा, वैलिडेशन और पहले की 838/489 DSpark तालिका का दस्तावेज़ देती है। यह कोड और परिणामों का रिकॉर्ड है, स्वतंत्र पुनरुत्पादन नहीं।
  • Moonshot AI का Kimi K3 मॉडल कार्ड कार्यान्वयन में संदर्भित मॉडल और वेट की पहचान करता है।
  • AgentX की कार्यप्रणाली अलग इंटरैक्टिविटी तुलना के पीछे के ट्रैफ़िक-रीप्ले वर्कलोड को समझाती है।