Көп түйінді DeepSeek орналастыруы арқылы төменірек кідіріс пен жоғарырақ өткізу қабілеті

Көпшілік жүйелерде кідіріс пен өткізу қабілеті жиі бір-біріне қайшы келетін мақсаттар болып табылады, олар жобалау және орналастыру кезінде ымыраға келуді талап етеді. Мысалы, тығыз үлкен тілдік модельдерде топтама өлшемін (batch size) ұлғайту өткізу қабілетін жақсартуы мүмкін, бірақ бұл кідірісті де арттырады; бір машина ішіндегі тензорлық параллелизмді (tensor parallelism) арттыру кідірісті азайтуы мүмкін, бірақ репликалар санын азайтып, өткізу қабілетінің төмендеуіне әкеледі.

DeepSeek-V3/R1 сияқты Сарапшылар қоспасы (Mixture of Experts - MoE) модельдері жақында тамаша модель мүмкіндіктері мен операциялық тиімділігін көрсетті. Мысалы, DeepSeek-V3/R1 моделі жалпы алғанда 671B параметрге ие, бірақ инференс кезінде әрбір токен тек 37B параметрді пайдаланады. Бұл модель архитектурасы инференс жүйелері үшін қиындықтар мен мүмкіндіктерді де ұсынады.

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

Орналастыру архитектуралары

Ұлғайту

Ұлғайту

Модельдегі шағын сарапшылардың көп болуына байланысты, орналастырулар бірнеше құрылғыларға таратылуы тиіс. Біз 8xH200 GPU бар бір түйіндегі бір түйінді орналастыруды да, 8xH100 GPU бар көп түйінді орналастыруларды да қарастырдық.

Екі орналастыру архитектурасы да біздің ішкі сұраныс диспетчері арқылы басқарылатын Деректер параллелизмін (Data Parallelism) пайдаланады. Деректер параллелизмін іске асыру әрқайсысы сұраныстарға қызмет көрсету және оларды сақтау үшін тәуелсіз жұмыс істейтін бірнеше инференс қозғалтқышының инстанстарын іске қосуды қамтиды. Қозғалтқышпен GRPC арқылы өзара әрекеттесетін сұраныс диспетчері сұраныстарды мүмкіндігінше біркелкі таратуға жауап береді, сонымен қатар KV қайта пайдалануды қамтамасыз етеді, ішінара сәйкес келетін префиксі бар сұраныстарды кэші бар серверлерге жібереді. Қозғалтқыш инстанстары бірнеше түйінді қамтымайды. Олар назар аударуды бірнеше құрылғылар арасында бөлу үшін қосымша тензорлық параллелизмді пайдалана алады. Инстанстар бір түйін жағдайында NVLink арқылы немесе көп түйін жағдайында InfiniBand арқылы сарапшыларды тарату және жинау арқылы өзара байланыстырылған.

Бір түйінді орналастыру конфигурациясы шағын топтама өлшемдерімен жоғары деңгейдегі кідірісті қамтамасыз етеді; алайда өнімділік жоғары жүктеме жағдайларында жылдам нашарлайды.

Қызмет көрсету қозғалтқышын орналастыру үшін біз бірнеше қозғалтқыш инстанстарын орналастыратын әр түйінгі бір под (pod) іске қосамыз. PyTorch бөлінген байланысты орнатуға және NVSHMEM инициализациясын келісуге жауап береді. Байланыс үшін біз бұрынғы блог жазбасында сипатталған реттелетін CUDA кернелдеріне сүйенеміз. Екі орналастыруды іске асыру мәні жағынан бірдей, модель сарапшылық параллелизмді іске асыратын фабрика негізінде пайдаланылатын дұрыс кернелдерді таңдайды.

Параллелизация әдістері

Өнімділікті салыстыруға кіріспес бұрын, DeepSeek-V3/R1 сияқты ауқымды MoE модельдерін орналастыруды мүмкіндік беретін негізгі параллелизация стратегияларын түсіну маңызды.

Тензорлық параллелизм

LLM инференсінде тензорлық параллелизм (TP) әдетте әр GPU-дағы жадты пайдалану мен есептеуді азайту, осылайша кідірісті азайту үшін қолданылады. Әдетте біз Назар аудару (Attention) және MLP қабаттарындағы Linear проекцияларын жол немесе баған өлшемдері бойынша бөліп, Назар аудару операцияларын назар аудару басының өлшемі бойынша бөле аламыз.

TP көмегімен Llama-3 архитектурасы GPU-лар арасында Linear проекциясы мен Назар аудару операциялары үшін дубликатталған есептеулерге ие емес, бұл – тамаша бөлу әдісі. Алайда DeepSeek-V3/R1 модельдерінде TP мұны жүзеге асыра алмайды.

