Minni daufþreyting og meiri afköst með DeepSeek uppsetningu á mörgum hnútum

Í flestum kerfum eru daufþreyting og afköst oft stefnur sem stangast á og krefjast málamiðlana við hönnun og uppsetningu. Til dæmis í þéttum stórum tungumálalíkönum getur stærð lotu bætt afköst en eykur einnig daufþreytingu; aukning á tensor-samsíðun innan einnar vélar getur dregið úr daufþreytingu en fækkar eintökum sem leiðir til minni afkasta.

Mixture of Experts (MoE) líkön eins og DeepSeek-V3/R1 hafa nýlega sýnt framúrskarandi eiginleika líkana og rekstrarhagkvæmni. Til dæmis hefur DeepSeek-V3/R1 líkanið alls 671B færibreytur en hvert tákn notar aðeins 37B færibreytur við ályktun. Þessi líkanarkitektúr býður upp á bæði áskoranir og tækifæri fyrir ályktunarkerfi.

Þessi grein sýnir fram á að þvert á hefðbundin kerfi geta MoE líkön eins og DeepSeek-V3/R1 náð bæði meiri afköstum og minni daufþreytingu á sama tíma þegar fleiri grafíkörgjafar eru notaðir við uppsetningar á mörgum hnútum í flestum tilfellum.

Uppsetningararkitektúrar

Stækka

Stækka

Vegna þess hve marga smá-sérfræðinga líkanið hefur verður að dreifa uppsetningum yfir margan búnað. Við skoðuðum bæði uppsetningar á einum hnút með 8xH200 grafíkörgjafum og uppsetningar á mörgum hnútum á 8xH100 grafíkörgjafum.

Báðir arkitektúrar uppsetningar nýta sér gagna-samsíðun sem stjórnað er í gegnum innri beiðnistýringu okkar. Útfærsla gagnasamsíðunar felur í sér ræsingu margra tilvika af ályktunarvél sem hvert um sig starfar sjálfstætt við að þjóna og viðhalda beiðnum. Beiðnistýringin sem hefur samskipti við vélina í gegnum GRPC ber ábyrgð á því að dreifa beiðnum eins jafnt og mögulegt er á meðan hún auðveldar einnig endurnotkun á KV-skyndiminni og sendir beiðnir með hluta af samsvörun í forskeyti á netþjónana sem innihalda skyndiminnið. Tilvik véla ná ekki yfir marga hnúta. Þau geta valkvætt nýtt tensor-samsíðun til að skipta athyglinni yfir á margan búnað. Tilvikin eru tengd saman í gegnum NVLink í tilviki eins hnúts eða InfiniBand fyrir tilvik margra hnúta sem senda út og safna saman sérfræðingum.

Uppsetningarstilling eins hnúts skilar yfirburða daufþreytingu með litlum lotustærðum; hins vegar versnar afköst hratt við auknar álagsskilyrði.

Til að setja upp þjónustuvélina ræsum við einum hólf (pod) á hvern hnút sem hýsir mörg tilvik véla. PyTorch sér um að setja upp dreifð samskipti og semja um frumstillingu NVSHMEM. Fyrir samskipti treystum við á sérsniðna CUDA-kjarna sem lýst er í fyrri bloggfærslu. Útfærsla þessara tveggja uppsetninga er nánast eins þar sem líkanið velur réttu kjarnana til að nota út frá efnisbúningi sem útfærir sérfræðinga-samsíðun.

Samsíðuvinnslutækni

Áður en farið er ofan í saumana á samanburði á afköstum er nauðsynlegt að skilja helstu samsíðunaraðferðir sem gera uppsetningu á stórum MoE líkönum eins og DeepSeek-V3/R1 mögulega.

Tensor-samsíðun

Við ályktun stórra tungumálalíkana er tensor-samsíðun (TP) venjulega notuð til að draga úr minnisnotkun og útreikningum á hvern grafíkörgjafa og þar með draga úr daufþreytingu. Venjulega getum við skipt línulegum vörpunum (Linear Projections) í athyglis- og MLP-lögum meðfram röðum eða dálkum og skipt athyglisaðgerðum meðfram stærð athyglisgaddar.

Með TP hefur Llama-3 arkitektúrinn enga tvítekenna útreikninga fyrir línulegar varpanir (Linear Projections) og athyglisaðgerðir þvert á grafíkörgjafa sem er tilvalin skiptingaraðferð. Hins vegar í DeepSeek-V3/R1 líkönum getur TP ekki náð þessu fram.

DeepSeek-V3/R1 líkön nota fjöl-dulinni athygli (Multi-Latent Attention - MLA). MLA-lag notar fyrst línulega vörpun kv_a_proj til að reikna út dulin vigur og notar síðan aðra línulega vörpun kv_b_proj til að umbreyta honum yfir í vinnusvæði hvers athyglisgaddar. Þar sem allir athyglisgaddar deila sama duldu vigrinum getur TP ekki skipt dula vigrinum þannig að öll TP-röð þurfa að endurtaka færibreytur og útreikninga á kv_a_proj og kv_b_proj. Á sama hátt þar sem MLA geymir dulin vigur í KV-skyndiminni geymir hver TP-röð eins eintak af KV-skyndiminninu.

Þrátt fyrir smá tvítekningu í MLA veitir tensor-samsíðun enn að hluta til lækkun á útreikningsþörf sem gerir það dýrmætt fyrir aðstæður sem krefjast mikils úttakshraða.

Sérfræðinga-samsíðun

DeepSeek-V3/R1 líkön skipta út MLP-lögum fyrir MoE-lög. MoE-lag hefur 256 beinda sérfræðinga og einn deildan sérfræðing. Hvert tákn er sent til 8 mismunandi beindra sérfræðinga til útreiknings og niðurstöðurnar eru vegnar saman. Hvert tákn reiknar einnig í deilda sérfræðingnum og niðurstöðunni er bætt við niðurstöðuna frá beindu sérfræðingunum.

Sérfræðinga-samsíðun (EP) þjónar sem dæmigerð skiptingaraðferð fyrir MoE-lög þar sem hver grafíkörgjafi stýrir 256 / EP beindum sérfræðingum á meðan hann heldur eintaki af deilda sérfræðingnum. Í samanburði við TP er kosturinn við EP sá að hún getur dreift útreikningum á fleiri grafíkörgjafa sem dregur úr útreikningum og minnisnotkun á hvern grafíkörgjafi.

Áður en útreikningar sérfræðinga eru framkvæmdir þurfa allir grafíkörgjafar að framkvæma AllToAll-samskipti til að senda tákn til þeirra grafíkörgjafa þar sem samsvarandi sérfræðingar eru staðsettir; eftir útreikninga sérfræðinga þarf önnur AllToAll-samskipti til að safna saman útreikningsniðurstöðum frá ýmsum grafíkörgjöfum og framkvæma vegna samlagningu. Við útfærðum fínstillta útgáfu af þessum tveimur AllToAll-samskiptakjörnum Dispatch og Combine með því að nota NVSHMEM. Í fyrri bloggfærslu okkar gerðum við grein fyrir útfærslunni og kjarnar okkar hafa verið opnaðir á GitHub.

Gagna-samsíðun

Með EP getum við dreift MoE-útreikningum yfir 128 eða jafnvel fleiri grafíkörgjafa. Hins vegar er ekki hægt að skipta MLA-útreikningum með EP. Á þessum punkti getum við kynnt til sögunnar gagna-samsíðun (DP). Hver DP-hópur er með fullkomið eintak af MLA-lagi. Hver DP-hópur samþykkir mismunandi inntök og framkvæmir útreikninga á MLA-lagi sjálfstætt.

Hægt er að sameina DP og TP í MLA-lagi þar sem einum DP-hópi er skipt í margar TP-raðir. Hægt er að sameina EP í MoE-lagi við DP/TP í MLA-lagi. EP = DP * TP. Til dæmis á 16 vélum þýðir EP128 DP32 TP4 að beindum sérfræðingum er dreift yfir 128 grafíkörgjafa þar sem hverjir 4 grafíkörgjafar mynduðu DP-hóp samtals 32 sjálfstæða DP-hópa.

Einn hnútur á móti mörgum hnútum

671B færibreytur DeepSeek fara yfir minnisgetu einnar 8-GPU H100 vélar (80 GB * 8) en ein 8-GPU H200 vél getur rúmað allt líkanið að fullu (141 GB * 8). Með því að nota EP8 DP8 TP1 stillinguna notar líkanið um 100 GB af minni á hvern grafíkörgjafa sem skilur eftir u.þ.b. 40 GB fyrir KV-skyndiminni og aðrar milliniðurstöður. Eitt tákn tekur upp 70.272 bæti af KV-skyndiminni. Gert er ráð fyrir að hver beiðni hafi 5.000 tákn og getur hver grafíkörgjafi rúmað um það bil 100 beiðnir.

Við vildum skilja afkastamuninn á milli uppsetninga á einum hnút og mörgum hnútum við mismunandi stillingar. Við notuðum eina H200 vél fyrir uppsetningu á einum hnút og allt að 16 H100 vélar fyrir uppsetningar á mörgum hnútum. Fyrir hvert uppsetningarumhverfi notuðum við samsetningar af TP 1, 2, 4, 8 og lotustærðum á hvern grafíkörgjafa 1, 2, 4, 8, 16, 32, 64, 128. Við gerðum ráð fyrir að hver beiðni hefði KV-skyndiminni lengd upp á 5.000 tákn. Við gerðum einnig ráð fyrir að Multi-Token Prediction (MTP) spái fyrir um 1 viðbótartákn (þ.e. fyrirspurnarlengd hverrar beiðni er 2) og gerðum varfærnislega ráð fyrir 60% samþykktirhlutfalli. Myndin hér að neðan sýnir afköst og úttakshraða fyrir mismunandi stillingar.

Stækka

Lóðrétti ásinn táknar úttakshraða á hverja beiðni í táknum/sek. Lóðrétti ásinn notar lógaritmískan skala til að sýna afköst á hverja vél í táknum/sek. Við merktum Pareto-mörkin fyrir hverja EP-stillingu með mismunandi lituðum línum.

Í aðstæðum með afar miklar kröfur um úttakshraða getur notkun á einum hnút EP8 DP1 TP8 með lotustærð 1 náð úttakshraða sem fer yfir 100 tákn/sek en afköstin eru afar lág sem jafngildir úttakshraðanum. Í þessari atburðarás hefur öll lotan aðeins 2 tákn sem hægt er að senda til í mesta lagi 2*8=16 sérfræðinga sem virkja samtals í mesta lagi 57B færibreytur.

Á bili úttakshraða frá 80 til 40 tákn/sek lækkar úttakshraði verulega eftir því sem afköst aukast. Aftur á móti hefur EP128 um það bil 5x meiri afköst en uppsetning á einum hnút við sama úttakshraða.

Hægt er að útskýra þetta fyrirbæri með því að skoða hvernig uppsetningar á einum hnút hegða sér: aukning á lotustærð tengist beint aukningu á virkjuðum sérfræðingum. Þegar lotustærðin er 1 er meðalfjöldi virkjaðra sérfræðinga á hvern grafíkörgjafa 2 * 8 / 8 = 2. Þegar lotan er nógu stór eru allir sérfræðingar virkjaðir sem þýðir að hver grafíkörgjafi virkjar 256 / 8 = 32 sérfræðinga. Að virkja fleiri sérfræðinga þýðir að grafíkörgjafinn þarf að lesa fleiri færibreytur úr minni sem eykur þrýsting á minnisbandbreidd verulega. Þar sem afkóðunaráfangi stórra tungumálalíkana er þegar takmarkaður af minnisbandbreidd frekar en útreikningsafköstum dregur aukning á lotustærð í uppsetningu á einum hnút verulega úr úttakshraða.

Samanburður á stillingum uppsetningar á mörgum hnútum (EP16, EP32, EP64 og EP128) leiðir í ljós að hærri EP-gildi færa Pareto-mörkin í átt að samtímis endurbótum á afköstum og úttakshraða.

Notkun hærri EP-tölu þýðir að hverjum grafíkörgjafa er úthlutað færri sérfræðingum. Til dæmis þýðir EP128 að hver grafíkörgjafi ber ábyrgð á 256 / 128 = 2 sérfræðingum þannig að þrýstingur á minnisbandbreidd minnkar verulega. Með öðrum orðum öðlumst við í raun meiri minnisbandbreidd með því að nota stærri EP-tölu. Þegar lotustærð á hvern grafíkörgjafa er minni en 64 hefur aukning á lotustærð ekki veruleg áhrif á útreikningshraða sérfræðinga vegna þess að aukning á fjölda inntaka eykur ekki þrýsting á minnisbandbreidd verulega. Þess vegna tökum við eftir því að þegar EP128 er notað hefur aukning á lotustærð ekki jafn mikil áhrif á úttakshraða.

Áhugavert nokk á stærri lotustærðum (64 beiðnir á hvern grafíkörgjafa) tókum við eftir nýju fyrirbæri: afköst uppsetningar á einum hnút eru örlítið meiri en í uppsetningu á mörgum hnútum. Hluti af ástæðunni er sá að NVLink innan hnúts hefur meiri bandbreidd en InfiniBand á milli hnúta. Annar hluti stafar af takmörkunum í útfærslu okkar. Við munum greina þetta fyrirbæri nánar síðar.

Vegna takmarkana á minnisgetu getur EP8 DP8 TP1 stillingin ekki náð lotustærð 128 á hvern grafíkörgjafa þannig að uppsetning á mörgum hnútum er enn betri valkostur við aðstæður sem sækjast eftir meiri afköstum.

Skörun útreikninga og samskipta

Eins og stuttlega var kynnt hér að ofan varðandi sérfræðinga-samsíðun eru grafíkörgjafar aðgerðalausir meðan á samskiptum í MoE-lagi stendur. Til að draga úr sóun og lækka daufþreytingu þurfum við að finna gagnaóháð útreikningsverkefni til að fylla þennan aðgerðalausa tíma.

Stækka

Efri hluti myndarinnar hér að ofan sýnir útreikningsflæði eins lags. MoE-útreikningar eru háðir Dispatch og útreikningar næsta lags eru háðir niðurstöðu Combine.

Við setjum deilda sérfræðinginn á hvern grafíkörgjafa. Á þennan hátt krefst útreikningur deilda sérfræðingsins ekki AllToAll-samskipta. Þess vegna getum við framkvæmt útreikning deilda sérfræðingsins strax eftir Dispatch Send og bíðum síðan eftir að Dispatch Recv ljúki. Við köllum þetta skörunarskipulag „Dispatch Overlap“.

Dispatch Overlap býður upp á einfalda útfærslu og víðtæka notagildi. Þessi tækni felur útreikningstíma deilda sérfræðingsins þvert á allar EP-stærðir og lotustærðir.

Til að auka skörun útreikninga og samskipta enn frekar notuðum við ör-lotu-gerð (micro batching) sem nefnd er í tækniskýrslu DeepSeek til að rjófa gagnaháð. Eins og sýnt er í neðri hluta myndarinnar skiptum við útreikningi eins Transformer-lags í 5 stig:

Stig 1: InputNorm, QKVProj, AppendKV, BMM

Stig 2: BMM, Attn, OProj, PostNorm, Gate

Stig 3: Dispatch Send, Shared Expert

Stig 4: Dispatch Recv, MoE, Combine Send

Stig 5: Combine Recv

Í fyrstu 3 þéttu Transformer-lögunum notum við alla lotuna. Í næstu 58 MoE Transformer-lögunum skiptum við lotunni jafnt í tvær ör-lotur. Ör-loturnar tvær keyra til skiptis með 3 stiga föruneyti. Þar sem engin gagnaháð er á milli þessara tveggja ör-lota getum við skipt yfir í útreikning annarrar ör-lotu eftir Dispatch Send og eftir Combine Send.

Sundurliðun á daufþreytingu

Næst berum við saman áhrif skörunar með tilraun ásamt því að bera saman afkastamun á milli uppsetningar á einum hnút EP8 og uppsetningar á mörgum hnútum EP128. Til hægðarauka við samanburð notuðum við H100 grafíkörgjafa fyrir eftirfarandi tilraun. Við notuðum TP1, lotustærð 128 á hvern grafíkörgjafa, fyrirspurnarlengd 2 á hverja beiðni og KV-skyndiminni lengd 5000.

Stækka

Myndin hér að ofan sýnir heildartíma sem fer í eitt MoE Transformer-lag og hlutfall daufþreytingar fyrir mismunandi gerðir kjarna. Að undanskildum Dispatch, Combine og GroupGEMM ætti keyrslutími annarra kjarna að vera jafn í EP8, EP128 NoOverlap og EP128 DispatchOverlap röðunum vegna þess að lotustærðin er sú sama.

Skörun

Við skulum fyrst bera saman áhrif þessara þriggja skörunaraðferða. NoOverlap tók 2667µs samtals, DispatchOverlap tók 2651µs sem sparar 16µs eða aðeins 0,6%. MicroBatch sýndi mjög verulega batnkun og tók 1896µs sem er 29% hraðauki. Bæði Dispatch og Combine tími minnkuðu verulega. Dispatch fór úr 593µs í 367µs og Combine úr 1012µs í 237µs.

Athugaðu að fyrir útreikningskjarna eykur það heildarkeyrslutímann að skipta lotu stærðar 128 í tvær lotur stærðar 64. Þess vegna þrátt fyrir að tíminn sem fór í samskipti minnkaði um 1001µs minnkaði heildartíminn aðeins um 771µs. Við munum útskýra ástæðuna með því að nota Roofline-líkanið í eftirfarandi kafla.

Af þessari ástæðu bætir ör-lotugerð (microbatching) ekki alltaf afköst.

Stækka

Myndin hér að ofan sýnir afkastabætingu Microbatch í samanburði við DispatchOverlap fyrir lotustærðir 4-128. Þegar lotustærðin er minni en 32 minnkar Microbatch afköst um 5%-40%. Þegar lotustærðin er stærri en eða jöfn 32 getur Microbatch bætt afköst um 10%-35%.

EP8 á móti EP128

Við skulum snúa aftur að fyrri mynd og bera saman EP8 og EP128 Microbatch. EP8 tók 1802µs samtals sem er örlítið minna en 1896µs hjá EP128. Auk aukins keyrslutíma kjarna sem stafar af Microbatch sem nefndur var hér að ofan eru helstu munirnir í GroupGEMM sem notaður er til MoE-útreikninga og tveimur samskiptakjörnum Dispatch og Combine.

GroupGEMM hjá EP8 tók 555µs á meðan GroupGEMM hjá EP128 tók 270µs sem er helmingun. Þetta er kjarnakostur uppsetningar á mörgum hnútum.

Því miður jókst tíminn sem fór í samskipti um 213µs sem vó þungt upp á móti kosti GroupGEMM. Í sérstökum afkastaprófum á samskiptakjörnum okkar komust að því að þeir geta aðeins náð helmingi af Infiniband bandbreiddinni. Við munum halda áfram að fínstilla samskiptakjarna okkar.

Annar kjarni sem dregst verulega aftur úr er GEMM. Microbatch jók GEMM um 95µs. Við munum greina GEMM dýpra í Roofline-kaflanum hér að neðan. Við teljum að núverandi útfærsla á GEMM hafi ekki enn náð kjriafköstum.

Roofline

Roofline-líkanið er gott tól til að greina afköst kjarna. Lóðrétti ás þess er reiknilegur styrkur (Arithmetic Intensity) sem er hlutfall FLOP og minnis I/O bæta. Hægt er að reikna gildi lárétta ásins beint út frá mælikvarða kjarnans. Lóðrétti ásinn táknar náð afköst sem reiknuð eru með því að deila FLOP með daufþreytingu viðmiðunarprófs.

Fræðileg efri mörk afkasta kjarna eru beint ákvörðuð af forskriftum grafíkörgjafans. Hámarksafköst H100 í FP8 eru 1979 TFLOP/s sem er sýnt sem lárétt lína í Roofline-líkaninu. Minnisbandbreidd H100 er 3,35 TB/s sem er sýnt sem halli línu sem fer í gegnum upphafspunktinn. Línurnar tvr gefa afkastatakmörk fyrir útreikningsbundna og minnisbundna kjarna í sömu röð.

Hér að neðan ræðum við afköst GroupGEMM og GEMM kjarna.

GroupGEMM

GroupGEMM-kjarninn í MoE framkvæmir eftirfarandi útreikning: Það eru g hópar samtals i-ti hópurinn er með m_i tákn sem framkvæmir fylkjamargföldun á [m_i, k] x [k, n] -> [m_i, n]. Við afkastaprófun gerum við ráð fyrir að fjöldi tákna í hverjum hópi sé sá sami sem er táknaður sem m_i = m. Þá er FLOP fjöldinn fyrir GroupGEMM 2 * g * m * k * n og minnis I/O bæti eru g * (m * k + n * k + m * n).

Í DeepSeek-V3/R1 líkaninu eru 256 sérfræðingar og hvert tákn er sent til 8 sérfræðinga til útreiknings. Að því gefnu að lotustærð sé 128 og fyrirspurnarlengd sé 2 og notuð sé EP128 DP128 stilling er meðalfjöldi tákna sem hver sérfræðingur fær (þ.e. m) 128 * 2 * 8 * 128 / 256 = 1024. Á sama hátt getum við reiknað m fyrir aðrar stillingar og lotustærðir.

Við notuðum GroupGEMM útfærslu DeepGEMM til afkastaprófunar. Prófunarpunktar náðu yfir samsetningar af EP8, EP16, EP32, EP64, EP128 stillingum með TP1 og lotustærðum 1-128.

Stækka

Myndin hér að neðan sýnir Roofline-líkanið fyrir GroupGEMM undir mismunandi EP stillingum. Mismunandi EP samsvarar mismunandi fjölda hópa. Myndin sýnir nánast skarast afkastalinur sem gefur til kynna að afköst GroupGEMM séu að mestu ákvörðuð af heildarfjölda tákna (táknuð sem g * m).

Stjörnurnar merkja gagnapunkta sem samsvara lotustærð 128 á hvern grafíkörgjafa fyrir hverja EP stillingu. Með því að bera saman þessa stjörnumerktu gagnapunkta sjáum við að eftir því sem EP eykst (og DP eykst samstillt) eykst fjöldi tákna á hvern sérfræðing m einnig. Við EP8 er m=128 en við EP128 er m=2048.

