Jeden node s více GPU vs. více nodů: kdy škálovat do šířky

Nejdražší chybou ve fázi nákupu je rozdělit rozpočet na GPU mezi dva uzly ve chvíli, kdy by práci zvládl jeden větší. Druhou nejdražší je zůstat na jednom uzlu tam, kde workload opravdu potřebuje fabric, a pak půl roku předstírat, že skříň stíhá.

Tento článek je rozhodovací logikou pro toto rozcestí: kdy je jedna skříň s 8 GPU správnou odpovědí, kdy není a jak poznat, na které straně hranice Váš workload leží. Doprovodné články pokrývají mechaniku (K02 trénink, K03 inference, K07 limity PCIe, K06 řešení výpadků); tento je rozhodnutím kupujícího.

Strop 8 GPU podle modelů

První otázka zní, jestli se model vejde do jednoho uzlu. S 8× RTX Pro 6000 Blackwell (96 GB každá) máte 768 GB využitelné VRAM, s 8× RTX 5090 (32 GB každá) 256 GB. Ani jedno není na poměry roku 2026 málo, ani jedno nepojme všechno.

Zlom nastává na hranici 405B / 671B. Pod ní stačí jedna skříň s 8× Pro 6000. Na ní a nad ní buď agresivně kvantizujete (váhy v INT4 — pro inferenci v pořádku, pro trénink bída), nebo překračujete hranici uzlu.

„Vejde se“ není totéž co „běží dobře“. Model, který zabere 95 % VRAM bez rezervy na KV cache, prefix cache, CUDA grafy nebo paměť aktivací, bude při jakékoli reálné zátěži odkládat požadavky. Praktické pravidlo: váhy na 60–70 % VRAM, zbylých 30–40 % na všechno ostatní. S tímto omezením se 405B ve FP8 nevejde pohodlně na 8× Pro 6000 pro inferenci při jakékoli použitelné souběžnosti — vejdou se váhy, ne workload.

Kdy NEMÁTE škálovat do šířky

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

• Inference jakéhokoli modelu, který se vejde. Pokud se model i KV vejdou při cílové souběžnosti, je vícenodové TP přes Ethernet nebo IB prostě pomalejší než jeden uzel. PCIe Gen5 uvnitř skříně nabízí ~50 GB/s mezi GPU na stejném přepínači, 200Gb/s IB mezi uzly ~25 GB/s. Workload, který na PCIe kulhá, se na IB plazí.
• Produkční provoz pro jednoho zákazníka. Jeden model, jeden klient, střední souběžnost. Skříň s 8× Pro 6000 zvládne 70B s 32–64 souběžnými požadavky bez potíží. Druhá skříň se hodí jen jako horká záloha nebo pro zdvojnásobení propustnosti přes DP — ani jedno není „škálování do šířky“ v těsně provázaném smyslu.
• Výzkumné laboratoře provozující modely 7B–72B. Většina akademické i aplikované práce v roce 2026 patří sem — Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma a dlouhý ocas doladěných modelů 70B. Žádný z nich nepotřebuje víc než jeden uzel.
• Doladění přes LoRA / QLoRA. Smysl PEFT je právě v tom, že nepotřebujete prostředky na plný trénink modelu. LoRA pro 70B se vejde na 4–8 GPU v jednom uzlu, QLoRA pro 405B na 8× Pro 6000.
• Dávková inference a offline workloady. Pokud SLA zní „zpracovat tento korpus do pátku“, zvládne to dávkování v režimu propustnosti na jedné skříni s 8 GPU. Více uzlů pomůže jen tehdy, když to do termínu nestihnete — a to obvykle proto, že je model příliš velký, ne proto, že je uzel pomalý.

Zhruba 80 % zákazníků Kentino by si mělo koupit jeden větší uzel místo dvou menších a většina ze zbývajících 20 % ve skutečnosti chce DP repliky za load balancerem, ne cluster.

Kdy škálovat do šířky MUSÍTE

Případů, kdy jeden uzel opravdu nestačí, je méně, než se obvykle předpokládá.

Trénink modelu 70B+ od nuly. Osm GPU prostě nestačí časem. Předtrénink 70B na publikovaných objemech tokenů (1.5–15T) zabere stovky GPU-měsíců na hardwaru třídy H100 a na spotřebních PCIe GPU ještě víc. Tato práce vyžaduje 32–128+ GPU a fabric SXM. Kentino tuto třídu nestaví.

Plnohodnotné doladění modelů 70B+. Ne LoRA — plné doladění s rezidentními stavy optimalizátoru, gradienty a aktivacemi. Plné doladění 70B (váhy FP16 + Adam v FP32 + gradienty + aktivace) znamená 1.2–1.5 TB stavu, což je i s FSDP za hranicí jednoho uzlu s 8 GPU. Ospravedlňuje cluster se 2–4 uzly na IB.

