Single-Node Multi-GPU vs. Multi-Node: Hvornår skal man skalere ud

Den dyreste fejl i købsfasen er at opdele et GPU-budget på tværs af to noder, når én større node ville have gjort jobbet. Den næstdyreste er at blive på én node, når arbejdsbyrden virkelig har brug for fabric, og derefter bruge seks måneder på at lade som om, at processoren kan følge med.

Denne artikel er beslutningslogikken bag den opdeling: hvornår en enkelt 8-GPU-boks er det rigtige svar, hvornår den ikke er det, og hvordan man kan se, hvilken side af linjen ens arbejdsbyrde sidder på. Ledsagende artikler dækker mekanikken (K02 uddannelse, K03 slutning, K07 PCIe-grænser, K06 håndtering af fejl); dette er købers beslutning.

8-GPU-loftet, efter model

Det første spørgsmål er, om modellen passer ind i én node. Med 8× RTX Pro 6000 Blackwell (96 GB hver) får du 768 GB brugbar VRAM; med 8× RTX 5090 (32 GB hver) får du 256 GB. Ingen af ​​dem er små efter 2026-standarder, og ingen af ​​dem rummer alt.

Klippen er ved 405B / 671B-linjen. Nedenfor er én 8-GPU Pro 6000-boks nok. Ved og over kvantiserer du enten aggressivt (INT4-vægte - fine til inferens, elendige til træning) eller krydser en nodegrænse.

"Passer" er ikke det samme som "kører godt". En model, der optager 95% af VRAM uden plads til KV-cache, præfiks-cache, CUDA-grafer eller aktiveringshukommelse, vil forudgå anmodninger under enhver reel belastning. Arbejdsreglen: vægter ved 60-70% af VRAM, hvilket efterlader 30-40% til alt andet. Med den begrænsning gør 405B ved FP8 det. ikke passer komfortabelt på 8× Pro 6000 til inferens ved enhver nyttig samtidighed — den passer til vægtene, ikke arbejdsbyrden.

Når du IKKE bør skalere ud

Tilfælde hvor det er entydigt korrekt at forblive på én node:

• Inferens for enhver model, der passer. Hvis model plus KV passer til målkonkurrencen, er multi-node TP over Ethernet eller IB strengt taget langsommere end single-node. PCIe Gen5 i en boks leverer ~50 GB/s mellem GPU'er på den samme switch; 200 Gbps IB mellem noder leverer ~25 GB/s. En arbejdsbelastning, der halter på PCIe, kravler på IB.
• Produktionsservice med én lejer. Én model, én klient, moderat samtidighed. En 8-GPU Pro 6000 håndterer nemt 70B med 32-64 samtidige anmodninger. En anden boks er kun nyttig som en hot spare eller fordobling af DP-gennemstrømning – det er heller ikke "skalering" i den tæt koblede forstand.
• Forskningslaboratorier, der kører 7B-72B-modeller. Det meste akademiske og anvendte arbejde i 2026 ligger her — Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma, 70B finjusteringshalen. Ingen behøver mere end én node.
• Finjustering af LoRA/QLoRA. Pointen med PEFT er, at du ikke behøver træningsressourcer til en komplet model. 70B LoRA passer til 4-8 GPU'er i én node; 405B QLoRA passer til 8× Pro 6000.
• Batchinferens og offline-arbejdsbelastninger. Hvis SLA'en er "behandl dette korpus inden fredag", håndterer throughput-mode batching på én 8-GPU-boks det. Multi-node hjælper kun, når du ikke kan afslutte i tide - normalt fordi modellen er for stor, ikke fordi én node er for langsom.

Omkring 80% af Kentino-kunder bør købe én større node i stedet for to mindre, og de fleste af de resterende 20% ønsker faktisk DP-replikaer bag en load balancer, ikke en klynge.

Når du SKAL skalere ud

De tilfælde, hvor én node virkelig ikke er nok, er mere snævre, end folk antager.

Træning af en 70B+ model fra bunden. Otte GPU'er er ikke nok til at klare sig selv. En pretrain på 70B med offentliggjorte token-budgetter (1.5-15T) tager hundredvis af GPU-måneder på H100-klasse hardware, mere på PCIe forbruger-GPU'er. Dette arbejde kræver 32-128+ GPU'er og en SXM-struktur. Kentino bygger ikke dette niveau.

Fuld finjustering på 70B+. Ikke LoRA — fuld finjustering med optimeringstilstande, gradienter og aktiveringer indeholdt. En 70B fuld finjustering (FP16-vægte + FP32 Adam + grad + aktivering) er 1.2-1.5 TB tilstand, ud over én 8-GPU-node, selv med FSDP. Retfærdiggør en IB-klynge med 2-4 noder.

