Casestudie: 4x RTX 4090 AI-arbejdsstation

Denne artikel dokumenterer en komplet byggeproces bestilt til en forskningskunde, der havde brug for en rackmonterbar, 24/7-kompatibel LLM-inferensarbejdsstation med tilstrækkelig VRAM til at hoste modeller i 70B-klassen uden cloudafhængighed. Alt her er målt på den faktiske hardware. Ingen syntetiske estimater, ingen marketingtal.

Byggeriet blev idriftsat og leveret i april 2026. Idriftsættelsesbenchmarks blev udført den 10. april 2026.

Hvorfor 4× RTX 4090

Arbejdsbyrdekravet var klart fra starten: Kør en kvantiseret 70B LLM med brugbar single-request latency, håndtering af samtidige anmodninger i et lille forskerteam, og hold alt on-prem af hensyn til datakontrol. Spørgsmålet var, hvor mange GPU'er af hvilken slags.

En 70B-model ved INT4 (AWQ eller GGUF Q4_K_M) optager i praksis cirka 38-40 GB VRAM. Det eliminerer løsninger med én GPU fuldstændigt – selv et RTX 4090 på 24 GB kan ikke hoste modellen alene. Du har brug for mindst to, og helst fire, så tensor-parallel servering under vLLM har plads til KV-cachen.

Fire RTX 4090-kort giver 96 GB VRAM i alt. Det er nok til at fylde en Llama 3.3 70B AWQ INT4-model med gpu_memory_utilization=0.80 og stadig have betydelig KV-cacheplads til batch-anmodninger. Det giver også beregningskapacitet — 4× 128 SM-chips, der kører samtidigt — hvilket er vigtigt for hurtig behandlingshastighed.

Det overvejede alternativ var 4× RTX Pro 6000 Blackwell, hvilket ville give 4× 96 GB = 384 GB VRAM. Det er et helt andet niveau: mere VRAM end nogen enkelt 70B-model har brug for, egnet til at køre flere store modeller samtidigt eller hoste modeller i 200B+-klassen ved rimelig kvantisering. Til denne arbejdsbyrde - én primær model, lille samtidig batch, på et budget med en enkelt arbejdsstation - ville den ekstra kapacitet stå ubrugt, og omkostningsforskellen er betydelig. 4× RTX 4090 var det rigtige svar til den angivne use case.

Et 8× L40-alternativ findes også i serien. L40 giver 48 GB VRAM pr. kort, ECC-understøttelse og er designet til vedvarende datacenterbelastning. For denne kunde krævede arbejdsbyrden ikke pålidelighedskontrakter i datacenterklassen, L40's mangel på driver-særheder i forbrugerklassen var en mindre fordel, og budgettet rakte ikke dertil. Værd at vide som en opgraderingsmulighed.

Én arkitektonisk grænse at nævne på forhånd: RTX 4090-kort har ingen NVLink. Al GPU-til-GPU-kommunikation sker via PCIe peer-to-peer. Dette er meningsfuldt for tensor-parallel inferens (diskuteret i benchmark-afsnittet) og værd at forstå, før du bestiller. Se N03 for en fuldstændig gennemgang af, hvornår NVLink er relevant, og hvornår det ikke er relevant.

Hardware Specifikationer

Et par bemærkninger om valgene:

CPU. EPYC 7542 er en 32-kernet Rom-generationschip med 128 MB L3-cache på tværs af 8 CCD'er. For en inferensarbejdsstation er dette overdimensioneret med hensyn til rå kerneantal - du vil ikke mætte 64 tråde på ren inferens. Hvor den fortjener sin plads er i PCIe-banebudgettet: Rome EPYC leverer 128 PCIe 4.0-baner fra CPU'en, hvilket er grunden til, at du kan placere fire fulde x16 GPU'er på denne platform uden banedeling eller bifurcation. RTX 4090 er en PCIe 4.0 x16-enhed; du vil have fire fulde x16-slots, og EPYC leverer dem. Se W02 for detaljer om banetopologien.

VÆDDER. Systemet blev leveret med 512 GB DDR4 ECC LRDIMM, hvilket oversteg de oprindeligt specificerede 256 GB. Ekstra system-RAM er virkelig nyttig her: modelindlæsning fra NVMe foregår via system-RAM før overførsel til VRAM, og for større modeller eller når man skifter mellem modeller, betyder 512 GB, at man kan holde flere modelvægtsæt i RAM samtidigt og undgå gentagne NVMe-læsninger.

