क्या हुआ?
शोधकर्ताओं ने DataKernelBench पेश किया, जो यह परीक्षण करने के लिए एक बेंचमार्क है कि क्या बड़े भाषा मॉडल GPU पर अनियमित, डेटा-आंदोलन-भारी डेटाबेस संचालन को अनुकूलित कर सकते हैं। सिस्टम SQL क्वेरीज़ को मान्य PyTorch TorchPlan प्रोग्राम में अनुवादित करता है, फिर मॉडल का मूल्यांकन करता है क्योंकि वे केंद्रीय टेंसर-बाउंड कोड अनुभाग या CUDA या ट्राइटन में पूर्ण क्वेरी को अनुकूलित करते हैं।
पेपर, 25 अगस्त, 2026 को arXiv को प्रस्तुत किया गया और ईएमएनएलपी 2026 में स्वीकार किए गए स्रोत में पहचाना गया, डेटा कर्नेलबेंच को विशेष रूप से जीपीयू पर डेटाबेस प्रश्नों के एआई-जनरेटेड अनुकूलन के मूल्यांकन के रूप में प्रस्तुत करता है। लेखकों का तर्क है कि मौजूदा एलएलएम कर्नेल बेंचमार्क डेटाबेस-शैली ऑपरेटरों का पर्याप्त परीक्षण नहीं करते हैं, जो अनियमित, विषम और डेटा आंदोलन पर हावी हो सकते हैं। यह बेंचमार्क के लक्ष्य को जेनरेट किए गए जीपीयू कोड का आकलन करने के लिए अक्सर उपयोग किए जाने वाले अधिक नियमित ऑपरेटरों से अलग बनाता है।
DataKernelBench SQL को मान्य PyTorch TorchPlan प्रोग्राम में परिवर्तित करता है। फिर मॉडलों को CUDA या ट्राइटन का उपयोग करके या तो कोर टेंसर-बाउंड स्निपेट या संपूर्ण क्वेरी को अनुकूलित करने के लिए कहा जाता है। मूल्यांकन में निष्पादन-निर्देशित मरम्मत शामिल है, जिसका अर्थ है कि उत्पन्न कार्यक्रमों का परीक्षण और उनके निष्पादन से फीडबैक के माध्यम से संशोधित किया जाता है। सार में कहा गया है कि अध्ययन में H100 GPU का उपयोग करके TPC-H SF10 वर्कलोड पर दस मालिकाना और ओपन-वेट मॉडल शामिल हैं।
पेपर के रिपोर्ट किए गए परिणामों के अनुसार, सबसे मजबूत पूर्ण-क्वेरी CUDA कॉन्फ़िगरेशन ने पूर्ण पास दर पर तुलना बेसलाइन पर 2.11× गति प्राप्त की। स्रोत बेसलाइन के नाम को उजागर नहीं करता है क्योंकि सार में उस स्थिति में एक विकृत लिंक होता है, इसलिए आपूर्ति की गई सामग्री से सटीक संदर्भ बिंदु की पहचान नहीं की जा सकती है। लेखक एक बड़े पैमाने के विस्तार की भी रिपोर्ट करते हैं: GPU मेमोरी से बड़े डेटा के लिए TorchPlan को Dashk-cuDF के साथ जोड़ा गया था, और TPC-H SF100 पर चार H100 GPU का उपयोग करके, सिस्टम ने रिपोर्ट की गई 2.54× स्पीडअप हासिल की।
कुल मिलाकर, सेटअप क्वेरी प्रतिनिधित्व से लेकर उत्पन्न प्रोग्राम निष्पादन और रिपोर्ट किए गए प्रदर्शन तक एक अनुक्रम को परिभाषित करता है। SQL इनपुट को एक मान्य टॉर्चप्लान प्रोग्राम के रूप में दर्शाया जाता है, जबकि अनुकूलन लक्ष्य या तो एक केंद्रीय टेंसर-बाउंड अनुभाग या पूर्ण क्वेरी हो सकता है। मॉडल-जनित परिणाम को केवल इसलिए पूर्ण नहीं माना जाता क्योंकि इसे लिखा जा चुका है; मूल्यांकन निष्पादन से फीडबैक के माध्यम से कार्यक्रमों का परीक्षण और संशोधन करने के लिए निष्पादन-निर्देशित मरम्मत का उपयोग करता है। हार्डवेयर और वर्कलोड सेटिंग्स भी रिपोर्ट किए गए प्रयोग का हिस्सा हैं: सार दस मालिकाना और ओपन-वेट मॉडल, टीपीसी-एच एसएफ 10 वर्कलोड और एक एच 100 जीपीयू का वर्णन करता है। यह चार एच100 जीपीयू के साथ टीपीसी-एच एसएफ100 पर बड़े पैमाने के टॉर्चप्लान और डस्क-सीयूडीएफ कॉन्फ़िगरेशन का अलग से वर्णन करता है। उस संरचना के भीतर, रिपोर्ट किए गए स्पीडअप बताए गए कॉन्फ़िगरेशन और पास स्थिति के परिणाम हैं, जबकि विकृत बेसलाइन लिंक आपूर्ति किए गए स्रोत में तुलना संदर्भ को अज्ञात छोड़ देता है। यह वह दायरा है जो सार बेंचमार्क और उसके रिपोर्ट किए गए मूल्यांकन के बारे में प्रदान करता है। परिणामस्वरूप विवरण अनुकूलित की जा रही वस्तुओं, प्रोग्रामिंग विकल्पों, मरम्मत तंत्र, मूल्यांकन किए गए कार्यभार, हार्डवेयर सेटिंग्स और दो रिपोर्ट किए गए प्रदर्शन परिणामों की पहचान करता है, लेकिन यह सार में दिए गए विवरणों से परे विवरण नहीं जोड़ता है।
यह क्यों मायने रखता है?
यह कार्य मौजूदा एलएलएम कोडिंग बेंचमार्क में अंतर को संबोधित करता है, जो लेखकों का कहना है कि डेटाबेस वर्कलोड के बजाय मशीन-लर्निंग ऑपरेटरों पर काफी हद तक ध्यान केंद्रित किया गया है। यदि रिपोर्ट किए गए परिणाम व्यापक कार्यभार पर टिके रहते हैं, तो भाषा मॉडल GPU-त्वरित डेटाबेस को तेज़ बनाने के लिए आवश्यक विशेष कर्नेल इंजीनियरिंग के लिए उपयोगी सहायक बन सकते हैं।
व्यावहारिक महत्व यह है कि डेटाबेस का प्रदर्शन अक्सर कार्यभार-विशिष्ट कार्यान्वयन विकल्पों पर निर्भर करता है, न कि केवल तेज़ सामान्य-उद्देश्य प्रणाली के चयन पर। पेपर का केंद्रीय दावा यह है कि एलएलएम संपूर्ण प्रश्नों के लिए जीपीयू प्रोग्राम तैयार और मरम्मत करके इस विशेष अनुकूलन प्रक्रिया में भाग ले सकते हैं। यह मॉडल को एक बेंचमार्क की तुलना में वास्तविक डेटाबेस वर्कलोड की संरचना के करीब रखता है जो अलग-अलग मशीन-लर्निंग कर्नेल का मूल्यांकन करता है।
रिपोर्ट किए गए निष्कर्ष मॉडल क्षमता और कार्यभार जानकारी के बीच श्रम के विभाजन की ओर भी इशारा करते हैं। लेखकों का कहना है कि उच्च प्रदर्शन वाले कार्यान्वयन आमतौर पर कर्नेल फ़्यूज़न और निष्पादन रणनीति में बदलाव का उपयोग करते हैं। वे यह भी रिपोर्ट करते हैं कि वर्कलोड संदर्भ हार्डवेयर संदर्भ से अधिक मायने रखता है, और मजबूत मॉडल पूर्ण-क्वेरी विशेषज्ञता से सबसे अधिक लाभान्वित होते हैं। व्यावहारिक रूप से, परिणाम से पता चलता है कि क्वेरी और उसके डेटा के विस्तृत विवरण के साथ मॉडल की आपूर्ति केवल उस GPU का वर्णन करने से अधिक मायने रख सकती है जिस पर कोड चलेगा।
परिणाम एक शोध दिशा के रूप में परिणामी हैं, लेकिन वे इस बात का प्रमाण नहीं हैं कि डेटाबेस इंजीनियरिंग को उत्पादन में स्वचालित किया गया है। स्रोत एक बेंचमार्क और नियंत्रित प्रयोगों का वर्णन करता है, न कि लाइव डेटाबेस सेवा में तैनाती का। यह यह भी स्थापित नहीं करता है कि उत्पन्न कोड परीक्षण किए गए प्रश्नों के बाहर लगातार सही है, कि मानव-लिखित कर्नेल की तुलना में इसका उत्पादन करना सस्ता है, या कि स्पीडअप डेटा वितरण और परिचालन आवश्यकताओं को बदलने से बच जाएगा। वे सीमाएँ महत्वपूर्ण हैं क्योंकि एक तेज़ क्वेरी जो किनारे के मामले में विफल हो जाती है वह प्रयोग करने योग्य डेटाबेस अनुकूलन नहीं है।
इंटरैक्टिव तंत्र: यह वास्तव में कैसे काम करता है
इस विकास के पीछे अंतर्निहित प्रौद्योगिकी का अंतःक्रियात्मक रूप से अन्वेषण करें।
Which component of an AI application is the machine-learning model itself?
आगे क्या देखना है
मुख्य प्रश्न यह हैं कि क्या परिणाम परीक्षण किए गए टीपीसी-एच वर्कलोड से परे सामान्यीकृत होते हैं, बेंचमार्क एक पूर्ण पास को कैसे परिभाषित करता है, और क्या रिपोर्ट की गई स्पीडअप विकास, सत्यापन और हार्डवेयर लागतों के लिए लेखांकन के बाद भी बनी रहती है। प्रदत्त स्रोत एक सार है, इसलिए वे विवरण और स्वतंत्र प्रतिकृति अनसुलझे हैं।
देखने लायक पहला मुद्दा प्रतिलिपि प्रस्तुत करने योग्यता है। सार संख्या और व्यापक प्रकार के मॉडल, हार्डवेयर और टीपीसी-एच स्केल कारकों की पहचान करता है, लेकिन यह मॉडल का नाम नहीं देता है, उनके संकेतों का वर्णन नहीं करता है, पास-दर गणना निर्दिष्ट करता है, या पूर्ण तुलना आधार रेखा प्रदान नहीं करता है। वे विवरण यह निर्धारित करेंगे कि सिस्टम का मूल्यांकन कितनी निष्पक्षता से किया गया था और अन्य लोग कितनी आसानी से प्रयोगों को दोहरा सकते हैं।
सामान्यीकरण एक और खुला प्रश्न है। रिपोर्ट किए गए परीक्षण एक H100 GPU पर TPC-H SF10 और चार H100 GPU पर TPC-H SF100 का उपयोग करते हैं। स्रोत यह नहीं बताता है कि डेटा कर्नेलबेंच अन्य क्वेरी परिवारों, डेटाबेस इंजन, डेटा वितरण, जीपीयू पीढ़ियों या मिश्रित सीपीयू-जीपीयू तैनाती को कवर करता है या नहीं। यह यह भी स्थापित नहीं करता है कि जब डेटा कम संरचित तरीकों से मेमोरी से अधिक हो जाता है, या जब बदलते उत्पादन भार के तहत शुद्धता और विलंबता को बनाए रखा जाना चाहिए तो दृष्टिकोण कैसे व्यवहार करता है।
अंत में, भविष्य के मूल्यांकनों को एलएलएम-आधारित ऑप्टिमाइज़र का उपयोग करने की पूरी लागत से कच्ची निष्पादन गति को अलग करना चाहिए। प्रासंगिक उपायों में पीढ़ी का समय, मरम्मत प्रयासों की संख्या, सत्यापन ओवरहेड, जीपीयू उपयोग, मेमोरी उपयोग और विफल या अस्वीकृत कार्यक्रमों की लागत शामिल होगी। सूत्र का कहना है कि निष्पादन-निर्देशित मरम्मत विधि का हिस्सा है, लेकिन सार उस प्रक्रिया के लिए कोई आंकड़े नहीं देता है। जब तक उन अज्ञात की रिपोर्ट नहीं की जाती है और स्वतंत्र रूप से परीक्षण नहीं किया जाता है, तब तक 2.11× और 2.54× आंकड़ों को इस पेपर द्वारा बताई गई प्रयोगात्मक शर्तों के तहत दावा किए गए परिणामों के रूप में माना जाना चाहिए, न कि सामान्य प्रदर्शन गारंटी के रूप में।