Hosting af 405B+ med produktionslatenstid. Vægtene passer til INT4 på 8× Pro 6000, men KV-cache plus samtidig servering ved brugbar latenstid skubber dig til to eller flere noder. To 8-GPU Pro 6000-bokse i TP=8 × PP=2 eller TP=4 × PP=4 er det realistiske minimum for Llama 3.1 405B ved en anstændig QPS. K03 pakker dette ud.

Multi-tenant produktion på >100k QPS aggregeret. En 8-GPU-node betjener 500-2,000 tok/s aggregat ved 70B FP8. Ud over titusindvis af QPS ønsker man flere replikaer, og derefter ønsker man en rigtig klynge med en router og præfiks-cache-bevidst routing. Det rigtige svar er normalt mange DP-replikaer, ikke én kæmpe TP-klynge.

Uden for disse fire svækkes sagen hurtigt. De fleste "Jeg har brug for multi-node" viser sig at være "Jeg vil have mere gennemløb" - et replikaspørgsmål, ikke et strukturspørgsmål.

Det sweet spot med én node

Geometrien for en stærk single-node build, på hardware som Kentino faktisk leverer:

Den vigtigste begrænsning: NVLink findes ikke på disse kort. RTX 5090, RTX Pro 6000 Blackwell, L40, L4 er PCIe-tilsluttet. NVLink-fabric SXM-moduler (H100 SXM, B200 SXM, GB200) kræver HGX-baseboards, som vi ikke selv bygger. K07 dækker omkostningerne; N03 dækker, når NVLink er vigtig.

PCIe-stien er den rigtige til inferens-først arbejde og det meste træning før frontlinjen. Batching i gennemløbstilstand amortiserer alt og reducerer omkostningerne ved inferens. For finjustering af modeller med fast størrelse er wall-clock-straffen versus SXM 1.2-1.4× – normalt acceptabelt. For tensor-parallel træning på 70B+ fra bunden er straffen 2-3×, og svaret er "køb SXM eller udfør ikke dette arbejde på Kentino-hardware."

Klippen mellem single-node og multi-node

Det, der gør multi-node til en anden systemkategori, er forbindelsesklippen mellem intra-node og inter-node, i båndbredde og latenstid.

Inde i en boks kommunikerer to GPU'er med ~50 GB/s med hop på under mikrosekunder. Cross-node får du ~25 GB/s på 200 Gbps IB - en 2× straf på IB, 4-5× på 100 GbE, 15× på 25 GbE. For TP-kollektiver, der aktiverer alle transformerlag, gør det meget ondt. K07 har den alt-reducerede timingtabel.

Latensen ganges med tiden: internnoden er 5-15 mikrosekunder på tunet RoCE versus nanosekunder inde i en boks. Ved træning og præfill afrunder dette; ved interaktiv inferens med lav latens og tæt TP gør det ikke.

Problemet er, hvorfor "bare tilføj en boks mere" ikke er en løbende beslutning. Alt, der kun lige akkurat overlever på PCIe inde i én node, vil ikke overleve på Ethernet eller IB mellem noder.

Stærk skaleringsmatematik: hvor den falder over

Amdahls lov: Hastighedsforøgelsen er begrænset af den serielle andel af arbejdsbyrden, og for distribueret træning er denne andel kommunikationsoverhead. For et træningstrin i 70B-klassen på Kentino-klassen PCIe-hardware ser skaleringseffektiviteten (gennemstrømning pr. GPU vs. baseline for enkelt GPU) sådan ud på tværs af builds, vi har leveret:

To ting at tage med sig. Først, At opdele et 8-GPU-job i to 4-GPU-noder er værre end at køre det i én boks — alle cross-node fabrics er langsommere end PCIe'en i den boks, du allerede havde. For det andet, Dataparallelisme skalerer meget bedre end tensorparallelisme på tværs af struktur. Hvis dit egentlige spørgsmål er "kan jeg håndtere flere anmodninger" i stedet for "kan jeg køre én større model hurtigere", så fungerer DP-replikaer, og de fungerer over standard 100 GbE.

Hvis den forventede effektivitet falder til under 60 %, er arbejdsbyrden forkert formet til multinode på commodity fabric. Omstrukturer (TP inde i en node, PP eller DP på ​​tværs), køb en større enkelt node, eller køb hardware i SXM-klassen. Brute force virker ikke.