Eftir því sem m eykst eykst reiknilegur styrkur (Arithmetic Intensity) einnig. Í flestum stillingum er GroupGEMM takmarkað af minnisbandbreidd þannig að aukning á m bætir afköst.

GEMM

GEMM-kjarninn samsvarar línulegum vörpunum (Linear Projections) í líkaninu eins og Q/K/V/O vörpun. Fyrir fylkjamargföldun á [m, k] x [k, n] -> [m, n] er FLOP fjöldinn 2 * m * k * n og minnis I/O bæti eru m * k + n * k + m * n. Við getum einnig prófað daufþreytingu fyrir lotustærðir 1-128.

Stækka

Myndin hér að neðan sýnir Roofline-líkanið fyrir GEMM undir mismunandi EP stillingum. Við sjáum að afköst GEMM eru takmörkuð af minnisbandbreidd. Eftir því sem lotustærð eykst eykst reiknilegur styrkur (Arithmetic Intensity) einnig og bætir þar af leiðandi afköst.

Ör-lota (Microbatch)

Þegar ör-lotugerð (microbatching) er notuð skiptum við lotunni jafnt í tvo hluta. Frá tveimur myndum hér að ofan sjáum við að þegar m verður m/2 minnkar skilvirkni fylkjamargföldunar. Þess vegna tekur það lengri tíma að framkvæma tvær fylkjamargfaldanir af stærð m/2 en að framkvæma eina fylkjamargföldun af stærð m.

Spá um mörg tákn (Multi-Token Prediction)

Í allri þessari grein höfum við gert ráð fyrir notkun á spá um mörg tákn (Multi-Token Prediction - MTP) fyrir spekulatífri afkóðun. MTP breytir fyrirspurnarlengd á hverja beiðni úr 1 í 2. Fyrir fylkjamargföldun jafngildir þetta því að breyta m í m * 2 og eykur þar með skilvirkni fylkjamargföldunar. Á hinn bóginn ef við teiknum Roofline-líkanið fyrir MLA myndum við komast að því að aukning á fyrirspurnarlengd eykur skilvirkni MLA-kjarnans verulega.

Þess vegna gegnir notkun MTP mikilvægu hlutverki í skilvirkni líkansins.

Innleiðing & hagræðing

Í þessum kafla munum við kynna nokkrar upplýsingar um útfærslu og fínstillingar fyrir DeepSeek-V3/R1 líkan okkar.

Magntölun (Quantization)

DeepSeek-V3/R1 var þjálfað innfædd á FP8 með því að nota magnunaráætlun á hvern blokk þar sem vægi voru mögnuð stöðugt og virkjanir voru magnaðar á flugi. Í stað þess að reikna út skalunarstuðul á hvern rás eða á hvern fylki stöðugt eru skalunarstuðlar reiknaðir yfir 128-staka vigra fyrir virkjanir og 128x128 staka flísar fyrir fylki sem takmarkar rýrnun nákvæmni vegna magnunar.

Hjá Perplexity treystum við á blöndu af CUDA og Triton kjörnum til að styðja við ályktun þar sem CUDA er notað fyrir afkastaviðkvæmustu og sjaldséðast breyttu kjarnana (eins og athygli og GEMM) en Triton útfærir breitt úrval af virkjunar-, stöðlunar- og veitukjörnum. Triton gerði okkur kleift að laga kjarnana fljótt að blokkar-magnunaráætluninni.

Fyrir línuleg og MoE-lög blöndum við Deep GEMM kjörnum við okkar eigin Triton GEMM kjörnum þar sem við höfum tekið eftir því að fyrir tilteknar fylkjastærðir og lágar lotustærðir skilar Split-K minni daufþreytingu. Ef ómagnaða lagið framkvæmir (M, K) x (K, N) margföldun þarf það (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) skalunarstuðul fyrir blokkar-magnun. Fyrir blokkar-magnun eru skalunarstuðlar fyrir virkjanir reiknaðir á flugi í stað þess að vera for-kvarðaðir. Þar sem skalunarstuðlar virkjana eru aðeins samantektir meðfram K og ekki meðfram M ásnum þurfa kjarnar aðeins smávægilegar breytingar til að styðja við áætlunina.

Stækka

