Menor latència i major rendiment amb el desplegament multinode de DeepSeek

En la majoria de sistemes, la latència i el rendiment solen ser objectius contradictoris que requereixen compromisos durant el disseny i el desplegament. Per exemple, en models de llenguatge grans i densos, augmentar la mida del lot pot millorar el rendiment, però també augmenta la latència; augmentar el paral·lelisme de tensors dins d'una sola màquina pot reduir la latència, però disminueix el nombre de rèpliques, la qual cosa comporta un rendiment inferior.

Els models de barreja d'experts (MoE), com ara DeepSeek-V3/R1, han demostrat recentment unes capacitats de model i una eficiència operativa excel·lents. Per exemple, el model DeepSeek-V3/R1 té 671 milions de milions de paràmetres en total, però cada testimoni només utilitza 37 milions de milions de paràmetres durant la inferència. Aquesta arquitectura de model presenta tant reptes com oportunitats per als sistemes d'inferència.

Aquest article demostra que, contràriament als sistemes convencionals, els models MoE com DeepSeek-V3/R1 poden aconseguir simultàniament un major rendiment i una menor latència quan utilitzen més GPU en desplegaments multinode en la majoria d'escenaris.

Arquitectures de desplegament

Amplia

Amplia

A causa del gran nombre de petits experts que té el model, els desplegaments s'han de repartir entre diversos dispositius. Vam considerar tant desplegaments d'un sol node en un sol node amb 8 GPU H200 com desplegaments multinode en 8 GPU H100.

Totes dues arquitectures de desplegament aprofiten el paral·lelisme de dades, orquestrat a través del nostre planificador de sol·licituds intern. La implementació del paral·lelisme de dades implica llançar múltiples instàncies de motors d'inferència, cadascuna operant de manera independent per servir i mantenir les sol·licituds. El planificador de sol·licituds, que interactua amb el motor a través de GRPC, s'encarrega de repartir les sol·licituds de la manera més uniforme possible, alhora que facilita la reutilització de KV, enviant sol·licituds amb un prefix parcialment coincidents als servidors que contenen la memòria cau. Les instàncies del motor no abasten diversos nodes. Opcionalment, poden utilitzar el paral·lelisme de tensors per fragmentar l'atenció entre diversos dispositius. Les instàncies estan interconnectades mitjançant NVLink en el cas d'un sol node o InfiniBand per al cas multinode, despachant i recollint experts.

La configuració de desplegament d'un sol node ofereix una latència superior amb mides de lot petites; tanmateix, el rendiment es degrada ràpidament en condicions de càrrega augmentada.

Per desplegar el motor de servei, llancem un pod per node que allotja múltiples instàncies de motors. PyTorch s'encarrega de configurar la comunicació distribuïda i de negociar la inicialització de NVSHMEM. Per a la comunicació, confiem en nuclis CUDA personalitzats descrits en una publicació del blog anterior. La implementació dels dos desplegaments és pràcticament idèntica, i el model tria els nuclis correctes per utilitzar segons el teixit que implementa el paral·lelisme d'experts.

Tècniques de paral·lelització

Abans d'endinsar-nos en les nostres comparacions de rendiment, és essencial entendre les estratègies clau de paral·lelització que fan possible el desplegament de models MoE massius com DeepSeek-V3/R1.

Paral·lelisme de tensors

En la inferència d' LLM, el paral·lelisme de tensors (TP) s'utilitza normalment per reduir l'ús de memòria i el càlcul per GPU, reduint així la latència. Normalment, podem fragmentar les projeccions Linear a les capes d'atenció i MLP al llarg de les dimensions de files o columnes, i fragmentar les operacions d'atenció al llarg de la dimensió del capçal d'atenció.

Amb TP, l'arquitectura Llama-3 no té càlculs duplicats per a les operacions de projecció Linear i d'atenció entre GPU, la qual cosa és un mètode de fragmentació ideal. Tanmateix, en els models DeepSeek-V3/R1, TP no pot aconseguir això.

