A generatív mesterséges intelligencia számítási és memóriaigénye gyakran több, mint amit egyetlen GPU képes kiszolgálni. Az NVIDIA TensorRT multi‑device inference egy olyan lehetőség, amely lehetővé teszi, hogy egy TensorRT hálózat több GPU között fusson: a végrehajtást NCCL‑támogatott elosztott collectives segítségével koordinálja, miközben megőrzi a TensorRT‑szerű inferenciaoptimalizációkat. A TensorRT 11.0 verziójától ez a képesség hivatalosan támogatott.
A jelentés tárgya, az NVIDIA Dynamo‑Triton (korábbi nevén NVIDIA Triton Inference Server) 26.07‑es kiadása engedélyezi a TensorRT backend több‑eszközös inferenciafunkcióját. Egy Triton KIND_MODEL‑példány most több GPU‑t birtokolhat, rank‑enként TensorRT végrehajtási kontextusokat, CUDA streameket és NCCL kommunikátorokat hozhat létre, és egyidejűleg indíthatja a rankeket minden kérésre. Az alkalmazás egyetlen, név szerint megadott modellt hív meg gRPC végponton keresztül, ahelyett, hogy maga koordinálná a GPU‑rankeket.
Ez a megközelítés azoknak az szervezeteknek nyújt közvetlen hasznot, amelyek generatív AI‑t telepítenek: lehetővé teszi GPU‑erőforrások feláldozását rövidebb késleltetésért, megőrzi az alkalmazás interfészét és a workflow‑t, a motort verziózott Triton modellként lehet csomagolni, és a rank/kommunikátor életciklus‑logikája kikerül a kliensből. Késleltetésérzékeny generatív média‑munkafolyamatoknál a gyorsabb eredmény rövidebb várakozási időt és gyorsabb iterációt jelent.
Példa: Cosmos 3 Nano és Ulysses context parallelism
A demonstrációban az NVIDIA Cosmos 3 Nano videógenerálót használják hosszú szekvenciás munkaterhelésként. A Diffusers a promptok, latensek, classifier‑free guidance (CFG), ütemezés, VAE dekódolás és képkocka utófeldolgozás koordinálását végzi; a Dynamo‑Triton szolgálja ki a 36 rétegű denoising transformert, míg a TensorRT multi‑device inference az Ulysses context parallelism‑t használva osztja szét a 44,160 videó token‑t legfeljebb nyolc NVIDIA GPU között.
A disztribútált Ulysses gráf minden TensorRT planba bele van fordítva telepítés előtt. A Dynamo‑Triton TensorRT backend betölti a verziózott plant, létrehozza a multi‑rank végrehajtási állapotot, és egy gRPC modelfelületet tesz elérhetővé; a kliens egyszerűen a transzformeres kérést küldi erre a végpontra, anélkül, hogy részt venne a GPU‑rankek koordinálásában.
A Cosmos 3 Nano példája jól mutatja a határt: a transformer a teljes egy GPU‑s generálási idő 93.4%-át teszi ki, ezért ez a szakasz a legnagyobb hatású a gyorsítás szempontjából. Minden egyes 35 denoising lépéshez egy negatív (unconditional) és egy prompt‑feltételes predikció szükséges a CFG miatt, így a Diffusers proxy lépésenként két soros Triton hívást indít — összesen 70 transformer RPC hívás egy generálás alatt. Minden kérés előkészített tensorokat visz, és noise_patches‑t ad vissza az alkalmazás munkafolyamatának.
Hogyan aktiválja a Dynamo‑Triton a context‑parallel elosztott TensorRT plant?
A disztribútált gráfot minden context‑parallel TensorRT planba lefordítják. A Dynamo‑Triton konfiguráció aktiválja ezt a plant; nem alakít át egy egydobos motort elosztott motorrá. Az egy‑GPU‑s alapvonal egy standard GPU model instance‑t használ GPU 0‑on. A két, négy és nyolc GPU‑s variánsok KIND_MODEL‑t használnak, engedélyezik a TensorRT backend multi‑device útvonalát és azonosítják a résztvevő rankeket.
Példa egy CP8 konfig részletre (részlet a generált CP8 config.pbtxt‑ből):
name: "cosmos3_cp8" backend: "tensorrt" max_batch_size: 0
instance_group [ { kind: KIND_MODEL count: 1 } ] parameters [ { key: "enable_multi_device" value: { string_value: "true" } }, { key: "multi_device_gpus" value: { string_value: "0,1,2,3,4,5,6,7" } } ]
Ulysses és a disztribúció részletei
A bemutatott Cosmos 3 Nano profil 44,160 videó tokennel dolgozik. Context‑parallel méret nyolcnál (CP8) minden rank a videó tokenek 5,520‑as részét dolgozza fel attention‑on kívül; a rövidebb, 2,992 tokenes szövegút replikálva marad. A 36 transformer rétegen belül az Ulysses az attention körüli particionálási tengelyt változtatja úgy, hogy minden rank a teljes videószekvenciát dolgozza fel egy nem átfedő fejrészre vonatkozóan.
A motort PyTorch‑ból exportálják és Torch‑TensorRT‑vel fordítják. Három lokális konverter alakítja le az export‑szervező operációkat a TensorRT publikus distributed‑collective rétegére: reduce‑scatter, all‑to‑all és all‑gather. Egy elfogadott context‑parallel plan két kezdeti reduce‑scattert, 36 transformer rétegenként három all‑to‑all műveletet és egy végső all‑gathert tartalmaz — összesen két reduce‑scatter, 108 all‑to‑all és egy all‑gather topológiát eredményezve.
Végponti generálási késleltetés benchmark
Minden négy variáns ugyanazon egészséges nyolc‑GPU‑s NVIDIA rendszeren futott. Az egy‑GPU‑s (SD) alapvonal egy GPU‑t használt; CP2, CP4 és CP8 rendre két, négy és nyolc ranket használt. Minden futtatás 1280×720 kimenetet, 189 képkockát 24 FPS‑szel és 35 denoising lépést tartalmazott.
Minden eredmény tartalmazott egy bemelegítést, majd öt mért teljes generálást. A mérés magában foglalta a prompt munkát, a 70 Dynamo‑Triton hívást, a CFG és scheduler frissítéseket, a VAE dekódolást és a képkockák utófeldolgozását; a modell betöltés és az mp4 kódolás ki volt zárva a időmérésekből.
A főbb eredmények (átlagok):
- SD (1 GPU): végső end‑to‑end átlag 156.595 s; transformer RPC átlag 146.192 s; RPC a teljes idő 93.4%-a.
- CP2 (2 GPU): E2E 87.999 s (1.78× gyorsulás vs SD); RPC 77.548 s (1.89×).
- CP4 (4 GPU): E2E 53.093 s (2.95×); RPC 42.661 s (3.43×).
- CP8 (8 GPU): E2E 34.183 s (4.58×); RPC 23.993 s (6.09×); RPC részarány 70.2%.
Az adatok szerint az end‑to‑end késleltetés 156.595 másodpercről 34.183 másodpercre csökkent, amikor az egy GPU‑s feldolgozásról nyolc GPU‑ra váltottak; a transformer RPC‑k gyorsulása elérte a 6.09×‑et.
Érdemes megjegyezni, hogy míg egy GPU‑n a transformer RPCk a teljes generálási idő 93.4%-át tették ki, CP8‑nál ez az arány 70.2%‑ra csökkent. Az RPC úton kívüli feldolgozás ideje viszonylag állandó maradt (kb. 10.2–10.5 s), így a prompt, scheduler frissítések, VAE dekódolás és utófeldolgozás a teljes idő nagyobb hányadát képviselik a több‑GPU‑s konfigurációkban.
Vizsgálat és validálás
Minden variáns ugyanazt a seedet és generálási profilt használta. A validáció mintavételezett képkockákat (0, 47, 94, 141, 188), ellenőrizte a formátumot és a temporális változást, és összehasonlította a context‑parallel kimeneteket az egy‑GPU‑s eredménnyel. CP2, CP4 és CP8 mind megfeleltek a konfigurált küszöböknek: mean absolute error (MAE) ≤ 25 és peak signal‑to‑noise ratio (PSNR) ≥ 18 dB.
Konkrét értékek: CP2 MAE 12.759, PSNR 21.111 dB; CP4 hasonlóan jó; CP8 MAE 16.316, PSNR 19.400 dB. A kimenetek nem pixel‑identikusak, de a kontaktlapon azonos, koherens cselekmény látható a clipben (például egy robotkar lemezt tisztít).
Következtetések és következő lépések
A demonstrált megoldás gyakorlati lehetőséget mutat azon termékcsapatok számára, ahol a válaszidő fontosabb, mint az egy kérelemre jutó GPU‑minimalizálás. Egy több percig tartó generálás akár körülbelül 34 másodperc alatt is elkészülhet nyolc GPU használatával, miközben az alkalmazás hagyományos model‑serving interfészt használ.
A csapatoknak mérlegelniük kell az erőforrás‑a‑késleltetés kompromisszumot: ez a benchmark nem mérte a párhuzamos kérések áteresztőképességét, a generált videóra eső költséget vagy az összköltséget (TCO). Ezeket a mutatókat minden szervezetnek a saját SLO‑i és költségvetése alapján kell értékelnie.
A saját környezetben való reprodukáláshoz letölthető az NVIDIA Dynamo‑Triton 26.07 az NGC‑ről, és használhatók a TensorRT, Torch‑TensorRT, Diffusers és Cosmos erőforrások.
További források: Dynamo‑Triton TensorRT backend multi‑device útmutató, TensorRT Multi‑Device dokumentáció és Dynamo‑Triton Model Repository dokumentáció.
