Inferenčné klastre: vLLM tensor parallel, pipeline parallel a čo Vás každý z nich naozaj stojí

Model triedy 70B sa nezmestí na jedno GPU pri žiadnej kvantizácii, ktorá by ponechala použiteľnú KV cache. Model s 405B parametrami sa nezmestí na jeden uzol. Keď to raz platí, otázka už neznie „ktoré GPU“, ale „ako model rozrežem medzi GPU, ktoré mám, a čo ma každý rez stojí?“

Tento článok pokrýva štyri spôsoby, ako vám vLLM umožní model rozkrojiť — tensor parallel, pipeline parallel, expert parallel, data parallel — čo každý z nich urobí s vaším účtom za šírku pásma a ako medzi nimi vyberať na portfóliu Kentino (5090, RTX Pro 6000 Blackwell, L40 a L4 pripojené cez PCIe — žiadne SXM diely s NVLink fabric). Predpokladáme, že čitateľ už prečítal I01, vie, čo je vLLM, a teraz potrebuje rozhodnúť o konfigurácii.

Štyri rozmery krájania modelu

Každý framework pre distribuovanú inferenciu — vLLM, SGLang, TensorRT-LLM, Triton — ponúka nejakú kombináciu tých istých štyroch osí. Nie sú to alternatívy; dajú sa kombinovať.

Tretí stĺpec je celá hra. TP kričí cez zbernicu pri každej vrstve. PP si pošepká medzi dvoma stupňami. Práve tento fakt rozhoduje, či TP udržíte v jednom stroji, PP natiahnete medzi uzly a kade vedie hranica.

Tensor parallel — ako to naozaj funguje

Pri TP je každá matica váh v transformeri (attention QKV, výstup attention, FFN up, FFN down) rozrezaná medzi tensor_parallel_size GPU. Každé GPU drží jeden shard každej vrstvy a počíta jeden shard každej aktivácie. Keďže attention aj FFN obsahujú matmuly, ktoré pred ďalšou operáciou (softmax, SwiGLU) potrebujú poskladať celú aktiváciu, čiastkové výsledky sa musia zlúčiť. vLLM to rieši operáciou all-reduce na konci attention a ďalšou na konci FFN — dve na každý blok transformera.

Llama 3.3 70B má 80 vrstiev a hidden 8192. Pri dekódovaní s batchom 32 presunie každý all-reduce ~512 KB, ×160 na vygenerovaný token → ~80 MB na token cez zbernicu. Prefill je dramaticky horší: 4 K prefill pri batchi 32 prežene v jednej doprednej passe cez all-reduce kruh rádovo 300 GB.

To číslo je dôvod, prečo TP miluje NVLink. NVLink na SXM H100/B200 má 900 GB/s. PCIe Gen 5 x16 má 64 GB/s jednosmerne a v najlepšom prípade 128 GB/s obojsmerne — čo na štvor-GPU doske platí len zriedka (linky bývajú zdieľané, pozri W02). Rozdiel 14×–28× sa prejaví v benchmarkoch: efektivita škálovania NVLinku sa pohybuje okolo 0.92×/kartu, pri PCIe okolo 0.70–0.78×/kartu na modeloch triedy 70B.

Praktický dôsledok: TP škáluje dobre do 4 GPU v jednom uzle s PCIe Gen 5. Nad tým stojí all-reduce viac, než paralelizmus ušetrí, a mali by ste siahnuť po pipeline parallel.

Konfigurácia vLLM: tensor_parallel_size

--tensor-parallel-size N hovorí enginu, aby každý tenzor váh rozdelil medzi N GPU v lokálnom uzle. Obmedzenia:

• N musí deliť počet attention hláv modelu (Llama 70B má 64 hláv → N ∈ {1, 2, 4, 8, 16, 32, 64}).
• vLLM umiestňuje TP ranky na ten istý uzol a predpokladá rýchlu vnútrouzlovú zbernicu.
• KV cache je shardovaná pozdĺž dimenzie hláv — každé GPU drží total_heads / N hláv. Vyššie TP dáva väčšiu rezervu KV na požiadavku.

Na hardvéri Kentino: TP=4 na stroji so 4× RTX 5090 alebo 4× RTX Pro 6000 Blackwell je sladký bod. TP=8 funguje, ale zbernica PCIe stoná; v osem-GPU stroji ste zvyčajne lepšie na TP=4 × PP=2.

Pipeline parallel — možnosť „cez miestnosť“

PP delí model podľa hĺbky. Pri pipeline_parallel_size=2 drží GPU 0 vrstvy 0–39 modelu Llama 70B a GPU 1 vrstvy 40–79. Požiadavka prejde cez GPU 0, tenzor aktivácií sa pošle na GPU 1 a GPU 1 dokončí doprednú passu.

Komunikácia je jeden tenzor tvaru (batch, seq_len, hidden_size) na hranicu stupňa. Pri batchi 32, seq 4096, hidden 8192 a FP16 je to ~1 GB na prefill a ~0.5 MB na dekódovaný token pri batchi 32 — o dva rády menej než all-reduce pri TP. PP pohodlne beží aj cez obyčajných 25 GbE alebo dokonca 10 GbE.

