Két NVIDIA DGX Stationon üzemeltetett GLM-5.3 kiszolgálása vLLM-mel tensor-paralelizálással

Ez a leírás bemutatja, hogyan futtatható helyben a NVIDIA GLM-5.3 NVFP4 modell vLLM-mel két, ConnectX‑8 RDMA-val összekapcsolt NVIDIA DGX Station (GB300) között úgy, hogy a modell súlyai a GPU-k memóriájában maradnak és tensor-paralelizmus (TP=2) osztja meg a súlyokat és a számítást. A GLM-5.3 egy kvantált, mixture-of-experts (MoE) architektúra, amely 753 milliárd paraméterrel rendelkezik és körülbelül 40 milliárd paramétert aktivál tokenenként. A teljes ellenőrzőpont (checkpoint) hozzávetőleg 464 GB, ami nagyobb, mint egy GB300 HBM3e memóriája (252 GB), ezért két állomás szükséges a modell betöltéséhez.

Miért fontos ez

A legnagyobb modellek már nem férnek el egyetlen GPU-n vagy gépen; a tensor-paralelizmus és a több‑gépes RDMA-alapú kommunikáció lehetővé teszi, hogy egyetlen, OpenAI-kompatibilis API mögött egy „frontier-scale” modellt szolgáljunk ki lokálisan. Ez különösen hasznos bizalmas adatokon végzett inferencia, helyi ügynökprototípusok és költségkontroll esetén.

Elvárások és követelmények

• Két GB300 NVIDIA DGX Station, Linux futtatással, összekapcsolva és validálva a "Connect Two DGX Stations playbook" alapján, beleértve a GPU‑memória RDMA tesztet.
• Ugyanaz a Linux felhasználói fiók SSH és sudo hozzáféréssel mindkét állomáson. A DGX Station szoftvercsomag tartalmazza a Docker-t és az NVIDIA Container Toolkit-et.
• Kimenő hozzáférés a konténerregiszterhez, Hugging Face-hez és csomagforrásokhoz.
• Legalább ~464 GB szabad lemezterület minden állomáson a checkpoint másolatához plusz hely a vLLM konténerhez és ideiglenes fájlokhoz.
• Elfogadott NVIDIA Open Model Agreement és a GLM-5.3 licencfeltételei; SPEED‑Bench használata esetén az NVIDIA Evaluation Dataset License Agreement is érvényes.
• Hugging Face fiók és olvasási token, hozzáféréssel a gated cais/hle adathalmazhoz (a SPEED‑Bench promptok letöltéséhez).

Lépések röviden

1. Két DGX Station előkészítése: hálózati rail és RDMA eszköz azonosítása (például cx8r1 és mlx5_1), majd a ~/glm53.env fájl létrehozása mindkét gépen a környezeti értékekkel (RANK=0/1, HEAD_IP, WORKER_IP, RAIL_IFACE, RAIL_HCA, stb.).
2. A Docker kép letöltése mindkét állomáson és a ~464 GB-os GLM-5.3-NVFP4 checkpoint letöltése Station A-n, majd rsync segítségével átmásolása Station B-re. Mindkét lemezen ugyanaz a checkpoint elhelyezkedés legyen. A tutorial ellenőrzi fájlösszegeket és a model configot (keresés: architectures == ["GlmMoeDsaForCausalLM"], quantization_config.quant_algo == "MIXED_PRECISION").
3. A vLLM szolgáltatás elindítása mindkét állomáson ugyanazzal a futtatási skripttel (~/launch-glm53.sh). Kulcsparaméterek: --nnodes 2, --node-rank (0/1), --tensor-parallel-size 2, --max-model-len 98304 és --gpu-memory-utilization 0.93. A konténer indítása beállít NCCL és RDMA paramétereket, FP8 KV-cache használatát, többszálú MTP (speculative decoding) konfigurációt és prefix cachinget. Station A (RANK=0) szolgálja ki az API-t; Station B csak workerként fut.
4. Ellenőrzés és első lekérdezés: Station A /health végpontja ellenőrizhető curl-lal. A NCCL logokból meg kell erősíteni, hogy GPU Direct RDMA (GDRDMA) aktív, és a memóriaeloszlás körülbelül 218 GiB súlyt mutat GPU-nként (a teljes checkpoint ~464 GB felosztva). Példa chat lekérés a v1/chat/completions végponton bemutatott JSON példával, ami rövid választ és a finish_reason: stop visszatérítést eredményez.
5. Terhelésmérés AIPerf‑fel és SPEED‑Bench coding promptokkal: a bemutatóban az 80 Coding beszélgetést használják a SPEED‑Bench-ből (80 konverzáció, 89 forduló összesen). Az AIPerf futtatás több koncorrenciát mér: C=1, 8, 16, 32; minden szinten melegítés és mérések vannak (10×C mérés, 3×C melegítés). A példakód exportálja a nyers válaszokat és gyűjti a szerver-metrikákat.

