Topologie klastrów z przełącznikami: Fat-Tree, Leaf-Spine, Dragonfly+, Tesseract

Każdy schemat klastra w prezentacji dostawcy zaczyna się tak samo: rząd prostokątów z podpisem „węzeł”, rząd prostokątów z podpisem „przełącznik” i strzałki pomiędzy nimi. Schematy są celowo proste, ponieważ prawdziwy wybór, który za tym stoi — która topologia, z jaką oversubskrypcją, z jaką prędkością na port — to największa pojedyncza decyzja kosztowa w klastrze AI zaraz po samych GPU.

Ten artykuł stanowi warstwę topologii pomiędzy N02 (który protokół — InfiniBand, RoCE, zwykły Ethernet) a N06–N08 (jak zachowuje się łącze, gdy topologia jest już okablowana). Omawia cztery rodziny, które mają znaczenie w 2026 roku: fat-tree / Clos / leaf-spine, dragonfly / dragonfly+, tesserakt / hiperkostka oraz rodzinę torus, która przetrwała w dwóch konkretnych niszach HPC. Kończy się szczerą konkluzją: mniej więcej dziewięciu na dziesięciu klientów Kentino nie potrzebuje niczego z tego, a artykuł powstał dla tego dziesiątego.

Odbiorcy: osoby wymiarujące klaster treningowy na 8 do 64 węzłów i sieć wokół niego. To nie jest książka kucharska z konfiguracjami Cisco/NVIDIA — to model myślowy, dzięki któremu taka książka staje się czytelna.

Trzy różne rzeczy, które nazywa się „przepustowością”

Zanim pojawią się prostokąty i strzałki — słownictwo. Trzy terminy używane są w literaturze sprzedażowej klastrów zamiennie, a nie oznaczają tej samej liczby:

32-portowy przełącznik 400 GbE ma 12.8 Tb/s przepustowości sumarycznej. Po podłączeniu do niego 16 węzłów po 400 GbE każdy otrzymuje się 3.2 Tb/s przepustowości bisekcyjnej (8 węzłów × 400 Gb/s po każdej stronie cięcia). Dla kroku allreduce, w którym każdy z 16 GPU wysyła połowę swojego gradientu przez przekrój, to właśnie przez 3.2 Tb/s dzieli się czas kroku — nie przez 12.8.

Skrót myślowy: przepustowość bisekcyjna to jedyna z tych trzech liczb, która przewiduje czas kroku treningowego przy obciążeniu ograniczonym przez allreduce. Gdy broszura dostawcy podaje przepustowość sumaryczną, warto w myślach wziąć najgorsze cięcie i odpowiednio podzielić, aby wrócić do bisekcji.

Dla klastra 16 węzłów po 8 GPU każdy (łącznie 128 GPU) na węzłach z pojedynczą kartą NIC 100 GbE:

Ta sama liczba węzłów, ta sama prędkość łącza, różne liczby w zależności od tego, co się ma na myśli. Tej ramy używa reszta artykułu.

Fat-tree, Clos, leaf-spine — to samo w trzech akcentach

Charles Clos udowodnił w 1953 roku, że wielostopniowa sieć małych przełączników krzyżowych może być nieblokująca — każde wejście może dotrzeć do każdego wyjścia bez rywalizacji — za ułamek kosztu jednego gigantycznego crossbara. Każda nowoczesna sieć centrum danych jest jakimś wariantem tego pomysłu. Nazewnictwo zdążyło się zaplątać:

• Sieć Clos to struktura matematyczna: stopień wejściowy, środkowy i wyjściowy złożone z mniejszych przełączników.
• Fat-tree (Charles Leiserson, 1985) to wariant Closa, w którym magistrale bliżej korzenia stają się stopniowo grubsze, dzięki czemu przepustowość bisekcyjna skaluje się z N.
• Zawinięty Clos (folded Clos) przenosi stopień wyjściowy z powrotem na stopień wejściowy. Leaf-spine to dwuwarstwowy zawinięty Clos. Trójwarstwowy zawinięty Clos z warstwami leaf, spine i super-spine to w praktyce to, co większość ludzi nazywa fat-tree.

