ऊर्जा-कुशल language model के लिए सिर्फ addition ही काफी है

 (arxiv.org)
2 पॉइंट द्वारा GN⁺ 2024-10-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • L-Mul एक linear-complexity multiplication algorithm है, जो इस बात पर ध्यान देता है कि LLM की बड़ी ऊर्जा लागत floating-point multiplication से आती है, और multiplication को integer addition से approximate करने की कोशिश करता है
  • fp32 multiplication की ऊर्जा लागत int32 addition से 37 गुना अधिक है, इसलिए tensor processing hardware पर L-Mul लागू करने से element-wise floating-point tensor multiplication ऊर्जा का 95% और dot product ऊर्जा का 80% तक घटाने की क्षमता हो सकती है
  • इसकी गणना-पद्धति mantissa multiplication और rounding को हटाती है, sign को XOR से संभालती है, और बाकी bits को x[1:] + y[1:] - offset रूप के addition से बनाती है
  • प्रयोगों में 4-bit mantissa L-Mul ने float8 e4m3 multiplication जैसी precision दिखाई, और 3-bit mantissa L-Mul ने float8 e5m2 से बेहतर परिणाम दिए
  • जब pre-trained LLM पर बिना अतिरिक्त training के L-Mul attention लागू किया गया, तो natural language inference कार्यों में औसत loss 0.07% था, और vision कार्यों में औसत accuracy 0.12% बढ़ी

L-Mul जिस bottleneck को निशाना बनाता है

  • बड़े neural network अपनी गणना का बड़ा हिस्सा floating-point tensor multiplication पर खर्च करते हैं, और यह operation addition की तुलना में अधिक ऊर्जा लेता है
  • L-Mul एक linear-complexity multiplication algorithm है, जो floating-point संख्याओं के multiplication को integer addition से approximate करता है
  • इसका उपयोग कई गणना चरणों में किया जा सकता है
    • attention mechanism के भीतर multiplication
    • matrix multiplication
    • element-wise multiplication
  • Transformer-आधारित LLM में attention, input context length N के लिए O(N²) complexity रखता है, और high-dimensional tensor multiplication के साथ मिलकर यह computational efficiency का बड़ा bottleneck बनता है

arithmetic operations के अनुसार ऊर्जा लागत

  • Horowitz(2014) की operation-cost तालिका addition और multiplication के बीच ऊर्जा अंतर को सीधे दिखाती है
    • int8 addition: 0.03 pJ
    • int32 addition: 0.1 pJ
    • fp16 addition: 0.4 pJ
    • fp32 addition: 0.9 pJ
    • int8 multiplication: 0.2 pJ
    • int32 multiplication: 3.1 pJ
    • fp16 multiplication: 1.1 pJ
    • fp32 multiplication: 3.7 pJ
  • fp32 multiplication, fp32 addition से 4 गुना और int32 addition से 37 गुना अधिक ऊर्जा उपयोग करता है
  • PyTorch में tensor multiplication परिणामों के accumulation की default precision fp32 पर सेट होती है
  • I/O और control operations को छोड़ दें, तो fp32 multiplication को int32 addition से approximate करने पर ऊर्जा उपयोग लगभग 1/37 ≈ 2.7% रह जाता है
  • accumulation precision को fp16 तक घटाने पर भी integer addition, floating-point multiplication ऊर्जा का केवल लगभग 4.7% उपयोग करता है

L-Mul की गणना-पद्धति

  • सामान्य floating-point multiplication, दो संख्याओं x, y के लिए इस रूप में होती है
    • (1 + xm) · 2^xe · (1 + ym) · 2^ye
    • परिणाम (1 + xm + ym + xm · ym) · 2^(xe+ye) और sign XOR से बनता है
  • गणना का bottleneck m-bit mantissa के लिए O(m²) mantissa multiplication है
  • L-Mul, xm · ym को हटाकर इसे इस रूप में approximate करता है
    • (1 + xm + ym + 2^-l(m)) · 2^(xe+ye)
  • l(m) mantissa bit count के अनुसार बदलता है
    • m ≤ 3 हो तो m
    • m = 4 हो तो अलग मान
    • m > 4 हो तो अलग मान
  • bit-level implementation को और सरल सूत्र में लिखा जा सकता है
    • sign bit: x[0] ⊕ y[0]
    • बाकी bits: x[1:] + y[1:] - offset
  • क्योंकि floating-point format 1 + xm को implicit रूप से संभालता है, L-Mul को वास्तविक implementation में एक adder से बनाया जा सकता है
  • यदि mantissa का योग 2 से ऊपर चला जाए, तो carry अपने-आप exponent तक पहुँच जाता है
  • इससे पारंपरिक floating-point multiplication में आवश्यक mantissa multiplication और rounding चरणों को छोड़ा जा सकता है, और गणना घटती है

