Vijf stappen om geheugen van de grootste beperking van AI om te zetten in een concurrentievoordeel

De afgelopen jaren heeft de AI-infrastructuur zich vooral gericht op rekenkracht boven alle andere metrics. Meer accelerators, grotere clusters en hogere FLOPS dreven het gesprek om het meest te maken van GPUs. Deze aanpak had zin toen de vooruitgang van modellen vooral afhing van de trainingsomvang. Nu AI-productiedeployments prioriteit hebben, is er een nieuwe beperking om op te focussen: geheugen.

Vandaag de dag komen veel van de zwaarste beperkingen voor AI voor in geheugencapaciteit, bandbreedte, latentie en de tijd- en energiekosten van het verplaatsen van gegevens door een systeem. Contextvensters blijven uitbreiden, met bedrijven als Anthropic die nu miljoen tokenvensters aanbieden in hun standaardgeprijsde aanbod. Inference-werklasten nemen toe. De groei van multi-agentsystemen betekent dat AI-systemen grotere volumes aan gegevens van de ene naar de andere fase doorsluizen. Operators kunnen blijven proberen meer GPUs toe te voegen, maar ze komen nog steeds tekort aan de prestaties die ze verwachten, omdat deze systemen honger lijden naar voldoende RAM om accelerators efficiënt te voeden wanneer elke server op zichzelf werkt, beperkt tot in-systeemgeheugen.

Deze verschuiving heeft invloed op zowel de doorvoer als de kosten voor hyperscalers en datacenteroperators. Wanneer geheugen de beperkende factor wordt, reageren organisaties vaak door dure hardware over te dimensioneren, waardoor de GPU-capaciteit onderbenut wordt en hogere energiekosten en infrastructuurkosten ontstaan. Het volgende stadium van AI-schaal zal minder afhankelijk zijn van het toevoegen van ruwe rekenkracht en meer van het opbouwen van geheugenarchitecturen die passen bij de manier waarop productie-AI daadwerkelijk werkt.

Hier zijn vijf stappen die infrastructuurleiders nu kunnen nemen om zich voor te bereiden op de almaar groeiende vraag naar geheugen.

1. Start met het meten van de echte bottleneck

Veel organisaties evalueren AI-prestaties nog steeds door een rekenkracht-georiënteerde lens. Ze volgen clustergebruik, acceleratoraantallen en bovendoorvoer, en gaan ervan uit dat verbeteringen zullen komen van het toevoegen van meer GPU-accelerators. Die visie mist vaak het echte probleem.

Geheugendruk manifesteert zich vaak in stilgezette accelerators, hogere per-tokenlatentie en onregelmatige doorvoer onder belasting. Een GPU kan onderbenut worden als het wacht op gegevens die uit een andere geheugentier, een andere server of een andere fase in de toepassing moeten komen. Inference maakt dat probleem zichtbaarder, omdat de KV-cachegrootte toeneemt en meer gelijktijdige sessies concurreren om bandbreedte.

Operators hebben betere zichtbaarheid nodig in de effectieve geheugengebruik, door te kijken naar bytes per token, acceleratorstilstandtijd en geheugen-toegangspatronen over CPUs, GPUs en aangrenzende geheugentiers. Ze hebben ook pipeline-tracing nodig die geheugen-gerelateerde vertragingen kan scheiden van netwerk- of opslagproblemen. Zonder die zichtbaarheid riskeren teams meer uit te geven aan rekenkracht zonder de werkelijke oorzaak van de vertraging aan te pakken.

2. Verplaats gegevens minder voordat u meer capaciteit toevoegt

In grote AI-systemen kan het verplaatsen van gegevens evenveel overhead creëren als het verwerken van de gegevens.

Dit is vooral waar in inference. Terwijl contextvensters uitbreiden, kan de KV-cache een van de grootste consumenten van systeemgeheugen in de stack worden. Multi-tenant serving en multi-agent workflows kunnen nog meer toevoegen. De eerste fase genereert een uitvoer, dan consumeert een andere fase deze en de infrastructuur behandelt deze overdracht door grote blokken gegevens tussen GPUs, servers of via framework-niveau-serialisatie te kopiëren.

Die kopieën hebben een echte kostenpost. Ze consumeren bandbreedte, voegen latentie toe en laten dure rekenbronnen wachten tot de volgende overdracht is voltooid. Ze dwingen operators ook om meer dure geheugen te kopen dan de workload echt nodig heeft.

Voordat ze meer accelerators investeren, moeten teams identificeren waar in een systeem gegevens meer dan nodig worden verplaatst. GPU-tot-GPU-overdrachten, server-tot-server-kopieën en herhaalde verplaatsing van tussenliggende staten over agent-pijpleidingen zijn goede plaatsen om te beginnen. In veel omgevingen levert het verminderen van onnodige beweging meer bruikbare prestaties op dan een extra server.

3. Bouw geheugentiers rond workload-gedrag

AI-infrastructuur werkt beter wanneer operators stoppen met het behandelen van geheugen als een enkele bron en beginnen met het behandelen als een hiërarchie met distincte rollen.