Dwuwarstwowy leaf-spine: każdy leaf łączy się z każdym spine. Dowolne dwa węzły komunikują się dokładnie w dwóch przeskokach. Pełna bisekcja = brak oversubskrypcji w warstwie spine.

Każdy leaf łączy się z każdym spine. Ruch każdy-z-każdym to najwyżej leaf → spine → leaf, czyli dwa przeskoki. Przy wystarczającym paśmie spine sieć jest nieblokująca: każdy węzeł może jednocześnie rozmawiać z każdym innym z pełną prędkością łącza.

Współczynnik oversubskrypcji to pokrętło decydujące o koszcie. Jeśli każdy leaf ma 32 downlinki 100 GbE (3.2 Tb/s do racka) i 8 uplinków 100 GbE (800 Gb/s z racka), oversubskrypcja wynosi 4:1 — czterokrotnie więcej pasma do racka niż z niego. Pełna bisekcja oznacza 1:1: tyle samo uplinku co downlinku. 2:1 jest typowe dla centrów danych ogólnego przeznaczenia. 1:1 (pełna bisekcja) to punkt wyjścia dla klastrów AI.

Koszt mniej więcej się podwaja przy przejściu z 4:1 na 1:1, ponieważ kupuje się dwa razy więcej portów spine i dwa razy więcej optyki. Powód, dla którego każdy poważny klaster AI płaci tę premię: oversubskrypcja niszczy przepustowość allreduce. Zsynchronizowany allreduce o 8 przepływach w sieci z oversubskrypcją 4:1 nie działa z jedną czwartą prędkości — załamuje się pod backpressure PFC (N07) i w praktyce potrafi stracić 60–80% teoretycznej przepustowości. Matematyka mówi: „dzielimy przez 4”. Rzeczywistość mówi: „dzielimy przez 5–10”.

Architektura referencyjna NVIDIA DGX SuperPOD zakłada trójwarstwowy fat-tree z pełną bisekcją na InfiniBand Quantum-2 NDR przy 400 Gb/s na port. Opublikowane klastry treningowe RoCE firmy Meta i seria Azure ND Microsoftu budują ten sam kształt na Ethernecie Spectrum-X. Branża zbiegła się na fat-tree z pełną bisekcją dla treningu AI, a ewolucja lat 2024–2026 polega na poszerzaniu fat-tree (400 GbE → 800 GbE na port) lub optymalizacji railowej (następna sekcja), a nie na zmianie fundamentalnej topologii.

Fat-tree zoptymalizowany railowo — dialekt specyficzny dla AI

Standardowy fat-tree traktuje każdą kartę NIC tak samo. Dla treningu AI liczy się to, która karta NIC danego GPU wysyła który gradient, ponieważ wzorce ruchu allreduce nie są jednorodne. Wariant rail-optimized przypisuje każdy GPU w węźle do konkretnego „raila” — dedykowanej ścieżki leaf-spine — i gwarantuje, że i-ty GPU w każdym węźle rozmawia wyłącznie z i-tym GPU w każdym innym węźle przez i-ty rail.

Fat-tree zoptymalizowany railowo: każdy slot GPU mapuje się na dedykowaną, niezależną płaszczyznę spine. Pierścień allreduce na GPU 3 używa tylko Raila 3.

Osiem niezależnych dwuwarstwowych fat-tree, po jednym na slot GPU. Pierścień allreduce na GPU 3 w 16 węzłach używa wyłącznie Raila 3 i nigdy nie przechodzi do innych raili. Zalety: zero kolizji ECMP pomiędzy railami, prostszy routing, niższy radix przełącznika na płaszczyznę. Kompromis: zadanie rozpięte na wiele slotów GPU (tensor-parallel wewnątrz węzła, data-parallel pomiędzy węzłami) i tak zostaje rozdzielone pomiędzy raile przez NCCL, więc topologia pomaga tylko wtedy, gdy obciążenie jest z nią zgodne. Dla data-parallel i NCCL świadomego raili to wyraźna wygrana; dla tensor-parallel rozpiętego na raile oszczędność znika.

Dragonfly i Dragonfly+ — gdy fat-tree jest poza zasięgiem

