Jeden uzel s více GPU vs. více uzelů: Kdy horizontálně navýšit kapacitu

Nejdražší chybou ve fázi nákupu je rozdělení rozpočtu na GPU mezi dva uzly, když by práci zvládl jeden větší uzel. Druhou nejdražší je zůstat na jednom uzlu, když pracovní zátěž skutečně potřebuje fabric, a pak strávit šest měsíců předstíráním, že systém to zvládá.

Tento článek představuje logiku rozhodování pro toto rozdělení: kdy je jeden 8-GPU box správnou odpovědí, kdy ne a jak zjistit, na které straně hranice se nachází vaše pracovní zátěž. Doprovodné články se zabývají mechanismy (K02 výcvik, K03 odvození, K07 Limity PCIe, K06 zpracování selhání); v tomto případě je rozhodnutí kupujícího.

Strop 8 GPU podle modelu

První otázkou je, zda se model vejde do jednoho uzlu. S 8× RTX Pro 6000 Blackwell (96 GB každá) získáte 768 GB použitelné VRAM; s 8× RTX 5090 (32 GB každá) získáte 256 GB. Ani jedna z nich není na poměry roku 2026 malá, ani jedna nepojme všechno.

Útes je na hranici 405B / 671B. Pod ní stačí jedna 8-GPU Pro 6000. Na a výše buď agresivně kvantujete (váhy INT4 – dobré pro inferenci, mizerné pro trénování), nebo překračujete hranici uzlu.

„Vhodí se“ není totéž co „běží dobře“. Model, který zabírá 95 % VRAM bez prostoru pro KV cache, prefix cache, CUDA grafy nebo aktivační paměť, bude předcházet požadavkům při jakékoli reálné zátěži. Funkční pravidlo: váží 60–70 % VRAM a 30–40 % ponechává pro všechno ostatní. S tímto omezením to dělá 405B v FP8. ne pohodlně se vejde na 8× Pro 6000 pro inferenci při jakékoli užitečné souběžnosti – odpovídá vahám, ne pracovní zátěži.

Kdy byste NEMĚLI horizontálně navyšovat

Případy, kdy je pobyt na jednom uzlu jednoznačně správný:

• Inference pro jakýkoli model, který se hodí. Pokud model plus KV odpovídá cílové souběžnosti, je víceuzlový TP přes Ethernet nebo IB výrazně pomalejší než jeden uzel. PCIe Gen5 uvnitř krabice poskytuje ~50 GB/s mezi GPU na stejném přepínači; 200 Gb/s IB mezi uzly poskytuje ~25 GB/s. Pracovní zátěž, která na PCIe kulhá, se na IB prohledává.
• Produkční služby pro jednoho klienta. Jeden model, jeden klient, střední souběžnost. 8-GPU Pro 6000 snadno zvládne 70B s 32–64 souběžnými požadavky. Druhý modul je užitečný pouze jako horká náhrada nebo zdvojnásobení propustnosti DP – ani jeden z nich není „škálovatelný“ v těsném smyslu.
• Výzkumné laboratoře provozující modely 7B–72B. Většina akademických a aplikovaných prací v roce 2026 se nachází zde – Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma, jemně doladěný ocas 70B. Žádná z nich nepotřebuje více než jeden uzel.
• Jemné doladění LoRA / QLoRA. Smyslem PEFT je, že nepotřebujete trénovací zdroje pro celý model. 70B LoRA se vejde na 4–8 GPU v jednom uzlu; 405B QLoRA se vejde na 8× Pro 6000.
• Dávková inference a offline úlohy. Pokud je SLA „zpracovat tento korpus do pátku“, zvládne to dávkové zpracování v propustném režimu na jednom 8GPU serveru. Víceuzlové zpracování pomáhá pouze tehdy, když nemůžete dokončit včas – obvykle proto, že je model příliš velký, ne proto, že je jeden uzel příliš pomalý.

Zhruba 80 % zákazníků Kentina by si mělo koupit jeden větší uzel místo dvou menších a většina zbývajících 20 % chce repliky DP za load balancerem, nikoli za clusterem.

Kdy MUSÍTE horizontálně navýšit kapacitu

Případy, kdy jeden uzel skutečně nestačí, jsou omezenější, než se předpokládá.

Trénování modelu 70B+ od nuly. Osm GPU nestačí na vytížení. Předtrénování 70B s publikovanými rozpočty tokenů (1.5–15T) trvá stovky měsíců GPU na hardwaru třídy H100, na spotřebitelských GPU PCIe více. Tato práce vyžaduje 32–128+ GPU a SXM fabric. Kentino tuto úroveň nevytváří.

Jemné doladění na úrovni 70B+ v plném rozsahu. Ne LoRA – plné jemné doladění s rezidentními stavy optimalizátoru, gradienty a aktivacemi. Úplné jemné doladění 70B (váhy FP16 + FP32 Adam + grad + aktivace) představuje 1.2–1.5 TB stavu, což je i s FSDP více než jeden uzel s 8 GPU. Ospravedlňuje IB cluster s 2–4 uzly.

Hosting 405B+ s produkční latencí. Váhy odpovídají INT4 na 8× Pro 6000, ale KV cache plus souběžné obsluhování s použitelnou latencí vás tlačí na dva nebo více uzlů. Dva 8-GPU Pro 6000 boxy v TP=8 × PP=2 nebo TP=4 × PP=4 jsou realistické minimum pro Llama 3.1 405B při slušném QPS. K03 rozbaluje tohle.

Produkce pro více nájemců s agregovanou rychlostí >100 000 QPS. Jeden uzel s 8 GPU obsluhuje agregátně 500–2 000 toků/s při 70B FP8. Nad desítky tisíc QPS chcete více replik a nad tento limit chcete skutečný cluster s routerem a směrováním s ohledem na prefix-cache. Správná odpověď je obvykle mnoho replik DP, ne jeden obrovský cluster TP.

Mimo tyto čtyři argumenty rychle slábnou. Většina otázek typu „Potřebuji více uzlů“ se nakonec ukáže jako „Chci větší propustnost“ – otázka týkající se repliky, nikoliv fabric.

Ideální místo pro jeden uzel

Geometrie silné jednouzlové sestavy na hardwaru, který Kentino skutečně dodává:

Klíčové omezení: NVLink na těchto kartách není. RTX 5090, RTX Pro 6000 Blackwell, L40, L4 jsou připojeny přes PCIe. Moduly NVLink-fabric SXM (H100 SXM, B200 SXM, GB200) vyžadují základní desky HGX, které nevyrábíme. K07 pokrývá náklady; N03 pokrývá, když na NVLinku záleží.

Cesta PCIe je vhodná pro práci zaměřenou na inferenci a většinu trénování blíže k hranici možností. Dávkování v propustném režimu amortizuje veškeré náklady na inferenci. Pro jemné ladění modelů s pevnou velikostí je penalizace nástěnných hodin oproti SXM 1.2–1.4× – obvykle přijatelná. Pro tenzorově paralelní trénování 70B+ od nuly je penalizace 2–3× a odpověď zní: „kupte si SXM, nebo tuto práci nedělejte na hardwaru Kentino.“

Útes mezi jednouzlovým a víceuzlovým systémem

Věc, která dělá z víceuzlových systémů jinou kategorii, je propast mezi vnitrouzlovými a meziuzlovými systémy, a to z hlediska šířky pásma a latence.

Uvnitř krabice dva GPU komunikují rychlostí ~50 GB/s s mezipásmovými přeskaky v řádu submikrosekund. Napříč uzly dosáhnete ~25 GB/s na 200 Gb/s IB – což je 2× penalizace na IB, 4–5× na 100 GbE a 15× na 25 GbE. Pro kolektivy TP, které využívají každou transformační vrstvu, to dost škodí. K07 má tabulku časování se všemi redukcemi.

Latence to znásobuje: meziuzlová doba je 5–15 mikrosekund na vyladěném RoCE oproti nanosekundám uvnitř boxu. Pro trénování a předvyplňování se to zaokrouhluje; pro interaktivní inferenci s nízkou latencí a přesným TP to neplatí.

Problém je v tom, proč „prostě přidat další krabici“ není trvalé rozhodnutí. Cokoli, co sotva přežije na PCIe uvnitř jednoho uzlu, nepřežije na Ethernetu nebo IB mezi uzly.

Strong-scalling matematika: kde se to překrucuje

Amdahlův zákon: zrychlení je omezeno sériovým podílem pracovní zátěže a pro distribuované trénování je tento podíl komunikační režie. Pro trénovací krok třídy 70B na hardwaru PCIe třídy Kentino vypadá efektivita škálování (propustnost na GPU vs. základní hodnota pro jeden GPU) napříč sestaveními, která jsme dodali, takto:

Dvě ponaučení. Zaprvé, Rozdělení úlohy s 8 GPU na dva uzly se 4 GPU je horší než její spuštění na jednom serveru. — každá síťová struktura mezi uzly je pomalejší než PCIe v krabici, kterou jste již měli. Za druhé, Paralelismus dat se napříč strukturou Fabric škáluje mnohem lépe než paralelismus tenzorů. Pokud vaše skutečná otázka zní „mohu obsloužit více požadavků“ spíše než „mohu spustit jeden větší model rychleji“, fungují repliky DP a fungují přes komoditní 100 GbE.

Pokud projektovaná efektivita klesne pod 60 %, je pracovní zátěž pro více uzlů na komoditní fabrice nesprávně dimenzována. Změňte architekturu (TP uvnitř uzlu, PP nebo DP napříč), kupte větší jeden uzel nebo hardware třídy SXM. Hrubá síla nefunguje.

Past výzkumné laboratoře a provozní daň