DeepSeek-V3/R1 модельдері көп жасырын назар аударуды (Multi-Latent Attention - MLA) пайдаланады. MLA қабаты алдымен жасырын векторды есептеу үшін kv_a_proj Linear проекциясын пайдаланады, содан кейін оны әрбір назар аудару басының кеңістігіне түрлендіру үшін басқа kv_b_proj Linear проекциясын пайдаланады. Барлық назар аудару бастары бірдей жасырын векторды бөлісетіндықтан, TP жасырын векторды бөле алмайды, сондықтан барлық TP рангтері kv_a_proj және kv_b_proj параметрлері мен есептеулерін репликациялауы керек. Сол сияқты, MLA жасырын векторды KV кэшінде сақтайтындықтан, әрбір TP рангі KV кэшінің бірдей көшірмесін сақтайды.

MLA-да кейбір дубликаттардың болуына қарамастан, тензорлық параллелизм есептеу талаптарын ішінара азайтуды қамтамасыз етеді, бұл оны жоғары шығыс жылдамдығын талап ететін сценарийлер үшін құнды етеді.

Сарапшылық параллелизм

DeepSeek-V3/R1 модельдері MLP қабаттарын MoE қабаттарымен алмастырады. MoE қабатында 256 бағытталған сарапшы және бір ортақ сарапшы бар. Әрбір токен есептеу үшін 8 түрлі бағытталған сарапшыға жіберіледі және нәтижелер салмақты қосындыланады. Сондай-ақ әрбір токен ортақ сарапшыда есептеледі және нәтиже бағытталған сарапшылардан алынған нәтижеге қосылады.

Сарапшылық параллелизм (EP) MoE қабаттары үшін әдеттегі бөлу тәсілі ретінде қызмет етеді, мұнда әрбір GPU ортақ сарапшының көшірмесін сақтай отырып, 256 / EP бағытталған сарапшыны басқарады. TP-мен салыстырғанда EP артықшылығы – ол есептеулерді көбірек GPU арасында таратып, әр GPU-ға келетін есептеу және жад жүктемесін азайтады.

Сарапшылық есептеулерді орындамас бұрын, барлық GPU токендерді сәйкес сарапшылар орналасқан GPU-ларға жіберу үшін AllToAll байланысын орындауы керек; сарапшылық есептеулерден кейін әр түрлі GPU-лардан есептеу нәтижелерін жинау және салмақты қосындылауды орындау үшін тағы бір AllToAll байланысы қажет. Біз NVSHMEM көмегімен осы екі AllToAll байланыс кернелінің оңтайландырылған нұсқасын, яғни Dispatch және Combine кернелдерін іске асырдық. Біздің превдо-кодта немесе алдыңғы блог жазбамызда іске асырылуы егжей-тегжейлі сипатталған, ал біздің кернелдер GitHub желісінде ашық кодты ретінде жарияланған.

Деректер параллелизмі

EP көмегімен біз MoE есептеулерін 128 немесе одан да көп GPU арасында тарата аламыз. Алайда MLA есептеулерін EP арқылы бөлу мүмкін емес. Бұл тұста біз Деректер параллелизмін (DP) енгізе аламыз. Әрбір DP тобында MLA қабатының толық көшірмесі болады. Әрбір DP тобы әртүрлі кірістерді қабылдайды және MLA қабатының есептеулерін дербес орындайды.

MLA қабатының DP және TP біріктірілуі мүмкін, мұнда бір DP тобы бірнеше TP рангіне бөлінеді. MoE қабатының EP көрсеткішін MLA қабатының DP/TP топтарымен біріктіруге болады. EP = DP * TP. Мысалы, 16 машинада EP128 DP32 TP4 бағытталған сарапшыларды 128 GPU арасында таратуды білдіреді, мұнда әрбір 4 GPU бір DP тобын құрайды, нәтижесінде барлығы 32 тәуелсіз DP тобы болады.

Бір түйінді және көп түйінді салыстыру

DeepSeek моделінің 671B параметрі бір 8-GPU H100 машинасының жад сыйымдылығынан асады (80 ГБ * 8), бірақ бір 8-GPU H200 машинасы бүкіл модельді толығымен сыйғыза алады (141 ГБ * 8). EP8 DP8 TP1 конфигурациясын пайдаланған кезде модель әр GPU үшін шамамен 100 ГБ жадты пайдаланады, бұл KV кэші мен басқа аралық нәтижелер үшін шамамен 40 ГБ қалдырады. Бір токен KV кэшінің 70 272 байтын алады. Әрбір сұраныста 5000 токен бар деп есептесек, әр GPU шамамен 100 сұранысты сыйғыза алады.

