[अनुवाद] Small Language Models (SLM) पर एक व्यापक अध्ययन

Small Language Models (SLM) पर एक व्यापक अध्ययन (Small Language Models: Survey, Measurements, and Insights)

शोधपत्र का परिचय

हाल के वर्षों में language models का विकास दो रुझानों में बंटा हुआ है। पहला है Large Language Model (LLM), जिन्हें विशाल data centers में लाखों GPU का उपयोग करके चलाया जाता है। ये models उन्नत language tasks को संभालते हैं और AI की मदद से विज्ञान जैसे जटिल समस्याओं को हल करने का लक्ष्य रखते हैं। लेकिन ऐसे LLM की लागत बहुत अधिक होती है और इन्हें भारी computational resources की आवश्यकता होती है, इसलिए इन्हें व्यक्तिगत devices पर तैनात करना व्यावहारिक नहीं है।

इसके विपरीत, Small Language Model (SLM) ऐसे devices के लिए डिज़ाइन किए गए हैं जिनमें resources सीमित होते हैं, जैसे smartphone, tablet और wearable devices। छोटे language models का उद्देश्य किफायती और व्यावहारिक AI उपलब्ध कराकर AI को सभी के लिए अधिक सुलभ बनाना है। यह शोधपत्र SLM पर पहला व्यापक सर्वेक्षण है, जो पिछले कुछ वर्षों में सार्वजनिक किए गए छोटे language models का तकनीकी innovation, performance और on-device execution cost के दृष्टिकोण से विश्लेषण करता है।

Small Language Models (SLM) की संरचना, dataset और training

Small Language Model (SLM) का अवलोकन

SLM, बड़े parameter वाले language models की तुलना में आकार में छोटे होते हैं, लेकिन इन्होंने common-sense reasoning, mathematical problem solving और in-context learning जैसे विभिन्न tasks में अच्छा प्रदर्शन दिखाया है। इससे on-device AI की संभावनाएं सामने आती हैं।

इस अध्ययन में 2023 के अंत से तेज़ी से बढ़ रहे SLM पर नज़र डाली गई और निम्नलिखित मानदंडों के आधार पर 59 SLM चुने गए, जिनके performance और cost आदि का अध्ययन किया गया:

• SLM का model size 100M से 5B के बीच परिभाषित किया गया है, और केवल उन्हीं models को शामिल किया गया है जिनके weights सार्वजनिक हैं और जिनका evaluation किया जा सकता है।

• बेहतर performance और वास्तविक deployment को ध्यान में रखते हुए केवल decoder-only Transformer architecture वाले models को शामिल किया गया है। यानी RWKV और Mamba जैसे architecture models इसमें शामिल नहीं किए गए।

• यह सर्वेक्षण pre-training प्रक्रिया से प्राप्त base knowledge पर केंद्रित है, इसलिए केवल instruct fine-tuned version उपलब्ध कराने वाले models (Microsoft Phi और StabilityAI StableLM) को छोड़कर केवल base models को शामिल किया गया है।

• इसके अलावा, pre-trained model को fine-tuning करके बनाए गए derivative models भी शामिल नहीं किए गए हैं।

उपरोक्त मानदंडों के अनुसार चुने गए models की सूची इस प्रकार है:

SLM की model architecture

SLM की model architecture, Transformer पर आधारित है और इसके कई रूपांतर हैं। Transformer architecture का मूल है Multi-Head Attention (MHA) और Feed-Forward Neural Network (FFN)। MHA input data के अलग-अलग हिस्सों पर ध्यान केंद्रित करने की क्षमता देता है, जिससे parallel processing की efficiency बढ़ती है। हाल के models में attention mechanism, FFN और activation functions के स्तर पर निम्नलिखित तरह के प्रयास किए जा रहे हैं:

1. Attention Mechanisms:

   • Multi-Head Attention (MHA): यह ऐसा mechanism है जो input data के कई हिस्सों पर एक साथ ध्यान देता है और Transformer का मुख्य घटक है।
   • Group-Query Attention (GQA): यह कई query values को समूहित करके attention की computational complexity कम करने का तरीका है।
   • Multi-Query Attention (MQA): यह प्रत्येक query के लिए अलग key और value projection की अनुमति देकर computational complexity कम करने का तरीका है।

2. Feed-Forward Neural Network (FFN):

   • Standard FFN: यह दो layers से बनी एक सरल network संरचना है।
   • Gated FFN: यह अतिरिक्त gate layer शामिल करके performance बढ़ाने वाली संरचना है।

3. Feed-Forward Neural Network का dimension expansion ratio (The intermediate ratio of the FFN): input dimension की तुलना में hidden layer के आकार को अनुपात के रूप में व्यक्त किया जाता है, जिसे सामान्यतः dimension expansion ratio कहा जाता है। यह अनुपात जितना बड़ा होगा, FFN उतने अधिक जटिल patterns सीख सकता है, लेकिन computational cost भी उतनी बढ़ेगी। Standard FFN में यह मान सामान्यतः लगभग 4 होता है, जबकि Gated FFN में यह 2 से 8 के बीच होता है।

4. Activation Functions: SLM में मुख्य रूप से ReLU (Rectified Linear Unit), GELU (Gaussian Error Linear Unit), $GELU_{tanh}$ और SiLU (Sigmoid Linear Unit) का उपयोग किया जाता है। 2022 में ReLU, 2023 में GELU और उसके variants, और 2024 में SiLU सबसे अधिक उपयोग की जाने वाली activation function बन गई है।

5. Layer Normalization: layer normalization के लिए LayerNorm और RMSNorm का उपयोग किया जाता है। RMSNorm का उपयोग लगातार बढ़ रहा है, और यह model training की stability बढ़ाने में योगदान देता है।

6. Vocabulary Size: vocabulary size से आशय उन unique tokens की संख्या से है जिन्हें SLM पहचान सकता है। हाल के SLM प्रायः 50,000 से अधिक vocabulary size रखते हैं, और पाया गया है कि vocabulary size बढ़ने पर performance भी बेहतर होती है।

ऊपर चुने गए 59 models के लिए, समय के साथ इन 6 प्रकार के रूपांतरणों का वितरण कैसे बदला, इसे इस प्रकार संक्षेपित किया जा सकता है:

इन model architectures की समीक्षा करते हुए model architecture innovations को भी समझा जा सका:

