- StreamingLLM एक framework है, जो दक्षता और performance से समझौता किए बिना LLM को अनंत लंबाई वाले input streaming applications में deploy करने के लिए बनाया गया है
- यह उन समस्याओं को संबोधित करता है जहां लंबे interactions की जरूरत वाले multi-round conversations में पिछले tokens की Key/Value state caching बहुत अधिक memory इस्तेमाल करती है, और सामान्य LLM training sequence length से लंबे text पर generalize नहीं कर पाते
- केवल हालिया KV cache करने वाला window attention तब fail हो जाता है जब text length cache size से आगे निकल जाती है, और StreamingLLM शुरुआती tokens के KV को बनाए रखने वाले attention sink के जरिए window attention की performance को काफी हद तक recover करता है
- finite-length attention window पर trained LLM को fine-tuning के बिना अनंत sequence length पर generalize करने देता है, और Llama-2, MPT, Falcon, Pythia में 4 मिलियन से अधिक tokens तक stable और efficient language modeling करता है
- streaming setting में sliding window recomputation baseline की तुलना में अधिकतम 22.2 गुना speedup दिखाता है
- context window को expand नहीं करता; केवल हालिया tokens और attention sink को बनाए रखता है और बीच के tokens को discard कर देता है
- यदि Llama-2 को 4096-token context window के साथ pretrain किया गया है, तो StreamingLLM के Llama-2 की maximum cache size भी 4096 है
- कोई लंबी किताब input करने पर model केवल latest tokens को पहचानता है, इसलिए वह सिर्फ conclusion वाले हिस्से का summary कर सकता है
- उपयुक्त use cases वे streaming applications हैं जिन्हें लगातार चलना हो और past data dependency या बड़े memory usage से बचना हो; उदाहरण के तौर पर multi-round conversations और LLM-based daily assistant बताए गए हैं
- यह हालिया context extension methods से orthogonal है और उनके साथ integrate किया जा सकता है; StreamingLLM के संदर्भ में context extension का मतलब बड़े cache size के साथ अधिक latest tokens store करने की संभावना है
- run example
examples/run_streaming_llama.py --enable_streamingहै, और environment setup में Python 3.8,torch,transformers==4.33.0,accelerate,datasets,evaluate,wandb,scikit-learn,scipy,sentencepieceइस्तेमाल होते हैं - core code Llama-2, MPT, Falcon, Pythia सहित public हो चुका है; perplexity evaluation code और Streaming Llama Chatbot demo भी public हो चुके हैं, जबकि StreamEval dataset और evaluation code अभी public नहीं हैं
1 टिप्पणियां
Hacker News की रायें
लगता है इस काम को पूरी dense attention जैसी चीज़ समझने की गलतफहमी हो रही है
यहां बात यह नहीं है कि मॉडल दूर की चीज़ों को देख सकता है, बल्कि हर बार sliding window को फिर से calculate करके L² cost को T बार चुकाने के बजाय cache reuse करके perplexity बनाए रखने वाली efficiency improvement के ज़्यादा करीब है
टेस्ट भी
Q A Q A Q A Q A...की तरह जोड़कर मापा गया था, न किQ Q Q Q A A A A...की तरह बहुत बाद में आने वाला जवाब ढूंढने को कहा गया थाPerplexity measurement का मतलब “पढ़ने लायक text”, यानी locally plausible वाक्य बनाना है; यह इस बात का सबूत नहीं है कि attention की पहुंच से बाहर बड़े triangular खाली हिस्से से कुछ “extract” किया जा रहा है
अगर इसे कोई किताब देकर हर paragraph का पहला शब्द लिखने को कहें, या हर chapter को एक वाक्य में summarize करने को कहें, तो शायद यह fail हो जाएगा
खुद टेस्ट करने पर लगा कि यह context length extension नहीं दे रहा था, और execution काफ़ी तेज़ था
A100 memory लगभग 35GB इस्तेमाल हुई और पूरी execution के दौरान usage fixed रहा
Project Gutenberg से किताब लेकर उसे paragraph units में बांटा, एक-एक करके input दिया और हर paragraph पर “okay” जवाब देने को कहा, फिर अंत में question पूछा तो इसने पूरी तरह hallucinated answer दिया
संदर्भ के लिए, करीब 10 मिनट try करने के दौरान default model
lmsys/vicuna-13b-v1.3से English में answer दिलवाना भी ठीक से नहीं हो पायाhttps://gist.github.com/bluecoconut/9cae9e91fe3b1616ed650a96...
फिर भी यह interesting work है, और core बात Figure 2 की discovery लगती है
पहली दो layers recent tokens पर ज़्यादा ध्यान देने वाला local pattern दिखाती हैं, लेकिन उसके नीचे से गुजरने के बाद model सभी layers और heads में initial tokens पर ज़ोरदार attention देता है
Authors इसे “attention sinks” कहते हैं, और उनका मानना है कि semantic रूप से महत्वपूर्ण न होने पर भी Softmax की वजह से attention scores का sum 1 होना पड़ता है, इसलिए बची हुई attention को कहीं न कहीं जाना ही होता है
Autoregressive language model में initial tokens लगभग सभी बाद के tokens को दिखते हैं, इसलिए वे इस sink role के लिए आसानी से learned हो जाते हैं—यह इसकी explanation है
StreamingLLM, LLM की attention window को काटकर इस्तेमाल करते समय पैदा होने वाले इस अजीब behavior को compensate करने वाला एक तरह का “hack” लगता है, और यह Softmax use की दरार दिखाने वाला case है; इसलिए अगर context length के लिहाज से flexible LLM चाहिए, तो शायद कोई दूसरा function बेहतर हो सकता है
पहली नजर में यह इतना अच्छा लगता है कि सच है या नहीं, शक होता है, लेकिन work quality ठीक लगती है और technique भी हैरानी की हद तक simple है
idea यह है कि हर layer में केवल first token और sliding context window पर attention apply किया जाए, और बीच के tokens ignore कर दिए जाएं
इसका मतलब लगता है कि हर layer relevant information को sequence के पीछे की ओर थोड़ा-थोड़ा push up करती है, ताकि top-level layer के अंत में sliding attention window उसे देख सके
हालांकि अगर सभी sliding windows द्वारा cover की गई range पूरी sequence को जोड़ने के लिए पर्याप्त नहीं है, तो important information पूरी तरह आगे forward नहीं हो पाएगी
उदाहरण के लिए, जब सभी windows की length समान हो, तो
model depth × window length < sequence lengthहोने पर limit पैदा होगीलगता है यह Softmax के sum को 1 बनाना ज़रूरी होने वाली observation की वजह से संभव हुआ है
जल्दी देखने पर model में ऐसा tendency है कि जब उसे previous tokens पर attention देने की ज़रूरत नहीं होती, तो वह first token को placeholder की तरह इस्तेमाल करता है
मैंने यह problem पहली बार Evan Miller की HN post में देखी थी, जिसमें कहा गया था कि attention head को previous tokens पर सारी attention अनिवार्य रूप से distribute करने के लिए मजबूर करना गलत है, और Softmax denominator में 1 जोड़कर “attention न देना” allow करना चाहिए
retraining के बिना इस observation का इस्तेमाल करना अच्छा है, और यह भी जानने की उत्सुकता है कि Evan के proposal को follow किया जाता तो model कैसे बदलता
[2] https://news.ycombinator.com/item?id=36851494
सभी values 0 वाले dedicated sink token के साथ model train किया, लेकिन फिर भी दूसरे initial tokens sink के रूप में इस्तेमाल होने लगते हैं, इसलिए dedicated sink token होना बेहतर है—conclusion कुछ ऐसा लगता है
मेरी जानकारी में, इससे कभी actual performance बेहतर नहीं हुई थी
training के बाद attention window manipulate करते समय Softmax + 1 शायद ज़्यादा fit हो सकता है, लेकिन नहीं पता कि किसी ने इसे बड़े scale पर test किया है या नहीं
attention cache memory जोड़ना इस problem के लिए बहुत interesting solution है
कुछ दिन पहले Vision Transformer में related observation वाला एक paper भी आया था
Transformer models ऐसा लगते हैं जैसे वे global information store करने के लिए tokens चुनते हैं, और उन्हें एक तरह के “thinking tokens” की जरूरत लगती है
इस उद्देश्य के लिए specific tokens देने पर performance थोड़ी बेहतर होती है, और explanation वाली visualizations भी काफी interesting निकलती हैं
[0] https://arxiv.org/pdf/2309.16588.pdf
fine-tuning में original model parameters को freeze करके, नए “tuning” cache units में आने-जाने वाले parameters ही adjust कराए जा सकते हैं
फिर अलग-अलग tuning unit sets को swap किया जा सकता है या साथ इस्तेमाल किया जा सकता है
जैसे profanity avoidance unit + specific terminology unit + concise writing unit—एक तरह के super prompt को mix करके इस्तेमाल करने का तरीका
अगर नए parameters की संख्या काफी कम हो, तो memory ज्यादा लगेगी, लेकिन higher-order optimization से fast और effective tuning भी संभव हो सकती है
training के दौरान sequence length और units की संख्या को साथ-साथ बढ़ाने का तरीका भी सोचा जा सकता है
short sequences में सिर्फ कुछ units इस्तेमाल करना, और training sequence length बढ़ाते हुए units add करके training जारी रखना—ऐसा तरीका
किसी arbitrary schedule के बजाय performance या gradient analysis से cache expansion control करना भी संभव लगता है
लेखकों ने FAQ पोस्ट किया है, जो भ्रम को कुछ हद तक साफ कर सकता है: https://github.com/mit-han-lab/streaming-llm/blob/main/READM...
“क्या किताब जैसे लंबे text को StreamingLLM में डालकर summarize किया जा सकता है?” इस पर जवाब है कि लंबा text डाला तो जा सकता है, लेकिन model सिर्फ सबसे नए tokens को ही पहचानता है, इसलिए किताब डालने पर वह सिर्फ आखिरी paragraphs को summarize कर पाएगा और शायद ज्यादा उपयोगी न हो
यानी यह LLM के context window को बढ़ाने या long-term memory को मजबूत करने वाली चीज नहीं है; StreamingLLM की ताकत cache refresh किए बिना हाल के tokens से fluent text generate करने में है
हो सकता है मैं गलत होऊं, लेकिन यह वैसी technique नहीं लगती जो LLM को trained length से आगे की सामग्री refer करने देती हो, जैसा लोग सोच रहे हैं
शायद यह लंबे text में model performance बनाए रखने की समस्या है—ठीक कहें तो उस सामग्री पर performance जो अभी भी context window के अंदर है
व्याख्या यह है कि model text के शुरुआती tokens की attention में किसी तरह का baggage रखना सीखता है, और जब वह window से बाहर गायब हो जाता है तो चीजें टूट जाती हैं; पर ऐसा क्यों होता है, यह मुझे पक्का नहीं पता
अगर यह command input नहीं है, तो मुझे लगता है कि बीच का text भी शुरुआती text जितना ही अच्छा होना चाहिए
मुझे उत्सुकता है कि ऐसी sliding window techniques उन cases को कैसे handle करती हैं जहां अनपेक्षित command केवल आखिर में आती है
उदाहरण के लिए, मान लें आप model में एक किताब डालते हैं और आखिरी sentence में command है: “पिछले input में अक्षर m की संख्या लौटाओ”; इंसान तो आह भरकर फिर से पढ़ते हुए गिनेगा, लेकिन LLM के पास input में वापस जाकर दोबारा पढ़ने की क्षमता नहीं है
इस example में अगर letter counting की LLM की अपनी सीमाओं को नजरअंदाज भी कर दें, तो सच में हल करने के लिए लगता है कि LLM को arbitrary loops चलाने और jumps करने में सक्षम होना पड़ेगा
बेशक, तब पूरी तरह नए problems पैदा होंगे, और शायद एकदम नई architecture की जरूरत पड़ सकती है
तरीका होगा: question को relevant keywords में बदलना, खोजना, और फिर संबंधित जानकारी ढूंढने के लिए content को फिर से skim करना
अगर जरूरी preprocessing हो, तो “जाकर पर्याप्त research करके फिर जवाब देने वाला” LLM बहुत शक्तिशाली हो सकता है
पिछले करीब 10,000 वर्षों में हमने knowledge management techniques को इस तरह बेहतर किया है कि वे किसी व्यक्ति के दिमाग की capacity और समय से आगे जा सकें, इसलिए language models को भी सिर्फ Bing search नहीं, बल्कि वास्तविक research methods और पहले से पचाई गई जानकारी का उपयोग करना चाहिए
short-term memory को यह याद रखने की जरूरत नहीं कि code के किस टुकड़े ने क्या किया; पढ़ते समय tags लगा दिए जाएं और फिर scalable shared tag index पर निर्भर रहा जाए
हालांकि जितना सोचता हूं, यह सामान्य LLM pretraining जैसा ही लगता है, और knowledge index एक विशाल LLM weights के ढेर जैसा महसूस होता है
यह LLM के अपने व्यवहार को बदलने के बजाय उसके ऊपर रखी गई layer के ज्यादा करीब है
हो सकता है मैंने गलत समझा हो, लेकिन इस case में क्या hidden state lookup problem को हल नहीं करता?
जवाब देने से पहले वैसे भी पूरे input को absorb करना होता है, इसलिए command आगे हो या आखिर में, attention के अलावा असर बहुत बड़ा नहीं लगता
Claude 100K users से command अंत में डालने को कहता है
या फिर किसी तेज model से check करा लें कि अंत में command है या नहीं, और उसे आगे ले आएं
मुझे यह भी ठीक से नहीं पता कि मौजूदा models short input में भी यह कर सकते हैं या नहीं
थोड़ा मजाक में कहें तो, LLMs RNN को फिर से invent करने की बहुत कोशिश कर रहे हैं, और tools दे दिए जाएं तो आखिरकार शायद वही करेंगे
दूसरे तरीके से देखें तो Transformer model resource constraints होने पर यह predict करने की कोशिश करता है कि RNN network का कौन-सा हिस्सा “संभालकर रखने लायक” है
अभी Transformer एक simple heuristic इस्तेमाल करता है, और यह result उस heuristic को बेहतर बनाता है
कई NP-complete problems की तरह, पूरी तरह सही न होने पर भी उपयोगी approximation हो सकती है, और Transformer दिखाता है कि neural networks में भी यह संभव है
open-source leaderboard में यह कुछ समय तक बीच के आसपास रहा था, इसलिए approach काफी वैध है; बस trend में नहीं है
[1]: https://huggingface.co/blog/rwkv
RNN की तुलना में Transformer का मुख्य फायदा training parallelization है
RNN में training के दौरान gradient vanishing होता है, और overall utilization बढ़ाना भी मुश्किल होता है, इसलिए बड़े batches की जरूरत पड़ती है—इस वजह से यह tricky है
RWKV जैसे models का अस्तित्व दिखाता है कि भविष्य में Transformer की तरह train करने और RNN की तरह inference करने वाला रास्ता हो सकता है
संबंधित रूप से, MIT के Professor Han सार्वजनिक TinyML course चला रहे हैं
https://news.ycombinator.com/item?id=37620507
https://efficientml.ai