NVMe. Modellager (2 TB) findes på et højhastigheds-PCIe 4.0 NVMe-drev. Sekventiel læsehastighed er vigtig ved indlæsning: en 38 GB modelfil med 4,589 MB/s indlæses sekventielt på cirka 8-10 sekunder. Målte indlæsningstider bekræfter dette: llama.cpp indlæste 70B Q4_K_M GGUF på 10.8 sekunder; vLLM (som også bygger CUDA-grafer ved indlæsning) tog 95 sekunder.

Dobbelt strømforsyning. Chassiset bruger to ATX-strømforsyningsenheder. Dette er delt strømforsyning: hver strømforsyning forsyner en del af systemet - typisk to GPU'er og tilhørende kortkomponenter hver. Hvis én strømforsyning svigter, mister du GPU'erne på dens skinne. Dette er ikke N+1 redundans; det er en strømkapacitetsordning, ikke en failover-ordning. For produktionssystemer, hvor oppetid er kontraktmæssig, er denne sondring vigtig. Se W04 for den fulde diskussion om strømforsyningsstørrelse.

Chassis luftstrøm. Chassiset er rackmonteret med industriel front-til-bag-rettet luftstrøm. GPU'erne er ikke åbne; de ​​sidder i en rettet luftstrømskanal med kabinetblæsere, der trækker luft hen over køleplader og blæser ud bagfra. Dette gør systemet velegnet til 24/7 vedvarende drift i et rackmiljø. Se W05 for termiske designdetaljer.

Software stak

Python-miljøet lever på /home/logic/llm-env/, modeller på NVMe hos /mnt/nvme/models/.

Idriftsættelsesresultater

GPU-beregningsgrundlinje

Den første test er altid rå beregning: matrixmultiplikation ved FP16 (Tensor Core-sti) og FP32. Dette bekræfter, at kortene fungerer korrekt, og giver en beregningsbasislinje til sammenligning med nominelle specifikationer.

Til reference: RTX 4090s teoretiske FP16 Tensor Core-peak er ~330 TFLOPS, FP32 ~82.6 TFLOPS. Benchmark-tallene på ~52% af FP16-peak er forventede - målingen er en sustained-throughput-matmul, der ikke opnår den teoretiske peak for en håndjusteret GEMM-kerne. De bekræfter, at alle fire Tensor Core-arrays fungerer og er konsistente.

GPU 1 er ~6% lavere på FP16 end de andre. Dette er normal variation i silicium inden for samme bin. Ingen hardwarefejl.

GPU-hukommelsesbåndbredde

VRAM-båndbredden på 920 GB/s er i overensstemmelse med RTX 4090-specifikationen (1,008 GB/s peak; gapet er benchmark-overhead). Dette båndbreddetal er det, der betyder noget for dekodningsgennemstrømningen: hver genereret token kræver indlæsning af hele sættet af KV-cache og vægttensorer fra VRAM, så båndbredden sætter direkte loftet for, hvor hurtigt du kan generere.

GPU-til-GPU-tallet (19-22 GB/s over PCIe peer-to-peer) er den arkitektoniske begrænsning, der er relevant for tensor-parallel servering. Med NVLink kører denne sti med 900 GB/s. Med kun PCIe får du cirka 2% af det. Dette er ikke katastrofalt for inferens - det meste af den tensor-parallelle kommunikation på en 70B AWQ INT4-model på tværs af 4 GPU'er passer inden for, hvad PCIe kan håndtere - men det undertrykker dekodningshastigheden for enkeltforespørgsler sammenlignet med et NVLink-tilsluttet system. Se benchmark-afsnittet nedenfor, og N03 til den bredere diskussion.

Én anomali: Båndbredde fra enhed til vært målt til 1.4 GB/s, langt under de forventede ~26 GB/s for PCIe Gen4 x16. Dette er en kendt CUDA-adfærd med ikke-fastgjort hukommelse. Hvis din applikation ofte flytter data fra GPU til vært (f.eks. sampling fra output-logits i en brugerdefineret pipeline), skal du bruge torch.pin_memory() eller forudalloker fastlåste buffere. Standard vLLM- og llama.cpp-serveringspipelines udløser ikke denne sti i hot loop'en.

Alle PCIe-links bekræftede Gen4 x16 (16 GT/s) under belastning. Ved inaktiv bruger driveren ASPM-strømbesparelse, og linkene falder til Gen1 (2.5 GT/s) — dette er normalt og ikke en lednings- eller riserfejl.

NVMe-opbevaring

Dette er stærke NVMe-tal for et PCIe 4.0-drev til forbrugere/prosumere. For modelserver er det relevante tal sekventiel læsning: 4,589 MB/s betyder, at en 38 GB-model indlæses i RAM på cirka 8-9 sekunder før enhver VRAM-overførsel. De 568K tilfældige IOPS er mere relevante, hvis du kører en hentningspipeline (RAG, vector store), hvor arbejdsbyrden er mange små tilfældige læsninger - dette drev håndterer det uden at blive flaskehalsen.

vLLM Inference — Llama 3.3 70B AWQ INT4

Dette er den centrale benchmark. Model: casperhansen/llama-3.3-70b-instruct-awqServering: vLLM 0.19.0 med tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

Afkodningshastigheden på 8.0 tok/s for enkeltforespørgsler kræver kontekst. vLLM 0.19.0 kørte AWQ-modellen med awq kerne, ikke awq_marlin. Det awq_marlin Kernen er den hurtigste vej til AWQ på Ada Lovelace (RTX 4090) og Blackwell GPU'er — benchmarknoterne indikerer, at den ikke blev valgt under denne idriftsættelseskørsel, og forbedringen forventes at være 2-3 gange på enkeltforespørgsels dekodningshastighed. Med awq_marlin, den samme model på den samme hardware burde nå cirka 16-24 tok/s single-stream.

Aggregatet på 179.3 tok/s på 32 samtidige anmodninger er det mest produktionsrelevante tal. Dette er, hvad et lille team, der rammer endpointen samtidigt, vil se som kombineret systemoutput. Kontinuerlig batching i vLLM betyder, at samtidige anmodninger amortiserer KV-cachen og opmærksomhedsberegningen på tværs af batchen, hvilket er grunden til, at 32 gange brugerforsinkelsen ikke producerer 32 gange latenstiden.

Latenstiden på 2,043 ms på en anmodning med 16 tokens er TTFT-grænsen (time-to-first-token) under vLLM på denne konfiguration. For interaktive brugsscenarier (chat, kodeassistance) er dette i den langsommere ende. Hoveddriveren er tensor-parallel scatter/gather overhead på tværs af fire GPU'er over PCIe - hvert prefill-trin kræver en AllReduce på tværs af alle fire kort via PCIe-strukturen. Med NVLink ville dette være cirka 50-100 ms TTFT; med PCIe P2P ved 20 GB/s strækker det sig yderligere. Dette er den direkte omkostning ved arkitekturen uden NVLink på latensfølsomme enkeltforespørgsler (se N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Model: Llama-3.3-70B-Instruct-Q4_K_M.ggufBackend: llama-cpp-python 0.3.20 med CUDA/cuBLAS, alle lag overført til GPU.

llama.cpp leverer cirka 20 tok/s ved single-stream-dekodning — bedre end det nuværende vLLM AWQ-tal og kan tilskrives llama.cpps cuBLAS-baserede kernesti, der fungerer godt med Q4_K_M-kvantiseringen. llama.cpp understøtter ikke samtidig batching af flere samtidige anmodninger på samme måde som vLLM gør, så 20 tok/s er et loft pr. session, ikke samlet kapacitet. For interaktive arbejdsgange for én bruger er llama.cpp ved 20 tok/s en behagelig læsehastighed for engelsk output.

Promptbehandlingshastigheden på 1,568 tok/s er høj. Dette måler, hvor hurtigt modellen kan indtage prompten (forudfyldningsfasen). Hurtig forudfyldning er vigtig, når du kører en model på lange systemprompter eller dokumentkontekst. Ved 1,568 tok/s behandles en dokumentkontekst på 4,000 tokens på under 3 sekunder, før genereringen begynder.

For økonomi og sammenligning med cloud-alternativer, se T01 (tok/s pr. euro) og T02 (pris pr. million tokens on-prem vs. cloud).

Hvad de to motorer er til for

Stresstest — Vedvarende belastning

Tre 60-sekunders stresstest blev kørt for at verificere termisk og elektrisk stabilitet under maksimal belastning: GPU-kun-brænding, CPU-kun-brænding og kombineret GPU+CPU-brænding.

GPU-brænding (FP16 matrixmultiplikation ved 100%, 60 s)

Nul beregningsfejl på tværs af alle fire GPU'er. Temperaturerne steg fra ~28°C som baseline til et stabilt plateau efter 40 sekunder. GPU 2 kørte varmest ved 72°C - det er det varmeste kort i kabinettets luftstrømsbane på den position. Den termiske drosselstærskel på RTX 4090 er 83°C; den højeste målte temperatur (72°C) efterlader en margin på 11°C. Systemet droslede ikke på noget tidspunkt.

Strømgrænserne blev sat til forskellige værdier på tværs af de fire kort (480 W, 450 W, 500 W, 480 W). Dette er en mindre uoverensstemmelse, der bør normaliseres: nvidia-smi -pl 480 -i 0,1,2,3 (eller hvilken grænse der end måtte være passende) at fastsætte ensartede lofter før produktionsbrug.

Kombineret GPU + CPU-brænding (alle 4 GPU'er + 64 CPU-tråde samtidigt, 60 sek.)

Tilføjelse af 64 CPU-tråde ved 100% belastning reducerede den samlede GPU TFLOPS med kun 0.6%. EPYC 7542 bruger cirka 200 W TDP ved fuld belastning; det kombinerede system kørte i alt med cirka 2.1-2.2 kW. Alle temperaturer forblev inden for marginen: GPU 2 toppede ved 73°C under kombineret belastning, stadig 10°C under throttle-grænsen.

Den gennemsnitlige belastning nåede 55+ under CPU-brændingsfasen (forventet for 64 tråde). Systemet var fuldt stabilt hele vejen igennem; ingen termiske hændelser, ingen beregningsfejl, ingen kernelpanik.

Dette bekræfter, at systemet er egnet til vedvarende inferensbelastninger døgnet rundt, hvor CPU'en også er optaget (forbehandling, tokenisering, overhead af servering af infrastruktur).

Hvad fungerede godt

EPYC-platformen. PCIe-lanebudgettet er virkelig løst. Alle fire RTX 4090-kort kører ved fuld Gen4 x16 under belastning (bekræftet i 04d PCIe-statuskontrol). Ingen bifurcation, ingen forringede slots. Nogle AMD Ryzen-builds med fire GPU'er kører to eller flere slots ved x8; ​​på EPYC Rome er dette ikke tilfældet.

VÆDDER. 512 GB er behageligt. Under indlæsning af llama.cpp-modellen bliver den 38 GB store GGUF-fil hukommelseskortlagt; med 512 GB tilgængelighed kan du køre flere processer sideløbende med LLM-serveren uden at konkurrere om hukommelse.

NVMe sekventiel hastighed. 4,589 MB/s sekventiel læsning holder indlæsningstiderne korte. På en modeliterationsworkflow – indlæsning, testning, skift af modeller – løber dette op i løbet af en dag.

Termisk tøj. Værst tænkelige vedvarende temperatur på 73°C (GPU 2, kombineret brænding) med 10°C headroom. I en typisk inferensarbejdsbelastning vil GPU'er ikke køre kontinuerligt med 100% udnyttelse - afkodning er VRAM-båndbreddebundet, ikke beregningsbundet - så de reelle driftstemperaturer vil være lavere end stresstestens peak.

llama.cpp 1,568 tok/s prompt evaluering. Dette tal overraskede os på den positive side. cuBLAS-forudfyldningsstien på fire 4090'ere er hurtig. Langkontekstapplikationer drager fordel af dette.

Hvad der overraskede os

vLLM AWQ-kernen fejler. Benchmarken kørte med awq kerne i stedet for awq_marlinIdriftsættelsespakken udløste dette automatisk baseret på den daværende modelkonfiguration. Med awq_marlin, forventes det, at single-request-gennemstrømningen vil stige fra 8 tok/s til 16-24 tok/s. Dette er en softwarekonfigurationsrettelse, ikke en hardwarebegrænsning – bekræft din vLLM-kvantiseringsmetode, når du konfigurerer produktionsvisning.

D2H båndbredde. Enhed-til-vært-hastighed på 1.4 GB/s overraskede os under den indledende analyse. Det er en CUDA ikke-fastgjort hukommelsesadfærd, ikke en PCIe-fejl. For standard serving stacks (vLLM, llama.cpp) er det ligegyldigt. For brugerdefineret inferenskode, der flytter tensorer til CPU'en til efterbehandling, skal du bruge fastgjorte hukommelsesallokeringer.

GPU 3 PCIe AER rettede fejl. Under vLLM-benchmarken loggede GPU 3 (bus c1:00.0) korrigerede PCIe-fejl (RxErr + BadTLP). Disse blev automatisk hardwarekorrigeret og påvirkede ikke beregningen. Sandsynlig årsag: PCIe-riser-placering eller linkgenforhandling ved Gen4-hastighed. Anbefalingen er at overvåge under vedvarende produktionsbelastning; hvis antallet af fejl stiger, skal GPU 3-riserkablet genindsættes. Nul fejl under selve stresstestene.

Kort NIC-linkflap. Netværksgrænsefladen gik kortvarigt ned og kom tilbage under GPU-benchmarkbelastning (13:38 UTC). Sandsynligvis en strømtransient fra samtidig GPU-opstart. I produktion med nvidia-persistenced kører (hvilket holder GPU-kontekster initialiseret), er strømtransienter ved indlæsning og start mindre. nvidia-persistenced som en systemd-tjeneste før produktion.

Hvad vi ville gøre anderledes med v2

Aktiver awq_marlin fra starten. Bekræft vLLM-kvantiseringskernestien under idriftsættelse, ikke efter. Tilføj en kerneidentitetskontrol til idriftsættelsesscriptet.

Normaliser GPU-strømgrænser før benchmarking. De fire kort blev leveret med forskellige konfigurerede grænser (480 W, 450 W, 500 W, 480 W). Indstilling af en ensartet grænse (nvidia-smi -pl) før den første benchmark-kørsel giver renere og mere sammenlignelige tal og undgår det inkonsistente strømforbrug under kombineret forbrænding.

Tilføj en overvågningsstak ved levering. Prometheus med DCGM-eksportøren plus Grafana tager et par timer at konfigurere og gør GPU-temperatur, VRAM-udnyttelse og PCIe-fejlrater synlige i realtid. Send dette som en del af standard idriftsættelsen i stedet for at lade det være en opgave efter levering. Se L05 for opsætningsvejledningen til stakken.

Pin (Binding) nvidia-persistenced i systemd-enhedsfilen under opsætningen af ​​operativsystemet. Det er en one-liner, men bliver konsekvent overset. Uden den tager den første GPU-belastning efter en stille periode et par ekstra sekunder og producerer den strømtransient, der forårsagede NIC-flappen.

LVM-udvidelse. OS-disken (512 GB SATA) har kun 100 GB allokeret til LVM-partitionen. De resterende 374 GB er ikke allokeret. Der er ingen grund til at lade den stå: lvextend og resize2fs tag 30 sekunder og giv dig den plads tilbage til OS-overhead, logs og Docker-lag.

Overvej en anden NVMe til modellagring. Den enkelte 2 TB NVMe rummer i øjeblikket alle modeller og vil blive fyldt op, efterhånden som modelbiblioteket vokser. En anden 4 TB NVMe i RAID 0 eller blot som en separat /mnt/nvme2 Mount ville tilføje fleksibilitet og holde sekventiel læseydelse høj på tværs af et større samlet bibliotek.

Sammenligning: Alternativer til denne version

Kundens arbejdsbyrde kunne have været håndteret med andet hardware. Her er en ærlig sammenligning:

4× RTX 4090 på 96 GB er den minimalt mulige konfiguration til at køre Llama 3.3 70B AWQ INT4 under vLLM med en meningsfuld batch-gennemstrømning. Det er ikke grænsen; en 8-GPU-build tilføjer kapacitet proportionalt. For en forskningskunde, der ønsker en enkelt dedikeret arbejdsstation – ikke en serverklynge – er 4× ofte det rigtige sted at starte.

Hverken 4×- eller 8×-konfigurationen har NVLink mellem GPU'er, hvilket betyder, at tensor-parallel inferens fungerer over PCIe. Den praktiske konsekvens er TTFT-latens for enkeltstående anmodninger, ikke den samlede batch-gennemstrømning. For en arbejdsbelastning på teamstørrelse (tiere af anmodninger i timen, ikke tusinder) er dette ikke en begrænsende faktor. For TTFT-krav under 100 ms, se N03 og begrundelsen for, hvorfor serien er rettet mod PCIe-tilsluttet multi-GPU snarere end NVSwitch fabric-systemer.

Total strøm- og elplanlægning

Under vedvarende GPU-belastning var den samlede systemeffekt cirka 1,900-2,200 W målt ved GPU-skinnerne (1,914 W GPU-alene-forbrug; ~2,100 W estimeret kombineret med CPU, drev, kort). Tag højde for strømforsyningens effektivitetstab (antag 90%), og planlæg et minimum på 16 A/230 V kredsløb, hvor 20 A foretrækkes til headroom.

Layoutet med to strømforsyninger deler dette på tværs af to udgange. Begge udgange skal være på kredsløb, der uafhængigt kan håndtere belastningen: hvis strømforsyning A forsyner to GPU'er med 500 W hver plus 200 W kort/CPU, er det 1,200 W på dens kredsløb. Størrelsen skal tilpasses.

Budget for rumkøling: Betragt dette system som 2.5 kW vedvarende (konservativt, inkluderer effektivitetstab og en margin). For et serverrum eller rackkabinet med flere systemer vil det samlede tal hurtigt blive forøget.

Se P01 for overvejelser om enfaset vs. trefaset og P04 til dimensionering af afbryder.

Prisbånd

En build med denne specifikation — EPYC 7542 platform, 512 GB ECC RAM, 4× RTX 4090, 2 TB NVMe, rackkabinet med dobbelt strømforsyning — falder inden for kategorien 18,000–24,000 € ekskl. moms sortiment til aktuelle komponentpriser, afhængigt af chassisvalg, RAM-sourcingtiming og GPU-tilgængelighed. Leveringstiden er 10-28 dage afhængigt af komponenttilgængelighed, bekræftet ved bestilling.

Dette udvalg inkluderer ikke installation, rack-PDU, netværk (10 GbE-switch, kabelføring) eller nogen form for softwarelicens. Systemet leveres med Ubuntu 24.04 LTS forudinstalleret og Python venv forudkonfigureret; medbring dine egne modelvægte.

Hvad denne bygning er egnet til

• Forskning og LLM-inferens i små teams. Kørsel af en 70B-model for et team på 5-15 brugere. Aggregatet på 179 tok/s under vLLM håndterer samtidige sessioner komfortabelt.
• Modelevaluering og iteration. Hurtige NVMe-indlæsningstider betyder, at det er hurtigt at skifte mellem kandidatmodeller. EPYC-platformens PCIe-lanebudget betyder, at alle fire GPU'er altid er på fuld båndbredde.
• Datasuveræne implementeringer. Al inferens er lokal. Ingen tokens forlader bygningen. Dette er den primære ikke-økonomiske grund til at køre on-prem i forskningssammenhænge.
• Budgetbevidst 70B indgangspunkt. RTX 4090 er den forbruger-GPU med det højeste VRAM på markedet. Med 24 GB pr. kort og fire kort, får du med 96 GB i alt 70B-klassen uden at skulle gå op til professionelle GPU-priser.

Hvad denne bygning ikke er egnet til

• TTFT med én anmodning på under 100 ms. PCIe P2P tensor-parallel topologien sætter en bund for TTFT til store modeller. Hvis du har brug for hurtig interaktiv latenstid på modeller over 70B, er denne arkitektur det forkerte valg. Du ønsker NVLink-tilsluttede GPU'er, hvilket betyder en helt anden klasse hardware (se N03).
• Kørsel af flere store modeller samtidigt. Ved 96 GB samlet VRAM med gpu_memory_utilization=0.80, har du cirka 77 GB brugbar hukommelse. En anden 70B INT4-model ville ikke passe. Hvis du har brug for at hoste to modeller samtidigt, skal du opgradere til en platform med mere VRAM pr. GPU eller flere GPU'er.
• Servering i stor skala. For hundredvis af samtidige brugere eller SLA-baseret oppetid er denne arkitektur (ingen NIC-tilføjelser på et 4-GPU-kabinet, single-node, forbruger-GPU'er med ECC slået fra) ikke det rette fundament. 8-GPU K-AI-serveren med L40 eller RTX Pro 6000 Blackwell, korrekt overvågning og to NIC'er er det.
• Træning af store modeller. Med 96 GB samlet VRAM kan du finjustere (LoRA, QLoRA) på 70B-modeller, men du kan ikke fuldt parametertræne dem. Til træning er VRAM-budgettet mere begrænset end til inferens. Hvis træning er en del af arbejdsbelastningsplanen, skal du tage dette i betragtning.

---

Dette er en del af Kentino Wiki, C-serien (Casestudier). Byggedata målt 2026-04-10. Artikel udgivet 2026-05-15. Rettelser og opfølgende målinger er velkomne på info@kentino.com.