MoE сарапшылары параллельдігі іске қосар алдында өлшеуді талап етеді

MoE-дегі сарапшылар параллельдігі іске қосар алдында өлшеуді талап етеді. Ол нашар маршрутизацияны түзетпейді және баяу түйінаралық желіні жылдам желіге айналдырмайды. Бұл тәсіл сарапшылардың салмағы мен есептеулерін көбірек GPU-ға таратады, сонымен бірге токендерді рангтер шекарасы арқылы тасымалдайды. Тек орташа throughput көрсеткішін өлшесеңіз, мәселені байқамай қалуыңыз мүмкін.

Сәтсіз іске қосу көбіне бірдей көрінеді: модель жадқа сыяды, демонстрациялық прогон өтеді, кейін production трафигі сұрау ұзындығы мен batch құрамын өзгертеді. Бір немесе бірнеше сарапшыға токендер шамадан тыс түседі, бір түйін алмасумен бітеледі, p99 өседі, ал capacity factor мәнін көтеру әрекеті OOM-мен аяқталады. Бұл сирек кездесетін шеткі жағдай емес. Іске қосар алдында сарапшылар санын тексеріп, әр токеннің жолын тексермегенде осындай нәтиже қалыпты.

Сарапшылар параллельдігі деп MoE қабатының сарапшылары EP тобындағы GPU-ларға бөлінетін схеманы айтамын. Трансформердің тығыз бөліктері өз параллельдік схемасы бойынша орындалады, ал роутер токенді бір немесе бірнеше сарапшыға бағыттайды. Жүйе dispatch жасайды, сарапшылардың MLP есептеуін орындайды және combine жасайды. Бюджетті есептегенде MLP-дің FLOPs көрсеткішін ғана емес, осы үш операцияның бәрін ескеру керек.

Алдымен жүктеменің жұмыс бірлігін бекітіңіз

MoE-ні сұраулар саны бойынша өлшеу мағынасыз. Роутер нақты қабаттағы нақты batch ішіндегі токендерді көреді, сондықтан жүктеменің жұмыс бірлігі кемінде белсенді токендер санын, sequence length, batch көлемін, top-k және prefill немесе decode режимін қамтуы керек.

Оқыту үшін белсенді токендерді әдетте былай көрсетуге болады:

T = micro_batch_size × sequence_length × число непустых позиций

Инференс үшін бұл жеткіліксіз. Prefill бір өтуде мыңдаған токен әкелуі мүмкін, ал decode кезінде әр sequence үшін бір жаңа токен ғана шығуы ықтимал. Бір минут ішінде есептелген batch-тің орташа көлемі екі түрлі режимді араластырады. «Типтік сұрау» бойынша бір өлшем ұзақ prefill-ден кейін қысқа интерактивті decode-ды жүйе көтере ме деген сұраққа жауап бермейді.

Кемінде төрт профиль жинаңыз:

• пайдаланушыға уәде етілген бір мезеттегі sequence саны бар қысқа decode;
• ұзындықтардың шынайы үлестірімі бар кәдімгі production prefill;
• рұқсат етілген контекст көлеміне жақын ұзақ prefill;
• жаңа қысқа сұраулар мен ұзақ жалғасып жатқан диалогтар қатар жүретін стресс-тестік аралас batch.

Бұл жиынтықты ұзындығы бірдей sequence-терден тұратын синтетикалық batch-пен алмастырмаңыз. Бірдей ұзындықтар ядроларды бастапқы тексеруге ыңғайлы, бірақ хабарлама көлемінің ауытқуын тегістеп, кезектерді жасырады. Іске қосу туралы шешім үшін кемінде тазартылған production сұрауларынан алынған replay немесе ұзындық, тіл, құжат түрлері және құрал шақыруларының үлестірімін сақтайтын жиынтық қажет.

Сәтті сұрау деп нені есептейтініңізді бөлек анықтаңыз. Егер қозғалтқыш сарапшы толып кеткенде токендерді тастаса, жылдам жауап жақсы жауап дегенді білдірмейді. Есепте latency, token drop rate және бекітілген бағалау жиынындағы сапа қатар көрсетілуі керек. Бұл көрсеткіштерді бір-бірінен бөлуге болмайды.

