Madalam latentsus ja suurem läbilaskevõime mitmesõlmelise DeepSeeki juurutusega

Enamikus süsteemides on latentsus ja läbilaskevõime sageli omavahel vastuolus olevad eesmärgid, mis nõuavad projekteerimisel ja juurutamisel kompromisse. Näiteks tihedate suurte keelemudelite puhul võib pakti suuruse suurendada läbilaskevõimet, kuid see suurendab ka latentsust; tensori paralleelsuse suurendamine ühes masinas võib latentsust vähendada, kuid vähendab koopiate arvu, mis viib madalama läbilaskevõimeni.

Ekspertide segu (Mixture of Experts ehk MoE) mudelid, nagu DeepSeek-V3/R1, on hiljuti näidanud suurepäraseid mudeli võimeid ja töötõhusust. Näiteks on DeepSeek-V3/R1 mudelil kokku 671B parameetrit, kuid iga token kasutab järelduse tegemisel ainult 37B parameetrit. See mudeli arhitektuur pakub järeldussüsteemidele nii väljakutseid kui ka võimalusi.

See artikkel näitab, et vastupidiselt tavapärastele süsteemidele võivad MoE mudelid, nagu DeepSeek-V3/R1, enamikus stsenaariumides saavutada mitmesõlmelistes juurutustes rohkemaid GPU-sid kasutades samaaegselt suurema läbilaskevõime ja madalama latentsuse.

Juurutuse arhitektuurid

Suurenda

Suurenda

Mudeli paljude väikeste ekspertide tõttu tuleb juurutused jagada mitme seadme vahel. Me kaalusime nii ühesõlmelisi juurutusi ühel 8xH200 GPU-dega sõlmel kui ka mitmesõlmelisi juurutusi 8xH100 GPU-dega.

Mõlemad juurutusarhitektuurid kasutavad andmeparalleelsust, mida korraldatakse meie oma päringute ajastaja kaudu. Andmeparalleelsuse rakendamine hõlmab mitme järeldusmootori eksemplari käivitamist, millest igaüks töötab iseseisvalt päringute teenindamiseks ja haldamiseks. Päringute ajastaja, mis suhtleb mootoriga GRPC kaudu, vastutab päringute võimalikult ühtlase hajutamise eest, hõlbustades samal ajal ka KV taaskasutust, saates osaliselt sobitatud eesliitega päringud vahemälu sisaldavatele serveritele. Mootori eksemplarid ei ulatu üle mitme sõlme. Nad võivad valikuliselt kasutada tensori paralleelsust tähelepanu jagamiseks mitme seadme vahel. Eksemplarid on omavahel ühendatud NVLinki kaudu ühesõlmelisel juhul või InfiniBandi kaudu mitmesõlmelisel juhul, saates ja kogudes eksperte.

Ühesõlmelise juurutuse konfiguratsioon tagab suurepärase latentsuse väikeste pakettide suurustega; siiski halveneb jõudlus suurenenud koormuse tingimustes kiiresti.

Teenindusmootori juurutamiseks käivitame ühe podi sõlme kohta, mis majutab mitut mootori eksemplari. PyTorch vastutab hajutatud side seadistamise ja NVSHMEM-i lähtestamise kokkuleppimise eest. Sidepidamisel tugineme kohandatud CUDA tuumadele, mida kirjeldatakse varasemas blogipostituses. Kahe juurutuse rakendus on praktiliselt identne, kusjuures mudel valib õiged tuumad ekspertide paralleelsust rakendava kanga põhjal.

Parralleliseerimistehnikad

Enne meie jõudlusvõrdlustesse süvenemist on hädavajalik mõista peamisi paralleerimisstrateegiaid, mis teevad massiivsete MoE mudelite, nagu DeepSeek-V3/R1, juurutamise võimalikuks.

Tensori paralleelsus

LLM-i järeldustes kasutatakse tensori paralleelsust (TP) tavaliselt mälu kasutusmahu ja arvutuste vähendamiseks GPU kohta, vähendades seeläbi latentsust. Tavaliselt saame lineaarprojektsioone tähelepanu- ja MLP-kihtides jagada piki rina- või veerudimensioone ning tähelepanuoperatsioone tähelepanupea dimensiooni piki.

TP-ga ei ole Llama-3 arhitektuuris lineaarprojektsiooni ja tähelepanuoperatsioonide jaoks GPU-de vahel duplikaatset arvutust, mis on ideaalne jagamismeetod. DeepSeek-V3/R1 mudelites ei saa aga TP seda saavutada.