Forskningslaboratoriefælden og den operationelle skat

Et mønster, vi ser ofte nok til at påpege: et laboratorium planlægger for "fremtiden" og bestiller to 4-GPU-noder i stedet for én 8-GPU-node. Hvad de rent faktisk får, er dårligere træning (0.65× cross-node TP vs. 0.73× intra-node), dårligere inferens for enhver model, der passer ind i én boks, dobbelt så stor driftsbyrde (to BMC'er, to NIC-tuninger, to driver-pin-tilstande, to fejldomæner) og omtrent den samme delpris efter den anden NIC, den anden PSU og switch-opgradering. Køb én 8-GPU-node først.

Multinode, når det er det rigtige svar, er ikke gratis. Den ekstra skat:

• Delt opbevaring — lokal NVMe holder op med at være nok. NFS, BeeGFS eller Lustre, plus et lager-VLAN (K04).
• Asynkrone shardede checkpoints — synkrone, ikke-shardede skrivninger til NFS standser klyngen. PyTorch DCP eller NeMo er påkrævet, ikke valgfrit.
• NIC- og NCCL-tuning — RoCE-flowkontrol, PFC, ECN, jumbo-rammer, NCCL-transportvalg, topologifiler, ring- vs. træ-algoritmer. Hver knap vil være forkert ud af boksen.
• Overvågning — DCGM pr. node, Prometheus-føderation, NCCL-sporbuffere.
• Fejlhåndtering — nodeafbrydelser, NIC-nulstillinger, switchportflapper. K06 dækker tilstandene; fejlrater for flere noder er omtrent N gange for en enkelt node, gendannelse er mere rodet.

I ingeniørtid koster det 4-5 gange pr. tilføjet node at have flere noder. Planlæg for det, eller accepter at klyngen bruger sine første seks måneder på halv teoretisk kapacitet.

Det konkrete beslutningsflow

Gennemgå dette i rækkefølge. Det første "ja" afslutter samtalen.

1. Passer modellen til 8× 96 GB ved FP8 med 30-40% VRAM headroom til KV? Hvis ja, én node, færdig.
2. Passer den ved INT4 med samme headroom? Hvis ja, og du udfører inferens (ikke træning), er én node ved INT4 svaret. INT4-vægte er ikke brugbare for træningens gradientsti — fortsæt.
3. Er arbejdsbyrdens gennemløbshastighed bundet snarere end modelstørrelsesgrænse? Hvis ja, er svaret dataparallelle replikaer af konfigurationer med én node, ikke en klynge. To bokse bag en load balancer, ingen nødvendig fabric.
4. Er arbejdsbelastningen tensorparallel træning af en model, der ikke passer i én node? Multinode med InfiniBand. Projektskaleringseffektivitet ved hjælp af K07s tabel. Under 60%, omstrukturer (TP indeni, PP på tværs) eller reducer antallet af noder og accepter langsommere vægtid.
5. Er arbejdsbyrden forudtræning af en 70B+ model fra bunden? Frontier-case. Multinode med NDR IB eller SXM. Kentino kan bygge IB-siden, men de fleste kunder, der stiller spørgsmålet, behøver faktisk ikke selv at udføre dette arbejde.

Trin et og to udgør størstedelen af ​​markedet. Trin tre betyder, at du vokser godt – svaret er replikaer, ikke en klynge. Trin fire og fem er virkelige, men sjældne.

Ærlig vurdering

Multi-node er lige i frontlinjen – 70+ milliarder træning fra bunden, 405+ milliarder inferens ved produktionslatens, hyperscale-servering over 100k QPS, eller forskning, der afhænger af den daglige gennemløbshastighed, som én boks ikke kan levere. Dette er reelle arbejdsbelastninger. De er ikke det meste af det, der bliver bygget.

For alt andet er én veludviklet 8-GPU-node løsningen. Den kører alle åbne inferensopgaver i 2026, der passer til 768 GB ved FP8/INT4, LoRA og QLoRA op til 405B, fuld finjustering af 13B-klassen uden problemer og skalerer til to eller tre DP-replikaer for gennemløb uden cluster-struktur. Og den er betydeligt nemmere at betjene.

Formen på den samtale, vi har med de fleste kunder: beskriv arbejdsbyrden, lav den rigtige matematik, projektskaleringseffektivitet. Hvis projektionen er en klynge, byg en klynge. Hvis det er én node, byg én node. Hvis det er to replikaer bag en router, byg den. Vi sælger ikke den største konfiguration, du vil tolerere - vi sælger den, der rent faktisk vil fungere.

---

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.