మల్టీ-నోడ్ డీప్‌సీక్ డిప్లాయ్‌మెంట్‌తో తక్కువ లేటెన్సీ మరియు అధిక త్రూపుట్

చాలా సిస్టమ్‌లలో, లేటెన్సీ మరియు త్రూపుట్ అనేవి తరచుగా ఒకదానికొకటి విరుద్ధంగా ఉండే లక్ష్యాలు, వీటిని డిజైన్ మరియు డిప్లాయ్‌మెంట్ సమయంలో రాజీపడాల్సి వస్తుంది. ఉదాహరణకు, డెన్స్ లార్జ్ లాంగ్వేజ్ మోడల్స్‌లో, బ్యాచ్ పరిమాణాన్ని పెంచడం వల్ల త్రూపుట్ మెరుగుపడుతుంది కానీ లేటెన్సీ కూడా పెరుగుతుంది; ఒకే మెషీన్ లో టెన్సర్ సమాంతరతను పెంచడం వల్ల లేటెన్సీ తగ్గుతుంది కానీ రెప్లికాల సంఖ్య తగ్గి, త్రూపుట్ తగ్గుతుంది.

డీప్‌సీక్-వి3/ఆర్1 (DeepSeek-V3/R1) వంటి మిక్చర్ ఆఫ్ ఎక్స్‌పర్ట్స్ (MoE) మోడల్స్ ఇటీవల అద్భుతమైన మోడల్ సామర్థ్యాలను మరియు ఆపరేషనల్ ఎఫిషియెన్సీని ప్రదర్శించాయి. ఉదాహరణకు, DeepSeek-V3/R1 మోడల్ మొత్తం 671B పారామీటర్లను కలిగి ఉంది, కానీ ఇన్ఫరెన్స్ సమయంలో ప్రతి టోకెన్ కేవలం 37B పారామీటర్లను మాత్రమే ఉపయోగిస్తుంది. ఈ మోడల్ ఆర్కిటెక్చర్ ఇన్ఫరెన్స్ సిస్టమ్స్ కోసం సవాళ్లను మరియు అవకాశాలను రెండింటినీ అందిస్తుంది.

ఈ వ్యాసం చూపిస్తోంది, సాంప్రదాయ వ్యవస్థలకు విరుద్ధంగా, DeepSeek-V3/R1 వంటి MoE మోడళ్లు బహుళ-నోడ్ డిప్లాయ్‌మెంట్‌లలో మరిన్ని GPUలను ఉపయోగించినప్పుడు ఒకేసారి అధిక throughput మరియు తక్కువ latency సాధించగలవు — చాలా సందర్భాల్లో.

డిప్లాయ్‌మెంట్ ఆర్కిటెక్చర్లు

విస్తరించు

విస్తరించు

మోడల్ కలిగి ఉన్న పెద్ద సంఖ్యలో చిన్న నిపుణుల (experts) కారణంగా, డిప్లాయ్‌మెంట్‌లను బహుళ పరికరాలలో విస్తరించాలి. మేము 8xH200 GPUలతో కూడిన ఒకే నోడ్‌పై సింగిల్-నోడ్ డిప్లాయ్‌మెంట్‌లను మరియు 8xH100 GPUలపై మల్టీ-నోడ్ డిప్లాయ్‌మెంట్‌లను పరిగణలోకి తీసుకున్నాము.

రెండు డిప్లాయ్‌మెంట్ ఆర్కిటెక్చర్లు మా ఇంట్లోని request scheduler ద్వారా సమన్వయం చేయబడే Data Parallelism‌ను ఉపయోగిస్తాయి. Data parallelism అమలు అనేది ప్రతి ఒక్కటి స్వతంత్రంగా inference requests‌ను సర్వ్ చేసి నిర్వహించేలా అనేక inference engine instances‌ను ప్రారంభించడం. engineతో GRPC ద్వారా పరస్పరం చేసే request scheduler, requests‌ను సాధ్యమైనంత సమంగా పంచడంలో బాధ్యత వహిస్తుంది; అలాగే KV re-use‌ను సులభతరం చేస్తూ, partially matched prefix ఉన్న requests‌ను cache కలిగిన servers‌కు పంపుతుంది. Engine instances అనేవి multiple nodes across span కావు. వారు కావాలనుకుంటే tensor parallelism‌ను ఉపయోగించి attention‌ను multiple devices across shard చేయగలరు. single-node సందర్భంలో instances NVLink ద్వారా, multi-node సందర్భంలో InfiniBand ద్వారా పరస్పరం అనుసంధానించబడి, experts‌ను dispatch చేసి collect చేస్తాయి.

సింగిల్-నోడ్ డిప్లాయ్‌మెంట్ కాన్ఫిగరేషన్ చిన్న బ్యాచ్ పరిమాణాలతో మెరుగైన లేటెన్సీని అందిస్తుంది; అయినప్పటికీ, పెరిగిన లోడ్ పరిస్థితులలో పనితీరు వేగంగా క్షీణిస్తుంది.

సర్వింగ్ ఇంజిన్‌ను డిప్లాయ్ చేయడానికి, బహుళ ఇంజిన్ ఇన్‌స్టాన్స్‌లను హోస్ట్ చేసే ప్రతి నోడ్‌కు ఒక పాడ్‌ను మేము ప్రారంభిస్తాము. డిస్ట్రిబ్యూటెడ్ కమ్యూనికేషన్‌ను సెటప్ చేయడానికి మరియు NVSHMEM ఇనిషియలైజేషన్‌ను చర్చించడానికి PyTorch బాధ్యత వహిస్తుంది. కమ్యూనికేషన్ కోసం, మేము మునుపటి బ్లాగ్ పోస్ట్లో వివరించిన కస్టమ్ CUDA కెర్నళ్లపై ఆధారపడతాము. ఎక్స్‌పర్ట్ ప్యారలెలిజమ్‌ను అమలు చేసే ఫ్యాబ్రిక్ ఆధారంగా ఉపయోగించడానికి సరైన కెర్నళ్లను మోడల్ ఎంచుకోవడంతో, రెండు డిప్లాయ్‌మెంట్‌ల అమలు దాదాపు ఒకేలా ఉంటుంది.

సమాంతరీకరణ పద్ధతులు

మా performance comparisons‌లోకి వెళ్లే ముందు, DeepSeek-V3/R1 వంటి భారీ MoE మోడళ్లను deploy చేయడం సాధ్యమయ్యేలా చేసే key parallelization strategies‌ను అర్థం చేసుకోవడం అవసరం.

టెన్సర్ ప్యారలెలిజమ్

LLM inference‌లో, Tensor Parallelism (TP) సాధారణంగా ప్రతి GPUపై memory usage మరియు computation‌ను తగ్గించడానికి ఉపయోగించబడుతుంది, తద్వారా latency తగ్గుతుంది. సాధారణంగా, Attention మరియు MLP Layers‌లోని Linear Projections‌ను row లేదా column dimensions לאורך shard చేయవచ్చు, అలాగే attention head dimension לאורך Attention operations‌ను shard చేయవచ్చు.

TPతో, Llama-3 ఆర్కిటెక్చర్‌లో GPUలలో Linear ప్రొజెక్షన్ మరియు అటెన్షన్ ఆపరేషన్‌ల కోసం డూప్లికేటెడ్ కంప్యూటేషన్ ఉండదు, ఇది ఆదర్శవంతమైన షార్డింగ్ పద్ధతి. అయితే, DeepSeek-V3/R1 మోడల్స్‌లో, TP దీన్ని సాధించలేదు.

DeepSeek-V3/R1 models Multi-Latent Attention (MLA)ను ఉపయోగిస్తాయి. MLA Layer ముందుగా latent vector‌ను గణించడానికి ఒక Linear Projection kv_a_projను ఉపయోగిస్తుంది, ఆపై దాన్ని ప్రతి attention head స్థలానికి మార్పు చేయడానికి మరో Linear Projection kv_b_projను ఉపయోగిస్తుంది. అన్ని attention heads ఒకే latent vector‌ను పంచుకుంటాయి కాబట్టి, TP latent vector‌ను shard చేయలేడు; అందువల్ల అన్ని TP Ranks‌లు kv_a_proj మరియు kv_b_proj యొక్క parameters మరియు computation‌ను replicate చేయాలి. అలాగే, MLA latent vector‌ను KV Cache‌లో నిల్వ చేస్తుంది కాబట్టి, ప్రతి TP Rank ఒకేలా ఉన్న KV Cache ప్రతిని నిల్వ చేస్తుంది.

MLAలో కొంత నకిలీ ఉన్నప్పటికీ, టెన్సర్ ప్యారలెలిజమ్ ఇప్పటికీ కంప్యూటేషన్ డిమాండ్లలో పాక్షిక తగ్గింపును అందిస్తుంది, ఇది అధిక అవుట్‌పుట్ వేగం అవసరమయ్యే దృశ్యాలకు దీన్ని విలువైనదిగా చేస్తుంది.

ఎక్స్‌పర్ట్ ప్యారలెలిజమ్

DeepSeek-V3/R1 మోడల్స్ MLP లేయర్‌లను MoE లేయర్‌లతో భర్తీ చేస్తాయి. ఒక MoE లేయర్ 256 రూటెడ్ ఎక్స్‌పర్ట్‌లను మరియు ఒక షేర్డ్ ఎక్స్‌పర్ట్‌ను కలిగి ఉంటుంది. ప్రతి టోకెన్ కంప్యూటేషన్ కోసం 8 వేర్వేరు రూటెడ్ ఎక్స్‌పర్ట్‌లకు పంపబడుతుంది, మరియు ఫలితాలు వెయిటెడ్ సమ్ చేయబడతాయి. ప్రతి టోకెన్ షేర్డ్ ఎక్స్‌పర్ట్‌లో కూడా లెక్కింపబడుతుంది, మరియు ఫలితం రూటెడ్ ఎక్స్‌పర్ట్‌ల ఫలితానికి జోడించబడుతుంది.

ఎక్స్‌పర్ట్ ప్యారలెలిజమ్ (EP) అనేది MoE లేయర్‌ల కోసం సాధారణ షార్డింగ్ విధానంగా పనిచేస్తుంది, ప్రతి GPU 256 / EP రూటెడ్ ఎక్స్‌పర్ట్‌లను నిర్వహిస్తూ షేర్డ్ ఎక్స్‌పర్ట్ యొక్క కాపీని నిర్వహిస్తుంది. TPతో పోలిస్తే, EP యొక్క ప్రయోజనం ఏమిటంటే ఇది బహుళ GPUలలో కంప్యూటేషన్‌ను పంపిణీ చేయగలదు, ప్రతి GPUకి కంప్యూటేషన్ మరియు మెమరీ వినియోగాన్ని తగ్గిస్తుంది.

expert computation‌కు ముందు, సంబంధిత experts ఉన్న GPUs‌కు tokens‌ను dispatch చేయడానికి అన్ని GPUs కూడా AllToAll communication‌ను చేయాలి; expert computation తర్వాత, వివిధ GPUs నుండి computation results‌ను సేకరించి weighted summation చేయడానికి మరో AllToAll communication అవసరం. ఈ రెండు AllToAll communication Kernels, Dispatch మరియు Combine, యొక్క optimized version‌ను మేము NVSHMEM ఉపయోగించి అమలు చేశాం. మా గత blog postలో, implementation‌ను వివరించాము, మరియు మా kernels GitHubలో open-sourced చేయబడ్డాయి.

డేటా ప్యారలెలిజమ్

EPతో, మేము 128 లేదా అంతకంటే ఎక్కువ GPUలలో MoE కంప్యూటేషన్‌ను పంపిణీ చేయవచ్చు. అయితే, MLA కంప్యూటేషన్‌ను EPతో విభజించలేము. ఈ సమయంలో, మనం డేటా ప్యారలెలిజమ్ (DP)ని పరిచయం చేయవచ్చు. ప్రతి DP గ్రూప్ MLA లేయర్ యొక్క పూర్తి కాపీని కలిగి ఉంటుంది. ప్రతి DP గ్రూప్ వేర్వేరు ఇన్‌పుట్‌లను అంగీకరిస్తుంది మరియు స్వతంత్రంగా MLA లేయర్ కంప్యూటేషన్‌ను నిర్వహిస్తుంది.

MLA layer యొక్క DP మరియు TP‌ను కలపవచ్చు, ఒక DP Group‌ను అనేక TP Ranks‌లుగా విభజిస్తూ. MoE layer యొక్క EP‌ను MLA Layer యొక్క DP/TPతో కలపవచ్చు. EP = DP * TP. ఉదాహరణకు, 16 machinesపై, EP128 DP32 TP4 అంటే routed experts‌ను 128 GPUs across పంపిణీ చేయడం, ప్రతి 4 GPUs ఒక DP Group‌ను ఏర్పరచడం ద్వారా, మొత్తం 32 independent DP Groups అవుతాయి.

సింగిల్-నోడ్ vs మల్టీ-నోడ్

డీప్‌సీక్ యొక్క 671B పారామీటర్లు ఒకే 8-GPU H100 మెషీన్ మెమరీ సామర్థ్యాన్ని మించిపోతాయి (80 GB * 8), కానీ ఒకే 8-GPU H200 మెషీన్ మొత్తం మోడల్‌ను పూర్తిగా ఇముడ్చుకోగలదు (141 GB * 8). EP8 DP8 TP1 కాన్ఫిగరేషన్‌ను ఉపయోగించి, మోడల్ ప్రతి GPUకి దాదాపు 100 GB మెమరీని ఉపయోగిస్తుంది, KV కాష్ మరియు ఇతర మధ్యంతర ఫలితాల కోసం సుమారు 40 GBని వదిలివేస్తుంది. ఒక టోకెన్ KV కాష్‌లో 70,272 బైట్లను ఆక్రమిస్తుంది. ప్రతి అభ్యర్థనకు 5,000 టోకెన్లు ఉన్నాయని అనుకుంటే, ప్రతి GPU సుమారు 100 అభ్యర్థనలను ఇముడ్చుకోగలదు.

వివిధ configurations కింద single-node మరియు multi-node deployments మధ్య performance differences‌ను అర్థం చేసుకోవాలనుకున్నాము. single-node deployment కోసం ఒక H200 machine‌ను, multi-node deployments కోసం గరిష్ఠంగా 16 H100 machines‌ను ఉపయోగించాము. ప్రతి deployment environment కోసం, TP 1, 2, 4, 8 కలయికలను మరియు ప్రతి GPUకు batch sizes 1, 2, 4, 8, 16, 32, 64, 128‌ను ఉపయోగించాము. ప్రతి request‌కు KV Cache length 5,000 tokens అని అనుకున్నాము. Multi-Token Prediction (MTP) 1 అదనపు token‌ను predict చేస్తుందని (అంటే, ప్రతి request యొక్క query length 2) కూడా అనుకుని, acceptance rate‌ను 60%గా సంరక్షణాత్మకంగా ఊహించాము. క్రింది figure వివిధ configurations కోసం throughput మరియు output speed‌ను చూపిస్తుంది.

విస్తరించు

క్షితిజ సమాంతర అక్షం టోకెన్లు/సెకనులో ప్రతి అభ్యర్థనకు అవుట్‌పుట్ వేగాన్ని సూచిస్తుంది. నిలువు అక్షం టోకెన్లు/సెకనులో ప్రతి మెషీన్‌కు త్రూపుట్‌ను చూపించడానికి లాగరిథమిక్ స్కేల్‌ను ఉపయోగిస్తుంది. మేము ప్రతి EP కాన్ఫిగరేషన్ కోసం పారేటో ఫ్రాంటియర్‌ను వేర్వేరు రంగుల గీతలతో గుర్తించాము.

అత్యంత అధిక అవుట్‌పుట్ వేగ అవసరాలున్న దృశ్యాలలో, బ్యాచ్ పరిమాణం 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 numberను ఉపయోగించడం అంటే ప్రతి GPUకి కేటాయించే experts సంఖ్య తక్కువగా ఉండడం. ఉదాహరణకు, EP128 అంటే ప్రతి GPU 256 / 128 = 2 experts‌కు బాధ్యత వహిస్తుంది, కాబట్టి memory bandwidth pressure గణనీయంగా తగ్గుతుంది. మరో మాటలో, పెద్ద EP numberను ఉపయోగించడం ద్వారా, మేము ప్రభావవంతంగా మరింత memory bandwidth‌ను పొందుతాము. ప్రతి GPU batch size 64 కంటే తక్కువగా ఉన్నప్పుడు, batch sizeను పెంచడం expert computation speed‌ను గణనీయంగా ప్రభావితం చేయదు, ఎందుకంటే inputs సంఖ్యను పెంచడం memory bandwidth pressure‌ను గణనీయంగా పెంచదు. అందువల్ల, EP128ను ఉపయోగించినప్పుడు, batch sizeను పెంచడం output speed‌ను అంతగా ప్రభావితం చేయదని గమనించాము.

ఆసక్తికరంగా, పెద్ద batch sizes (GPUకు 64 requests) వద్ద, మేము ఒక కొత్త phenomenon‌ను గమనించాము: single-node deployment throughput multi-node deployment కంటే కొద్దిగా ఎక్కువగా ఉంది. ఇందుకు ఒక కారణం intra-node NVLink‌కు inter-node InfiniBand కంటే అధిక bandwidth ఉండడం. మరో కారణం మా implementationలో ఉన్న పరిమితులు. ఈ phenomenon‌ను తరువాత మరింత వివరంగా విశ్లేషిస్తాము.

మెమరీ సామర్థ్య పరిమితుల కారణంగా, EP8 DP8 TP1 కాన్ఫిగరేషన్ ప్రతి GPUకి 128 బ్యాచ్ పరిమాణాన్ని చేరుకోలేదు, కాబట్టి అధిక త్రూపుట్‌ను కోరుకునే దృశ్యాలలో మల్టీ-నోడ్ డిప్లాయ్‌మెంట్ ఇప్పటికీ మెరుగైన ఎంపిక.

కంప్యూటేషన్ మరియు కమ్యూనికేషన్ ఓవర్‌లాపింగ్

ఎక్స్‌పర్ట్ ప్యారలెలిజమ్ గురించి పైన సంక్షిప్తంగా పరిచయం చేసినట్లుగా, MoE లేయర్ కమ్యూనికేషన్ సమయంలో GPUలు నిష్క్రియంగా (idle) ఉంటాయి. వ్యర్థాలను తగ్గించడానికి మరియు లేటెన్సీని తక్కువ చేయడానికి, ఈ నిష్క్రియ సమయాన్ని భర్తీ చేయడానికి మేము డేటా-స్వతంత్ర కంప్యూటేషన్ పనులను కనుగొనవలసి ఉంది.

విస్తరించు

పైన పేర్కొన్న చిత్రంలో పై భాగం ఒక లేయర్ యొక్క కంప్యూటేషన్ ప్రవాహాన్ని చూపుతుంది. MoE కంప్యూటేషన్ డిస్పాచ్‌పై ఆధారపడి ఉంటుంది, మరియు తదుపరి లేయర్ యొక్క కంప్యూటేషన్ కంబైన్ ఫలితంపై ఆధారపడి ఉంటుంది.

మేము ప్రతి GPUపై షేర్డ్ ఎక్స్‌పర్ట్‌ను ఉంచుతాము. ఈ విధంగా, షేర్డ్ ఎక్స్‌పర్ట్ కంప్యూటేషన్‌కు AllToAll కమ్యూనికేషన్ అవసరం లేదు. అందువల్ల, డిస్పాచ్ సెండ్ పూర్తయిన వెంటనే మనం షేర్డ్ ఎక్స్‌పర్ట్ కంప్యూటేషన్‌ను నిర్వహించవచ్చు, ఆపై డిస్పాచ్ రెక్వ్ పూర్తయ్యే వరకు వేచి ఉండవచ్చు. మేము ఈ ఓవర్‌లాప్ పథకాన్ని "డిస్పాచ్ ఓవర్‌లాప్" అని పిలుస్తాము.

డిస్పాచ్ ఓవర్‌లాప్ సూటియైన అమలును మరియు విస్తృత అనువర్తనీయతను అందిస్తుంది. ఈ సాంకేతికత అన్ని EP పరిమాణాలు మరియు బ్యాచ్ పరిమాణాలలో షేర్డ్ ఎక్స్‌పర్ట్ కంప్యూటేషన్ సమయాన్ని దాచిపెడుతుంది.

కంప్యూటేషన్ మరియు కమ్యూనికేషన్ ఓవర్‌లాప్‌ను మరింత పెంచడానికి, డేటా డిపెండెన్సీని విచ్ఛిన్నం చేయడానికి DeepSeek టెక్నికల్ నివేదికలో పేర్కొన్న మైక్రో బ్యాచింగ్‌ను మేము ఉపయోగించాము. చిత్రంలో దిగువ భాగంలో చూపినట్లుగా, మేము ఒక ట్రాన్స్‌ఫార్మర్ లేయర్ యొక్క కంప్యూటేషన్‌ను 5 దశలుగా విభజించాము:

దశ 1: ఇన్‌పుట్‌నార్మ్, QKVProj, అపెండ్‌కేవి, BMM

దశ 2: BMM, అటెన్, OProj, పోస్ట్‌నార్మ్, గేట్

దశ 3: డిస్పాచ్ సెండ్, షేర్డ్ ఎక్స్‌పర్ట్

దశ 4: డిస్పాచ్ రెక్వ్, MoE, కంబైన్ సెండ్

దశ 5: కంబైన్ రెక్వ్

మొదటి 3 డెన్స్ ట్రాన్స్‌ఫార్మర్ లేయర్‌లలో, మేము మొత్తం బ్యాచ్‌ను ఉపయోగిస్తాము. కింది 58 MoE ట్రాన్స్‌ఫార్మర్ లేయర్‌లలో, మేము బ్యాచ్‌ను సమానంగా రెండు మైక్రో బ్యాచ్‌లుగా విభజిస్తాము. రెండు మైక్రో బ్యాచ్‌లు ప్రత్యామ్నాయంగా అమలు చేయబడతాయి, 3 దశల ద్వారా ఆఫ్‌సెట్ చేయబడతాయి. ఈ రెండు మైక్రో బ్యాచ్‌ల మధ్య డేటా డిపెండెన్సీ లేనందున, డిస్పాచ్ సెండ్ తర్వాత మరియు కంబైన్ సెండ్ తర్వాత మనం మరొక మైక్రో బ్యాచ్ కంప్యూటేషన్‌కు మారవచ్చు.

లేటెన్సీ బ్రేక్‌డౌన్

తదుపరి, మేము ఒక ప్రయోగం ద్వారా ఓవర్‌లాపింగ్ ప్రభావాలను పోల్చుతాము, అలాగే సింగిల్-నోడ్ డిప్లాయ్‌మెంట్ EP8 మరియు మల్టీ-నోడ్ డిప్లాయ్‌మెంట్ EP128 మధ్య పనితీరు వ్యత్యాసాలను పోల్చుతాము. పోలికను సులభతరం చేయడానికి, కింది ప్రయోగం కోసం మేము H100 GPUలను ఉపయోగించాము. మేము TP1, ప్రతి GPUకి 128 బ్యాచ్ పరిమాణం, ప్రతి అభ్యర్థనకు 2 క్వెరీ పొడవు మరియు 5000 KV కాష్ పొడవును ఉపయోగించాము.

విస్తరించు

పైన పేర్కొన్న చిత్రం ఒక MoE ట్రాన్స్‌ఫార్మర్ లేయర్‌పై ఖర్చు చేసిన మొత్తం సమయాన్ని మరియు విభిన్న రకాల కెర్నళ్ల లేటెన్సీ నిష్పత్తిని చూపుతుంది. డిస్పాచ్, కంబైన్ మరియు గ్రూప్‌జెమ్ మినహా, EP8, EP128 NoOverlap మరియు EP128 డిస్పాచ్‌ఓవర్‌లాప్ సిరీస్‌లలో ఇతర కెర్నళ్ల అమలు సమయం సమానంగా ఉండాలి ఎందుకంటే బ్యాచ్ పరిమాణం ఒకేలా ఉంటుంది.

ఓవర్‌లాపింగ్

ముందుగా మూడు ఓవర్‌లాపింగ్ పద్ధతుల ప్రభావాలను పోల్చి చూద్దాం. NoOverlap మొత్తంగా 2667µs తీసుకుంది, డిస్పాచ్‌ఓవర్‌లాప్ 2651µs తీసుకుంది, 16µs లేదా కేవలం 0.6% ఆదా చేసింది. మైక్రోబ్యాచ్ చాలా ముఖ్యమైన మెరుగుదలను చూపింది, 1896µs తీసుకుంది, 29% వేగవంతం అయింది. డిస్పాచ్ మరియు కంబైన్ సమయం రెండూ గణనీయంగా తగ్గాయి. డిస్పాచ్ 593µs నుండి 367µsకి తగ్గింది, మరియు కంబైన్ 1012µs నుండి 237µsకి తగ్గింది.

కంప్యూటేషన్ కెర్నళ్ల కోసం, 128 పరిమాణం గల బ్యాచ్‌ను 64 పరిమాణం గల రెండు బ్యాచ్‌లుగా విభజించడం మొత్తం అమలు సమయాన్ని పెంచుతుందని గమనించండి. అందువల్ల, కమ్యూనికేషన్‌పై ఖర్చు చేసిన సమయం 1001µs తగ్గినా, మొత్తం సమయం కేవలం 771µs మాత్రమే తగ్గింది. కింది విభాగంలో రూఫ్‌లైన్ మోడల్‌ను ఉపయోగించి మేము దీనికి కారణాన్ని వివరిస్తాము.

ఈ కారణంగా, మైక్రోబ్యాచింగ్ ఎప్పుడూ పనితీరును మెరుగుపరచదు.

విస్తరించు

పైన పేర్కొన్న చిత్రం 4-128 బ్యాచ్ పరిమాణాల కోసం డిస్పాచ్‌ఓవర్‌లాప్‌తో పోలిస్తే మైక్రోబ్యాచ్ యొక్క పనితీరు మెరుగుదలను చూపుతుంది. బ్యాచ్ పరిమాణం 32 కంటే తక్కువగా ఉన్నప్పుడు, మైక్రోబ్యాచ్ పనితీరును 5%-40% తగ్గిస్తుంది. బ్యాచ్ పరిమాణం 32 కంటే ఎక్కువగా లేదా సమానంగా ఉన్నప్పుడు, మైక్రోబ్యాచ్ పనితీరును 10%-35% మెరుగుపరుస్తుంది.

EP8 vs EP128

మునుపటి చిత్రానికి తిరిగి వెళ్దాం మరియు EP8 మరియు EP128 మైక్రోబ్యాచ్‌లను పోల్చి చూద్దాం. EP8 మొత్తంగా 1802µs తీసుకుంది, ఇది EP128 యొక్క 1896µs కంటే కొద్దిగా తక్కువ. పైన పేర్కొన్న మైక్రోబ్యాచ్ ద్వారా తీసుకువచ్చిన పెరిగిన కెర్నల్ అమలు సమయం కాకుండా, ప్రధాన వ్యత్యాసాలు MoE కంప్యూటేషన్ కోసం ఉపయోగించే గ్రూప్‌జెమ్ మరియు రెండు కమ్యూనికేషన్ కెర్నలు, డిస్పాచ్ మరియు కంబైన్.

EP8 యొక్క గ్రూప్‌జెమ్ 555µs తీసుకుంది, అయితే EP128 యొక్క గ్రూప్‌జెమ్ 270µs తీసుకుంది, సగానికి తగ్గింది. ఇది మల్టీ-నోడ్ డిప్లాయ్‌మెంట్ యొక్క ప్రధాన ప్రయోజనం.

దురదృష్టవశాత్తు, కమ్యూనికేషన్‌పై ఖర్చు చేసిన సమయం 213µs పెరిగింది, ఇది గ్రూప్‌జెమ్ యొక్క ప్రయోజనాన్ని చాలా వరకు భర్తీ చేసింది. మా కమ్యూనికేషన్ కెర్నళ్ల ప్రత్యేక పనితీరు పరీక్షలలో, అవి ఇన్‌ఫినిబాండ్ బ్యాండ్‌విడ్త్‌లో సగాన్ని మాత్రమే సాధించగలవని మేము కనుగొన్నాము. మా కమ్యూనికేషన్ కెర్నళ్లను మేము ఆప్టిమైజ్ చేస్తూనే ఉంటాము.

గణనీయంగా వెనుకబడి ఉన్న మరో కెర్నల్ GEMM. మైక్రోబ్యాచ్ GEMMను 95µs పెంచింది. దిగువన ఉన్న రూఫ్‌లైన్ విభాగంలో మేము GEMMను మరింత లోతుగా విశ్లేషిస్తాము. ప్రస్తుత GEMM అమలు ఇంకా సరైన పనితీరును సాధించలేదని మేము நம்புகிறோம்.

రూఫ్‌లైన్

కెర్నల్ పనితీరును విశ్లేషించడానికి రూఫ్‌లైన్ మోడల్ మంచి సాధనం. దీని సమాంతర అక్షం అరిథ్మెటిక్ ఇంటెన్సిటీ, FLOP మరియు మెమరీ I/O బైట్ల నిష్పత్తి. సమాంతర అక్షం విలువను కెర్నల్ యొక్క సెమాంటిక్స్ నుండి నేరుగా లెక్కించవచ్చు. నిలువు అక్షం సాధించిన పనితీరును సూచిస్తుంది, ఇది బెం marquées లేటెన్సీ ద్వారా FLOPని విభజించడం ద్వారా లెక్కించబడుతుంది.

kernel performance యొక్క theoretical upper bound నేరుగా GPU యొక్క specifications ద్వారా నిర్ణయించబడుతుంది. H100 యొక్క FP8 peak performance 1979 TFLOP/s, Roofline modelలో ఒక horizontal lineగా ప్రాతినిధ్యం చేయబడుతుంది. H100 యొక్క memory bandwidth 3.35 TB/s, మూలబిందువు గుండా వెళ్లే line యొక్క slope‌గా ప్రాతినిధ్యం చేయబడుతుంది. ఈ రెండు lines వరుసగా compute-bound మరియు memory-bound kernels‌కు performance limits‌ను ఇస్తాయి.

క్రింద, మేము గ్రూప్‌జెమ్ మరియు GEMM కెర్నళ్ల పనితీరు గురించి చర్చిస్తాము.

గ్రూప్‌జెమ్ (GroupGEMM)

MoEలోని గ్రూప్‌జెమ్ కెర్నల్ కింది కంప్యూటేషన్‌ను నిర్వహిస్తుంది: మొత్తంగా g గ్రూప్‌లు ఉన్నాయి, i-వ గ్రూప్ m_i టోకెన్‌లను కలిగి ఉంది, [m_i, k] x [k, n] -> [m_i, n] యొక్క మ్యాట్రిక్స్ గుణకారాన్ని నిర్వహిస్తుంది. పనితీరు పరీక్షలో, ప్రతి గ్రూప్‌లోని టోకెన్ల సంఖ్య ఒకేలా ఉంటుందని మేము అనుకుంటాము, దీనిని m_i = m అని సూచిస్తాము. అప్పుడు గ్రూప్‌జెమ్ కోసం FLOP గణన 2 * g * m * k * n, మరియు మెమరీ I/O బైట్లు g * (m * k + n * k + m * n).

DeepSeek-V3/R1 modelలో, 256 experts ఉన్నాయి, మరియు ప్రతి token computation కోసం 8 experts‌కు dispatch చేయబడుతుంది. batch size 128, query length 2, EP128 DP128 configuration అనుకుంటే, ప్రతి expert స్వీకరించే tokens యొక్క సగటు సంఖ్య (అంటే, m) 128 * 2 * 8 * 128 / 256 = 1024 అవుతుంది. అలాగే, ఇతర configurations మరియు batch sizes కోసం mను కూడా లెక్కించవచ్చు.

పనితీరు పరీక్ష కోసం మేము DeepGEMM యొక్క గ్రూప్‌జెమ్ అమలును ఉపయోగించాము. పరీక్ష పాయింట్లు TP1 మరియు బ్యాచ్ పరిమాణాలు 1-128తో EP8, EP16, EP32, EP64, EP128 కాన్ఫిగరేషన్‌ల కలయికలను కవర్ చేశాయి.

విస్తరించు

పైన పేర్కొన్న చిత్రం విభిన్న EP కాన్ఫిగరేషన్‌ల క్రింద గ్రూప్‌జెమ్ కోసం రూఫ్‌లైన్ మోడల్‌ను చూపుతుంది. వేర్వేరు EP వేర్వేరు గ్రూప్‌ల సంఖ్యకు అనుగుణంగా ఉంటుంది. ఈ చిత్రం దాదాపు అతివ్యాప్తి చెందుతున్న పనితీరు రేఖలను వివరిస్తుంది, గ్రూప్‌జెమ్ పనితీరు ప్రధానంగా మొత్తం టోకెన్ గణన ద్వారా నిర్ణయించబడుతుందని సూచిస్తుంది (ఇది g * mగా సూచించబడుతుంది).

ప్రతి EP కాన్ఫిగరేషన్ కోసం ప్రతి GPUకి 128 బ్యాచ్ పరిమాణానికి అనుగుణంగా ఉండే డేటా పాయింట్లను నక్షత్రాలు గుర్తు చేస్తాయి. ఈ నక్షత్రాలతో కూడిన డేటా పాయింట్లను పోల్చి చూస్తే, EP పెరిగేకొద్దీ (మరియు DP సమకాలీనంగా పెరిగేకొద్దీ), ప్రతి ఎక్స్‌పర్ట్‌కు టోకెన్ల సంఖ్య m కూడా పెరుగుతుందని మనం చూడవచ్చు. EP8 వద్ద, m=128, అయితే EP128 వద్ద, m=2048.

m పెరిగేకొద్దీ, అరిథ్మెటిక్ ఇంటెన్సిటీ కూడా పెరుగుతుంది. చాలా కాన్ఫిగరేషన్‌లలో, గ్రూప్‌జెమ్ మెమరీ బ్యాండ్‌విడ్త్ ద్వారా పరిమితం చేయబడింది, కాబట్టి mని పెంచడం పనితీరును మెరుగుపరుస్తుంది.

GEMM

GEMM కెర్నల్ మోడల్‌లోని Linear ప్రొజెక్షన్‌లకు అనుగుణంగా ఉంటుంది, ఉదాహరణకు Q/K/V/O ప్రొజెక్షన్. [m, k] x [k, n] -> [m, n] యొక్క మ్యాట్రిక్స్ గుణకారం కోసం, FLOP గణన 2 * m * k * n, మరియు మెమరీ I/O బైట్లు m * k + n * k + m * n. బ్యాచ్ పరిమాణాలు 1-128 కోసం మేము లేటెన్సీని కూడా పరీక్షించవచ్చు.

విస్తరించు

పైన పేర్కొన్న చిత్రం విభిన్న EP కాన్ఫిగరేషన్‌ల క్రింద GEMM కోసం రూఫ్‌లైన్ మోడల్‌ను చూపుతుంది. GEMM పనితీరు మెమరీ బ్యాండ్‌విడ్త్ ద్వారా పరిమితం చేయబడిందని మనం చూడవచ్చు. బ్యాచ్ పరిమాణం పెరిగేకొద్దీ, అరిథ్మెటిక్ ఇంటెన్సిటీ కూడా పెరుగుతుంది, తద్వారా పనితీరు మెరుగుపడుతుంది.

మైక్రోబ్యాచ్

మైక్రోబ్యాచింగ్‌ను ఉపయోగిస్తున్నప్పుడు, మేము బ్యాచ్‌ను సమానంగా రెండు భాగాలుగా విభజిస్తాము. పైన పేర్కొన్న రెండు చిత్రాల నుండి, m అనేది m/2 అయినప్పుడు, మ్యాట్రిక్స్ గుణకారపు సామర్థ్యం తగ్గుతుందని మనం చూడవచ్చు. అందువల్ల, m/2 పరిమాణం గల రెండు మ్యాట్రిక్స్ గుణకారాలను అమలు చేయడం కంటే m పరిమాణం గల ఒక మ్యాట్రిక్స్ గుణకారాన్ని అమలు చేయడానికి ఎక్కువ సమయం పడుతుంది.

మల్టీ-టోకెన్ ప్రిడిక్షన్

ఈ వ్యాప్తం అంతటా, స్పెక్యులేటివ్ డికోడింగ్ కోసం మల్టీ-టోకెన్ ప్రిడిక్షన్ (MTP) వినియోగాన్ని మేము అనుకున్నాము. MTP ప్రతి అభ్యర్థనకు క్వెరీ పొడవును 1 నుండి 2కి మారుస్తుంది. మ్యాట్రిక్స్ గుణకారం కోసం, ఇది mని m * 2కి మార్చడానికి సమానం, తద్వారా మ్యాట్రిక్స్ గుణకార సామర్థ్యాన్ని పెంచుతుంది. మరోవైపు, మేము MLA కోసం రూఫ్‌లైన్ మోడల్‌ను గీస్తే, క్వెరీ పొడవును పెంచడం MLA కెర్నల్ సామర్థ్యాన్ని గణనీయంగా పెంచుతుందని మేము కనుగొంటాము.

అందువల్ల, మోడల్ సామర్థ్యంలో MTP వినియోగం ముఖ్యమైన పాత్ర పోషిస్తుంది.

అమలు & ఆప్టిమైజేషన్‌లు

ఈ విభాగంలో, మేము మా DeepSeek-V3/R1 మోడల్ కోసం కొన్ని అమలు మరియు ఆప్టిమైజేషన్ వివరాలను పరిచయం చేస్తాము.

క్వాంటైజేషన్

DeepSeek-V3/R1 FP8పై nativeగా per-block quantization schemeను ఉపయోగించి trained చేయబడింది, ఇందులో weights statically quantize చేయబడతాయి మరియు activations on-the-flyగా quantize చేయబడతాయి. ప్రతి channel లేదా ప్రతి matrix కోసం scaling factor‌ను statically గణించడం బదులు, activations కోసం 128-element vectorsపై మరియు matrices కోసం 128x128 element tilesపై scaling factors గణించబడతాయి, దీని వల్ల quantization కారణమైన accuracy degradation పరిమితం అవుతుంది.

Perplexity వద్ద, ఇన్ఫరెన్స్‌కు మద్దతు ఇవ్వడానికి మేము CUDA మరియు Triton కెర్నళ్ల మిశ్రమంపై ఆధారపడతాము, అత్యంత పనితీరు-సెన్సిటివ్ మరియు అరుదుగా సవరించబడిన కెర్నళ్ల (అటెన్షన్ మరియు GEMM వంటివి) కోసం CUDA ఉపయోగించబడుతుంది, మరియు Triton విస్తృత శ్రేణి యాక్టివేషన్, సాధారణీకరణ (normalization) మరియు యుటిలిటీ కెర్నళ్లను అమలు చేస్తుంది. బ్లాక్ క్వాంటైజేషన్ పథకానికి కెర్నళ్లను త్వరగా అనుసరించడానికి Triton మాకు అనుమతించింది.

Linear మరియు MoE layers కోసం, మేము Deep GEMM kernels‌ను మా స్వంత Triton GEMM kernels‌తో mix చేస్తాము, ఎందుకంటే కొన్ని matrix dimensions మరియు తక్కువ batch sizes వద్ద Split-K తక్కువ latencyను అందిస్తుందని గమనించాము. unquantized layer ఒక (M, K) x (K, N) multiplication చేస్తే, block quantization కోసం దీనికి (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) scaling factor అవసరం. block quantization కోసం, activations‌కు సంబంధించిన scaling factors ముందుగా calibrate చేయకుండా, on-the-flyగా గణించబడతాయి. activation scaling factors కేవలం K לאורך మాత్రమే సమీకరించబడతాయి, M dimension לאורך కాదు కాబట్టి, ఈ scheme‌ను support చేయడానికి kernels‌కు కేవలం స్వల్ప మార్పులు మాత్రమే అవసరం.

విస్తరించు

DeepSeek-V3/R1 ఉపయోగించే SiLU యాక్టివేషన్ ఫంక్షన్‌కు CUDA గ్రాఫ్‌లు, బ్లాక్ క్వాంటైజేషన్ మరియు డైనమిక్‌గా రూట్ చేయబడిన టోకెన్ గణనలకు మద్దతు ఇవ్వడానికి గణనీయమైన మార్పులు అవసరమయ్యాయి. బ్లాక్ క్వాంటైజేషన్ సమస్యాత్మకంగా ఉండవచ్చు ఎందుకంటే ఇది క్షితిజ సమాంతర తగ్గింపులను పరిచయం చేస్తుంది, అయితే కెర్నల్ ఇప్పటికే యాక్టివేషన్‌లను వాటి హిడెన్ డైమెన్షన్ వెంట 1024 మూలకాల బ్లాకులుగా విభజించింది. ఒక బ్లాక్ లోపల, అతిపెద్ద సంపూర్ణ విలువను లెక్కించడానికి క్వాంటైజ్ చేయవలసిన టెన్సర్ 128 బ్లాకులలో మరింత విభజించబడింది, Triton సమర్థవంతమైన క్రాస్-వార్ప్ గరిష్ట తగ్గింపులను ఉత్పత్తి చేస్తుంది, తక్కువ ఓవర్‌హెడ్‌ను జోడిస్తుంది.