DeepSeek-V3/R1 mudelid kasutavad mitme latentse tähelepanu (MLA) mehhanismi. MLA kiht kasutab esmalt lineaarset projektsiooni kv_a_proj latentsusvektori arvutamiseks, seejärel kasutab teist lineaarset projektsiooni kv_b_proj, et teisendada see iga tähelepanupea ruumi. Kuna kõik tähelepanupead jagavad sama latentsusvektorit, ei saa TP latentsusvektorit jagada, nii et kõik TP auastmed peavad kordama parameetreid ja arvutusi kv_a_proj ja kv_b_proj jaoks. Samamoodi, kuna MLA salvestab latentsusvektori KV vahemällu, salvestab iga TP auaste identse KV vahemälukoopia.

Vaatamata mõningale duplikatsioonile MLA-s, pakub tensori paralleelsus endiselt arvutusvajaduste osalist vähendamist, muutes selle väärtuslikuks stsenaariumide puhul, mis nõuavad suurt väljundkiirust.

Ekspertide paralleelsus

DeepSeek-V3/R1 mudelid asendavad MLP kihid MoE kihtidega. MoE kihil on 256 marsruuditud eksperti ja üks jagatud ekspert. Iga token suunatakse arvutusteks 8 erinevale marsruuditud eksperdile ja tulemused summeeritakse kaalustatult. Iga token arvutatakse ka jagatud eksperdis ja tulemus lisatakse marsruuditud ekspertide tulemusele.

Ekspertide paralleelsus (EP) toimib MoE kihtide tüüpilise jagamislähenemisviisina, kus iga GPU haldab 256 / EP marsruuditud eksperti, säilitades samal ajal jagatud eksperdi koopia. Võrreldes TP-ga on EP eeliseks see, et see suudab arvutusi jaotada rohkemate GPU-de vahel, vähendades arvutus- ja mälukasutust GPU kohta.

Enne eksperdiarvutuste tegemist peavad kõik GPU-d sooritama AllToAll side, et saata tokenid GPU-dele, kus vastavad eksperdid asuvad; pärast eksperdiarvutusi on vaja teist AllToAll sidet, et koguda arvutustulemusi erinevatelt GPU-delt ja teostada kaalutud summeerimine. Me rakendasime NVSHMEM-i abil nende kahe AllToAll side tuuma optimeeritud versiooni, Dispatch ja Combine. Oma eelmises blogipostituses kirjeldasime rakendust üksikasjalikult ja meie tuumad on GitHubis avatud lähtekoodiga.

Andmeparalleelsus

EP-ga saame MoE arvutusi jaotada 128 või isegi rohkemate GPU vahel. MLA arvutusi ei saa aga EP-ga jagada. Sel hetkel saame tutvustada andmeparalleelsust (DP). Igal DP rühmal on MLA kihi täielik koopia. Iga DP rühm aktsepteerib erinevaid sisendeid ja teostab MLA kihi arvutusi sõltumatult.

MLA kihi DP-d ja TP-d saab kombineerida, kus üks DP rühm jagatakse mitmeks TP auastmeks. MoE kihi EP-d saab kombineerida MLA kihi DP/TP-ga. EP = DP * TP. Näiteks 16 masinal tähendab EP128 DP32 TP4 marsruuditud ekspertide jaotamist 128 GPU vahel, kus iga 4 GPU moodustab ühe DP rühma, kokku 32 sõltumatut DP rühma.

Ühesõlmelne vs mitmesõlmelne

DeepSeeki 671B parameetrit ületavad ühe 8-GPU H100 masina (80 GB * 8) mälumahu, kuid üks 8-GPU H200 masin mahutab täielikult kogu mudeli (141 GB * 8). Kasutades konfiguratsiooni EP8 DP8 TP1, kasutab mudel umbes 100 GB mälu GPU kohta, jättes ligikaudu 40 GB KV vahemälu ja muude vahetulemuste jaoks. Üks token hõivab 70 272 baiti KV vahemälu. Eeldades, et igal päringul on 5000 tokenit, mahutab iga GPU umbes 100 päringut.