Сарапшылардың орташа жүктемесі көп нәрсені дәлелдемейді

Сарапшылар теңгерімін сарапшыға түскен токендердің әдемі орташа санымен емес, тағайындаулар үлестірімімен бағалайды. Қабатта E сарапшы бар делік, ал роутер top-k-ден кейін e сарапшысына n_e токенін тағайындады. Орташа мәні μ = Σn_e / E. Бұл тек ауқымды түсінуге жеткілікті. Тәуекелді бағалау үшін үлестірімнің жоғарғы бөлігін қарау керек.

Мен әдетте әр MoE қабаты үшін мына өрістерді талап етемін:

{
  "layer": 17,
  "active_tokens": 8192,
  "top_k": 2,
  "tokens_per_expert": [911, 844, 1003, 771],
  "expert_p50": 846,
  "expert_p95": 995,
  "expert_max": 1003,
  "expert_max_to_mean": 1.14,
  "top_5_percent_expert_share": 0.09,
  "dropped_tokens": 0
}

Нақты журналда бұл массивті әр сұрауда сақтаудың қажеті жоқ. Оны уақыт терезелері бойынша гистограммаға жинақтауға болады. Бірақ p95, p99, max/mean және ыстық сарапшылар трафигінің үлесі әр қабат бойынша қолжетімді болуы керек. Модель бойынша жалпы статистика p99-ды бүкіл сұрау үшін анықтайтын қабатты жасырады.

Бастапқы талдау үшін қарапайым шек пайдалы: тұрақты профильде max/mean бірден айтарлықтай жоғары болса, сізде теңгерімсіздік бар. Оның қаншалықты қолайлы екені capacity-ге, batch көлеміне және жад қорына байланысты. Әмбебап шек жоқ. Маңыздысы, ең жоғары жүктеме capacity-ге үнемі тірелмеуі және трафик үлгілері арасында көрініс күрт өзгермеуі керек.

Екі механизмді шатастырмаңыз. Auxiliary loss, jitter, stochastic routing және ұқсас тәсілдер роутерді оқыту кезіндегі теңгерімсіздікті азайтуға тырысады. Олар нақты production batch-те біркелкілікті кепілдемейді. Fine-tuning-тен немесе домен ауысқаннан кейін үлестірім өзгеруі мүмкін, тіпті оқыту журналы дұрыс көрінсе де. Сондықтан оқудан кейін бақылау жиынында өлшеу де, тірі трафикті бақылау да қажет.

DeepSpeed MoE құжаттамасы қабат нәтижесімен және auxiliary loss-пен бірге exp_counts қайтарады. Бұл дұрыс бастама, бірақ соңғы метрика емес. Тағайындаулар есептегіші токендерді кім алғанын көрсетеді. Ол сарапшы деректерді қанша уақыт күткенін, оның MLP-і қанша уақыт жұмыс істегенін және қай рангте кезек пайда болғанын көрсетпейді.

Сарапшы мен GPU әртүрлі деңгейде теңгерілуі мүмкін

Роутер токендерді сарапшылар арасында біркелкі бөліп, соған қарамастан бір GPU-ды артық жүктей алады. Бұл бір рангте бірнеше танымал сарапшы орналасқанда, сарапшылар үлестірімі желі топологиясына сәйкес келмегенде немесе әр сарапшының есептеу құны әртүрлі болғанда болады.

Екі матрицаны есептеңіз. Біріншісі, expert_load[layer, expert], сарапшылардың тағайындауларын көрсетеді. Екіншісі, rank_load[layer, rank], ранг иесіне тиесілі барлық сарапшылардың тағайындауларын қосады. Түйінаралық іске қосу үшін үшінші матрицаны, node_load[layer, node], қосыңыз. Ол GPU графигі жиі жасырып қалатын мәселені көрсетеді.

Сегіз GPU-да 64 сарапшы бар деп елестетіңіз. Әр сарапшы шамамен бірдей токен алады, бірақ 0-7 сарапшылары бір түйінде орналасқан және белгілі бір доменге байланысты маршрутизация көбіне соларды таңдайды. Әр сарапшы ішіндегі теңгерімсіздік орташа болуы мүмкін. Түйіндер арасында ол айқын болады: басқа түйіндер бір адреске көбірек активация жібереді, ал жауап combine кезінде сол жолмен кері қайтады.