CUDA గ్రాఫ్‌ల క్రింద MoE రూటింగ్‌కు మద్దతు ఇవ్వడానికి, టోకెన్ గణనల యొక్క ఎప్పర్ బౌండ్‌ను ఉంచడానికి కేటాయించబడిన బఫర్‌ల పరిమాణం ఆధారంగా పనిని షెడ్యూల్ చేయడానికి బదులుగా, ప్రతి ఎక్స్‌పర్ట్‌కు టోకెన్ల సంఖ్యను సూచించే రూటింగ్ సమాచారం గురించి కెర్నలు తెలుసుకోవాలి. ఇన్‌పుట్ టెన్సర్ డైమెన్షన్‌ల ఆధారంగా మేము సమస్యను విభజించలేము, కాబట్టి ఎంత మంది టోకెన్లు నిండి ఉన్నారో నిర్ణయించడానికి రూటింగ్ సమాచారాన్ని చదివే స్థిర సంఖ్యలో పర్సిస్టెంట్ కెర్నళ్లను మేము ప్రారంభిస్తాము మరియు వాటి మధ్య యాక్టివేషన్‌లను ప్రాసెస్ చేసే పనిని డైనమిక్‌గా విభజిస్తాము.

మేము మా కొన్ని కెర్నళ్లను ఇప్పటికే FlashInfer ప్రాజెక్ట్‌కి అప్‌స్ట్రీమ్ చేసాము మరియు భవిష్యత్తులో మా కోడ్‌ను మరింత ఓపెన్-సోర్స్ చేస్తాము.

MLA లేయర్

MLA కంప్యూటేషన్ కోసం మేము FlashInferని ఉపయోగిస్తాము. FlashInfer సౌకర్యవంతమైన పేజ్ టేబుల్ సెట్టింగ్‌లను మరియు అత్యంత అధిక పనితీరును మద్దతు ఇస్తుంది.

మేము 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 గ్రాఫ్ కెర్నల్ లాంచింగ్ ఓవర్‌హెడ్‌ను గణనీయంగా తగ్గిస్తుంది, ఇది పనితీరుకు చాలా కీలకం. మేము ప్రతి బ్యాచ్ పరిమాణం కోసం ఒక CUDA గ్రాఫ్‌ను సృష్టిస్తాము.

మా AllToAll కెర్నల్‌ను అభివృద్ధి చేయడానికి ముందు, AllToAll కమ్యూనికేషన్ కోసం మేము torch.all_to_all_single()ని ఉపయోగించాము. ఈ ఆపరేషన్‌కు అన్ని GPUలు ఒకే బ్యాచ్ పరిమాణాన్ని ఉపయోగించడం అవసరం. అయితే, వేర్వేరు DP గ్రూప్‌లు వేర్వేరు బ్యాచ్ పరిమాణాలను అమలు చేయవచ్చు.

వేర్వేరు బ్యాచ్ పరిమాణాలను ఉపయోగించే వేర్వేరు DP గ్రూప్‌లతో all_to_all_single() అనుకూలంగా ఉండేలా చూసుకోవడానికి, అన్ని DP గ్రూప్‌లలో గరిష్ట బ్యాచ్ పరిమాణాన్ని పొందడానికి ప్రతి మోడల్ రన్కు ముందు మేము మొదట allreduce() ఆపరేషన్‌ను ఉపయోగించాము. ఆపై అన్ని DP గ్రూప్‌లు అమలు చేయడానికి ఈ బ్యాచ్ పరిమాణాన్ని ఉపయోగించేలా చేసాము.

ఈ విధానం మేము CUDA గ్రాఫ్‌ను ఉపయోగించగలమని నిర్ధారించినప్పటికీ, దీనికి మూడు ప్రతికూలతలు ఉన్నాయి. మొదటిది, దీనికి అదనపు allreduce() ఆపరేషన్ అవసరం. రెండవది, చిన్న బ్యాచ్ పరిమాణాలు గల DP గ్రూప్‌లు పాడ్ చేయడానికి బలవంతం చేయబడతాయి. మూడవది, ఇది మా అమలు కోడ్‌ను సంక్లిష్టంగా చేస్తుంది.

మా సొంత AllToAll కెర్నల్‌ను అమలు చేసిన తర్వాత, అన్ని GPUలు ఒకే బ్యాచ్ పరిమాణాన్ని ఉపయోగించడం మాకు ఇకపై అవసరం లేదు. అందువల్ల, అదనపు allreduce() ఆపరేషన్‌లను నిర్వహించడం లేదా బ్యాచ్ పరిమాణాలను పాడ్ చేయడం మాకు ఇకపై అవసరం లేదు.

MoE రూటర్

MoE రూటర్ ట్రిటన్‌లో అమలు చేయబడింది, ఇది స్టాండర్డ్ లైబ్రరీ నుండి తీసుకోబడిన సవరించిన క్రమబద్ధీకరణపై ఆధారపడి ఉంటుంది, ఇది క్రమబద్ధీకరించబడిన మూలకాల సూచికలను కూడా ట్రాక్ చేస్తుంది. మిక్స్‌ట్రల్ రూటింగ్ అనేది డీప్‌సీక్ రూట్‌ల యొక్క ప్రత్యేక కేస్ అయినందున, టాప్-K గ్రూప్ అనేది అన్ని ఎక్స్‌పర్ట్‌ల గ్రూప్‌తో సమానంగా ఉంటుంది, కాబట్టి ఈ అమలు అన్ని MoE మోడల్స్‌లో పంచుకోబడుతుంది. స్పేస్ కెర్నలు టాప్-K సూచికలు మరియు స్కోర్‌లను నేరుగా వినియోగిస్తాయి, అయితే ఆల్-టు-ఆల్ పై ఆధారపడిన డెన్స్ డిస్పాచ్/కంబైన్ పథకాలకు టోకెన్ ప్రాతిపదికన కాకుండా ప్రతి-ఎక్స్‌పర్ట్‌కు రూటింగ్ సమాచారం సమీకరించబడాలి.

భవిష్యత్తు పని

భవిష్యత్ పనిలో, DeepSeek మోడల్ యొక్క పనితీరును మరింత ఆప్టిమైజ్ చేయాలని మేము ప్లాన్ చేస్తున్నాము.

అత్యంత ముఖ్యమైన తదుపరి ఆప్టిమైజేషన్ ప్రిఫిల్ డిస్గ్రిగేషన్. DeepSeek-V3/R1 మోడల్ యొక్క ప్రిఫిల్ దశ మరియు డికోడ్ దశ చాలా భిన్నమైన గణన లక్షణాలను కలిగి ఉన్నాయి. రెండూ వేర్వేరు ఆప్టిమైజేషన్ వ్యూహాలు మరియు డిప్లాయ్‌మెంట్ పథకాలను ఉపయోగించవచ్చు.