Біз әртүрлі конфигурациялардағы бір түйінді және көп түйінді орналастырулардың өнімділік айырмашылықтарын түсінгіміз келді. Біз бір түйінді орналастыру үшін бір H200 машиналарын және көп түйінді орналастырулар үшін 16-ға дейін H100 машиналарын пайдаландық. Әрбір орналастыру ортасы үшін біз TP 1, 2, 4, 8 комбинацияларын және әр GPU үшін 1, 2, 4, 8, 16, 32, 64, 128 топтама өлшемдерін қолдандық. Әрбір сұраныстың KV кэш ұзындығы 5000 токен деп есептедік. Сондай-ақ көп токенді болжау (Multi-Token Prediction - MTP) қосымша 1 токенді болжайды деп болжадық (яғни әрбір сұраныстың сұрау ұзындығы 2) және қабылдау деңгейін сақтықпен 60% деп алдық. Төмендегі сурет әртүрлі конфигурациялар үшін өткізу қабілеті мен шығыс жылдамдығын көрсетеді.

Ұлғайту

Көлденең ось токен/с өлшеміндегі әрбір сұраныс үшін шығыс жылдамдығын білдіреді. Тік ось токен/с өлшеміндегі әр машина үшін өткізу қабілетін көрсету үшін логарифмдік шкаланы пайдаланады. Біз әрбір EP конфигурациясы үшін Парето шекарасын (Pareto Frontier) түрлі түсті сызықтармен белгіледік.

Шығыс жылдамдығына өте жоғары талаптар қойылатын сценарийлерде топтама өлшемі 1 болатын бір түйінді EP8 DP1 TP8 пайдалану 100 токен/с асатын шығыс жылдамдығына қол жеткізе алады, бірақ өткізу қабілеті өте төмен, бұл шығыс жылдамдығына тең. Бұл сценарийде бүкіл топтамада тек 2 токен бар, олар ең көбі 2*8=16 сарапшыға жіберіліп, жалпы алғанда ең көбі 57B параметрді іске қоса алады.

80-40 токен/с шығыс жылдамдығы диапазонында өткізу қабілеті артқан сайын шығыс жылдамдығы айтарлықтай төмендейді. Керісінше, EP128 бірдей шығыс жылдамдығында бір түйінді орналастыруға қарағанда шамамен 5 есе жоғары өткізу қабілетіне ие.

Бұл құбылысты бір түйінді орналастырулардың қалай жұмыс істейтінін зерттеу арқылы түсіндіруге болады: топтама өлшемін ұлғайту іске қосылған сарапшылардың көбеюіне тікелей әсер етеді. Топтама өлшемі 1 болған кезде, әр GPU үшін белсендірілген сарапшылардың орташа саны 2 * 8 / 8 = 2 құрайды. Топтама жеткілікті үлкен болған кезде, барлық сарапшылар іске қосылады, яғни әр GPU 256 / 8 = 32 сарапшыны іске қосады. Көбірек сарапшыларды іске қосу GPU жадтан көбірек параметрлерді оқуы қажет екенін білдіреді, бұл жад өткізу қабілетіне түсетін қысымды айтарлықтай арттырады. Үлкен тілдік модельдерді декодтау фазасы есептеу өнімділігімен емес, жад өткізу қабілетімен шектелетіндіктен, бір түйінді орналастыруда топтама өлшемін ұлғайту шығыс жылдамдығын айтарлықтай төмендетеді.

Төрт көп түйінді орналастыру конфигурациясын (EP16, EP32, EP64 және EP128) салыстыру жоғарырақ EP мәндері Парето шекарасын өткізу қабілеті мен шығыс жылдамдығын бір мезгілде жақсартуға қарай жылжытатынын көрсетеді.

EP мәнінің жоғары болуы әр GPU-ға азырақ сарапшылар бөлінетінін білдіреді. Мысалы, EP128 әр GPU 256 / 128 = 2 сарапшыға жауап беретінін білдіреді, сондықтан жад өткізу қабілетіне түсетін қысым айтарлықтай азаяды. Басқаша айтқанда, үлкенірек EP мәнін пайдалану арқылы біз тиімді түрде көбірек жад өткізу қабілетіне ие боламыз. Әр GPU үшін топтама өлшемі 64-тен аз болған кезде, топтама өлшемін ұлғайту сарапшылардың есептеу жылдамдығына айтарлықтай әсер етпейді, өйткені кірістер санын көбейту жад өткізу қабілетіне түсетін қысымды айтарлықтай арттырмайды. Сондықтан EP128 пайдаланған кезде топтама өлшемін ұлғайту шығыс жылдамдығына соншалықты қатты әсер етпейтінін көреміз.

Бір қызығы, үлкенірек топтама өлшемдерінде (әр GPU үшін 64 сұраныс) біз жаңа құбылысты байқадық: бір түйінді орналастырудың өткізу қабілеті көп түйінді орналастыруға қарағанда сәл жоғары. Мұның себептерінің бірі – түйіндік NVLink көп түйінді InfiniBand-қа қарағанда жоғарырақ өткізу қабілетіне ие. Тағы бір себебі – біздің іске асыруымыздағы шектеулер. Біз бұл құбылысты кейінірек толығырақ талдайтын боламыз.

