I TEE sono davvero veloci su NVIDIA Blackwell

Traduzione dell’articolo originale in inglese: https://phala.com/posts/blackwell-gpu-cc-serialized-bridge

Blackwell cambia radicalmente il panorama delle prestazioni dell’AI confidenziale. Su NVIDIA B300, l’operazione BF16 matmul eseguita con GPU Confidential Computing raggiunge prestazioni pari a 0,998x rispetto alla modalità non confidenziale. Un CUDA Graph che concatena 96.000 operazioni matmul arriva a 1,0012x. I Tensor Core e la memoria HBM operano ormai a prestazioni praticamente native.

Lo stack di serving perde ancora throughput perché un altro percorso è diventato la risorsa limitante: il bridge tra la confidential VM e la GPU. Nel paper *The Serialized Bridge* abbiamo misurato sistemi basati su B300 e RTX Pro 6000 Blackwell, individuando una regola costante: il trasferimento host/device diventa serializzato, caratterizzato da un elevato costo di inizializzazione ed è, di fatto, sincrono all’interno di un contesto CUDA.

Misurazioni del serving confidenziale su B300.

Il nuovo modello delle prestazioni

Il bridge presenta tre proprietà fondamentali per il serving degli LLM:

• I trasferimenti host/device all’interno dello stesso contesto vengono serializzati. L’utilizzo di un numero maggiore di CUDA stream non aumenta la larghezza di banda del bridge.
• Le copie con non_blocking=True continuano comunque a bloccare il thread della CPU quando è attivo GPU-CC.
• I trasferimenti di piccole dimensioni pagano un costo fisso di inizializzazione, misurato in circa 330 microsecondi per chiamata.

Questa distinzione emerge immediatamente nei microbenchmark. Su B300, BF16 matmul raggiunge 0,998x con CC attivo rispetto a CC disattivato. Un CUDA Graph esteso arriva a 1,0012x. Un benchmark in stile HBM da 1 GiB ottiene 0,912x. Un singolo trasferimento H2D (host-to-device) nello stesso contesto scende a 0,203x, mentre il D2H (device-to-host) arriva a 0,211x.

Rapporti B300 CC-on / CC-off.

La regola operativa è semplice: considerare ogni attraversamento del bridge come una risorsa da pianificare. Occorre raggruppare i trasferimenti, svuotare le code in modo efficiente ed evitare di inserirli nel percorso critico dell’esecuzione.

Perché le policy predefinite del runtime possono diventare controproducenti

I moderni runtime di serving sono stati progettati assumendo la disponibilità di DMA economiche e asincrone. Questa ipotesi non è più valida con GPU-CC. La pianificazione asincrona predefinita di vLLM normalmente sovrappone lo scaricamento degli output con il passo successivo dell’inferenza. Con GPU-CC, però, queste copie concorrenti vengono serializzate sullo stesso canale del bridge: il costo della sovrapposizione rimane, mentre il beneficio scompare.

In un test di dense decode con Qwen3.6–27B-FP8 su B300, con concorrenza pari a 128, il percorso asincrono predefinito con CC attivo ha raggiunto 3550 token/s. Disabilitando la pianificazione asincrona si è saliti a 4104 token/s, recuperando il 57% del divario introdotto da Confidential Computing. Con la policy sincrona, il costo residuo di GPU-CC è risultato pari a circa 1%.

Throughput della pianificazione su B300.

Una patch che introduce un thread dedicato allo scaricamento dei dati migliora ulteriormente la situazione, spostando le operazioni bloccanti fuori dal thread principale del motore di serving. In un test qualificato su B300 ad alta concorrenza è stato raggiunto un throughput di 5518 token/s con concorrenza 512, ovvero entro l’8,3% rispetto al percorso asincrono non confidenziale di riferimento.

L’insegnamento più importante è più generale: un runtime destinato al serving confidenziale deve adottare impostazioni predefinite consapevoli della modalità GPU-CC. Bisogna svuotare i buffer prima di ricaricarli, spostare le attese bloccanti lontano dal thread critico, mantenere il più possibile i dati residenti sulla GPU e considerare ogni trasferimento come una risorsa limitata.

Il costo della modalità confidenziale dipende dai trasferimenti

L’overhead introdotto da GPU-CC dipende dal tipo di carico di lavoro. Il serving online con throughput limitato può mascherarne l’impatto. Il dense decode con dati residenti in memoria paga un costo moderato. Il routing dei modelli MoE e il ripristino della cache KV risultano più penalizzati perché generano un traffico maggiore attraverso il bridge.

Nei risultati del paper relativi a B300:

• Il serving online di GPT-OSS-120B, con profilo MLPerf e qps=1,19, perde solo l’1,1%.
• Qwen3.6–27B-FP8 in modalità dense perde il 13,0%.
• Gemma-4–31B-it in modalità dense, con concorrenza 128, perde il 14,2%.
• Il decode dei modelli MoE perde tra il 24,7% e il 27,6%.
• Il ripristino della cache KV aumenta il warm TTFT da 405,4 ms a 935,2 ms, con una penalizzazione del 131%.

Overhead della modalità confidenziale su B300 in funzione del carico.

Questo è il modo corretto di valutare la capacità di inferenza confidenziale: chiedersi quali dati attraversano il bridge, con quale frequenza e se il runtime pianifica tali trasferimenti in modo esplicito.

Anche il cold start è un problema del bridge

Lo stesso modello spiega i tempi di caricamento dei modelli. Caricare GPT-OSS-120B su una GPU confidenziale utilizzando il percorso predefinito di safetensors ha richiesto 287,09 secondi su B300. Questo valore è rimasto quasi invariato anche sulla RTX Pro 6000, indicando che il collo di bottiglia è nel percorso software: parsing serializzato, staging e trasferimento sicuro in un unico contesto CUDA.

Un loader progettato specificamente per GPU-CC modifica il modello di trasferimento. Distribuisce gli shard dei pesi su un pool di contesti CUDA, riutilizza i cicli di vita sicuri, preriscalda il pool ed esegue lo smantellamento in modo asincrono. Su B300 il tempo di caricamento scende da 287,09 secondi a 8,36 secondi.

Tempo di caricamento di GPT-OSS-120B su B300.

Il cold start è una caratteristica fondamentale del prodotto. Con 287 secondi, la capacità del sistema è difficile da trattare come elastica. Con 8,4 secondi, il serving confidenziale diventa molto più semplice da pianificare, ripristinare e scalare.

Anche lo stato della cache KV segue la stessa regola. In presenza di elevato churn, il ripristino di un prefisso da 1,1 GiB aumenta il warm TTFT su B300 del 131%. Una pianificazione sincrona riporta il valore quasi in parità. Sulla RTX Pro 6000, una strategia di offload consapevole del riutilizzo riduce il volume di spill da 2,3 GiB a 2,3 MB, migliorando di 2,97 volte il warm TTFT con GPU-CC attivo.

Blackwell ridefinisce anche il confine del tenant

L’HGX B300 introduce un secondo cambiamento importante: il tenant confidenziale può coincidere con una partizione del fabric NVSwitch. Il paper qualifica tenant confidenziali multi-GPU su B300, dimostrando una larghezza di banda peer-to-peer CUDA pari a 510,4 GB/s all’interno di una CVM confidenziale composta da due GPU.

Sono state inoltre validate topologie con tenant confidenziali a quattro GPU e partizioni isolate eseguite in parallelo. Il principale confine di fiducia rimasto riguarda il piano di controllo del fabric: l’identità del Fabric Manager e lo stato esatto del routing NVSwitch richiedono prove verificabili dal tenant più solide.

Evidenze del fabric confidenziale su B300.

Per una piattaforma di AI confidenziale, il fabric diventa sia un elemento di pianificazione sia un elemento di fiducia. Il piano di controllo deve esporre lo stato di GPU-CC, lo stato di salute del fabric, l’identità della partizione e, in prospettiva, informazioni attestabili sul routing del fabric.

Cosa significa tutto questo per l’AI confidenziale

La piattaforma di AI confidenziale di Phala opera già esattamente al livello in cui queste decisioni diventano determinanti: impostazioni predefinite del runtime, caricamento dei modelli, politiche per la cache KV, pianificazione dei tenant, attestazione e orchestrazione delle CVM tramite dstack.

Il paper fornisce cinque regole pratiche per il serving confidenziale in produzione:

1. Considerare gli attraversamenti del bridge come risorse da pianificare.
2. Ottenere la concorrenza dei trasferimenti host/device tramite pool di contesti CUDA.
3. Rendere le impostazioni predefinite del runtime consapevoli della modalità GPU-CC.
4. Massimizzare la permanenza in GPU dei pesi del modello e dello stato della cache KV.
5. Pianificare e attestare il fabric come parte integrante del confine di sicurezza del tenant.

Blackwell rende l’inferenza confidenziale molto più veloce, ma allo stesso tempo rende ancora più costose le vecchie assunzioni su cui sono stati progettati i runtime. La prossima generazione di piattaforme di AI confidenziale sarà valutata in base alla capacità di rispettare i vincoli imposti dal Serialized Bridge e di dimostrare con chiarezza l’affidabilità del fabric che viene allocato.

Leggi il paper: The Serialized Bridge: Understanding and Recovering LLM Serving Performance under Blackwell GPU Confidential Computing.