सीमित मेमोरी में कुशल LLM inference को संभव बनाने वाला ‘LLM in a Flash’

 (huggingface.co)
1 पॉइंट द्वारा GN⁺ 2023-12-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM in a Flash DRAM से बड़े LLM के parameters को flash memory में रखता है और केवल ज़रूरी हिस्सों को DRAM में लाकर सीमित मेमोरी वाले devices पर भी inference संभव बनाता है
  • flash memory की access characteristics को ध्यान में रखकर बने inference cost model के आधार पर, यह transfer होने वाले data की मात्रा घटाता है और बड़े, लगातार chunks पढ़ने को बढ़ावा देता है
  • windowing पहले activate हुए neurons को reuse करता है, और row-column bundling flash की sequential access ताकत का इस्तेमाल कर bottleneck को कम करता है
  • दोनों techniques को मिलाने पर उपलब्ध DRAM के अधिकतम 2 गुना size वाले model चलाए जा सकते हैं, और simple loading की तुलना में CPU पर 4~5 गुना, GPU पर 20~25 गुना तेज़ inference दिखता है
  • sparsity awareness, context-adaptive loading, और hardware-oriented design के संयोजन से memory-constrained devices पर LLM चलाने की संभावना बढ़ती है

flash memory आधारित LLM inference

  • Large language models विभिन्न natural language processing tasks में उच्च performance देते हैं, लेकिन compute और memory requirements बड़ी होने के कारण सीमित DRAM capacity वाले devices पर इन्हें चलाना कठिन होता है
  • LLM in a Flash इस constraint को model parameters को flash memory में store करके और inference के दौरान केवल आवश्यक data को on-demand DRAM में लाकर संभालता है
  • इस approach के केंद्र में flash memory के behavior के अनुरूप बनाया गया inference cost model है
    • flash से transfer होने वाले data की मात्रा घटाने के लिए optimize करता है
    • data को बड़े और लगातार chunks में पढ़ने के लिए design किया गया है

transfer मात्रा और read patterns घटाने वाली दो techniques

  • windowing पहले activate हुए neurons को reuse करके flash से DRAM में ले जाए जाने वाले data transfer की मात्रा घटाता है
  • row-column bundling flash memory की sequential data access में मजबूती के अनुरूप, flash से पढ़े जाने वाले data chunks का size बढ़ाता है
  • दोनों techniques को साथ इस्तेमाल करने पर उपलब्ध DRAM से अधिकतम 2 गुना बड़े model चलाए जा सकते हैं
  • simple loading method की तुलना में inference speedup hardware के अनुसार अलग-अलग दिखता है
    • CPU पर 4~5 गुना तेज़
    • GPU पर 20~25 गुना तेज़
  • यह design sparsity awareness, context-adaptive loading, और hardware-oriented design को integrate कर सीमित memory environments में LLM inference को संभव बनाता है

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