Els models DeepSeek-V3/R1 utilitzen l'atenció multilatsent (MLA). Una capa MLA utilitza primer una projecció Linear kv_a_proj per calcular el vector latent, i després utilitza una altra projecció Linear kv_b_proj per transformar-lo a l'espai de cada capçal d'atenció. Com que tots els capçals d'atenció comparteixen el mateix vector latent, TP no pot fragmentar el vector latent, de manera que tots els rangs de TP han de replicar els paràmetres i el càlcul de kv_a_proj i kv_b_proj. De la mateixa manera, com que MLA emmagatzema el vector latent a la memòria cau KV, cada rang de TP emmagatzema una còpia idèntica de la memòria cau KV.

Tot i certa duplicació a MLA, el paral·lelisme de tensors encara proporciona una reducció parcial de les demandes de càlcul, la qual cosa el fa valuós per a escenaris que requereixen altes velocitats de sortida.

Paral·lelisme d'experts

Els models DeepSeek-V3/R1 substitueixen les capes MLP per capes MoE. Una capa MoE té 256 experts encaminats i un expert compartit. Cada testimoni s'envia a 8 experts encaminats diferents per al càlcul, i els resultats es sumen ponderadament. Cada testimoni també calcula a l'expert compartit, i el resultat s'afegeix al resultat dels experts encaminats.

El paral·lelisme d'experts (EP) serveix com a enfocament de fragmentació típic per a les capes MoE, amb cada GPU gestionant 256 / EP experts encaminats alhora que manté una còpia de l'expert compartit. En comparació amb TP, l'avantatge de l'EP és que pot distribuir el càlcul entre més GPU, reduint el càlcul i l'ús de memòria per GPU.

Abans de realitzar el càlcul d'experts, totes les GPU han de realitzar una comunicació AllToAll per enviar testimonis a les GPU on es troben els experts corresponents; després del càlcul d'experts, cal una altra comunicació AllToAll per recollir els resultats del càlcul de diverses GPU i realitzar la suma ponderada. Hem implementat una versió optimitzada d'aquests dos nuclis de comunicació AllToAll, Dispatch i Combine, utilitzant NVSHMEM. En la nostra publicació del blog anterior, vam detallar la implementació, i els nostres nuclis s'han publicat en codi obert a GitHub.

Paral·lelisme de dades

Amb l'EP, podem distribuir el càlcul MoE entre 128 o fins i tot més GPU. Tanmateix, el càlcul de MLA no es pot particionar amb l'EP. En aquest punt, podem introduir el paral·lelisme de dades (DP). Cada grup de DP té una còpia completa de la capa MLA. Cada grup de DP accepta diferents entrades i realitza el càlcul de la capa MLA de manera independent.

El DP i el TP de la capa MLA es poden combinar, amb un grup de DP dividit en diversos rangs de TP. L'EP de la capa MoE es pot combinar amb el DP/TP de la capa MLA. EP = DP * TP. Per exemple, en 16 màquines, EP128 DP32 TP4 significa distribuir experts encaminats entre 128 GPU, amb cada 4 GPU formant un grup de DP, per a un total de 32 grups de DP independents.

Un sol node enfront de multinode

Els 671 milions de milions de paràmetres de DeepSeek superen la capacitat de memòria d'una sola màquina H100 de 8 GPU (80 GB * 8), però una sola màquina H200 de 8 GPU pot allotjar completament tot el model (141 GB * 8). Utilitzant la configuració EP8 DP8 TP1, el model utilitza aproximadament 100 GB de memòria per GPU, deixant aproximadament 40 GB per a la memòria cau KV i altres resultats intermedis. Un testimoni ocupa 70.272 bytes de memòria cau KV. Suposant que cada sol·licitud té 5.000 testimonis, cada GPU pot allotjar aproximadament 100 sol·licituds.