1. Parameter Sharing

   • parameter sharing एक ऐसी तकनीक है जिसका उपयोग Large Language Models (LLM) में network की कई layers या components में एक ही weights set को पुन: उपयोग करने के लिए किया जाता है। इस approach से model में parameters की संख्या काफ़ी कम की जा सकती है, जिससे performance बनाए रखते हुए training और inference दोनों अधिक efficient हो सकते हैं।
   • Embedding-lm_head sharing: embedding weights को अंतिम lm_head layer के साथ साझा करना सबसे सामान्य weight sharing तकनीक है। यह word embedding layer की sharing है और इसका RoPE (Rotary Position Encoding) से कोई संबंध नहीं है। Gemma और Qwen जैसे models ने इस sharing technique का उपयोग किया है।
   • Layer-wise Attention/FFN sharing: इस तरीके में एक ही weights set को model की कई layers में दोबारा उपयोग किया जाता है। यह SLM/LLM में आम है, जहां सभी Transformer layers समान parameters साझा करते हैं। उदाहरण के लिए, MobiLLaMA सभी Transformer blocks के FFN weights साझा करता है, जबकि MobileLLM दो आस-पास के Transformer blocks के Attention और FFN weights साझा करता है।

2. Layer-wise Parameter Scaling

   • इस तकनीक का प्रस्ताव और उपयोग OpenELM में किया गया था। पारंपरिक SLM, model की प्रत्येक Transformer layer के लिए समान configuration का उपयोग करते हैं, इसलिए layers के बीच parameters समान रूप से वितरित होते हैं। इसके विपरीत, OpenELM की प्रत्येक Transformer layer अलग configuration रखती है, जैसे heads की संख्या और FFN dimension, जिससे model की अलग-अलग layers में parameters की संख्या भी अलग हो सकती है। इसके ज़रिए OpenELM उपलब्ध parameter budget का बेहतर उपयोग कर अधिक accuracy हासिल कर सकता है।

3. Nonlinearity Compensation

   • PanGu-$\pi$ ने नवीनतम language models का विश्लेषण करके feature collapse problem को हल करने का प्रयास किया है। feature collapse problem उच्च-आयामी representation learning में उत्पन्न होने वाली समस्या है, जिसमें model विभिन्न inputs के लिए एक जैसे या बहुत मिलते-जुलते features सीख लेता है। PanGu-$\pi$ इस समस्या को हल करने के लिए GELU या ReLU जैसी activation functions की nonlinearity की भरपाई करने देता है, और layer output के परिमाण को scale करके output variation को स्थिर बनाए रखता है।

> #### मुख्य इनसाइट: SLM की मॉडल संरचना में 2 प्रमुख अवलोकन हैं:
> 1. अगस्त 2024 तक, सामान्य SLM आर्किटेक्चर GQA(Group-Query Attention), SiLU activation function का उपयोग करने वाला gated FFN(Gated FFN), 2~8 के बीच FFN expansion ratio(Intermediate Ratio of FFN), RMSNorm, और 50,000 से अधिक vocabulary size(Vocabulary Size) अपनाता है। हालांकि, ये सेटिंग्स मुख्य रूप से अनुभवजन्य(empirical) हैं, और इनका कठोर व सार्वजनिक सत्यापन नहीं हुआ है।
> 2. SLM में transformer संरचना को लेकर नवाचार सीमित हैं। Embedding-lm_head sharing तकनीक को छोड़कर, अन्य तकनीकों के Vanilla Transformer संरचना से बेहतर होने के मजबूत प्रमाण नहीं मिले हैं। साथ ही, इन्हें विभिन्न शोध समूहों या कंपनियों द्वारा व्यापक रूप से अपनाया या अध्ययन भी नहीं किया गया है, इसलिए आगे सत्यापन की आवश्यकता है.

प्रशिक्षण डेटासेट(Training Dataset)

SLM का प्रदर्शन प्रशिक्षण में उपयोग किए गए डेटासेट पर काफी निर्भर करता है। इस अध्ययन में SLM मॉडलों द्वारा उपयोग किए जाने वाले 12 सार्वजनिक डेटासेट देखे गए:

नाम	टोकन संख्या	मुख्य डोमेन	विवरण और उपयोग
The Pile	825B	विज्ञान, अकादमिक शोधपत्र, वेब टेक्स्ट, कानूनी दस्तावेज़	विभिन्न छोटे डेटासेटों को मिलाकर बनाया गया डेटासेट, जिसमें कई डोमेनों का टेक्स्ट शामिल है और जिसका उपयोग मॉडल की समग्र समझ क्षमता बेहतर करने के लिए किया जाता है.
FineWeb-Edu	1.3T/5.4T	शैक्षिक टेक्स्ट, पाठ्यपुस्तकें, शिक्षण सामग्री	FineWeb से फ़िल्टर किए गए शिक्षा-संबंधी टेक्स्ट से बना बड़ा डेटासेट, जिसका उद्देश्य learning और education domain से जुड़े कार्यों में मॉडल का प्रदर्शन बेहतर करना है.
StarCoder	35B	Python code	Python प्रोग्रामिंग भाषा में लिखे कोड वाला डेटासेट, जिसका उपयोग code generation और programming-संबंधित कार्यों के लिए मॉडल को प्रशिक्षित करने में होता है.
Cosmopedia	25B	synthetic text, शिक्षण सामग्री	synthetic text से बना डेटासेट, जिसमें पाठ्यपुस्तकें, blog posts, कहानियाँ, WikiHow लेख आदि शामिल हैं, ताकि मॉडल विभिन्न writing styles और contexts सीख सके.
RefinedWeb	5T	वेब दस्तावेज़, समाचार लेख, ब्लॉग, तकनीकी दस्तावेज़	CommonCrawl से निकाले गए उच्च-गुणवत्ता वाले वेब डेटा को सख्ती से फ़िल्टर कर बनाया गया डेटासेट, जिसका उपयोग NLP कार्यों में व्यापक domain knowledge सिखाने के लिए होता है.
RedPajama	1.2T	वेब डेटा, समाचार, social media	CommonCrawl snapshots से निकाला गया विशाल टेक्स्ट डेटा शामिल करता है, और web text-आधारित मॉडल प्रशिक्षण में उपयोग होता है.
Dolma	-	deduplicated English text	MinHash algorithm का उपयोग कर deduplicate किया गया English corpus, जिसका उपयोग दोहराए गए टेक्स्ट हटाकर परिष्कृत डेटा के माध्यम से मॉडल प्रदर्शन को optimize करने के लिए होता है.
WuDaoCorpora	4T	चीनी टेक्स्ट	चीनी डेटा पर आधारित विशाल corpus, जिसमें 3T tokens का training data और 1.08T चीनी characters शामिल हैं, और जिसका उपयोग Chinese language model training में होता है.
RoBERTa CCNewsV2	-	समाचार लेख	CommonCrawl के news dataset का updated version, जिसका उपयोग नवीनतम समाचार डेटा-आधारित NLP कार्यों में किया जाता है.
PushShift Reddit	-	social media data (Reddit posts)	Reddit डेटा को संग्रहित, विश्लेषित और संग्रहीत करने वाले प्लेटफ़ॉर्म से संकलित डेटा, जिसका उपयोग social media interaction और conversational language model training में किया जाता है.
DCLM-baseline	1.35T	वेब टेक्स्ट	Common Crawl से निकाला गया standardized corpus, जिसका उपयोग pretrained language models के लिए डेटासेट के रूप में होता है और जो विभिन्न evaluation tasks के लिए उपयुक्त है.
CulturaX	6.3T	बहुभाषी टेक्स्ट	167 भाषाओं से बना विशाल multilingual text dataset, जिसका उपयोग multilingual model training के लिए बड़े पैमाने की टेक्स्ट सामग्री के रूप में होता है.

