Fp8 kernel नाम में "cutlass" डालने पर लगभग 100TFLOPS की रफ्तार बढ़ जाती है

 (github.com/triton-lang)
1 पॉइंट द्वारा GN⁺ 2025-10-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Attention kernel को persistent रूप में रिफैक्टर करके कम context length पर प्रदर्शन बेहतर किया गया
  • fp16 में बड़े context पर softmax partition के ptxas instruction scheduling issue के कारण प्रदर्शन घटता है
  • fp8 में kernel नाम में "cutlass" शामिल होने पर लगभग 100TFLOPS प्रदर्शन वृद्धि देखी गई
  • इस optimization का विश्लेषण kernel naming के जरिए hardcoded optimization trick के रूप में किया गया
  • प्रदर्शन पर असर और इसके काम करने का कारण NVIDIA ptxas की internal implementation से जुड़ी एक असामान्य घटना है

सारांश: Persistent Attention kernel का रिफैक्टरिंग और "cutlass" naming effect

अवलोकन

  • यह Pull Request Triton के attention kernel को persistent attention तरीके से रिफैक्टर करने के बारे में है
  • मुख्य उद्देश्य कम context length वाले हिस्सों में performance optimization हासिल करना है
  • लेकिन fp16 प्रकार में context आकार बढ़ने पर softmax हिस्से में ptxas instruction scheduling issue की वजह से प्रदर्शन में गिरावट दिखाई देती है

fp8 में "cutlass" नाम अपनाने का प्रभाव

  • fp8 मॉडल इस्तेमाल करने पर kernel नाम में "cutlass" शामिल करने से लगभग 100TFLOPS तक प्रदर्शन वृद्धि मापी गई
  • इसका कारण यह है कि NVIDIA का ptxas (PTX assembler) आंतरिक रूप से kernel नाम में "cutlass" होने पर विशेष optimization लागू करता है
  • वास्तविक कोड में dtype यदि float8e5 हो तो kernel नाम को "cutlass_gluon_attention" आदि के रूप में सेट किया जाता है
  • ptxas disassembly analysis के नतीजे में वास्तव में internal code में strstr(kernel_name, "cutlass") शर्त मौजूद पाई गई

प्रदर्शन benchmark

  • रिफैक्टरिंग से पहले और बाद के benchmark data में persistent attention लागू करने से पहले की तुलना में D=64 पर सापेक्ष प्रदर्शन गिरावट देखी गई
    • इसका कारण softmax हिस्से की instruction scheduling समस्या है
  • लेकिन fp8 type और "cutlass" naming के संयोजन में कुछ context और आकारों पर काफी अधिक throughput दर्ज किया गया
  • प्रतिनिधि परिणामों का सार:
    • Attention Z=4, H=32, D=64, causal=False:
      • persistent लागू करने से पहले: triton-fp16 लगभग 383, triton-fp8 लगभग 413, cudnn-fp16 लगभग 565
      • persistent लागू करने के बाद: triton-fp16 लगभग 360, triton-fp8 लगभग 370
    • Attention Z=4, H=32, D=128, causal=True:
      • persistent लागू करने से पहले: triton-fp16 लगभग 312, triton-fp8 लगभग 345, cudnn-fp16 लगभग 553
      • persistent लागू करने के बाद: triton-fp16 लगभग 356, triton-fp8 लगभग 351

naming trick की खोज और विश्लेषण

  • यदि kernel नाम में "cutlass" स्ट्रिंग शामिल हो, तो NVIDIA ptxas में experimental optimization routine सक्रिय हो जाता है, यह बात community analysis में सामने आई
  • ptxas में naming match के लिए hardcoded logic (strstr(kernel_name, "cutlass")) मौजूद है
  • यह trick aggressive, experimental optimization है, और kernel की accuracy में बदलाव होगा या नहीं, यह hardware और स्थिति के अनुसार अलग हो सकता है