Әр қабат үшін мыналарды тексеріңіз:

• токен мен сарапшы бір рангте орналасқан кездегі жергілікті тағайындаулар үлесі;
• әр ранг жіберген және қабылдаған байттар;
• ранг жұптары арасындағы хабарлама көлемінің p50 және p99 мәндері;
• ең көп жүктелген ранг пен орташа ранг арасындағы айырма;
• түйін шекарасынан өтетін трафик үлесі.

Көп команда тек all-to-all жалпы байттарына қарайды. Бұл кеш байқалатын метрика. Жалпы көлемі бірдей all-to-all әртүрлі жұмыс істеуі мүмкін: бір нұсқада жеткілікті ірі әрі біркелкі жіберілімдер болады, екіншісі ұсақ хабарламаларға және бірнеше артық жүктелген қабылдаушыға сүйенеді. Decode кезінде екінші жағдай жиі кездеседі.

Сарапшылардың орналасуын «ретімен жайғастырып, ұмыту» қағидасымен таңдамаңыз. Алдымен қай сарапшылардың бірге таңдалатынын және олардың токендері сұраулардың қай топтарынан келетінін өлшеңіз. Кейін сол деректерде бірнеше орналасуды тексеріңіз. Егер фреймворк орналасуды жеткілікті дәл басқаруға мүмкіндік бермесе, кемінде EP тобы инфрақұрылымдағы жылдам домен шекарасына сәйкес келетініне және баяу түйінаралық байланысты кездейсоқ кесіп өтпейтініне көз жеткізіңіз.

All-to-all есептеулерден бөлек профайлдануы керек

MoE-де токен алмасудан екі рет өтеді: алдымен сарапшы иесіне dispatch жасалады, кейін бастапқы рангке combine арқылы қайтарылады. Сондықтан MoE қабатының уақытын түгел GEMM-ге жатқызуға болмайды. Кемінде router, packing немесе permutation, dispatch, expert compute, combine және unpacking кезеңдеріне белгі қою керек.

Бір қабатқа арналған жазбаның ең қарапайым түрі мынадай болуы мүмкін:

{
  "layer": 17,
  "router_ms": 0.08,
  "pack_ms": 0.21,
  "dispatch_ms": 1.74,
  "expert_compute_ms": 1.12,
  "combine_ms": 1.58,
  "unpack_ms": 0.18,
  "remote_token_fraction": 0.76,
  "cross_node_bytes": 67108864
}

Өлшеуді дұрыс синхрондаңыз. Асинхронды GPU шақыруының айналасында CUDA оқиғаларынсыз немесе нақты синхрондаусыз CPU уақытын алсаңыз, операцияны кезекке қою уақытын өлшейсіз. Әр шағын операциядан кейін синхрондау қойсаңыз, алмасу мен есептеулердің қабаттасуын өзіңіз жоясыз. Профиль жеке бөліктердің ұзақтығын да, қабаттың критикалық жолын да көрсетуі керек.

Megatron Core құжаттамасы MoE үшін өнімділіктің үш негізгі шектеуін атайды: жад, коммуникация және есептеулер тиімділігі. Бұл пайдалы тұжырым, өйткені барлық мәселені бір баптаумен емдеуге болмайтынын көрсетеді. EP-ні ұлғайту жадты босатуы мүмкін, бірақ коммуникацияны арттырады. Grouped GEMM есептеу уақытын азайтуы мүмкін, бірақ dispatch теңгерімсіздігін түзетпейді. Агрессивтірек кванттау жад қысымын азайтуы мүмкін, бірақ желідегі ұсақ операциялар санын қысқартпайды.

Екі бақылау прогонын жасаңыз. Біріншісінде, іске асыру мүмкіндік берсе, сол модельді жергілікті сарапшылармен EP=1 күйінде іске қосыңыз. Екіншісінде мақсатты EP конфигурациясын қолданыңыз. Олардың айырмасы тек «желі құны» емес, өйткені GEMM пішіндері мен жад орналасуы да өзгереді. Дегенмен бұл баптауды жалғастыру қажет пе екенін тез көрсетеді. DeepSpeed AutoEP құжаттамасында expert parallel өлшемі 1 болғанда сарапшылар жергілікті болып қалатыны және бұл AllToAll-сыз тестілеуге жарайтыны тікелей көрсетілген.