Vèrem voler entendre les diferències de rendiment entre els desplegaments d'un sol node i els multinode sota diferents configuracions. Vam utilitzar una màquina H200 per al desplegament d'un sol node i fins a 16 màquines H100 per als desplegaments multinode. Per a cada entorn de desplegament, vam utilitzar combinacions de TP 1, 2, 4, 8 i mides de lot per GPU d'1, 2, 4, 8, 16, 32, 64, 128. Vam suposar que cada sol·licitud tenia una longitud de memòria cau KV de 5.000 testimonis. També vam suposar que la predicció de múltiples testimonis (MTP) prediu 1 testimoni addicional (és a dir, la longitud de consulta de cada sol·licitud és 2) i vam suposar de manera conservadora una taxa d'acceptació del 60%. La figura següent mostra el rendiment i la velocitat de sortida per a diferents configuracions.

Amplia

L'eix horitzontal representa la velocitat de sortida per sol·licitud en testimonis/s. L'eix vertical utilitza una escala logarítmica per mostrar el rendiment per màquina en testimonis/s. Hem marcat la frontera de Pareto per a cada configuració d'EP amb línies de diferents colors.

En escenaris amb requisits de velocitat de sortida extremadament alts, utilitzar un sol node EP8 DP1 TP8 amb una mida de lot d'1 pot aconseguir una velocitat de sortida superior a 100 testimonis/s, però el rendiment és extremadament baix, equivalent a la velocitat de sortida. En aquest escenari, tot el lot només té 2 testimonis, que es poden enviar a com a màxim 2*8=16 experts, activant un total de com a màxim 57 milions de milions de paràmetres.

En el rang de velocitat de sortida de 80-40 testimonis/s, a mesura que augmenta el rendiment, la velocitat de sortida disminueix significativament. Per contra, l'EP128 té un rendiment aproximadament 5 vegades superior al del desplegament d'un sol node a la mateixa velocitat de sortida.

Aquest fenomen es pot explicar examinant com es comporten els desplegaments d'un sol node: augmentar la mida del lot es correspongui directament amb un augment dels experts activats. Quan la mida del lot és 1, el nombre mitjà d'experts activats per GPU és 2 * 8 / 8 = 2. Quan el lot és prou gran, s'activen tots els experts, la qual cosa significa que cada GPU activa 256 / 8 = 32 experts. Activar més experts significa que la GPU necessita llegir més paràmetres de la memòria, augmentant significativament la pressió sobre l'amplada de banda de la memòria. Com que la fase de descodificació dels models de llenguatge gran ja té coll d'ampolla per l'amplada de banda de la memòria en lloc del rendiment de càlcul, augmentar la mida del lot en el desplegament d'un sol node redueix significativament la velocitat de sortida.

La comparació de les quatre configuracions de desplegament multinode (EP16, EP32, EP64 i EP128) revela que els valors d'EP més alts desplacen la frontera de Pareto cap a millores simultànies en el rendiment i la velocitat de sortida.

Utilitzar un nombre d'EP més alt significa que a cada GPU se li assignen menys experts. Per exemple, EP128 significa que cada GPU és responsable de 256 / 128 = 2 experts, de manera que la pressió sobre l'amplada de banda de la memòria es redueix significativament. En altres paraules, utilitzant un nombre d'EP més gran, guanyem efectivament més amplada de banda de memòria. Quan la mida del lot per GPU és inferior a 64, augmentar la mida del lot no afecta significativament la velocitat de càlcul dels experts perquè augmentar el nombre d'entrades no augmenta significativament la pressió sobre l'amplada de banda de la memòria. Per tant, observem que quan s'utilitza EP128, augmentar la mida del lot no afecta la velocitat de sortida de manera tan significativa.

Curiosament, amb mides de lot més grans (64 sol·licituds per GPU), vam observar un nou fenomen: el rendiment del desplegament d'un sol node és lleugerament superior al del desplegament multinode. Part de la raó és que l'NVLink intranode té una amplada de banda superior a l'InfiniBand internode. Una altra part es deu a limitacions de la nostra implementació. Analitzarem aquest fenomen amb més detall més endavant.

A causa de les limitacions de capacitat de memòria, la configuració EP8 DP8 TP1 no pot assolir una mida de lot de 128 per GPU, de manera que el desplegament multinode continua sent una opció millor en escenaris que persegueixen un major rendiment.