Жад сыйымдылығының шектеулеріне байланысты EP8 DP8 TP1 конфигурациясы әр GPU үшін 128 топтама өлшеміне жете алмайды, сондықтан өткізу қабілеті жоғары сценарийлерде көп түйінді орналастыру әлі де жақсырақ таңдау болып табылады.

Есептеу мен байланысты қабаттастыру

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

Ұлғайту

Жоғарыдағы суреттің жоғарғы бөлігі бір қабаттың есептеу ағынын көрсетеді. MoE есептеуі Dispatch (Тарату) процесіне тәуелді, ал келесі қабаттың есептеуі Combine нәтижесіне тәуелді.

Біз ортақ сарапшыны әр GPU-ға орналастырамыз. Осылайша, ортақ сарапшының есептеуі AllToAll байланысын қажет етпейді. Сондықтан біз Dispatch Send орындалғаннан кейін бірден ортақ сарапшының есептеуін орындай аламыз, содан кейін Dispatch Recv аяқталуын күте аламыз. Біз бұл қабаттастыру схемасын "Dispatch Overlap" деп атаймыз.

Dispatch Overlap оңай іске асыруды және кең қолданыс аясын ұсынады. Бұл әдіс барлық EP өлшемдері мен топтама өлшемдерінде ортақ сарапшының есептеу уақытын жасырады.

Есептеу мен байланыстың қабаттасуын одан әрі арттыру үшін біз деректер тәуелділігін бұзу үшін DeepSeek техникалық есебінде аталған микро топтамаларды (micro batching) пайдаландық. Суреттің төменгі бөлігінде көрсетілгендей, біз бір Transformer қабатының есептеуін 5 сатыға бөлдік:

1-саты: InputNorm, QKVProj, AppendKV, BMM

2-саты: BMM, Attn, OProj, PostNorm, Gate

3-саты: Dispatch Send, Ортақ сарапшы (Shared Expert)

4-саты: Dispatch Recv, MoE, Combine Send

5-саты: Combine Recv

Алғашқы 3 тығыз (Dense) Transformer қабатында біз толық топтаманы пайдаланамыз. Келесі 58 MoE Transformer қабаттарында біз топтаманы екі микро топтамаға біркелкі бөлеміз. Екі микро топтама 3 сатылық ығысумен кезектесіп орындалады. Бұл екі микро топтама арасында деректер тәуелділігі болмағандықтан, біз Dispatch Send және Combine Send орындалғаннан кейін басқа микро топтаманың есептеуіне ауыса аламыз.

Кідірісті бөлу (Latency Breakdown)

Әрі қарай біз эксперимент арқылы қабаттастыру әсерлерін салыстырамыз, сондай-ақ EP8 бір түйінді орналастыру мен EP128 көп түйінді орналастырудың өнімділік айырмашылықтарын салыстырамыз. Салыстыруды жеңілдету үшін біз келесі эксперимент үшін H100 GPU пайдаландық. Біз TP1, әр GPU үшін 128 топтама өлшемін, әр сұраныс үшін 2 сұрау ұзындығын және 5000 KV кэш ұзындығын қолдандық.

Ұлғайту

Жоғарыдағы сурет бір MoE Transformer қабатына жұмсалған жалпы уақытты және кернелдердің әртүрлі түрлерінің кідіріс үлесін көрсетеді. Dispatch, Combine және GroupGEMM қоспағанда, басқа кернелдердің орындалу уақыты топтама өлшемі бірдей болғандықтан EP8, EP128 NoOverlap және EP128 DispatchOverlap серияларында бірдей болуы тиіс.

Қабаттастыру (Overlapping)

Алдымен үш қабаттастыру әдісінің әсерлерін салыстырайық. NoOverlap барлығы 2667µs, ал DispatchOverlap 2651µs уақыт алды, бұл 16µs немесе тек 0.6% үнемдеуді білдіреді. MicroBatch өте маңызды жақсартуды көрсетіп, 1896µs уақыт алды, бұл 29% жылдамдатуды қамтамасыз етеді. Dispatch пен Combine уақыты да айтарлықтай қысқарды. Dispatch 593µs-тан 367µs-қа дейін, ал Combine 1012µs-тан 237µs-қа дейін азайды.

Есептеу кернелдері үшін 128 өлшемді топтаманы 64 өлшемді екі топтамаға бөлу жалпы орындалу уақытын арттыратынын ескеріңіз. Сондықтан байланысқа жұмсалған уақыт 1001µs қысқарғанымен, жалпы уақыт тек 771µs азайды. Біз бұл себепті келесі бөлімде Roofline моделі арқылы түсіндіреміз.

Осы себепті микро топтамаға бөлу әрқашан өнімділікті жақсарта бермейді.

Ұлғайту

Жоғарыдағы сурет 4-128 топтама өлшемдері үшін DispatchOverlap-пен салыстырғанда Microbatch өнімділігінің жақсаруын көрсетеді. Топтама өлшемі 32-ден аз болған кезде, Microbatch өнімділікті 5%-40% төмендетеді. Топтама өлшемі 32-ден үлкен немесе оған тең болған кезде, Microbatch өнімділікті 10%-35% жақсарта алады.

