Leader di pensiero

Cinque passaggi per trasformare la memoria da limite principale dell’AI in un vantaggio competitivo

mm
Aggiungi Unite.AI alle tue fonti preferite su Google

Negli ultimi anni, l’infrastruttura dell’AI si è concentrata sul calcolo più di ogni altra metrica. Più acceleratori, cluster più grandi e FLOPS più alti hanno guidato la conversazione per sfruttare al meglio le GPU. Questo approccio aveva senso quando il progresso del modello dipendeva principalmente dalla scala di addestramento. Ora, con la priorità alle distribuzioni di produzione dell’AI, c’è un nuovo vincolo su cui concentrarsi: la memoria.

Oggi, molte delle limitazioni più difficili per l’AI si verificano nella capacità di memoria, nella larghezza di banda, nella latenza e nel tempo e nel costo energetico di spostare i dati all’interno di un sistema. Le finestre di contesto continuano ad espandersi, con aziende come Anthropic che offrono finestre di token di milioni nella loro offerta a prezzo standard. I carichi di lavoro di inferenza stanno crescendo. La crescita dei sistemi multi-agente significa che i sistemi di intelligenza artificiale passano volumi di dati più grandi da una fase all’altra. Gli operatori possono continuare a provare ad aggiungere più GPU, ma non raggiungono comunque le prestazioni che si aspettano perché questi sistemi sono affamati di RAM sufficiente per alimentare gli acceleratori in modo efficiente quando ogni server opera all’interno del proprio sistema, limitato alla RAM del sistema.

Questo cambiamento influisce sia sulla produttività che sui costi per i fornitori di servizi cloud e gli operatori di data center. Quando la memoria diventa il fattore limitante, le organizzazioni spesso rispondono sovradimensionando l’hardware costoso, lasciando la capacità di GPU inutilizzata e assorbendo costi di energia e infrastruttura più alti. La prossima fase di scalabilità dell’AI dipenderà meno dall’aggiunta di calcolo grezzo e più dalla costruzione di architetture di memoria che si adattino al modo in cui l’AI di produzione funziona effettivamente.

Ecco cinque passaggi che i leader dell’infrastruttura possono intraprendere ora per prepararsi alle crescenti richieste di memoria.

1. Inizia misurando il vero collo di bottiglia

Molte organizzazioni valutano ancora le prestazioni dell’AI attraverso una lente di calcolo. Monitorano l’utilizzo del cluster, il numero di acceleratori e la produttività generale, quindi suppongono che i miglioramenti provengano dall’aggiunta di più acceleratori GPU. Quella visione spesso perde di vista il problema reale.

La pressione sulla memoria spesso si manifesta in acceleratori bloccati, latenza per token più alta e produttività inconsistente sotto carico. Un’GPU può sembrare sottoutilizzata se sta aspettando che i dati arrivino da un’altra memoria o da un’altra fase dell’applicazione. L’inferenza rende quel problema più visibile poiché la dimensione della cache KV cresce e più sessioni simultanee competono per la larghezza di banda.

Gli operatori necessitano di una migliore visibilità sull’utilizzo effettivo della memoria, guardando ai byte spostati per token, al tempo di blocco dell’acceleratore e ai modelli di accesso alla memoria tra CPU, GPU e livelli di memoria adiacenti. Hanno anche bisogno di una tracciatura della pipeline in grado di separare i ritardi legati alla memoria da problemi di rete o di archiviazione. Senza quella visibilità, i team rischiano di spendere di più sul calcolo senza affrontare la vera fonte del rallentamento.

2. Riduci lo spostamento dei dati prima di aggiungere più capacità

Nei grandi sistemi di intelligenza artificiale, spostare i dati può creare così tanto sovraccarico quanto elaborare i dati.

Questo è particolarmente vero nell’inferenza. Man mano che le finestre di contesto si espandono, la cache KV può diventare uno dei maggiori consumatori di memoria di sistema nello stack. Il servizio multi-tenant e i flussi di lavoro multi-agente possono aggiungere ancora di più. La prima fase genera un output, poi un’altra lo consuma e l’infrastruttura gestisce questo passaggio copiando grandi blocchi di dati tra GPU, tra server o attraverso la serializzazione a livello di framework.

Queste copie hanno un costo reale. Consumano larghezza di banda, aggiungono latenza e lasciano risorse di calcolo costose in attesa che il prossimo trasferimento si completi. Spingono anche gli operatori ad acquistare più memoria costosa di quanto il carico di lavoro richieda effettivamente.

Prima di investire in più acceleratori, i team dovrebbero identificare dove nel sistema i dati si spostano più del necessario. I trasferimenti GPU-to-GPU, le copie server-to-server e lo spostamento ripetuto di stati intermedi attraverso le pipeline degli agenti sono buoni punti di partenza. In molti ambienti, ridurre gli spostamenti non necessari consegna più prestazioni utilizzabili di un altro server.

3. Costruire livelli di memoria intorno al comportamento del carico di lavoro

L’infrastruttura dell’AI funziona meglio quando gli operatori smettono di trattare la memoria come una singola fonte e iniziano a trattarla come una gerarchia con ruoli distinti.