community discussion

  • कई reviewers ने performance comparison, accuracy और optimization method पर सवाल और विश्लेषण किए
  • Deepseek technical report की सामग्री, Hopper GPU जैसे विशिष्ट architecture पर अंतर आदि पर भी चर्चा हुई
  • naming change के जरिए optimization कितना व्यापक रूप से लागू होता है और stability issue क्या हैं, यह भी उठाया गया

निष्कर्ष और संकेत

  • सिर्फ kernel के नाम से भी hardware स्तर पर वास्तविक performance बदलाव होना एक बेहद असामान्य घटना है
  • NVIDIA software stack (ptxas) में छिपे optimization trigger होने से यह संकेत मिलता है कि AI framework development में naming convention भी performance को प्रभावित कर सकता है
  • व्यवहारिक रूप से इस trick का उपयोग करते समय reproducibility और stability की जांच जरूर करनी चाहिए, और hardware vendor की optimization policy पर करीबी नजर रखने की जरूरत है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-04
Hacker News राय

  • ptxas को disassemble करने पर पता चला कि "cutlass" नाम वाले kernel को पहचानने वाली logic hardcoded है
    लगता है NVIDIA ने यहां अस्थिर, प्रयोगात्मक और आक्रामक optimization लागू किया है; संभव है कि इस optimization को हर बार जबरन चालू करने पर पेचीदा bugs आ जाएं

    • असल में पेचीदा bugs से ज़्यादा सूक्ष्म performance बदलाव दिखते हैं
      GPU compiler बहुत कठिन होते हैं, और basic optimization से आगे बढ़ते ही अक्सर समस्याओं के साथ मिले-जुले नतीजे आते हैं
      कुछ kernels तेज़ हो जाते हैं, कुछ धीमे, और कुल मिलाकर performance बढ़े यह सुनिश्चित करना बहुत मुश्किल होता है
      पूरी test suite में किसी एक optimization से हमेशा speed बढ़े, ऐसा लगभग कभी नहीं होता
      मेरा अनुभव Nvidia नहीं बल्कि दूसरे GPU systems के साथ है, लेकिन यह स्थिति जानी-पहचानी लगती है
      लगता है Nvidia ने भी ऐसे optimizations पाए होंगे जो कुछ kernel sets पर शानदार नतीजे देते हैं और कुछ पर बहुत खराब, और उनके पास इसे अपने-आप लागू करने का कोई भरोसेमंद मानदंड नहीं रहा होगा

  • यह संदर्भ समझाने के लिए धन्यवाद
    मैं इस क्षेत्र से नहीं हूं (और इस project का नाम भी पहली बार सुना), इसलिए title और PR पढ़कर भी समझ नहीं आ रहा था

  • 25 साल पहले ATI(AMD) का वह मामला याद आ गया जब Quake III benchmark में executable का नाम quack करने पर performance बदल गई थी और cheating पकड़ में आई थी
    संबंधित links: techreport.com review, hardocp.com review, 3dcenter.de article

    • जो लोग मेरी तरह भ्रमित हुए हों, उनके लिए साफ कर दूं
      ATI quake नाम वाले executable को पहचानकर texture quality वगैरह बदल देता था ताकि benchmark score बढ़ जाए
      लोगों ने executable का नाम quack कर दिया, तो image quality बढ़ गई और score गिर गया; इससे पता चला कि ATI driver जानबूझकर quality घटाकर speed बढ़ा रहा था
      यानी file name ATI ने नहीं बदला था, users ने बदला था

    • या फिर Intel C++ Compiler का वह issue, जिसमें output में मौजूद "GenuineIntel" string चेक की जाती थी
      संबंधित wiki link यहां है

    • आज भी सभी vendors ऐसा करते हैं
      drivers लोकप्रिय games के rendering loop को intercept करके bugs ठीक करते हैं, shaders को ज़्यादा optimized versions से बदलते हैं, या fast code paths खोलते हैं
      आदर्श रूप से इन बदलावों का output पर बहुत कम असर होना चाहिए, लेकिन कुछ मामलों में दखल इतना आक्रामक होता है कि quality काफ़ी गिर जाती है
      यानी वे अपने hardware पर game को तेज़ चलाने के लिए छेड़छाड़ करते हैं

    • इस विषय पर और गहरी चर्चा वाला thread है, यहां देखना सुझाऊंगा
      दिलचस्प बात यह है कि वह भी इसी cutlass optimization पर पुरानी पोस्ट है

    • ऐसे मामले बहुत आम हैं
      मोबाइल chipset makers benchmark के लिए cheats करते रहे हैं (VW emissions, Nvidia 3DMark benchmark, Intel Xeon के लिए SPEC benchmark आदि),
      और computer graphics में अब लगभग परंपरा-सी है कि drivers हर game के लिए tweaks, settings, workarounds वगैरह डालते हैं
      (दुर्भाग्य से आजकल अच्छे source links बहुत जल्दी गायब हो जाते हैं, इसलिए archive.org का सहारा लेना पड़ता है। मुझे लगता है ऐसी यादें बचाकर रखनी चाहिए।)
      संदर्भ links: Mediatek benchmark cheating, Volkswagen emissions scandal, Nvidia 3DMark controversy, Intel compiler SPEC benchmark impact

  • compiler के साथ काम करने के नज़रिए से देखें तो, इस तरह के optimizations कभी-कभी names (schema, substring आदि) पर निर्भर करते हैं
    पसंद न आए, फिर भी व्यवहार में चीज़ें ऐसे ही चलती हैं
    यह ज़रूरी नहीं कि दुर्भावनापूर्ण हो; optimization सिर्फ अपनी library पर लागू हो, यह पूरे सिस्टम को तोड़ने के जोखिम से ज़्यादा सुरक्षित विकल्प हो सकता है
    या फिर frontend ज़्यादा भरोसेमंद जानकारी (जैसे structural information) दे ही नहीं पाता

    • शायद यह malicious नहीं है, लेकिन optimization का यह तरीका आख़िरकार एक नई रुकावट पैदा करता है
    • function type या schema पर निर्भरता कुछ हद तक समझ आती है, लेकिन अगर सिर्फ नाम के आधार पर लागू हो तो अजीब लगता है
    • भले ही इसे “टूट-फूट रोकने” के लिए किया गया हो, अगर कोई संयोग से वही नाम इस्तेमाल कर ले तो अनपेक्षित समस्याएं आ सकती हैं
      मुझे नहीं लगता यह तरीका मददगार है

  • मुझे इसमें कुछ खास नया नहीं लगता

    • 2024 की शुरुआत में SPEC ने Intel Xeon CPU के 2,600 benchmark results अमान्य कर दिए थे, क्योंकि Intel compiler ने अनुचित optimizations का इस्तेमाल करके score बढ़ाया था (Tom's Hardware article)
    • Microsoft भी Java/C compiler benchmark metrics में ऐसा कुछ करता रहा है
    • और अब सब लोग AI benchmark cheating में लगे हैं (AI benchmarking scandal)

  • लगभग 10 साल पहले Webpack के एक खास version में add.svg नाम की file होने पर build टूट जाता था, यह बात याद आ गई
    आखिरकार file का नाम plus.svg करके समस्या हल की थी

    • numpy में भी कुछ ऐसा ही
      "secret.py" नाम की file रख देने से अनजाने में numpy को तोड़ देने का अनुभव कुछ लोगों को हुआ है

  • commit message की ईमानदारी प्रभावशाली लगी

    • किसी ने commit diff की बनावट को लेकर आलोचना की थी
      कोई अगर लिखता है कि “किसी चीज़ को लगभग 100 tflops तेज़ कर दिया”, और जवाब में लोग कहते हैं “commit message अच्छा नहीं है”... तो फिर शायद उन्हें John Carmack की commit style भी पसंद नहीं आएगी

    • मुझे व्यक्तिगत रूप से ऐसे ईमानदार messages पसंद हैं
      AI से अपने-आप बने "refactored X" जैसे दोहरावदार commit messages की भरमार से यह कहीं बेहतर लगता है

    • मुझे लगता है commits को squash करके history समेटनी चाहिए
      समझ नहीं आता GitHub पर डालते समय squash क्यों नहीं किया गया

  • NVIDIA Jetson पर काम सीखते समय की बात याद आ गई
    पता चला था कि बस एक command चलाओ और सब कुछ तेज़ हो जाता है (related link)

    • क्या आप power mode की बात कर रहे हैं?
      article के मुताबिक 5W और 10W दो modes हैं, और 10W default है, इसलिए ऐसा भी समझा जा सकता है कि “तेज़” वाला असर तो default से 5W पर बदलने पर ही लागू होगा। शायद मैं कुछ गलत समझ रहा हूं?

  • कभी-कभी heavily tuned code high-level language (जैसे C++) में लिखा होता है, और GPU assembly के स्तर पर भी बहुत specific result चाहिए होता है, लेकिन compiler मनचाहा output नहीं देता
    अगर आप vendor की team से बात करें तो वे कई solutions देंगे, लेकिन open source code में उनमें से बहुत-सी चीज़ें अपनाना मुश्किल होता है (जैसे proprietary #pragma, intrinsics आदि)
    high-performance library बनाने वालों के लिए अगर performance न निकले तो ship करना ही संभव नहीं होता
    ऐसे में function names जैसी चीज़ों से specific code transformations trigger कराने की trick इस्तेमाल करनी पड़ती है
    इस तरह का optimization वास्तविक दुनिया में आम है, और इसे benchmark score बढ़ाने के लिए image quality घटाने जैसी हरकत के बराबर नहीं मानना चाहिए

    • ऐसे मामलों में inline assembly क्यों नहीं इस्तेमाल करते, यह सवाल भी उठा

  • यह PR पहली बार आया था तब भी इस पर चर्चा हो चुकी थी
    मुझे इसमें कुछ नया नहीं लगता
    पिछली चर्चा

    • यह जाना-पहचाना लगा, जैसे पहले भी देख चुका हूं

  • काश code साझा करना आसान बनाने वाली कोई आर्थिक संरचना होती
    binary blob drivers, baseband और ऐसी जटिल व्यवस्थाओं के बजाय, सबको जानकारी आसानी से मिलती और समय व मेहनत की यह बर्बादी कम होती
    अनगिनत बेहतरीन engineers और researchers महीनों-बरसों उस documentation, schematics और binary code को reverse engineer और decode करने में लगा देते हैं जो पहले से किसी और के पास होता है
    CUDA और NVIDIA जैसी कंपनियां इस मामले में निराशाजनक लगती हैं

    • समस्या का मूल software codebase विकसित करने की शुरुआती fixed cost, उसके बाद maintenance labor cost, और distribution की छोटी-सी cost (जैसे download servers) है
      desktop apps के मामले में प्रति user अतिरिक्त cost लगभग 0 के बराबर होती है
      इसलिए software को लगातार recurring income model चाहिए, लेकिन income user count के अनुपात में लगातार बढ़ती नहीं रहनी चाहिए
      जिन लोगों ने नए code development में निवेश किया, उन्हें product लोकप्रिय होने पर अपनी investment वसूल करनी चाहिए, लेकिन मौजूदा crowdfunding models इस संरचना को पूरा नहीं करते
      users बढ़ने पर प्रति user contribution बहुत कम हो जाती है; और फिर भी अगर हर कोई 100%, या 10%, या 1% ही contribute करे, तो कुल investment astronomical हो सकती है
      इसलिए मुझे लगता है कि auction-style pledge system की ज़रूरत है
      इस मॉडल में भी समस्याएं हैं; खासकर exclusive और non-exclusive modes के बीच transition बहुत पेचीदा है
      अगर कुछ बड़ी कंपनियां पूरी development cost देकर चीज़ को open source कर दें, तो बाकी सभी individuals और companies असल में free riders बन जाते हैं