Referencebyggeri: Et robot- + AI-laboratorium i ét rack

Artiklerne før denne beskriver arkitekturen, softwarestakken, strømforbruget og netværksdesignet. Denne sætter en pris og en stykliste på det hele – taget fra den reelle hardware, som Kentino har leveret og benchmarket, ikke en teoretisk stykliste samlet fra et marketingark.

Implementeringsmålet er et forsknings- eller integrationslaboratorium, der kører en til fire robotter sammen med on-prem inferens og en træningsbane. Mellemstor: ikke en hobbyboks, der knap nok kan betjene en 7B, ikke en hyperskala-klynge, der kræver et facilitetsteam. Et seriøst arbejdsmiljø, som et team på to til seks personer kan etablere, drive og udvikle uden dedikeret DevOps.

Artiklen dækker to niveauer af det samme arkitekturmønster. Udviklingsniveauet med 4 GPU'er er der, hvor de fleste laboratorier starter. Produktionsniveauet med 8 GPU'er er der, hvor de lander efter den første rigtige arbejdsbyrde. Hardwarevalgene er forskellige; arkitekturen er identisk.

Hvad flådedataene viser

Kentino har implementeret en flåde af ensartet konfigurerede 4-GPU computernoder. Hver enhed har den samme specifikation: AMD EPYC 7542 (32 kerner / 64 tråde, 2.9 GHz boost), 512 GB DDR4 ECC LRDIMM ved 2666 MT/s på tværs af otte DIMM'er, fire RTX 4090 GPU'er (24 GB VRAM hver, 96 GB i alt), et 2 TB NVMe scratchdrev og en 512 GB SATA SSD til operativsystemet. Bundkortet er ASRockRack ROMED8-2T/BCM. Ubuntu 24.04 LTS, kerne 6.8.0-generisk, NVIDIA driver 590.48.01, CUDA 13.1/13.2.

Alle ti noder producerer identiske benchmark-numre. Det er ikke en tilfældighed – det er pointen med en referencebuild. Når hver enhed forlader den samme konfiguration, er benchmarken en specifikation, ikke et heldigt løb.

GPU-beregning

FP16 tensor-core matmul på tværs af de fire kort (8192 × 8192 arbejdsbyrde):

GPU 1 kører cirka 6% lavere end GPU'erne 0, 2 og 3 – inden for det normale silicium-lotteri-spænd for forbrugerkort. Alle fire bestod 60 sekunders GPU-burn og kombineret GPU+CPU-burn med nul beregningsfejl. Temperaturrummet er behageligt: ​​den termiske drosselstærskel for RTX 4090 er 83 °C, og det varmeste kort i flåden toppede ved 73 °C under samtidig GPU- og CPU-belastning. Der blev ikke observeret nogen drosling på nogen node.

En praktisk bemærkning om effektgrænser: Flåden leveres med grænser pr. kort, der er sat lidt anderledes (450 W, 480 W, 500 W afhængigt af slot). For vedvarende produktionsbrug udjævner normalisering af alle fire til 450 W det samlede forbrug og reducerer strømforsyningsubalancen. TFLOPS-straffen ved 450 W vs. 500 W er under 2% - ikke den asymmetriske skinnebelastning værd.

vLLM-inferens — Llama 3.3 70B AWQ

Benchmarket med vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

En vigtig advarsel: benchmarken brugte awq kvantiseringskerne, ikke awq_marlin. Det awq_marlin Stien på Ada Lovelace (RTX 4090) er 2-3 gange hurtigere for latenstid på én anmodning. Produktionsimplementeringer bør bruge awq_marlin eller FP8-stien under vLLM 0.20+, hvilket yderligere lukker hullet. Med awq_marlin, antallet af enkeltforespørgsler ovenfor bevæger sig fra ~8 tok/s til cirka 16-20 tok/s på disse kort – mere i overensstemmelse med, hvad brugerne oplever i praksis. Den samlede fordel ved batch-gennemstrømning er proportionalt mindre, fordi flaskehalsen ved høj samtidighed skifter til hukommelsesbåndbredde snarere end beregning.

Disse tal gælder for Llama 3.3 70B ved INT4 (AWQ). En 7B- eller 8B-model ved Q4 kører 4-6 gange hurtigere pr. token på den samme hardware; en 13B-model kører cirka 2.5 gange hurtigere. 70B-tallet er den relevante størrelsesbegrænsning for VLM og store planlægningsmodeller i en robotkontekst.

llama.cpp — enkeltbruger, ingen samtidighed

