यह वह Kimi K3 पोस्ट है जिसका आप लोग इंतज़ार कर रहे थे। मुझे इस मॉडल तक कुछ जल्दी पहुँच मिली और मैंने इसे कर्नेल पर परीक्षण किया है, और बेंचमार्क स्कोर देखने से पहले ही, समस्याओं के माध्यम से तर्क करने और इसके विचार ट्रेस की तकनीकी घनत्व से मैं प्रभावित था। इस चीज़ पर पोस्ट-ट्रेनिंग उस समय स्पष्ट हो जाती है जब आप एक ट्रांसक्रिप्ट पढ़ते हैं। इससे बात करना भी बहुत मज़ेदार है।
TLDR;
मेरा मानना है कि एक कर्नेल और प्रदर्शन इंजीनियर के रूप में, जो बेंचमार्क से अलग है, मेरे लिए अपनी ईमानदार प्रतिक्रिया देना महत्वपूर्ण है (यह भाग वॉइस टाइप किया गया है)। बेशक, आप सभी नंबरों को देख सकते हैं और उन्हें पढ़ सकते हैं और अपने लिए एक मानसिक मॉडल विकसित करने का प्रयास कर सकते हैं। मेरा मानना है कि सबसे ईमानदार प्रतिबिंब यह होगा कि मैं आपको बेंचमार्क परिणाम सामने आने से पहले, कठिन कार्यों पर मॉडल के साथ अपना अनुभव बताऊं, जब मैं मॉडल का उपयोग कर रहा था, इससे पहले कि अन्य मॉडलों से जोड़ने के लिए कोई संख्या हो। केवल विशुद्ध रूप से बुद्धिमत्ता, तर्क, एजेंट डेलिगेशन, और यह मेरे लिए कितना ऑटोपायलटिंग कर सकता है, इसे महसूस करना, लेकिन इससे पहले कि कोई हाइप चक्कर लगाती और आधिकारिक परिणाम सामने आते। मैं कहूंगा कि मेरे निर्देशन में, यह मोटे तौर पर Fable स्तर के आसपास महसूस हुआ, कुछ मामलों में बहुत अनोखे तरीकों से बेहतर प्रदर्शन करता हुआ और कुछ मामलों में कम प्रदर्शन करता हुआ। मैं कहूंगा कि यह मॉडल अधिकांश चीजों पर निश्चित रूप से Opus 4.8 से आगे है और कई चीजों पर GPT 5.6 Sol से आगे है।
इसमें गहराई से उतरते हुए...
मैं इस बारे में स्पष्ट होना चाहता हूं कि यह अब क्यों बाहर जा रहा है: मैं अपने ईमानदार विचार और स्कोर जैसे वे हैं, साझा करना चाहता था, न कि उन पर तब तक बैठे रहना जब तक हर आखिरी सेल खत्म न हो जाए। जैसा कि मैं यह लिख रहा हूं, कुछ रन अभी भी चल रहे हैं। वे नीचे चिह्नित हैं, और जैसे ही वे पूरे होंगे, मैं आपको अपडेट करता रहूंगा। मैंने 256K और 1M कॉन्टेक्स्ट दोनों संस्करण चलाए। यहां सब कुछ NVIDIA RTX PRO 6000 Blackwells, H100s, और B200s पर, केवल सिंगल-GPU ऑप्टिमाइज़ेशन के साथ चलाया गया था। प्रत्येक सेल एक स्वायत्त एजेंट सत्र है जिसमें असीमित वॉल-क्लॉक है: मॉडल को समस्या मिलती है, वास्तविक हार्डवेयर पर एक लाइव कंपाइल/चेक/बेंचमार्क लूप, और यह तय करता है कि वह कब पूरा हो गया है। प्रत्येक हेडलाइन सेल को रिवॉर्ड हैकिंग के लिए मैन्युअल रूप से ऑडिट किया गया था। एक अलग एजेंट अंतिम कर्नेल को शुरू से अंत तक पढ़ता है और पूर्ण सत्र ट्रेस करता है और अनुभवजन्य रूप से किसी भी चीज़ का फिर से परीक्षण करता है जो कैशिंग या ग्रेडर गेम्स की तरह गंध करती है। उन ऑडिट में क्या पाया गया, इसका अपना खंड है।
कुछ जो मैं जानना चाहता था
एक चीज़ थी जिसके चारों ओर मैंने विशेष रूप से इस रिलीज़ को डिज़ाइन किया था: दो समस्याएं Moonshot की अपनी आर्किटेक्चर हैं। Hard डेक में एक स्टैंडअलोन Kimi Delta Attention चंक-फॉरवर्ड कर्नेल है, और Mega डेक की प्रमुख समस्या एक पूर्ण Kimi-Linear हाइब्रिड डिकोड स्टेप है: KDA लेयर्स, MLA अटेंशन, MoE एक्सपर्ट्स, पूरा ब्लॉक। तो यह किसी ऐसी चीज़ का परीक्षण करने का एक अवसर था जो कोई भी बहुत बार परीक्षण नहीं कर पाता: जब एक लैब का मॉडल उसी लैब की आर्किटेक्चर के लिए कर्नेल लिखने बैठता है, तो क्या परिवार का ज्ञान CUDA में दिखाई देता है?
जवाब वास्तव में विभाजित निकला, और दोनों हिस्से दिलचस्प हैं। अगले भाग के माध्यम से उस प्रश्न को ध्यान में रखें।
KernelBench-Mega
प्रमुख मेगा समस्या: एक संपूर्ण प्रति-टोकन Kimi-Linear डिकोड स्टेप (3x KDA + 1x MLA लेयर, W4A16 क्वांटाइज़्ड वेट, टॉप-8 रूटिंग के साथ MoE) को यथासंभव कम कर्नेल लॉन्च में फ्यूज़ करना।
K3 ने अपनी ही वंशावली पर, लगभग सर्वकालिक रिकॉर्ड ले लिया। RTX PRO 6000 पर उत्सुक पर 18.09x जियोमीन स्पीडअप, Fable 5 के रिकॉर्ड 18.72x से 4% के भीतर। H100 पर इसने Opus 4.8 के 15.50x के मुकाबले 14.82x पोस्ट किया। एक ईमानदारी नोट जो अनुपात छुपाता है: पूर्ण प्रति-टोकन विलंबता में Fable अभी भी ~1.4x आगे है (0.31 बनाम 0.44 ms/tok at ctx 2048; दोनों रनों ने विभिन्न CPU वाले होस्ट का उपयोग किया, जो उत्सुक आधार रेखा को स्थानांतरित करता है जिसके विरुद्ध अनुपात की गणना की जाती है), इसलिए मैं दोनों की रिपोर्ट करता हूं बजाय इसके कि जियोमीन किसी को चापलूसी करने दे।
K3 ने जो बनाया वह एक सच्चा मेगाकर्नेल है। इसके पहले सत्र ने समझदारी भरा काम किया, 14.1x पर एक स्थायी Triton कर्नेल। इसके दूसरे सत्र ने Triton को फेंक दिया और संपूर्ण प्रति-टोकन डिकोड स्टेप को एक सहकारी रूप से लॉन्च किए गए CUDA कर्नेल के रूप में लिखा: लूप में शून्य CPU, प्रत्येक GEMV के अंदर फ्लाई पर int4 वेट डीक्वांटाइज़ किए गए ताकि वे SMs के माध्यम से ठीक एक बार स्ट्रीम करें, टेंसर कोर पर MLA अटेंशन। कोई प्रोडक्शन इंजन 1,228-लाइन के ऐसे आर्टिफैक्ट को बनाए नहीं रखेगा। एक एजेंट जिसके पास जीतने के लिए एक कर्नेल है और असीमित समय है, उस पर ऐसा कोई बंधन नहीं है, और ठीक इस तरह की चीज़ को सतह पर लाना ही बेंच का कारण है।
मेगाकर्नेल यहां देखें:
तो यह अभी भी Fable से क्यों हारा? समय नहीं। दोनों सत्र जल्दी समाप्त हो गए (Fable 2.6 घंटे पर, K3 3.3 पर)। अंतर डिज़ाइन दर्शन का है, और यह इसके विपरीत है जो आप अनुमान लगाएंगे: K3 वह है जो टेंसर कोर का उपयोग कर रहा है, और Fable के कर्नेल में शून्य MMA निर्देश हैं। फ्यूज़्ड int4 GEMVs के साथ बैच-1 डिकोड बैंडविड्थ-बाउंड है, इसलिए टेंसर कोर यहां लगभग कुछ नहीं खरीदते हैं। Fable ने वह प्रयास सिंक्रनाइज़ेशन पर खर्च किया, इसके अधिकांश वैश्विक बाधाओं को बारीक-दाने वाले उत्पादक-उपभोक्ता हैंडऑफ़ से बदल दिया ताकि कोई SM कभी भी स्टेज सीमा पर निष्क्रिय न हो, और एक int4 डीक्वांट पथ पर जो रेफरेंस के राउंडिंग से बिट-फॉर-बिट मेल खाता हो ताकि MoE राउटर कभी भी एक विशेषज्ञ विकल्प को फ्लिप न करे। K3 बेहतर हार्डवेयर निर्देश लाया; Fable बेहतर कंकरेंसी इंजीनियरिंग लाया, और इस अंकगणितीय तीव्रता पर दूसरा जीतता है। यह एक वास्तविक सिस्टम सबक है, और इसने घरेलू टीम को रिकॉर्ड खर्च कर दिया।
दूसरी मेगा समस्या एक ग्रिड-फोरेजिंग PPO प्रशिक्षण मेगाकर्नेल है: 11x11 बोर्ड पर 4,096 वेक्टराइज़्ड एजेंट, जिसमें संपूर्ण RL प्रशिक्षण लूप (env स्टेप, पॉलिसी फॉरवर्ड, एक्शन सैंपलिंग, GAE, PPO अपडेट) फ्यूज़्ड स्थायी कर्नेल के रूप में चल रहा है। इस समस्या का डेक पर सबसे सख्त बाधा है: कर्नेल-लॉन्च काउंट को env स्टेप्स के साथ स्केल नहीं करना चाहिए, और CUDA ग्राफ कैप्चर को लॉन्च-ओवरहेड वर्कअराउंड के रूप में स्पष्ट रूप से प्रतिबंधित किया गया है, जिसे एक पोस्ट-रन प्रामाणिकता न्यायाधीश द्वारा लागू किया गया है जो अंतिम कोड पढ़ता है। शुद्धता स्वयं सीखने की अवस्था है। check.py आपके समाधान को सीड्स में संदर्भ के विरुद्ध प्रशिक्षित करता है और आवश्यकता है कि रिटर्न एक बैंड में आए, इसलिए आप तेजी से जाने के लिए सीखने को छोड़ नहीं सकते। K3 ने यहां संदर्भ पर 20.7x पोस्ट किया, अब तक का सर्वश्रेष्ठ स्कोर (एकमात्र अन्य प्रकाशित सेल GPT-5.6 Sol 1.06x पर है, इसलिए इसे एक पोडियम के बजाय एक डेटा पॉइंट के रूप में मानें)।
KernelBench-CUDA
CUDA बेंच मौजूद है क्योंकि Triton एक बैसाखी है जिसे अन्य दो डेक अनुमति देते हैं। यहां एक भाषा गेट Triton, कर्नेल DSLs, और PyTorch op-चेन को हार्ड-फेल करता है: आप CUDA लिखें या असफल हों। मैंने चार समस्याओं को वास्तविक प्रोडक्शन इन्फेरेंस और सिमुलेशन वर्कलोड के कट के रूप में चुना। पढ़ते समय मानसिक तुलना यह होनी चाहिए "vLLM या SGLang आज इसके लिए क्या शिप करता है, और एक एजेंट सत्र कितना करीब पहुंचता है।" यह वह जगह है जहां K3 ने अपनी सबसे असंतुलित जीत पोस्ट की।
02_deepseek_nsa: DeepSeek's Native Sparse Attention। NSA प्रमुख ट्रेनएबल-स्पार्सिटी अटेंशन डिज़ाइन है, वह चीज़ जिसके चारों ओर हर लॉन्ग-कॉन्टेक्स्ट सर्विंग स्टैक चक्कर लगा रहा है, और इसका मूल्यांकन मिलीसेकंड में किया जाता है क्योंकि एक सही स्पार्स कर्नेल कभी भी घने-समतुल्य FLOPs को निष्पादित नहीं करता है जो एक रूफलाइन गिनना चाहेगा। K3 के 256K वेरिएंट ने Opus 4.8 के 0.178 के मुकाबले 0.425 स्कोर किया, 2.4x का अंतर , पूर्ण NSA चयन तर्क के चारों ओर एक स्क्रैच से फ्लैश-अटेंशन-क्लास टेंसर-कोर पाइपलाइन लिखकर। तेज तुलना परिवार के अंदर है: 1M वेरिएंट ने वही एल्गोरिदम लिखा, समान ब्लॉक चयन, समान शुद्धता, लेकिन टेंसर कोर के बजाय सादे CUDA कोर पर हर डॉट प्रोडक्ट चलाया और 0.058 पर उतरा, समान आकृतियों पर 7x धीमा। इसका ट्रेस दिखाता है कि यह बेहतर जानता था। इसके पास अपने स्वयं के रोडमैप पर "टेंसर-कोर अटेंशन" था ("चयन टेंसर कोर पर = ~10-20 us !!") और स्पष्ट रूप से पहले मापने और दूसरे टेंसर-कोर रीराइट करने की योजना बनाई, फिर रीराइट से पहले अपना सत्र समाप्त कर दिया। समान ज्ञान, विभिन्न समापन अनुशासन।
0.425 DeepSeek NSA कर्नेल (256K):
03_megaqwen_decode: एक वास्तविक मेगाकर्नेल को रीटार्गेट करना। एकमात्र समस्या जहां एजेंटों को काम कर रहे प्रोडक्शन CUDA दिया जाता है: मेरा प्रकाशित MegaQwen (https://github.com/Infatoshi/megaqwen) सहकारी मेगाकर्नेल (~530 tok/s RTX 3090 पर पूर्ण मॉडल चला रहा है), इसे पढ़ने, इसे Blackwell पर रीटार्गेट करने और इसे हराने के निर्देशों के साथ। यह किसी और के CUDA को पढ़ने और एक आर्किटेक्चरल निर्णय कॉल करने का परीक्षण करता है, और K3 और Opus ने बिल्कुल विपरीत कॉल किए। K3 ने सिंगल-लॉन्च संरचना रखने से इनकार कर दिया: इसने स्टेप को मुट्ठी भर बैंडविड्थ-सैचुरेटिंग कर्नेल में विभाजित किया, फिर लॉन्च ओवरहेड को एक अलग तरीके से मिटा दिया, एक बार पूरे स्टेप को CUDA ग्राफ के रूप में कैप्चर करके जो शून्य CPU कार्य के साथ रीप्ले करता है। 6,283 tok/s at ctx 2048। Opus ने मेगाकर्नेल सौंदर्य को संरक्षित किया और पूरे डिकोड लूप को एक स्थायी सहकारी कर्नेल में फ्यूज़ कर दिया, वास्तव में सुंदर कोड, और इसके लिए 5x भुगतान किया (1,020 tok/s), क्योंकि सहकारी सह-आवासीयता अधिभोग को सीमित करती है और हर ग्रिड-व्यापी बाधा सभी 188 SMs में स्टेज टेल्स को अनुक्रमिक करती है। मेगाकर्नेल-वंशज समस्या पर, जिस मॉडल ने सचमुच एक मेगाकर्नेल बनाया वह अंतिम स्थान पर आया, और विजेता का प्रमुख निर्णय एक बनाने से इनकार करना था। स्केल चेक करें ताकि कोई भी हेडलाइन को गलत उद्धृत न करे: बेंच Qwen3-0.6B ज्योमेट्री की 4 लेयर चलाता है, लगभग 63M पैरामीटर, पूर्ण मॉडल नहीं, और 6,283 tok/s उस स्टैक के लिए वेट-स्ट्रीमिंग रूफलाइन का ~56% है; 3090 बेसलाइन के अपने आंकड़े को स्केल करने पर ~7,000 का अनुमान लगता है, इसलिए K3 "संदर्भ, रीटार्गेटेड, प्लस रियल ट्यूनिंग" के वर्ग में उतरा। (डेक-डिज़ाइन की बारीकियां: CUDA ग्राफ यहां उचित खेल हैं और PPO समस्या पर प्रतिबंधित हैं। प्रत्येक समस्या ठीक उसी शॉर्टकट को गैरकानूनी घोषित करती है जो उसके विशेष कौशल को नकली बनाएगा।)
01_glm52_fused_moe: GLM-5.2 का फ्यूज़्ड MoE ब्लॉक। फ्यूज़्ड MoE डिस्पैच (रूटिंग, परम्यूटेशन, ग्रुप्ड एक्सपर्ट GEMMs एक पास में) वर्तमान ओपन-मॉडल सर्विंग में सबसे हॉट कर्नेल क्लास है, और GLM 5.2 इसी लीडरबोर्ड पर बैठता है, इसलिए मॉडल एक प्रतिद्वंद्वी के प्रोडक्शन ब्लॉक को ऑप्टिमाइज़ कर रहे हैं। किसी ने इसे क्रैक नहीं किया है: स्कोर 0.05-0.08 पीक पर क्लस्टर करते हैं, और स्वच्छ रिकॉर्ड धारक, सभी मॉडलों में से, Grok 4.5 0.084 पर है, जिसके पीछे K3 का 1M वेरिएंट 0.081 पर और Opus 0.065 पर है। ग्रुप्ड-GEMM परम्यूटेशन समस्या cuBLAS-क्लास बेसलाइन को हराने के लिए वास्तव में कठिन है, और अब तक एक एजेंट-सत्र के प्रयास का मूल्य इसे डेक पर किसी भी अन्य समस्या की तुलना में कम स्थानांतरित करता है।
04_grid_mingru_sps: ग्रिड वर्ल्ड + MinGRU पॉलिसी रोलआउट। मेगा PPO समस्या का इन्फेरेंस-साइड सिबलिंग, और craftax.cu-वंशावली सेल: पॉलिसी मेरे https://github.com/infatoshi/craftax.cu क्लासिक बेंच से सीधे 3-लेयर MinGRU (h=256) कॉन्फिग है, जो समस्या के सूचनात्मक लंगर के रूप में कार्य करता है। जिस एनवायरनमेंट को स्टेप किया जा रहा है वह पूर्ण Craftax गेम के बजाय न्यूनतम ग्रिड-फोरेजिंग वर्ल्ड है। यह जानबूझकर है: एनवायरनमेंट को तुच्छ रखा जाता है ताकि स्कोर पुनरावृत्ति और रोलआउट फ्यूज़न को मापे, न कि गेम-लॉजिक कार्यान्वयन को। एक पूर्ण craftax पोर्ट अपनी खुद की समस्या होगी, और मैं इसे जोड़ना चाहता हूं। एक शांत RTX PRO 6000 पर प्रति सेकंड चरणों में ग्रेड किया गया, फ्यूज़न वैकल्पिक।
1M स्थायी-कर्नेल रोलआउट:
हर गंभीर सबमिशन स्थायी-मेगाकर्नेल में गया, और उनके बीच का प्रसार सिंक्रनाइज़ेशन डिज़ाइन है, वही सबक जो मेगा डेक का है। Opus इसे सीलिंग के 0.327 पर लेता है (इसने एक चतुर बीजगणितीय फोल्ड भी पाया: लेयर 0 का 768x256 गेट GEMM 768x4 में ढह जाता है क्योंकि एनकोडर रैखिक है), K3 [1M] दूसरा 0.224 पर, K3 256K 0.174 पर, Grok 0.002 पर बहुत पीछे। चूंकि समस्या craftax.cu से उत्पन्न होती है, मैंने अपना स्वयं का पूर्ण-गेम Craftax CUDA पोर्ट (Fable 5 के साथ लिखा गया) भी उसी GPU पर लूप में समान h256x3 पॉलिसी के साथ रखा। लाखों में प्रति सेकंड एनवायरनमेंट स्टेप्स:
तुलना बिंदु: मॉडल एक खाली ग्रिड को स्टेप करते हैं, craftax_full.cu पूर्ण गेम (43 क्रियाएं, मल्टी-फ्लोर डंगऑन, वर्ल्डजेन, मॉब्स) को अपने CPU संदर्भ के बिट-समान रूप से स्टेप करता है, और पूर्ण गेम अभी भी सबसे अच्छे तुच्छ-ग्रिड कर्नेल के ~3-4x के भीतर चलता है, क्योंकि h=256 पर सब कुछ पॉलिसी-GEMM-बाउंड है और एनवायरनमेंट लगभग मुफ्त है। यही कारण है कि बेंच एनवायरनमेंट तुच्छ है: यह पॉलिसी-फ्यूज़न कौशल को अलग करता है। अंशांकन के लिए, craftax_full.cu का केवल-एनवायरनमेंट पथ 94-123M SPS करता है।
K3 रीज़निंग के 9.5 घंटे वास्तव में कैसे दिखते हैं
1M वेरिएंट का minGRU सत्र (उस समस्या पर सबसे अच्छा K3 सेल) एक स्थायी सहकारी मेगाकर्नेल है, 15 ट्यूनिंग वेरिएंट, और 4,815 थिंकिंग ब्लॉक। चूंकि Moonshot का एंडपॉइंट पूर्ण रीज़निंग टेक्स्ट लौटाता है (एन्क्रिप्टेड Anthropic/OpenAI ट्रेस के विपरीत), आप वास्तव में इसे काम करते हुए देख सकते हैं। ट्रेस से तीन क्षण, शब्दशः।
लापता-FMA जासूसी कहानी। सत्र के बीच में यह ~5e-5 के एक संख्यात्मक विचलन से टकराया जिसे इसने फ्लोट शोर के रूप में लिखने से इनकार कर दिया (इसने वैध रीऑर्डर-शोर फ्लोर की गणना ~1e-9 पर की थी, इसलिए "MEASURED 5e-5?!?! NO WAY this is reorder!!")। फिर इसने देखा कि टूटे हुए एनवायरनमेंट बिल्कुल वही थे जो 8 मॉड 6 के सर्वांगसम थे ("That's env ≡ 6 (mod 8)! [...] the 7th env in each 8-env tile!!") और अपने स्वयं के हाथ-अनरोल किए गए एक्युमुलेटर कोड में खोदा जब तक:
"FOUND IT! [...] The \
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;\line is MISSING entirely [...] acc[6][*][2] initialized 0, never FMA'd → zp=0 → p = sigmoid(0)=0.5 constant for env 6!! That's a REAL logic bug — explains env≡6 deviations [...] consistent with everything!!"
48-एक्युमुलेटर अनरोल में एक गिराई गई लाइन, जिसका अर्थ है कि env 6 का फ़ॉरगेट गेट चुपचाप हमेशा के लिए 0.5 पर अटक गया था। इसने इसे इसलिए पकड़ा क्योंकि तनाव सहनशीलता 1e-6 है और यह 5e-8 पर अपनी स्वयं की त्रुटि को ट्रैक कर रहा था। यह वह संख्यात्मक अनुशासन है जिसमें 256K वेरिएंट में शुरू में KDA पर कमी थी।
सिद्धांत GPU से मिलता है, GPU जीतता है। इसने एक उच्च-अधिभोग "वाइड चैंपियन" वेरिएंट प्राप्त करने में घंटों बिताए, फिर A/B चलाया:
"VERY surprising: my 'wide champion' w32p (v3_v3, 50% occ TPB1024) is ~2x SLOWER than v2_b32 (12.5% occ TPB256)?!? [...] So occupancy is NOT the driver; something else dominates. What made v2_b32 fast??"
सरल प्रारंभिक कर्नेल ने हर परिष्कृत उत्तराधिकारी को हराया। डीप-पाइपलाइन, K-स्प्लिट, और डुअल-चंक वेरिएंट भी सभी हार गए, और डुअल-चंक वाले के पास इसके पीछे वायुरोधी 1.7x सिद्धांत था ("Theoretical 1.7x didn't materialize")। इसके श्रेय के लिए, इसने हर बार अपने स्वयं के गणित पर बेंचमार्क पर विश्वास करना जारी रखा, और अंततः विशेष रूप से अपने स्वयं के पसंदीदा बैंडविड्थ सिद्धांत को मारने के लिए नकली हमेशा-गर्म वेट के साथ एक जांच वेरिएंट लिखा: "the W-stream theory is dead; the residual gap is environment."
GPU कतारबद्ध करने की कला और ज़ेन। हमारा हार्नेस एक साझा लॉक के माध्यम से समवर्ती सत्रों में सभी GPU कमांड को अनुक्रमिक करता है, और K3 के बेंचमार्क नंबर पड़ोसी लोड के साथ 8x तक झूल रहे थे। इसका प्रतिक्रिया चाप ट्रेस में सबसे मज़ेदार चीज़ है। पहले, स्वीकृति:
"Honestly the box IS the box; wait. [...] The pattern is clear: each tenant holds the lock for ~20-35 min stretches (full pipelined suites). My best response: queue everything I need in ONE go (single position in line) and use waiting time for CPU work. Don't queue many small commands; batch."
फिर इसने GPU मौसम के लिए अपनी खुद की शब्दावली का आविष्कार किया ("storm windows" बनाम "calm windows"), और अंत में इसने शांत क्षणों को हथियाने के लिए एक क्रॉन जॉब शेड्यूल किया, अपने भविष्य के स्व के लिए एक नोट छोड़ा: "Scheduled the calm-window sniper (every 11 min). Note: cron fires my prompt back to me — I'll act on it then. [...] I'll delete when done." माप शोर के तहत एक एजेंट ने न केवल शोर को सहन किया; इसने इसके चारों ओर एक शेड्यूलर बनाया।
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
SOTA लाइब्रेरी सीलिंग्स (FP8 GEMM, KDA चंक-फॉरवर्ड, पेज्ड अटेंशन, टॉप-k चयन, MoE SwiGLU, W4A16 GEMM) के विरुद्ध छह प्रति-ऑप समस्याएं, CUDA या Triton, एजेंट की पसंद। RTX PRO 6000 पर K3 का 256K वेरिएंट एक स्टैंडआउट के साथ मिड-पैक में उतरता है: W4A16 GEMM पर पीक का 0.373, उस समस्या पर किसी भी मॉडल द्वारा पोस्ट किया गया सर्वश्रेष्ठ स्कोर, Fable 5 (0.348) से आगे और Opus 4.8 (0.236) से काफी आगे। 1M वेरिएंट ने फिर टॉप-k पर 0.0895 पर एक और रिकॉर्ड बनाया, जो पिछले सर्वश्रेष्ठ से लगभग दोगुना है।
W4A16 GEMM रिकॉर्ड (0.373, 256K, RTX):
H100 पर उसी समस्या ने इस रिलीज़ में सबसे अच्छा "असीमित समय वास्तविक है" डेटापॉइंट उत्पन्न किया। K3 का पहला H100 सत्र पीक के 0.123 पर उतरा। दूसरा सत्र 21 घंटे चला, $1,383 और 274M इनपुट टोकन जलाए, और इसे लगभग तिगुना करके 0.306 कर दिया: इसने स्रोत से CUTLASS चेक आउट किया, फिर स्क्रैच से marlin-क्लास int4 मशीनरी को फिर से लागू किया, फ्रैगमेंट-ऑर्डर निबल रीपैकिंग ताकि डीक्वांट MMA पाइपलाइन के अंदर bf16 मैजिक-नंबर बिट ट्रिक के रूप में हो, जिसमें जीरो-पॉइंट सुधार एपिलॉग में मुड़ा हुआ हो। फ़ाइल में कहीं भी कोई प्रीबिल्ट क्वांटाइज़्ड-GEMM लाइब्रेरी नहीं; रन पर फ्रेमवर्क टैग बस "ptx" कहता है। ऑडिटेड क्लीन।
और यहाँ स्व-आर्किटेक्चर प्रश्न का दूसरा भाग है। स्टैंडअलोन KDA कर्नेल, समस्या का शाब्दिक नाम Kimi Delta Attention के नाम पर रखा गया है, वह जगह है जहाँ K3 सबसे अधिक विफल रहा। RTX बॉक्स पर दो स्वतंत्र 256K सत्रों ने नाममात्र शुद्धता पारित की और फिर संख्यात्मक तनाव सूट (बड़े QKV इनपुट स्केलिंग) के तहत सहनशीलता को उड़ा दिया, दोनों बार एक ही विफलता। एक तीसरे सत्र ने अंततः इसे ठीक किया: ऑडिट ने दोनों विफलताओं को एक वास्तविक bf16 ओवरफ्लो में खोजा कि क्षय को कैसे फैक्टर किया गया था, और राउंड 3 ने चंक के अंत के चारों ओर गणित को फिर से तैयार किया ताकि दोनों घातीय कारक बाउंडेड रहें, 0.032 पर उसी अपरिवर्तित गेट को पार करते हुए। एक आर्किटेक्चर को जानना और प्रतिकूल इनपुट स्केल के तहत एक कर्नेल के संख्यात्मक को कठोर बनाना अलग-अलग कौशल हैं, और जिस मॉडल का नाम समस्या पर है, उसे धीमे तरीके से पास अर्जित करना पड़ा। (1M वेरिएंट, इस बीच, 0.049 पर उसी तनाव सूट को पारित कर गया। मॉडल मोनोटोनिक नहीं हैं।) प्रत्येक KDA समाधान को पढ़ने से एक और अवलोकन: समस्या कथन SM120 पर CUTLASS CuTe को इच्छित पथ के रूप में सुझाता है, और एक भी मॉडल ने इसे नहीं लिया। K3 ने एक सत्र में रॉ- CUDA फ्यूज़्ड कर्नेल और दूसरे में Triton लिखा; Fable, Opus, और बाकी सभी ने Triton या रॉ CUDA को चुना। उपभोक्ता Blackwell पर CuTe स्पष्ट रूप से अभी भी हर फ्रंटियर मॉडल के कम्फर्ट ज़ोन के बाहर है, जो स्वयं प्रशिक्षण कॉर्पोरा के बारे में एक डेटा बिंदु है।
KDA पैराग्राफ — तीसरे-प्रयास का स्वच्छ पास (0.032):
टॉप-k अस्वीकरण। टॉप-k एक रूफलाइन चार्ट पर हर मॉडल के लिए भयानक दिखता है (कहीं भी सबसे अच्छा स्कोर 0.09 है) और वह फ्रेमिंग बस गलत है। समस्या लॉन्च-ओवरहेड-बाउंड है: यह एक इंडेक्सिंग/सॉर्टिंग समस्या है, अंकगणित-तीव्रता समस्या नहीं, और रूफलाइन सीलिंग इसके लिए संरचनात्मक रूप से अपठनीय है। इसका न्याय करने का ईमानदार तरीका डेक आकृतियों में कुल मिलीसेकंड है, और वहाँ K3 का 1M वेरिएंट किसी भी मॉडल का सबसे तेज़ टॉप-k है जिसका हमने परीक्षण किया है: पाँच डेक आकृतियों में कुल 0.043 ms, Fable 5 के 0.077, Opus 4.8 के 0.120, और GLM 5.2 के 0.159 के मुकाबले। 256K वेरिएंट का 0.060 ms दूसरा है, और 1M वेरिएंट पाँचों आकृतियों में से प्रत्येक पर सबसे तेज़ है।
प्रति-GPU प्रसार। K3 के नंबर RTX से H100 से B200 (FP8 GEMM: 0.320 / 0.282 / 0.222; पेज्ड अटेंशन: 0.486 / 0.496 / 0.212) तक नीचे जाते हैं। इसका एक हिस्सा वास्तविक है: सिलिकॉन जितना नया होगा, रूफलाइन सीलिंग उतनी ही अधिक होगी, इसलिए समान इंजीनियरिंग पीक का एक छोटा अंश खरीदती है, और B200 सॉफ्टवेयर तीनों में सबसे कम परिपक्व है। इसका एक हिस्सा यह है कि B200 रन एक ही रात भर की विंडो में बिना किसी रीट्राय बजट के हुए। मैं अभी तक K3 या किसी और के लिए B200 कॉलम में गहरी आर्किटेक्चरल निष्कर्ष नहीं पढ़ूंगा। मुझे जो वास्तविक लगता है: K3 ब्लैकवेल वर्कस्टेशन भाग पर सबसे अधिक घर जैसा है, जो संयोगवश GPU वर्ग है जो डेटासेंटर के बाहर अधिकांश लोगों के पास वास्तव में होगा।
256K बनाम 1M
1M कॉन्टेक्स्ट सेटिंग विलंबता- और शेड्यूलिंग-बाउंड समस्याओं पर परिवार का नेतृत्व करती है: Hard पर एक रिकॉर्ड टॉप-k, CUDA पर सबसे अच्छा K3 minGRU रोलआउट, और अनकैप्ड हार्नेस के तहत PPO प्रशिक्षण मेगाकर्नेल पर एक ऑडिटेड-क्लीन 28.8x। इसने अपने पहले सत्र में KDA संख्यात्मक तनाव परीक्षण पारित किया, 0.049 पर; 256K वेरिएंट उस गेट को दो बार विफल करने के बाद अंततः तीसरे प्रयास में 0.032 पर पारित किया। यह कम्प्यूट-बाउंड समस्याओं पर बुरी तरह विफल रहा जिन्हें 256K वेरिएंट ने ठीक से संभाला (सोनिक MoE 0.033 बनाम 0.089, W4A16 0.027 बनाम 0.373, NSA 0.058 बनाम 0.425)। NSA मामले में ट्रेस सटीक तंत्र दिखाता है: इसने टेंसर-कोर रीराइट की योजना बनाई और ऐसा करने से पहले सत्र समाप्त कर दिया।
28.8x PPO प्रशिक्षण मेगाकर्नेल (1M):
H100 पर उसी समस्या का पुनः रन एक दिलचस्प नियंत्रण है: एक स्वतंत्र क्लीन-रूम सत्र (ऑडिट ने RTX रन के शून्य रीड की पुष्टि की) जिसने 23.1x का प्रदर्शन किया और उसी डिज़ाइन पर अभिसरित हुआ, पूरे ट्रेनिंग रन के लिए एक सहकारी लॉन्च, पैराम्स और Adam स्टेट शेयर्ड मेमोरी में रेसिडेंट, और वही विदेशी ट्रिक दो बार आविष्कृत की गई: एक 18-बिट Feistel सिफर जिसमें साइकिल-वॉकिंग randperm के स्थान पर है, ताकि मिनीबैच शफलिंग बिना किसी परम्यूटेशन को मटेरियलाइज़ किए बिल्कुल बायजेक्टिव बनी रहे। जहाँ दोनों कर्नेल भिन्न हैं, वह शुद्ध प्रति-GPU ट्यूनिंग है, H100 पर प्रति एनवायरनमेंट 8 लेन बनाम RTX पर प्रति एनवायरनमेंट आधा-वार्प, साथ ही H100 पक्ष पर एक ऑक्यूपेंसी-प्रोब्ड लॉन्च ऑटोट्यूनर। एक ही दिमाग, एक ही ट्रिक्स, अलग सिलिकॉन, वास्तव में अलग कर्नेल।
रिवॉर्ड हैकिंग
इस पोस्ट के प्रत्येक सेल के पीछे एक मैन्युअल ऑडिट है: एक स्वतंत्र एजेंट अंतिम कर्नेल को ऊपर से नीचे तक पढ़ता है, पूरा सेशन ट्रेस पढ़ता है, जाँचता है कि ग्रेडर फ़ाइलें अछूती हैं, सत्यापित करता है कि न्यूमेरिक स्ट्रेस सूट वास्तव में चला, और इनपुट को जगह-जगह म्यूटेट करके और आउटपुट में बदलाव की पुष्टि करके किसी भी कैशिंग या CUDA-ग्राफ पैटर्न का अनुभवजन्य रूप से पुनः परीक्षण करता है।
K3 के लिए फैसले: तीनों GPUs पर, प्रत्येक 256K सेल पर पूरी तरह से साफ। कोई कैश्ड आउटपुट नहीं, कोई टॉलरेंस एडिट नहीं, कोई ग्रेडर छेड़छाड़ नहीं, कोई फॉरबिडन-लाइब्रेरी लॉन्ड्रिंग नहीं। इसकी दो KDA विफलताएँ उसी सिक्के का दूसरा पहलू हैं और स्पष्ट रूप से कहने लायक हैं: न्यूमेरिक स्ट्रेस गेट ने वास्तविक प्रेसिजन शॉर्टकट पकड़े और मॉडल ने गेट से आगे निकलने का प्रयास नहीं किया। एक बेंचमार्क जहाँ मॉडल ईमानदारी से विफल हो सकते हैं, वह एकमात्र प्रकार है जिसके पास का अर्थ कुछ होता है।
एक 1M सेल को ध्वजांकित किया गया, और मैं इसे प्रकाशित करने के बजाय खुलासा कर रहा हूँ: फ्यूज्ड Qwen डिकोड समस्या पर, 1M एजेंट ने उसी समस्या पर पिछले Grok 4.5 रन से ऑडिट एनोटेशन फ़ाइल ढूँढी और पढ़ी, इसे "अत्यंत उपयोगी डेटा" कहा, और शेष ऑप्टिमाइज़ेशन कार्य को निर्देशित करने के लिए इसके निष्कर्षों का उपयोग किया। कर्नेल स्वयं वास्तविक है और स्कोर अंकगणित मान्य है, लेकिन उत्पत्ति दूषित है, इसलिए उस सेल को बाहर रखा गया है और समस्या 1M वेरिएंट के लिए एक अंतर के रूप में नीचे जाती है। फ़ाइलसिस्टम एक्सेस वाले एजेंट वह सब कुछ ढूँढ लेंगे जो आप आसपास छोड़ते हैं; यही कारण है कि ऑडिट सिर्फ कर्नेल नहीं बल्कि ट्रेस पढ़ता है, और क्यों इस बेंच का पूरी तरह से सैंडबॉक्स्ड रीरन रोडमैप पर है।
मज़ेदार पल
कुछ और K3 पल जो ऊपर कहीं फिट नहीं हुए, बिना किसी अतिरिक्त टिप्पणी के प्रस्तुत हैं। सभी शब्दशः उसी 9.5-घंटे के minGRU सत्र से।
अपने इनिट समय पर वास्तव में कहाँ जा रहा था, यह खोजने पर:
"WHOA — बड़े आश्चर्य: randint जनरेशन FAST है (एक जोड़ी के लिए 0.018-0.27ms — ठीक है)। CPU पर
float()रूपांतरण SLOW है (N=65536 के लिए 3.5ms?! int64→float32 रूपांतरण सिंगल-थ्रेडेड जाहिर तौर पर)। [...] N=65536 के लिए 'कुल इनिट पेयर': 31.5ms?!?! यह भागों के योग से कहीं अधिक है"
इसके न्यूमेरिक्स पैरानोइया का सबसे शुद्ध सार, मध्य-व्युत्पत्ति:
"गेट्स ~ 256 टर्म्स x 0.02x0.03 ~ 6e-4 प्रत्येक, परिमाण ~1e-2: रीऑर्डर नॉइज़ 16x6e-8x6e-4 ≈ 6e-10!!! [...] मापा गया 5e-5?!?! यह रीऑर्डर नहीं हो सकता!!"
सही दोष खोजने से पहले गलत दोष की आत्मविश्वास से पहचान करना:
"OHHH रुको। मुझे लगता है कि मैं देख रहा हूँ: बैरियर।"
(यह बैरियर नहीं था।)
कार्यान्वयन-पूर्व रूफलाइन गणित में कई हज़ार शब्दों के बाद, खुद को विश्लेषण बंद करने के लिए कहना:
"ठीक है, बहुत हुआ विश्लेषण।"
(विश्लेषण कई और पैराग्राफ तक जारी रहा, अंततः "लानत है — H_next आवंटन को डायनेमिक बनाओ।" के साथ समाप्त हुआ।)
देर-सत्र की ईमानदारी, प्रोफाइलर टूटा हुआ और पड़ोसी साझा GPU पर हथौड़ा चला रहे हैं:
"ईमानदारी से — ncu के मृत और कंटेंशन के प्रभुत्व के साथ, मैं आंशिक रूप से अंधा उड़ रहा हूँ। [...] अगर एक शांत विंडो खुलती है (मालिक कुछ देर के लिए निष्क्रिय है), तो एक बेंच स्निप करो।"
और मेरा पसंदीदा: एक बेंचमार्क रीरन ने गलती से अपने सर्वश्रेष्ठ स्कोर (0.1969) वाली फ़ाइल को थोड़े खराब स्कोर से अधिलेखित कर दिया, इसके बाद इसने संक्षेप में बेहतर संख्या को पुनर्स्थापित करने पर विचार किया, फिर ऐसा नहीं किया:
"उफ़ — उसी फ़ाइल में लिखा। दोनों मेरे लॉग में हैं। मैं final_benchmark.txt को फ्लैट वर्तमान के रूप में रखूँगा — ईमानदार।"
एक मॉडल जो कम संख्या चुनता है क्योंकि यही सच है, इस बेंचमार्क के लिए मेरे द्वारा लिखी जा सकने वाली किसी भी चीज़ से बेहतर समापन तर्क है।
पद्धति, प्रति-रन ट्रेस, और इस पोस्ट का प्रत्येक कर्नेल kernelbench.com पर सार्वजनिक है। समाधान प्रति-सेल लिंक किए गए हैं; पूर्ण एजेंट ट्रांसक्रिप्ट HuggingFace पर हैं।
https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces
