RAM og VRAM: Hvordan de relaterer sig i en AI-server

Det første spørgsmål, købere stiller om en AI-server, er "hvor mange GPU'er". Det andet er "hvilken CPU". Spørgsmålet, der rent faktisk afgør, om kassen fungerer godt – og det, som de fleste specifikationsark begraver – er, hvordan de to hukommelsessystemer er dimensioneret i forhold til hinanden. En maskine med 4 GPU'er, 192 GB VRAM og 32 GB system-RAM er i stykker. Den samme maskine med 1 TB system-RAM er, for de fleste arbejdsbelastninger, penge, der er sat i brand. Det rigtige svar ligger midt imellem og afhænger af, hvad du rent faktisk kører.

Denne artikel gennemgår, hvad VRAM og system-RAM hver især gør, hvordan de relaterer sig, hvor båndbreddeflaskehalse sidder, og hvilke forhold der gælder i praksis. Målgruppen er købere og integratorer, der dimensionerer et build, ikke ingeniører, der skriver CUDA-kerner.

Hvad VRAM rent faktisk indeholder

Når en model "indlæses på GPU'en", er der tre ting, der findes i VRAM:

1. Modelvægte. En 70B-model ved FP16 er 140 GB; ved INT8, 70 GB; ved INT4 (den almindelige self-host-kvantisering), 35-40 GB afhængigt af kvanteskemaet.
2. KV-cache. Hukommelsesomkostninger pr. anmodning. En 70B-model ved 8K kontekst single-stream er 1-2 GB. Ved 32K er den 4-8 GB. Under batch-server (10-20 samtidige) fylder dette din resterende VRAM, ikke vægtene.
3. Aktiveringer og arbejdsområde. Mellemliggende opgaver i fremadgående pass, opmærksomhedsskrab, kernel-arbejdsområde. Et par GB til inferens; væsentligt mere under træning, fordi aktiveringer gemmes til bagudgående pass.

Til træning, tilføj optimeringstilstand (Adam beholder to FP32-værdier pr. vægt — cirka 8 gange FP16-vægtens størrelse) og gradienter (1× vægtstørrelse). Derfor kræver træning af en 70B-model fra bunden 8× H100- eller A100 80 GB-noder, og det er ikke noget, en Kentino-boks gør. Finjustering med LoRA eller QLoRA er en anden historie og fungerer komfortabelt på en 4-GPU 5090- eller Pro 6000 Blackwell-build.

Praktisk implikation: modelstørrelse i VRAM er ikke "parametre × bytes pr. parameter". For en 8K-kontekst implementering af en 70B-model ved INT4, planlæg 40 GB vægte + 20-40 GB KV cache ved realistisk batch + 4 GB overhead = ~70 GB. Det passer til en enkelt RTX Pro 6000 Blackwell Server Edition (96 GB) eller kræver 3-4 RTX 5090 til enhver rimelig batch. "VRAM i alt" betyder mindre end "VRAM pr. kort og hvordan de er tilsluttet".

VRAM-båndbredde: det tal, der bestemmer tokengenereringshastigheden

Tokengenerering på en transformer LLM er båndbreddebundet, ikke beregningsbundet. Hver genereret token læser hele modellen fra VRAM gennem hukommelsesbussen. Specifikationsarkets TFLOPS-tal er stort set irrelevant for inferens; det, der betyder noget, er GB/s hukommelsesbåndbredde.

Kentino sælger ikke H100 eller H200; de er angivet for ærlig sammenligning. De er fortsat båndbreddekongerne og grunden til, at hyperscalere køber dem. Prisforskellen er 6-10 gange, båndbreddeforskellen ved single-stream-inferens er 2 gange. For ikke-hyperscale-arbejdsbelastninger er den matematik ikke til fordel for HBM.

En grov regel for generering af INT4 single-stream tokens: tok/s ≈ båndbredde (GB/s) / modelstørrelse (GB), ganget med en stakeffektivitetsfaktor på 0.6-0.8. En 70B-model ved INT4 (~40 GB) på en enkelt 5090:

1790 GB/s × 0.7 / 40 GB ≈ 31 tok/s (single stream, no batching)

Dette stemmer overens med det, vi måler på prøvebænken. Batching øger den samlede gennemløbshastighed til 50-100 tok/s, men hastigheden per stream forbliver tæt på båndbreddeloftet. Ingen mængde system-RAM ændrer dette tal.

ECC VRAM: reel til træning, mindre kritisk til inferens

RTX Pro 6000 Blackwell-serien har ECC (fejlkorrigerende) VRAM. Det gør forbrugerkort (5090, 4090) ikke. Markedsføring får dette til at lyde kritisk; virkeligheden er mere nuanceret.

ECC VRAM registrerer og korrigerer enkeltbit-hukommelsesfejl under kørsel. Uden den udbreder en flip sig – normalt usynligt under inferens (én token er lidt anderledes end den ville have været), lejlighedsvis katastrofalt under træning (NaN-udbredelse, divergens, dead run).

Når ECC er vigtig:

• Langvarig træning. Hukommelsestrafik over flerdagesjob gør et stille bitflip til en reel sandsynlighed. At miste en 48-timers kørsel på grund af en uopdaget fejl er meget værre end på grund af en rettet fejl.
• Numeriske arbejdsbelastninger uden mennesker i løkken. Simulering, modellering, alt der forbruges downstream uden fornuftstjek.
• Regulerede arbejdsbyrder. Hvis din compliance-ordning kræver bit-nøjagtig reproducerbarhed, er ECC obligatorisk.

Når ECC primært er kosmetisk:

• LLM-inferensvisning. Bit-flip-hastigheden på moderne GDDR7 er lav nok til, at effekten på outputkvaliteten er under støj. Vi har kørt forbruger-5090-kort under kraftig inferens i flere måneder uden at se anomalier, der kan spores tilbage til VRAM-fejl.
• Billed- og videogenerering. Perceptuel støjgulv sluger en enkeltbitfejl.
• Udvikling og eksperimentering. Genstart og genstart er billigt.

Ærlig version: Hvis arbejdsbyrden primært er inferens, betaler Pro 6000 premium for 96 GB VRAM og validerede drivere, ikke ECC. Hvis arbejdsbyrden er træning, tjener ECC sin pris. Vi sælger begge dele og fortæller dig det samme i telefonen.

System-RAM: Hvor meget, og sandheden om CPU-offload

System-RAM gør fire ting i en AI-server:

1. Stages modelindlæsning fra disk til VRAM. En 70B-modelfil flytter NVMe → sidecache → system-RAM → VRAM. Hvis system-RAM'en er mindre end filen, vil indlæsningen enten mislykkes eller gå i vasken.
2. Understøtter operativsystemet, inferensserveren (vLLM, llama.cpp, Triton) og hjælpetjenester (vektor database, overvågning, anmodningskø).
3. Indeholder tokenizer-tilstand, anmodningskøer og buffere for/efterbehandling.
4. Værter eventuelt CPU-aflastede lag. Det er dette, folk overvurderer.

CPU-offload, i llama.cpp og lignende runtime-programmer, lader dig køre en model, der er større end VRAM, ved at beholde nogle lag på CPU'en og streame dem gennem GPU'en pr. token. Det virker. I næsten alle realistiske tilfælde er det også en øvelse i elendighed.

Tal: En 5090 har 1.79 TB/s VRAM-båndbredde. En 12-kanals EPYC Genoa-platform med DDR5-4800 leverer ~460 GB/s samlet set. CPU-offload er optimistisk set 4-6 gange langsommere pr. token end fuld VRAM-residens — det forudsætter perfekt NUMA-lokalitet og en CPU, der ikke også er optaget af at betjene overhead.

Benchmarks fra en 4×5090 kasse med --n-gpu-layers tunet:

• Fuldt på GPU (70B INT4 på tværs af 4×24 GB): 28–32 tok/s single-stream.
• 80% på GPU, 20% på CPU: 6-9 tok/s.
• 50/50: 2–4 tok/s.

Dette er ikke en Kentino-mening. Det handler om, hvordan DDR5-båndbredde hænger sammen med GDDR7-båndbredde. Løsningen på "modellen passer ikke i VRAM" er flere eller bedre GPU'er, ikke system-RAM med offload. Undtagelsen er AMD Ryzen AI Max 300 unified-memory-platformen, et andet bæst og uden for rammerne her.

Køb nok system-RAM til at indlæse og servere, ikke til at beregne.

Hvor meget system-RAM, konkret

En arbejdsregel for K-AI-builds:

System RAM ≈ 1.5 × total VRAM, rounded to the next standard config.

For en 4-GPU-build:

For 8-GPU-builds er RAM-skalering ikke strengt lineær – hold dig inden for én sokkels kanaler, hvor det er muligt. Vi bruger som standard 256 GB på 8× 5090 og 512 GB på 8× Pro 6000 Blackwell.

Reglen har to fejltilstande ved kanterne:

• Underspecificeret: 64 GB på en 8-GPU-boks. Modellen indlæses langsomt, sidens cache kan ikke holde vægte til hurtig genindlæsning, og samtidig visning plus hjælpetjenester (pgvector, overvågning) begynder at bytte.
• Overspecificeret: 2 TB på en 4-GPU inferensboks. Det fungerer fint, men du har brugt €4,000-€8,000 på RAM, der sender sider. Undtagelsen er hosting af mange modeller og roterer dem VRAM↔RAM — så fungerer stor system-RAM som en hot cache. Sjælden uden for forskningslaboratorier.

"64 GB er nok"-tilfældet eksisterer: en maskine med 2 GPU'er, én model ad gangen, ingen samtidighed, ingen hjælpetjenester. Ikke en seriøs server, men en seriøs udviklerarbejdsstation.

EPYC-kanaler: hvor båndbredden rent faktisk kommer fra

System-RAM-båndbredden på AMD EPYC (grundlaget for næsten alle vores 8-GPU-servere) skaleres med antallet af udfyldte hukommelseskanaler, ikke den overordnede DIMM-hastighed. Kanalerne er pr. sokkel, udfyldt med én DIMM pr. kanal.

To ting fra denne tabel:

1. Udfyld alle tolv kanaler på en EPYC Genoa/Torino-platform for at få den annoncerede båndbredde. Otte DIMM'er i et tolvkanalssystem giver otte kanalers båndbredde, ikke tolv. Vi ser dette fejlkonfigureret konstant i felten.
2. DIMM-antallet bestemmer den mindste fornuftige RAM-størrelse. 12 × 16 GB = 192 GB. 12 × 32 GB = 384 GB. De "pengesparende" konfigurationer, der ikke bruger så meget (seks 32 GB DIMM'er til 192 GB), efterlader halvdelen af ​​båndbredden på bordet. Gør ikke dette.

Dobbelt sokkel giver i alt 24 kanaler; båndbredden fordobles samlet set, men kun hvis arbejdsbyrden respekterer NUMA.

NUMA: omkostningerne ved at krydse linjen

En EPYC-server med to sokler har to CPU-chips, hver med sine egne hukommelsescontrollere, DIMM-slots og PCIe-rootkompleks. Overgangen fra den ene sokkels hukommelse til den anden sokkels GPU krydser Infinity Fabric – hurtigt, men ikke så hurtigt som at forblive lokal.

Grove, men brugbare tal:

Til slutning er NUMA-straf normalt usynlig – når modellen er i VRAM, er system-RAM-trafikken en lille smule. NUMA er vigtig, når:

• Indlæser en model. En indlæsning på 100 GB fra den forkerte node tager mærkbart længere tid. Bind med numactl eller indstil affinitet i din container-kørselstid.
• CPU-side forbehandling (tokenisering i stor skala, billeddekodning, lyd-resampling). En travl tokenizer på socket 0 med GPU'er, der hænger ud for socket 1, mister 20-40% gennemløbshastighed.
• Træning med CPU-offloaded optimizer-tilstand (DeepSpeed ​​Zero-Offload). NUMA-fremmedtilstand fordobler trintiden. Fastgør alt.

Praktisk svar: standard til single-socket for inferensservere medmindre du har en specifik grund til at vælge dual. Dual-socket findes i vores sortiment (K-AI 256 Turin Dual), fordi nogle arbejdsbelastninger - samtidig træning plus inferens, store vektorlagre i hukommelsen, otte GPU'er, der kræver to rodkomplekser - faktisk har brug for det. De fleste har ikke. Single-socket Turin med 12 kanaler og 384-512 GB håndterer de fleste inferens-use cases.

DDR5 RDIMM vs. LRDIMM og ECC

Server-RAM i 2026 er ensartet DDR5 ECC. Valget er RDIMM vs. LRDIMM:

• RDIMM (registreret): Standard serverhukommelse, bufferet kommandosti, ECC inkluderet. Ryd op til 64 GB moduler, 128 GB på nogle platforme.
• LRDIMM (Load-Reduced): Tilføjer en hukommelsesbuffer, der reducerer busbelastningen, hvilket muliggør højere kapacitet pr. kanal. Kræves til moduler på 128 GB+. Lidt højere latenstid, marginal i reelle arbejdsbelastninger.

Kentino-standard: 32 GB eller 64 GB RDIMM'er ved DDR5-4800 (Genoa) eller DDR5-6000 (Turin). LRDIMM kun, når build'et kræver 1 TB+, sjælden ekstern træning eller hosting med flere modeller. ECC er ikke til forhandling — ikke-ECC-server-DIMM'er findes ikke i de platforme, vi leverer.

Hvad går i stykker, når hukommelsen er forkert

Forudsigelige fejltilstande, i omtrentlig rækkefølge efter hyppighed:

• Langsom modelindlæsning på underspecifikation af RAM. En 70B-model har ~40 GB på disken. Med 32 GB system-RAM ødelægger indlæsning sidens cache, og en 40-sekunders koldstart bliver til 4 minutter. Rettelse: Minimum 1.5× samlet VRAM.
• Halv båndbreddestraf fra underbefolkede DIMM-kanaler. Seks DIMM'er i en tolvkanals EPYC. CPU-bundet forbehandling halveres lydløst. Rettelse: Udfyld alle kanaler.
• NUMA-fremmed adgang på dobbeltsocket med uoverensstemmende affinitet. Fix: numactl --cpunodebind=0 --membind=0, eller frameworkets NUMA-bevidste tilstand.
• OOM ved høj batch på undervurderet KV-cache. vLLM'er --gpu-memory-utilization 0.9 efterlader 10% headroom, men 64-concurrent ved 32K kontekst overløber stadig et 24 GB kort. Rettelse: kortere kontekst, mindre batch eller mere VRAM.
• CPU-offload "redder" build'en og ødelægger gennemløbshastigheden. "Serveren er langsom" — det viser sig, at 30% af lagene sidder på CPU'en, fordi VRAM var stram. Størrelsesfejl, ikke justering. Køb det rigtige GPU-antal på forhånd.

Ingen af ​​disse er eksotiske. Alle dukker op i den første måned efter en ny installation.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.