Mixture-of-Experts (MoE) මොඩලයක් ඔබේ පරීක්ෂණ පරිසරයේ හොඳින් ක්රියා කරන්නේ, නමුත් නිෂ්පාදන පද්ධතියේදී ප්රතිඵල අඩු වීමක් පෙනේද? ඒකේ හේතුව බොහෝ විට capacity factor කියන අගයක්යි. මේ අගය නිශ්චිත ගණනක බෆර් එකක් සකසා, එක් එක් විශේෂඥ (expert) ට ටෝකන ගණන අධික වූ විට ඒ ටෝකන අහෝසි කරයි. අහෝසි වූ ටෝකන කිසිම දෝෂයක් නොදෙනවා – ඒවා එම ස්ථරයේ Feed‑Forward බ්ලොක් එක අත්හැරයි, ඉතිරි පථය පමණක් අනුගමනය කරයි.
MoE ස්ථරයක් තුළ එක් එක් විශේෂඥයෙකුට capacity = capacity_factor × tokens × top_k / num_experts ලෙස බෆර් එකක් දෙනවා. බෆර් පිරී ගොස් ඇත්නම්, ඉතිරි ටෝකන drop වෙයි. මේ නිසා එකම batch එකේ ටෝකන වාරිකය, batch size, සහ token‑වල පිහිටීම මත පදනම්ව ප්රතිඵල වෙනස් විය හැකිය.
ඇයි මේ ප්රශ්නය වැදගත්? MoE මොඩලය තුළ රවුටර් (router) එකට එකම විශේෂඥයට බොහෝ ටෝකන යැවීම “rich get richer” යන තත්වයට පත් කරයි. එමනිසා load imbalance එක සාමාන්ය තත්ත්වයක් වන අතර, අමතර loss (auxiliary loss) සහ router z‑loss වැනි පාලන ක්රමයන් ඒක සකස් කරයි. නමුත් ඒවා සකස් නොකළහොත්, නිෂ්පාදන පරිසරයේ token distribution එක වෙනස් වීමෙන් ගැටලු පැමිණේ.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ AI සංවර්ධකයින්, විද්යාල සිසුන්, සහ තාක්ෂණික ව්යාපාර සඳහා මෙය වැදගත් කරුණකි:
- සිසුන්ට – MoE මොඩලයක් උගන්වද්දී, capacity factor එකේ සැකසුම් නිවැරදිව තේරුම් ගැනීමෙන් පරික්ෂණ ප්රතිඵල හා නිෂ්පාදන ප්රදර්ශනය අතර ගැටලුවක් නොමැතිව ඉගෙන ගත හැක.
- ඩිවෙලපර්ස් – බෆර් අගය වැඩි කිරීම, dropless block‑sparse kernel (MegaBlocks) භාවිතය, හෝ DeepSeek‑V3 වැනි routing bias ක්රමය යොදා ගනිමින් පද්ධතියේ ගුණාත්මකතා බදු අඩු කරගත හැක.
- ව්යාපාර – නිෂ්පාදන පරිසරයේ token drop rate එක මොන ස්ථරයකද, කුමන විශේෂඥයකද නිරීක්ෂණය කිරීමෙන්, මොඩලයේ විශ්වාසනීයතාවය හා සේවා වේගය වැඩි කරගත හැක.
ඉතින්, MoE මොඩලයක් නිවැරදිව පවත්වා ගැනීමට, ප්රථමයෙන් capacity_factor අගය වැඩි කිරීම, පසුව dropless kernel එකකට මාරු වීම, සහ අවසානයේ ප්රතිඵල ලොග් කරමින් drop rate එක පරීක්ෂා කිරීම යන ක්රියාමාර්ග අනුගමනය කළ යුතුය.
මෙම සැලසුම් අනුගමනය කළහොත්, ඔබේ AI සේවා පද්ධතිය තදබල, වේගවත්, සහ නවීන තාක්ෂණික අවශ්යතා සපුරාලන ලෙස වැඩ කරනු ඇත.