2022 से 2024 तक अध्ययन में शामिल SLMs द्वारा pre-training डेटासेट के उपयोग की प्रवृत्ति इस प्रकार रही:

2022 और 2023 में सबसे व्यापक रूप से उपयोग किया गया pre-training डेटासेट The Pile था, लेकिन हाल के समय में अधिक डेटासेट प्रस्तावित किए गए हैं, जिससे विकल्पों की विविधता बढ़ी है। 2024 में आते-आते SLM के pre-training में The Pile डेटासेट अब उपयोग नहीं हो रहा है, और RefinedWeb या RedPajama जैसे डेटासेट धीरे-धीरे व्यापक रूप से अपनाए जा रहे हैं। यह दिखाता है कि बेहतर गुणवत्ता वाले pre-training डेटासेट बनाने के लिए research और engineering efforts सक्रिय रूप से जारी हैं.

इसके बाद, उपयोग किए गए pre-training डेटासेट के अनुसार SLM के प्रदर्शन को देखा गया। पिछले 3 वर्षों में जारी SLMs को parameter size के अनुसार 4 समूहों(<1B / 1B-1.4B / 1.5-2B / 2.5B-3B) में वर्गीकृत किया गया, और प्रत्येक समूह के भीतर average accuracy(commonsense reasoning/understanding और problem solving, इन दो प्रकार की accuracy का औसत) के आधार पर क्रमबद्ध करने पर परिणाम इस प्रकार हैं:

इन परिणामों से पता चलता है कि हाल ही में जारी दो डेटासेट, DCLM(DataComp-LM) और FineWeb-Edu, अन्य डेटासेटों की तुलना में बेहतर प्रदर्शन दिखाते हैं। इन दोनों डेटासेट की एक समान विशेषता यह है कि ये model-based data filtering अपनाते हैं.

इसके अलावा, भले ही coding capability device पर deploy किए जाने वाले SLM का मुख्य कार्य नहीं है, फिर भी StarCoder जैसे pre-training डेटासेटों में coding data अक्सर शामिल होता है। यह शायद इस सामान्य धारणा के कारण है कि coding data मॉडल की reasoning ability सुधारने में मदद कर सकता है.

इसके बाद pre-training में उपयोग किए गए tokens की संख्या और मॉडल आकार तथा pre-training में उपयोग किए गए tokens की संख्या और average accuracy को देखा गया.

पहले, मॉडल का आकार और प्रशिक्षण में उपयोग किए जाने वाले डेटा की मात्रा(tokens की संख्या) के बीच संबंध का अध्ययन करने वाले Chinchilla Law के अनुसार, मॉडल parameter size और training tokens की संख्या के बीच optimal ratio लगभग 20 होना चाहिए। उदाहरण के लिए, 1B मॉडल के लिए 20B tokens के पैमाने वाला training dataset आवश्यक माना जाता है.

2022 से 2024 तक जारी SLMs के आकार और training tokens की संख्या का सांख्यिकीय विश्लेषण(नीचे चित्र के बाएँ (a)) दिखाता है कि सामान्यतः मॉडल जितना बड़ा होता है, training में उपयोग किए गए tokens की संख्या उतनी अधिक होती है, और नए मॉडल अपेक्षाकृत अधिक training tokens का उपयोग करने की प्रवृत्ति रखते हैं। ध्यान देने योग्य बात यह है कि SLM, मॉडल आकार की परवाह किए बिना, Chinchilla Law द्वारा सुझाई गई मात्रा से कहीं अधिक tokens(सामान्यतः 1.5T से अधिक) पर प्रशिक्षित हो रहे हैं.

SLM द्वारा pre-training में उपयोग किए गए tokens की संख्या और average accuracy के विश्लेषण(नीचे चित्र के दाएँ (b)) से पता चलता है कि सामान्यतः इन दोनों संकेतकों में positive correlation है, और यह विशेष रूप से तब अधिक स्पष्ट है जब training tokens की संख्या 700B से कम हो। लेकिन जब training tokens 1T से अधिक हो जाते हैं, तब training data की quality, tokens की मात्रा की तुलना में अधिक महत्वपूर्ण हो जाती है, इसलिए यह correlation कमजोर दिखाई देता है.

> #### मुख्य अंतर्दृष्टि: SLM के training dataset में 2 प्रमुख अवलोकन हैं:
> - training data की गुणवत्ता SLM के प्रदर्शन के लिए बेहद महत्वपूर्ण है, और हाल के SLM शोध में इस पर लगातार अधिक ध्यान दिया जा रहा है। सामान्यतः, SLM पर data quality का प्रभाव data की मात्रा और model architecture की तुलना में अधिक बड़ा होता है। dataset शोध में एक उल्लेखनीय रुझान model-based filtering का उपयोग है, जिसके प्रमुख उदाहरण FineWeb-Edu(1.3T/5.4T) और DCLM-baseline(4T) हैं। इन दोनों datasets पर प्रशिक्षित SLM ने private datasets पर प्रशिक्षित SLM की तुलना में प्रतिस्पर्धी प्रदर्शन दिखाया।
> - हाल के SLM, model size की परवाह किए बिना, training के लिए बड़े पैमाने के tokens (आम तौर पर 1.5T या उससे अधिक) का उपयोग करते हैं। कुछ मामलों में कम मात्रा के data का भी उपयोग किया जाता है। (उदा. Qwen2-0.5B ने 12T tokens का उपयोग किया, जबकि Qwen2-1.5B ने केवल 7T tokens का उपयोग किया।) इसका मतलब है कि ये Chinchilla scaling law की तुलना में काफी अधिक "over-training" किए गए हैं, और इस तरह का over-training अधिक training time लगाकर बेहतर प्रदर्शन वाले SLM (powerful SLM) को deploy करने के लिए अपनाया जाता है.

प्रशिक्षण एल्गोरिद्म (Training Algorithm)

SLM training के लिए कई तरह के algorithms मौजूद हैं। प्रमुख training algorithms में Maximal Update Parameterization(μP), Knowledge Distillation, और Two Stage Pre-training रणनीति शामिल हैं.

