Inferenční klastry: vLLM Tensor Parallel, Pipeline Parallel a kolik vás každý z nich skutečně stojí

Model třídy 70B se nevejde na jednu GPU při žádné kvantizaci, která ponechává užitečnou KV mezipaměť. Model 405B se nevejde na jeden uzel. Jakmile je to pravda, otázka již nezní „kterou GPU“, ale „jak rozříznu model napříč GPU, které mám, a kolik mě každý rozříznutí stojí?“.

Tento článek se zabývá čtyřmi způsoby, jakými vLLM umožňuje rozdělení modelu – tenzorový paralelní, pipeline paralelní, expertní paralelní a datový paralelní – jak každý z nich ovlivňuje váš účet za šířku pásma a jak si mezi nimi vybrat v řadě Kentino (5090 s připojením PCIe, RTX Pro 6000 Blackwell, L40, L4 – žádné součástky NVLink-fabric SXM). Publikum četlo. I01, ví, co je vLLM, a nyní potřebuje provést konfigurační rozhodnutí.

Čtyři rozměry řezání modelu

Každý framework pro distribuovanou inferenci – vLLM, SGLang, TensorRT-LLM, Triton – nabízí nějakou kombinaci stejných čtyř os. Nejsou to alternativy; skládají se.

Třetí sloupec představuje celou hru. TP křičí přes sběrnici na každé vrstvě. PP šeptá mezi dvěma fázemi. Tato jediná skutečnost rozhoduje o tom, zda ponecháte TP uvnitř jednoho boxu, posunete PP napříč uzly a kam spadne čára.

Tenzorová paralelnost – jak to vlastně funguje

V TP je každá váhová matice v transformátoru (pozornost QKV, výstup pozornosti, FFN nahoru, FFN dolů) rozdělena na řezy. tensor_parallel_size GPU. Každá GPU ukládá jeden shard z každé vrstvy a vypočítává jeden shard z každé aktivace. Protože pozornost a FFN obsahují matmuly, které potřebují plně aktivace znovu sestavena před další operací (softmax, SwiGLU), dílčí výsledky musí být zkombinovány. vLLM to dělá pomocí all-reduce na konci pozornosti a další na konci FFN – dva na transformátorový blok.

Llama 3.3 70B má 80 vrstev, skrytých 8192. Při dekódování dávky 32 se každý all-reduce pohybuje ~512 KB, ×160 na vygenerovaný token → ~80 MB na token přes sběrniciPředplnění je dramaticky horší: předplnění o objemu 4 K v dávce 32 tlačí řádově 300 GB skrz redukční prstenec jedním průchodem dopředu.

To číslo je důvod, proč TP miluje NVLinkSXM H100/B200 NVLink má rychlost 900 GB/s. PCIe Gen 5 x16 má v nejlepším případě rychlost 64 GB/s jednosměrně, 128 GB/s obousměrně – na desce se 4 GPU se to stává jen zřídka (linky jsou obvykle sdílené, viz… W02). Rozdíl 14×–28× se projevuje v benchmarkových testech: Účinnost škálování NVLink dosahuje ~0.92×/kartaPCIe ~0.70–0.78×/karta u modelů třídy 70B.

Praktický důsledek: TP se dobře škáluje na 4 GPU v jednom uzlu PCIe Gen 5. Kromě toho paralelismus ušetří více než all-sub-continuing, a proto byste měli raději sáhnout po pipeline parallel.

Konfigurace vLLM: tensor_parallel_size

--tensor-parallel-size N říká enginu, aby rozdělil každý váhový tenzor napříč N GPU v lokálním uzlu. Omezení:

• N musí vydělit počtem hlav zaměřených na pozornost modelu (Llama 70B má 64 hlav → N ∈ {1, 2, 4, 8, 16, 32, 64}).
• vLLM umisťuje TP pozice na stejný uzel a předpokládá rychlou sběrnici v rámci uzlu.
• Mezipaměť KV je rozdělena podél dimenze head – každá GPU ukládá total_heads / N hodnota hlav. Vyšší TP dává větší prostor pro KV na požadavek.

Na hardwaru Kentino: TP=4 na boxu s 4× RTX 5090 nebo 4× RTX Pro 6000 Blackwell je ideální volbou. TP=8 funguje, ale sběrnice PCIe se chvěje; uvnitř boxu s 8 grafickými kartami je obvykle lepší TP=4 × PP=2.

Paralelní potrubí – možnost napříč místností

PP rozděluje model hloubkou, S pipeline_parallel_size=2GPU 0 obsahuje vrstvy 0–39 70B Llamy, GPU 1 obsahuje vrstvy 40–79. Požadavek prochází GPU 0, aktivační tenzor odesílá se do GPU 1, GPU 1 dokončí průchod dopředu.

Komunikace je jeden tenzor tvaru (batch, seq_len, hidden_size) na hranici fáze. Pro dávku 32, sekvenci 4096, skrytou 8192, FP16, tj. ~1 GB na předběžné vyplnění a ~0.5 MB na dekódovací token v dávce 32 — o dva řády méně než TP all-reduce. PP pohodlně probíhá napříč obyčejný 25 GbE nebo dokonce 10 GbE.