Transformer attention में उपयोग

  • L-Mul-आधारित attention, Q, K, V बनाने के बाद attention calculation की matrix multiplication को L-matmul से बदल देता है
  • गणना का रूप इस प्रकार है
    • K = H · Wk
    • Q = H · Wq
    • V = H · Wv
    • A = softmax[L-matmul(Q, Kᵀ) / √d]
    • H′ = L-matmul(A, H)
  • L-matmul एक matrix multiplication है जिसमें सामान्य floating-point multiplication की जगह पूरी तरह L-Mul का उपयोग होता है
  • यह संरचना floating-point multiplication को integer addition में बदलकर computational resources का उपयोग कम करती है

precision·complexity analysis और प्रयोग परिणाम

  • precision analysis इस आधार पर किया गया है कि L-Mul, floating-point संख्या के fraction को कितने bits तक बनाए रखने के बराबर है
  • uniform-distribution operands पर आधारित analysis में L-Mul, fp8 e5m2 से अधिक accurate है
  • pre-trained LLM के 5 संयुक्त weight distributions पर आधारित व्यावहारिक analysis में, 5-bit mantissa operands पर यह fp8 e4m3 से अधिक precision हासिल कर सकता है
  • प्रयोग परिणाम theoretical error estimates के अनुरूप हैं
    • 4-bit mantissa L-Mul: float8 e4m3 multiplication जैसी precision
    • 3-bit mantissa L-Mul: float8 e5m2 से अधिक precision
  • pre-trained LLM में standard attention implementation को सीधे L-Mul attention से बदला गया, और कोई अतिरिक्त training नहीं की गई
    • commonsense, structured reasoning, language understanding कार्यों में औसत performance loss: 0.07%
    • visual question answering, object hallucination, free-form visual instruction कार्यों में औसत accuracy परिवर्तन: 0.12% सुधार
  • fine-tuning प्रयोगों में attention, linear transformation और element-wise multiplication के सभी multiplications को 3-bit mantissa L-Mul से बदलने वाला model, float8 e4m3 accumulation precision वाले standard model के समान performance देता है
  • gate-level computational cost estimation में सामान्य multiplication का स्तर इस प्रकार है
    • fp16 multiplication: लगभग 584
    • fp8 e4m3 multiplication: लगभग 325
    • fp8 e5m2 multiplication: लगभग 296
  • L-Mul की gate-level computational cost estimation इससे कम है
    • fp16 L-Mul: लगभग 256
    • fp8 L-Mul: लगभग 157
  • GPU पर L-Mul का native implementation नहीं है, इसलिए इसकी efficiency का पूरा लाभ उठाना कठिन है, और L-Mul-आधारित models को ऐसी devices पर train और host करने की सिफारिश की जाती है जिनमें विशेष architecture design integrated हो
  • यह तकनीक फिलहाल patent pending स्थिति में है

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