Kompromisom je latencia. Pri PP=2 každý token preskakuje medzi stupňami — naivne 2× dlhší čas na token. vLLM to zmierňuje mikrobatchovaním: stupeň 0 začne ďalší mikrobatch, kým stupeň 1 dokončuje aktuálny. Pri dostatočnej konkurencii sa bublina zatvorí; pri jedinej požiadavke bez batchovania je PP len daň na latencii bez akéhokoľvek prínosu.

Konfigurácia vLLM: pipeline_parallel_size

--pipeline-parallel-size M rozdelí model po vrstvách do M skupín. Celkový počet GPU = tensor_parallel_size × pipeline_parallel_size. Odporúčanie z dokumentácie:

• Jeden uzol, ≤ 8 GPU, model sa zmestí: čisté TP, pipeline_parallel_size=1.
• Viac uzlov: TP vnútri uzla, PP medzi uzlami. Dvojuzlový klaster s 8 GPU beží na TP=4, PP=2.
• Počet GPU nedelí počet hláv načisto: nastavte TP=1, PP=počet GPU. PP sa o počet hláv nestará. (Päť-GPU stroj — jeden slot ukrojila sieťovka — zvládne Llamu len cez PP=5.)

Expert parallel — iba pre MoE

Modely MoE (DeepSeek-V3, Mixtral, varianty Qwen-MoE) neaktivujú pri každom tokene každý parameter. Majú routované FFN vrstvy, kde na token vystrelí len malá podmnožina „expertov“; husté attention vrstvy zostávajú husté.

Expert parallel (EP) sharduje expertov medzi GPU a husté vrstvy ponecháva pod TP alebo DP. S prepínačom --enable-expert-parallel sa vrstvy expertov prepnú z replikovaných na rozdelené, jeden alebo pár expertov na GPU. Komunikačný vzor je all-to-all na každú MoE vrstvu: tokeny sa smerujú na to GPU, ktoré vlastní cieľového experta, tam sa spočítajú a vrátia sa.

EP je na šírku pásma nárazové. Vďaka nemu sú veľké MoE modely na PCIe klastroch vôbec zvládnuteľné — plné TP na modeli so 671B aktívnych parametrov je beznádejné. Pre nasadenia Kentino je EP relevantné len pri modeloch triedy DeepSeek-V3; hustá Llama 70B z neho neťaží. Vstupným bodom je vstavané EP vo vLLM spolu s čerstvým buildom.

Data parallel — nudná, geniálna os

DP je najjednoduchšia os škálovania a zároveň tá, ktorú väčšina inštalácií nevyužíva. Spustíte N identických kópií modelu, každú na vlastnej sade GPU (každá sada môže sama používať TP a/alebo PP). Load balancer rozstrekuje požiadavky na tú repliku, ktorá má kapacitu.

Čo DP prináša:

• Lineárne škálovanie priepustnosti (N× požiadaviek za sekundu).
• Nulová komunikácia medzi replikami počas inferencie.
• Nezávislé KV cache na každú repliku (prefix cache je per replika).
• Triviálna izolácia porúch.

Čo DP stojí:

• N× pamäť GPU — každá replika drží celý model.
• Žiadne zníženie latencie. Jedna požiadavka trvá toľko, koľko trvá na jednej replike.

Ak máte stroj so 4× RTX Pro 6000 a Llama 70B sa zmestí do TP=4, druhý štvor-GPU stroj vám dá DP=2 × TP=4 — dvojnásobnú priepustnosť pri rovnakej latencii na požiadavku. Pre chat, agentné a RAG workloady je to správny obchod. Prepínač --data-parallel-size vo vLLM (a novší režim data_parallel_deployment) spúšťa a spravuje repliky. DP je najčistejší spôsob, ako škálovať za hranicu jedného stroja.

Kombinovanie osí — pravidlo palca

Výber osi: začnite najmenším paralelizmom, ktorý sa zmestí, a DP pridávajte skôr než PP.

Praktický príklad. Servovanie Llama 3.3 70B (FP8 ≈ 75 GB váh plus KV) pri vysokej konkurencii:

• Stroj so 4× RTX Pro 6000 Blackwell (4 × 96 GB = 384 GB) ho pohodlne utiahne na TP=4 a zostane ~250 GB na KV, prefix cache a CUDA grafy.
• Pridajte druhý stroj so 4× Pro 6000. DP=2 × TP=4. Dve repliky za routerom. Dvojnásobná priepustnosť, rovnaká latencia.
• Llama 3.1 405B vo FP8 (~400 GB váh)? Jeden stroj so 4× Pro 6000 nestačí. Dva stroje cez PP=2 × TP=4 áno — a medziuzlová linka presúva aktivácie, nie all-reduce. 25 GbE stačí, 100 GbE je pohodlné.

KV cache: časť, ktorú každý podceňuje

KV cache sú kumulatívne key/value tenzory attention pre každý token promptu, každý vygenerovaný token, každú súbežnú požiadavku a každú vrstvu. Rastie lineárne s dĺžkou kontextu aj s konkurenciou. Llama 70B pri 8 K kontexte potrebuje zhruba 2.5 GB KV cache na požiadavku vo FP16. Pri 32 súbežných požiadavkách je to 80 GB — viac než celá VRAM 5090.