Me soovisime mõista jõudluse erinevusi ühesõlmeliste ja mitmesõlmeliste juurutuste vahel erinevates konfiguratsioonides. Kasutasime ühesõlmeliseks juurutuseks ühte H200 masinat ja mitmesõlmelisteks juurutusteks kuni 16 H100 masinat. Iga juurutuskeskkonna jaoks kasutasime TP 1, 2, 4, 8 kombinatsioone ja partiide suurusi GPU kohta 1, 2, 4, 8, 16, 32, 64, 128. Eeldasime, et igal päringul oli KV vahemälu pikkus 5000 tokenit. Eeldasime samuti, et mitme tokeni ennustamine (MTP) ennustab 1 täiendava tokeni (st iga päringu päringu pikkus on 2), ja eeldasime konservatiivselt 60% vastuvõtumäära. Allolev joonis näitab läbilaskevõimet ja väljundkiirust erinevate konfiguratsioonide jaoks.

Suurenda

Horisontaalne telg tähistab väljundkiirust päringu kohta ühikutes tokenid/s. Vertikaalne telg kasutab logaritmilist skaalat, et näidata läbilaskevõimet masina kohta ühikutes tokenid/s. Märkisime iga EP konfiguratsiooni Pareto piiri erinevate värvidega joontega.

Äärmiselt kõrge väljundkiiruse nõuetega stsenaariumides võib ühesõlmelise EP8 DP1 TP8 kasutamine pakendi suurusega 1 saavutada väljundkiiruse, mis ületab 100 tokenit/s, kuid läbilaskevõime on äärmiselt madal, olles võrdne väljundkiirusega. Selles stsenaariumis on kogu partiis ainult 2 tokenit, mida saab saata maksimaalselt 2*8=16 eksperdile, aktiveerides kokku maksimaalselt 57B parameetrit.

Väljundkiiruse vahemikus 80-40 tokenit/s läbilaskevõime suurenedes väljundkiirus väheneb märkimisväärselt. Seevastu EP128-l on samal väljundkiirusel umbes 5 korda suurem läbilaskevõime kui ühesõlmelisel juurutusel.

Seda nähtust saab selgitada ühesõlmeliste juurutuste käitumise uurimisega: partii suuruse suurendamine on otseselt seotud aktiveeritud ekspertide arvu suurenemisega. Kui partii suurus on 1, on aktiveeritud ekspertide keskmine arv GPU kohta 2 * 8 / 8 = 2. Kui partii on piisavalt suur, on kõik eksperdud aktiveeritud, mis tähendab, et iga GPU aktiveerib 256 / 8 = 32 eksperti. Rohkemate ekspertide aktiveerimine tähendab, et GPU peab mälust lugema rohkem parameetreid, suurendades märkimisväärselt mäluriba laiuse survet. Kuna suurte keelemudelite dekodeerimisfaas on mäluriba laiuse, mitte arvutusjõudluse poolest juba kitsaskohaks, vähendab partii suuruse suurendamine ühesõlmelises juurutuses väljundkiirust märkimisväärselt.

Nelja mitmesõlmelise juurutuse konfiguratsiooni (EP16, EP32, EP64 ja EP128) võrdlus näitab, et kõrgemad EP väärtused nihutavad Pareto piiri läbilaskevõime ja väljundkiiruse samaaegse paranemise suunas.

Kõrgema EP numbri kasutamine tähendab, et igale GPU-le eraldatakse vähem eksperte. Näiteks EP128 tähendab, et iga GPU vastutab 256 / 128 = 2 eksperdi eest, mistõttu mäluriba laiuse surve väheneb oluliselt. Teiste sõnadega, suurema EP numbri kasutamisega saavutame tõhusalt rohkem mäluriba laiust. Kui GPU-põhine partii suurus on alla 64, ei mõjuta partii suuruse suurendamine eksperdiarvutuse kiirust märkimisväärselt, kuna sisendite arvu suurendamine ei suurenda mäluriba laiuse survet märkimisväärselt. Seetõttu märkame, et EP128 kasutamisel ei mõjuta partii suuruse suurendamine väljundkiirust nii oluliselt.

Huvitaval kombel täheldasime suuremate partiide suuruste puhul (64 päringut GPU kohta) uut nähtust: ühesõlmelise juurutuse läbilaskevõime on veidi kõrgem kui mitmesõlmelisel juurutusel. Osaliselt on põhjuseks see, et sõlmesisene NVLink pakub suuremat ribalaiust kui sõlmevaheline InfiniBand. Teine osa on tingitud meie rakenduse piirangutest. Analüüsime seda nähtust hiljem üksikasjalikumalt.