Егер EP=1 жылдамырақ болып, жадқа сыйса, сарапшыларды тек тарату үшін таратудың қажеті жоқ. Егер EP=1 жадқа сыймаса, сізге желі керек пе деген пікірталас емес, оның нақты құнын есептеу қажет.

Capacity factor сапаны, жадты және кідіріс құйрығын өзгертеді

Capacity factor сарапшы бір өтуде қабылдай алатын токендер шегін белгілейді. Қарапайым түрде top-1 үшін сарапшы сыйымдылығы сарапшыға түсетін токендердің орташа саны мен capacity коэффициентінің көбейтіндісі ретінде есептеледі. Нақты формула мен дөңгелектеу қозғалтқышқа байланысты, сондықтан іске қоспас бұрын дәл өз іске асыруыңыздың кодын немесе құжаттамасын оқыңыз.

Бұл баптаудың жағымсыз қасиеті бар: ол таза өнімділік параметрі сияқты көрінеді, бірақ модель нәтижесін өзгертуі мүмкін. Сыйымдылық шектеулі болса, артық токендер іске асыруға қарай тасталады, қайта бағытталады немесе басқа тармақпен өңделеді. DeepSpeed құжаттамасында drop_tokens=false іс жүзінде шектелмеген сыйымдылықты білдіреді. Megatron Core құжаттамасында drop жоқ режим де, сыйымдылық шектеліп, артық токендер EP рангтері арасындағы алмасуға дейін тасталатын режим де сипатталған.

Бұл режимдер бірін-бірі алмастырмайды.

Drop жоқ режим барлық тағайындалған токендердің өңделуін сақтайды, бірақ динамикалық буферлердің үлкеюіне және ыстық сарапшыларда ұзақ кідіріс құйрығына әкелуі мүмкін. Шектелген сыйымдылық есептеу мен жадтың бір бөлігінің жоғарғы шегін бекітеді, бірақ токен жоғалту қаупін енгізеді. Capacity мәніне дейін padding жасау тағы бір ымыра қосады: тұрақты пішіндер кейбір ядроларға ыңғайлы, бірақ бос позициялар үшін ресурс төлейсіз.

Capacity factor-ды бір орташа мәнмен емес, бірнеше прогон арқылы тексеріңіз. Әр жүктеме профилі үшін мыналарды өлшеңіз:

1. қабат және top-1, top-2 маршруты бойынша token drop rate;
2. әр GPU-дағы peak allocated және peak reserved memory;
3. MoE қабаты уақытының p50, p95 және p99 мәндері;
4. модель жауаптары көрінетін жиындағы сапа өзгерісі;
5. сарапшылар жүктемесінің max/mean коэффициенті.

«Коэффициентті көтеріңіз, мәселе жоғалады» деген кеңес қате. Мәселе drop rate метрикасында жоғалып, memory headroom және p99 көрсеткіштерінде қайта пайда болуы мүмкін. Жоғары коэффициент ұзақ prefill кезінде жад қоры жеткілікті болып, теңгерімсіздік сирек кездесетіні расталғанда орынды. Ол роутер немесе сарапшылар орналасуын түзетуді алмастырмайды.

Оқыту мен serving үшін бір capacity factor-ды бөлек тексермей қолданбаңыз. Оқытуда кері өту және оптимизатор күйі бар. Serving кезінде batch пішіні басқа және кідіріс құйрығына талап қатаңырақ. DeepSpeed capacity_factor және eval_capacity_factor параметрлерін бөлек береді. Осы екі параметрдің болуының өзі режимдерді бір баптауға біріктірмеу керегін көрсетеді.

Жадты белсенді параметрлер саны бойынша емес, кезеңдер бойынша есептеңіз