SiLU virkjunaraðgerðin sem DeepSeek-V3/R1 notar krafðist verulegra breytinga til að styðja við CUDA-graf, blokkar-magnun og kraftmikið beinda táknatölu. Blokkar-magnun getur verið vandkvæðum bundin þar sem hún kynnir láréttar samantektir en kjarninn skipti virkjunum nú þegar meðfram falinni stærð þeirra í blokkir af 1024 stökum. Innan einnar blokkar var tensorn sem átti að magna skipt frekar í blokkir af 128 til að reikna út stærsta algera gildið þar sem Triton myndaði skilvirkar cross-warp max samantektir sem bætti við lágmarks yfirbyggingu.

Til að styðja við MoE beiningu undir CUDA-graf verða kjarnarnir að vera meðvitaðir um beiningarupplýsingarnar sem gefa til kynna fjölda tákna á hvern sérfræðing í stað þess að áætla vinnu út frá stærð biðminnanna sem úthlutað var til að geyma efri mörk táknatölunnar. Við getum ekki skipt vandamálinu út frá stærð inntakstensorsins þannig að við ræsum fastan fjölda þrautseigra kjarna sem lesa beiningarupplýsingarnar til að ákvarða hve mörg tákn eru fyllt og skipta vinnu við úrvinnslu virkjananna á milli þeirra á kraftmikinn hátt.

Við höfum þegar uppstreymt sumum kjörnum okkar í FlashInfer verkefnið og í framtíðinni munum við opna meira af kóðanum okkar.

MLA-lag

Við notum FlashInfer fyrir MLA-útreikning. FlashInfer styður sveigjanlegar síðutöflustillingar og afar mikil afköst.

Við sameinuðum q_a_proj og kv_a_proj í eitt qkv_a_proj. Daufþreyting minnkaði úr 15,4 µs + 14,8 µs = 30,2 µs í 16,7 µs.

Við sundurliðuðum kv_b_proj í tvo fylki, k_b_proj og v_b_proj. Við skrifuðum FP8 blokkar-magnaðan BMM kjarna for útreikninga sem tengjast þessum tveimur fylkjum.

CUDA-graf (Cuda Graph)

CUDA-graf getur dregið verulega úr yfirbyggingu kjarnaræsingar sem er mikilvægt fyrir afköst. Við búum til CUDA-graf fyrir hverja lotustærð.

Áður en við þróuðum okkar eigin AllToAll-kjarna notuðum við torch.all_to_all_single() fyrir AllToAll-samskipti. Þessi aðgerð krefst þess að allir grafíkörgjafar nýti sömu lotustærð. Hins vegar gætu mismunandi DP-hópar keyrt mismunandi lotustærðir.

Til að tryggja að all_to_all_single() sé samhæft við mismunandi DP-hópa sem nota mismunandi lotustærðir notuðum við fyrst allreduce() aðgerð áður en hver líankeyrsla fór fram til að fá hámarks lotustærð meðal allra DP-hópa. Síðan gerðum við það að verkum að allir DP-hópar nýttu þessa lotustærð við keyrslu.

Þrátt fyrir að þessi nálgun tryggi að við getum notað CUDA-graf hefur hún þrjá ókosti. Í fyrsta lagi krefst hún viðbótar allreduce() aðgerðar. Í öðru lagi eru DP-hópar með minni lotustærðir þvingaðir til að fylla í (pad). Í þriðja lagi gerir hún útfærslukóða okkar flókinn.

Eftir að við útfærðum okkar eigin AllToAll-kjarna þörfnumst við ekki lengur þess að allir grafíkörgjafar noti sömu lotustærð. Þess vegna þurfum við ekki lengur að framkvæma viðbótar allreduce() aðgerðir eða fylla í lotustærðir.

MoE-beirari (MoE Router)

MoE-beirarinn er útfærður í Triton og treystir á breytta röðun sem dregin er af stöðluðum bókasafni sem heldur einnig utan um vísbendingar raðaðra staka. Útfærslan er deild þvert á allar MoE-líkön þar sem Mixtral beining er sérstakt tilvik DeepSeek beininganna þar sem Top-K hópurinn er sá sami og hópur allra sérfræðinga. Dreifðu kjarnarnir neyta Top-K vísbendinga og stiga beint á meðan þéttar dispatch/combine áætlanir sem treysta á all-to-all krefjast þess að beiningarupplýsingar séu samantektir á hvern sérfræðing í stað þess að vera á táknagrundvelli.

Framtíðarvinna

Í framtíðarvinnu ætlum við að fínstilla afköst DeepSeek-líkansins enn frekar.