Mälumahu piirangute tõttu ei saa EP8 DP8 TP1 konfiguratsioon saavutada partii suurust 128 GPU kohta, nii et mitmesõlmelne juurutus on suuremat läbilaskevõimet taga ajavates stsenaariumides endiselt parem valik.

Arvutuste ja side kattumine

Nagu eespool lühidalt tutvustati seoses ekspertide paralleelsusega, on GPU-d MoE kihi side ajal jõude. Raiskamise vähendamiseks ja latentsuse alandamiseks peame leidma andmetest sõltumatuid arvutusülesandeid selle jõudeaja täitmiseks.

Suurenda

Ülaltoodud joonise ülemine osa näitab ühe kihi arvutusvoogu. MoE arvutus sõltub Dispatchist ja järgmise kihi arvutus sõltub Combine tulemusest.

Me asetame jagatud eksperdi igale GPU-le. Sel viisil ei vaja jagatud eksperdi arvutus AllToAll sidet. Seetõttu saame sooritada jagatud eksperdi arvutuse kohe pärast Dispatch Sendi, oodates seejärel Dispatch Recv valmimist. Nimetame seda kattumisskeemi "Dispatch Overlap".

Dispatch Overlap pakub lihtsat rakendust ja laia kohaldatavust. See tehnika peidab jagatud eksperdi arvutusaega kõigis EP suurustes ja partiide suurustes.

Arvutuste ja side kattuvuse edasiseks suurendamiseks kasutasime DeepSeeki tehnilises aruandes mainitud mikropartietust andmesõltuvuse murdmiseks. Nagu on näidatud joonise alumises osas, jagasime ühe Transformeri kihi arvutuse 5 etappi:

1. etapp: InputNorm, QKVProj, AppendKV, BMM

2. etapp: BMM, Attn, OProj, PostNorm, Gate

3. etapp: Dispatch Send, jagatud ekspert

4. etapp: Dispatch Recv, MoE, Combine Send

5. etapp: Combine Recv

Esimeses kolmes tihedas Transformeri kihis kasutame kogu partiid. Järgmises 58 MoE Transformeri kihis jagame partii ühtlaselt kaheks mikropartiiks. Kaks mikropartiid täidetakse vaheldumisi, nihutatuna 3 etapi võrra. Kuna nende kahe mikropartii vahel ei ole andmesõltuvust, saame pärast Dispatch Sendi ja pärast Combine Sendi lülituda teise mikropartii arvutusele.

Latentsuse jaotus

Järgmisena võrdleme katse kaudu kattumise efekte ning samuti võrdleme ühesõlmelise juurutuse EP8 ja mitmesõlmelise juurutuse EP128 jõudluse erinevusi. Võrdluse hõlbustamiseks kasutasime järgmises katses H100 GPU-sid. Kasutasime TP1, partii suurust 128 GPU kohta, päringu pikkust 2 päringu kohta ja KV vahemälu pikkust 5000.

Suurenda

Ülaltoodud joonis näitab ühele MoE Transformeri kihile kulutatud koguaega ja erinevat tüüpi tuumade latentsuse osakaalu. Välja arvatud Dispatch, Combine ja GroupGEMM, peaks teiste tuumade täitmisaeg EP8, EP128 NoOverlap ja EP128 DispatchOverlap seerias olema sama, kuna partii suurus on sama.

Kattumine

Võrdleme esmalt kolme kattumismeetodi efekte. NoOverlap võttis kokku 2667 µs, DispatchOverlap võttis 2651 µs, säästes 16 µs ehk ainult 0,6%. Mikropartii näitas väga märkimisväärset paranemist, võttes 1896 µs, mis on 29% kiiruse kasv. Nii Dispatchi kui ka Combine'i aeg vähenes märkimisväärselt. Dispatch vähenes 593 µs-lt 367 µs-ni ja Combine 1012 µs-lt 237 µs-ni.

Pange tähele, et arvutustuumade puhul suurendab suurusega 128 partii jagamine kaheks suurusega 64 partiiks kogutäitmisaega. Seetõttu, kuigi sidele kulunud aeg vähenes 1001 µs võrra, vähenes koguaeg ainult 771 µs võrra. Selgitame põhjust Roofline mudeli abil järgmises jaotises.

Sel põhjusel ei paranda mikropartiistamine alati jõudlust.

Suurenda