1. Maximal Update Parameterization(μP): यह model initialization, layer-wise learning rate, activation magnitude आदि को नियंत्रित करके model layer width से स्वतंत्र रूप से स्थिर training सुनिश्चित करता है। यह तरीका training stability को बेहतर बनाता है, और छोटे models से बड़े models तक training hyperparameters की transferability भी सुधारता है, जिससे learning rate आदि को समान रखा जा सकता है। Cerebras-GPT अपने models को train करने के लिए इस तकनीक का उपयोग करता है.

2. Knowledge Distillation: यह Large Language Model (LLM) में व्यापक रूप से उपयोग किया जाने वाला एक concept है, जिसमें बड़े और जटिल teacher model से उपयोगी knowledge निकालकर उसे छोटे और अधिक efficient student model को सिखाया जाता है। यह Knowledge Distillation (KD) तकनीक दोनों models के outputs के बीच का अंतर कम करने के तरीके से काम करती है, ताकि student model teacher model के behavior और predictions को लगभग सीख सके। LaMini-GPT और Gemma-2 ने इस तकनीक का उपयोग किया है.

3. Two Stage Pre-training: जैसा कि नाम से स्पष्ट है, यह एक ऐसी training strategy है जिसमें model को दो अलग-अलग चरणों से गुजरते हुए train किया जाता है। पहले pretraining phase में बड़े पैमाने के low-quality data का उपयोग किया जाता है। इस प्रक्रिया में अधिक compute resources की आवश्यकता होती है। इसके बाद annealing phase में high-quality, task-specific SFT(Supervised Fine-Tuning) data को pretraining data के साथ मिलाकर उपयोग किया जाता है। MiniCPM इस तकनीक का उपयोग करता है.

SLM की क्षमताएं (Capabilities)

SLM evaluation datasets और metrics

इस अध्ययन में SLM की क्षमताओं का मूल्यांकन करने के लिए 12 datasets को 3 श्रेणियों—commonsense reasoning, problem-solving, और mathematics—में व्यवस्थित किया गया है:

नाम	प्रकार	विवरण और उपयोग
HellaSwag	commonsense reasoning	यह narrative understanding को test करता है और संभावित sentence completion का मूल्यांकन करता है.
TruthfulQA	commonsense reasoning	यह dataset इस बात का मूल्यांकन करता है कि model गलत जानकारी न दे.
Winogrande	commonsense reasoning	यह pronoun ambiguity resolution के माध्यम से commonsense reasoning क्षमता का मूल्यांकन करता है.
CommonsenseQA	commonsense reasoning	यह रोज़मर्रा के ज्ञान की मांग करने वाले multiple-choice questions से बने commonsense reasoning tasks प्रदान करता है.
PIQA	commonsense reasoning	यह physical commonsense reasoning और object interaction का मूल्यांकन करने वाला dataset है.
OpenBookQA	commonsense reasoning	इसमें ऐसे open-book science problems शामिल हैं जिन्हें scientific knowledge और commonsense को मिलाकर हल करना होता है.
BoolQ	commonsense reasoning	यह yes/no questions के माध्यम से commonsense और factual reasoning क्षमता का मूल्यांकन करता है.
ARC Easy	problem-solving	यह सामान्य ज्ञान और reasoning को test करने वाले सरल science problems वाला dataset है.
ARC Challenge	problem-solving	यह ऐसे जटिल science exam questions प्रदान करता है जिनमें knowledge integration की आवश्यकता होती है.
MMLU	problem-solving	यह विभिन्न शैक्षणिक क्षेत्रों में problem-solving क्षमता का मूल्यांकन करने वाला dataset है.
GSM8K	mathematics	यह elementary school स्तर की mathematical reasoning क्षमता का मूल्यांकन करने वाला dataset है.
Minerva Math	mathematics	यह विभिन्न विषयों में उन्नत mathematical reasoning क्षमता का मूल्यांकन करता है.

मूल्यांकन के दौरान मुख्य metric के रूप में Accuracy का उपयोग किया जाता है, जिसमें पूरे evaluation dataset की संख्या के मुकाबले सही predictions की संख्या का अनुपात निकाला जाता है। commonsense reasoning, problem-solving, और mathematics tasks में यह देखा जाता है कि सही उत्तर चुना गया या समाधान कितना सटीक दिया गया.

SLM का समग्र प्रदर्शन (Overall Capabilities)

commonsense reasoning, problem-solving, और mathematics—इन तीन tasks के लिए चुने गए SLMs पर experiments किए गए और प्रगति का विश्लेषण नीचे दिए गए चित्र की तरह किया गया। कुल मिलाकर, उल्लेखनीय performance improvement देखा गया, और विशेष रूप से प्रत्येक task में क्रमशः 10.4%, 13.5%, और 13.5% सुधार हुआ। इसके मुकाबले, open source Large Language Model LLaMA ने उसी अवधि में औसतन केवल 7.5% सुधार दिखाया:

विशेष रूप से, private datasets पर प्रशिक्षित Microsoft की Phi family ने 7B आकार के नवीनतम LLaMA 3.1 के समान स्तर का प्रदर्शन हासिल किया (commonsense reasoning में 67.6%, problem-solving में 72.4%), और इसने अन्य सभी models की तुलना में बेहतर प्रदर्शन दिखाया। हालांकि mathematics में अभी भी कुछ अंतर मौजूद है, लेकिन सामान्य reasoning के क्षेत्र में SLM और LLM के बीच का अंतर तेज़ी से कम हो रहा है। Qwen2 जैसे कुछ अपवाद मौजूद हैं, लेकिन सामान्य रूप से model size बढ़ने पर performance भी बेहतर होने की प्रवृत्ति दिखाई देती है.

कुछ अग्रणी SLM private datasets का उपयोग करके train किए गए हैं, लेकिन commonsense reasoning tasks में open source models और private models के बीच का अंतर धीरे-धीरे कम हो रहा है। उदाहरण के तौर पर, SmolLM और DCLM-1B, DCLM और FineWeb-Edu जैसे high-quality datasets की बदौलत commonsense reasoning में बहुत उत्कृष्ट प्रदर्शन करते हैं (क्रमशः 64.2% और 63.8%)। हालांकि, जटिल reasoning या logic की मांग करने वाले tasks, खासकर mathematics में, high-quality datasets की कमी के कारण अभी भी काफी बड़ा अंतर बना हुआ है.

मुख्य इनसाइट्स: SLM के विकास में 4 प्रमुख अवलोकन हैं:

• 2022 से 2024 तक SLM ने विभिन्न भाषा कार्यों में उल्लेखनीय प्रदर्शन सुधार दिखाया है। कुल मिलाकर इनमें बड़ा प्रदर्शन सुधार देखा गया, और यह (संस्करण 1/2/3/3.1 के) LLaMA-7B में हुए सुधारों से भी आगे निकलता है। ये परिणाम इस उम्मीद को मजबूत करते हैं कि On-Device पर विभिन्न Downstream Task हल किए जा सकते हैं।
• Phi मॉडल परिवार ने अधिकांश कार्यों में लगातार State-of-the-Art प्रदर्शन दिखाया है। सितंबर 2024 तक Phi-3-mini ने Llama-3.1-8B के बराबर सटीकता हासिल कर ली है। माना जाता है कि यह प्रदर्शन Microsoft की सावधानीपूर्वक data engineering का परिणाम है, लेकिन यह किसी विशेष dataset के लिए instructive tuning और संभावित overfitting के कारण भी हो सकता है।
• सामान्यतः मॉडल का आकार जितना बड़ा होता है, प्रदर्शन भी उतना बेहतर होता है, लेकिन Qwen2-1.5B जैसे अपवाद भी हैं। ऐसे अपवाद दिखाते हैं कि छोटे मॉडल भी कुछ विशेष कार्यों में उत्कृष्ट प्रदर्शन कर सकते हैं।
• commonsense reasoning के क्षेत्र में open source dataset पर प्रशिक्षित SLM, private SLM के साथ प्रदर्शन अंतर को कम कर रहे हैं। हालांकि, जटिल reasoning या logic की आवश्यकता वाले कार्यों में अब भी काफी अंतर मौजूद है, इसलिए mathematical reasoning पर केंद्रित dataset की आवश्यकता है.

In-Context Learning Capabilities

In-Context Learning (ICL), SLM की एक महत्वपूर्ण क्षमता है, जिसमें दिए गए input context के आधार पर नया कार्य किया जाता है। commonsense reasoning और problem solving सहित 8 कार्यों में विभिन्न मॉडलों और प्रत्येक मॉडल के 2B आकार वाले variants का उपयोग करके ICL क्षमता पर प्रयोग किए गए। सामान्यतः SLM सभी कार्यों में इससे महत्वपूर्ण लाभ प्राप्त कर सके। हालांकि, HellaSwag और PIQA जैसे सरल datasets में, अपवादस्वरूप ICL shots की संख्या से अलग लगभग समान प्रदर्शन देखा गया। इसके अलावा, औसतन 5 उदाहरणों (5-shots) के साथ किया गया in-context learning, सभी कार्यों में zero-shot प्रदर्शन को 2.1% तक सुधारता है।

विशेष रूप से Gemma2 मॉडल ने 4.8% accuracy वृद्धि के साथ सबसे बड़ा सुधार दिखाया। अपवादस्वरूप LaMini मॉडल में 2% से अधिक प्रदर्शन गिरावट देखी गई। इसके आधार पर यह परिकल्पना रखी गई कि LaMini अपने training dataset पर overfitting कर रहा है, इसलिए अतिरिक्त उदाहरण दिए जाने पर noise उत्पन्न हो सकता है।

सामान्यतः यह देखा गया कि SLM का मॉडल आकार बढ़ने के साथ उसकी in-context learning क्षमता भी बेहतर होती है।

मुख्य इनसाइट्स: SLM की in-context learning क्षमता में 2 प्रमुख अवलोकन हैं:

• सामान्यतः अधिकांश SLM में एक निश्चित स्तर की in-context learning क्षमता मौजूद होती है। लेकिन यह क्षमता कार्य के प्रकार के अनुसार अलग-अलग दिखाई देती है: अधिकांश SLM Arc Challenge कार्य में काफी सुधार दिखाते हैं, जबकि HellaSwag या PIQA जैसे मामलों में सुधार बहुत मामूली होता है।
• SLM का मॉडल आकार जितना बड़ा होता है, छोटे मॉडलों की तुलना में उसकी in-context learning क्षमता उतनी अधिक मजबूत होने की प्रवृत्ति दिखती है। LaMini जैसे कुछ छोटे पैमाने के SLM में in-context learning का उपयोग करने पर प्रदर्शन घटने की घटना भी देखी जाती है.

SLM की Runtime Cost

SLM की Runtime Cost में मॉडल को वास्तविक डिवाइस पर चलाते समय होने वाली latency और memory footprint शामिल होती है। यह अध्ययन SLM के runtime प्रदर्शन का मूल्यांकन करता है और विभिन्न hardware पर किए गए प्रयोगों के परिणामों का विश्लेषण करता है। साथ ही यह बताता है कि model architecture और quantization प्रदर्शन को कैसे प्रभावित करते हैं, और इसके माध्यम से यह समझाता है कि real-time environment में SLM को कैसे optimize किया जा सकता है।

Runtime cost मापने के लिए निम्न 2 प्रकार के edge devices का उपयोग किया गया। एक है Jetson Orin, जिसका उपयोग मुख्यतः drone या छोटे robot जैसे edge devices में किया जाता है, और दूसरा है smartphone, जिसे लोग दैनिक जीवन में मुख्य रूप से उपयोग करते हैं। ये इस प्रकार हैं:

डिवाइस नाम	हार्डवेयर प्रकार	सpecification
Jetson Orin NX 16GB	GPU	1024-core NVIDIA Ampere architecture GPU with 32 tensor cores, 16G DRAM
MEIZU 18Pro	CPU	Snapdragon 888, 8G RAM

इसके अलावा, चूंकि प्रत्येक मॉडल के आधिकारिक parameter count को मापने के तरीके अलग-अलग हैं, इसलिए लेखकों ने llama.cpp से प्राप्त parameter values का उपयोग किया। मापन को inference के समय prefill चरण और decode चरण में विभाजित किया गया, और अलग से उल्लेख न होने पर prompt length 50 तथा token generation length 50 निर्धारित की गई। साथ ही, thermal throttling से होने वाली प्रदर्शन गिरावट से बचने के लिए 10 सेकंड के अंतराल पर परीक्षण किए गए, और बड़े मॉडलों को मापने के लिए 4-bit quantization लागू किया गया।

• latency measurement: मॉडल के आकार के अनुसार पहले token के generation time (prefill) और उसके बाद प्रत्येक token के generation time (decode) को मापा जाता है।
• memory usage measurement: KV cache और memory buffer usage को मापकर यह विश्लेषण किया जाता है कि मॉडल कितनी memory घेरता है।

Runtime Cost Overview

इस अध्ययन में शामिल SLM के inference latency और memory footprint का सारांश इस प्रकार है:

• Inference Latency (अनुमान विलंब समय): SLM की inference latency, मॉडल के आकार के अनुसार तीन खंडों में विभाजित होती है: 0.1-1B, 1-2B, 2-3B। इन खंडों के भीतर प्रत्येक मॉडल समान प्रकार की latency दिखाता है। विशेष रूप से, मॉडल architecture का latency पर प्रभाव भी काफी महत्वपूर्ण है। उदाहरण के लिए, Qwen2-0.5B में समान आकार के अन्य मॉडलों की तुलना में पहले token का समय 1.46 गुना अधिक है, जबकि Qwen1.5-0.5B, उससे छोटे मॉडल OpenELM-1.1B के समान प्रदर्शन दिखाता है।

  • Prefill चरण: वह चरण जिसमें input prompt को process किया जाता है और KV cache बनाया जाता है, जहां कई token parallel में process होते हैं।
  • Decode चरण: वह चरण जिसमें उत्पन्न प्रत्येक token के आधार पर अगला token predict किया जाता है, और इसमें अधिक memory resources की आवश्यकता होती है।

