Quando un agente AI impiega cinque secondi prima di parlare, il problema non è necessariamente che il modello ‘pensi’ troppo. Può stare spostando grandi quantità di dati tra memoria, acceleratori e rete. d-Matrix vuole ridurre questa attesa collegando la propria prossima generazione Raptor all’infrastruttura NVIDIA con NVLink Fusion, una tecnologia per unire processori diversi ad alta banda e bassa latenza. L’accordo annunciato il 10 settembre prevede una roadmap pluriennale. Raptor dovrebbe entrare nei rack NVIDIA MGX insieme a CPU Vera, switch NVLink, DPU BlueField-4, schede di rete ConnectX-9 e Spectrum-X Ethernet. Astera Labs lavorerà ai collegamenti. Per gli operatori il vantaggio promesso è usare un’architettura di rack, alimentazione, raffreddamento e filiera già diffusa invece di progettare un sistema separato per ogni acceleratore. La parola chiave resta promessa. d-Matrix prevede il tape-out, cioè la chiusura del progetto da inviare alla produzione, entro la fine del 2026. La disponibilità iniziale dei rack Raptor-MGX è indicata per il quarto trimestre 2027. Non ci sono ancora prezzo pubblico, benchmark indipendenti né un sistema che un’azienda possa ordinare oggi.
Perché è importante
- d-Matrix userà NVLink Fusion per collegare i futuri acceleratori Raptor a rack NVIDIA MGX, con CPU Vera, rete Spectrum-X e altri componenti della piattaforma.
- L’architettura punta a separare prefill e decode: le GPU preparano il contesto, mentre chip specializzati accelerano la generazione interattiva dei token.
- Raptor non è acquistabile oggi: il tape-out è atteso entro fine 2026 e i rack integrati nel quarto trimestre 2027; prestazioni e costi pubblici indipendenti non sono ancora disponibili.
Raptor entra nel rack NVIDIA, ma il prodotto è ancora futuro
L’addestramento costruisce il modello; l’inferenza lo usa. Ogni prompt deve essere letto e trasformato in una sequenza di token, piccole unità di testo. Nelle applicazioni interattive contano almeno due tempi: l’attesa prima del primo token e la velocità con cui arrivano i successivi. Un agente aggiunge chiamate a strumenti, nuove fonti e più turni, moltiplicando gli spostamenti di dati. La prima fase si chiama prefill: il sistema elabora istruzioni e contesto. È intensa dal punto di vista del calcolo e può essere adatta a GPU molto potenti. La seconda, decode, genera un token dopo l’altro e incontra spesso un limite nella velocità con cui i pesi del modello vengono letti dalla memoria. d-Matrix propone di affidare il prefill ai sistemi NVIDIA Vera Rubin e il decode ai propri XPU specializzati. Raptor usa una memoria tridimensionale: un chip DRAM e uno di calcolo SRAM vengono sovrapposti nello stesso pacchetto. L’obiettivo è avvicinare dati e operazioni per ridurre tempo ed energia persi nello spostamento. È un approccio diverso dai problemi di fabbricazione descritti nell’articolo sulle maschere più grandi per i chip AI High-NA: qui il collo di bottiglia non è stampare il chip, ma alimentarlo continuamente con i dati.
d-Matrix indica tre carichi sensibili alla latenza: assistenti di programmazione, chatbot in tempo reale e agenti vocali. Per chi usa un prodotto, il risultato desiderato è semplice: risposta che parte prima e mantiene un ritmo naturale. Per chi lo gestisce, il vantaggio può essere servire più richieste con lo stesso budget energetico o riservare l’hardware costoso alle fasi che ne hanno davvero bisogno. Un coding assistant può leggere un repository nel prefill, poi produrre e correggere codice nel decode. Un agente vocale alterna ascolto, ragionamento, strumenti e sintesi: anche piccoli ritardi si sommano fino a rompere la conversazione. Un chatbot di assistenza deve invece reggere picchi e molte sessioni. La stessa architettura non è automaticamente ottimale per tutti: modello, lunghezza del contesto e numero di utenti cambiano il carico. Gli utenti non vedranno il nome del chip nella maggior parte dei servizi e non devono scegliere un data center per ottenere una risposta migliore. Possono però misurare quattro dati: tempo al primo token, velocità della generazione, latenza degli strumenti e durata totale del compito. La guida sul costo degli agenti per risultato valido aggiunge tentativi, revisione ed esito alla stessa prova.
Cosa puoi farci concretamente
- Prima di cambiare modello o infrastruttura, misurare tempo al primo token, token al secondo, latenza del tool e durata totale su dieci attività rappresentative.
- Separare i lavori interattivi da quelli batch: una risposta vocale richiede bassa latenza, mentre un report notturno può privilegiare costo e capacità complessiva.
- Per un acquisto futuro, chiedere benchmark indipendenti sul proprio modello, consumo per richiesta, compatibilità software e percorso di uscita dalla piattaforma.
Il verdetto: collaborazione utile, risultati ancora da dimostrare
NVLink Fusion permette a NVIDIA di aprire la propria piattaforma a processori specializzati mantenendo al centro rete, rack, software e filiera. Per d-Matrix riduce il rischio di portare un chip nuovo in produzione su larga scala. Per i clienti può ampliare la scelta senza costruire due data center distinti. È anche un legame stretto con un ecosistema proprietario: compatibilità e facilità di distribuzione possono aumentare insieme alla dipendenza. Le dichiarazioni su latenza, efficienza e costo arrivano dai partner. Prima di una decisione servono benchmark indipendenti sullo stesso modello, qualità identica dell’output, consumo del sistema completo e stabilità sotto carico. Il costo del token non include da solo rete, raffreddamento, licenze software, capacità inutilizzata e lavoro operativo. Una demo molto veloce con una configurazione selezionata non è un dato economico generale. L’annuncio è importante perché rende leggibile la prossima fase della corsa AI. Non basta costruire modelli più capaci: bisogna farli rispondere milioni di volte con ritardo e costo sostenibili. Raptor potrebbe aiutare nei lavori interattivi, ma il 2027 è lontano e il progetto deve ancora diventare silicio, rack e servizio. Oggi la conclusione corretta è capire il collo di bottiglia e preparare metriche, non acquistare una promessa.
Nell’hardware AI prestazioni e affidabilità devono essere osservate nel sistema completo. Sensori, memoria, rete, alimentazione e software determinano il risultato quanto il componente più visibile. I test devono quindi riprodurre condizioni e carichi operativi. Nel caso di “Perché gli agenti AI lenti hanno un problema di memoria, non solo di chip”, questo significa leggere la novità oltre l’annuncio e capire quali parti del lavoro vengono realmente modificate. Il rischio è misurare soltanto il picco e ignorare manutenzione, sicurezza e variabilità. Nel mondo fisico un errore può fermare un processo o produrre conseguenze materiali. Soglie, ridondanze e procedure di recupero sono parte della prestazione. La diffusione dipenderà dalla capacità di ridurre costo di integrazione e tempo di riconfigurazione. Piattaforme, simulazione e strumenti condivisi possono accelerare il passaggio alla produzione, mentre il know-how sul processo resterà determinante. La notizia è quindi un indicatore di una trasformazione più ampia, che va seguita attraverso risultati e condizioni operative anziché con la sola successione degli annunci.
La prova dei fatti
Prima di cambiare modello o infrastruttura, misurare tempo al primo token, token al secondo, latenza del tool e durata totale su dieci attività rappresentative. Questo primo passo serve a trasformare il tema in un perimetro verificabile: un responsabile, un input conosciuto, un risultato atteso e una misura precedente con cui confrontarsi. Senza questi elementi il progetto rimane una dimostrazione difficile da valutare. Separare i lavori interattivi da quelli batch: una risposta vocale richiede bassa latenza, mentre un report notturno può privilegiare costo e capacità complessiva. L’azione deve essere documentata insieme ai criteri di controllo, indicando quali casi possono procedere e quali devono fermarsi. È così che l’esperienza delle persone diventa una regola applicabile e migliorabile nel tempo. Per un acquisto futuro, chiedere benchmark indipendenti sul proprio modello, consumo per richiesta, compatibilità software e percorso di uscita dalla piattaforma. Prima di estendere il metodo è utile raccogliere correzioni, tempi e costi per alcune settimane. Gli errori vanno raggruppati per causa: dati, istruzioni, strumenti o eccezioni del processo. Ogni categoria richiede un intervento diverso. d-Matrix userà NVLink Fusion per collegare i futuri acceleratori Raptor a rack NVIDIA MGX, con CPU Vera, rete Spectrum-X e altri componenti della piattaforma. È il punto da cui partire perché definisce l’effetto più immediato per professionisti e imprese. La sua importanza va misurata sul lavoro quotidiano: quante attività coinvolge, quali persone tocca e cosa accade quando il risultato non è corretto.
L’architettura punta a separare prefill e decode: le GPU preparano il contesto, mentre chip specializzati accelerano la generazione interattiva dei token. Questo secondo elemento chiarisce perché non basta scegliere un prodotto. Servono un processo, dati affidabili e una responsabilità finale. L’adozione diventa sostenibile quando la tecnologia può essere osservata e corretta senza interrompere l’operatività. Raptor non è acquistabile oggi: il tape-out è atteso entro fine 2026 e i rack integrati nel quarto trimestre 2027; prestazioni e costi pubblici indipendenti non sono ancora disponibili. Il terzo punto indica la prospettiva di medio periodo. La decisione migliore non è necessariamente quella con più funzioni, ma quella che mantiene valore, controllo e possibilità di evoluzione quando cambiano modelli, prezzi o requisiti.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