Provoz 405B+ v produkční latenci. Váhy se v INT4 na 8× Pro 6000 vejdou, ale KV cache spolu se souběžným provozem v použitelné latenci Vás posunou na dva a více uzlů. Dvě skříně s 8× Pro 6000 v režimu TP=8 × PP=2 nebo TP=4 × PP=4 jsou reálným minimem pro Llama 3.1 405B při slušném QPS. K03 to rozebírá podrobně.

Víceklientský provoz nad >100k QPS v součtu. Jeden uzel s 8 GPU obslouží v součtu 500–2,000 tok/s u 70B ve FP8. Nad desítky tisíc QPS chcete více replik a nad tím už skutečný cluster s routerem a směrováním podle prefix cache. Správnou odpovědí bývá mnoho DP replik, ne jeden obří TP cluster.

Mimo tyto čtyři případy argument rychle slábne. Většina „potřebuji víc uzlů“ se nakonec ukáže jako „chci vyšší propustnost“ — což je otázka replik, ne fabricu.

Ideální jednouzlová konfigurace

Jak vypadá silná jednouzlová sestava na hardwaru, který Kentino skutečně dodává:

Zásadní omezení: na těchto kartách NVLink není. RTX 5090, RTX Pro 6000 Blackwell, L40 i L4 jsou připojené přes PCIe. Moduly SXM s NVLink fabricem (H100 SXM, B200 SXM, GB200) vyžadují základní desky HGX, které nestavíme. K07 rozebírá cenu, N03 pak to, kdy na NVLinku záleží.

Cesta přes PCIe je správná pro práci zaměřenou na inferenci a pro většinu tréninku pod hranicí špičkového výzkumu. Dávkování v režimu propustnosti u inference rozpustí náklady na all-reduce. U doladění modelů pevné velikosti je penalizace reálného času oproti SXM 1.2–1.4× — obvykle přijatelná. U tenzorově paralelního tréninku 70B+ od nuly je penalizace 2–3× a odpověď zní: „kupte SXM, nebo tuto práci na hardwaru Kentino nedělejte“.

Propast mezi jedním a více uzly

Tím, co dělá z vícenodového řešení jinou kategorii systému, je propast v propojení mezi vnitřkem uzlu a prostorem mezi uzly — v propustnosti i latenci.

Uvnitř skříně spolu dvě GPU mluví rychlostí ~50 GB/s se skoky pod jednu mikrosekundu. Mezi uzly dostanete ~25 GB/s na 200Gb/s IB — tedy 2× penalizaci na IB, 4–5× na 100 GbE a 15× na 25 GbE. U TP kolektivů, které se spouštějí v každé vrstvě transformeru, to bolí hodně. K07 obsahuje tabulku časů all-reduce.

Latence to ještě znásobuje: mezi uzly jde o 5–15 mikrosekund na vyladěném RoCE oproti nanosekundám uvnitř skříně. U tréninku a prefillu se to ztratí v zaokrouhlení, u interaktivní inference s nízkou latencí a těsným TP nikoli.

Právě kvůli této propasti není „prostě přidáme další skříň“ plynulé rozhodnutí. Cokoli, co sotva přežívá na PCIe uvnitř uzlu, nepřežije na Ethernetu ani IB mezi uzly.

Matematika silného škálování: kde se zlomí

Amdahlův zákon: zrychlení je omezené sériovou částí workloadu a u distribuovaného tréninku je touto částí režie komunikace. Pro tréninkový krok třídy 70B na hardwaru s PCIe, jaký staví Kentino, vypadá efektivita škálování (propustnost na GPU oproti jednomu GPU) napříč sestavami, které jsme dodali, takto:

Dva závěry. Zaprvé: rozdělit úlohu pro 8 GPU do dvou uzlů po 4 GPU je horší než ji nechat běžet v jedné skříni — každý fabric mezi uzly je pomalejší než PCIe uvnitř skříně, kterou jste už měli. Zadruhé: datový paralelismus škáluje přes fabric mnohem lépe než tenzorový. Pokud Vaše skutečná otázka zní „zvládnu obsloužit víc požadavků“, a ne „zvládnu rozběhnout jeden větší model rychleji“, DP repliky fungují — a fungují i přes běžné 100 GbE.

Pokud předpokládaná efektivita klesne pod 60 %, má workload pro vícenodový provoz na běžném fabricu špatný tvar. Přearchitektujte ho (TP uvnitř uzlu, PP nebo DP napříč), kupte větší jednotlivý uzel, nebo hardware třídy SXM. Hrubá síla nefunguje.

Past výzkumných laboratoří a provozní daň

