Az NVIDIA DSX AI Factory Platform részeként elérhető NVIDIA AI Cluster Runtime (AICR) receptek célja, hogy reprodukálható, ellenőrizhető Kubernetes futtatókörnyezetet biztosítsanak az NVIDIA Dynamo elosztott inferencia-keretrendszeréhez. A receptek rögzített komponensverziókat, környezetfüggő konfigurációkat és validációs ellenőrzéseket tartalmaznak, így a platformcsapatok gyorsabban telepíthetik és ellenőrizhetik a szükséges GPU-drivereket, erőforrás- és ütemezési komponenseket, hálózatot és megfigyelést.
Miért fontos a futtatókörnyezet Dynamo számára
Egy DynamoGraphDeployment leírja, hogyan fusson például vLLM, SGLang vagy NVIDIA TensorRT LLM a klaszter podjain belül, de ez a graf csupán a stack teteje. A termelési inferencia klaszterhez alacsonyabb rétegű futtatókörnyezet szükséges, amely megválaszolja a következőket:
- Telepítve van-e az NVIDIA GPU Operator az adott node-okhoz illeszkedő driver stackkel?
- Fel vannak-e címkézve és felfedezhetők-e a GPU node-ok?
- A klaszter a várható Dynamic Resource Allocation (DRA) drivert használja-e a GPU-k exponálására?
- Az ütemező képes-e GPU munkavállalókat a szükséges topológiai és gang-scheduling követelményekkel elhelyezni?
- Elérhetők-e node health jelek, mielőtt munkaterhelés landolna egy degradált node-on?
- Elérhető-e Prometheus a Dynamo és az accelerator metrikák gyűjtéséhez?
- Ha Kubernetes-native ingress szükséges, a Gateway API / Endpoint Picker (EPP) út konfigurálva van-e?
Az AICR receptek ezeket a futtatókörnyezeti követelményeket rögzítik.
Mit szállít az AICR a Dynamo számára
Egy AICR Dynamo-recept csomagolja magát a dynamo-platform Helm chartot (AICR példában rögzítve: 1.4.2), amely tartalmazza a Dynamo operátort, runtime image-eket és többek között a nvidia.com/v1beta1 DynamoGraphDeployment CustomResourceDefinition-t (v1beta1 a korábbi v1alpha1 helyett).
A recept telepíti a futtatáshoz szükséges komponenseket, többek között:
- NVIDIA GPU Operator (GPU driver stack)
- Node Feature Discovery (GPU felfedezés és címkézés)
- DRA Driver for NVIDIA GPUs (GPU exposal DRA-n keresztül)
- KAI Scheduler (gang scheduling és topológiai placement)
- Grove (multi-komponens serving grafok koordinált indítása és skálázása)
- NVSentinel és Nodewright (node health, ahol a recept támogatja)
- Prometheus stack (cluster, accelerator és Dynamo metrikák)
- agentgateway és Gateway API erőforrások (ha ingress Kubernetes-native)
A recepthez a komponensek verziói, node selectorok, tolerationök, checksummok és validációs elvárások is rögzítve vannak a reprodukálhatóság érdekében.
A Dynamo 1.4-től a komponensek kölcsönös felfedezése Kubernetes erőforrásokon keresztül történik; alapértelmezett út többé nem telepíti a NATS-ot, de az opt-in marad.
KV-cache, disaggregált szolgálás és esemény síkok
Agentikus munkaterhelések hosszú token-prefixeket használnak; ha egy forduló olyan workerhez érkezik, amely nem tartja a prefixet GPU memóriában, akkor a rendszer újraprocesszál intermediate tokeneket a cached eredmények újrahasználata helyett. Dynamo olyan munkavállalóra irányít, amely már tartalmazza a releváns KV blokkokat, akár frontend routeren keresztül, akár Gateway API / GAIE / EPP integrációval.
A Dynamo képes elkülöníteni a prompt feldolgozást (prefill) a token generálástól (decode) — ez a disaggregált serving. KV-cache hiány esetén a prefill pool újraprocesszálja a promptot, majd a decode munkavállalók tokenenként generálnak. Ez lehetővé teszi a prefill és decode kapacitások független skálázását és hangolását.
Dynamo 1.4.2 esetén az AICR alapértelmezett Kubernetes út a request plane-re TCP-t, a KV-cache eseményekre pedig ZMQ-t használ. Például egy vLLM worker így publikálhatja a KV-cache eseményeket:
--enable-prefix-caching --kv-transfer-config
{"enable_kv_cache_events": true, "publisher": "zmq", "endpoint": "tcp://*:5557"}
A worker runtime feliratkozik a helyi vLLM eseményforrásra, normalizálja az eseményeket, és újraközli azokat a Dynamo eseménysíkon; mind a natív Dynamo Frontend, mind a GAIE/EPP út ezen Dynamo-kezelt KV-cache állapot alapján hoz döntéseket.
Mely routing útvonalakat támogatja a Dynamo Kubernetes-en?
A Dynamo két routing útvonalat támogat Kubernetes-en. AICR mindkettőhöz csomagolja és validálja a szükséges runtime-ot.
Útvonal 1: Dynamo Frontend router (alapértelmezett)
Az alapértelmezett konfiguráció egy Dynamo Frontendet exponál Kubernetes Service mögött. DYN_ROUTER_MODE=kv mellett a Frontend tokenizálja a kérést, pontozza a jogosult worker-eket prefix átfedés és aktuális terhelés alapján, kiválaszt egy workert, és a Dynamo request plane-en (alapértelmezett TCP) keresztül továbbítja.
Ez a legkisebb topológia, alkalmas, ha az alkalmazáscsapat egy modell-specifikus végpontot birtokol, vagy ha egy meglévő edge proxy egyszerűen továbbítja a forgalmat a Dynamo Frontend Service felé. Ez a leginkább bizonyított produkciós opció, és nem igényel további gateway/EPP komponenseket.
Útvonal 2: Gateway API Inference Extension (GAIE) és Dynamo EPP
A második út integrálja a Dynamo-t a Gateway API-val és a Gateway API Inference Extension-nel (GAIE). AICR példa konfigurációban az agentgateway egy HTTPRoute-t old fel egy InferencePool-ra. A Dynamo operátor a DynamoGraphDeployment-ből hozza létre az InferencePool-t: selector-ral az alkalmas worker podok azonosítására és endpointPickerRef-tel a Dynamo EPP Service megadására.
A gateway meghívja a Dynamo EPP-t GAIE endpoint-selection interfészén keresztül; az EPP tokenizálja a kérést, a Dynamo KV-routerrel választ endpointot, és a kiválasztást+útválasztási metaadatokat visszaadja a gatewaynek. A gateway ezután a kiválasztott worker Frontend sidecar-jához továbbítja a kérést; a Frontend direct módban fut (--router-mode direct), így alkalmazza az EPP által választott végpontot anélkül, hogy újrarouterezne.
Ez az út alkalmas, ha a platform csapat kezeli a megosztott Kubernetes ingress-t, és a végpont-kiválasztás, timeoutok, retry-k, fallback konfigurációi a Gateway API mechanizmusain keresztül szeretnének megvalósulni. Mindkét routing mód használható HTTPRoute mögött; a különbség az, hogy a szállítást melyik komponens végzi a worker felé: Dynamo Frontend vagy a Gateway.
Kitekintés: Dynamo 1.5-től natív Rust EPP váltja a Go/CGO hidat, közvetlenül implementálva a GAIE Lightweight Endpoint Picker (ext_proc) interfészt, így csökkentve az EPP által per-kérésen felvett overhead-et.
Melyik útvonalat válasszuk?
A döntés alapvetően azon múlik, hogy a Gateway vagy a Dynamo Frontend kezelje-e a request továbbítását a worker felé (timeoutok, retry-k, fallback). Összefoglalva:
- Dynamo Router (Frontend): egyszerűbb, kisebb topológia, modell-specifikus végpontokhoz ideális. Nincs szükség további gateway/EPP infra komponensekre.
- GAIE / EPP: központi, megosztott ingress esetén előnyös, amikor a platform szinten akarják kezelni a worker kiválasztást és a hálózati viselkedést.
Mindkét útvonal élő worker-publikált KV-cache eseményeken alapuló precíz cache-aware elhelyezést használ; AICR alapértelmezés szerint élő eseményeket engedélyez.
Hogyan működik az AICR recept folyamat?
AICR különválasztja a runtime telepítését az alkalmazás telepítésétől. Folyamata röviden:
-
Snapshot a klaszterről: aicr snapshot --namespace aicr-validation --output snapshot.yaml. A snapshot rögzíti a klaszter állapotát, amely alapján a receptet választja és validálja.
-
Dynamo recept generálása: aicr recipe --snapshot snapshot.yaml --intent inference --platform dynamo --output recipe.yaml. A recept rögzíti a komponensverziókat és a környezeti konfigurációt.
Például az AICR v1.0.0 Amazon EKS Dynamo inference recepthez kiválasztott Helm chart verziók egyes elemei:
- NVIDIA GPU Operator v26.7.1
- Node Feature Discovery 0.19.0
- cert-manager v1.20.2
- AWS EBS CSI Driver 2.59.0
- AWS EFA v0.5.29
- NVSentinel v1.25.0
- NodeWright Operator v0.19.0
- NVIDIA DRA GPU Driver 0.5.0
- KAI Scheduler v0.16.9
- Grove v0.1.0-alpha.13
- Dynamo Platform 1.4.2
- Agent Gateway v1.5.0
- Kube Prometheus Stack 84.4.0
-
Runtime bundle renderelése: aicr bundle --recipe recipe.yaml ... --deployer helmfile --output bundle. A parancs Helm értékeket és manifesteket renderel deployment-re kész csomaggá; node selector és toleration flag-ek testre szabhatóak.
-
Runtime telepítése: Helmfile vagy a generált deploy.sh használatával (például helmfile -f bundle/helmfile.yaml apply vagy a bundle-helm/deploy.sh futtatásával). AICR a komponensfüggőségeket ütemezi és többszálúan alkalmazza az azonos szinten levő, független komponenseket.
-
Telepítés utáni validálás: aicr validate --recipe recipe.yaml --node-selector nodeGroup=gpu-worker --toleration ... --phase deployment --phase conformance --output report.json. A validáció telepítési és konformancia ellenőrzéseket futtat a live klaszteren a receptben rögzített elvárásokhoz képest.
Az alkalmazás (DynamoGraphDeployment) csak akkor kerül telepítésre, ha ezek az ellenőrzések sikeresek. A teljesítmény-validáció külön fut, mert ideiglenes serving munkát telepít és GPU-kat foglal le.
Mire terjed ki az AICR validáció?
A validáció a receptben kódolt ellenőrzéseket futtatja, amelyek Dynamo-recept esetén tipikusan lefedik:
- Klaszter alapvonal: elvárt erőforrások, GPU allocatable kapacitás, működő nvidia-smi az accelerator node-okon
- Platform egészség: GPU Operator és Dynamo platform/operátor egészsége és verziója
- Accelerator hozzáférés: DRA támogatás és biztonságos accelerator hozzáférés
- Ütemezés és skálázás: gang scheduling, pod autoscaling, cluster autoscaling és vezérlőrobosztusság
- Megfigyelhetőség: Prometheus backup accelerator és AI service metrikák
- Ingress: Gateway API és agentgateway készültsége Kubernetes-native ingressre
Ezek biztosítják, hogy a telepített runtime megfelel a recept követelményeinek, mielőtt az alkalmazás beindul.
Hol kezdjük el
Az NVIDIA AI Cluster Runtime (AICR) és az NVIDIA Dynamo nyílt forráskódú komponensek az NVIDIA DSX AI Factory Platform részei. Az AICR receptek és telepítési példák elérhetők a NVIDIA DSX AI Factory GitHub-on; közösségi és támogatási csatornák a NVIDIA DSX AI Factory Slack-en és a KubeCon rendezvényeken (például NVIDIA workshop és NVIDIA stand #170) biztosítanak további bemutatókat és gyakorlati tapasztalatot. A rendezvényekhez regisztráció szükséges.
Kapcsolódó parancsok és példák (összefoglaló):
- Snapshot készítése: aicr snapshot --namespace aicr-validation --output snapshot.yaml
- Recept generálása: aicr recipe --snapshot snapshot.yaml --intent inference --platform dynamo --output recipe.yaml
- Bundle létrehozása: aicr bundle --recipe recipe.yaml [placement flags] --deployer helmfile --output bundle
- Telepítés Helmfile-lal: helmfile -f bundle/helmfile.yaml apply
- Validálás: aicr validate --recipe recipe.yaml --phase deployment --phase conformance --output report.json
Az AICR lehetővé teszi, hogy a platformcsapatok reprodukálható, ellenőrzött alapot nyújtsanak a Dynamo alapú inferencia szolgáltatásokhoz Kubernetes környezetben.
