एक मानक Transformer में, हर token हर layer में एक ही feedforward network (FFN) से गुज़रता है। एक MoE Transformer में, उस एकल FFN को कई समानांतर FFNs से बदल दिया जाता है — "experts" — और एक छोटा routing network (अक्सर gate कहा जाता है) जो तय करता है कि कौन से experts हर token को process करते हैं। आम तौर पर, gate top-k experts (आम तौर पर 2) का चयन करता है और gate के softmax weights का उपयोग करके उनके outputs को blend करता है। मुख्य अंतर्दृष्टि यह है कि कुल parameter count विशाल हो सकती है (मॉडल को memorize और सामान्यीकृत करने के लिए विशाल क्षमता देते हुए), जबकि प्रति-token compute manageable रहता है क्योंकि किसी भी दिए गए input के लिए अधिकांश experts idle हैं। Mixtral 8x7B, उदाहरण के लिए, लगभग 47B कुल parameters है लेकिन प्रति token केवल लगभग 13B सक्रिय करता है।
Routing mechanism वह जगह है जहाँ अधिकांश इंजीनियरिंग जटिलता रहती है। एक naive router सभी tokens को एक ही कुछ experts को भेज सकता है, अन्य को unused छोड़ते हुए — एक समस्या जिसे expert collapse कहा जाता है। इसे रोकने के लिए, MoE मॉडल auxiliary load-balancing losses का उपयोग करते हैं जो प्रशिक्षण के दौरान असमान expert utilization को penalize करते हैं। Google से मूल Switch Transformer ने top-1 routing (प्रति token एक expert) का उपयोग किया और प्रभावशाली scaling प्राप्त किया, लेकिन अधिकांश आधुनिक MoE मॉडल स्थिरता के लिए top-2 routing पसंद करते हैं। DeepSeekMoE जैसे कुछ नए दृष्टिकोण shared experts जोड़ते हैं जो routed वालों के साथ हमेशा सक्रिय होते हैं, routing निर्णयों की परवाह किए बिना हर token के लिए processing के एक baseline स्तर को सुनिश्चित करते हुए।
Trade-off जो MoE तैनाती को परिभाषित करता है वह memory बनाम compute है। भले ही प्रति token experts का एक अंश ही सक्रिय हो, उन सभी को memory में loaded किया जाना चाहिए। एक 8x7B MoE मॉडल को मोटे तौर पर एक dense 47B मॉडल के समान मेमोरी की आवश्यकता है, भले ही यह मोटे तौर पर एक 13B dense मॉडल की गति से चलता है। यह MoE मॉडलों को उपभोक्ता hardware के लिए awkward बनाता है — यदि आप अपने GPU VRAM में केवल 13B parameters fit कर सकते हैं, तो आपको MoE overhead के बिना एक dense 13B मॉडल से वही inference गति मिलेगी। MoE वास्तव में तब चमकता है जब आपके पास पूर्ण मॉडल को रखने के लिए पर्याप्त मेमोरी हो और आप अधिकतम quality प्रति FLOP चाहते हों। यही कारण है कि यह cloud serving के लिए एक प्राकृतिक fit है: OpenAI और Mistral जैसे providers अपने clusters पर पर्याप्त मेमोरी provision कर सकते हैं, और प्रति-request compute लागत वही है जो उनके margins को संचालित करती है।
Expert parallelism MoE के लिए विशिष्ट एक तैनाती pattern है। एक multi-GPU setup में, आप विभिन्न experts को विभिन्न GPUs पर रख सकते हैं ताकि हर device केवल experts का एक उपसमुच्चय रखे और गणना करे। Tokens को इस आधार पर GPUs में routed किया जाता है कि उन्हें कौन से experts चाहिए, processed होते हैं, और परिणाम वापस इकट्ठा होते हैं। यह all-to-all communication overhead पेश करता है लेकिन एक एकल device के लिए बहुत बड़े मॉडलों को कुशलतापूर्वक चलाने की अनुमति देता है। Google के GShard और Switch Transformer papers ने इसे scale पर प्रदर्शित किया, और यही है कैसे आज production में सबसे बड़े MoE मॉडल serve किए जाते हैं।
एक nuance जिसमें practitioners अक्सर भागते हैं: MoE मॉडल fine-tuning के दौरान unpredictably व्यवहार कर सकते हैं। यदि आप एक संकीर्ण domain पर fine-tune करते हैं, तो router सभी tokens को experts के एक छोटे उपसमुच्चय में funnelling शुरू कर सकता है, बाकी की क्षमता को प्रभावी रूप से बर्बाद करते हुए। कुछ टीमें fine-tuning के दौरान router को freeze करती हैं; अन्य अतिरिक्त regularization जोड़ती हैं। Quantization एक और gotcha है — experts जो कम सक्रिय होते हैं उनके पास कम calibration samples होते हैं, इसलिए naive post-training quantization उन्हें disproportionately degrade कर सकता है। क्षेत्र इन operational चुनौतियों के माध्यम से सक्रिय रूप से काम कर रहा है, लेकिन MoE स्पष्ट रूप से वह दिशा है जहाँ चीज़ें जा रही हैं। Grok, DBRX, Mixtral, और लगभग निश्चित रूप से GPT-4 सभी इसका उपयोग करते हैं, और दक्षता तर्क केवल मॉडल आकार बढ़ने पर मज़बूत होता जाता है।