EP8 пен EP128 салыстыруы

Алдыңғы суретке оралып, EP8 пен EP128 Microbatch нұсқаларын салыстырайық. EP8 барлығы 1802µs уақыт алды, бұл EP128-дің 1896µs мәнінен сәл аз. Жоғарыда аталған Microbatch әкелетін артқан кернел орындалу уақытынан басқа, негізгі айырмашылықтар MoE есептеулері үшін қолданылатын GroupGEMM және екі байланыс кернелінде, яғни Dispatch пен Combine-да жатыр.

EP8-дің GroupGEMM-і 555µs уақыт алды, ал EP128-дің GroupGEMM-і 270µs уақыт алып, екі есе азайды. Бұл – көп түйінді орналастырудың негізгі артықшылығы.

Өкінішке орай, байланысқа жұмсалған уақыт 213µs көбейді, бұл GroupGEMM артықшылығын айтарлықтай теңестірді. Байланыс кернелдерінің жеке өнімділік сынақтарында біз олардың Infiniband өткізу қабілетінің тек жартысына қол жеткізе алатынын анықтадық. Біз байланыс кернелдерін оңтайландыруды жалғастырамыз.

Айтарлықтай артта қалатын тағы бір кернел – GEMM. Microbatch GEMM уақытын 95µs көбейтті. Біз GEMM кернелін төмендегі Roofline бөлімінде тереңірек талдайтын боламыз. Біз қазіргі GEMM іске асырылуы әлі де оңтайлы өнімділікке қол жеткізген жоқ деп есептейміз.

Roofline моделі

Roofline моделі кернел өнімділігін талдау үшін жақсы құрал болып табылады. Оның көлденең осі Арифметикалық қарқындылықты, яғни FLOP-тың жад I/O байттарына қатынасын білдіреді. Көлденең ось мәні кернелдің семантикасынан тікелей есептелуі мүмкін. Тік ось қол жеткізілген өнімділікті білдіреді, ол FLOP-ты эталондық кідіріске бөлу арқылы есептеледі.

Кернел өнімділігінің теориялық жоғарғы шегі тікелей GPU сипаттамаларымен анықталады. H100-дің FP8 шыңындағы өнімділігі 1979 TFLOP/s құрайды, ол Roofline моделінде көлденең сызық ретінде көрсетілген. H100 жадының өткізу қабілеті 3.35 ТБ/с құрайды, ол бастапқы нүкте арқылы өтетін сызықтың көлбеуі ретінде көрсетілген. Бұл екі сызық сәйкесінше есептеулермен шектелген (compute-bound) және жадпен шектелген (memory-bound) кернелдер үшін өнімділік шектерін береді.

Төменде біз GroupGEMM және GEMM кернелдерінің өнімділігін талқылаймыз.

GroupGEMM

MoE-дегі GroupGEMM ядросы келесі есептеуді орындайды: Барлығы g топ бар, i-ші топта m_i токен бар, және [m_i, k] x [k, n] -> [m_i, n] матрицалық көбейтуі орындалады. Өнімділік тестілеуінде әр топтағы токендер саны бірдей деп ұйғарамыз, ол m_i = m деп белгіленеді. Сонда GroupGEMM үшін FLOP саны 2 * g * m * k * n, ал жад I/O байттары g * (m * k + n * k + m * n) болады.

DeepSeek-V3/R1 моделінде 256 сарапшы бар және әрбір токен есептеу үшін 8 сарапшыға жіберіледі. Топтама өлшемі 128, сұрау ұзындығы 2, EP128 DP128 конфигурациясын пайдалана отырып, әр сарапшы қабылдайтын токендердің орташа саны (яғни m) 128 * 2 * 8 * 128 / 256 = 1024 құрайды. Сол сияқты біз басқа конфигурациялар мен топтама өлшемдері үшін де m мәнін есептей аламыз.

Біз өнімділікті сынау үшін DeepGEMM GroupGEMM іске асырылуын пайдаландық. Сынақ нүктелері TP1 және 1-128 топтама өлшемдері бар EP8, EP16, EP32, EP64, EP128 конфигурацияларының комбинацияларын қамтыды.

Ұлғайту

Жоғарыдағы сурет әртүрлі EP конфигурациялары астындағы GroupGEMM үшін Roofline моделін көрсетеді. Әртүрлі EP әртүрлі топ сандарына сәйкес келеді. Суретте шамамен қабаттасатын өнімділік сызықтары көрсетілген, бұл GroupGEMM өнімділігі негізінен жалпы токендер санымен (g * m ретінде белгіленген) анықталатынын көрсетеді.