Mért eredmények (SPEED‑Bench Coding, prefix caching engedélyezve)

A táblázatban bemutatott számok a publikált mérésből származnak:

• C=1: overall throughput 107.4 tok/s, mean request latency 49.84 s, mean TTFT 479.75 ms, mean inter-token latency 8.78 ms/token
• C=8: overall throughput 386.0 tok/s, mean request latency 114.17 s, mean TTFT 433.79 ms, mean inter-token latency 19.01 ms/token
• C=16: overall throughput 607.8 tok/s (csúcs), mean request latency 136.46 s, mean TTFT 482.90 ms, mean inter-token latency 23.77 ms/token
• C=32: overall throughput 385.0 tok/s, mean request latency 453.54 s, mean TTFT 899.36 ms, mean inter-token latency 77.90 ms/token

Összefoglalva: a csúcsteljesítmény C=16 mellett volt (607.8 tok/s). Nagyobb konkurencia (C=32) mellett a teljes áteresztőképesség visszaesett és a kérések átlagos válaszideje jelentősen megnőtt (453.5 s).

Erőforrás- és működési részletek

• A checkpoint körülbelül 464 GB; mindkét állomáson megtartják a teljes fájlrendszer-másolatot. vLLM betöltéskor a súlyok runtime-ban oszlanak meg a két GB300 GPU között.
• Minden token feldolgozásához mindkét rank részt vesz; egyik GPU sem tartalmazza a teljes modellt önmagában.
• A KV-cache FP8 formátumban csökkenti a cache memóriaigényt, így több kontextust lehet tárolni.
• A szolgáltatás alapértelmezés szerint 0.0.0.0 címen hallgat a --network host beállítással; ez nincs autentikálva — éles környezetben TLS és hozzáférés-szabályozás javasolt.

Hibakeresési tippek

• Ha hiányoznak változók vagy SSH hiba lép fel, futtassa újra: source ~/glm53.env és ellenőrizze az A→B kulcs alapú belépést.
• A SPEED‑Bench előkészítés gated dataset hibát dobhat: jelentkezzen be ugyanazzal a Hugging Face fiókkal és fogadja el a caiS/hle repository hozzáférési feltételeit.
• Startup vagy RDMA ellenőrzés hibája esetén nézze át a docker logokat mindkét csomagban; ellenőrizze a checkpointot és a RoCE GID indexet.
• CUDA out-of-memory esetén csökkentse a --max-model-len paramétert vagy a párhuzamos kérések számát.

Leállítás és erőforrás-felszabadítás

A vLLM konténerek leállítása először Station A-n, majd B‑n:

• docker stop --timeout 60 "$CONTAINER"
• docker rm "$CONTAINER" Ellenőrizze a státuszt docker inspect segítségével és nvidia-smi-vel, hogy nincsenek-e futó vLLM folyamatok. A checkpointok és a benchmark eredmények megmaradnak diszken.

Mit jelent ez a gyakorlatban?

A bemutatott folyamat után egy 753 milliárd paraméteres GLM-5.3 modell fut helyileg, egyetlen OpenAI-kompatibilis végponton keresztül, két DGX Station erőforrásait kihasználva. Így biztonságosan futtatható inferencia érzékeny adatokon, fejleszthetők helyi ügynökök és mérésekkel meghatározható a munkaterheléshez optimális konkurencia.

Mellékletek

• A leírás részletes parancsokat és környezeti beállításokat tartalmaz a ~/glm53.env és ~/launch-glm53.sh fájlokra, a letöltésre, rsync-re, konténerindításra és AIPerf benchmark futtatásra.
• A tutorial tartalmaz egy rövid Mintalekérést (chat completion) és a várt választ példáját, valamint részletes utasításokat a prefix caching beállításainak módosítására és a benchmark reprodukálására.

A leírás célja, hogy működő példát adjon a nagy, MoE-alapú kvantált modell lokális, több‑GPU/ több‑gépes szolgálatba állítására vLLM és RDMA használatával.