Markdown आवृत्ती

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

# vLLM च्या Kimi K3 डिकोड मार्गाने विशिष्ट GB300 चाचणीत सेकंदाला 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 नुसार हा विशेष मार्ग एका NVLink डोमेनमध्ये आठ किंवा 16 GPU असलेल्या GB300 उपयोजनांसाठी आहे; प्रीफिल, मिश्र बॅच आणि समर्थित नसलेले टप्पे मानक मॉडेल फॉरवर्ड मार्गाकडे परत जातात.

## वेळ कुठे खर्च होत होता

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-गटाचे निकाल आहेत. बॅच 64 वर प्रत्येक वापरकर्त्याचा अनुभव अधिक वेगवान होतो असा दावा करण्यासाठी हे निकाल DSpark च्या आकड्याबरोबर एकत्र करता येत नाहीत.

पोस्टमधील आणखी एक आकडा [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, Hyper Optimizing Kimi K3 in vLLM: Moving Fast and Responsibly (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 ची संख्याही बदलते.