Koszt fat-tree rośnie mniej więcej jak N log N — każde podwojenie liczby węzłów wymaga większego pasma spine, a trzecia warstwa podwaja liczbę przełączników na punkt końcowy. Dla 1024 węzłów nieblokujący trójwarstwowy fat-tree da się zbudować. Dla 10,000 węzłów liczba przełączników i koszt optyki stają się dotkliwe. Dragonfly, zaproponowany przez Johna Kima, Williama Dally'ego i in. w 2008 roku, powstał właśnie po to, by przekroczyć tę ścianę.

Pomysł: węzły grupuje się w grupy. Wewnątrz grupy wszystkie przełączniki są gęsto połączone (często mniejszym Closem). Pomiędzy grupami każda grupa ma jedno bezpośrednie łącze do każdej innej. Efektem jest sieć o średnicy 3 (przeskok wewnątrz grupy, przeskok międzygrupowy, przeskok wewnątrz grupy), która skaluje się do ogromnych liczb węzłów przy znacznie mniejszej liczbie kabli dalekiego zasięgu niż fat-tree.

Dragonfly: gęsty Clos wewnątrz grupy, jedno łącze globalne na parę grup. Średnica 3. Skaluje się do 1000+ węzłów przy mniejszej liczbie kabli dalekiego zasięgu niż fat-tree.

Największa oszczędność to okablowanie optyczne. Optyka dalekiego zasięgu pomiędzy rackami jest najdroższą częścią fat-tree. Dragonfly zastępuje ją jednym grubym łączem na parę grup, a nie jednym na każdą kombinację leaf-spine. Dla klastra o G grupach po S węzłów fat-tree potrzebuje mniej więcej G × S × log(G × S) kabli; dragonfly potrzebuje G(G − 1)/2 kabli międzygrupowych plus sieć wewnątrz każdej grupy. Przy G = 32 grupach po 32 węzły (1024 łącznie) liczba kabli dalekiego zasięgu spada o mniej więcej rząd wielkości.

Dragonfly+ (Mellanox, 2017) dopracowuje to rozwiązanie dla InfiniBandu. Struktura wewnątrz grupy staje się małym dwudzielnym Closem, więc rozbudowa grupy nie wymaga przekładania okablowania, a łącza międzygrupowe korzystają z routingu adaptacyjnego, by omijać zatłoczone grupy. To topologia systemów Frontier (ORNL, eksaskalowy AMD MI250X) i El Capitan (LLNL, MI300A) — oba okablowane przełącznikami HPE Slingshot-11 w układzie dragonfly, maksymalna średnica trzech przeskoków, 12.8 Tb/s na przełącznik.

Haczykiem jest tryb awarii małych zadań rozpiętych pomiędzy grupami. W fat-tree dwa węzły na przeciwległych krańcach klastra widzą tę samą przepustowość bisekcyjną co dwa węzły oddalone o jeden rack (z dokładnością do liczby przeskoków). W dragonfly dwa węzły w różnych grupach dzielą swoje łącze międzygrupowe z każdym innym przepływem międzygrupowym. Jeśli zadanie treningowe na 16 GPU trafi na 8 węzłów w grupie A i 8 w grupie B, to jedno łącze międzygrupowe jest współdzielone ze wszystkimi innymi, którzy akurat rozpinają się na tej samej parze. Routing adaptacyjny pomaga, ale nie eliminuje rywalizacji o pasmo.

Praktyczny wniosek: dragonfly sprawdza się znakomicie przy skali hiperskalerów (1000+ węzłów, zadania wymiarowane tak, by wypełnić grupy), a znacznie gorzej w średnich klastrach z różnorodnymi małymi zadaniami. To zła topologia dla 16-węzłowego klastra treningowego — w tej skali fat-tree jest tańszy i szybszy. To właściwa topologia dla 1024-węzłowego superkomputera o mieszanym obciążeniu.

Tesserakt — hiperkostka 4D

Tesserakt to hiperkostka 4D: 16 wierzchołków, każdy połączony dokładnie z 4 sąsiadami, średnica 4 (najdłuższa z najkrótszych ścieżek pomiędzy dowolnymi dwoma węzłami). Po uogólnieniu na k wymiarów otrzymuje się k-kostkę: 2^k węzłów, każdy z k bezpośrednimi łączami, średnica k. Routing oparty na odległości Hamminga — XOR adresu źródłowego i docelowego, zmiana jednego bitu naraz — jest trywialnie deterministyczny i równoważy obciążenie przy ruchu losowym.

