GPU-platformok ellenőrzése futásidejű AI-leltárral az NVIDIA DSX AI Factory segítségével

Az NVIDIA AI Cluster Runtime (AICR), amely az NVIDIA DSX AI Factory Platform nyílt forráskódú, moduláris komponense, most tartalmaz egy kvalifikált AI bill of materials (AIBOM) komponenst, hogy áthidalja a platform-recept alapján létrehozott konfiguráció és a futó munkaterhelések közötti láthatósági hiányt. A megoldás a Google által fejlesztett k8s-aibom projektet használja, amely Kubernetes-en figyeli az AI munkaterheléseket és CycloneDX 1.6 formátumban állít elő AIBOM-okat.

Miért volt szükség erre

Platform csapatok AICR-rel ismert, verziózottra rögzített GPU platformrecepteket hoznak létre; ugyanakkor az alkalmazáscsapatok a recepttől függetlenül definiálják és frissítik a munkaterheléseket. Így egy reproducible deployment bundle önmagában nem bizonyítja, hogy melyik csomagok futnak az egyes node-okon. A mutable image tagek, például :latest, tovább bonyolítják a helyzetet: az azonos címkék alatt két node különböző kódot futhattat, és egy később lehúzott image olyan verziót is hozhat, amelyet korábban nem vizsgáltak biztonsági szempontból.

Mit csinálnak az AICR és a k8s-aibom együtt

• AICR: ismert-jó GPU platform konfigurációkat alakít át verzióra zárt receptekké és reproducible deployment bundle-ökbe. Minden recept egy hardver, felhő, operációs rendszer és cél kombinációhoz rögzíti a komponenseket, verziókat, értékeket, korlátozásokat, telepítési sorrendet és validációs elvárásokat. A bundle-ek ellenőrzőösszeggel rendelkeznek; aláírás opcionális az aicr bundle --attest parancson keresztül.
• k8s-aibom: a Kubernetes workload és pod API-kat figyeli, és minden felismert AI munkaterheléshez előállít egy AIBOM-ot. Csak támogatott munkatípusok kerülnek leltárba (például native Dynamo grafok, NIMService, LeaderWorkerSet, DisaggregatedSet, CronJob), és a kapcsolódó child workload-okat a tulajdonos AIBOM-jába egyesíti.

E két megközelítés kiegészíti egymást: az AICR ellenőrzött, reprodukálható infrastruktúra-intentet ad, míg a k8s-aibom a futó munkaterhelések felfedezését és bizonyíték-alapú leírását biztosítja. Együtt segítenek megtalálni az "árnyékmunkaterheléseket", azonosítani modelleket, inference runtime-okat, ügynököket, RAG-komponenseket, valamint külső AI API-kat és vektoradatbázisokat, továbbá érzékelik a függőségek elmozdulását.

Kölcsönös hatókör és korlátok

AICR és k8s-aibom eltérő rétegeket fednek le:

• AICR a futtatókörnyezet (driver-ek, operátorok, kernel-ek, Kubernetes komponensek, telepítési konfiguráció) oldala.
• k8s-aibom magasabb szinten, később a klaszter életciklusában figyel: ami ténylegesen deklarálva és fut a klaszterben.

Fontos, hogy egyik nézet sem elegendő önmagában a teljes AI kormányzáshoz; a felelősség határa a két nézet között ma még gyakran hiányzik.

Példa használat — követelmények és verziók

A cikkben szereplő példák AICR v1.2.0-ra és a katalógra épülnek, amely k8s-aibom 1.6.2-t pin-el. A reprodukálhatóság érdekében a CLI build-nek meg kell egyeznie a katalóggal. Követelményként egy Google Kubernetes Engine (GKE) klaszter szükséges, Kubernetes 1.32 vagy újabb verzióval, NVIDIA H100 GPU node-okkal, Container-Optimized OS-sel (COS) és GKE által menedzselt driver-ekkel és device pluginokkal.

Recept legenerálása

Példa parancs a recept létrehozására:

aicr recipe \
  --service gke \
  --accelerator h100 \
  --os cos \
  --intent inference \
  --output recipe.yaml

A k8s-aibom komponens a recept részeként kerül kiválasztásra; lekérdezhető érték például:

aicr query \
  --service gke --accelerator h100 --os cos --intent inference \
  --selector components.k8s-aibom.version
# 1.6.2

Bundle készítése és telepítés

Bundle készítése a Helm deployerrel (node selector címkéket igazítsa a saját rendszeréhez):

aicr bundle \
  --recipe recipe.yaml \
  --system-node-selector nodeGroup=system-pool \
  --accelerated-node-selector nodeGroup=gpu-worker \
  --output ./bundles

Telepítés ellenőrzés és futtatás:

(cd ./bundles && aicr verify . && chmod +x deploy.sh && ./deploy.sh)

A k8s-aibom controller a k8s-aibom-system namespace-ben fut; a fő chart CRD-it használja. Ellenőrizze a telepített CRD storage verzióját:

kubectl get crd aiboms.aibom.k8saibom.dev \
  -o jsonpath='{.spec.versions[?(@.storage==true)].name}'
# v1beta1

Validáció

A telepítési és konformancia fázisok ellenőrzésére:

aicr snapshot --output snapshot.yaml
aicr validate --recipe recipe.yaml --snapshot snapshot.yaml \
  --phase deployment --phase conformance

A k8s-aibom egészségellenőrzését a deployment fázis részeként futtatja az AICR; ez a controller elérhetőségét, az AIBOMControllerConfig Ready=True állapotát és a CRD-k storage verzióját ellenőrzi.

Inventory opt-in és példamunkaterhelés

Namespace-ként felül kell írni az opt-in szabályt:

kubectl create namespace prod-jobs
kubectl label namespace prod-jobs aibom.k8saibom.dev/enabled=true

Egy egyszerű vLLM példa, amely Qwen modellt szolgál ki (példa manifest vllm-qwen.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen
  namespace: prod-jobs
spec:
  replicas: 1
  selector:
    matchLabels: {app: vllm-qwen}
  template:
    metadata:
      labels: {app: vllm-qwen}
    spec:
      tolerations:
        - key: dedicated
          operator: Equal
          value: gpu-workload
          effect: NoSchedule
      nodeSelector:
        cloud.google.com/gke-accelerator: nvidia-h100-mega-80gb
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "Qwen/Qwen2.5-0.5B-Instruct",
                 "--max-model-len", "4096",
                 "--gpu-memory-utilization", "0.30"]
          ports:
            - containerPort: 8000
          resources:
            limits:
              nvidia.com/gpu: "1"
          volumeMounts:
            - {name: shm, mountPath: /dev/shm}
      volumes:
        - name: shm
          emptyDir: {medium: Memory, sizeLimit: 2Gi}

Alkalmazás:

kubectl apply -f vllm-qwen.yaml

Az inventory megtekintése:

kubectl -n prod-jobs get aiboms.aibom.k8saibom.dev

Példa kimenet sor:

NAME WORKLOAD NAME CATEGORY RUNTIME READY AGE apps-deployment-vllm-qwen Deployment vllm-qwen inference vllm True 28m

A controller automatikusan kategorizálta a munkaterhelést és a futtatási környezetet. Fontos megjegyezni, hogy az AIBOM a workload spec-en alapul, tehát megjelenhet még a pod indulása előtt, és Ready=True állapotot jelenthet még akkor is, ha a pod éppen húzza az image-t. Az AIBOM azt mutatja meg, mi lett deklarálva és — ha a Pod elérhető — mit oldott fel, de nem igazolja a sikeres ütemezést vagy végrehajtást.

AIBOM ellenőrzése

A dokumentum inline tárolódhat a resource-on, és SHA-256 digest is szerepel rajta. Például:

kubectl -n prod-jobs get aibom apps-deployment-vllm-qwen -o json > aibom.json
jq -r '.status.bomDocument.inline.data' aibom.json | base64 -d > bom.json
jq -r '.status.bomDocument.sha256' aibom.json
shasum -a 256 bom.json | awk '{print $1}'
jq -r '.components[] | "\(.type)\t\(.name)"' bom.json

A komponenslistában tipikusan ilyesmi szerepel: application vllm, container vllm/vllm-openai, machine-learning-model Qwen/Qwen2.5-0.5B-Instruct. Az attribútumok négy bizalmi szinttel járnak: declared, inferred, unresolved vagy verified, és minden állításhoz megadódik a bizonyíték lokátora.

Erőforrás-használat mérések

A downstream mérések (k8s-aibom v1.6.1 GKE-n NVIDIA Dynamo és AICR konfigurációval) controller overheadként a következőket mutatták:

• Körülbelül négy API-server kérés percenként egy 15 perces stabil állapotablak alatt
• Átlagos controller CPU használat: 2.2 millicore
• Controller memória working set: 28–34 MiB
• Egy AIBOM regenerálás történt, amikor az image tag megváltozott

Jövőbeli fejlesztési irányok és ismert hiányok

Az integráció szándékosan nem valósít meg néhány lehetőséget alapértelmezés szerint; ezek döntési pontok, nem véletlen hiányosságok:

• Aláírt runtime megfigyelések: jelenleg az AIBOM erőforrás maga nincs aláírva; aláírással a megfigyelések sérülésbiztosak lennének.
• Ellenőrzött provenance kapcsolása: k8s-aibom képes Sigstore aláírások ellenőrzésére és Verified bizalmi szint hozzárendelésére, de AICR alapértelmezésben ezt nem engedélyezi. AICR képes bundlet attestálni, de a platform-provenance runtime inventory-hoz való összekapcsolása további munkát igényel.
• Intent vs. observáció összevetés: AICR a telepítési intentet rögzíti; k8s-aibom az observált specifikációt és pod státusz bizonyítékokat. Együttes összevetésükhöz meg kell egyezni az artifact-azonosítókban és frissességi szabályokban; ez további integrációt igényel.

Hol érhetők el a projektek

• NVIDIA AI Cluster Runtime (AICR): NVIDIA/aicr (nyílt forráskódú)
• k8s-aibom: GoogleCloudPlatform/k8s-aibom (nyílt forráskódú)

Ha Kubernetes-en futtat GPU munkaterheléseket, ez az integráció automatikus leltárt ad a felismert AI munkaterhelésekről és bizonyítékot arra, hogyan jutott az egyes attribútumokhoz.