Az AI rendszerek széleskörű elterjedését gyakran gátolja az a kérdés, hogyan lehet az érzékeny adatokat, a szellemi tulajdont és a modell súlyait védeni közben, amikor a modell aktívan inferál. Erre a problémára kínál megoldást az NVIDIA Confidential Computing (CC), amely hardver- és szoftverszinten biztosít titoktartást és integritást az inferencia során.
Mit véd a CC?
A CC célja, hogy az adatokat, a futtató kódot és a modell súlyait védje akkor is, amikor a modellt használják (active inference). A technológia rétegzett védelmet ad: a szilikontól a rendszerösszeköttetéseken át a rendszer-szoftverig terjedő biztonsági mechanizmusokat nyújt.
Hardveres bizalomgyökér és kulcsok
A Blackwell architektúrájú GPU-k — köztük az NVIDIA RTX PRO 6000, az HGX B200 és az HGX B300 — CC-t támogató hardverrel készülnek. A GPU-k gyártáskor befúrt, soha szoftvernek vagy hostnak ki nem szolgáltatott privát aláírókulccsal rendelkeznek, amely a titkosítási és hitelesítési lánc alapja. Az HGX B200 és HGX B300 konfigurációk több GPU-s (akár 8 GPU) biztonságos működést is támogatnak NVIDIA NVLink titkosítással.
Hitelesítés (attestation) a titkos kulcsok kiadás előtt
Minden bizalmi zóna — például a Confidential VM (CVM) — csak akkor kap hozzáférést titkokhoz (például modell-dekódolási kulcsokhoz), ha átment a remote attestation folyamaton. Az NVIDIA Remote Attestation Service (NRAS) egy aláírt bizonyítékcsomagot (a GPU hardver jelentése és a CPU TEE mérései — például AMD SEV‑SNP vagy Intel TDX) ellenőriz egy ismert jó referenciamanifeszt (RIM) alapján. Az attestation kézfogás jellemzően a futtatás indításakor történik meg egyszer, és miután a CVM megerősített, egyszerűsített állapotban van, az egyes inferencia-kérések futási idejét ez nem növeli.
Mi befolyásolhatja az inferencia teljesítményét CC módban?
A CC két fő forrásból okozhat teljesítménykülönbséget a Blackwell GPU-kon:
- Biztonságos feladatküldés késleltetése: titkosítási és kernelindítási overhead miatt a kisebb munkadaraboknál nagyobb arányban érvényesül. Több munka elvégzése egy GPU indításon csökkenti az overhead relatív hatását.
- Host–device (CPU→GPU) sávszélesség csökkenése: ha a munkaterhelés erősen függ a bemenetek átadásától, a CC titkosított átvitelre korlátozott sávszélessége befolyásolhatja a GPU kitöltöttségét.
NVIDIA és a közreműködő projektek több optimalizációt vezettek be az inferencia hatékonyságának megőrzésére CC mellett, például:
- CC‑kompatibilis autotuner időzítés (FlashInfer): a GPU globális időzítő regiszterének használata pontosabb kernelválasztást tesz lehetővé CC módban.
- Aszinkron D2H (device-to-host) másolás munkavállaló: az SGLang áthúzta a per-token visszaolvasást a scheduler kritikus útjából, így visszaáll a compute/copy átfedés, amelyet a CC mód szinkronizáltnak tehet.
- Részleges CUDA-graph támogatás: az SGLang CUDA-graph replay-t használ prefill és vegyes batch-ekre a kernel indítási overhead csökkentésére.
Benchmarkok — mit mértek?
A CC teljesítményhatását több konfiguráción mérték a Qwen 3.5 397B‑A17B modell FP8 pontossággal, HGX B300 (Blackwell Ultra) hardveren. A tesztkörnyezet virtualizált VM GPU passthrough-val futott, és az összehasonlítás alapja a Confidential Computing ki‑ és bekapcsolt állapota volt, minden más változót változatlanul hagyva.
A mért metrikák közé tartoztak:
- Kimeneti throughput per GPU (token/s)
- Median Time To First Token (TTFT) — a kérelem beadásától az első tokenig mért késleltetés (ms)
- Median Time Per Output Token (TPOT) — per-token késleltetés steady-state streamingben (ms)
A tesztelt munkaterhelési paraméterek: input/output hosszok 8192/1024 és 1024/1024; batchméretek 4, 8, 16, 32, 64, 128, 256 párhuzamos kérés.
Eredmények: minimális teljesítményveszteség
A vizsgálat azt mutatta, hogy CC bekapcsolása esetén a throughput és a tokenenkénti késleltetés általában kis mértékben, jellemzően egyjegyű százalékokkal romlott. A táblázat a relatív változást adja meg (Δ% vs OFF) különböző egyidejűségi szinteknél és ISL/OSL beállításoknál (ISL/OSL = 1024/1024 és 8192/1024):
- Párhuzamosság 4–256 között: a Δ% értékek általában -2% és -8% között mozogtak, ritkábban előforduló -1% körüli vagy -3% körüli hatásokkal.
Konkrét példák a mért értékekből (összegzett, relatív hatás):
- Kis és közepes párhuzamossági szinteken a throughput csökkenés jellemzően 2–6% volt.
- A per-token késleltetés (TPOT) is hasonló mértékben romlott, gyakran 1–8% között.
Ez alapján a szerzők szerint a CC által biztosított titoktartás és integritás jelentős biztonsági előnyt ad, miközben a valós produkciós inferencia-munkaterhelések teljesítményét csak minimálisan befolyásolja.
Tesztkörnyezet részletek
- Hardver: HGX B300 (Blackwell Ultra), GPU power limit 1100W
- Host: Intel TDX, Ubuntu 25.10, kernel 6.17.0-20
- Guest: Ubuntu 24.04.4 LTS, kernel 6.8.0-124, 256 vCPU, 2 NUMA node
- NVIDIA driver: 595.71.05, CUDA 13.2
- Szoftver: SGLang docker.io/lmsysorg/sglang:v0.5.12-cu130 (PRs: 28251 SGLang és 3638 FlashInfer)
- NCCL v2.28.9-1, OpenSSL 3.6.0
- Orchestration: Docker + NVIDIA Container Toolkit
A dokumentáció megjegyzi a CPU teljesítmény és vCPU pining helyes beállításának követését a reprodukálható eredmények érdekében.
Következtetés és továbblépés
A CC hardveres védelme lehetővé teszi, hogy vállalati AI-inferenciák bizalmasan fussanak anélkül, hogy jelentős teljesítményveszteséget kellene vállalni. Az elvégzett mérések szerint az általuk tesztelt Qwen 3.5 és SGLang kombináción a CC bekapcsolása során tipikusan kis százalékos overhead jelenik meg, így a szervezetek megfelelhetnek adatvédelmi és szabályozói követelményeknek anélkül, hogy fel kellene áldozniuk a produkciós teljesítményt.
Az érdeklődők további anyagokat és technikai dokumentációt találhatnak az NVIDIA Confidential Computing dokumentációjában, a Blackwell architektúra whitepaperében, valamint az NVIDIA Remote Attestation Service (NRAS) és kapcsolódó eszközök ismertetőiben.
Források és releváns szabályozások említése: NIST SP 800-207 Zero Trust Architecture; HIPAA Security Rule (HHS); GDPR Article 32 — Security of Processing.