Benchmarket med llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, alle fire GPU'er:

llama.cpp indlæses hurtigere (10.8 sek. vs. 95 sek. for vLLM) og leverer højere dekodningshastighed for enkeltbrugere på disse kort, fordi det ikke betaler for den kontinuerlige batch-scheduler-overhead. Handlen er nul samtidighed - én bruger ad gangen. Den korrekte læsning af disse tal: llama.cpp på en 4-GPU-node giver en udvikler en responsiv 70B-model til interaktiv brug; vLLM er det rigtige valg, når du har mere end én klient.

Se I02 for den fulde serving-stack beslutningsmatrix. Den korte version: start med vLLM i Docker, brug awq_marlin kvantisering, og skift kun til llama.cpp for enkeltbruger-udviklingsbokse eller Jetson-implementeringer.

GPU-hukommelsesbåndbredde

Båndbredden fra enhed til enhed (på kortet) er konstant på 920.2-920.6 GB/s på tværs af alle fire kort - inden for 0.04% af hinanden, hvilket bekræfter, at GDDR6X ikke er variablen her. PCIe Host→Device-båndbredden lander på 26.2-26.3 GB/s, hvilket bekræfter, at Gen4 x16 forhandles fuldt ud under belastning (inaktiv linktilstand viser Gen1 på grund af ASPM-strømbesparelse - normalt, ikke en fejl). GPU-til-GPU-peer-overførsler over PCIe (ingen NVLink) måler 19-22 GB/s, hvilket er det forventede loft for peer-to-peer over et delt PCIe-rodkompleks uden NVLink (se N03 for kontekst).

NVMe-opbevaring

Sekventiel båndbredde er tæt på Gen4 x4-loftet. Tilfældige IOPS ved kødybde 32 mætter godt: 568K læse-IOPS er et godt stykke over, hvad LLM-vægtindlæsning eller datasætadgangsmønstre kræver ved enkeltnode-skala. Modelindlæsning fra NVMe til VRAM tager 10-30 sekunder afhængigt af modellens størrelse; dette drev er ikke flaskehalsen.

Referenceopbygningen

BOM — 4-GPU udviklingsniveau

Udviklingsniveauet er det rette udgangspunkt for et laboratorium, der kører en eller to robotter, en eller to aktive modeller og lejlighedsvis LoRA-finjustering ved siden af.

Udviklingsniveau: 4-GPU computing node + administreret ToR switch + 6 GHz AP + 5 kVA online UPS.

BOM — 8-GPU produktionsniveau

Produktionsniveauet fordobler antallet af GPU'er. Arkitektonisk mønster er det samme; CPU, RAM og chassis skaleres i overensstemmelse hermed for at understøtte otte PCIe-slots med fuld båndbredde. En AMD EPYC Genoa- eller Turin-platform leverer PCIe-lanebudgettet til 8× x16-slots uden kompromis med bifurkationen (se W02 ).

Bemærk: 25 GbE NIC-tilføjelsen er kun mulig på 8-GPU-kabinetter. 4-GPU-kabinettet har ikke plads til et ekstra NIC-kort — de 10 GbE onboard-porte på ROMED8-2T/BCM er den praktiske grænse på 4-GPU-niveauet (se N01 og reglerne på produktsiden).

Lagring ud over beregningsnoden

For udviklingsniveauet giver en 4-bay NAS med 4× 16 TB harddiske 48 TB brugbar ved RAID-5 – nok til et års episodedata for et laboratorium med 2 robotter. Tilslut den med 10 GbE til ToR-switchen; sæt den ikke på samme grænseflade som robottrafikken.

Strøm og køling til racket

Fra I04 :

Data fra flådens stresstest bekræfter, at 4-GPU-noden bruger ~1,914 W ved fuld GPU-belastning, hvor alle fire kort når deres effektgrænser. Tilføj CPU (~120 W vedvarende), NVMe og blæseroverhead, og noden lander på cirka 2.1-2.2 kW vedvarende.

Elektrisk installation til udviklingsniveauet: en 400 V 16 A trefaset forsyning er minimum; 32 A trefaset giver plads til vækst. Strømforsyningskabler på to separate faser. Se I04 og P02 for ledningslayout. Til produktionsniveauet (10 kW fuldt rack) skal du bruge en 400 V 32 A trefaset forsyning med mindst 15 kW kølekapacitet.

UPS-størrelse: størrelse kun til serveren, ikke robotterne. For udviklingsniveauet er en 5 kVA dobbeltkonverteret online UPS det mindst fornuftige valg. For produktionsniveauet er det 10 kVA. Angiv altid online dobbeltkonvertering. Se P05.

Softwarestak på bart metal

Softwarestak: fastlåst Ubuntu + NVIDIA-driver → containerværktøjssæt → vLLM + llama.cpp + nginx + overvågning.

Chaufførfastgørelse er ikke til forhandling. Flåden kører med chaufførnummer 590.48.01; apt-mark hold nvidia-driver-590 er det første, der gøres efter installation af et bare-metal OS. En uovervåget apt-get upgrade der henter en nyere driver, har ødelagt produktionsinferensen præcis så mange gange, som man ville forvente. Se L01 for den fulde procedure.

Overvågning er ikke valgfri. Flådedataene viser, at GPU 3 på én node havde korrigerbare PCIe AER-fejl (RxErr + BadTLP) under benchmarking – automatisk korrigeret af hardware, men synligt i DCGM-tællere. Uden overvågning dukker dette op som "lejlighedsvise mærkelige inferensfejl" uger senere. Tilslut DCGM, og indstil en alarm om korrigerbare ECC-fejl over en baseline-rate. Se L05 for Prometheus + Grafana-stakken.

Størrelsesvariationer

4-GPU-udviklingsniveauet — hvad det rent faktisk kan køre

96 GB VRAM i alt (4× 24 GB) med TP=4:

72B VLM passer ikke komfortabelt på 4× 24 GB ved INT4 — matematikken er tæt på, men kontekstvinduer ud over 4K overdriver det. Brug enten 32B VLM-varianten, eller opgrader til 8-GPU-niveauet eller en 4× RTX Pro 6000 Blackwell-node (96 GB VRAM hver) til 72B-klassen. Se W07 for diskussionen om VRAM vs. modelniveau.

Udviklingsniveauet håndterer: én 70B inferensmodel, der betjener 1-3 samtidige robotklienter, én VLM (32B-klasse) til visuelle forespørgsler og lejlighedsvis LoRA-finjustering på en mindre basismodel. Det dækker 80% af brugsscenarierne i robotlaboratorier i 2026.

8-GPU-produktionsniveauet — den ekstra headroom

192 GB samlet VRAM (8× 24 GB):

8-GPU-niveauet åbner også døren for samtidig servering af flere modeller: en 70B LLM på 4 GPU'er og en 32B VLM på de andre 4, der betjener en blandet robotflåde med forskellige modelkrav på samme tid, fra én boks. På 4-GPU-niveauet kræver dette et modelbyttetrin med 30-120 sekunders nedetid pr. bytte.

Bemærkning om TP=8 for en 70B: TP=8 over PCIe peer-to-peer (ingen NVLink) skalerer dårligere end TP=4 × PP=2 ved samtidighed over 8, fordi kommunikationsomkostningerne ved all-reduce vokser med tensorens parallelle grad. Benchmarkdataene viser en GPU-til-GPU PCIe-båndbredde på 19-22 GB/s - nok til TP=4, men TP=8 all-reduce ved høje batchstørrelser mætter disse links. Den anbefalede konfiguration for en 70B på 8× 4090 er TP=4 × PP=2, som vist i I02.

Rack-layout

Beregningsnoden sidder altid under switchen og UPS'en – front-til-bag-luftstrøm kræver, at den kolde luft kommer ind fra forsiden af ​​racket (kold gang eller rum-AC-forsyning), passerer gennem serveren og forlader den varme gang bagtil. Se W05 og I04 for luftstrømsdisciplinen.

Jump-værten er en 1U- eller small-form-factor-maskine med en DisplayPort-breakout, der bruges til initial opstart, driverinstallation og vedligeholdelse, når den primære server ikke kan nås via netværket. Den behøver ikke en GPU. En brugt arbejdsstation eller en lille 1U med 16 GB RAM og en Gen3 SSD er fint.

Hvad denne bygning ikke er

Ikke en stationær GPU-server i et rackkabinet. Den åbne tower-konstruktion til stationære computere – GPU'er monteret på et riserkort, intet kabinet, blæsere pegende mod loftet – er ikke det, der beskrives her. Desktop-konstruktioner er fine til udvikling; de er ikke klassificeret til vedvarende 24/7-drift og giver ikke den styrede luftstrøm fra forsiden til bagsiden, der holder GPU'erne ved en stabil driftstemperatur i ugevis.

Ikke en NVLink-klynge. RTX 4090 (forbruger-/arbejdsstationsklasse) har ikke NVLink. GPU-til-GPU-overførsler går over PCIe med 19-22 GB/s, ikke 900 GB/s. Dette er tilstrækkeligt til TP=4-inferensvisning, og det er en reel begrænsning for TP=8-træning. Hvis din arbejdsbyrde er tung distribueret træning på en 70B+-model, ændrer RTX Pro 6000 Blackwell (NVLink-kompatibel i sin multi-GPU-udgave) eller en platform med NVSwitch matematikken - men også prisen. Se N03.

Ikke redundante strømforsyninger. Konfigurationen med to strømforsyninger er delt strømforsyning: Strømforsyning A forsyner GPU'er 0 og 1 (plus bundkort), strømforsyning B forsyner GPU'er 2 og 3. Hvis strømforsyning A fejler, mister du to GPU'er og bundkortet. Intet fejler automatisk. Dette er en ærlig dobbeltstrømforsyning — den balancerer skinnebelastningen og reducerer risikoen ved enkeltpunkter i forhold til en enkelt stor strømforsyning, men det er ikke N+1 redundans. Se W04.

Ikke et cloud-alternativ til alt. Hvis dit laboratoriums primære arbejdsbyrde er et enkelt modelkald ti gange om dagen, retfærdiggør TCO-beregningen ikke on-prem. Denne build betaler sig af cloud-API-udgifterne, når du kører vedvarende inferens for flere klienter, finjusterer regelmæssigt eller opererer under begrænsninger for dataophold. Se T02 for den detaljerede beregning.

Hvorfor disse specifikke valg

AMD EPYC 7542 som CPU-vært. En 32-core EPYC leverer 128 PCIe 4.0-baner fra CPU'en alene, nok til 4× GPU'er ved x16 uden bifurcation, plus et NIC, lagerplads og en PCIe-switch til udvidelse. EPYC er standardplatformen for multi-GPU AI-servere i denne skala af en grund: Intel Xeon med samme kerneantal leverer færre PCIe-baner, hvilket tvinger bifurcation-kompromiser på 4+ GPU-konfigurationer. Se W02 for aritmetikken for baneantallet.

512 GB system-RAM. Flåden leveres med 512 GB (8× 64 GB), hvilket overstiger den nominelle specifikation på 256 GB. Dette er bevidst: indlæsning af store modeller under containeropstart, forhåndshentning af datasæt til træning og operativsystemets sidecache bruger alle RAM, som VRAM ikke kan. For vLLM med KV-cache-swapplads aktiveret kan system-RAM'en direkte bruges som overflow - 4 GB swapplads pr. GPU kræver 16 GB system-RAM-headroom. 512 GB giver denne headroom plads til Isaac Sim, som kan indeholde 10-30 GB simuleringstilstand i system-RAM under policytræning.

2 TB NVMe scratch. Benchmarken viser 4,589 MB/s sekventiel læsning – hurtigt nok til at indlæse en 70B FP8-model (~75 GB) på under 20 sekunder. For et laboratorium, der ofte udskifter modeller (udviklingsworkflow, A/B-testinferensstakke), er indlæsningstiden vigtig. En langsommere SATA SSD fordobler eller tredobler den tid pr. swap.

Luftstrøm i racket forfra og bagfra. Den mest almindelige fejl ved førstegangsopbygninger: desktop-orientering (sideindtag, topudstødning, bagudstødning) fungerer ikke i et forseglet rack. Beregningsnoden skal bruge rettet luftstrøm, der matcher rackets konvention for kold gang/varm gang. Se I01 og W05.

Den ærlige vurdering af hardware fra 2026

Dette er en referenceversion til maj 2026. RTX 4090 er ikke den nyeste Kentino GPU-mulighed — RTX 5090 (32 GB VRAM, Blackwell-arkitektur, sm_120) og RTX Pro 6000 Blackwell (96 GB VRAM) er tilgængelige og ændrer VRAM-per-kort-beregningen betydeligt. En 4-GPU-node med RTX Pro 6000 Blackwell giver 384 GB VRAM — nok til komfortabelt at hoste Qwen 2.5 VL 72B ved FP8 på fire kort — til en proportionalt højere pris pr. kort.

Hvad der ikke ændrer sig mellem generationer: det arkitektoniske mønster. AMD EPYC-vært, PCIe multi-GPU, front-to-back-chassis, dobbelt strømforsyning, Ubuntu 24.04, vLLM i Docker, Prometheus + DCGM-eksportør. Dette mønster har været ensartet på tværs af to GPU-generationer og vil overleve den næste. Reservedelslisten bliver billigere og hurtigere; mønsteret holder.

---

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.