Ülaltoodud joonis näitab mikropartii jõudluse paranemist võrreldes DispatchOverlapiga partiide suuruste 4-128 jaoks. Kui partii suurus on alla 32, vähendab mikropartii jõudlust 5%-40%. Kui partii suurus on suurem või võrdne 32-ga, võib mikropartii parandada jõudlust 10%-35%.

EP8 vs EP128

Pöördume tagasi eelmise joonise juurde ja võrdleme EP8 ja EP128 mikropartiid. EP8 võttis kokku 1802 µs, olles veidi vähem kui EP128 1896 µs. Lisaks ülaltoodud mikropartii toodud tuuma täitmisaja suurenemisele on peamised erinevused MoE arvutuste jaoks kasutatavas GroupGEMM-is ja kahes sidetuumas, Dispatchis ja Combine'is.

EP8 GroupGEMM võttis 555 µs, samas kui EP128 GroupGEMM võttis 270 µs, vähenedes poole võrra. See on mitmesõlmelise juurutuse peamine eelis.

Kahjuks suurenes sidele kulunud aeg 213 µs võrra, mis kompenseeris suurel määral GroupGEMM-i eelise. Meie sidetuumade eraldi jõudlustestides leidsime, et need suudavad saavutada ainult poole Infinibandi ribalaiusest. Jätkame oma sidetuumade optimeerimist.

Teine tuum, mis märkimisväärselt maha jääb, on GEMM. Mikropartii suurendas GEMM-i 95 µs võrra. Analüüsime GEMM-i põhjalikumalt allpool olevas Roofline jaotises. Usume, et praegune GEMM-i rakendamine ei ole veel saavutanud optimaalset jõudlust.

Roofline

Roofline mudel on hea tööriist tuuma jõudluse analüüsimiseks. Selle horisontaalne telg on aritmeetiline intensiivsus, ujukomaoperatsioonide ja mälu I/O baitide suhe. Horisontaalse telje väärtust saab arvutada otse tuuma semantikast. Vertikaalne telg tähistab saavutatud jõudlust, mis arvutatakse ujukomaoperatsioonide jagamisel etalonlatentsusega.

Tuuma jõudluse teoreetilise ülempiiri määravad otseselt GPU spetsifikatsioonid. H100 FP8 tippjõudlus on 1979 TFLOP/s, mis on Roofline mudelis esitatud horisontaalse joonena. H100 mäluriba laius on 3,35 TB/s, mis on esitatud läbi nullpunkti läbiva joone kaldena. Need kaks joont annavad vastavalt arvutuspiiranguga ja mälu piiranguga tuumade jõudluspiirid.

Allpool käsitleme GroupGEMM-i ja GEMM-i tuumade jõudlust.

GroupGEMM

GroupGEMM tuum MoE-s teostab järgmise arvutuse: Kokku on g rühma, i-ndal rühmal on m_i tokenit, teostades maatrikskorrutust [m_i, k] x [k, n] -> [m_i, n]. Jõudlustestimisel eeldame, et tokenite arv igas rühmas on sama, mida tähistatakse kui m_i = m. Siis on GroupGEMM-i ujukomaoperatsioonide arv 2 * g * m * k * n ja mälu I/O baidid on g * (m * k + n * k + m * n).

DeepSeek-V3/R1 mudelis on 256 eksperti ja iga token suunatakse arvutusteks 8 eksperdile. Eeldades partii suurust 128, päringu pikkust 2, kasutades EP128 DP128 konfiguratsiooni, on iga eksperdi vastuvõetud tokenite keskmine arv (st m) 128 * 2 * 8 * 128 / 256 = 1024. Samamoodi saame arvutada m teiste konfiguratsioonide ja partiide suuruste jaoks.

Kasutasime DeepGEMM-i GroupGEMM-i rakendust jõudlustestimiseks. Katsepunktid katsid EP8, EP16, EP32, EP64, EP128 konfiguratsioonide kombinatsioone TP1-ga ja partiide suurusi 1-128.

Suurenda

Ülaltoodud joonis näitab GroupGEMM-i Roofline mudelit erinevate EP konfiguratsioonide all. Erinevad EP-d vastavad erinevatele rühmade arvudele. Joonis illustreerib peaaegu kattuvaid jõudlusjooni, mis näitab, et GroupGEMM-i jõudlus on peamiselt määratud tokenite koguarvuga (mida tähistatakse kui g * m).

Tähed tähistavad andmepunkte, mis vastavad partii suurusele 128 GPU kohta iga EP konfiguratsiooni jaoks. Neid tärniga tähistatud andmepunkte võrreldes näeme, et EP suurenemisel (ja DP sünkroonsel suurenemisel) suureneb ka tokenite arv eksperdi kohta m. EP8 juures on m=128, samas kui EP128 juures on m=2048.