Superposició de càlcul i comunicació

Tal com s'ha introduït breument més amunt pel que fa al paral·lelisme d'experts, les GPU estan inactives durant la comunicació de la capa MoE. Per reduir el malbaratament i abaixar la latència, hem de trobar tasques de càlcul independents de les dades per omplir aquest temps d'inactivitat.

Amplia

La part superior de la figura anterior mostra el flux de càlcul d'una capa. El càlcul de MoE depèn de Dispatch, i el càlcul de la capa següent depèn del resultat de Combine.

Col·loquem l'expert compartit a cada GPU. D'aquesta manera, el càlcul de l'expert compartit no requereix comunicació AllToAll. Per tant, podem realitzar el càlcul de l'expert compartit immediatament després de Dispatch Send, i després esperar que es completi Dispatch Recv. Anomenem a aquest esquema de superposició "Dispatch Overlap".

Dispatch Overlap ofereix una implementació senzilla i una àmplia aplicabilitat. Aquesta tècnica amaga el temps de càlcul de l'expert compartit a totes les mides d'EP i mides de lot.

Per augmentar encara més la superposició de càlcul i comunicació, vam utilitzar el lotatge micro esmentat a l'informe tècnic de DeepSeek per trencar la dependència de dades. Tal com es mostra a la part inferior de la figura, vam dividir el càlcul d'una capa Transformer en 5 etapes:

Etapa 1: InputNorm, QKVProj, AppendKV, BMM

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

Etapa 3: Dispatch Send, expert compartit

Etapa 4: Dispatch Recv, MoE, Combine Send

Etapa 5: Combine Recv

En les primeres 3 capes Dense Transformer, utilitzem tot el lot. En les 58 capes MoE Transformer següents, dividim uniformement el lot en dos microots. Els dos microots s'executen alternativament, desfasats en 3 etapes. Com que no hi ha dependència de dades entre aquests dos microots, podem canviar al càlcul d'un altre microot després de Dispatch Send i després de Combine Send.

Desglossament de la latència

A continuació, comparem els efectes de la superposició mitjançant un experiment, així com les diferències de rendiment entre el desplegament d'un sol node EP8 i el desplegament multinode EP128. Per facilitar la comparació, hem utilitzat GPU H100 per al següent experiment. Hem utilitzat TP1, una mida de lot de 128 per GPU, una longitud de consulta de 2 per sol·licitud i una longitud de memòria cau KV de 5000.

Amplia

La figura anterior mostra el temps total dedicat a una capa MoE Transformer i la proporció de latència de diferents tipus de nuclis. Excepte per a Dispatch, Combine i GroupGEMM, el temps d'execució d'altres nuclis hauria de ser el mateix a les sèries EP8, EP128 NoOverlap i EP128 DispatchOverlap perquè la mida del lot és la mateixa.

Superposició

Primer comparem els efectes dels tres mètodes de superposició. NoOverlap va trigar 2667 µs en total, DispatchOverlap va trigar 2651 µs, estalviant 16 µs o només un 0,6%. MicroBatch va mostrar una millora molt significativa, trigant 1896 µs, una acceleració del 29%. Tant el temps de Dispatch com el de Combine es van reduir significativament. Dispatch va disminuir de 593 µs a 367 µs, i Combine de 1012 µs a 237 µs.

Tingueu en compte que per als nuclis de càlcul, dividir un lot de mida 128 en dos lots de mida 64 augmenta el temps total d'execució. Per tant, tot i que el temps dedicat a la comunicació es va reduir en 1001 µs, el temps total només es va reduir en 771 µs. Explicarem el motiu utilitzant el model Roofline a la secció següent.

Per aquest motiu, el lotatge micro no sempre millora el rendiment.

Amplia

La figura anterior mostra la millora del rendiment de Microbatch en comparació amb DispatchOverlap per a mides de lot de 4 a 128. Quan la mida del lot és inferior a 32, Microbatch redueix el rendiment entre un 5% i un 40%. Quan la mida del lot és superior o igual a 32, Microbatch pot millorar el rendiment entre un 10% i un 35%.