• Memory Footprint (मेमोरी उपयोग): SLM की memory usage, मॉडल के आकार और context length के अनुसार बदलती है। विशेष रूप से Bloom-560M और Gemma-2B जैसे मॉडलों में बहुत बड़ा vocabulary size (256,000) होने के कारण अधिक memory उपयोग होती है। इसके विपरीत, OpenELM series, GQA(Group-Query Attention) का उपयोग करके KV cache का आकार कम करती है, जिससे memory usage की बचत होती है।

> #### मुख्य इनसाइट: SLM की रनिंग लागत में 3 प्रमुख अवलोकन हैं:
> - मॉडल के आकार के अलावा, मॉडल आर्किटेक्चर भी latency को प्रभावित करता है। उदाहरण के लिए, Qwen1.5-0.5B में Qwen2-0.5B की तुलना में 25.4% अधिक parameters हैं, लेकिन यह Jetson Orin पर 31.9% तेज़ चलता है। इसका मतलब है कि SLM विकसित करते समय उसे उस hardware के अनुसार अनुकूलित करना चाहिए जिस पर उसे deploy किया जाएगा।
> - inference speed पर मॉडल आर्किटेक्चर का प्रभाव decode चरण की तुलना में prefill चरण में अधिक दिखाई देता है। इसका कारण यह है कि prefill चरण की compute density अधिक होती है, जबकि decoding चरण मुख्यतः memory-bound होता है। मॉडल आर्किटेक्चर का अंतर compute-bound scenarios को अधिक सीधे प्रभावित कर सकता है। उदाहरण के लिए, अधिक चौड़े और उथले मॉडल में computational parallelism अधिक होती है।
> - रनटाइम memory usage आम तौर पर मॉडल के आकार के साथ linear correlation रखता है। हालांकि, जिन कुछ मॉडलों का vocabulary size बड़ा होता है, वे समान आकार के अन्य मॉडलों की तुलना में अधिक memory उपयोग करते हैं। उदाहरण के लिए, Bloom model family का vocabulary size 250,880 है, जो अधिकांश मॉडलों से लगभग 5 से 8 गुना बड़ा है.

क्वांटाइज़ेशन और हार्डवेयर का प्रभाव(Impact of Quantization and Hardware)

पहले, हमने पाँच quantization methods (Q8_0, Q6_K, Q5_K, Q4_K_M, Q3_K) और quantization से पहले के Phi-1.5 मॉडल (FP16) की latency मापकर यह देखा कि Quantization का SLM की रनिंग लागत पर क्या प्रभाव पड़ता है:

मोबाइल डिवाइसों में int8 operations के लिए पर्याप्त support नहीं हो सकता, फिर भी memory access overhead को प्रभावी ढंग से कम किया जा सकता है। ऐसा इसलिए है क्योंकि कम precision के कारण data compression होता है, जिससे cache utilization बेहतर होता है। हर method n-bit quantization का उपयोग करती है; Qn_K और Qn_K_M, k-quant method का उपयोग करके मध्यम स्तर के parameters वाले मॉडल को n-bit में quantize करते हैं, जबकि Qn_0 symmetric quantization को दर्शाता है.

Prefill चरण में quantization का प्रभाव यह है कि जब prompt length छोटी होती है, तो quantization latency को कम से कम 25% घटा देता है। लेकिन जैसे-जैसे prompt length बढ़ती है, यह प्रभाव घटता जाता है, और जब prompt length 50 के करीब पहुँचती है, तो Q6_K और Q3_K quantization methods unquantized FP16 मॉडल के समान या उससे भी अधिक latency दिखाती हैं। Q8_0, Q4_K_M, और Q5_K methods स्थिर performance improvement देती हैं, और खासकर Q4_K_M सबसे अच्छा प्रदर्शन दिखाती है, जो औसतन 50% latency reduction दिलाती है.

Decode चरण में quantization का प्रभाव अधिक consistent performance improvement दिखाता है, जहाँ latency अधिकतम 75% तक घटती है और न्यूनतम 17% की कमी देखी जाती है। साथ ही, Prefill चरण की तरह यहाँ भी Q4_K_M method सबसे प्रभावी है, जबकि Q6_K सबसे कम efficient है.

> #### मुख्य इनसाइट: SLM में quantization का रनिंग लागत पर प्रभाव लेकर 2 प्रमुख अवलोकन हैं:
> - quantization के लाभ prefill चरण की तुलना में decode चरण में अधिक स्पष्ट दिखाई देते हैं। मोबाइल डिवाइसों में quantization मुख्य रूप से memory access overhead को कम करता है। क्योंकि decode चरण memory bandwidth से अधिक प्रभावित होता है, जबकि prefill चरण compute से अधिक प्रभावित होता है, इसलिए quantization से decode चरण में अधिक लाभ मिलता है।
> - quantization precision जितनी अधिक regular होती है, performance उतनी बेहतर होती है। 3-bit quantization, 4-bit quantization की तुलना में अधिक compression ratio देती है, लेकिन 4-bit quantization prefill और decode दोनों चरणों में बेहतर performance देती है। 3-bit quantization का प्रदर्शन कम होने का कारण irregular bit-width के चलते hardware optimization support की कमी और data alignment & padding से उत्पन्न अतिरिक्त overhead है। इसलिए compression ratio कम होने के बावजूद 4-bit quantization अधिक efficient है; इसी तरह 5-bit और 6-bit quantization भी compression ratio में बेहतर होते हुए 8-bit quantization के समान या उससे अधिक inference latency दिखाते हैं.

इसके बाद, हमने Bloom-1B1 मॉडल को Jetson Orin NX 16GB (GPU उपयोग) और Meizu 18 Pro (CPU उपयोग) पर टेस्ट करके यह मापा कि hardware, SLM की रनिंग लागत को कैसे प्रभावित करता है:

Prefill चरण में, जब prompt length छोटी होती है, Jetson Orin, Meizu 18 Pro की तुलना में 10 से 20 गुना तेज़ प्रदर्शन दिखाता है। साथ ही, prompt length बढ़ने पर Jetson की performance advantage और अधिक स्पष्ट हो जाती है। जैसे-जैसे prompt लंबा होता है, दोनों डिवाइसों में पहला token generate करने में लगने वाला समय linear रूप से बढ़ता है, लेकिन Jetson लंबे prompts में भी स्थिर प्रदर्शन बनाए रखता है.

