L’AI locale diventa software quando il modello smette di comandare l’architettura

La parte interessante di DIN Deploy non è che NVIDIA abbia pubblicato qualche sample C++ per far girare modelli AI in locale. Di repository dimostrativi ne escono continuamente. La parte interessante è il confine che prova a rendere stabile: il modello si prepara da una parte, l’applicazione lo esegue dall’altra, e in mezzo c’è un contratto abbastanza standard da evitare che ogni modello si porti dietro il proprio piccolo ecosistema runtime.

DIN Deploy, pubblicato da NVIDIA come raccolta open source di esempi C++, parte da checkpoint disponibili su Hugging Face, li esporta in ONNX con strumenti Python e poi li usa da applicazioni native costruite sulle API di ONNX Runtime. L’accelerazione, quando disponibile, passa dal TensorRT RTX Execution Provider. Windows e Linux sono entrambi nel perimetro, con preset CMake anche per x86-64 e Arm64.

Il punto non è togliere Python. È metterlo al posto giusto

Quando si parla di AI locale, la discussione finisce spesso in una falsa alternativa: Python contro C++, prototipo contro software “vero”, framework contro codice nativo. È una contrapposizione abbastanza sterile. Python resta perfettamente sensato per preparare ed esportare il modello; il problema nasce quando le dipendenze della fase di ricerca e conversione diventano, quasi per inerzia, dipendenze dell’applicazione distribuita.

DIN Deploy separa esplicitamente i due momenti. L’exporter Python scarica il checkpoint e produce l’artefatto ONNX. Da quel punto in poi la CLI C++ lavora con sessioni e tensori di ONNX Runtime. Non serve trascinare nell’applicazione il runtime specifico usato per ottenere il modello originale. È una differenza architetturale più importante di quanto sembri, perché sposta il problema da “come integro questo particolare modello?” a “quale contratto di input, output e operatori deve rispettare il mio modello?”.

Un formato portabile non rende automaticamente portabile tutto il sistema. Ma crea finalmente un confine su cui si può progettare, testare e sostituire un componente senza riscrivere il resto.

ONNX Runtime come confine, non come promessa magica

Il vantaggio di usare ONNX Runtime non è soltanto poter caricare un file .onnx. È mantenere l’applicazione agganciata a un’API comune mentre l’esecuzione può essere affidata a provider differenti. La documentazione di ONNX Runtime descrive proprio questo modello: l’applicazione usa la stessa interfaccia e gli Execution Provider si occupano di mappare il grafo sull’hardware disponibile.

Qui però conviene evitare il salto logico che il marketing rende sempre molto invitante. Portabilità dell’API non significa portabilità automatica delle prestazioni, né compatibilità universale di qualunque modello. Operatori supportati, shape dinamiche, memoria, precisione, versione del provider e caratteristiche della GPU continuano a contare. Nel caso di TensorRT RTX, la documentazione corrente indica il supporto per GPU RTX basate su Ampere e successive e raccomanda oggi il provider standalone tramite EP ABI, mentre l’integrazione built-in è deprecata.

Questa distinzione è sana: il codice applicativo può essere più stabile del backend che lo accelera, ma il backend non smette per questo di essere un componente tecnico con requisiti e limiti propri.

I sample sono abbastanza diversi da essere utili

NVIDIA non ha scelto un solo modello giocattolo. I sample coprono riconoscimento vocale offline e streaming con Whisper, Parakeet TDT e Nemotron ASR Streaming, segmentazione interattiva con SAM 2.1 e generazione di immagini con FLUX.2-klein-4B. Questo conta perché costringe l’architettura a confrontarsi con pipeline diverse: audio, immagini, video, generazione e gestione di risorse GPU.

Il sample FLUX.2 mostra anche l’interoperabilità grafica con Vulkan e DirectX e l’uso della quantizzazione post-training. Se l’interfaccia ONNX rimane invariata, il modello quantizzato può sostituire quello precedente senza cambiare il codice applicativo che lo invoca. Non significa che la quantizzazione sia neutra — NVIDIA stessa specifica che dipende dall’hardware — ma è esattamente il tipo di sostituibilità che un buon confine architetturale dovrebbe permettere.

I benchmark vanno letti per quello che sono

NVIDIA pubblica risultati su DGX Spark: per esempio 206,41 volte il real-time per Parakeet TDT su GPU e 38,3 FPS per SAM 2.1 contro 0,5 FPS su CPU. Sono numeri interessanti, ma restano misure del vendor su una macchina specifica. Non sono una previsione delle prestazioni sul PC RTX che avete sotto la scrivania e non sono il motivo principale per cui DIN Deploy merita attenzione.

Il benchmark dice che il percorso accelerato può fare una differenza enorme. Non dice quanto farà la vostra applicazione, con il vostro modello, le vostre shape, la vostra GPU e il vostro preprocessing. Confondere le due cose sarebbe trasformare un sample architetturalmente interessante nell’ennesimo grafico da keynote.

Il vero vantaggio è poter cambiare una decisione senza cambiare tutto

Nel software le astrazioni diventano utili quando rendono reversibili le decisioni costose. Se l’applicazione conosce direttamente il framework del modello, il formato dei tensori del framework, il suo sistema di device e magari anche il suo preprocessing, cambiare modello o backend significa spesso riaprire metà integrazione.

Con una pipeline come quella mostrata da DIN Deploy, il modello può cambiare dietro un contratto ONNX finché quel contratto resta compatibile. Il provider può cambiare dietro ONNX Runtime finché supporta ciò che il grafo richiede. Il codice C++ può concentrarsi sulla parte che appartiene davvero al prodotto: acquisizione dei dati, lifecycle, UI, I/O, gestione degli errori, integrazione con il resto del sistema.

Non è assenza di lock-in. TensorRT RTX resta una tecnologia NVIDIA e l’accelerazione dipende dall’hardware supportato. È però un lock-in collocato in un punto più esplicito: nel provider di esecuzione, non disseminato in tutta l’applicazione. Questa è una differenza progettuale concreta.

Perché interessa soprattutto a chi scrive software, non demo

Una demo AI deve dimostrare che un modello produce un risultato. Un’applicazione deve continuare a produrlo dopo aggiornamenti, installazioni su macchine diverse, cambi di modello, problemi di memoria, input sbagliati e versioni nuove delle dipendenze. Sono due mestieri diversi.

DIN Deploy è interessante perché sposta la conversazione verso il secondo mestiere. CMake, C++, API stabili, separazione fra conversione e runtime, provider sostituibili: non sono parole particolarmente glamour. Sono però esattamente le cose che iniziano a contare quando l’AI locale smette di essere una finestra di notebook e deve entrare in un prodotto.

Per chi lavora già con software nativo, la domanda utile non è quindi “TensorRT RTX è più veloce?”. La domanda è: posso progettare l’inferenza come un componente sostituibile, invece di lasciare che il modello scelto oggi determini l’architettura dell’applicazione di domani? DIN Deploy non risolve ogni caso, ma mette sul tavolo una risposta abbastanza concreta da poter essere compilata, misurata e — cosa rara — contestata con il codice.