Tesserakt (hiperkostka 4D): 16 węzłów, każdy z 4 sąsiadami. Linie ciągłe = krawędzie sześcianu 3D; linie przerywane = łącza czwartego wymiaru. Średnica 4. Każda etykieta węzła to 4-bitowy adres; sąsiedzi różnią się dokładnie jednym bitem.

Topologie hiperkostki zdominowały masowo równoległe obliczenia lat 80. Connection Machine CM-2 (Thinking Machines, 1987) to 65,536 węzłów okablowanych jako 12-wymiarowa hiperkostka. Intel iPSC/2 pracował na hiperkostkach 7D. CM-5 (Thinking Machines, 1991) porzucił hiperkostki na rzecz fat-tree, ponieważ to podejście nie skalowało się płynnie powyżej mniej więcej 1024 węzłów — każdy nowy wymiar podwaja liczbę węzłów i wymaga przekablowania wszystkich istniejących.

W 2026 roku termin „tesserakt” wciąż pojawia się w trzech miejscach, które warto rozróżnić:

1. Jako nazwa systemu badawczego HPC DiRAC. DiRAC Tesseract w EPCC (Edynburg) to 1476-węzłowy klaster HPE SGI 8600 na Intel Omni-Path. „Tesseract” jest tu marką; sieć jest bliższa fat-tree.
2. Jako termin badawczy z obszaru „płaszczyzny sterowania SDN” (Tesseract: a 4D control plane, Yan i in.). Bez związku z topologią fizyczną.
3. Jako topologia bazowa kompaktowych klastrów akceleratorów bez przełączników. Klaster 16 węzłów okablowany jako dosłowna hiperkostka 4D ma ciekawe właściwości: każdy węzeł ma dokładnie 4 karty NIC, brak centralnego przełącznika, deterministyczny routing, średnica 4. Temat omawiamy porządnie w N05 (topologie bez przełączników).

Co tesserakt oferuje w 2026 roku: brak podatku od przełączników, deterministyczny routing przez XOR odległości Hamminga oraz małą średnicę (log₂(N)). Co go utrudnia: stałe N (musi być potęgą 2), złożoność okablowania rosnąca z wymiarem, liczba kart NIC na węzeł równa k, a także to, że nowoczesne kolektywy AI (NCCL ring/tree) nie wykorzystują natywnie struktury hiperkostki.

Torus — ocalały w dwóch konkretnych niszach

k-arna n-kostka uogólnia hiperkostkę: zamiast adresu binarnego z jednym łączem na wymiar stosuje się siatkę k na k na k z zawijaniem. W torusie 3D każdy węzeł jest połączony z 6 sąsiadami (±x, ±y, ±z). Torus 6D ma 12 sąsiadów.

IBM Blue Gene/L i /P działały na torusie 3D, skalując się do setek tysięcy węzłów przy zaledwie 6 szybkich łączach na węzeł. Fujitsu Tofu (interkonekt komputera K, 2011) uogólnił to do siatki/torusa 6D — 158,976 węzłów w systemie Fugaku (działa do 2026 roku), ułożonych 24×23×24×2×3×2.

Cerebras Wafer-Scale Engine używa torusa 2D na waflu: każdy element przetwarzający ma 4 sąsiadów, zawijanie, ~1 ns na przeskok. Działa to, ponieważ połączenia na waflu są niemal darmowe; kable poza waflem już nie.

Dlaczego torus przegrał wszędzie indziej: asymetryczne ścieżki i złe zachowanie przy niejednorodnych obciążeniach AI. Nowoczesne obciążenia AI (NCCL ring/tree, hierarchiczne algorytmy NVIDII) zakładają jednorodne pasmo każdy-z-każdym. Torus to narusza. W 2026 roku torus przetrwał w trzech miejscach: interkonekt Cerebras na waflu, Fujitsu Fugaku i jego następcy oraz wnętrze węzłów SXM przez NVSwitch. Poza tymi niszami każdy nowy klaster AI w latach 2025–2026 to Clos.

Tabela porównawcza