I dati più caldi dovrebbero rimanere più vicini all’acceleratore. Ciò include set di lavoro che richiedono la latenza più bassa e la larghezza di banda più alta. Altri buffer attivi e stati frequentemente accessibili possono sedere nella DRAM. Strutture più grandi che necessitano di scalabilità più che di velocità assoluta possono spostarsi nella memoria condivisa. Dati più freddi e modelli meno attivi appartengono più in basso nello stack.

Questo approccio richiede ai team di capire quali dati cambiano costantemente, quali dati molti processi condividono e quali dati possono tollerare uno scambio di latenza modesto senza influenzare la qualità del servizio. Troppi ambienti di distribuzione continuano a spingere tutto nel livello HBM più veloce perché sembra più sicuro. Quell’approccio aumenta i costi e di solito lascia l’efficienza sul tavolo.

Una strategia di memoria a livelli dà agli operatori più controllo sia sulle prestazioni che sull’economia. Nell’AI di produzione, quell’equilibrio sta diventando un requisito di progettazione fondamentale.

4. Trattare la memoria condivisa come parte dell’architettura per l’AI agente

L’AI multi-agente sta aumentando il costo di una progettazione di memoria frammentata.

In molti sistemi agente, un agente produce un output che un altro agente utilizza immediatamente. Un terzo servizio può classificare quell’output, aggiungere contesto o instradarlo in un altro modello. Se ogni fase crea una copia fresca dello stesso stato, il traffico aumenta rapidamente. Man mano che il contesto cresce, la dimensione di quei dati copiati cresce con esso. Il sistema spende più tempo spostando informazioni che elaborando dati.

È qui che la memoria condivisa diventa sempre più importante, in particolare per la cache KV condivisa e altri stati che più agenti o servizi devono accedere. La memoria condivisa può ridurre le copie ridondanti, ridurre il traffico di rete e migliorare l’utilizzo in tutta la traiettoria dell’applicazione. Può anche aiutare i sistemi agente a scalare efficacemente poiché diversi nodi o agenti possono riutilizzare la cache KV con la memoria condivisa.

Per i fornitori di servizi cloud, questo non è più un caso limite. Man mano che l’AI agente matura, la memoria condivisa sta diventando un requisito pratico per una distribuzione efficiente.

5. Accettare CXL per l’infrastruttura di produzione

Per gli ultimi anni, l’industria ha visto CXL come uno standard promettente che necessitava di più tempo per maturare, poiché CXL si è mosso rapidamente dalla versione 1 alla versione 2. Ora, con l’hardware 3.x disponibile presto, CXL sta raggiungendo il punto di essere completo, compatibile con le versioni precedenti e pronto ad affrontare i carichi di produzione.

CXL ha raggiunto un livello di maturità in cui i fornitori di servizi cloud e gli operatori di data center dovrebbero considerarlo un’opzione pratica per l’espansione della memoria di produzione, la pooling e le architetture di memoria condivisa. Ora appartiene alla pianificazione dell’infrastruttura seria, specialmente per gli ambienti che necessitano di una scalabilità della memoria più flessibile e di migliori economie intorno all’inferenza.

Ciò non significa che ogni carico di lavoro debba spostarsi su una memoria basata su CXL. La memoria locale rimarrà essenziale per i dati più caldi e più sensibili alla latenza. Ma gli operatori non devono più aspettare una versione futura dello standard prima di agire. La domanda più utile è dove CXL possa risolvere problemi di produzione reali oggi.

Le opportunità più chiare sono nell’espansione della memoria, nella memoria condivisa e nelle progettazioni di memoria condivisa che riducono le copie non necessarie attraverso i flussi di lavoro dell’AI. Quegli utilizzi si allineano direttamente con i punti di pressione attuali: la crescente domanda di cache KV, il trasferimento di dati crescente da agente a agente e la necessità di migliorare l’utilizzo della GPU senza spingere il costo totale di proprietà ancora più in alto.

Gli operatori devono ancora ingegnerizzare con cura. La latenza, la prevedibilità e il supporto software continuano a essere importanti. Le politiche di gestione della memoria devono posizionare i dati nel livello giusto al momento giusto. Ma quelle sono domande di implementazione, non motivi per ritardare la pianificazione.

In XCENA, vediamo la memoria, lo spostamento dei dati e l’utilizzo come i vincoli centrali nell’infrastruttura dell’AI di produzione. È per questo che ci concentriamo sulla memoria computazionale basata su CXL e sulle architetture che riducono la copia non necessaria, supportano l’accesso condiviso e aiutano gli operatori a utilizzare meglio le risorse di calcolo costose.

L’industria ha trattato la memoria come una risorsa di supporto dietro il vero motore del progresso dell’AI. Quella visione non si adatta più alla realtà della distribuzione di produzione. La memoria ora definisce l’utilizzo, l’efficienza e il costo a ogni livello dello stack. Gli operatori che riconoscono quel cambiamento presto avranno un vantaggio che si misura non solo nelle prestazioni, ma in quanto sono efficaci nel scalare l’AI nel mondo reale.

Jin Kim è l'amministratore delegato e co-fondatore di XCENA, un'azienda di semiconduttori fabless con sede in Corea del Sud, che si concentra sulla costruzione di soluzioni di memoria di prossima generazione per l'intelligenza artificiale e l'elaborazione dei dati su larga scala. Con un background che include ruoli di leadership senior presso SK Hynix, dove è stato uno dei vicepresidenti aziendali più giovani, Kim porta una profonda esperienza nel campo del calcolo centrato sui dati e dell'architettura dei semiconduttori.