EP8 enfront de EP128

Tornem a la figura anterior i comparem EP8 i EP128 Microbatch. EP8 va trigar 1802 µs en total, lleugerament menys que els 1896 µs de l'EP128. A més de l'augment del temps d'execució del nucli aportat per Microbatch esmentat anteriorment, les principals diferències es troben a GroupGEMM utilitzat per al càlcul de MoE i els dos nuclis de comunicació, Dispatch i Combine.

El GroupGEMM de l'EP8 va trigar 555 µs, mentre que el GroupGEMM de l'EP128 va trigar 270 µs, reduint-se a la mitad. Aquest és l'avantatge principal del desplegament multinode.

Malauradament, el temps dedicat a la comunicació va augmentar en 213 µs, la qual cosa va compensar en gran mesura l'avantatge de GroupGEMM. En proves de rendiment separades dels nostres nuclis de comunicació, vam trobar que només poden aconseguir la meitat de l'amplada de banda d'InfiniBand. Continuarem optimitzant els nostres nuclis de comunicació.

Un altre nucli que es queda significativament enrere és GEMM. Microbatch va augmentar GEMM en 95 µs. Analitzarem GEMM amb més profunditat a la secció Roofline a continuació. Creiem que la implementació actual de GEMM encara no ha aconseguit un rendiment òptim.

Roofline

El model Roofline és una bona eina per analitzar el rendiment dels nuclis. El seu eix horitzontal és la intensitat aritmètica, la relació entre FLOP i bytes d'E/S de memòria. El valor de l'eix horitzontal es pot calcular directament a partir de la semàntica del nucli. L'eix vertical representa el rendiment aconseguit, calculat dividint FLOP per la latència de referència.

El límit superior teòric del rendiment del nucli està determinat directament per les especificacions de la GPU. El rendiment pic de FP8 de l'H100 és de 1979 TFLOP/s, representat com a línia horitzontal al model Roofline. L'amplada de banda de la memòria de l'H100 és de 3,35 TB/s, representada com el pendent d'una línia que passa per l'origen. Les dues línies proporcionen els límits de rendiment per als nuclis limitats per càlcul i limitats per memòria, respectivament.

A continuació, parlem del rendiment dels nuclis GroupGEMM i GEMM.

GroupGEMM

El nucli GroupGEMM a MoE realitza el càlcul següent: Hi ha g grups en total, el i-èsim grup té m_i testimonis, realitzant una multiplicació de matrius de [m_i, k] x [k, n] -> [m_i, n]. En les proves de rendiment, suposem que el nombre de testimonis de cada grup és el mateix, denotat com a m_i = m. Aleshores, el recompte de FLOP per a GroupGEMM és 2 * g * m * k * n, i els bytes d'E/S de memòria són g * (m * k + n * k + m * n).

En el model DeepSeek-V3/R1, hi ha 256 experts, i cada testimoni s'envia a 8 experts per al càlcul. Suposant una mida de lot de 128, una longitud de consulta de 2, utilitzant la configuració EP128 DP128, el nombre mitjà de testimonis rebuts per cada expert (és a dir, m) és 128 * 2 * 8 * 128 / 256 = 1024. De la mateixa manera, podem calcular m per a altres configuracions i mides de lot.

Hem utilitzat la implementació GroupGEMM de DeepGEMM per a les proves de rendiment. Els punts de prova van cobrir combinacions de configuracions EP8, EP16, EP32, EP64, EP128 amb TP1 i mides de lot d'1-128.

Amplia

La figura anterior mostra el model Roofline per a GroupGEMM sota diferents configuracions d'EP. Diferents EP corresponen a diferents nombres de grups. La figura il·lustra línies de rendiment gairebé superposades, indicant que el rendiment de GroupGEMM està determinat predominantment pel recompte total de testimonis (representat com a g * m).