Vzor, který vidíme dostatečně často, abychom ho zdůraznili: laboratoř plánuje „budoucnost“ a objedná dva uzly se 4 GPU místo jednoho uzlu s 8 GPU. Ve skutečnosti však dosáhne horšího trénování (0.65× TP mezi uzly vs. 0.73× TP uvnitř uzlu), horší inference pro jakýkoli model, který se vejde do jedné krabice, dvojnásobné provozní zatížení (dvě BMC, dvě ladění síťové karty, dva stavy pinů ovladače, dvě domény selhání) a zhruba stejné náklady na součástky po upgradu druhé síťové karty, druhého zdroje a přepínače. Nejprve si kupte jeden uzel s 8 GPU.

Více uzlů, pokud je to správná odpověď, není zdarma. Dodatečná daň:

• Sdílené úložiště — lokální NVMe už nestačí. NFS, BeeGFS nebo Lustre a úložná VLAN (K04).
• Asynchronní horizontálně dělené kontrolní body — synchronní nedefragilované zápisy do NFS zastaví cluster. PyTorch DCP nebo NeMo je povinný, nikoli volitelný.
• Ladění síťové karty a NCCL — Řízení toku RoCE, PFC, ECN, jumbo rámce, volba transportu NCCL, topologické soubory, kruhové vs. stromové algoritmy. Každý knoflík bude hned po instalaci špatný.
• monitorování — DCGM na uzel, federace Prometheus, trasovací vyrovnávací paměti NCCL.
• Ošetření selhání — odpojení uzlů, reset síťové karty, uzavření portů přepínače. K06 pokrývá režimy; četnost selhání více uzlů je zhruba N-krát vyšší než u jednoho uzlu, obnova je chaotičtější.

Z hlediska inženýrského času stojí více uzlů 4–5× více za každý přidaný uzel. Počítejte s tím, nebo akceptujte, že cluster stráví prvních šest měsíců na polovině teoretické kapacity.

Tok konkrétního rozhodování

Projděte si to v pořadí. První „ano“ konverzaci ukončí.

1. Vejde se do modelu 8× 96 GB v FP8 s 30–40% rezervou VRAM pro KV? Pokud ano, jeden uzel, hotovo.
2. Pasuje to na INT4 se stejnou rezervou? Pokud ano a provádíte inferenci (ne trénujete), pak je odpovědí jeden uzel na INT4. Váhy INT4 nejsou pro gradientní cestu trénování použitelné – pokračujte.
3. Je pracovní zátěž omezena propustností, nikoli velikostí modelu? Pokud ano, odpovědí jsou datově paralelní repliky konfigurací s jedním uzlem, nikoli cluster. Dvě zařízení za load balancerem, žádná fabrica není potřeba.
4. Je pracovní zátěž tenzorově paralelním trénováním modelu, který se nevejde do jednoho uzlu? Více uzlů s InfiniBand. Efektivita škálování projektu pomocí K07tabulka `s. Pod 60 %, přepracujte architekturu (TP uvnitř, PP napříč) nebo snižte počet uzlů a akceptujte pomalejší dobu načítání.
5. Je předtrénování úlohy modelem o velikosti 70 miliard dolarů od nuly? Případ Frontier. Více uzlů s NDR IB nebo SXM. Kentino může sestavit stranu IB, ale většina zákazníků, kteří se ptají, tuto práci ve skutečnosti nemusí dělat sami.

Kroky jedna a dva tvoří většinu trhu. Krok tři znamená, že se vám daří – odpovědí jsou repliky, ne shluk. Kroky čtyři a pět jsou skutečné, ale vzácné.

Upřímný pohled

Víceuzlové technologie jsou na samé hranici – 70 miliard+ trénování od nuly, 405 miliard+ inference s produkční latencí, hyperškálování s rychlostí nad 100 tisíc QPS nebo výzkum, který závisí na denní propustnosti, kterou jeden server nedokáže poskytnout. To jsou reálné úlohy. Netvoří většinu toho, co se vytvoří.

Pro všechno ostatní je řešením jeden dobře specifikovaný 8-GPU uzel. Zvládá každou inferenční úlohu s otevřenou váhou 2026, která se vejde do 768 GB na FP8/INT4, LoRA a QLoRA až do 405B, zvládá kompletní jemné doladění třídy 13B bez stížností a škáluje se na dvě nebo tři repliky DP pro zajištění propustnosti bez nutnosti clusterové fabrice. A jeho provoz je dramaticky jednodušší.

Forma konverzace, kterou vedeme s většinou zákazníků: popis pracovní zátěže, výpočty přizpůsobivosti, efektivita škálování projektu. Pokud je projekce cluster, vytvořte cluster. Pokud se jedná o jeden uzel, vytvořte jeden uzel. Pokud se jedná o dvě repliky za routerem, vytvořte tu. Neprodáváme největší konfiguraci, kterou budete tolerovat – prodáváme tu, která bude skutečně fungovat.

---

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.