Mikilvægasta næsta fínstillingin er forhleðslu-aðgreining (Prefill Disaggregation). Forhleðsluáfanginn og afkóðunaráfangi DeepSeek-V3/R1 líkansins hafa mjög mismunandi útreikningseiginleika. Báðir geta notað mismunandi fínstillingarstefnur og uppsetningarskipulag.

Fyrir MLA-lagið í afkóðunaráfanga notum við fylkjuhrífingu (Matrix Absorption) til að draga úr FLOP fjölda MLA-útreikninga. Í forhleðsluáfanga væri betra að varpa dula vigrinum fyrst yfir í K/V rými og reikna síðan í formi fjölhöfða athyglis (Multi-Head Attention - MHA).

Ef forhleðsla og afkóðun keyra á sama grafíkörgjafa til að draga úr áhrifum forhleðslu á úttakshraða afkóðunar notum við venjulega hlutaða forhleðslu (chunked prefill) til að skipta fyrirspurninni í marga hluta til forhleðslu. Vegna þess að KV-skyndiminnið geymir dula vigurinn verður erfitt að breyta MLA í MHA form.

Fyrir MoE-lagið í afkóðunaráfanga notum við eins stóra EP og DP og mögulegt er til að auka fjölda inntakstákna á hvern sérfræðing og bæta þar af leiðandi afköst GroupGEMM. Í forhleðsluáfanga vegna þess að fjöldi tákna er nú þegar nógu stór er GroupGEMM þegar útreikningsbundið. Þess vegna getum við notað minni EP og DP fyrir forhleðslu.

Ef forhleðsla og afkóðun keyra á sama grafíkörgjafa mun daufþreyting MoE-laga á öllum grafíkörgjöfum aukast á meðan einhver DP-hópur er að framkvæma forhleðslu sem hefur veruleg áhrif á úttakshraða afkóðunar.

Auk forhleðslu-aðgreiningar ætlum við einnig að fínstilla eftirfarandi þætti:

AllToAll afköst: AllToAll-kjarni okkar getur nú aðeins náð 1/3 af Infiniband bandbreiddinni. Við munum halda áfram að fínstilla þennan kjarna.

EAGLE-stíls spekulatíf afkóðun: Í gögnunum hér að ofan gerðum við ráð fyrir notkun á spekulatífri afkóðun til að spá fyrir um 1 tákn. EAGLE getur notað trjástruktúr til að spá fyrir um mörg tákn sem bætir samþykktarlengd og getur aukið úttakshraða verulega.

GEMM-kjarni: Í Roofline-líkaninu sem sýnt var fyrr getum við fundið að skilvirkni GEMM-kjarnans er enn fjarri fræðilegum mörkum. Við munum halda áfram að fínstilla þennan kjarna.

GB200 NVL72: Í nýjustu GB200 NVL72 lausn NVIDIA eru 72 Blackwell grafíkörgjafar tengdir saman í gegnum háhraða NVLink. Fyrir MoE arkitektúrlíkön er þetta mjög stórt tækifæri og áskorun.

Niðurstaða

Uppsetning á mörgum hnútum af DeepSeek MoE líkönum nær því sem venjulega er ómögulegt með þéttum stórum tungumálalíkönum: að bæta bæði afköst og daufþreytingu á sama tíma. Með því að dreifa sérfræðingum yfir fleiri grafíkörgjafa drögum við úr þrýstingi á minnisbandbreidd á hvern tæki sem gerir kleift að vinna úr hraðar og skilar meiri afköstum kerfis. Tilraunir okkar sýna að EP128 stillingar ná allt að 5x meiri afköstum á jafngildum úttakshraða í samanburði við uppsetningar á einum hnút.

Tækni til að skarast útreikningar og samskipti eins og ör-lotugerð (micro-batching) dregur verulega úr yfirbyggingu samskipta á mörgum hnútum þar sem útfærsla okkar sýnir allt að 40% hraðauka. Sérsniðnir AllToAll samskiptakjarnar okkar og fínstilltar kjarnaútfærslur hafa gert skilvirka uppsetningu á 671B færibreytu líkaninu mögulega.

Þegar MoE arkitektúrar ná vinsældum fyrir getu sína veita þessar uppsetningarstefnur dýrmæta innsýn í að mælikvarða slík líkön á skilvirkan hátt.

Heimildir

Tækniskýrsla DeepSeek-V3

Yfirlit yfir ályktunarkerfi DeepSeek-V3/R1

Megatron-LM: Þjálfun tungumálalíkana með mörgum milljörðum færibreytum með því að nota líkansamsíðun

EAGLE: Spekulatíf sýnataka krefst endurskoðunar á óvissu eiginleika

Tilvitnun

@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}
}