AI-translated from English; not yet reviewed by a fluent editor.

# एक खास GB300 परीक्षण में vLLM के Kimi K3 डिकोड पथ ने प्रति सेकंड 842 टोकन हासिल किए

> vLLM ने एक खास DSpark कॉन्फ़िगरेशन में 16 GB300 GPU पर Kimi K3 के लिए कुल डिकोड गति प्रति सेकंड 842 बनाम 488 टोकन बताई है। इसमें प्रीफिल शामिल नहीं है।

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

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

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

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

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

कर्नेल के डिज़ाइन जितना ही दायरा भी मायने रखता है। [पुल रिक्वेस्ट](https://github.com/vllm-project/vllm/pull/61867) में 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 इस मेट्रिक को प्रति सेकंड कुल डिकोड टोकन कहता है और प्रीफिल को बाहर रखता है। सिंथेटिक स्वीकृति यह तय करती है कि बेंचमार्क कितने प्रस्तावित टोकन स्वीकार करेगा; यह उपयोगकर्ताओं के प्रॉम्प्ट से मापी गई स्वीकृति दर नहीं है। अलग प्रॉम्प्ट, स्वीकृति व्यवहार, बैच आकार या इनपुट लंबाई वाली तैनाती को अपना मापन करना होगा।

पोस्ट में एक [नॉन-स्पेक्युलेटिव तालिका](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation) भी है। उदाहरण के लिए TP16 पर बैच 1 में प्रति सेकंड 256.4 टोकन और बैच 64 में 3606.1 टोकन बताए गए हैं, जो संबंधित सामान्य कॉन्फ़िगरेशन से क्रमशः 1.88× और 1.62× बेहतर हैं। ये स्पेक्युलेटिव डिकोडिंग के बिना पूरे TP समूह के कुल परिणाम हैं। इन्हें DSpark के आँकड़े के साथ जोड़कर बैच 64 में हर उपयोगकर्ता के लिए अधिक तेज़ अनुभव का दावा नहीं किया जा सकता।

पोस्ट का एक और आँकड़ा [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx) से जुड़ा है। यह ऐसा वर्कलोड है जो सिंथेटिक सामग्री के साथ कोडिंग एजेंट के ट्रैफ़िक पैटर्न दोबारा चलाता है। vLLM ने एक साथ एक अनुरोध होने पर प्रति उपयोगकर्ता प्रति सेकंड टोकन में P90 इंटरैक्टिविटी 403.2 बनाम 223.7 बताई है। अनुकूलित परिणाम **16 GB300 GPU** पर चला, जबकि पिछली तुलना **आठ GPU** पर चली थी। कार्यान्वयन के साथ GPU की संख्या भी बदलती है, इसलिए यह 1.8× तुलना अकेले डिकोड पथ के सुधार को अलग नहीं करती। AgentX में लंबे कॉन्टेक्स्ट, संवाद के टर्न, विराम और कैश का दोबारा इस्तेमाल भी शामिल है, इसलिए उसकी मेट्रिक शुद्ध डिकोड बेंचमार्क से अलग सवाल का जवाब देती है।

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

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

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

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

## बड़ा बदलाव

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

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

- [vLLM की 16 अक्टूबर की तकनीकी पोस्ट](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) डिकोड बदलाव समझाती है और 842/488 सेटअप, नॉन-स्पेक्युलेटिव तालिका तथा AgentX तुलना देती है। परिणाम परियोजना और NVIDIA योगदानकर्ता Benjamin Chislett ने बताए हैं।
- [मर्ज की गई vLLM पुल रिक्वेस्ट #61867](https://github.com/vllm-project/vllm/pull/61867) वैकल्पिक सेटिंग, समर्थित कॉन्फ़िगरेशन, कार्यान्वयन का दायरा, वैलिडेशन और पहले की 838/489 DSpark तालिका का दस्तावेज़ देती है। यह कोड और परिणामों का रिकॉर्ड है, स्वतंत्र पुनरुत्पादन नहीं।
- [Moonshot AI का Kimi K3 मॉडल कार्ड](https://huggingface.co/moonshotai/Kimi-K3) कार्यान्वयन में संदर्भित मॉडल और वेट की पहचान करता है।
- [AgentX की कार्यप्रणाली](https://inferencex.semianalysis.com/agentx) अलग इंटरैक्टिविटी तुलना के पीछे के ट्रैफ़िक-रीप्ले वर्कलोड को समझाती है।

## Sources

- [vLLM, vLLM में Kimi K3 का गहन अनुकूलन: तेज़ और ज़िम्मेदार प्रगति (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — प्रथम-पक्षीय तकनीकी विवरण और 842/488, 1.73× परिणाम का स्रोत। इसमें 16 GB300 GPU पर TP16, बैच 1, DSpark DL7, सिंथेटिक AL6, ISL1, OSL1k और प्रीफिल के बिना कुल डिकोड TPS बताए गए हैं। अलग नॉन-स्पेक्युलेटिव और AgentX परिणाम भी दिए हैं।
- [vLLM पुल रिक्वेस्ट #61867, Kimi K3 विशेष डिकोड](https://github.com/vllm-project/vllm/pull/61867) — मर्ज किया गया कार्यान्वयन और लेखकों के चलाए वैलिडेशन का रिकॉर्ड। अंतिम वैकल्पिक सेटिंग, समर्थित कॉन्फ़िगरेशन और सामान्य पथ पर वापसी का दस्तावेज़ देता है। पहले की DSpark तालिका TP16 B1 सिंथेटिक AL6 पर 838/489 बताती है, इसलिए उन आँकड़ों को ब्लॉग की जोड़ी के साथ नहीं मिलाया गया है।
- [Moonshot AI, Kimi K3 मॉडल कार्ड](https://huggingface.co/moonshotai/Kimi-K3) — मॉडल और मॉडल प्रदाता के वेट की पहचान करता है; vLLM के प्रदर्शन को स्वतंत्र रूप से सिद्ध नहीं करता।
- [InferenceX, AgentX कार्यप्रणाली और डेटासेट](https://inferencex.semianalysis.com/agentx) — अलग से बताई गई इंटरैक्टिविटी तुलना में इस्तेमाल ट्रैफ़िक-रीप्ले वर्कलोड समझाता है। vLLM की तुलना में GPU की संख्या भी बदलती है।