Show HN: LLM inference की speed 2x बढ़ाने की संभावना (Speeding up LLM inference 2x times (possibly))

 (asciinema.org)
1 पॉइंट द्वारा GN⁺ 2024-04-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Effort क्या है?

  • Effort से मतलब है किसी काम को पूरा करने या लक्ष्य हासिल करने के लिए लगाई जाने वाली ऊर्जा, समय और संसाधन
  • यह बाधाओं को पार करने या इच्छित परिणाम पाने के लिए ज़रूरी मेहनत और परिश्रम को दर्शाता है
  • Effort physical भी हो सकता है और mental भी
    • जैसे भारी सामान उठाने या marathon दौड़ने में लगने वाला physical effort
    • या जटिल समस्याएँ हल करने या नई skills सीखने के लिए ज़रूरी एकाग्रता और मानसिक शक्ति जैसा mental effort
  • यह व्यक्तिगत विकास, कार्यस्थल, शिक्षा और जीवन के कई क्षेत्रों में सफलता के लिए एक मुख्य तत्व है

GN⁺ की राय

  • Effort सिर्फ लगाए गए समय या ऊर्जा की मात्रा भर नहीं है, बल्कि इसमें निरंतरता, एकाग्रता और motivation जैसे कई तत्व मिलकर काम करते हैं। इसलिए सिर्फ कड़ी मेहनत करने से सफलता की गारंटी नहीं होती
  • खासकर mental effort वाले कामों में burnout से बचने का ध्यान रखना चाहिए। उचित आराम और rewards के ज़रिए effort को बनाए रखने के तरीके ढूँढना महत्वपूर्ण है
  • हर व्यक्ति का effort लगाने का तरीका अलग हो सकता है। कोई कम समय में बहुत focused effort लगा सकता है, तो कोई लंबे समय तक लगातार effort करता है। अपने लिए सही तरीका ढूँढना सबसे प्रभावी है

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