«Бір токенде тек екі сарапшы белсенді» деген сөз есептеуді бағалауға пайдалы, бірақ жадты бағалауда қауіпті. GPU-да тығыз салмақтар, жергілікті сарапшылар салмағы, инференс кезіндегі KV cache, активациялар, dispatch буферлері, permutation уақытша тензорлары және коммуникация буферлері тұрады. Оқыту кезінде оларға градиенттер мен оптимизатор күйлері қосылады.

Әр ранг үшін максимумдарды төрт нүктеде бөлек түсіріңіз: MoE қабатына кірер алдында, packing-тен кейін, dispatch-тен кейін және expert compute-тен кейін. Максимум dispatch-тен кейін пайда болса, қабаттар санын азайту немесе тығыз салмақтардың бір бөлігін көшіру себепті жоймайды. Максимум expert compute ішінде пайда болса, сарапшылардың жергілікті жүктемесін, grouped matrix операцияларының көлемін және активациялар форматын қараңыз.

Сандарды профайлерден алсаңыз да, мына есептік парақ пайдалы:

память ранка = постоянные веса
             + KV cache или training states
             + активации плотной части
             + буферы dispatch и combine
             + временные тензоры MoE
             + резерв аллокатора

«Аллокатор қоры» дегенді түсіндірілмейтін қор ретінде жазбаңыз. Ол жүктеме тесті таза процесте өтіп, бір сағаттан кейін құлауына жиі себеп болады. Қысқа және ұзақ сұраулар кезектесетін ұзақ прогон фрагментацияны және жад шыңының тұрақтануын бақылау үшін қажет.

Сарапшылар ішіндегі tensor parallelism де тегін емес. Ол сарапшының MLP-і жадқа сыймаған кезде немесе матрицалары жеткілікті үлкен болғанда көмектесуі мүмкін, бірақ шағын сарапшы матрицаларын бөлу коммуникация қосып, есептеу пішінін нашарлатады. Megatron Core TP мен EP бірге қолданылғанда sequence parallelism талап етеді. Бұл сән үшін қойылатын жалауша емес: sequence-ті келісімді бөлмесеңіз, артық жад жұмсалады немесе активациялар қате алмасады.

Top-2 ыстық сарапшылардан қорғамайды

Top-2 routing-ті жиі дайын қорғаныс ретінде қабылдайды: бірінші сарапшы толса, жұмысты екіншісі алады. Іс жүзінде екінші маршруттың да үлестірімі, сыйымдылығы және желі құны бар. Оны бөлек өлшеу керек.

Үш есептегіш жинаңыз: екінші таңдау біріншіден өзгеше болатын токендер үлесі, екінші таңдаудың тағайындаулар үлестірімі және есептеуге жетпеген екінші тағайындаулар үлесі. Егер екінші таңдау үнемі сарапшылардың танымал тобына қайталанса, ол сол топқа түсетін қысымды тек екі еселейді. Егер ол үнемі қашықтағы сарапшыға барса, белсенді сарапшылар саны бойынша команда күткеннен де көп желі трафигін тудыруы мүмкін.

DeepSpeed MoE ішінде top-2 үшін екінші сарапшыны іріктеуді басқаратын top2_2nd_expert_sampling параметрі бар. Мұндай механизмдерді біреудің конфигурациясына қарап қоспаңыз немесе өшірмеңіз. Оларды бірдей сұраулар жиынында сапа, rank skew, drop rate және tail latency бойынша салыстырыңыз. Бір метрика жақсарғанда екіншісі нашарласа, қайсысы сервисіңізді шектейтінін білмейінше шешім шығару мүмкін емес.

Тағы бір айырманы жиі елемейді: роутер теңгерімсіздігі және орындау теңгерімсіздігі. Роутер тағайындауларды дерлік тең бөлуі мүмкін, бірақ жоспарлаушы немесе ядролар шағын сарапшы топтарын нашар орындауы ықтимал. Керісінше, жақсы grouped GEMM batch-тің жартысын бір сарапшыға жіберетін роутерді құтқармайды. Алдымен тағайындау есептегіштерін, кейін сарапшы топтарындағы есептеу уақытын қараңыз. Екі қабатты бір уақытта өзгертпеңіз, әйтпесе нәтиже берген өзгерісті анықтай алмайсыз.

