AI-felhő- és on‑premise rendszerekben a GPU-használat hatékonysága erőforrás‑ és hálózati topológiafüggő. Ha a munkaterhelések elhelyezése rosszul történik, a szorosan összekapcsolt GPU‑csoportok széttöredeznek, a forgalom megosztott kapcsolatokra és kapcsolókra kerül, ami csökkenti az áteresztőképességet, növeli a költségeket, és hosszabb várakozási időket eredményez, miközben a GPU-k továbbra is el vannak látva tápegységgel anélkül, hogy előre haladna a munka.
A GPU‑k folyamatosan adatot cserélnek tréning és inferencia közben, ezért a kommunikációs lokalitás — azaz, hogy mely GPU‑k vannak közeli topológiai tartományban — jelentős teljesítményelőnyt adhat. NVIDIA NVLink és NVLink Switch magas sávszélességű, minden‑minden kommunikációt támogató scale‑up összeköttetést biztosít rack‑szinten, míg az NVIDIA Spectrum‑X Ethernet kiszámítható, alacsony késleltetésű scale‑out hálózatot ad rendszerek és rackek között.
Egy ütemező csak akkor tud jó helyezési döntéseket hozni, ha pontos, naprakész képe van a GPU‑k és a hálózati fabric kapcsolatairól. A gyakorlatban a topológia naprakészen tartása az a pont, ahol a helyezés gyakran megbukik.
Mit csinál a Topograph?
NVIDIA Topograph egy nyílt forráskódú eszközkészlet, amely feltérképezi a fürt hardver‑topológiáját, normalizálja azt egy közös modellbe, és az egyes munkamenedzserek által várt formátumban publikálja az eredményt — például Kubernetes node labelként, Slurm topology konfigurációként vagy Slinky ConfigMapként. A Topograph képes felderíteni a topológiát felhő API‑kon keresztül vagy on‑premises fabric rendszerekből, majd a canonical modell alapján különböző engine‑eken keresztül írja ki a kimenetet.
A Topograph a NVIDIA DSX OS klaszter‑orchestration rétegében együttműködik a Dynamic Resource Allocation (DRA) és a KAI Scheduler komponensekkel, lehetővé téve topológia‑tudatos gang schedulinget az AI‑factory infrastruktúrákon.
Miben segít a topológia‑tudatosság?
A hardver kapcsán érdemes az adatforgalmat egy úthálózathoz hasonlítani: ugyanabban a lokalitási domainben lévő GPU‑knak rövidebb, nagyabb sávszélességű útvonalai vannak egymás felé; a domainek közti forgalom több megosztott linket és kapcsolót terhel. Rossz elhelyezés esetén nőhet a versenyhelyzet és a késleltetés. Ennek elkerülésére a Topograph segít azonosítani a közeli erőforrásokat, amiket az ütemező előnyben részesíthet.
Konkrét sávszélesség‑adatok a forrás szerint: modern NVIDIA Quantum InfiniBand portok akár 800 Gb/s‑ot érhetnek el; az NVLink ötödik generációja (Blackwell‑típusok, pl. GB200/GB300) GPU‑nként 1.8 TB/s bidirekcionális sávszélességet, a hatodik generáció (Vera Rubin) pedig GPU‑nként 3.6 TB/s‑ot ad, dedikált NVLink Switch fabric segítségével. Az ilyen non‑blocking, all‑to‑all felépítés lehetővé teszi, hogy minden GPU „saját sávot” kapjon rendkívül magas terhelés alatt is.
Hogyan működik a Topograph architektúrája?
Topograph két alapfogalom köré épül: provider és engine. A provider szerepe a topológia felfedezése felhő API‑kból vagy helyi fabric eszközökből és annak normalizálása egy közös, canonical modellbe. Az engine pedig ezt a modellt átalakítja a cél környezetnek megfelelő formátumba (Kubernetes node label, Slurm topology fájlok, Slinky ConfigMap, NFD erőforrások vagy instance‑orientált JSON).
A Topograph jelenleg több felhő‑ és hosztolt szolgáltatóval rendelkezik működő integrációval: Google Cloud, Lambda, Nebius, Nscale és Oracle Cloud Infrastructure (OCI); további felhő és kolokációs szolgáltatók fejlesztés alatt állnak. On‑premises használatnál az InfiniBand provider ibnetdiscover segítségével, vagy NetQ a Spectrum‑X és MNNVL (Multi‑Node NVLink) tartományokhoz használható. A provider interfész nyitott, így operátorok saját provider hozzáadásával járulhatnak hozzá az upstream projekthez.
A Topograph öt fő komponens tartja naprakészen a topológiai képet:
- API Server: kérések validálása, duplikátumok összegzése és discovery feladathoz történő továbbítás
- Node Observer: figyeli a konfigurált Kubernetes node vagy Pod változásokat és az API állapotát, majd regenerációt kezdeményez újrapróbálkozásokkal
- Node Data Broker: összegyűjti a node‑onkénti attribútumokat és node annotációként tárolja azokat
- Provider: a felhő vagy fabric adatokat konvertálja canonical reprezentációra
- Engine: kiírja azt a formát, amire az ütemezőnek szüksége van
API és műveletek
A Topograph API szerver az alábbi végpontokat kínálja:
- POST /v1/generate — aszinkron generálási kérelem, visszaad egy kérésszámot (HTTP 202)
- GET /v1/topology?uid=<request-id> — feldolgozás alatt 202‑t, kész eredmény esetén 200‑at ad vissza
- POST /v1/lookup — lekéri a gyorsítótárazott állapotot vagy eredményt ugyanazon kéréshez anélkül, hogy új generálást indítana
- GET /healthz — liveness ellenőrzés
- GET /metrics — Prometheus metrikák
A Topograph egy tipikus aggregációs késleltetést használ (például 15 másodperc), hogy az ismétlődő, azonos kéréseket összevonja és a klaszter események során elkerülje a redundáns munkát. Teszteléshez hardver nélküli környezetekhez szimulációs modellek, illetve a kwok‑nodes és Kind/KWOK segédletek alakítják virtuális Kubernetes node‑okká a modelleket.
Kubernetes integráció (engine: k8s)
A beépített Kubernetes scheduler nem ismeri a fizikai interconnect hierarchy‑t; a Topograph ezt a hiányt pótolja azzal, hogy provider‑jelentett topológiát node labelként publikál. Ezeket a label‑eket a standard affinity‑k és topology‑aware scheduler‑ek (vagy KAI Scheduler, Kueue TAS) fel tudják használni.
Előfeltételek: Kubernetes 1.27 vagy újabb, Helm 3.10+ vagy 4.x, megfelelő kubectl jogosultságok és egy támogatott provider. A Topograph Helm chart telepítése például így történik:
helm repo add topograph https://dsx-ai-factory.github.io/topograph helm repo update helm install topograph topograph/topograph --namespace topograph --create-namespace --set engine.name=k8s --set provider.name=<provider>
A Topograph a node‑okon a következő kulcsokkal írja a lokalitás és gyorsító‑domain információt:
- fabric.topograph.run/tier-0 … tier-1 … tier-N (a legközelebbi levélkapcsolótól kifelé növekvő szintek)
- accelerator.topograph.run/domain
- accelerator.topograph.run/sub-domain (opcionális)
A label‑ek megjeleníthetők: kubectl get nodes --show-labels | grep -E 'fabric.topograph.run|accelerator.topograph.run'
A Topograph API alapértelmezett ClusterIP címe a telepítés alapján topograph.topograph.svc.cluster.local:49021; lokális hibakereséshez port‑forward is használható.
A node label‑ek használhatók a Kubernetes affinity konfigurációkban topologyKey‑ként. Például preferált podAffinity beállítással a scheduler a tier‑0 domaineket részesíti előnyben, míg tier‑1‑et helyettesítőként kezeli. Az alapértelmezett scheduler egyesével helyezi el a Podokat, így ez preferencia, nem feltétlenül globálisan optimális gang‑elhelyezés. KAI Scheduler és Kueue képesek ugyanazokat a label‑eket gang schedulinghez használni.
KAI Scheduler segítségével hierarchikus Topology erőforrást lehet definiálni, és egy Job annotációival megadni, hogy a gang‑ot mely szinteken kell tartani (például required: tier‑1, preferred: tier‑0).
A Topograph NFD engine (engine: nfd) esetén NodeFeature és NodeFeatureGroup objektumokat publikál; az NFD master felel a csoportok státuszának kezeléséért. Az NFD használatához engedélyezni kell az alpha NodeFeatureGroupAPI feature gate‑et.
Slurm támogatás (engine: slurm)
A Topograph Slurm számára több formátumban képes kimenetet generálni: cluster‑wide tree és block formátumokban, illetve Slurm 25.05 óta per‑partition YAML konfigurációt is képes előállítani. A Slurm‑es telepítésnél a Topograph rendszerint Linux bare‑metal vagy VM környezetre kerül, csomagként (Debian/RPM) telepítve. A konfigurációs fájl alapértelmezett elérési portja 49021, és a service systemd‑vel indítható.
A Slurm konfigurációt a /v1/generate végponton keresztül lehet újrageneráltatni; a Topograph képes fájlba írni a topology.conf vagy topology.yaml állományokat és opcionálisan scontrol reconfigure‑t futtatni.
A Topograph szkriptek segítségével node‑state alapú frissítéseket is lehet regisztrálni (például node up/down eseményekre), bár ez nem biztosít észlelést minden switch‑átkötésre.
Slinky támogatás (engine: slinky)
A Slinky (SchedMD fejlesztése; SchedMD‑et NVIDIA megvásárolta 2025. decemberében) Slurm‑ot futtat Kubernetesen. A Topograph Slinky engine a Kubernetes node‑okat slurmd Pod‑okhoz rendezi és Slurm topológiai adatokat ír egy ConfigMapbe. A Slinky engine támogatja a cluster‑wide tree és block kimeneteket, valamint per‑partition YAML konfigurációkat. MNNVL és DRA blokktopológiákhoz speciális dra provider is elérhető, amely a meglévő nvidia.com/gpu.clique label‑eket használja.
A Topograph regenerálja és frissíti a ConfigMapet, amikor a kijelölt slurmd Podok változnak; opcionális useDynamicNodes mód annotál kiválasztott Kubernetes nodeokat a jelenlegi Slurm topológiai specifikációval.
Összefoglalás — mikor érdemes használni?
Nagy skálán a helytelen elhelyezési döntések hálózati torlódást és teljesítményromlást okoznak. A Topograph automatikusan fenntart egy szolgáltató‑jelentett, aktuális topológiai térképet, amely föderáltan és konzisztensen használható felhős és on‑premises környezetekben, így csökkentve a kézi karbantartás szükségességét.
A megoldás KAI Scheduleren, Kueue‑n és natív Kubernetes scheduling mechanizmusokon keresztül újrahasznosítja a topológiai információt, ami javíthatja az AI‑gyártósorok hatékonyságát, a tokenenkénti watt‑arányt és a költségeket. A Topograph forráskódja és helm chartjai elérhetők a dsx‑ai‑factory/topograph GitHub tárházban, és további információk találhatók a DSX OS ökoszisztémáról.