Kui m suureneb, suureneb ka aritmeetiline intensiivsus. Enamikus konfiguratsioonides on GroupGEMM piiratud mäluriba laiusega, seega m suurendamine parandab jõudlust.

GEMM

GEMM tuum vastab mudeli lineaarprojektsioonidele, nagu Q/K/V/O projektsioon. Maatrikskorrutuse [m, k] x [k, n] -> [m, n] jaoks on ujukomaoperatsioonide arv 2 * m * k * n ja mälu I/O baidid on m * k + n * k + m * n. Saame testida ka latentsust partiide suuruste 1-128 jaoks.

Suurenda

Ülaltoodud joonis näitab GEMM-i Roofline mudelit erinevate EP konfiguratsioonide all. Näeme, et GEMM-i jõudlus on piiratud mäluriba laiusega. Partii suuruse suurenemisel suureneb ka aritmeetiline intensiivsus, parandades seeläbi jõudlust.

Mikropartii

Mikropartiide kasutamisel jagame partii ühtlaselt kaheks osaks. Kahest ülaltoodud joonisest näeme, et kui m muutub väärtuseks m/2, väheneb maatrikskorrutuse tõhusus. Seetõttu võtab kahe suurusega m/2 maatrikskorrutuse täitmine kauem aega kui ühe suurusega m maatrikskorrutuse täitmine.

Mitme tokeni ennustamine

Kogu selle artikli vältel oletasime spekulatiivse dekodeerimise jaoks mitme tokeni ennustamise (MTP) kasutamist. MTP muudab päringu pikkuse päringu kohta 1-lt 2-le. Maatrikskorrutuse jaoks on see samaväärne m muutmisega väärtuseks m * 2, suurendades seeläbi maatrikskorrutuse tõhusust. Teisest küljest, kui joonistame MLA jaoks Roofline mudeli, leiaksime, et päringu pikkuse suurendamine suurendab oluliselt MLA tuuma tõhusust.

Seetõttu mängib MTP kasutamine mudeli tõhususes olulist rolli.

Rakendamine ja optimeerimised

Selles jaotises tutvustame mõningaid rakendamise ja optimeerimise üksikasju meie DeepSeek-V3/R1 mudeli jaoks.

Kvantimine

DeepSeek-V3/R1 treeniti algselt FP8-l, kasutades plokipõhist kvantimisskeemi, kus kaalud kvantiti staatiliselt ja aktiveerimised lennult. Selle asemel, et arvutada skaleerimistegurit kanali või maatriksi kohta staatiliselt, arvutatakse skaleerimistegurid aktiveerimiste jaoks 128-elemendiliste vektorite ja maatriksite jaoks 128x128 elemendiliste paanide ulatuses, piirates kvantimisest tulenevat täpsuse halvenemist.

Perplexity-s tugineme järelduse toetamiseks CUDA ja Tritoni tuumade segule, kus CUDA-t kasutatakse kõige jõudlustundlikumate ja harvemini muudetavate tuumade jaoks (nagu tähelepanu ja GEMM), ning Triton rakendab laia valikut aktiveerimis-, normaliseerimis- ja utiliidituumi. Triton võimaldas meil tuumad kiiresti plokikvantimisskeemiga kohandada.

Lineaarsete ja MoE kihtide jaoks segame Deep GEMM tuumi omaenda Triton GEMM tuumadega, kuna oleme märganud, että teatud maatriksmõõtmete ja madalate partiide suuruste puhul tagab Split-K madalama latentsuse. Kui kvantimata kiht teostab korrutuse (M, K) x (K, N), vajab see plokikvantimiseks skaleerimistegurit (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)). Plokikvantimise jaoks arvutatakse aktiveerimiste skaleerimistegurid lennult, selle asemel et neid eelnevalt kalibreerida. Kuna aktiveerimise skaleerimistegurid agregeeritakse ainult piki K dimensiooni ja mitte piki M dimensiooni, vajavad tuumad skeemi toetamiseks vaid väheseid muudatusi.

Suurenda

