Inferensklynger: vLLM Tensor Parallel, Pipeline Parallel, og hvad hver enkelt rent faktisk koster dig

En 70B-klasse model passer ikke på én GPU ved nogen kvantisering, der efterlader brugbar KV-cache. En 405B-model passer ikke på én node. Når det er sandt, er spørgsmålet ikke længere "hvilken GPU", men "hvordan skærer jeg modellen på tværs af de GPU'er, jeg har, og hvad koster hvert snit mig?"

Denne artikel dækker de fire måder, hvorpå vLLM lader dig opdele en model — tensor parallel, pipeline parallel, expert parallel, data parallel — hvad hver enkelt gør ved din båndbredderegning, og hvordan du vælger mellem dem på Kentino-serien (PCIe-attached 5090, RTX Pro 6000 Blackwell, L40, L4 — ingen NVLink-fabric SXM-dele). Publikum har læst. I01, ved hvad vLLM er, og skal nu træffe konfigurationsbeslutninger.

De fire dimensioner ved at skære en model

Ethvert distribueret inferensframework — vLLM, SGLang, TensorRT-LLM, Triton — eksponerer en kombination af de samme fire akser. De er ikke alternativer; de komponerer.

Kolonne tre er hele spillet. TP råber hen over bussen på hvert lag. PP hvisker mellem to faser. Den ene kendsgerning afgør, om du holder TP inden for én boks, skubber PP på tværs af noder, og hvor grænsen går.

Tensorparallel — hvordan det rent faktisk fungerer

I TP er hver vægtmatrix i transformeren (opmærksomhed QKV, opmærksomhedsudgang, FFN op, FFN ned) skåret på tværs tensor_parallel_size GPU'er. Hver GPU gemmer én shard af hvert lag og beregner én shard af hver aktivering. Fordi attention og FFN indeholder matmuls, der har brug for fuld aktiveringen samles igen før næste operation (softmax, SwiGLU), skal delvise resultater kombineres. vLLM gør dette med en alt-reducere i slutningen af ​​opmærksomheden og en anden i slutningen af ​​FFN'en — to pr. transformerblok.

Llama 3.3 70B har 80 lag, skjult 8192. Ved batch 32 afkodning er hver all-reduce-bevægelse ~512 KB, ×160 pr. genereret token → ~80 MB pr. token på tværs af bussenForudfyldning er dramatisk værre: en 4K forudfyldning ved batch 32 skubber i størrelsesordenen 300 DK gennem reduktionsringen i én fremadgående passage.

Det tal er derfor TP elsker NVLinkSXM H100/B200 NVLink er 900 GB/s. PCIe Gen 5 x16 er 64 GB/s unidirektionel, 128 GB/s tovejs i bedste fald — sjældent tilfældet på et 4-GPU-kort (baner deles normalt, se W02). Forskellen på 14×–28× viser sig i benchmarks: NVLink-skaleringseffektivitet lander ~0.92×/kort, PCIe ~0.70–0.78×/kort på modeller i 70B-klassen.

Praktisk konsekvens: TP skalerer godt til 4 GPU'er i én PCIe Gen 5-node. Derudover reducerer du omkostningerne mere, end parallelismen sparer, og du bør i stedet bruge en parallel pipeline.

vLLM-konfiguration: tensor_parallel_size

--tensor-parallel-size N fortæller motoren at shardere alle vægttensorer på tværs af N GPU'er i den lokale node. Begrænsninger:

• N skal dividere modellens opmærksomhedshovedtælling (Llama 70B har 64 hoveder → N ∈ {1, 2, 4, 8, 16, 32, 64}).
• vLLM placerer TP-ranger på den samme node og antager en hurtig intra-node-bus.
• KV-cache er shardet langs hoveddimensionen — hver GPU gemmer total_heads / N hovedernes værdi. Højere TP giver mere KV-headroom pr. anmodning.

På Kentino-hardware: TP=4 på en 4× RTX 5090 eller 4× RTX Pro 6000 Blackwell-boks er det optimale. TP=8 virker, men PCIe-bussen halter; du er normalt bedre stillet med TP=4 × PP=2 i en 8-GPU-boks.

Parallel rørledning — muligheden på tværs af rummet

PP opdeler modellen efter dybde. Med pipeline_parallel_size=2, GPU 0 indeholder lag 0-39 af en 70B Llama, GPU 1 indeholder 40-79. En anmodning flyder gennem GPU 0, aktiveringstensor sender til GPU 1, GPU 1 afslutter den fremadrettede gennemgang.

Kommunikation er én tensor af form (batch, seq_len, hidden_size) pr. fasegrænse. For batch 32, seq 4096, skjult 8192, FP16, dvs. ~1 GB pr. forudfyldning og ~0.5 MB pr. dekodertoken ved batch 32 — to størrelsesordener mindre end TP all-reduce. PP løber komfortabelt på tværs almindelig 25 GbE eller endda 10 GbE.