1 टिप्पणियां

 
GN⁺ 2024-10-10
Hacker News की राय

  • मुझे याद है कि पहले Intel CPU पर floating-point calculations महंगे होते थे, इसलिए प्रोग्रामर integer tricks से उन्हें bypass करते थे
    Forth के लिए मशहूर Chuck Moore ने दिखाया था कि 1.6 × 4.1 जैसी वैल्यू को बीच की गणना में 16 × 41 जैसे integer के रूप में प्रोसेस किया जा सकता है, फिर आउटपुट के समय decimal point को सही जगह पर वापस रखा जा सकता है. अगर floating-point values की range ऐसी हो कि 10 से गुणा करने पर भी 65536 से ऊपर न जाए, तो यह 16-bit integer पर भी ठीक चलता था, और उन embedded chips के लिए बढ़िया था जिन्हें 10-bit precision वाले analog values को प्रति सेकंड कई बार तेज़ी से compute करना होता था
    मैंने बहुत पहले Microsoft Streets and Trips पर काम कर चुके एक Microsoft engineer से भी बात की थी; उनका कहना था कि वे ऐसे numbers और calculations, जो सामान्यतः floating point होते, उन्हें सिर्फ़ ज़रूरी precision रखने वाले किसी packed integer format में डालते थे, ताकि उस समय के CPU पर तेज़ चल सकें और CD-ROM में फिट होने लायक ज़्यादा आसानी से compress भी हो सकें. स्क्रीनशॉट यहाँ है: https://archive.org/details/3135521376_qq_CD1

    • इसे fixed-point arithmetic कहा जाता है, और काश ज़्यादा प्रोग्रामर इस शानदार तकनीक को जानते
      सही financial code में यही इस्तेमाल होना चाहिए, लेकिन मैंने finance industry में इसे ज़्यादा नहीं देखा, जब तक कि mainframe न चल रहा हो. दिलचस्प बात यह है कि मैंने software rasterizers में fixed-point arithmetic कहीं ज़्यादा देखा है, जैसे FreeType, GDI, WPF, WARP(D3D11 reference rasterizer)
    • मुझे उस दौर के fractal generator FRACTINT के साथ छेड़छाड़ करने की याद है, जब floating-point coprocessors आम नहीं थे. वह fixed-point math से fractals को calculate और display करता था, और तब fractals इतने शानदार लगते थे कि हर कोई fractal business करना चाहता था, और सारे Nobel Prize भी मानो fractal researchers को ही मिलने वाले थे
    • Ozaki ने int8 tensor cores के साथ fp64 matrix multiplication किया है
      https://arxiv.org/html/2306.11975v4
      वाकई दिलचस्प
    • मेरी जानकारी में आज भी पैसे या financial numbers को संभालने का यह सबसे अच्छा तरीका है
    • वह खास trick fixed-point arithmetic के नाम से जानी जाती है. यह function के fixed point वाली अवधारणा से अलग है

  • दावा यह है कि “element-wise floating-point tensor multiplication में energy cost संभावित रूप से 95% और dot product में 80% तक घट सकती है”; अगर यह convolutional neural networks की बात होती, तो computation optimization का कहीं ज़्यादा मतलब होता
    लेकिन transformers में computation हल्का और memory भारी होती है. bottleneck model weights को cores तक लाने की प्रक्रिया है, और उद्धृत 95% व 80% energy savings पूरे inference process के लिए नहीं बल्कि सिर्फ़ multiplication operation को अलग करके दी गई हैं

    • prefill, single-batch में भी, और multi-batch decoding भी अब भी compute-bound है
      “decoder-only transformer inference memory-bandwidth bottleneck है” जैसी बार-बार दोहराई जाने वाली बात सख्ती से सिर्फ़ batch size 1 वाले single-batch decoding पर लागू होती है. उस स्थिति में ज़्यादातर vector-matrix multiplies होते हैं
    • इससे भी बुरा यह है कि energy gain fp32 computation के मुकाबले बताया गया है, जबकि fp8 में multipliers इतने छोटे होते हैं कि adders और shifters energy व area के लिहाज़ से arithmetic unit का बड़ा हिस्सा बन जाते हैं, इसलिए इस paper का फायदा छोटा होगा
      fp8 में estimated gate count सामान्य fp8 multiplier के लिए 296 है और इस तकनीक के लिए 157, इसलिए multiplier power gain काफ़ी कम होगा. लगभग 50% ज़्यादा उचित अनुमान लगता है, और फिर वही बात कि fp8 में dot product में addition operation का बड़ा हिस्सा होता है
      कुल मिलाकर 80% power gain और मामूली accuracy drop का दावा काफ़ी बेईमानी भरा लगता है. power gain सिर्फ़ fp32 operations पर लागू है, जबकि मामूली accuracy drop सिर्फ़ fp8 operators पर. fp32 में accuracy drop का विश्लेषण नहीं किया गया, और fp8 dot products में बचने वाली power भी नहीं दिखाई गई
    • fp8 इतना छोटा है कि multiplication को बड़े floating-point formats की तुलना में बहुत सरल circuitry से किया जा सकता है
      fp4 जैसे और छोटे formats में तो शायद बस lookup table ही इस्तेमाल की जा सकती है, और तब यह वास्तव में कुछ हद तक standardized quantization scheme जैसा हो जाएगा
    • transformers के लिए वाकई अच्छी architecture शायद memory और compute की colocated layout जैसी लगती है
    • यह सिर्फ़ single-user या हल्के inference के लिए सही है. training और batched inference में यह जल्दी ही compute bottleneck बन सकता है

  • [2023] GradIEEEnt half decent: The hidden power of imprecise lines
    http://tom7.org/grad/murphy2023grad.pdf
    वीडियो भी है: https://www.youtube.com/watch?v=Ae9EKCyI1xU

    • इस पर पहले का HN पोस्ट भी है
      GradIEEEnt half decent: The hidden power of imprecise lines [video] - https://news.ycombinator.com/item?id=36806970 - जुलाई 2023, 9 टिप्पणियाँ
      GradIEEEnt half decent - https://news.ycombinator.com/item?id=35780921 - मई 2023, 32 टिप्पणियाँ
    • मैं चाहता था कि paper इसे “earlier exploration को support करने वाला काम” जैसी किसी तरह cite करे, लेकिन अफ़सोस ऐसा नहीं था

  • मैंने इसे पढ़ा नहीं है, लेकिन लगता है कि यह किसी न किसी रूप में log table का इस्तेमाल कर रहा है
    मैं इसे कमतर नहीं बता रहा, बल्कि पूछ रहा हूँ क्योंकि logic gates जैसे और बुनियादी स्तर पर logs को लेकर मुझे लगता है कि मैं कुछ मिस कर रहा हूँ. अगर multiplication को table lookup और addition में बदला जा सकता है, तो उलटे ऐसे circuits या tradeoffs के संयोजन भी होने चाहिए जो मुश्किल addition और आसान multiplication दें

    • log space अच्छा है, क्योंकि यह multiplication को addition से बदल देता है
      यह हिस्सा आसान है और hardware में कोई भी कर सकता है. मुश्किल हिस्सा accumulation है, ख़ासकर तब जब बड़ी range में accumulate करना हो और फिर भी log space में बने रहना हो
    • हाँ, log number systems ऐसे ही काम करते हैं

  • मुझे हैरानी है कि paper में error term की ठीक से derivation और discussion नहीं दिखती. सब कुछ सिर्फ़ inference results के ज़रिए परोक्ष रूप से handle किया गया है

    • मुझे भी यह paper थोड़ा अजीब लगा. gate estimates को diagrams के बिना सिर्फ़ text description में देने से ज़रूरी हिस्से छूट जाना बहुत आसान है
      पूरी gate-level explanation न भी हो, तब भी “adder” जैसे block labels वाला diagram होना चाहिए था. पहले paragraph में de Vries नाम देखना भी भरोसा बढ़ाने वाला नहीं था

  • method section के footnote में लिखा है: “L-Mul आधारित models को integrated special architecture design वाले devices पर train और host करने की सिफारिश की जाती है. patent pending”

  • लगता है computation कम होगी, लेकिन क्योंकि हर value के लिए अब भी 8 bits चाहिए, इसलिए inference चलाने के लिए memory requirement कम नहीं होगी
    इस वजह से यह कहना मुश्किल है कि इससे model inference के लिए ज़्यादा accessible हो जाएगा. अगर यह storage format training के लिए भी उपयुक्त हो, तो यह संभावित रूप से दिलचस्प application area हो सकता है

    • वास्तव में precision और range के हिसाब से यह हर weight पर लगभग 0.5 bits कम efficient है, लेकिन paper इस बिंदु को बिल्कुल उभारता नहीं है

  • bytes को move करने में computation की तुलना में 10x से भी ज़्यादा energy लगती है. compute efficiency उतनी बड़ी समस्या नहीं है जितनी लोग समझते हैं
    अभी compute बस गलत जगह पर है, और कम से कम dot product में शुरुआती aggregation के लिए इसे memory bus को bypass करके memory cells के ठीक पास होना चाहिए

    • फिर भी क्या यह battery-constrained devices के लिए उपयोगी नहीं हो सकता?

  • मेरे अनुभव में fixed-point math के असली जादूगर 8-bit और 16-bit video game designers थे
    उन्होंने जो optimizations किए वे अद्भुत थे, और उदाहरण के लिए उन्हीं की बदौलत शुरुआती flight simulators और first-person shooters के लिए real time में 3D matrix math calculate करना संभव हुआ

    • angles को 2π = 256 के रूप में redefine करना काफ़ी चतुर trick थी