Vzorec, který vidíme dost často na to, abychom ho pojmenovali: laboratoř plánuje „do budoucna“ a objedná dva uzly po 4 GPU místo jednoho s 8 GPU. Ve skutečnosti dostane horší trénink (0.65× TP mezi uzly oproti 0.73× uvnitř uzlu), horší inferenci u každého modelu, který se vešel do jedné skříně, dvojnásobnou provozní zátěž (dvě BMC, dvě ladění NIC, dva stavy připnutých ovladačů, dvě domény selhání) a po započtení druhé síťovky, druhého zdroje a upgradu přepínače zhruba stejnou cenu dílů. Kupte nejdřív jeden uzel s 8 GPU.

Vícenodové řešení, i když je správnou odpovědí, není zadarmo. Daň navíc:

• Sdílené úložiště — lokální NVMe přestává stačit. NFS, BeeGFS nebo Lustre plus vyhrazená VLAN pro úložiště (K04).
• Asynchronní rozdělené checkpointy — synchronní nerozdělené zápisy na NFS zastaví celý cluster. PyTorch DCP nebo NeMo je nutnost, ne volba.
• Ladění NIC a NCCL — řízení toku RoCE, PFC, ECN, jumbo rámce, volba transportu NCCL, topologické soubory, ring versus tree algoritmy. Každý knoflík bude z výroby nastavený špatně.
• Monitoring — DCGM na každém uzlu, federace Prometheus, trasovací buffery NCCL.
• Řešení výpadků — odpojení uzlu, resety síťovek, výpadky portů na přepínači. K06 popisuje jednotlivé režimy; poruchovost vícenodového řešení je zhruba N× vyšší než u jednoho uzlu a zotavení je nepříjemnější.

V inženýrském čase stojí každý přidaný uzel 4–5× víc. Počítejte s tím, nebo se smiřte s tím, že cluster stráví prvního půl roku na polovině teoretické kapacity.

Konkrétní rozhodovací postup

Projděte si to popořadě. První „ano“ debatu ukončuje.

1. Vejde se model na 8× 96 GB ve FP8 s rezervou 30–40 % VRAM na KV? Pokud ano, jeden uzel, hotovo.
2. Vejde se v INT4 se stejnou rezervou? Pokud ano a jde Vám o inferenci (ne o trénink), odpovědí je jeden uzel v INT4. Váhy v INT4 nejsou použitelné pro gradientní část tréninku — pokračujte dál.
3. Je workload omezený propustností, a ne velikostí modelu? Pokud ano, odpovědí jsou datově paralelní repliky jednouzlových konfigurací, ne cluster. Dvě skříně za load balancerem, žádný fabric není potřeba.
4. Jde o tenzorově paralelní trénink modelu, který se do jednoho uzlu nevejde? Více uzlů s InfiniBandem. Odhadněte efektivitu škálování podle tabulky v K07. Pod 60 % přearchitektujte (TP uvnitř, PP napříč), nebo snižte počet uzlů a smiřte se s delším reálným časem.
5. Jde o předtrénink modelu 70B+ od nuly? Případ pro špičku oboru. Více uzlů s NDR IB nebo SXM. Kentino dokáže IB stranu postavit, ale většina zákazníků, kteří se ptají, tuto práci ve skutečnosti sama dělat nepotřebuje.

Kroky jedna a dva pokrývají drtivou většinu trhu. Krok tři znamená, že se Vám dobře daří — odpovědí jsou repliky, ne cluster. Kroky čtyři a pět jsou reálné, ale vzácné.

Upřímně

Vícenodové řešení je na místě na špici oboru — trénink 70B+ od nuly, inference 405B+ v produkční latenci, hyperscale provoz nad 100k QPS nebo výzkum závislý na denní propustnosti, kterou jedna skříň nedodá. Jsou to reálné workloady. Nejsou to ale ty, které se staví nejčastěji.

Ve všem ostatním je odpovědí jeden dobře navržený uzel s 8 GPU. Zvládne každý otevřený inferenční workload roku 2026, který se vejde do 768 GB ve FP8/INT4, LoRA i QLoRA až do 405B, plná doladění třídy 13B bez reptání a škáluje na dvě až tři DP repliky kvůli propustnosti i bez clusterového fabricu. A provozuje se nesrovnatelně snadněji.

Rozhovor s většinou zákazníků má tento tvar: popište workload, spočítejte, co se vejde, odhadněte efektivitu škálování. Pokud z toho vyjde cluster, postavíme cluster. Pokud jeden uzel, postavíme jeden uzel. Pokud dvě repliky za routerem, postavíme to. Neprodáváme největší konfiguraci, kterou ještě strpíte — prodáváme tu, která bude skutečně fungovat.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.