Decode चरण में, generated tokens की संख्या बढ़ने के साथ Meizu 18 Pro की per-token latency तेज़ी से बढ़ती है। खासकर पहले token से 10वें token के बीच latency में तेज़ उछाल आता है, और उसके बाद latency स्थिर हो जाती है। Meizu 18 Pro में latency की यह तेज़ बढ़ोतरी तापमान बढ़ने के कारण होती है, क्योंकि DVFS(Dynamic Voltage and Frequency Scaling) या Thermal Throttling, power consumption और frequency को समायोजित करते हुए computational efficiency को कम कर देते हैं। दूसरी ओर, Jetson अपने अधिक efficient cooling system की वजह से 30 tokens generate होने तक latency में कम बदलाव दिखाता है, और उसके बाद ही latency बढ़ती हुई देखी जाती है.

> #### मुख्य इनसाइट: hardware का SLM की रनिंग लागत पर प्रभाव लेकर 2 प्रमुख अवलोकन हैं:
> - decode चरण में tokens एक-एक करके sequentially generate होते हैं, जबकि prefill चरण में prompt के tokens को parallel process किया जा सकता है, इसलिए GPU पर यह कहीं अधिक तेज़ प्रदर्शन दिखाता है।
> - लंबे inference workloads में Jetson, smartphone की तुलना में बेहतर performance stability दिखाता है। इसका कारण यह है that Jetson का hardware structure अपेक्षाकृत सरल है, जिससे heat dissipation आसान हो जाती है.

latency और memory analysis का breakdown(Latency and Memory Breakdown)

latency को और बारीकी से विभाजित करते हुए, हमने Qwen1.5-0.5B और Qwen2-0.5B मॉडलों के लिए यह विश्लेषण किया कि प्रत्येक layer और operation कुल latency में कितना हिस्सा लेते हैं:

Qwen1.5-0.5B और Qwen2-0.5B मॉडल आकार में समान हैं, लेकिन latency में अंतर दिखाते हैं, और प्रत्येक मॉडल की latency के विस्तृत विश्लेषण के माध्यम से हमने मापा कि हर layer (Embedding, Attention, FFN, LM_Head) का समय-वितरण कैसा है.

Prefill चरण में, Qwen1.5 मॉडल में attention layer, FFN layer की तुलना में बड़ा हिस्सा लेती है। इसका कारण KV cache के आकार में वृद्धि है, जिससे attention layer में अधिक computation की आवश्यकता होती है। दूसरी ओर, Qwen2 मॉडल में FFN layer, attention layer से अधिक हिस्सा लेती है। ऐसा इसलिए है क्योंकि Qwen2 मॉडल में FFN layer अधिक चौड़ी है.

Decode चरण में, Qwen1.5 मॉडल में attention operations का अनुपात और बढ़ जाता है। इसका कारण यह है कि generated tokens पहले से generate किए गए tokens के साथ interact करते हैं, जिससे अधिक computation की ज़रूरत होती है, और KV cache का आकार बढ़ने पर यह प्रवृत्ति और स्पष्ट हो जाती है। Qwen2 मॉडल में अभी भी FFN layer सबसे अधिक समय लेती है, क्योंकि FFN की computation width अधिक होने से अधिक समय लगता है.

Operators का विश्लेषण करने पर, दोनों मॉडलों में सामान्य रूप से matrix-vector multiplication operation (mul_mat_vec_q) कुल computation time का 80% से अधिक हिस्सा लेता है। खासकर Qwen2-0.5B मॉडल में, FFN layer अधिक चौड़ी होने के कारण mul_mat_vec_q operation का हिस्सा और अधिक हो जाता है.

इसके अलावा, memory usage का विश्लेषण करने पर निम्नलिखित सामने आता है:

विश्लेषण के नतीजे इस बात पर ज़ोर देते हैं कि सिर्फ मॉडल का आकार ही नहीं, बल्कि vocabulary size भी memory usage पर बड़ा असर डालती है। मॉडल जितनी बड़ी vocabulary इस्तेमाल करता है, output layer में इस्तेमाल होने वाला Compute Buffer उतना ही बड़ा हो जाता है। उदाहरण के लिए, Bloom-560M मॉडल की vocabulary size 250,880 है, जिसके कारण उसके compute buffer का आकार 492MB तक पहुंचता है। यह vocabulary size 32,000 वाले OpenELM-1.1B की तुलना में 3.5 गुना अधिक memory इस्तेमाल करता है।

इसके अलावा, GQA(Group-Query Attention) इस्तेमाल करने वाले मॉडल, MHA(Multi-Head Attention) इस्तेमाल करने वाले मॉडलों की तुलना में छोटे KV Cache रखते हैं। उदाहरण के लिए, OpenELM-3B मॉडल का KV cache आकार 164MB है, जो StableLM-zephyr-3B मॉडल से लगभग 3.9 गुना छोटा है।

जब context length बढ़ती है, तो Compute Buffer और KV Cache मॉडल की memory usage के प्रमुख निर्धारक बन जाते हैं। Qwen2 मॉडल सीरीज़ में जब context length 131,072 तक पहुंचती है, तो Compute Buffer और KV Cache कुल memory usage का 83% से 87% हिस्सा लेते हैं। इसके विपरीत, Qwen1.5 मॉडल में अधिकतम context length 32,768 पर ये दोनों तत्व कुल memory का 85% से 90% तक लेते हैं।

इस विश्लेषण से साफ़ होता है कि vocabulary size और context length का SLM की memory usage पर स्पष्ट प्रभाव पड़ता है, और vocabulary जितनी बड़ी तथा context जितना लंबा होगा, memory usage उतनी ही तेजी से बढ़ेगी।

निष्कर्ष और भविष्य के शोध की दिशा

अब तक 100M से 5B तक के आकार वाले Small Language Models (SLM) पर व्यापक अध्ययन और performance measurement किए गए, तथा मॉडल के performance और execution cost आदि का मूल्यांकन किया गया। इसके आधार पर SLM की वर्तमान उपलब्धियों और सीमाओं का विश्लेषण किया गया है, और भविष्य में आवश्यक विभिन्न शोध विषय प्रस्तावित किए गए हैं:

• SLM architecture और processor का co-design और co-optimization (Co-design and co-optimizations of SLM architecture and device processors.): दिए गए model size के भीतर भी SLM का performance architecture configuration के अनुसार काफी बदल सकता है। उदाहरण के लिए, transformer की depth-width ratio, attention type, और activation function का execution speed पर बहुत बड़ा प्रभाव पड़ता है। खासकर, NPU(Neural Processing Unit) जैसे integer operation-optimized processors पर कुशलतापूर्वक चलाने के लिए SLM को quantize करने के तरीके महत्वपूर्ण हैं। accuracy और speed के बीच बेहतर trade-off पाने के लिए, specific hardware के अनुरूप architecture design और optimization आवश्यक हैं, और pre-training से पहले speed-optimized architecture खोजना एक संभावित दिशा हो सकती है।

