La memoria GPU è una delle risorse più costose e limitanti nelle infrastrutture di intelligenza artificiale in produzione. L’aumento delle finestre di contesto, delle conversazioni a più turni e degli agenti capaci di lavorare per sessioni prolungate obbliga i sistemi a conservare quantità crescenti di informazioni già elaborate. Quando queste informazioni non possono rimanere nella memoria ad alta velocità degli acceleratori, il modello deve ricalcolarle, occupando capacità computazionale che potrebbe essere utilizzata per servire nuove richieste o aumentare il numero di utenti gestiti dalla stessa infrastruttura.
Weka affronta questo problema con NeuralMesh 6, una nuova versione della propria piattaforma software che utilizza la memoria flash NAND come estensione della memoria disponibile per i carichi di lavoro AI. L’obiettivo non è sostituire direttamente la memoria HBM delle GPU, che continua a essere indispensabile per le operazioni più sensibili alla latenza, ma creare un livello di capacità molto più ampio ed economico nel quale conservare dati intermedi, cache e informazioni di contesto che altrimenti occuperebbero risorse GPU o dovrebbero essere ricalcolate.
L’approccio prende il nome di Augmented Memory Grid e aggrega grandi quantità di memoria flash distribuita, rendendole accessibili ai sistemi di inferenza come un’estensione condivisa della memoria. Il vantaggio deriva soprattutto dalla differenza di costo e capacità tra memoria GPU e NAND: a parità di investimento, un’infrastruttura può installare quantità di flash superiori di diversi ordini di grandezza rispetto alla memoria degli acceleratori, conservando quindi una parte molto più ampia dei risultati già calcolati.
Il problema è particolarmente evidente nella gestione della cache KV, l’insieme di dati intermedi generati dal meccanismo di attenzione dei modelli linguistici. Durante la fase di prefill, il modello elabora l’intero input e calcola le relazioni tra i token; durante la successiva fase di decoding utilizza questi risultati per generare progressivamente la risposta. La prima fase è molto più onerosa sul piano computazionale, soprattutto quando il prompt include documenti estesi, cronologie complete o repository software di grandi dimensioni.
Nelle conversazioni a più turni, ogni nuovo messaggio si aggiunge alla sequenza precedente. Senza una cache persistente, il sistema deve elaborare nuovamente una parte consistente dell’intera cronologia, anche se la maggioranza dei token era già stata analizzata nei turni precedenti. Con l’aumentare delle interazioni, il lavoro duplicato cresce rapidamente e può trasformare una sessione apparentemente semplice in un carico molto pesante per le GPU. Conservare la cache KV su un livello flash sufficientemente rapido permette invece di recuperare i risultati già prodotti e di concentrare la capacità computazionale soltanto sui nuovi token.
Questo meccanismo diventa rilevante nelle applicazioni che mantengono sessioni lunghe e ricche di contesto, come assistenti aziendali, agenti per il servizio clienti, sistemi di supporto alla programmazione e piattaforme di retrieval che interrogano grandi basi documentali. In questi ambienti il costo non dipende soltanto dal numero di richieste, ma anche dalla quantità di cronologia che deve essere riletta e ricalcolata a ogni interazione. Un livello di memoria esterna alla GPU può quindi migliorare il throughput complessivo e ridurre il costo per risposta senza richiedere l’acquisto immediato di ulteriori acceleratori.
NeuralMesh 6 introduce anche una gestione multi-tenant pensata per infrastrutture condivise da più organizzazioni, reparti o clienti. I cluster componibili assegnano CPU, memoria e storage dedicati ai tenant che richiedono un isolamento fisico completo, mentre la modalità virtuale utilizza la rete RDMA per separare logicamente ambienti differenti sulla stessa infrastruttura. Secondo l’architettura proposta da Weka, un singolo cluster può gestire oltre mille tenant virtuali e, combinando più cluster componibili, arrivare a supportare decine di migliaia di ambienti separati.
Questa capacità risponde soprattutto alle esigenze dei GPU cloud e delle piattaforme neocloud, che devono assegnare rapidamente nuove risorse computazionali a clienti differenti senza costruire ogni volta un’infrastruttura separata. Quando un’organizzazione ottiene una nuova disponibilità di GPU, il problema non è soltanto accendere i nodi, ma trasferire dataset, modelli, checkpoint, configurazioni e dipendenze necessarie per iniziare il lavoro. Se il processo di replica richiede giorni o settimane, una parte della capacità appena acquisita rimane inutilizzata nonostante il suo costo.
Per ridurre questo intervallo, NeuralMesh 6 introduce una replica basata sui metadati. L’ambiente di destinazione diventa consultabile prima che venga completata la copia fisica di tutti i dati, mentre i contenuti vengono trasferiti progressivamente quando sono effettivamente richiesti. Questo consente di iniziare a utilizzare un nuovo cluster senza attendere il trasferimento integrale di archivi che possono raggiungere dimensioni molto elevate, riducendo il tempo necessario per rendere operative nuove allocazioni di GPU.
La piattaforma unifica inoltre l’accesso ai dati tramite protocolli file e object storage. Le pipeline di addestramento e fine-tuning utilizzano spesso file system tradizionali, mentre molti strumenti cloud-native e di inferenza si aspettano interfacce compatibili con S3. Nelle architetture convenzionali, un gateway traduce i dati tra i due modelli e può richiedere copie separate, sincronizzazioni o livelli aggiuntivi di elaborazione. Weka consente invece di leggere gli stessi dati fisici attraverso entrambe le modalità, evitando duplicazioni e riducendo la complessità dell’infrastruttura.
L’eliminazione del gateway può migliorare anche le prestazioni nei carichi caratterizzati da un numero elevato di accessi concorrenti. Le piattaforme AI devono alimentare simultaneamente numerose GPU con file di grandi dimensioni, piccoli oggetti, checkpoint e sequenze di dati distribuite. Ogni livello intermedio aumenta la latenza e può trasformare lo storage nel collo di bottiglia dell’intero sistema, lasciando gli acceleratori in attesa nonostante la loro elevata capacità di calcolo.
Sul piano hardware, Weka ha introdotto Wekapod 3, la prima linea di sistemi progettata direttamente dall’azienda per eseguire NeuralMesh. La piattaforma utilizza AlloyFlash, una configurazione che combina memorie NAND TLC e QLC all’interno dello stesso cluster. La TLC offre prestazioni e durata superiori, ma ha un costo per terabyte maggiore; la QLC permette invece di aumentare la capacità complessiva con un costo inferiore, accettando prestazioni più contenute.
Il software distribuisce automaticamente i dati tra i due livelli in base alle caratteristiche del carico di lavoro. Le informazioni che devono essere recuperate con bassa latenza vengono indirizzate verso la memoria TLC, mentre i dati meno sensibili alla velocità o destinati principalmente alla conservazione vengono collocati sulla QLC. Questo modello consente di ridurre il costo medio per terabyte senza applicare la stessa tecnologia di memoria a ogni tipologia di dato, evitando di utilizzare componenti più costosi dove non producono un vantaggio concreto.
NeuralMesh 6 rende inoltre permanente la riduzione dei dati, anziché proporla come funzione opzionale. Deduplicazione e compressione riducono la capacità fisica necessaria per conservare checkpoint, versioni di modelli e dataset che spesso condividono grandi quantità di contenuti identici o molto simili. L’efficacia reale di queste tecniche dipende dalla struttura dei dati, ma può incidere in modo significativo sui costi quando vengono mantenute numerose copie successive dello stesso modello o di ambienti di addestramento derivati da una base comune.
La strategia di Weka si inserisce in una trasformazione più ampia del mercato dello storage. Dell, NetApp, Pure Storage e VAST stanno adattando le proprie piattaforme ai carichi di intelligenza artificiale, spostando l’attenzione dalla semplice conservazione dei dati alla capacità di alimentarli alla velocità richiesta dagli acceleratori. In questo scenario, la differenziazione non dipende più soltanto dalla capacità totale o dal numero di operazioni al secondo, ma dalla gestione della cache KV, dall’integrazione con le GPU, dalla rapidità di replica e dalla possibilità di utilizzare gli stessi dati in pipeline differenti.
Per le aziende che valutano queste piattaforme, il punto decisivo riguarda il beneficio misurabile sui carichi reali. Le prestazioni dichiarate devono essere confrontate utilizzando modelli, dataset, protocolli e dimensioni analoghe a quelle dell’ambiente di produzione, perché un sistema ottimizzato per il training sequenziale può comportarsi in modo molto diverso durante l’inferenza multi-tenant o l’esecuzione di agenti con contesti lunghi. Anche la riduzione dei dati deve essere verificata su contenuti rappresentativi, distinguendo tra capacità fisica installata, capacità logica dichiarata e risparmio effettivamente ottenibile.
L’estensione della memoria GPU attraverso lo storage flash non elimina la necessità di acceleratori più potenti né rende equivalenti NAND e HBM. Introduce però un livello intermedio che può ridurre la quantità di lavoro ripetuto, aumentare il numero di sessioni gestibili e migliorare l’utilizzo di GPU già acquistate. Nelle infrastrutture in cui memoria e capacità computazionale sono ormai il principale limite alla crescita, conservare e riutilizzare il lavoro svolto dal modello può risultare economicamente più efficace che continuare ad aumentare il numero di acceleratori.