Afvejningen er latensMed PP=2 hopper hvert token mellem stadier — naivt 2× vægtid pr. token. vLLM afhjælper dette med mikrobatching: stadie 0 starter den næste mikrobatch, mens stadie 1 afslutter den nuværende. Med tilstrækkelig samtidighed lukker boblen; med én anmodning og ingen batching er PP en latenstidsskat uden gevinst.

vLLM-konfiguration: pipeline_parallel_size

--pipeline-parallel-size M opdeler modellen i lag på tværs af M grupper. Samlede GPU'er = tensor_parallel_size × pipeline_parallel_sizeVejledning til dokumentation:

• Enkelt node, ≤ 8 GPU'er, modellen passer til: ren TP, pipeline_parallel_size=1.
• Multinode: TP inden for noden, PP på tværs af noderEn klynge med to noder og 8 GPU'er kører TP=4, PP=2.
• GPU-antallet dividerer ikke hovedantallet rent: sæt TP=1, PP=GPU'er. PP er ligeglad med hovedantallet. (En boks med 5 GPU'er — én plads mistet til et netværkskort — kan kun køre Llama via PP=5.)

Ekspertparallel — kun for MoE

MoE-modeller (DeepSeek-V3, Mixtral, Qwen-MoE-varianter) aktiverer ikke alle parametre på alle tokens. De har routede FFN-lag, hvor kun en lille delmængde af "eksperter" aktiverer per token; tætte opmærksomhedslag forbliver tætte.

Ekspertparallel (EP) shards-eksperter på tværs af GPU'er samtidig med at tætte lag holdes under TP eller DP. Med --enable-expert-parallel, ekspertlag skifter fra replikerede til partitionerede, en eller få eksperter pr. GPU. Kommunikationsmønsteret er alt-til-alt pr. MoE-lag: tokens ruter til den GPU, der ejer måleksperten, beregningen, returneringen.

EP er båndbredde-bursting. Det gør store MoE-modeller overhovedet håndterbare på PCIe-klynger - fuld TP på en 671B-aktiv model er håbløs. For Kentino-implementeringer er EP kun relevant for DeepSeek-V3-klasse modeller; kompakt Llama 70B drager ikke fordel. vLLM's indbyggede EP plus en nyere build er standardindgangspunktet.

Dataparallel — den kedelige, strålende akse

DP er den nemmeste skaleringsakse og den, der udnyttes for lidt af de fleste installationer. Du spinner op N identiske kopier af modellen, hver på sit eget sæt af GPU'er (hvert sæt kan selv bruge TP og/eller PP). En load balancer sender anmodninger til den replika, der har kapacitet.

Hvad DP giver:

• Lineær gennemløbsskalering (N× anmodninger/sek.).
• Nul kommunikation mellem replikaer under inferens.
• Uafhængige KV-caches pr. replika (præfikscache er pr. replika).
• Trivial fejlisolering.

Hvad DP koster:

• N× GPU-hukommelsen — hver replika indeholder den fulde model.
• Ingen reduktion af latenstid. En enkelt anmodning kræver, hvad som helst, på én replika.

Hvis du har en 4× RTX Pro 6000-boks, og Llama 70B passer i TP=4, giver en anden 4×-boks DP=2 × TP=4 — fordoblet gennemløb, samme latenstid pr. anmodning. For chat-, agent- og RAG-arbejdsbelastninger er det den rigtige handel. vLLM's --data-parallel-size flag (og det nyere data_parallel_deployment mode) starter og administrerer replikaer. DP er den reneste måde at skalere ud over én boks.

Kombination af akserne – tommelfingerreglen

Aksevalg: start med den mindste parallelisme, der passer, og tilføj derefter DP før PP.

Eksempel på udførelse. Servering af Llama 3.3 70B (FP8 ≈ 75 GB vægte, plus KV) ved høj samtidighed:

• En 4× RTX Pro 6000 Blackwell-boks (4 × 96 GB = 384 GB) kører det komfortabelt under TP=4, med ~250 GB tilbage til KV, præfiks-cache og CUDA-grafer.
• Tilføj en anden 4× Pro 6000-boks. DP=2 × TP=4. To replikaer bag en router. Dobbelt gennemløb, samme latenstid.
• Llama 3.1 405B ved FP8 (~400 GB vægt)? Én 4× Pro 6000-boks passer ikke. To bokse via PP=2 × TP=4 gør det — og linket på tværs af noder er bevægelige aktiveringer, ikke all-reduce. 25 GbE er nok; 100 GbE er komfortabelt.

KV-cache: den del, som alle undervurderer

KV-cachen er de kumulative opmærksomhedsnøgle-/værditensorer for hvert prompttoken, hvert genereret token, hver samtidig anmodning, hvert lag. Den vokser lineært med kontekstlængde og samtidighed. Llama 70B ved 8 K kontekst kræver omtrent 2.5 GB KV-cache pr. anmodning i FP16. Ved 32 samtidige anmodninger er det 80 GB - mere end en 5090'ers samlede VRAM.