De heetste gegevens moeten het dichtst bij de accelerator blijven. Dat omvat de werksets die de laagste latentie en de hoogste bandbreedte vereisen. Andere actieve buffers en vaak geraadpleegde staten kunnen in DRAM zitten. Grotere structuren die schaal nodig hebben in plaats van absolute snelheid, kunnen naar het gedeelde geheugen verhuizen. Koude gegevens en minder actieve modellen horen verder naar beneden in de stack.

Deze aanpak vereist dat teams begrijpen welke gegevens constant veranderen, welke gegevens veel processen delen en welke gegevens een matige latentietoeslag kunnen verdragen zonder de servicakwaliteit te beïnvloeden. Te veel implementaties gebruiken nog steeds alles in de snelste HBM-laag, omdat het veiliger aanvoelt. Die aanpak verhoogt de kosten en laat doorgaans efficiëntie op tafel liggen.

Een gestratificeerde geheugenstrategie geeft operators meer controle over zowel prestaties als economie. In productie-AI wordt die balans een core-ontwerpeis.

4. Behandel gedeeld geheugen als onderdeel van de architectuur voor agente-AI

Multi-agente AI verhoogt de kosten van gefragmenteerd geheugenontwerp.

In veel agente-systemen produceert een agent output die een andere agent onmiddellijk gebruikt. Een derde service kan die output rangschikken, context toevoegen of doorsturen naar een andere model. Als elke stap een verse kopie van dezelfde staat maakt, stijgt het verkeer snel. Terwijl context groeit, groeit de grootte van die gekopieerde gegevens mee. Het systeem besteedt meer tijd aan het verplaatsen van informatie dan aan het verwerken van gegevens.

Dit is waar gedeeld geheugen steeds belangrijker wordt, vooral voor gedeelde KV-cache en andere staten die meerdere agenten of services nodig hebben om toegang te krijgen. Gedeeld geheugen kan redundante kopieën verminderen, netwerkverkeer verlagen en de benutting over de volledige toepassingspad verbeteren. Het kan ook helpen agente-systemen effectief schalen wanneer verschillende knooppunten of agenten KV-cache met gedeeld geheugen kunnen hergebruiken.

Voor hyperscalers is dit geen randgeval meer. Terwijl agente-AI rijpt, wordt gedeeld geheugen een praktische vereiste voor efficiënte implementatie.

5. Omarm CXL voor productie-infrastructuur

De afgelopen jaren zag de industrie CXL als een veelbelovende standaard die nog meer tijd nodig had om te rijpen, terwijl CXL snel van versie 1 naar 2 ging. Nu met 3.x-hardware beschikbaar, bereikt CXL het punt waarop het feature-compleet, backward-compatibel en klaar is om productiewerklasten aan te pakken.

CXL heeft een niveau van volwassenheid bereikt waarop hyperscalers en datacenteroperators het moeten behandelen als een praktische optie voor productiegeheugenuitbreiding, -pooling en gedeeld-geheugenarchitecturen. Het hoort nu in serieuze infrastructuurplanning, vooral voor omgevingen die flexibele geheugenschaal en betere economie rond inference nodig hebben.

Dat betekent niet dat elke workload naar CXL-gebaseerd geheugen moet worden verplaatst. Lokale geheugen zal nog steeds essentieel zijn voor de heetste en meest latentie-gevoelige gegevens. Maar operators hoeven niet langer te wachten op een toekomstige versie van de standaard voordat ze actie ondernemen. De meest bruikbare vraag is waar CXL reële productieproblemen vandaag kan oplossen.

De duidelijkste kansen liggen in geheugenuitbreiding, gedeeld geheugen en gedeeld-geheugenontwerpen die onnodige kopieën over AI-workflows verminderen. Die use-cases komen rechtstreeks overeen met de huidige drukpunten: stijgende KV-cache-eisen, groeiende agent-tot-agent-gegevensoverdracht en de noodzaak om GPU-benutting te verbeteren zonder de totale kosten van eigendom nog hoger te duwen.

Operators moeten nog steeds zorgvuldig ontwerpen. Latentie, voorspelbaarheid en software-ondersteuning zijn nog steeds belangrijk. Geheugenbeleidsregels moeten gegevens in de juiste laag op het juiste moment plaatsen. Maar dat zijn implementatievragen, geen redenen om plannen uit te stellen.

Bij XCENA zien we geheugen, gegevensverplaatsing en benutting als de centrale beperkingen in productie-AI-infrastructuur. Daarom richten we ons op CXL-gebaseerde computationeel geheugen en architectuur die onnodige kopieën vermindert, gedeelde toegang ondersteunt en operators helpt om beter gebruik te maken van dure rekenbronnen.

De industrie behandelde geheugen jarenlang als een ondersteunende bron achter de echte motor van AI-vooruitgang. Die visie past niet langer bij de productie-implementatiereductie. Geheugen vormt nu de benutting, efficiëntie en kosten op elk niveau van de stack. De operators die die verschuiving vroeg herkennen, zullen een voordeel hebben dat niet alleen wordt gemeten in prestaties, maar in hoe effectief ze AI in de echte wereld schalen.