DeepSeek-V3/R1 poolt kasutatav SiLU aktiveerimisfunktsioon nõudis CUDA graafikute, plokikvantimise ja dünaamiliselt marsruuditud tokenite arvude toetamiseks olulisi muudatusi. Plokikvantimine võib olla problemaatiline, kuna see toob sisse horisontaalsed taandamised, kuid tuum tükeldas aktiveerimised nende peidetud dimensiooni piki juba 1024 elemendilisteks plokkideks. Ühe ploki piires tükeldati kvantitav tensor edasi 128-elemendilisteks plokkideks suurima absoluutväärtuse arvutamiseks, kusjuures Triton genereeris tõhusad rist-warp maksimaalsed taandamised, lisades minimaalset lisakulu.

MoE marsruutimise toetamiseks CUDA graafikute all peavad tuumad olema teadlikud marsruutimisteabest, mis näitab tokenite arvu eksperdi kohta, selle asemel et ajastada tööd tokenite arvude ülempiiri hoidmiseks eraldatud puhvrite suuruse alusel. Me ei saa probleemi jagada sisendtensori mõõtmete alusel, seega käivitame fikseeritud arvu püsivaid tuumi, mis loevad marsruutimisteavet, et määrata kindlaks, kui mitu tokenit on asustatud, ja jagavad aktiveerimiste töötlemise töö nende vahel dünaamiliselt.

Oleme juba ülesvoolu lisanud mõned oma tuumad FlashInferi projektile ja tulevikus teeme rohkem oma koodist avatud lähtekoodiga.

MLA kiht

Kasutame MLA arvutuste jaoks FlashInfer-it. FlashInfer toetab paindlikke leheküljetabeli sätteid ja ülikõrget jõudlust.

Me ühendasime q_a_proj ja kv_a_proj üheksainsaks qkv_a_proj-ks. Latentsus langes 15,4 µs + 14,8 µs = 30,2 µs-lt 16,7 µs-ni.

Me lagundasime kv_b_proj kaheks maatriksiks, k_b_proj ja v_b_proj. Kirjutasime FP8 plokikvandiduga BMM tuuma nende kahe maatriksiga seotud arvutuste jaoks.

CUDA graafik

CUDA graafik võib märkimisväärselt vähendada tuuma käivitamise lisakulu, mis on jõudluse jaoks ülioluline. Loome igale partii suurusele CUDA graafiku.

Enne oma AllToAll tuuma väljatöötamist kasutasime AllToAll side jaoks funktsiooni torch.all_to_all_single(). See operatsioon nõuab, et kõik GPU-d kasutaksid sama partii suurust. Erinevad DP rühmad võivad aga käitada erinevaid partiide suurusi.

Tagamaks, et all_to_all_single() ühildub erinevate DP rühmadega, mis kasutavad erinevaid partiide suurusi, kasutasime enne iga mudeli käivitamist kõigepealt allreduce() operatsiooni, et saada maksimaalne partii suurus kõigi DP rühmade seas. Seejärel panime kõik DP rühmad seda partii suurust käitamiseks kasutama.

Kuigi see lähenemisviis tagab CUDA graafiku kasutamise, on sellel kolm puudust. Esiteks nõuab see täiendavat allreduce() operatsiooni. Teiseks on väiksemate partiide suurustega DP rühmad sunnitud täiendama (polsterdama). Kolmandaks muudab see meie rakenduskoodi keeruliseks.

Pärast oma AllToAll tuuma rakendamist ei nõua me enam kõigilt GPU-delt sama partii suuruse kasutamist. Seetõttu ei pea me enam teostama täiendavaid allreduce() operatsioone ega polsterdama partiide suurusi.

MoE ruuter

MoE ruuter on rakendatud Tritonis, tuginedes standardraamatukogust tuletatud muudetud sordile, mis jälgib ka sorditud elementide indekseid. Rakendust jagatakse kõigi MoE mudelite vahel, kuna Mixtrali marsruutimine on DeepSeek-ruutide erijuhtum, kus Top-K rühm on sama mis kõigi ekspertide rühm. Hõredad tuumad tarbivad Top-K indekseid ja skoore otse, samas kui all-to-all-ile tuginevad tihedad dispatch/combine skeemid nõuavad marsruutimisteabe agregeerimist eksperdi-põhiselt, mitte tokeni-põhiselt.

Tulevane töö

Tulevases töös plaanime DeepSeeki mudeli jõudlust edasi optimeerida.

Kõige olulisem järgmine optimeerimine on eeltäitmise disagregeerimine (Prefill Disaggregation). DeepSeek-V3/R1 mudeli eeltäitmise faasil (Prefill) ja dekodeerimise faasil (Decode) on väga erinevad arvutusomadused. Mõlemad saavad kasutada erinevaid optimeerimisstrateegiaid ja juurutusskeeme.

