Az üzemelő, „agentic” AI‑rendszerekben a leggyorsabb és legdrágább memóriaszint az HBM (High Bandwidth Memory). Minden bájt, amelyet felesleges súlymásolatok, egy leállt munkamenet KV‑cache‑e vagy újraszámolt prefix foglal le, nem termel tokent. NVIDIA szerint a kérdés ma már nem pusztán az, mennyi memória van egy GPU‑ban, hanem az, hogy mennyi hasznos munkát végez el ez a bájt.
A cég generációs adatai azt mutatják, hogy a GB300‑tól az NVIDIA Vera Rubinig a HBM‑kapacitás nagyjából 288 GB‑on maradt, miközben a sávszélesség 19,2 TB/s‑ig nőtt, és az agentic átviteli hatékonyság megawatt‑onként sokkal gyorsabban skálázódott. A SemiAnalysis AgentX vizsgálatában a Vera Rubin NVL72 akár 30×‑os throughput‑ot ad megawatt‑onként a GB300 NVL72‑höz képest adott interaktivitás (például 160 token/s/felhasználó) mellett. Ezt a 30×‑os javulást a kapacitás önmagában nem magyarázza; a különbség az, hogy mennyi hasznos munkát végez el egy bájt.
NVIDIA ezt együtttervezési (co‑design) problémának tekinti, amely átfogja a GPU architektúrát, a scale‑up összeköttetést, a szerverező szoftvert, a CPU‑t és a tárolást. A következőkben öt olyan mechanizmust ismertetünk, amelyek növelik egy memóriabájt értékét: a súlyokat kódoló bitektől a pod‑szintű megosztott tárolóig.
1. NVFP4: több intelligencia kevesebb bájtban
A legegyszerűbb módja a bájt értékének növelésének, ha kisebbé tesszük az egyes értékeket anélkül, hogy elveszítjük, amit kódolnak. Az NVFP4 ezt 4‑bites E2M1 elemmel és két szintű skálázással (mikroblokk‑szintű FP8/E4M3 skála minden 16 értékre és egy per‑tensor FP32 skála felül) valósítja meg. Az eredmény egy olyan formátum, amely elég kicsi ahhoz, hogy jelentős HBM‑területet szabadítson fel, de elég finomgránulátumú marad a pontosság megtartásához, ahol az egyszerű 4‑bites formátumok alulmaradnának.
Súlyokon alkalmazva az NVFP4 körülbelül 3,5×‑re csökkenti a modell helyigényét FP16‑hoz, és 1,8×‑ra FP8‑hoz képest, így több HBM marad KV‑cache‑re, nagyobb batch‑ekre és magasabb párhuzamosságra. NVFP4 alapértelmezett precízióvá vált nyílt agentic benchmarkoknál (például AA‑AgentPerf, SemiAnalysis AgentX és MLPerf Endpoints). Ezekben és vezető MoE architektúrákban akár 4×‑es throughput‑ot is hoz egy FP8 bázishoz képest azonos interaktivitás mellett.
NVFP4 a KV cache‑re is kiterjeszthető: a KV cache lábnyomát FP8‑hoz viszonyítva akár 50%‑kal csökkenti, így körülbelül kétszer annyi kontextus maradhat eszközön. Kevesebb kiürítés magasabb cache‑hit arányt eredményez, míg a kisebb cache kisebb szélessáv‑igényt jelent dekódolás közben.
2. Wide Expert Parallelism és NVLink: 72 GPU mint egyetlen memória‑pool
A mixture‑of‑experts (MoE) modellek tokenenként csak egy részhalmazt aktiválnak, de az expert‑súlyoknak valahol HBM‑en kell lenniük. Ha az expert‑ek kevés GPU‑ra vannak sűrítve, minden GPU memóriájának nagy része súlyokra megy el, és a dekódolási lépések drága weight‑loading költséggel járnak. Bár a bájtok helyben vannak, nem feltétlenül dolgoznak hatékonyan.
NVIDIA TensorRT‑LLM‑ben a Wide Expert Parallelism (Wide‑EP) úgy változtatja meg az arányt, hogy az experteket nyolc vagy több GPU között osztja meg. Például DeepSeek‑R1 modell EP64 beállításánál egy GPU rétegenként négy expertet tart, ami a teljes modell 14 848 expert blokkja közül 232‑t helyez el lokálisan. Ennek hatásai:
- Kapacitás: több HBM marad KV cache‑re, nagyobb batch‑ekre és több egyidejű munkára.
- Számítási intenzitás: a GroupGEMM kernel több tokenen újrahasznosítja a betöltött súlyokat, növelve FLOP‑ok számát bájtonként.
- Egyensúly: az Expert Parallel Load Balancer (EPLB) a forró és hűvös experteket újraelosztja a forward pass‑ok között, elkerülve, hogy egy GPU memóriája túlterhelt legyen, miközben más GPU‑k üresen állnak.
Ez csak azért működik, mert a scale‑up domain távoli bájtokat közel olyan használhatóvá tesz, mint a lokálisakat. Minden MoE réteg all‑to‑all dispatch és combine forgalmat generál; ennek abszorpciójához nagy sávszélességű NVLink‑re van szükség. GB200 NVL72‑n 130 TB/s összesített NVLink sávszélesség kezeli ezt a forgalmat; nagy EP (EP32) akár 1,8×‑kal több output tokent/s/GPU‑t adhat kis EP‑hez (EP8) képest adott interaktivitásnál.
Vera Rubin NVL72 esetén egy Rubin GPU akár 288 GB HBM4‑et és 3,0 TB/s NVLink 6 sávszélességet hoz, ami egy rack‑szinten nagyjából 20,7 TB HBM4‑nek felel meg. Rubin továbbá bevezeti az inline memory tensor accelerator (TMA) descriptor frissítéseket, így egy megosztott leíró szolgálhatja ki az összes expertet közös elrendezéssel, csökkentve a metadata‑overhead növekedését az expert‑számmal.
Wide‑EP tehát eldönti, hol lakjanak a súlybájtok. A következő kérdés az, hogy a kiszámolt KV cache bájtokat újra kell‑e számolni vagy megtartani.
3. Dynamo: a megosztott KV cache mint flottaszintű erőforrás
A KV cache a korábban feldolgozott tokenekhez tartozó köztes attention eredményeket tárolja, hogy a modellt ne kelljen újraszámolni. Ez az állapot átmeneti és kiüríthető, de csak akkor értékes, ha újra felhasználják. Az agentic munkaterhelésekben rengeteg újrahasznosítási lehetőség van (rendszerpromptok, eszközsémák, közös dokumentumok, többlépéses feladatok előzményei), de ha egy kérés olyan GPU‑ra esik, amely nem tartalmazza a prefixet, vagy az épp ki lett ürítve, újra kell tölteni a prefillt.
NVIDIA Dynamo a terjesztett serving réteg, amely a KV cache‑t flottaszintű erőforrásként kezeli. Három együtttervezett képessége van:
- KV‑aware routing: a Dynamo router nyomon követi, hol vannak a KV blokkok, és a cache‑fedést és a dolgozói terhelést egyaránt figyelembe veszi a kérések elhelyezésekor. Ez a megközelítés átalakítja a lehetséges újraszámolásokat cache‑hitekké.
- Disaggregated serving: prefill és decode külön GPU‑poolokon futnak, így a decode GPU‑k HBM‑et szentelhetnek KV cache‑re és batch‑méretre, nem pedig tartaléknak a bursty prefill számára.
- KV Cache Runner (KVCR): követi, hol található minden blokk a konfigurált GPU, lefoglalt CPU és tároló‑tier‑eken (helyi SSD‑k, hálózati fájlrendszerek). Egy prefix, amely nem HBM‑en van, visszaállítható később, így a hasznos kontextus túlélheti a GPU kiürítését. KVCR a NVIDIA Inference Xfer Library (NIXL)‑t használja a tároló‑átviteli útvonalakhoz, lehetővé téve a cache blokkok mozgatását miközben a GPU más munkát végez. A KVCR‑Guard opció pedig megőrzi a KVCR‑által kezelt host‑memória cache‑t egy motorhiba esetén, amíg a guard szolgáltatás és a host elérhető.
Dynamo KV‑cache offloadja gyors visszanyerést igényel: érdemes egy prefixet HBM‑en kívül megőrizni csak akkor, ha a visszatöltés gyorsabb, mint az újra‑prefill. NIXL ezen offload utat köti össze külső tárolókkal. Külön validációs tesztekben a VAST Data és a WEKA 35 GB/s‑ot mutattak egy H100 GPU felé GPUDirect Storage használatával, illetve egyedi NIXL plugin révén 270 GB/s aggregált olvasási áthidalást nyolc H100 GPU között. Ezek a tesztek azt mutatták, hogy a külső tároló képes KV cache‑t szolgáltatni anélkül, hogy átviteli szűk keresztmetszet lenne. Egy VAST teszt azt is bemutatta, hogy vLLM és LMCache használatával egy DGX H100 rendszeren a tárolt KV cache betöltése az újraszámolás helyett csökkentette az első tokenig tartó időt Qwen3‑32B esetén 130K tokenes prompttal.
Dynamo tehát koordinálja, hova mennek a cached bájtok és mikor térnek vissza. A következő két eszköz a kontextus számára rendelkezésre álló kapacitást növeli, először a CPU memóriával.
4. NVIDIA Vera CPU: az inaktív kontextusok HBM‑pazarlásának csökkentése
Az agentic inferencia nem folyamatos egy lépés: egy munkamenet GPU lépések és CPU‑oldali feladatok (eszköhívások, kódvégrehajtás, lekérdezések, sandbox értékelések) váltakozása. Ezekben a „gátakban” az HBM‑en tartott session KV cache kapacitást foglal anélkül, hogy aktív token‑generálást szolgálna, miközben más kérések versenyeznek ugyanazokért a bájtokért.
A Vera CPU két fronton csökkenti ezt a költséget:
- Rövidebb gaps: 88 Olympus mag gyorsabb egyszálú teljesítményt (1,8×), 40%‑kal alacsonyabb csúcs betöltött latenciát az x86 CPU‑khoz képest és magonként akár 14 GB/s memória sávszélességet nyújt. A gyorsabb, előre kiszámíthatóbb eszköz‑hívások lerövidítik azt az időablakot, amelyben a KV cache kiürítési kockázatnak van kitéve.
- Gyors hely a kontextus számára: egy Vera CPU akár 1,5 TB LPDDR5X‑et kínál, több mint 5×‑e egy Rubin GPU HBM4‑kapacitásának. NVIDIA NVLink‑C2C‑vel koherensen kapcsolódik Rubinhoz 1,8 TB/s‑on, ami megközelítőleg 7×‑e egy x16 PCIe Gen 6 link 256 GB/s‑ának.
Ezek együtt megváltoztatják az inaktív munkamenet gazdaságosságát: a Dynamo KV Block Manager a KV cache‑t Vera memóriába helyezheti az eszköz‑hívás idejére, és visszahozhatja NVLink‑C2C‑n keresztül, amikor az agent folytatja. Így az HBM a tokeneket aktívan generáló munkamenetekre marad, miközben a szünetelő munkamenet elkerüli a dupla prefill költséget.
Vera memóriája a "meleg" tier: olyan kontextus számára méretezett, amely várhatóan visszatér egy adott körön belül. A hosszabb életű, átkötetszinti vagy csomópontok közötti kontextus tárolásához azonban egy még nagyobb rétegre van szükség.
5. CMX: pod‑szintű, megosztott kontextus‑tárhely
Ha minden újrahasznosítható KV‑cache bájtot csak GPU vagy host memóriában tartunk, korlátozott a kapacitás az aktív inferenciához; kidobásuk viszont újraszámoláshoz vezet. Többkörös munkamenetek, hosszú távú feladatok és több‑ügynökös munkafolyamatok nagy mennyiségű, percekkel később vagy más node‑on újra szükséges KV cache‑t generálnak. A hagyományos hierarchia (lokális SSD‑k, vállalati megosztott tároló) nem optimális erre az adat‑jellegre: a helyi SSD‑k egy node‑hoz kötöttek, míg a vállalati tárolók replikációs és metadata‑overheadet viselnek, amelyet az ideiglenes KV cache nem igényel.
NVIDIA CMX context memory storage egy új G3.5 réteget hoz létre: Ethernet‑hez csatlakozó flash, pod‑szinten megosztva és kifejezetten KV cache‑re optimalizálva. A megoldás az NVIDIA STX referencia dizájnon alapul és négy rétegen együtttervezett:
- Storage processing: a NVIDIA BlueField‑4 STX Storage Processor kezeli az NVMe SSD‑ket, futtat tároló szolgáltatásokat és offloadolja az adat‑integritást és titkosítást KV cache számára.
- Hálózat: NVIDIA Spectrum‑X Ethernet alacsony késleltetésű, nagy sávszélességű RDMA hozzáférést biztosít a számítógép node‑ok és a CMX tároló node‑ok között.
- KV‑aware szolgáltatások: NVIDIA DOCA Memos KV‑aware szolgáltatásokat és I/O vezérlést nyújt BlueField‑4‑en, a kontextust elsőrangú erőforrásként kezelve elhelyezésre és megosztásra.
- Serving integráció: Dynamo és NIXL úgy teszik láthatóvá a CMX‑et, mint egy összehangolt kontextus‑réteget a podon belül, előstatizálva a kontextust és a kéréseket oda irányítva, ahol a KV cache már létezik.
A pod‑szintű pooling azt jelenti, hogy egy prefix, amelyet egyszer számítottak ki az egyik node‑on, újrahasznosítható kompatibilis modell példányok között a podon belül, így az ügynökök, amelyek közös dokumentumokat, eszközöket vagy munkamemóriát használnak, elkerülhetik a duplikált prefillt. A CMX csökkenti a KV‑cache duplikációt és a node‑ok között rekedt kapacitást, ezáltal kiterjesztve az effektív GPU memória‑kapacitást inferencia számára. Előreállítva a gyakran használt kontextust GPU vagy host memóriába, a CMX csökkenti az inferencia megakadásait, miközben egy KV cache‑re optimalizált tárolási réteg alacsonyabb energia‑ráfordítással szolgál. NVIDIA szerint ezek a képességek akár 5×‑os tokensebesség‑ és 5×‑os energiahatékonyság‑javulást tesznek lehetővé hosszú kontextusú inferencia esetén tradicionális tárolókkal szemben.
Hogyan egészítik ki egymást a megoldások?
Mind az öt eszköz különféle pazarlásokat szüntet meg: NVFP4 a felesleges biteket, Wide‑EP a redundáns súlymásolatokat, Dynamo az újraszámolást, Vera az inaktív HBM‑tartózkodást eszköz‑hívások alatt, CMX pedig a pod‑szintű megosztást és újrafelhasználást. Mivel ezek egyetlen, együtttervezett memóriarendszerként működnek, az előnyök összeadódnak: egy 4‑bites KV blokk helyet takarít meg HBM‑ben, Vera memóriában és CMX‑en egyaránt.
Ennek eredménye egy olyan AI „gyár”, amely a memóriát már nem csak kapacitás alapján méri, hanem azon tokenek szerint, amelyeket bájtonként képes előállítani. A Vera Rubin NVL72 egy példája ennek a szemléletnek: ugyanazokról a 288 GB/GPU‑ról a GB300‑hoz képest akár 30×‑os throughput‑javulást mutat megawatt‑onként. Az agentic munkaterhelések növekedésével minden bájt számít.
Közreműködők
A munkát lehetővé tették Wei‑ming Chen, Shiyang Chen, Chao Ni, Mengdi Wang és Jeff Pool mérnöki hozzájárulásai.