Біркелкі емес трафиктегі деградацияны әдейі тексеріңіз

Біркелкі synthetic workload конфигурацияның ең жақсы жағдайда жұмыс істейтінін көрсетеді. Іске қосу кезінде басқа сұраққа жауап керек: роутер теңгерімсіз токен ағынын көргенде сервис қаншалықты баяулайды.

Бірнеше сұрау класынан тұратын қайталанатын тест жасаңыз. Мысалы, production трафигін техникалық құжаттарға, қысқа сұрауларға, ұзақ тарихы бар диалогтарға және құралдар қолданылатын сұрауларға бөліңіз. Алдымен кластарды бөлек, кейін нақты кезектегі үлесімен араластырып іске қосыңыз. Production трафигі болмаса, жиынды тақырып бойынша емес, қасиеттері бойынша құрыңыз: ұзындық, тіл, арнайы токендер үлесі, құрылымдалған мәтін тығыздығы және құрал шақыруларының саны.

Одан кейін бір ғана throughput саны емес, деградация қисығы керек. Конкуренттілікті біртіндеп көтеріп, әр қадамда end-to-end p99, MoE-layer time p99, рангтің ең жоғары жүктемесін, remote token fraction, drop rate және жад шыңын тіркеңіз. Орташа throughput дерлік өзгермей тұрғанда p99 өсетін нүкте ең жоғары әдемі throughput-тан маңыздырақ. Дәл сол жерде кезек теңгерімсіздікті жасыра бастайды.

Жақсы тест әдейі қолайсыз терезе жасайды: ұзақ prefill decode-пен қатар жүреді, сұраулардың ұзындығы әртүрлі болады, конкуренттілік мезгіл-мезгіл артады. Ең нашар сценарийде модель баяуырақ жұмыс істесе, оны бірден жарамсыз деп жариялаудың қажеті жоқ. Деградация көлемін, себебін және пайдаланушылар үшін қоятын шегіңізді білу керек.

API деңгейіндегі rate limit осы шекті ұстап тұруға көмектеседі, бірақ профильді алмастырмайды. AI Router-де кілт деңгейінде rate limits қолданып, аудит журналдарын алуға болады. Сондықтан production кезінде MoE деградациясын артық жеке деректерді сақтамай, трафиктің нақты класымен салыстыру ыңғайлы. Бұл іске қосқаннан кейін пайдалы, бірақ жүктеменің бастапқы шектерін алдын ала анықтау керек.

Дайындық чеклисті шешіммен аяқталуы керек

Іске қосар алдында командада профильдер сақталған бума емес, нақты жауаптары бар қысқа тізім болуы керек. Кез келген сұраққа «білмейміз» деген жауап берілсе, конфигурация мәлімделген жүктеме көлеміне әлі дайын емес.

• Біз қандай төрт жүктеме пішінін тексердік және олар нақты сұрауларға қаншалықты ұқсайды?
• Expert skew, rank skew және уақыт p99 ең жоғары болатын MoE қабаты қайсы?
• Түйінаралық токендердің үлесі қандай және қай түйіндер жұбы ең көп алмасу жасайды?
• Таңдалған capacity factor кезінде сапа мен drop rate қалай өзгереді?
• Ұзақ аралас прогонда әр GPU-да қанша жад қалады?

Бұған нақты шешімді қосыңыз: рұқсат етілген конкуренттілік, кіріс ұзындығының шегі, batch лимиті, capacity policy және p99 өскен кездегі әрекет. «Бақылаймыз» әрекет болып саналмайды. Нақты ауыстырып қосу тетігі керек: admission-ды азайту, batch-ті қысқарту, трафиктің бір бөлігін басқа модельге жіберу, тәуекелді маршрутизация режимін өшіру немесе конфигурацияны кері қайтару.

Сарапшылар параллельдігі модельге болжап болмайтын кідіріс құйрығынсыз қажетті сыйымдылық бергенде өзін ақтайды. Алдымен мұны токендер үлестірімі, all-to-all уақыты, әр рангтің жады және артық жүктеме кезіндегі сапа арқылы дәлелдеңіз. Осыдан кейін EP тобының көлемі болжам емес, команда жауап бере алатын параметрге айналады.