Жұлдызшалар әрбір EP конфигурациясы үшін әр GPU үшін 128 топтама өлшеміне сәйкес келетін деректер нүктелерін белгілейді. Осы жұлдызшалы деректер нүктелерін салыстыра отырып, EP артқан сайын (және DP синхронды түрде көбейген сайын) әр сарапшыға келетін токендер саны m де көбейетінін көре аламыз. EP8 кезінде m=128, ал EP128 кезінде m=2048 болады.

m мәні артқан сайын Арифметикалық қарқындылық та артады. Көптеген конфигурацияларда GroupGEMM жад өткізу қабілетімен шектеледі, сондықтан m мәнін ұлғайту өнімділікті жақсартады.

GEMM

GEMM кернелі модельдегі Q/K/V/O проекциясы сияқты Linear проекцияларына сәйкес келеді. [m, k] x [k, n] -> [m, n] матрицалық көбейтуі үшін FLOP саны 2 * m * k * n құрайды, ал жадтың I/O байттары m * k + n * k + m * n болады. Біз сондай-ақ 1-128 топтама өлшемдері үшін кідірісті сынақтан өткізе аламыз.

Ұлғайту

Жоғарыдағы сурет әртүрлі EP конфигурациялары астындағы GEMM үшін Roofline моделін көрсетеді. GEMM өнімділігі жад өткізу қабілетімен шектелетінін көре аламыз. Топтама өлшемі ұлғайған сайын Арифметикалық қарқындылық та артады, осылайша өнімділік жақсарады.

Микро топтама (Microbatch)

Микро топтамаға бөлуді пайдаланған кезде біз топтаманы екі бөлікке біркелкі бөлеміз. Жоғарыдағы екі суреттен m мәні m/2 болған кезде матрицалық көбейту тиімділігі төмендейтінін көре аламыз. Сондықтан m/2 өлшемді екі матрицалық көбейтуді орындау m өлшемді бір матрицалық көбейтуді орындағанға қарағанда көбірек уақыт алады.

Көп токенді болжау (Multi-Token Prediction)

Осы мақала бойы біз болжамды декодтау үшін Көп токенді болжауды (MTP) пайдалануды болжадық. MTP әр сұраныс үшін сұрау ұзындығын 1-ден 2-ге дейін өзгертеді. Матрицалық көбейту үшін бұл m мәнін m * 2 мәніне өзгертуге тең, осылайша матрицалық көбейту тиімділігін арттырады. Екінші жағынан, егер біз MLA үшін Roofline моделін салатын болсақ, сұрау ұзындығын ұлғайту MLA кернелінің тиімділігін айтарлықтай арттыратынын көрер едік.

Сондықтан MTP қолдану модель тиімділігінде маңызды рөл атқарады.

Іске асыру және оңтайландыру

Бұл бөлімде біз DeepSeek-V3/R1 моделі үшін кейбір іске асыру және оңтайландыру мәліметтерін таныстырамыз.

Кванттау (Quantization)

DeepSeek-V3/R1 блок бойынша кванттау схемасын қолдана отырып, FP8 форматында жергілікті түрде оқытылды, мұнда салмақтар статикалық түрде, ал активациялар динамикалық түрде квантталды. Арна немесе матрица үшін статикалық түрде масштабтау коэффициентін есептеудің орнына, масштабтау коэффициенттері активациялар үшін 128 элементті векторлар бойынша және матрицалар үшін 128x128 элементті плиткалар бойынша есептеледі, бұл кванттауға байланысты дәлдіктің нашарлауын шектейді.

Perplexity жүйесінде біз инференсті қолдау үшін CUDA және Triton кернелдерінің жиынтығына сүйенеміз, мұнда CUDA өнімділікке ең сезімтал және сирек өзгеретін кернелдер үшін (назар аудару және GEMM сияқты) қолданылады, ал Triton активациялардың, қалыптастырудың және утилиталық кернелдердің кең спектрін іске асырады. Triton кернелдерді блок бойынша кванттау схемасына тез бейімдеуге мүмкіндік берді.

Сызықтық және MoE қабаттары үшін біз Deep GEMM ядроларын өзіміздің Triton GEMM ядроларымен араластырып қолданамыз, өйткені белгілі бір матрица өлшемдері мен шағын batch өлшемдерінде Split-K кідірісті төменірек беретінін байқадық. Егер квантталмаған қабат (M, K) x (K, N) көбейтуді орындаса, онда блоктық кванттау үшін (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) масштабтау коэффициенті қажет болады. Блоктық кванттау кезінде активациялар үшін масштабтау коэффициенттері алдын ала калибрленудің орнына, орындалу барысында есептеледі. Активация масштабтау коэффициенттері тек K бойымен және M өлшемі бойымен емес жинақталатындықтан, бұл схеманы қолдау үшін ядроларға тек аздаған өзгерістер қажет.

Ұлғайту

