GPUDirect Storage: il collo di bottiglia non si indovina

C’è un modo molto costoso per affrontare un problema di performance: partire dal componente più visibile. Se un carico di lavoro usa una GPU, la tentazione è guardare subito alla GPU. Più memoria, più acceleratori, un driver diverso, un altro parametro da modificare. Peccato che il tempo perso possa trovarsi altrove, nel percorso che i dati devono attraversare prima di arrivare alla memoria dell’acceleratore.

È il motivo per cui trovo interessante gds-diag, presentato da NVIDIA il 30 ottobre 2026. Non perché sia l’ennesimo strumento con una skill per agenti AI, ma perché prova a rendere osservabile una parte dell’infrastruttura che spesso viene trattata come una scatola nera: la relazione fra storage, filesystem, configurazione e GPU.

La tesi è semplice: prima di ottimizzare un sistema bisogna sapere quale percorso stanno seguendo davvero i dati. E, quando entra in gioco un agente, quel percorso deve essere verificato da controlli eseguibili, non ricostruito per intuizione linguistica.

Il problema non è soltanto quanto corre la GPU

GPUDirect Storage (GDS) è una tecnologia NVIDIA pensata per rendere possibile, sulle piattaforme supportate, un trasferimento più diretto fra storage e memoria GPU. Il percorso tradizionale può richiedere un passaggio intermedio nella memoria di sistema, con copie e lavoro aggiuntivo. GDS punta a ridurre quei passaggi attraverso meccanismi DMA e le API cuFile, dove architettura e configurazione lo consentono. È il modello documentato da NVIDIA, non una promessa che ogni lettura diventi automaticamente più veloce.

Il dettaglio importante è proprio quel “dove lo consentono”. Una GPU compatibile non certifica il filesystem; un filesystem apparentemente corretto non garantisce che il mountpoint utilizzato dall’applicazione percorra il data path desiderato. E una libreria che continua a funzionare non dimostra, da sola, che il trasferimento sia avvenuto senza il percorso di compatibilità.

La documentazione NVIDIA descrive infatti un compatibility mode che può usare buffer nella memoria CPU quando il percorso diretto non è disponibile o appropriato. È utile perché permette di continuare a operare in configurazioni meno favorevoli; diventa però un problema se interpretiamo il semplice funzionamento dell’applicazione come prova di una configurazione ottimale.

Non sto dicendo che ogni installazione GDS ricada nel fallback, né che il fallback sia sempre sbagliato. Sto dicendo che, senza osservare il percorso effettivo, non abbiamo ancora una diagnosi. Abbiamo una supposizione.

gds-diag sposta la conversazione dai sintomi alle verifiche

Il progetto, pubblicato nel repository open source NVIDIA MagnumIO, comprende uno script Python a riga di comando e una skill opzionale per coding agent. La parte CLI è pensata per eseguire controlli deterministici e restituire risultati comprensibili, compresi report strutturati in JSON.

Per avviare lo strumento diagnostico serve Linux con Python 3.8 o successivo. È importante non confondere questo prerequisito con quelli di GPUDirect Storage vero e proprio: secondo la guida NVIDIA, GDS richiede una GPU NVIDIA di classe datacenter e CUDA Toolkit 12.2 o successivo, mentre il tool di preflight può essere eseguito anche senza un’installazione GDS già funzionante.

Prima si verifica l’idoneità

I comandi support-matrix e pre-install rispondono a domande che dovrebbero precedere qualsiasi intervento: la combinazione di piattaforma e storage è supportata? Ci sono prerequisiti assenti? La matrice distingue anche una vista generale (--static) da una che incorpora informazioni del sistema in esame (--live). Questo evita di confondere la compatibilità teorica con lo stato reale della macchina.

Poi si verifica l’installazione

Con post-install e config-audit si passa dall’hardware alle condizioni operative. Il secondo controlla file di configurazione e modificatori provenienti dall’ambiente, e può valutare una configurazione candidata prima che venga adottata. È una differenza sostanziale: non serve applicare una modifica per scoprire se contiene un errore evidente.

Infine si guarda dove gira l’applicazione

container-check prende in considerazione ambienti come Docker, containerd, Enroot e Kubernetes; mount-check approfondisce un percorso o un mountpoint specifico. Il comando all /percorso/da/verificare orchestra una sequenza completa di controlli. È qui che la diagnosi smette di essere un elenco generico di requisiti e diventa una verifica legata al contesto del workload.

Per chi lavora su applicazioni containerizzate, questo passaggio conta parecchio. Il processo dentro il container vede un ambiente che non coincide necessariamente con quello dell’host: dispositivi esposti, librerie disponibili, mount e componenti kernel non si possono dedurre dal nome dell’immagine. La documentazione MagnumIO per Docker elenca esplicitamente i dispositivi e le opzioni da considerare. Non è una checklist da copiare senza valutazione di sicurezza; è una dimostrazione di quante condizioni possono influenzare il percorso dei dati.