Uplink klastra — jak topologia spotyka się ze światem zewnętrznym

Sieć przełączana to wyspa. Musi łączyć się z siecią firmową (rejestry modeli, magazyn zbiorów danych, S3, telemetria), ze stacjami roboczymi programistów (SSH, Jupyter, kopiowanie checkpointów na zewnątrz) oraz z innymi klastrami (przekazanie trening → inferencja). Tym połączeniem jest uplink klastra.

Dwa modele o bardzo różnych konsekwencjach:

Pojedynczy punkt uplinku. Para przełączników spine (albo dedykowany router uplinku) kończy całą łączność zewnętrzną. Łatwo to osłonić firewallem, łatwo ograniczyć pasmo, łatwo monitorować. Tryb awarii: to łącze jest pojedynczym punktem awarii, a jego wysycenie (duże kopiowanie checkpointu na zewnątrz, pobranie 10 GB fragmentu zbioru danych) uderza jednocześnie we wszystkie węzły.

Rozproszony uplink. Każdy leaf ma osobny uplink do sieci kampusowej, często wolniejszy 25 GbE ponad siecią 100 GbE. Pobieranie danych i ruch zewnętrzny zostają lokalnie przy leafie — brak zatorów w sieci wewnętrznej. Tryb awarii: każdy leaf jest granicą bezpieczeństwa, konfiguracji firewalla jest N razy więcej, a monitorowanie staje się trudniejsze.

Dla bazowego przypadku Kentino (klaster treningowy 4–16 węzłów) właściwą odpowiedzią jest pojedynczy punkt uplinku. Sieć wewnętrzna obsługuje wyłącznie RDMA (RoCE albo InfiniBand) i jest nastrojona na niskie opóźnienia oraz pracę bezstratną. Uplink to zwykły Ethernet, TCP i normalne QoS. Nie należy umieszczać magazynu obiektowego ze zbiorami danych w tej samej bezstratnej sieci co allreduce GPU — źle zachowujący się klient S3 nie powinien móc wywołać backpressure PFC na ruchu treningowym. Dwie sieci: płaszczyzna danych (bezstratne RDMA) i płaszczyzna zarządzania/uplinku (stratne TCP). N08 opisuje praktyczną konfigurację.

Szczere stanowisko Kentino

Większość klientów Kentino kupuje od 1 do 4 węzłów. W tej skali:

• 1 węzeł. Brak pytania o topologię. PCIe wewnątrz obudowy (K07), jedna zarządzająca karta NIC 25 GbE na zewnątrz i gotowe.
• 2 węzły. Bezpośredni kabel pomiędzy dwiema kartami RDMA. Bez przełącznika. Nie ma topologii do wyboru.
• 3–4 węzły. Pojedynczy 32-portowy przełącznik 100 GbE obsłuży każdy-z-każdym z pełną bisekcją za $30k–50k łącznie. Nadal nie ma topologii do wyboru.

Rozmowa o topologii zaczyna się przy 8 węzłach, gdy liczba portów jednego przełącznika robi się ciasna, a staje się obowiązkowa przy 16 węzłach. Poniżej tej granicy właściwa odpowiedź brzmi: „jeden dobry przełącznik, pełna bisekcja na każdym porcie i tyle”. Powyżej: „dwuwarstwowy leaf-spine, 100 albo 200 GbE na węzeł, pełna bisekcja (1:1) i żadnego dotykania pokrętła oversubskrypcji, o ile nikt do tego nie zmusi”.

Dragonfly+ to właściwa odpowiedź przy skali hiperskalerów. Tesserakt / hiperkostka jest ciekawą opcją bez przełączników dla kompaktowych klastrów (N05). Torus to wybór związany z jednym dostawcą, dla operatorów HPC z obciążeniami świadomymi topologii. Dla wszystkich pozostałych w przedziale cenowym Kentino domyślnym wyborem jest fat-tree. Pełna bisekcja, jeśli budżet na to pozwala; 2:1, jeśli nie; nigdy 4:1 dla treningu AI.

---

To część Kentino Wiki, serii referencyjnej o obliczeniach AI, robotyce i systemach, które je łączą. Zapraszamy do przesyłania uwag i poprawek na adres info@kentino.com.