DeepSeek-V3/R1 қолданатын SiLU активация функциясы CUDA графиктарын, блок бойынша кванттауды және динамикалық бағытталатын токен сандарын қолдау үшін айтарлықтай өзгерістерді талап етті. Блок бойынша кванттау көлденең қысқартуларды енгізгендіктен проблема тудыруы мүмкін, алайда кернел активацияларды олардың жасырын өлшемі бойынша 1024 элементтік блоктарға бөліп қойған болатын. Бір блок ішінде квантталатын тензор ең үлкен абсолютті мәнді есептеу үшін 128 блоктарға қосымша бөлінді, бұл ретте Triton минималды қосымша шығындармен тиімді cross-warp макс қысқартуларын генерациялады.

CUDA графиктары астында MoE бағыттауын қолдау үшін кернелдер токен сандарының жоғарғы шегін сақтау үшін бөлінген буферлердің өлшеміне негізделетін жұмысты жоспарлаудың орнына, әр сарапшыға келетін токендер санын көрсететін бағыттау ақпаратын білуі тиіс. Біз мәселені кіріс тензор өлшемдеріне сүйеніп бөле алмаймыз, сондықтан қанша токен толтырылғанын анықтау үшін бағыттау ақпаратын оқитын және активацияларды өңдеу жұмыстарын олардың арасында динамикалық түрде бөлетін тұрақты кернелдердің бекітілген санын іске қосамыз.

Біз өзіміздің кейбір кернелдерімізді FlashInfer жобасына енгіздік және болашақта кодымыздың көбірек бөлігін ашық кодты (open-source) жасайтын боламыз.

MLA қабаты

Біз MLA есептеулері үшін FlashInfer пайдаланамыз. FlashInfer икемді бет кестесінің (Page Table) параметрлерін және өте жоғары өнімділікті қолдайды.

Біз q_a_proj және kv_a_proj біріктіріп, біркелкі qkv_a_proj жасадық. Кідіріс 15.4 µs + 14.8 µs = 30.2 µs мәнінен 16.7 µs дейін азайды.

Біз kv_b_proj екі матрицаға, яғни k_b_proj және v_b_proj бөлдік. Осы екі матрицаға қатысты есептеулер үшін біз FP8 блокты квантталған BMM кернелін жаздық.

Cuda графигі (Cuda Graph)

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

AllToAll кернелін әзірлемес бұрын, біз AllToAll байланысы үшін torch.all_to_all_single() пайдаландық. Бұл операция барлық GPU-дан бірдей топтама өлшемін пайдалануды талап етеді. Алайда әртүрлі DP топтары әртүрлі топтама өлшемдерін іске қосуы мүмкін.

all_to_all_single() әртүрлі топтама өлшемдерін пайдаланатын әртүрлі DP топтарымен үйлесімді болуын қамтамасыз ету үшін біз алдымен барлық DP топтары арасындағы максималды топтама өлшемін алу үшін әрбір модель жұмысының алдында allreduce() операциясын пайдаландық. Содан кейін біз барлық DP топтарына осы топтама өлшемін пайдаланып жұмыс істеуді қамтамасыз еттік.

Бұл тәсіл Cuda графигін пайдалана алатынымызды қамтамасыз еткенімен, оның үш кемшілігі бар. Біріншіден, ол қосымша allreduce() операциясын талап етеді. Екіншіден, топтама өлшемдері кішірек DP топтары толтыруға (padding) мәжбүр болады. Үшіншіден, бұл біздің іске асыру кодымызды күрделі етеді.

Өзіміздің AllToAll кернелін іске қосқаннан кейін біз барлық GPU-дан бірдей топтама өлшемін пайдалануды талап етпейміз. Сондықтан бізге қосымша allreduce() операцияларын орындау немесе топтама өлшемдерін толтыру қажет емес.

MoE роутері (MoE Router)

MoE роутері Triton тілінде іске қосылған, ол сұрыпталған элементтердің индекстерін де қадағалайтын стандартты кітапханадан алынған өзгертілген сұрыптауға сүйенеді. Іске асыру барлық MoE модельдерінде ортақ болып табылады, өйткені Mixtral бағыттауы Top-K тобы барлық сарапшылар тобымен бірдей болатын DeepSeek бағыттауларының арнайы жағдайы болып табылады. Сирек кернелдер Top-K индекстері мен ұпайларын тікелей тұтынады, ал all-to-all байланысына сүйенетін тығыз Dispatch/Combine схемалары бағыттау ақпаратының токен негізінде емес, әр сарапшы бойынша жиналуын талап етеді.

Болашақ жұмыстар

Болашақ жұмыстарда біз DeepSeek моделінің өнімділігін одан әрі оңтайландыруды жоспарлап отырмыз.

Ең маңызды келесі оңтайландыру – Префиллді ажырату (Prefill Disaggregation). DeepSeek-V3/R1 моделінің Prefill (Префилл) фазасы мен Decode (Декодтау) фазасы верификациялық сипаттамалар мен есептеу сипаттамалары бойынша өте ерекшеленеді. Екеуі де әртүрлі оңтайландыру стратегиялары мен орналастыру схемаларын пайдалана алады.