Kompromis je latenceS PP=2 každý token přeskakuje mezi fázemi – naivně 2× doba zpracování tokenu. vLLM tento problém zmírňuje pomocí mikrodávkování: fáze 0 spouští další mikrodávku, zatímco fáze 1 dokončuje tu aktuální. S dostatečnou souběžností se bublina uzavře; s jedním požadavkem a žádným dávkováním je PP daní z latence, která nemá žádný zisk.

Konfigurace vLLM: pipeline_parallel_size

--pipeline-parallel-size M rozděluje model podle vrstev napříč M skupinami. Celkový počet GPU = tensor_parallel_size × pipeline_parallel_sizePokyny k dokumentům:

• Jeden uzel, ≤ 8 GPU, model odpovídá: čistý TP, pipeline_parallel_size=1.
• Více uzlů: TP v rámci uzlu, PP napříč uzlyDvouuzlový cluster s 8 GPU běží na TP=4, PP=2.
• Počet GPU nedělí počet hlav čistě: nastavte TP=1, PP=GPU. PP se o počet hlav nestará. (Počítač s 5 GPU – jeden slot ztracený pro síťovou kartu – může spustit Llamu pouze přes PP=5.)

Expertní paralelní – pouze pro MŠMT

Modely MoE (příchutě DeepSeek-V3, Mixtral, Qwen-MoE) neaktivují každý parametr na každém tokenu. Mají směrované vrstvy FFN, kde se na token aktivuje pouze malá podmnožina „expertů“; husté vrstvy pozornosti zůstávají husté.

Expertní paralelní (EP) experti na shardy napříč grafickými procesory při zachování hustých vrstev pod TP nebo DP. S --enable-expert-parallel, expertní vrstvy přepínají z replikovaných na dělené, jeden nebo několik expertů na GPU. Komunikační vzorec je všichni ke všem na vrstvu MoE: tokeny směrují k GPU, které vlastní cílového experta, a vracejí se.

EP je vysoce výkonný z hlediska šířky pásma. Díky tomu jsou velké modely MoE vůbec zpracovatelné na clusterech PCIe – plný TP na modelu s aktivní kapacitou 671B je beznadějný. Pro nasazení Kentina je EP relevantní pouze pro modely třídy DeepSeek-V3; hustá Llama 70B z toho neprospívá. Vestavěný EP vLLM a nedávná sestavení jsou výchozím vstupním bodem.

Datová paralela – nudná, brilantní osa

DP je nejjednodušší osa pro škálování a zároveň ta, kterou většina instalací nevyužívá. Roztočíte se nahoru. N identických kopií modelu, každý na vlastní sadě GPU (každá sada může sama o sobě používat TP a/nebo PP). Vyrovnávač zátěže rozděluje požadavky na repliku, která má kapacitu.

Co DP nabízí:

• Lineární škálování propustnosti (N× požadavků/s).
• Nulová komunikace mezi replikami během inference.
• Nezávislé mezipaměti KV na repliku (prefixová mezipaměť je na repliku).
• Izolace triviálních poruch.

Kolik stojí DP:

• N× paměť GPU – každá replika obsahuje celý model.
• Žádné snížení latence. Jeden požadavek zabere tolik, kolik je potřeba na jednu repliku.

Pokud máte box s 4× RTX Pro 6000 a Llama 70B se vejde do TP=4, druhý box s 4× poskytuje DP=2 × TP=4 – dvojnásobnou propustnost, stejnou latenci na požadavek. Pro úlohy chatu, agentů a RAG je to správná výměna. vLLM --data-parallel-size vlajka (a novější data_parallel_deployment režim) spouští a spravuje repliky. DP je nejčistší způsob škálování za hranice jednoho boxu.

Kombinování os – základní pravidlo

Výběr osy: začněte s nejmenší rovnoběžností, která se hodí, a poté přidejte DP před PP.

Příklad zpracování. Obsluha Llama 3.3 70B (FP8 ≈ 75 GB vah plus KV) s vysokou souběžností:

• Krabice s 4× RTX Pro 6000 Blackwell (4 × 96 GB = 384 GB) jej pohodlně zvládá s TP=4, přičemž pro KV, prefix cache a CUDA grafy zbývá ~250 GB.
• Přidejte druhý box 4× Pro 6000. DP=2 × TP=4. Dvě repliky za routerem. Dvojnásobná propustnost, stejná latence.
• Llama 3.1 405B v FP8 (váhy ~400 GB)? Jeden box 4× Pro 6000 se nevejde. Dva boxy přes PP=2 × TP=4 ano – a propojení mezi uzly přesouvá aktivace, ne redukuje je. 25 GbE stačí; 100 GbE je pohodlné.

KV cache: část, kterou všichni podceňují