Hvordan parallelisme interagerer med KV:

• Under TP, KV bliver shardet af Attention Head på tværs af TP-gruppen. KV pr. GPU = total / tensor_parallel_sizeHøjere TP → mere headroom for samtidige anmodninger.
• Under PP, KV forbliver på GPU'en, der indeholder det lag, der producerede den. Hvert trin ejer sin egen KV.
• Under DP, KV er fuldt uafhængig pr. replika.
• Under parallel kontekst (en nyere vLLM-tilstand), KV er sharderet langs sekvens dimension — nyttig til meget lange kontekster med én anmodning.

Når du skal dimensionere en kasse, skal du ikke kun kontrollere, om vægte fit. Kør KV-matematikken ved dit mål for samtidighed og kontekstvindue. Den mest almindelige stille fejl i produktions-vLLM er, at motoren forudser anmodninger under KV-tryk.

Anmodningsrouting — hvad der ligger foran klyngen

En enkelt vLLM-instans håndterer sin egen interne batching (kontinuerlig batching, præfiks-caching, planlægning). Den routerer ikke på tværs af replikaer. Det er routerens opgave.

NGINX er den rigtige standard for en installation med 2 replikaer — round-robin, sundhedstjek aktiveret /health, færdig. vLLM Routeren (Rust, udgivet sidst i 2025) er det rigtige valg, når præfiks-cache-hitrate dominerer din hale-latens: den routerer på ensartet hashing af promptpræfikset, så cache-varme replikaer bliver ved med at modtage de samme samtaler. For en agentarbejdsbyrde med lange delte systemprompter kan dette fordoble den effektive gennemløbshastighed vs. round-robin.

Båndbreddematematikken

Krydsreferencer: N02, N06.

Den ærlige læsning: TP og EP vil gerne blive i en boksPP og DP er ligeglade. Med et 10-25 GbE cross-node link er PP og DP fine. I det øjeblik du vil have TP på tværs af noder, betaler du for InfiniBand HDR eller 200 GbE RoCE - og du bør først spørge, om DP på ​​tværs af TP-grupper med én node giver dig det samme resultat for en tiendedel af budgettet. For de fleste implementeringer i Kentino-størrelse gør det.

To konkrete konfigurationsopskrifter

Opskrift A — Én node, 4× RTX 5090, Llama 70B Q4 / FP8

Hardware: K-AI 256 Turin Dual eller en hvilken som helst 4-GPU 5090-boks. PCIe Gen 5, ingen NVLink, AMD EPYC-vært.

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --dtype auto \
  --port 8000

Forventet: cirka 30-40 tok/s pr. anmodning ved lav samtidighed, samlet ~400-600 tok/s ved 32 samtidige (varierer med prompt mix, præfiks-cache hitrate, præcis kvantitet — behandl som en startkonvolut). PCIe Gen 5 all-reduce er flaskehalsen ved afkodning; præfill skalerer næsten lineært.

Opskrift B — To noder, 8× RTX Pro 6000 Blackwell i alt, Llama 405B FP8

To K-AI-bokse, hver 4× Pro 6000 (96 GB). 100 GbE RoCE-link mellem dem, eller 25 GbE hvis budgettet er stramt (fungerer, lidt langsommere præfyldning).

# Node 0 (head):
vllm serve meta-llama/Llama-3.1-405B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 32

# Node 1 (worker, joined via Ray):
ray start --address=<head-ip>:6379

TP=4 inden for hver node bruger PCIe Gen 5 til alle reduktioner. PP=2 på tværs af noder sender aktiveringer over 25/100 GbE. Med Ray som den distribuerede backend (vLLM's standard for multinode) koordinerer head'en planlægning og KV-tilstand.

Ærlig præstationsvurdering: 405B ved FP8 på tværs af 8× Pro 6000 over PCIe + Ethernet lander omkring 6-12 tok/s pr. anmodning - et godt stykke under et 8× SXM B200-chassis, til en brøkdel af capex og uden SXM-forsyningsproblemet. Hvis din SLA er "svar på 30 sekunder for en færdiggørelse af 500 tokens", fungerer det. Hvis den er "svar på 2 sekunder", skal du ikke bruge en 405B - ​​brug en 70B.

Hvad vi ikke kører

NVLink, NVSwitch, SXM B200, komplette HGX-kort: ikke i Kentinos sortiment. De er det rigtige svar, hvis du har budgettet og arbejdsbyrden. De er ikke det rigtige svar for de fleste af vores kunder, der dimensionerer til 1-4 samtidige agent-workflows eller en enkelt robotplatform, ikke SaaS-inferens med 1000 brugere. PCIe-stien er ærlig omkring, hvad den kan og ikke kan. TP på under 10 ms pr. token på tværs af 16 GPU'er er en anden samtale - ikke den klynge, denne artikel handler om.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.