MLA қабаты үшін Decode фазасында біз MLA есептеулерінің FLOP санын азайту үшін Матрицалық абсорбцияны (Matrix Absorption) пайдаланамыз. Prefill фазасында алдымен жасырын векторды K/V кеңістігіне жобалау және содан кейін Multi-Head Attention (MHA) пішімінде есептеу жақсырақ жұмыс істейді.

Егер Prefill және Decode бір GPU-да жұмыс істесе, Prefill-дің Decode шығыс жылдамдығына әсерін азайту үшін біз әдетте сұрауды Prefill үшін бірнеше кесектерге бөлу үшін бөлінген префиллді (chunked prefill) пайдаланамыз. KV кэші жасырын векторды сақтайтындықтан, MLA-ны MHA пішіміне түрлендіру қиынға соғады.

MoE қабаты үшін Decode фазасында біз әр сарапшыға келетін кіріс токендер санын арттыру үшін мүмкіндігінше үлкен EP және DP қолданамыз, осылайша GroupGEMM өнімділігін жақсартамыз. Prefill фазасында токендер саны қазірдің өзінде жеткілікті үлкен болғандықтан, GroupGEMM есептеулермен шектелген. Сондықтан Prefill үшін біз кішірек EP және DP пайдалана аламыз.

Егер Prefill және Decode бір GPU-да жұмыс істесе, кез келген DP тобы Prefill орындап жатқанша, барлық GPU-лардағы MoE қабаттарының кідірісі артады, бұл Decode шығыс жылдамдығына айтарлықтай әсер етеді.

Префиллді ажыратудан басқа, біз келесі аспектілерді де оңтайландыруды жоспарлап отырмыз:

AllToAll өнімділігі: Біздің AllToAll кернеліміз қазіргі уақытта Infiniband өткізу қабілетінің тек 1/3 бөлігіне қол жеткізе алады. Біз бұл кернелді оңтайландыруды жалғастырамыз.

EAGLE стиліндегі болжамды декодтау: Жоғарыдағы деректерде біз 1 токенді болжау үшін болжамды декодтауды қолдануды болжадық. EAGLE бірнеше токендерді болжау үшін ағаш құрылымын пайдалана алады, бұл қабылдау ұзындығын жақсартады, бұл шығыс жылдамдығын айтарлықтай арттыра алады.

GEMM кернелі: Бұрын көрсетілген Roofline моделінен біз GEMM кернелінің тиімділігі әлі де теориялық шектен алыс екенін көре аламыз. Біз бұл кернелді оңтайландыруды жалғастырамыз.

GB200 NVL72: NVIDIA-ның соңғы GB200 NVL72 шешімінде 72 Blackwell GPU жоғары жылдамдықты NVLink арқылы өзара байланыстырылған. MoE архитектурасының модельдері үшін бұл өте үлкен мүмкіндік пен сын-қатер болып табылады.

Қорытынды

DeepSeek MoE модельдерін көп түйінді орналастыру тығыз LLM көмегімен әдетте мүмкін емес нәрсеге қол жеткізеді: өткізу қабілеті мен кідірісті бір мезгілде жақсарту. Сарапшыларды көбірек GPU арасында тарату арқылы біз әр құрылғыға түсетін жад өткізу қабілетінің қысымын азайтамыз, бұл жылдамырақ өңдеуге және жоғары жүйелік өткізу қабілетіне мүмкіндік береді. Біздің эксперименттеріміз бір түйінді орналастырулармен салыстырғанда бірдей шығыс жылдамдығында 5 есеге дейін жоғары өткізу қабілетіне қол жеткізетін EP128 конфигурацияларын көрсетеді.

Микро топтамаға бөлу сияқты есептеу мен байланысты қабаттастыру әдістері көп түйінді байланыс шығындарын айтарлықтай азайтады, біздің іске асыруымыз 40%-ға дейін жылдамдатуды көрсетеді. Біздің реттелетін AllToAll байланыс кернелдері және оңтайландырылған кернелді іске асырулар 671B параметрлік моделін тиімді орналастыруға мүмкіндік берді.

MoE архитектуралары өз мүмкіндіктері үшін танымалдылыққа ие болған сайын, бұл орналастыру стратегиялары мұндай модельдерді тиімді масштабтау үшін құнды түсініктер береді.

Әдебиеттер тізімі

DeepSeek-V3 техникалық есебі

DeepSeek-V3/R1 инференс жүйесінің шолуы

Megatron-LM: Модель параллелизмін пайдалана отырып, көп миллиард параметрлі тілдік модельдерді оқыту

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

Дәйексөз

@online{perplexity2025LowerLatencyAndHigherThroughputWithMultiNodeDeepseekDeployment,
  author = {{Perplexity} and Lequn Chen and Nandor Licker and Erin McKnight},
  title = {{Lower latency and higher throughput with multi-node DeepSeek deployment}},
  date = {2025-04-18},
  url = {https://perplexity.coolkeypoint.com/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment}
}