1 टिप्पणियां

 
GN⁺ 2024-04-19
Hacker News की रायें

  • एल्गोरिदम का मूल विचार ऐसा लगता है कि execution के दौरान parameters को prune किया जाए, और हर group के भीतर prune किए जाने वाले weights की absolute value ranking से कम महत्वपूर्ण weights तय करके उन्हें 0 बना दिया जाए, ताकि weight matrix sparse हो जाए
    model pruning खोजने पर बहुत सारे नतीजे आते हैं, और https://arxiv.org/abs/2305.11627 भी “magnitude-based pruning” को baseline के रूप में लेता है और https://arxiv.org/pdf/2301.00774.pdf को cite करता है
    papers का baseline को ढीले-ढाले तरीके से implement करके अपनी method का गुणगान करना, या बहुत सारे mathematical terms लगाकर उसे package करना, अच्छा नहीं लगता। original blog post इस method को ऐसे लोगों तक भी कहीं ज़्यादा आसानी से पहुँचाता है जिनके पास background knowledge बहुत कम है

    • पिछला एक महीना research को जितना हो सके reproducible और reliable बनाने में लगाया। original implementation बहुत inefficient था, और Metal/GPU matrix multiplication operations तेज़ होने के बाद भी benchmark करना आसान रहे, इसके लिए बाकी implementation को जितना हो सके Llama.cpp के करीब मिलाने में काफी समय लगाया
      जिन papers का ज़िक्र किया गया, उनके approaches static लगते हैं, और उन्होंने 20–50% results के साथ actual computation को तेज़ करने वाला algorithm पेश नहीं किया लगता। मुश्किल हिस्से का बड़ा भाग वही था। कभी समय निकालकर related literature को ठीक से देखने का इरादा है
      आखिरकार, लोगों ने comments में जो papers डाले हैं, उनके साथ एक citation page जोड़ना चाहता हूँ। मुझे लगता है कि जल्द ही कोई न कोई इस algorithm को पहले से व्यवस्थित करके लिखी गई कोई पोस्ट ढूँढ निकालेगा
      development के दौरान gpt-4 से भी पूछा और Google भी किया, लेकिन जो मिला वह ज़्यादातर static था या पूरे dimensions/layers को मनमाने ढंग से हटाकर फिर से train करने वाला था। इस idea से बिल्कुल match करने वाली चीज़ नहीं मिली
    • “बहुत सारे mathematical terms लगाकर अपनी method को package करना और baseline को poorly implement करना” खराब paper का संकेत लगता है
      लेख जितना घना और समझने में मुश्किल होगा, उतनी ही संभावना है कि उसके अंदर खराब science छिपी हो

  • GPU implementation वाले हिस्से की यह लाइन अच्छी लगी
    “जो पाठक GPU programming में नए हैं, वे अब पूछ सकते हैं — यह काम कैसे करता है?
    जिन पाठकों को GPU programming का अनुभव है, वे पूछ सकते हैं — आखिर यह काम कैसे करता है?”

    • मेरी समझ के हिसाब से memory reads और कुछ और चीज़ों को आम तौर पर सही approach माने जाने वाले तरीके के उलट implement करना पड़ा
      अगर Metal को सच में अच्छी तरह जानने वाला कोई व्यक्ति इस code को review कर दे तो अच्छा होगा। यह मेरी GPU programming की पहली कोशिश थी

  • “matrix को पलटो, elements को row-wise sort करो, और multiplication को उस दिशा से फिर से देखो। समझदार लोग इसे Compressed Sparse Row (CSR) format कहते हैं। अब multiplication करने के लिए vector का 1 लो, 256 से multiply करो, और output vector की तीसरी row में add करो, इस तरह आगे बढ़ो। अब देखते हैं कि सबसे कम values वाली last column को काट देने पर क्या होता है।”
    मुझे जानना है कि CSR multiplication की संख्या घटाने के तरीके से यह कैसे जुड़ता है

    • क्या सवाल को फिर से phrasing कर सकते हैं? मैं ठीक से समझ नहीं पाया

  • यह तरीका semi-structured sparsity, यानी तथाकथित 2:4 sparsity जैसा लगता है, इसलिए explicit comparison किया जा सकता है। सरसरी तौर पर देखने पर यह technique Apple Silicon के लिए optimized है, 75% sparsity पर करीब 2x speed, input के आधार पर runtime पर लागू होने वाली dynamic method, और sparsity level चुना जा सकता है
    वहीं 2:4 semi-structured sparsity sparse tensor cores वाले GPU, यानी Nvidia Ampere और उसके बाद के लिए optimized है, 50% sparsity पर करीब 2x speed, model के stored state में लागू होने वाली static method है, और 50% sparsity पर इसके results इस technique से खराब होने की संभावना है
    जो comparison देखना चाहूँगा वह है semi-structured sparsity के 50% sparsity·2x speedup results बनाम इस technique के 75% sparsity·2x speedup results

    • check करने के लिए धन्यवाद। मैं भी उम्मीद कर रहा हूँ कि और tests जल्दी आएँ
      Apple Silicon इसलिए चुना क्योंकि उस पर develop करना आसान था। यह algorithm दूसरे architectures पर भी अच्छा performance दे सकता है

  • CSR इस्तेमाल कर चुके व्यक्ति के तौर पर यह हैरान करने वाला नहीं है। नए formats में block ELL जैसे कुछ हो सकते हैं जो hardware characteristics से बेहतर match करते हों
    ऐसे formats uncoalesced reads या gather से बचते हैं, लेकिन code ज़्यादा tricky हो जाता है

    • आखिर CSR experience वाले किसी व्यक्ति से मिलकर अच्छा लगा
      bucketMul में uncoalesced reads लगभग नहीं हैं और यह सामान्य CSR से अलग data structure इस्तेमाल करता है। यहाँ समझाया गया है: https://kolinko.github.io/effort/bucketmul.html
      हर matrix row को 16 parts में बाँटता है, और चुनता है कि कौन-सा part पढ़ना है। writes पूरी तरह linear हैं
      हालांकि अभी पक्का नहीं कि मैं समझदारी की बात कर रहा हूँ या नहीं। आज थोड़ी देर हो गई है और दिन लंबा था

  • अच्छा आइडिया और अच्छी पोस्ट। मैं भी neural network inference में sparsity के क्षेत्र पर काम कर रहा हूं, और कुछ बातें ध्यान में रखने लायक लगती हैं।
    dense matrix-vector multiplication implementation की तुलना में यह algorithm complexity बढ़ाता है, लेकिन memory traffic घटाता है। matrix-vector multiplication आम तौर पर memory-bottlenecked होता है, इसलिए memory access कम करने से throughput बढ़ता है। हालांकि batch size 1 से बड़ा होते ही memory access bottleneck नहीं रह जाता, इसलिए speedup बहुत जल्दी गायब हो जाने की संभावना है।
    तुलना के लिए मैं सिर्फ उसी model को नहीं, बल्कि 2x faster architecture वाले किसी दूसरे model को भी देखना चाहूंगा। उदाहरण के लिए 13B parameter LLM पर इस method को 50% sparsity के साथ लगाने पर 7B parameter LLM से तुलना में कैसा है, और baseline bit width के आधे पर quantize किए गए उसी LLM से तुलना में कैसा है—यह जानना दिलचस्प होगा। अगर समान समय में मौजूदा inference framework की तुलना में higher-fidelity output दिखा सके, तो यह एक दिलचस्प paper बन सकता है।
    multiplication skip करने से approximation error के real result की तुलना में हमेशा absolute value में छोटा होने की तरफ झुकने की संभावना अधिक है। अगर उस systematic error को correct करने वाला कोई correction term जोड़ा जा सके, तो performance थोड़ी और बेहतर हो सकती है।

    • algorithmic complexity असल में बढ़ती नहीं है। multiplication O(effrt * inDim * outDim) है, dispatch calculation O(inDim) है, और cutoff point ढूंढना O(~inDim * log inDim) है।
      Big-O notation GPU workloads के लिए बहुत उपयुक्त नहीं है, लेकिन इस case में मोटे तौर पर सही है।
      मुख्य समस्या GPU की architectural limits हैं। इस algorithm को traditional method की तुलना में registers/threadgroup/cache memory ज्यादा चाहिए, और वही main bottleneck बनता है। साथ ही, सभी multiplications अलग-अलग buckets इस्तेमाल करती हैं, इसलिए MoE models की तरह काम को parallelize करना straightforward नहीं है।
      बड़े architectures के लिए, मैंने effectively 13B model Mixtral पर काफी testing की, और मेरी भावना है कि वहां यह कहीं बेहतर टिकता है। effort के मुकाबले inference speed भी बनी रहती है, और effort के मुकाबले quality 20–25% नहीं बल्कि 12–16% तक readable results बनाए रखती है। testing limited थी, और Mistral implementation जोड़ते समय मैंने Mixtral implementation खराब कर दिया, इसलिए पक्का data नहीं है, लेकिन जल्द ही उसे fix करने वाला हूं।
      intuition के हिसाब से, model जितना बड़ा होगा, effort को उतना ज्यादा कम किया जा सकेगा।
      multiplication skip करने से bias पैदा होगा—शुरुआत में मेरा भी यही अनुमान था, लेकिन intuition के उलट ऐसा नहीं हुआ। कुछ charts हैं, लेकिन वे अभी public release के लिए तैयार नहीं हैं।
      matrix की values positive और negative में समान रूप से distributed हैं, इसलिए किसी threshold के बाद result values में drift ज्यादा नहीं होता।

  • शानदार लग रहा है। हालांकि 15ms latency 60Hz vertical sync के 16.7ms के करीब है।
    अगर आप हर token पर screen refresh कर रहे हैं, तो कहीं synchronization लगने की वजह हो सकती है।

    • ऐसा नहीं है। CPU और GPU work अलग-अलग measure किए जा रहे हैं, और 15ms kernel calls के बीच होता है। text output न करने पर भी होता है।
      फिर भी idea के लिए धन्यवाद। इसे अपनी पहली community contribution मानूंगा :D

  • सच में कमाल का और open contribution है। मैं ध्यान से देखूंगा कि llama.cpp इसे implement करता है या नहीं।
    मैं CPU inference को तेज करने का तरीका ढूंढ रहा था, और effort वाला idea मुझे सच में पसंद आया।

    • इसे develop करना marathon जैसा था, और main page पर आकर खुशी हुई।
      नाम chatgpt ने suggest किया था। जब उसने कहा कि वह इस approach को पहचान नहीं पा रहा, तो यह सच में नया भी हो सकता है।
      मैं llama.cpp और दूसरे projects से संपर्क करना चाहूंगा, और अच्छा होगा अगर यह implement हो जाए। मैंने खुद llama के लिए patch लिखने के बारे में भी सोचा था, लेकिन C++ और उस project का scale मेरे लिए भारी पड़ गया।
      CPU inference भी इसी तरह तेज होगा। इसके अलावा, सिर्फ कुछ weights—जैसे कम important ones को skip करके 70%—load किए जा सकते हैं, इसलिए पहले से कम VRAM में model चलाया जा सकेगा। हालांकि Q8 implementation अभी भी चाहिए।
      मजेदार बात यह है कि जब मैंने llama.cpp से benchmark compare करने की कोशिश की, तो MB Air 16GB पर 7B/FP16 speed नहीं मिली। वजह यह है कि normal तरीके से इसे run करना possible नहीं है। Effort के साथ possible है।
      इसी तरह 96GB M2 पर full resolution लेकिन cut-down Mixtral चलाया। आम तौर पर RAM 114GB चाहिए होती है, लेकिन सिर्फ 75% weights load करने पर यह smoothly चला। अभी मैंने implementation थोड़ा खराब कर दिया है और यह garbage output दे रहा है, इसलिए fix की जरूरत है।

  • अच्छी पोस्ट। simple quantization की तुलना में performance per VRAM कैसा है, यह सच में जानना चाहूंगा।
    यह भी जानना चाहूंगा कि cross-platform version implement करने की कोई plan है या नहीं।

    • performance per VRAM बहुत बेहतर नहीं है। क्योंकि structure अभी भी सभी weights का इस्तेमाल करता है, बस हमेशा सभी को use नहीं करता।
      बेशक weights कम load किए जा सकते हैं, लेकिन weights को 20–30% से ज्यादा घटाने पर quality जल्दी खराब होती दिखती है।
      दूसरे शब्दों में, यह algorithm inference time को VRAM usage से अलग कर देता है।
      फिर भी, मुझे भी curiosity है कि effort के साथ 75% cut-down Q8, Q6 से बेहतर results दे सकता है या नहीं।
      हालांकि implementation को पर्याप्त polish करके ठीक से test करने में अभी कुछ हफ्ते और लगेंगे।

  • यह method retraining नहीं करता, लेकिन सोच रहा हूं कि क्या इस approach को quantization के साथ use करके और बाद में additional training करने से lost quality का कुछ हिस्सा वापस पाया जा सकता है।
    ऐसी चीजें देखना अच्छा लगता है, और आगे performance और cost कितनी improve हो सकती है, इसकी mental picture बनाना भी अच्छा है। open source में develop करने के लिए धन्यवाद।

    • पहली नजर में तो possible लगता है। मैंने जो पढ़ा है, उसके हिसाब से quantization में quality का कुछ हिस्सा वापस पाने के दो main तरीके हैं।
      एक है बाद में किया जाने वाला post-training, और दूसरा है training के दौरान quantize करना, लेकिन activations और gradients को full precision में रखना—quantization-aware training।