Mezipaměť KV je kumulativní tenzor klíč/hodnota pozornosti pro každý token promptu, každý vygenerovaný token, každý souběžný požadavek, každou vrstvu. Lineárně roste s délkou kontextu a souběžností. Llama 70B při 8 K kontextu potřebuje zhruba 2.5 GB mezipaměti KV na požadavek v FP16. Při 32 souběžných požadavcích to je 80 GB – více než celá VRAM 5090.

Jak paralelismus interaguje s KV:

• Pod TP, KV je rozdělena podle attention head napříč skupinou TP. KV na GPU = total / tensor_parallel_sizeVyšší TP → větší prostor pro souběžné požadavky.
• Pod PPKV zůstává na GPU a obsahuje vrstvu, která jej vytvořila. Každá fáze vlastní svůj vlastní KV.
• Pod DP, KV je plně nezávislý na každé replikě.
• V kontextu paralelně (novější režim vLLM), KV je rozdělen podél sekvence dimenze – užitečná pro velmi dlouhé kontexty s jedním požadavkem.

Při určování velikosti krabice se nepokoušejte pouze ověřovat, zda závaží Spusťte matematický výpočet KV v cílovém okně souběžnosti a kontextu. Nejčastějším tichým selháním v produkčním vLLM je, že engine předchází požadavkům pod tlakem KV.

Směrování požadavků – co se nachází před clusterem

Jedna instance vLLM si sama zpracovává interní dávkování (kontinuální dávkování, ukládání prefixů do mezipaměti, plánování). Nesměruje napříč replikami. To je úkol routeru.

NGINX je správná výchozí volba pro instalaci se 2 replikami – round robin, kontroly stavu zapnuté. /healthHotovo. Router vLLM (Rust, vydaný koncem roku 2025) je tou správnou volbou, pokud míra zásahů do prefix-cache dominuje vaší latenci ocasu: směruje na základě konzistentního hashování prefixu výzvy, takže repliky s podporou mezipaměti stále dostávají stejné konverzace. Pro pracovní vytížení agenta s dlouhými sdílenými systémovými výzvami to může zdvojnásobit efektivní propustnost oproti round robin.

Matematika šířky pásma

Křížové odkazy: N02, N06.

Upřímný přečtený text: TP a EP chtějí zůstat v škatulcePP a DP na tom nezáleží. S propojením mezi uzly 10–25 GbE jsou PP a DP v pořádku. V okamžiku, kdy chcete TP napříč uzly, platíte za InfiniBand HDR nebo 200 GbE RoCE – a měli byste se nejprve zeptat, zda vám DP napříč skupinami TP s jedním uzlem přinese stejný výsledek za desetinu rozpočtu. U většiny nasazení velikosti Kentina ano.

Dva konkrétní konfigurační recepty

Recept A — Jeden uzel, 4× RTX 5090, Llama 70B Q4 / FP8

Hardware: K-AI 256 Turin Dual nebo jakýkoli 4-GPU 5090 box. PCIe Gen 5, bez NVLink, hostitel 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čekává se: zhruba 30–40 tok/s na požadavek při nízké souběžnosti, celková hodnota ~400–600 tok/s při 32 souběžných požadavcích (liší se v závislosti na kombinaci promptů, míře zásahů do prefix-cache, přesném množství – považovat za počáteční obálku). PCIe Gen 5 all-reduce je úzkým hrdlem při dekódování; prefill se škáluje téměř lineárně.

Recept B — Dva uzly, celkem 8× RTX Pro 6000 Blackwell, Llama 405B FP8

Dva K-AI boxy, každý 4× Pro 6000 (96 GB). 100 GbE RoCE propojení mezi nimi, nebo 25 GbE, pokud je rozpočet omezený (bude fungovat, o něco pomalejší prefill).

# 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 uvnitř každého uzlu používá PCIe Gen 5 pro redukci všech uzlů. PP=2 napříč uzly zajišťuje aktivace přes 25/100 GbE. S Ray jako distribuovaným backendem (výchozí nastavení vLLM pro více uzlů) koordinuje hlavní uzlový uzl plánování a stav KV.

Upřímné hodnocení výkonu: 405B v FP8 napříč 8× Pro 6000 přes PCIe + Ethernet dosahuje rychlosti okolo 6–12 tokenů/s na požadavek – což je výrazně méně než u šasi 8× SXM B200, za zlomek kapitálových výdajů a bez problémů s dodávkami SXM. Pokud je vaše SLA „odpověď do 30 s pro dokončení 500 tokenů“, funguje to. Pokud je „odpověď do 2 s“, nepoužívejte 405B – použijte 70B.

Co neprovozujeme

NVLink, NVSwitch, SXM B200, plné desky HGX: nejsou v řadě Kentino. Jsou to správné řešení, pokud máte rozpočet a pracovní zátěž. Nejsou to správné řešení pro většinu našich zákazníků, kteří dimenzují pro 1–4 souběžné pracovní postupy agentů nebo platformu s jedním robotem, nikoli pro SaaS inferenci s 1 000 uživateli. Cesta PCIe je upřímná v tom, co může a nemůže dělat. TP pod 10 ms na token napříč 16 GPU je jiná konverzace – ne cluster, o kterém je tento článek.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.