In questo articolo Indice dei contenuti 2 sezioni
Con LPDDR5X-PIM Samsung prova a rovesciare una logica che regge l’informatica da decenni, cioè quella di spostare i dati verso il processore invece di portare il calcolo dove i dati già si trovano. Il prototipo mostrato a Hot Chips 2026 è una memoria da 16 GB che ospita unità aritmetiche accanto ai banchi DRAM, e il numero che spiega tutto in un colpo solo è la banda disponibile: 76,8 GB/s attraverso l’interfaccia esterna, contro 614 GB/s che le unità di elaborazione interne possono sfruttare senza uscire dal chip.
Per anni la corsa all’accelerazione dell’intelligenza artificiale ha seguito una strada abbastanza lineare, GPU sempre più potenti, pile di memorie HBM con bus larghissimi, persino memorie flash progettate per avvicinarsi fisicamente agli acceleratori. Resta però il costo, in energia e in tempo, di trasferire miliardi di parametri avanti e indietro. Il Processing-in-Memory, o PIM, è la risposta che i ricercatori inseguono da decenni per aggirare il collo di bottiglia dell’architettura di von Neumann, dove memoria e processore sono due mondi separati. Samsung ci lavora pubblicamente almeno dal 2021.
Cosa c’è davvero dentro i 16 GB del prototipo
Il chip mostrato integra 16 blocchi PIM affiancati ai banchi DRAM. Ogni blocco contiene unità pensate per fare una cosa sola, ma quella che nelle reti neurali torna in continuazione: moltiplicare valori e accumulare il risultato. Nessuno sta cercando di trasformare la memoria in una CPU general purpose, l’obiettivo è più modesto e più furbo, dare abbastanza capacità di calcolo da eseguire in locale le operazioni che altrimenti costringerebbero il sistema a inondare GPU o NPU di dati.
I numeri di potenza pura non impressionano se confrontati con un acceleratore vero, si parla di 2,4 TOPS con pesi SINT4 e circa 1,2 TFLOPS in FP8. Hanno senso proprio perché quei calcoli avvengono dove i dati sono già parcheggiati. È il motivo per cui il PIM funziona bene sulle moltiplicazioni matrice vettore tipiche dei LLM, quelle situazioni in cui il processore deve rileggere montagne di pesi per sputare fuori ogni singolo token.
Il test su Llama 3.1 8B e il muro del software
La verifica è avvenuta su silicio reale, con il modello Llama 3.1 8B e un acceleratore edge sviluppato in casa. Nel test, con un contesto di 320 token, attivazioni SINT8, pesi SINT4 e output SINT32, la LPDDR5X convenzionale si fermava attorno ai 27 token al secondo. La versione PIM è salita a 81,3 token al secondo, con il tempo di elaborazione sceso da 12,3 a 5,4 secondi. Throughput triplicato, in pratica.
Va detto senza girarci intorno che si tratta di un benchmark del produttore, con un modello specifico, una quantizzazione specifica e una finestra di contesto piuttosto contenuta. Allungando il contesto, gonfiando la KV cache, introducendo batching o architetture Mixture-of-Experts il quadro può cambiare parecchio.
Il problema più fastidioso, però, non riguarda l’hardware. Riguarda il software. Runtime come llama.cpp e vLLM non sanno cosa farsene di una memoria del genere, non la sfruttano in automatico. Servono backend dedicati, una distribuzione dei pesi che tenga conto di come sono organizzati i banchi e formati numerici compatibili con le unità presenti nella DRAM.
Poi c’è la questione della memoria virtuale, che complica ulteriormente le cose. Un’applicazione lavora normalmente su indirizzi virtuali e lascia al sistema operativo il compito di decidere dove piazzare le pagine nella RAM fisica. Il PIM ribalta questo schema, perché certe matrici devono finire nei banchi giusti, con gli allineamenti giusti. Nemmeno un meccanismo collaudato come mmap, che llama.cpp usa abbondantemente per caricare i modelli, basta da solo. Runtime, driver e allocatori dovrebbero conoscere la topologia fisica della memoria.
La direzione indicata da Samsung resta interessante proprio perché attacca il problema alla radice, riducendo il numero di volte in cui i dati devono viaggiare invece di aumentare all’infinito la velocità con cui raggiungono GPU e NPU. Prima di parlare di adozione su larga scala serviranno però supporto nei runtime, formati di quantizzazione adeguati, gestione consapevole dei banchi e integrazione con sistemi operativi e acceleratori. Più che un rimpiazzo per CPU e GPU, il PIM si profila come un livello ulteriore di specializzazione, dedicato alle operazioni per cui spostare i dati costa più che elaborarli.