Un FAIL è più utile di una risposta sicura di sé

L’output di gds-diag distingue FAIL, WARN, INFO e PASS. Un FAIL segnala un blocco, un WARN un possibile impedimento, un INFO aggiunge contesto e i PASS vengono mostrati con --verbose. I risultati includono spiegazioni e possibili mitigazioni. L’opzione --json consente di conservare o elaborare il referto in modo strutturato.

Questa scelta progettuale ha una conseguenza pratica: il referto può essere confrontato fra due esecuzioni, archiviato insieme a una modifica di configurazione o passato a un altro sistema senza chiedere a un modello di reinterpretare ogni volta un log scritto per esseri umani. Il JSON non rende automaticamente corretto il controllo, ma rende esplicito che cosa è stato osservato e come è stato classificato.

Una diagnosi utile non è quella che suona più convincente. È quella che si può ripetere dopo aver cambiato una sola variabile.

Pensiamo a una sequenza di troubleshooting: prima raccolgo il report, poi identifico il vincolo, modifico una configurazione alla volta e ripeto lo stesso controllo. Solo dopo confronto le metriche applicative. Se nel frattempo ho cambiato driver, container, mount e filesystem insieme, magari ottengo un miglioramento, ma ho perso la possibilità di attribuirlo con ragionevole precisione a una causa.

La skill AI ha un ruolo. Non quello di sostituire il controllo

NVIDIA accompagna il CLI con una skill utilizzabile, fra gli altri, da Claude e Codex. L’agente può ricevere una richiesta in linguaggio naturale, scegliere il sottocomando appropriato, leggere il referto e proporre il passo successivo. Questo è un impiego sensato di un modello: gestire intenzione, contesto e sequenza, lasciando al tool specializzato la raccolta dei fatti tecnici.

C’è però una distinzione che non va cancellata. Lo script gds-diag non applica da solo le mitigazioni; l’agente, se dispone dei permessi e se le policy locali lo consentono, può arrivare a proporre o eseguire cambiamenti. Non sono la stessa operazione. Un comando di diagnostica read-only e un agente capace di modificare script di avvio, mount o configurazioni richiedono livelli di autorizzazione diversi.

Per questo un flusso serio dovrebbe separare almeno quattro momenti: osservazione, interpretazione, proposta di modifica e verifica successiva. Se la proposta richiede privilegi o comporta rischio operativo, serve un gate appropriato. Se un controllo fallisce, l’agente deve riportare l’incertezza; non può trasformare un dato mancante in una spiegazione elegante.

È un principio vicino a quello che ho già affrontato parlando di agenti AI e test eseguibili, ma qui il problema è diverso: non dimostrare un bug nel codice, bensì rendere riproducibile una diagnosi di infrastruttura. Il modello è utile proprio quando smette di fingersi lo strumento di misura.

Una procedura che adotterei prima di parlare di ottimizzazione

Se dovessi valutare un deployment GDS, partirei da un inventario: GPU, versione CUDA, stack storage, mount effettivamente usato e ambiente di esecuzione. Poi confronterei support matrix e preflight con i requisiti documentati, senza prendere la presenza del software come garanzia di un data path diretto.

Passerei quindi a post-install, config-audit e ai controlli specifici per container o mountpoint. Salverei il report JSON con data, contesto e versione degli strumenti, annotando i WARN che potrebbero essere rilevanti per il workload. Se emergesse una correzione, la tratterei come un cambiamento operativo: ipotesi dichiarata, approvazione dove necessaria, modifica minima, nuovo controllo.

Solo alla fine metterei sul tavolo le prestazioni: throughput, latenza, utilizzo CPU e comportamento dell’applicazione reale, misurati prima e dopo nelle stesse condizioni. gds-diag è un diagnostico di compatibilità e configurazione, non un benchmark che dimostra automaticamente un incremento di velocità. Confondere i due piani significa tornare esattamente al problema di partenza.

Il punto è progettare sistemi che sappiano spiegare il proprio stato

La novità interessante non è che NVIDIA abbia aggiunto un’interfaccia in linguaggio naturale a uno script. È la combinazione di controlli circoscritti, esiti classificati, report esportabili e orchestrazione separata. Questo pattern non si limita alle GPU: vale per un database che degrada, una coda che accumula ritardi o un servizio che attraversa più livelli di rete. Cambiano i controlli, non il principio.

Un’infrastruttura non diventa osservabile perché le abbiamo collegato un agente AI. Diventa osservabile quando sa produrre evidenze che un agente, un amministratore e un sistema di monitoraggio possono leggere senza inventare ciò che manca. A quel punto anche l’automazione ha qualcosa di concreto su cui ragionare.

Prima di comprare performance, insomma, conviene capire dove stanno passando i byte.