Ako paralelizmus ovplyvňuje KV:

• Pri TP je KV shardovaná podľa attention hláv v rámci TP skupiny. KV na jedno GPU = total / tensor_parallel_size. Vyššie TP → väčšia rezerva pre súbežné požiadavky.
• Pri PP zostáva KV na GPU, ktoré drží vrstvu, čo ju vytvorila. Každý stupeň vlastní svoju KV.
• Pri DP je KV plne nezávislá na každej replike.
• Pri context parallel (novší režim vLLM) je KV shardovaná pozdĺž dimenzie sekvencie — užitočné pri veľmi dlhých kontextoch jednej požiadavky.

Pri dimenzovaní stroja nekontrolujte len to, či sa zmestia váhy. Prepočítajte KV pri cieľovej konkurencii a kontextovom okne. Najčastejším tichým zlyhaním v produkčnom vLLM je engine, ktorý pod tlakom na KV odkladá požiadavky.

Smerovanie požiadaviek — čo stojí pred klastrom

Jedna inštancia vLLM si rieši vlastné interné batchovanie (continuous batching, prefix caching, plánovanie). Medzi replikami však nesmeruje. To je úloha routera.

Pre inštaláciu s dvoma replikami je správnou predvoľbou NGINX — round-robin, health-check na /health a hotovo. vLLM Router (Rust, vydaný koncom roka 2025) je správna voľba vo chvíli, keď vašej koncovej latencii dominuje úspešnosť prefix cache: smeruje podľa konzistentného hashovania prefixu promptu, takže cache-teplé repliky dostávajú tie isté konverzácie. Pri agentnom workloade s dlhými zdieľanými systémovými promptmi to oproti round-robinu môže zdvojnásobiť efektívnu priepustnosť.

Matematika šírky pásma

Krížové odkazy: N02, N06.

Poctivé zhrnutie: TP a EP chcú zostať vnútri stroja. PP a DP je to jedno. S medziuzlovou linkou 10–25 GbE sú PP aj DP v pohode. Vo chvíli, keď chcete TP cez uzly, platíte za InfiniBand HDR alebo 200 GbE RoCE — a najprv by ste sa mali spýtať, či vám DP nad jednouzlovými TP skupinami nedá rovnaký výsledok za desatinu rozpočtu. Pri väčšine nasadení veľkosti Kentino dá.

Dva konkrétne konfiguračné recepty

Recept A — jeden uzol, 4× RTX 5090, Llama 70B Q4 / FP8

Hardvér: Kentino AI 256 Turin Dual alebo ľubovoľný štvor-GPU stroj s 5090. PCIe Gen 5, bez NVLinku, hostiteľ AMD EPYC.

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

Očakávajte zhruba 30–40 tok/s na požiadavku pri nízkej konkurencii a agregovane ~400–600 tok/s pri 32 súbežných (líši sa podľa mixu promptov, úspešnosti prefix cache a konkrétnej kvantizácie — berte to ako východiskovú obálku). Pri dekódovaní je úzkym miestom all-reduce cez PCIe Gen 5; prefill škáluje takmer lineárne.

Recept B — dva uzly, spolu 8× RTX Pro 6000 Blackwell, Llama 405B FP8

Dva stroje Kentino AI, každý so 4× Pro 6000 (96 GB). Medzi nimi 100 GbE RoCE linka, prípadne 25 GbE pri napätom rozpočte (bude fungovať, prefill bude mierne pomalší).

# 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 vnútri každého uzla využíva na all-reduce PCIe Gen 5. PP=2 medzi uzlami posiela aktivácie cez 25/100 GbE. S Rayom ako distribuovaným backendom (predvoľba vLLM pre viac uzlov) hlavný uzol koordinuje plánovanie a stav KV.

Poctivé zhodnotenie výkonu: 405B vo FP8 cez 8× Pro 6000 po PCIe a Ethernete vychádza okolo 6–12 tok/s na požiadavku — výrazne menej než šasi s 8× SXM B200, ale za zlomok investície a bez problémov s dostupnosťou SXM. Ak vaše SLA znie „odpovedz do 30 s na 500-tokenové dokončenie“, funguje to. Ak znie „odpovedz do 2 s“, nepoužívajte 405B — použite 70B.

Čo neprevádzkujeme

NVLink, NVSwitch, SXM B200, plné HGX dosky: v portfóliu Kentino nie sú. Sú správnou odpoveďou, ak máte rozpočet aj workload. Nie sú správnou odpoveďou pre väčšinu našich zákazníkov, ktorí dimenzujú na 1–4 súbežné agentné workflowy alebo jednu robotickú platformu, nie na SaaS inferenciu pre 1 000 používateľov. Cesta cez PCIe je poctivá v tom, čo zvláda a čo nie. TP cez 16 GPU pod 10 ms na token je iná debata — nie klaster, o ktorom je tento článok.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI compute, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy uvítame na info@kentino.com.