MLA kihi puhul kasutame dekodeerimise faasis maatriksi neeldumist MLA arvutuste ujukomaoperatsioonide arvu vähendamiseks. Eeltäitmise faasis annaks paremaid tulemusi latentsusvektori esmalt projekteerimine K/V ruumi ja seejärel mitmepäise tähelepanu (MHA) kujul arvutamine.

Kui eeltäitmine ja dekodeerimine jooksevad samal GPU-l, kasutame eeltäitmise mõju vähendamiseks dekodeerimise väljundkiirusele tavaliselt tükeldatud eeltäitmist (chunked prefill), et jagada päring mitmeks tükiks eeltäitmise jaoks. Kuna KV vahemälu salvestab latentsusvektori, muutub MLA teisendamine MHA kujule keeruliseks.

MoE kihi puhul kasutame dekodeerimise faasis võimalikult suurt EP-d ja DP-d, et suurendada sisendtokenite arvu eksperdi kohta, parandades seeläbi GroupGEMM-i jõudlust. Eeltäitmise faasis on GroupGEMM tokenite suure arvu tõttu juba arvutuspiiranguga. Seetõttu saame eeltäitmiseks kasutada väiksemat EP-d ja DP-d.

Kui eeltäitmine ja dekodeerimine jooksevad samal GPU-l, suureneb kõigi GPU-de MoE kihtide latentsus seni, kuni mõni DP rühm teostab eeltäitmist, mõjutades märkimisväärselt dekodeerimise väljundkiirust.

Lisaks eeltäitmise disagregeerimisele plaanime optimeerida ka järgmisi aspektide:

AllToAll jõudlus: Meie AllToAll tuum suudab praegu saavutada ainult 1/3 InfiniBandi ribalaiusest. Jätkame selle tuuma optimeerimist.

EAGLE-stiilis spekulatiivne dekodeerimine: Ülaltoodud andmetes eeldasime spekulatiivse dekodeerimise kasutamist 1 tokeni ennustamiseks. EAGLE saab kasutada puustruktuuri mitme tokeni ennustamiseks, parandades vastuvõtupikkust, mis võib väljundkiirust oluliselt suurendada.

GEMM tuum: Varem näidatud Roofline mudelis võime leida, et GEMM tuuma tõhusus on teoreetilisest piirist endiselt kaugel. Jätkame selle tuuma optimeerimist.

GB200 NVL72: NVIDIA viimases GB200 NVL72 lahenduses on 72 Blackwelli GPU-d omavahel ühendatud kiirrohelise NVLinki kaudu. MoE arhitektuuri mudelite jaoks on see väga suur võimalus ja väljakutse.

Kokkuvõte

DeepSeeki MoE mudelite mitmesõlmelne juurutus saavutab selle, mis on tihedate LLM-ide puhul tavaliselt võimatu: parandab samaaegselt nii läbilaskevõimet kui ka latentsust. Jaotades eksperte rohkemate GPU-de vahel, vähendame mäluriba laiuse survet seadme kohta, võimaldades kiiremat töötlemist ja suuremat süsteemi läbilaskevõimet. Meie katsed näitavad, et EP128 konfiguratsioonid saavutavad võrreldavate väljundkiiruste juures kuni 5 korda suurema läbilaskevõime võrreldes ühesõlmeliste juurutustega.

Arvutuste ja side kattuvuse tehnikad, nagu mikropartiistamine, vähendavad märkimisväärselt mitmesõlmelise side lisakulu, kusjuures meie rakendus näitab kuni 40% kiiruse kasvu. Meie kohandatud AllToAll side tuumad ja optimeeritud tuumade rakendused on võimaldanud 671B parameetriga mudeli tõhusa juurutuse.

Kuna MoE arhitektuurid koguvad oma võimekuse tõttu populaarsust, pakuvad need juurutusstrategiad väärtuslikke teadmisi selliste mudelite tõhusaks mastaapseks laiendamiseks.

Viited

DeepSeek-V3 tehniline aruanne

DeepSeek-V3/R1 järeldussüsteemi ülevaade

Megatron-LM: Mitme miljardi parameetriga keelemudelite treenimine mudelparalleelsust kasutades

EAGLE: Spekulatiivne valik nõuab funktsioonide ebakindluse ümbermõtestamist

Viide

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