Les estrelles marquen els punts de dades corresponents a una mida de lot de 128 per GPU per a cada configuració d'EP. Comparant aquests punts de dades amb estrelles, podem veure que a mesura que l'EP augmenta (i el DP augmenta sincrònicament), el nombre de testimonis per expert m també augmenta. A l'EP8, m=128, mentre que a l'EP128, m=2048.

A mesura que m augmenta, la intensitat aritmètica també augmenta. En la majoria de configuracions, GroupGEMM està limitat per l'amplada de banda de la memòria, de manera que augmentar m millora el rendiment.

GEMM

El nucli GEMM correspon a les projeccions Linear del model, com ara la projecció Q/K/V/O. Per a una multiplicació de matrius de [m, k] x [k, n] -> [m, n], el recompte de FLOP és 2 * m * k * n, i els bytes d'E/S de memòria són m * k + n * k + m * n. També podem provar la latència per a mides de lot d'1-128.

Amplia

La figura anterior mostra el model Roofline per a GEMM sota diferents configuracions d'EP. Podem veure que el rendiment de GEMM està limitat per l'amplada de banda de la memòria. A mesura que augmenta la mida del lot, la intensitat aritmètica també augmenta, millorant així el rendiment.

Microbatch

Quan s'utilitza el lotatge micro, dividim el lot uniformement en dues parts. A partir de les dues figures anteriors, podem veure que quan m es converteix en m/2, l'eficiència de la multiplicació de matrius disminueix. Per tant, executar dues multiplicacions de matrius de mida m/2 triga més que executar una multiplicació de matrius de mida m.

Predicció de múltiples testimonis

Al llarg d'aquest article, hem suposat l'ús de la predicció de múltiples testimonis (MTP) per a la descodificació especulativa. L'MTP canvia la longitud de consulta per sol·licitud d'1 a 2. Per a la multiplicació de matrius, això equival a canviar m a m * 2, augmentant així l'eficiència de la multiplicació de matrius. D'altra banda, si dibuixem el model Roofline per a MLA, trobaríem que augmentar la longitud de la consulta augmenta significativament l'eficiència del nucli MLA.

Per tant, l'ús de l'MTP juga un paper important en l'eficiència del model.

Implementació i optimitzacions

En aquesta secció, introduirem alguns detalls d'implementació i optimització per al nostre model DeepSeek-V3/R1.

Quantificació

DeepSeek-V3/R1 es va entrenar de manera nativa en FP8 utilitzant un esquema de quantificació per bloc, amb pesos quantificats estàticament i activacions quantificades sobre la marxa. En lloc de calcular un factor d'escalat per canal o per matriu estàticament, els factors d'escalat es calculen a través de vectors de 128 elements per a les activacions i tessel·les de 128x128 elements per a les matrius, limitant la degradació de la precisió a causa de la quantificació.