• उच्च-गुणवत्ता synthetic dataset का निर्माण (Constructing high-quality synthetic dataset): हाल ही में जारी DCLM और FineWeb-Edu जैसे pre-training datasets ने SLM के performance को काफी बेहतर बनाया है। इन datasets का मुख्य innovation यह है कि बड़े corpus से high-quality data को filter करने के लिए pre-trained models का उपयोग किया जाता है। synthetic data पर शोध अभी शुरुआती चरण में है और इसमें काफी संभावनाएं हैं। data deduplication, filtering, mixing, और evaluation जैसी standardized synthetic data management process का निर्माण अत्यावश्यक है।

• device environment को ध्यान में रखते हुए Chinchilla law का विस्तार (A deployment-aware Chinchilla law for model scaling): Chinchilla law के अनुसार, model performance को optimize करने के लिए model size और training data size (token count) के बीच संतुलन, लगभग 1:20, ज़रूरी है। लेकिन SLM को सीमित device memory और compute capability के अनुरूप होना पड़ता है, इसलिए वे training data की मात्रा कहीं अधिक इस्तेमाल करने की प्रवृत्ति रखते हैं। यह तरीका एक हद तक प्रभावी है, लेकिन training data को अनंत तक scale नहीं किया जा सकता, इसलिए optimal data scaling method खोजना अब भी एक खुली समस्या है। इसके अलावा, data scale, training और inference cost के साथ-साथ SLM के lifecycle और economic benefits को भी ध्यान में रखना होगा, और MoE(Mixture-of-Experts) जैसी sparsity लागू होने पर यह समस्या और जटिल हो जाती है।

• personalization के लिए continual on-device learning (Continual on-device learning for personalization): जब SLM को device पर deploy किया जाता है, तो वह on-device data का उपयोग करके data leakage की चिंता के बिना बेहतर performance या personalization दे सकता है। इसके लिए पहला तरीका RAG(Retrieval-Augmented Generation) तकनीक का उपयोग करके prompt में personal data inject करना है। इस तरीके में text embedding generation और prompt processing time बढ़ जाता है, और personalization के लिए data को लंबे समय तक device पर stored रखना पड़ता है। दूसरा तरीका SLM को fine-tune करना है, जिसमें personalization के लिए आवश्यक knowledge को model weights में embed किया जा सकता है और fine-tuning के बाद data हटाया जा सकता है। हालांकि, on-device fine-tuning में memory और energy consumption अधिक होता है, जिससे गंभीर resource issues पैदा हो सकते हैं। zeroth-order optimization लागू करके memory में activation values को store किए बिना, inference चरण में hardware accelerator का उपयोग करने वाले तरीकों पर शोध किया जा सकता है।

• device और cloud पर SLM और LLM का collaboration (Device-cloud SLM-LLM collaboration): SLM की क्षमताएं तेज़ी से आगे बढ़ रही हैं, लेकिन cloud पर चलने वाले Large Language Models (LLM) के साथ अंतर अब भी मौजूद है। इसे दूर करने के लिए device और cloud का collaboration एक महत्वपूर्ण शोध विषय होगा। सहज रूप से, SLM उन tasks को संभाल सकता है जिन्हें device पर आसानी से हल किया जा सकता है, और cloud LLM जटिल tasks के लिए filter की भूमिका निभा सकता है। लेकिन इसके लिए ऐसा decision-making module चाहिए जो यह तय करे कि कौन-से tasks SLM संभाल सकता है और कौन-से नहीं। device और cloud के बीच उचित collaboration method खोजने के लिए आगे और शोध की आवश्यकता है।

• SLM performance evaluation में fairness का प्रश्न (Benchmarking SLMs fairly): SLM में खासकर GSM8k जैसे व्यापक रूप से इस्तेमाल होने वाले benchmark पर overfitting की समस्या है। इसके अलावा, कई SLM private datasets का उपयोग करके train किए जाते हैं, इसलिए उनके performance की निष्पक्ष तुलना करना कठिन होता है। SLM मुख्यतः on-device चलते हैं, इसलिए वे cloud environment की तुलना में अलग प्रकार के tasks करते हैं। smartphone पर deploy किए गए SLM अक्सर user data-sensitive tasks संभालते हैं, और ऐसे specialized ad-hoc tasks मौजूदा benchmarks में शामिल नहीं होते, जिससे वे महत्वपूर्ण evaluation criteria से बाहर रह सकते हैं।

• sparsity लागू करने वाले SLM (Sparse SLMs): फिलहाल SLM में sparsity लागू करने पर बहुत कम शोध हुआ है। इसका कारण यह है कि LLM की तुलना में SLM में अपेक्षाकृत कम sparsity level होने की उम्मीद है, जिससे sparsity-आधारित speedup या memory saving का लाभ सीमित हो सकता है। इसके अलावा, MoE(Mixture-of-Experts) जैसी sparsity-based architectures memory usage घटा सकती हैं, लेकिन computation complexity बढ़ा सकती हैं, इसलिए memory-constrained devices के लिए वे उपयुक्त न भी हों। smartphone की external storage (जैसे flash memory) का उपयोग करके fixed weights (Cold Weights) को store करके और ज़रूरत पड़ने पर load करके SLM को और scale किया जा सकता है, लेकिन ऐसे तरीकों में I/O latency जैसी समस्याओं के साथ heterogeneous hardware accelerators के साथ compatibility बनाए रखने जैसे मुद्दों पर अधिक शोध की आवश्यकता है।

Small Language Models पर व्यापक अध्ययन शोधपत्र: Small Language Models: Survey, Measurements, and Insights

https://arxiv.org/abs/2409.15790

परियोजना होमपेज

https://ubiquitouslearning.github.io/TinyLLMLeaderBoard/#/slm

GitHub रिपॉजिटरी

https://github.com/UbiquitousLearning/SLM_Survey

---

यह लेख GPT मॉडल से तैयार किए गए सारांश पर आधारित है, इसलिए संभव है कि इसमें मूल लेख की सामग्री या आशय से अलग तरीके से व्यवस्थित कुछ बातें हों। यदि विषय में आपकी रुचि है, तो कृपया मूल लेख भी साथ में देखें! पढ़ते समय यदि आपको कोई अटपटी या गलत बात दिखे, तो कृपया कमेंट में बताएं। 🤗

⚠️विज्ञापन⚠️: क्या 🔥PyTorch Korea User Group🇰🇷 द्वारा संकलित यह लेख आपके लिए उपयोगी रहा? सदस्य के रूप में जुड़ें, तो हम आपको प्रमुख लेख ईमेल💌 से भेजेंगे! (डिफ़ॉल्ट रूप से Weekly, लेकिन Daily में बदलना भी संभव है.)