1 टिप्पणियां

 
GN⁺ 2023-12-22
Hacker News टिप्पणियाँ

  • वह पेपर पहले से ही काफ़ी जटिल Deja Vu पेपर की sparsity-आधारित तकनीक पर बना है, इसलिए उसे समझने में समय लगा।
    Deja Vu का कहना है कि जिन मॉडलों में weight sparsity कम होती है, उनमें भी “contextual sparsity” काफ़ी अधिक हो सकती है। यानी matrix multiplication के result vector में बहुत से 0 बनते हैं, लेकिन कौन-सी position 0 बनेगी, यह input के अनुसार बदलता है।
    इस sparsity का उपयोग करके matrix की कुछ rows को load करना छोड़ा जा सकता है, और performance gain पाने के लिए पहले से यह predict करना होता है कि कौन-सी rows छोड़ी जाएँगी; यह prediction low-rank matrix से किया जा सकता है।
    Apple का पेपर सुझाव देता है कि यह खोज सिर्फ RAM loading performance ही नहीं, बल्कि bandwidth को ज़्यादा घटाए बिना flash memory से loading में भी मदद करती है।
    Attention matrix अपेक्षाकृत हल्का है, और जिसे sparse तरीके से load करना चाहिए वह FFN है। साथ ही, FFN input के बजाय ReLU layer के output को predict करने पर कहीं बेहतर sparsity मिल सकती है। अगर यह predict किया जा सके कि “matrix multiplication के बाद और ReLU से पहले यह vector slot negative होगा”, तो उस matrix column को load किए बिना 0 output किया जा सकता है।
    प्रस्ताव यह है कि FFN की ज़्यादातर rows को बिल्कुल load करने की ज़रूरत नहीं होती, और हर FFN के लिए हाल ही में इस्तेमाल की गई rows का cache रखा जाए, फिर ज़रूरत पड़ने पर उसे flash से update किया जाए। Chunk loading और projection layers के बीच correlation जैसी और भी बातें हैं, लेकिन मूल insight यही लगती है।
    FFN का मतलब Feed Forward Network है, और transformer में यही सबसे बड़े blocks होते हैं.

  • मुझे यह जानने की जिज्ञासा है कि model का कितना हिस्सा load न करने पर वास्तविक performance difference दिखना शुरू होता है।
    उदाहरण के लिए, अगर पूरे model को RAM में रखने पर मिलने वाली performance का 90% बनाए रखना हो, तो क्या आधी memory ही काफ़ी होगी, या 90% चाहिए, या 95%?
    आखिरकार सवाल यह है कि RAM कम करने पर maximum performance की तुलना में performance कितनी तेज़ी से गिरती है। Graph कम RAM की स्थिति में इस algorithm और baseline algorithm की तुलना करता है; वह अलग बात है, लेकिन सवाल अच्छा है।
    अगर 8GB का model पूरा फोन memory में डाले बिना भी अच्छी performance दे सके, तो यह साफ़ तौर पर उपयोगी होगा।

    • Apple ने उपलब्ध memory के दोगुने आकार के model को चलाया। क्या वही मिला हुआ optimal point है, या response time की क़ीमत पर उससे बड़े models भी चल सकते हैं, यह पता नहीं।
      पूरा पेपर पढ़ने लायक है, और काफ़ी दिलचस्प काम है: https://arxiv.org/pdf/2312.11514
      पेपर में ज़ोर देकर बताई गई बात data transfer को कम करना और flash memory throughput को अधिकतम करना है, जिसके लिए दो पूरक तकनीकों का उपयोग किया गया।
      Windowing वह तरीका है जिसमें हाल में compute किए गए tokens के activation values को reuse करते हुए, पिछले कुछ tokens के लिए ज़रूरी parameters ही load किए जाते हैं, जिससे weight-loading I/O requests की संख्या घटती है।
      Row-column bundling में up-projection और down-projection layers की rows और columns को जोड़कर store किया जाता है, ताकि flash से बड़े continuous chunks पढ़े जा सकें, और बड़े chunks पढ़कर throughput बढ़े।
    • मैं बस अपने विचार व्यवस्थित कर रहा हूँ; इसे किसी authoritative explanation की तरह न लें।
      सिद्धांततः, जब model का कुछ हिस्सा flash में हो, तो single-token inference time उतना होना चाहिए जितना पूरा model RAM में होने पर inference time होता है, और उसमें flash में रखे model के हिस्से को load करने का समय जुड़ जाता है।
      यह मानते हुए कि flash में वापस लिखने की ज़रूरत नहीं है, लेकिन मैं LLM विशेषज्ञ नहीं हूँ, इसलिए ग़लत भी हो सकता हूँ।
      अगर layers की संख्या 10 से बहुत ज़्यादा हो, तो शायद RAM का सिर्फ़ छोटा-सा हिस्सा छोड़कर एक-एक layer load की जा सकती है। ज़्यादातर LLMs में दर्जनों layers होती हैं, इसलिए यह plausible लगता है।
      अगर inference के दौरान RAM bottleneck न हो, तो ऐसा भी हो सकता है कि current layer पर inference चलते समय अगली layer को flash से RAM में DMA transfer किया जाए। Single-processor system में RAM bottleneck की वजह से यह ठीक से न चल पाए, ऐसा लगता है।
      Dual-processor system में शायद एक processor अगली layer को RAM में load करे, जबकि दूसरा processor पिछली layer पर inference चलाए; ऐसे में कम RAM के साथ भी बहुत बड़े LLMs चलाना संभव हो सकता है।
      मैं इस समय नई LLM AI machine assemble करने के लिए रखे parts के ढेर के पास बैठा हूँ। z840 dual-processor है, इसलिए इस तरह की चीज़ें सीधे आज़माने को लेकर उत्साहित हूँ।

  • Apple डिवाइस, प्रतिस्पर्धियों के समान डिवाइसों की तुलना में, RAM काफ़ी कम होने के लिए जाने जाते हैं।
    इसका एक हिस्सा इस वजह से है कि Apple की software टीम Objective-C जैसी ज़्यादा efficient भाषाओं का उपयोग करती है, और एक हिस्सा इस वजह से कि iOS apps को बहुत तरह के screen resolutions को target नहीं करना पड़ता। इसलिए high-resolution textures को load करके बाद में downscale करने की ज़रूरत अपेक्षाकृत कम होती है।
    साथ ही, Apple जैसी scale पर खरीदने पर भी RAM बहुत सस्ती नहीं होती, इसलिए RAM बढ़ाने से margins पर असर, दूसरे features जोड़ने की तुलना में, ज़्यादा पड़ता है।
    लेकिन LLM स्वभाव से ही बहुत RAM लेते हैं, इसलिए ये सारी चुनौतियाँ फिर सामने आ जाती हैं। चाहे कोई भी memory-saving technique इस्तेमाल करें, ज़्यादा RAM वाले competitors बड़े, बेहतर और ज़्यादा स्मार्ट models चला सकते हैं

    • इसके अलावा, आजकल ज़्यादातर desktop Mac में RAM upgrade संभव नहीं है।
      मैं जल्द ही Mac खरीदना चाहता हूँ, लेकिन कितनी RAM order करूँ, इसे लेकर सच में दुविधा है। budget सीमित होने से यह और मुश्किल हो जाता है। अगर कोई सीमा न होती, तो मैं कम से कम 32GB लेता।
      अभी भी उम्मीद है कि Apple अपनी RAM pricing policy बदले, लेकिन शायद यह बेकार की उम्मीद है
    • “कम RAM” संभव होने के तरीके पर दो बातें और जोड़ूँ तो, Apple डिवाइस memory compression को support करते हैं: https://www.lifewire.com/understanding-compressed-memory-os-...
      इसका संबंधित implementation भी देखा जा सकता है: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libke...
      और Apple डिवाइस “jetsam” नाम का एक feature भी support करते हैं, जो high-priority apps को smoothly चलते रहने देने के लिए unused या background apps को बंद करके memory खाली करता है: https://developer.apple.com/documentation/xcode/identifying-...
    • Mac पर बने रहने की मेरी एकमात्र वजह इसकी आदत है, और MacBook Air का शांत होना।
      अगर किसी के पास शांत या लगभग noiseless Linux laptop की recommendation हो, तो मैं सुनने के लिए तैयार हूँ। ज़्यादातर में fans तेज़ चलते हैं, और शांति के बदले मैं कुछ CPU performance छोड़ने को तैयार हूँ। अगर quiet mode को आसानी से on/off किया जा सके, तो वह भी अच्छा होगा।
      अब तक मैंने ऐसा कुछ नहीं देखा जो MacBook Air की शांति की बराबरी करे, और अगर कोई product मुझे ग़लत साबित करे तो मुझे खुशी होगी।
      बेशक, अगर वह सस्ता हो या RAM replace की जा सके, तो यह भी अच्छा होगा। मैं MacBook Air का उपयोग मुख्यतः web-based services और Linux servers में remote terminal के रूप में करता हूँ, जहाँ बड़े projects compile होते हैं और home/self-hosting चलता है
    • मुझे नहीं पता यह व्याख्या सही है या नहीं। लगता है Apple लंबे समय में यह दांव लगा रहा है कि सही CPU/GPU architecture होने पर flash memory, RAM के बराबर आ सकती है।
      टाइमलाइन शायद आगे खिसक गई है, लेकिन मुझे नहीं लगता कि उनका hypothesis ग़लत है

  • मुझे इस विषय की केवल सीमित समझ है, लेकिन मैं सोच रहा हूँ कि क्या इस तरीके से फ़ोन पर offline LLM चलाना संभव हो जाएगा।
    अगर हाँ, तो server पर confidential data भेजे बिना AI-सहायित content moderation जैसे कई दिलचस्प applications संभव हो सकते हैं

    • हाँ, यह उस दिशा में काफ़ी सुधार ला सकता है। इस technique के बिना भी फ़ोन पर LLM पहले से चल सकते हैं; असली सवाल यह है कि model कितना बड़ा हो सकता है, उसे कितनी aggressively quantize करना पड़ेगा, और जो कुछ models बचते हैं वे काफ़ी अच्छे results देते हैं या नहीं।
      उदाहरण के लिए, कल Apple A-series chips (iPhone) पर LLM चलाने को लेकर एक GitHub Discussion यहाँ पोस्ट हुई थी: https://news.ycombinator.com/item?id=38703161
    • हाँ। अंतिम लक्ष्य यही है कि फ़ोन की DRAM बहुत सीमित होने के बावजूद फ़ोन पर बड़े models चलाए जा सकें
    • पक्का नहीं, लेकिन लगता है कि यही नए Pixel का एक selling point है

  • मुझे अच्छा लगता है कि हाल की पोस्टें इसे “AI” नहीं बल्कि LLM कह रही हैं। इससे पता चलता है कि बात marketing hype की नहीं, बल्कि एक specific technology की हो रही है

    • यह Hugging Face है। उसके audience को देखते हुए, अगर यह specific न होता तो वही बहुत अजीब होता

  • मुझे जिज्ञासा है कि यह FlashAttention से कैसे अलग है। इतने मिलते-जुलते terms इस्तेमाल करके अगर abstract में फ़र्क न बताया जाए, तो भ्रम होता है।
    संपादन: लगता है यह flash framework के भीतर दो अलग mechanisms का extension है। paper का title बेहतर हो सकता था, लेकिन शुरुआती कुछ पन्नों में यह समझाया गया है

  • निष्कर्ष में मैं “यह feature users के सामने कैसे आएगा” जैसी किसी धारा की उम्मीद कर रहा था, लेकिन शायद वह paper के दायरे से बाहर की बात है।
    मैं जानना चाहता हूँ कि क्या ऐसा feature CoreML के API call या setting के रूप में आएगा, जैसे use_flash flag देना पड़े, या फिर यह users को दिखे बिना होने वाला runtime optimization होगा।
    यह भी जानना चाहूँगा कि क्या किसी को Apple के CoreML, Metal आदि के developer roadmap को समझाने वाली कोई अच्छी presentation या talk पता है

  • क्या Apple ने किसी ईरानी कंपनी का अधिग्रहण किया था?

    • लगता है टीम के ज़्यादातर लोग XNOR.ai से हैं, जिसे Apple ने 2020 में acquire किया था[0]। कंपनी Seattle-आधारित थी, और उसके founders संभवतः ईरानी मूल के थे।
      [0]: https://www.geekwire.com/2020/exclusive-apple-acquires-xnor-...
    • मेरे मन में भी यही बात आई थी। ज़्यादातर लोग Sharif से हैं, जो ईरान में Stanford जैसी मानी जाती है

  • मुझे पता है कि अप्रोच अलग है, लेकिन दोनों flash memory का इस्तेमाल करते हैं, इसलिए मुझे उम्मीद थी कि यह पेपर कम-से-कम FlashAttention [1] का ज़िक्र करेगा
    [1] https://arxiv.org/abs/2205.14135

    • जहाँ तक मुझे पता है, FlashAttention flash memory को बिल्कुल हैंडल नहीं करता
      मेरी समझ के अनुसार, FlashAttention local memory, खासकर SRAM, का बेहतर उपयोग करने वाले access pattern के बारे में है. उदाहरण के लिए, data को CPU L1 cache या GPU के समान स्तर वाली memory में बनाए रखना
      दूसरे शब्दों में, FlashAttention DRAM से तेज हिस्से के बारे में है, जबकि यह पेपर DRAM से धीमे हिस्से पर बेहतर offloading की समस्या को संभालता है

  • “उदाहरण के लिए, OPT 6.7B मॉडल FFN लेयर के अंदर उल्लेखनीय 97% sparsity दिखाता है” में, क्या कोई जानता है कि यह metric ठीक-ठीक क्या मतलब रखता है?
    मैं जानना चाहता/चाहती हूँ कि क्या इसका मतलब है कि layer values का 97% 0 है, या फिर इसे उसके आकार के 3% तक compress किया जा सकता है

    • इसका मतलब है कि उस layer के output का 97% 0 है, और किसी भी समय सिर्फ 3% activate होता है
      लेकिन क्योंकि activate होने वाला 3% स्थिर नहीं है, इसलिए बाकी 97% को पूरी तरह हटाया नहीं जा सकता. पेपर शायद यह कहता है कि active 3% का काफी सटीक अनुमान लगाया जा सकता है, जिससे accuracy बहुत ज़्यादा खोए बिना इसे तेज बनाया जा सकता है