MLA Layer కోసం, Decode phaseలో, MLA computation యొక్క FLOP count‌ను తగ్గించడానికి మేము Matrix Absorption‌ను ఉపయోగిస్తాము. Prefill phaseలో, ముందుగా latent vector‌ను K/V spaceలోకి project చేసి, ఆపై Multi-Head Attention (MHA) రూపంలో compute చేయడం మెరుగ్గా పనిచేస్తుంది.

ప్రిఫిల్ మరియు డికోడ్ ఒకే GPUలో నడిస్తే, డికోడ్ అవుట్‌పుట్ వేలపై ప్రిఫిల్ ప్రభావాన్ని తగ్గించడానికి, ప్రిఫిల్ కోసం క్వెరీని బహుళ డీప్‌లుగా విభజించడానికి మేము సాధారణంగా చంక్డ్ ప్రిఫిల్‌ను ఉపయోగిస్తాము. KV కాష్ లేటెంట్ వెెక్టర్‌ను నిల్వ చేస్తుంది కాబట్టి, MLAని MHA రూపంలోకి మార్చడం కష్టం అవుతుంది.

MoE లేయర్ కోసం, డికోడ్ దశలో, ప్రతి ఎక్స్‌పర్ట్‌కు ఇన్‌పుట్ టోకెన్ల సంఖ్యను పెంచడానికి మేము వీలైనంత పెద్ద EP మరియు DPని ఉపయోగిస్తాము, తద్వారా గ్రూప్‌జెమ్ పనితీరును మెరుగుపరుస్తాము. ప్రిఫిల్ దశలో, టోకెన్ల సంఖ్య ఇప్పటికే తగినంత పెద్దదిగా ఉన్నందున, గ్రూప్‌జెమ్ ఇప్పటికే కంప్యూట్-బౌండ్‌గా ఉంటుంది. అందువల్ల, ప్రిఫిల్ కోసం, మనం చిన్న EP మరియు DPని ఉపయోగించవచ్చు.

ప్రిఫిల్ మరియు డికోడ్ ఒకే GPUలో నడిస్తే, ఏదైనా DP గ్రూప్ ప్రిఫిల్‌ను నిర్వహిస్తున్నంత కాలం, అన్ని GPUలపై MoE లేయర్‌ల లేటెన్సీ పెరుగుతుంది, ఇది డికోడ్ అవుట్‌పుట్ వేగాన్ని గణనీయంగా ప్రభావితం చేస్తుంది.

ప్రిఫిల్ డిస్గ్రిగేషన్ కాకుండా, కింది అంశాలను ఆప్టిమైజ్ చేయాలని కూడా మేము ప్లాన్ చేస్తున్నాము:

AllToAll పనితీరు: మా AllToAll కెర్నల్ ప్రస్తుతం ఇన్‌ఫినిబాండ్ బ్యాండ్‌విడ్త్‌లో 1/3 మాత్రమే సాధించగలదు. మేము ఈ కెర్నల్‌ను ఆప్టిమైజ్ చేస్తూనే ఉంటాము.

ఈగల్-శైలి స్పెక్యులేటివ్ డికోడింగ్: పై డేటాలో, 1 టోకెన్‌ను అంచనా వేయడానికి స్పెక్యులేటివ్ డికోడింగ్‌ను ఉపయోగిస్తున్నట్లు మేము అనుకున్నాము. ఈగల్ బహుళ టోకెన్లను అంచనా వేయడానికి ట్రీ నిర్మాణాన్ని ఉపయోగించగలదు, అంగీకార పొడవును మెరుగుపరుస్తుంది, ఇది అవుట్‌పుట్ వేగాన్ని గణనీయంగా పెంచుతుంది.

GEMM కెర్నల్: ఇంతకు ముందు చూపిన రూఫ్‌లైన్ మోడల్‌లో, GEMM కెర్నల్ యొక్క సామర్థ్యం సిద్ధాంతపరమైన పరిమితికి ఇంకా చాలా దూరంలో ఉందని మనం కనుగొనవచ్చు. మేము ఈ కెర్నల్‌ను ఆప్టిమైజ్ చేస్తూనే ఉంటాము.

GB200 NVL72: NVIDIA యొక్క తాజా GB200 NVL72 పరిష్కారంలో, 72 బ్లాక్‌వెల్ GPUలు హై-స్పీడ్ NVLink ద్వారా పరస్పరం కనెక్ట్ చేయబడ్డాయి. MoE ఆర్కిటెక్చర్ మోడల్స్ కోసం, ఇది చాలా పెద్ద అవకాశం మరియు సవాలు.

ముగింపు

DeepSeek MoE మోడల్స్ యొక్క మల్టీ-నోడ్ డిప్లాయ్‌మెంట్ డెన్స్ LLMలతో సాధారణంగా అసాధ్యమైనదాన్ని సాధిస్తుంది: త్రూపుట్ మరియు లేటెన్సీ రెండింటినీ ఏకకాలంలో మెరుగుపరచడం. ఎక్కువ GPUలలో ఎక్స్‌పర్ట్‌లను పంపిణీ చేయడం ద్వారా, మేము ప్రతి పరికరానికి మెమరీ బ్యాండ్‌విడ్త్ ఒత్తిడిని తగ్గిస్తాము, వేగవంతమైన ప్రాసెసింగ్ మరియు అధిక సిస్టమ్ త్రూపుట్‌ను ప్రారంభిస్తాము. సింగిల్-నోడ్ డిప్లాయ్‌మెంట్‌లతో పోలిస్తే సమానమైన అవుట్‌పుట్ వేగాల వద్ద EP128 కాన్ఫిగరేషన్‌లు గరిష్టంగా 5 రెట్లు ఎక్కువ త్రూపుట్‌ను సాధిస్తున్నట్లు మా ప్రయోగాలు చూపుతున్నాయి.

మైక్రో-బ్యాచింగ్ వంటి కంప్యూటేషన్-కమ్యూనికేషన్ ఓవర్‌లాపింగ్ సాంకేతికతలు మల్టీ-నోడ్ కమ్యూనికేషన్ ఓవర్‌హెడ్‌ను గణనీయంగా తగ్గిస్తాయి, మా అమలు గరిష్టంగా 40% వేగవంతం అవ్వడాన్ని చూపుతుంది. మా కస్టమ్ AllToAll కమ్యూనికేషన్ కెర్నలు మరియు ఆప్టిమైజ్ చేసిన కెర్నల్ అమలులు 671B పారామీటర్ మోడల్ యొక్క సమర్థవంతమైన డిప్లాయ్‌మెంట్‌ను ప్రారంభించాయి.

MoE architectures తమ capability కోసం మరింత ప్రజాదరణ పొందుతున్న కొద్దీ, ఈ deployment strategies ఇటువంటి models‌ను సమర్థవంతంగా scale చేయడానికి విలువైన insights‌ను అందిస్తాయి.

ప్రస్తావనలు

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