A Perplexity, confiem en una barreja de nuclis CUDA i Triton per donar suport a la inferència, amb CUDA utilitzat per als nuclis més sensibles al rendiment i modificats amb poca freqüència (com ara l'atenció i GEMM), i Triton implementant una àmplia gamma de nuclis d'activació, normalització i utilitat. Triton ens va permetre adaptar ràpidament els nuclis a l'esquema de quantificació per bloc.

Per a les capes lineals i MoE, barregem els nuclis Deep GEMM amb els nostres propis nuclis Triton GEMM, ja que hem observat que per a certes dimensions de matrius i mides de lot baixes, Split-K ofereix una latència més baixa. Si la capa no quantificada realitza una multiplicació (M, K) x (K, N), necessita un factor d'escalat (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) per a la quantificació per bloc. Per a la quantificació per bloc, els factors d'escalat per a les activacions es calculen sobre la marxa, en lloc de precalibrar-se. Com que els factors d'escalat d'activació s'agreguen només al llarg de la dimensió K i no al llarg de la M, els nuclis només requereixen lleugeres alteracions per donar suport a l'esquema.

Amplia

La funció d'activació SiLU utilitzada per DeepSeek-V3/R1 va requerir canvis substancials per donar suport als grafs CUDA, la quantificació per bloc i el recompte de testimonis encaminats dinàmicament. La quantificació per bloc pot ser problemàtica, ja que introdueix reduccions horitzontals, però el nucli ja havia fragmentat les activacions al llarg de la seva dimensió oculta en blocs de 1024 elements. Dins d'un bloc, el tensor a quantificar es fragmentava encara més en blocs de 128 per calcular el valor absolut més gran, amb Triton generant reduccions màximes entre unions eficients, afegint una sobrecàrrega mínima.

Per donar suport a l'encaminament MoE sota els grafs CUDA, els nuclis han de conèixer la informació d'encaminament que indica el nombre de testimonis per expert, en lloc de planificar el treball basant-se en la mida dels búfers que es van assignar per contenir el límit superior del recompte de testimonis. No podem dividir el problema en funció de les dimensions del tensor d'entrada, de manera que llancem un nombre fix de nuclis persistents que llegeixen la informació d'encaminament per determinar quants testimonis s'omplen i divideixen el treball de processament de les activacions entre ells de manera dinàmica.

Ja hem pujat alguns dels nostres nuclis al projecte FlashInfer i en el futur publicarem més del nostre codi en codi obert.

Capa MLA

Utilitzem FlashInfer per al càlcul de MLA. FlashInfer admet configuracions de taula de pàgines flexibles i un rendiment extremadament alt.

Hem fusionat q_a_proj i kv_a_proj en un únic qkv_a_proj. La latència va disminuir de 15,4 µs + 14,8 µs = 30,2 µs a 16,7 µs.

Hem descompost kv_b_proj en dues matrius, k_b_proj i v_b_proj. Hem escrit un nucli BMM quantificat per blocs FP8 per als càlculs relacionats amb aquestes dues matrius.

Graf CUDA

El graf CUDA pot reduir significativament la sobrecàrrega de llançament de nuclis, la qual cosa és crucial per al rendiment. Creem un graf CUDA per a cada mida de lot.

Abans de desenvolupar el nostre nucli AllToAll, vam utilitzar torch.all_to_all_single() per a la comunicació AllToAll. Aquesta operació requereix que totes les GPU utilitzin la mateixa mida de lot. Tanmateix, diferents grups de DP poden executar diferents mides de lot.

Per garantir que all_to_all_single() sigui compatible amb diferents grups de DP que utilitzen diferents mides de lot, vam utilitzar primer una operació allreduce() abans de cada execució del model per obtenir la mida de lot màxima entre tots els grups de DP. Després vam fer que tots els grups de DP utilitzessin aquesta mida de lot per executar-se.

Tot i que aquest enfocament garanteix que podem utilitzar el graf CUDA, té tres desavantatges. Primer, requereix una operació allreduce() addicional. Segon, els grups de DP amb mides de lot més petites es veuen obligats a afegir farciment. Tercer, fa que el nostre codi d'implementació sigui complex.

Després d'implementar el nostre propi nucli AllToAll, ja no requerim que totes les GPU utilitzin la mateixa mida de lot. per tant, ja no necessitem realitzar operacions allreduce() addicionals ni afegir farciment a les mides de lot.

Encaminador MoE

L'encaminador MoE s'implementa a Triton, basant-se en una ordenació modificada derivada de la biblioteca estàndard que també fa un seguiment dels índexs dels elements ordenats. La implementació es comparteix entre tots els models MoE, ja que l'encaminament de Mixtral és un cas especial de les rutes de DeepSeek on el grup Top-K és el mateix que el grup de tots els experts. Els nuclis dispersos consumeixen directament els índexs i les puntuacions Top-K, mentre que els esquemes de despatx/combinació densos que es basen en all-to-all requereixen que la informació d'encaminament s'agregui per expert en lloc de per testimoni.

Treball futur

En treballs futurs, tenim previst optimitzar encara més el rendiment del model DeepSeek.

La següent optimització més important és la desagregaçó de la prefeta (Prefill Disaggregation). La fase de prefeta (Prefill) i la fase de descodificació (Decode) del model DeepSeek-V3/R1 tenen característiques computacionals molt diferents. Ambdues poden utilitzar diferents estratègies d'optimització i esquemes de desplegament.

Per a la capa MLA, a la fase de descodificació, utilitzem l'absorció de matrius per reduir el recompte de FLOP del càlcul de MLA. A la fase de prefeta, projectar primer el vector latent a l'espai K/V i després calcular en forma d'atenció multi-capçal (MHA) funcionaria millor.

Si la prefeta i la descodificació s'executen a la mateixa GPU, per reduir l'impacte de la prefeta en la velocitat de sortida de la descodificació, normalment utilitzem la prefeta fragmentada (chunked prefill) per dividir la consulta en diversos fragments per a la prefeta. Com que la memòria cau KV emmagatzema el vector latent, es fa difícil convertir MLA en forma MHA.

Per a la capa MoE, a la fase de descodificació, utilitzem EP i DP tan grans com sigui possible per augmentar el nombre de testimonis d'entrada per expert, millorant així el rendiment de GroupGEMM. A la fase de prefeta, com que el nombre de testimonis ja és prou gran, GroupGEMM ja està limitat per càlcul. Per tant, per a la prefeta, podem utilitzar EP i DP més petits.

Si la prefeta i la descodificació s'executen a la mateixa GPU, mentre qualsevol grup de DP estigui realitzant la prefeta, la latència de les capes MoE a totes les GPU augmentarà, afectant significativament la velocitat de sortida de la descodificació.

A part de la desagregaçó de la prefeta, també tenim previst optimitzar els aspectes següents:

Rendiment d'AllToAll: el nostre nucli AllToAll actualment només pot aconseguir 1/3 de l'amplada de banda d'InfiniBand. Continuarem optimitzant aquest nucli.

Descodificació especulativa a l'estil EAGLE: en les dades anteriors, vam suposar l'ús de la descodificació especulativa per predir 1 testimoni. EAGLE pot utilitzar una estructura d'arbre per predir múltiples testimonis, millorant la longitud d'acceptació, la qual cosa pot augmentar significativament la velocitat de sortida.

Nucli GEMM: en el model Roofline mostrat anteriorment, podem comprovar que l'eficiència del nucli GEMM encara està lluny del límit teòric. Continuarem optimitzant aquest nucli.

GB200 NVL72: en l'última solució GB200 NVL72 d'NVIDIA, 72 GPU Blackwell estan interconnectades mitjançant NVLink d'alta velocitat. Per als models d'arquitectura MoE, això és un repte i una oportunitat molt grans.

Conclusió

El desplegament multinode dels models DeepSeek MoE aconsegueix el que normalment és impossible amb els LLM densos: millorar simultàniament tant el rendiment com la latència. Distribuint els experts entre més GPU, reduïm la pressió sobre l'amplada de banda de la memòria per dispositiu, permetent un processament més ràpid i un major rendiment del sistema. Els nostres experiments mostren que les configuracions EP128 aconsegueixen un rendiment fins a 5 vegades superior a velocitats de sortida equivalents en comparació amb els desplegaments d'un sol node.

Les tècniques de superposició de càlcul i comunicació, com el lotatge micro, redueixen significativament la sobrecàrrega de comunicació multinode, i la nostra implementació mostra una acceleració de fins al 40%. Els nostres nuclis de comunicació AllToAll personalitzats i les implementacions de nuclis optimitzats han permès el desplegament eficient del model de 671 milions de milions de paràmetres.

A mesura que les arquitectures MoE guanyen popularitat per la seva capacitat, aquestes estratègies de desplegament proporcionen informació valuosa per escalar aquests models de manera eficient.

Referències

Informe tècnic de DeepSeek-V3

Visió general del sistema d'inferència DeepSeek-V3/R1

Megatron-LM: Entrenament de models de llenguatge de milers de milions de paràmetres utilitzant el paral·lelisme de models

EAGLE: el mostreig especulatiu requereix replantejar-se la incertesa de les característiques

Citació

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