Etterspørselen etter GPU-kraft har aldri vært høyere. Hver virksomhet, fra startups som deployer sin første AI-modell til store bedrifter som kjører tusenvis av inferens-endepunkter, trenger pålitelig og skalerbar GPU-infrastruktur. Men å bygge det riktig er langt vanskeligere enn bare å montere noen servere og håpe på det beste.

GPU-datasentre er fundamentalt forskjellige fra tradisjonelle compute-miljøer. Effekttettheten er 3-5 ganger høyere. Kjølebehovene er ekstreme. Nettverket må designes for massive dataflyt mellom GPU-er. Og orkestreringslaget må forstå maskinvaretopologi på et nivå som standard Kubernetes rett og slett ikke håndterer.

Hos ZeroSubnet har vi bygget denne stacken fra grunnen av, fra betonggulvet til Kubernetes-kontrollplanet. Dette innlegget går gjennom nøyaktig hvordan vi gjør det, og starter med en interaktiv visuell reise gjennom hele byggeprosessen.

Reisen: Fra tomt gulv til live infrastruktur

Klikk deg gjennom hvert kapittel nedenfor for å se et GPU-datasenter komme til live. Følg med mens bygget tar form, serverrack fylles med maskinvare, nettverksforbindelser pulserer med data, og Kubernetes tar kontroll over hele infrastrukturen.

Maskinvare-stakken

Den interaktive historien over gir deg det visuelle overblikket. Nå går vi dypere inn i de tekniske valgene bak hvert lag.

GPU-valg

Ikke alle GPU-er er like, og valget avhenger helt av arbeidsbelastningsprofilen din.

Akselerator

Best egnet for

Minne Interconnect

NVIDIA H100

General trening, inferens

80 GB HBM3

NVLink 4 — 900 GB/s

NVIDIA H200

Minneintensiv trening + lang kontekst inferens

141 GB HBM3e — 4,8 TB/s

NVLink 4 — 900 GB/s

NVIDIA B200

Frontier-trening og inferens- gjennomstrømming

192 GB HBM3e — 8 TB/s

NVLink 5 — 1,8 TB/s

NVIDIA GB200 NVL72

Rack-skala trening og inferens som én enhet

72 GPU-er, 13,5 TB HBM3e

NVLink-fabric — 130 TB/s samlet

AMD MI325X

Inferens på store modeller

256 GB HBM3e — 6 TB/s

Infinity Fabric

AMD MI355X

Frontier-trening, FP4/FP6-inferens

288 GB HBM3e — 8 TB/s

Infinity Fabric

Nøkkelen er å matche arkitekturen til arbeidsbelastningen, ikke å jage den nyeste modellen for sin egen skyld. For storskala trening i frontier-klassen behandler Blackwell-baserte GB200 NVL72-rack 72 GPU-er som ett enkelt NVLink-domene og reduserer det som tidligere krevde multi-rack InfiniBand-fabrikker til ett enkelt væskeavkjølt skap. For minneintensiv inferens med svært lange kontekster lar H200s 141 GB HBM3e-modeller passe helt på kortet som ellers ville krevd tensor parallelism på tvers av flere GPU-er. På AMD-siden gjør MI355X sin 288 GB HBM3e og native FP4/FP6-støtte den til et sterkt inferens-per-krone-alternativ for kunder som kan akseptere en yngre programvarestakk mot bedre prisytelse.

Nettverk: Den skjulte flaskehalsen

I et GPU-datasenter er nettverket ofte den begrensende faktoren, ikke GPU-ene selv. Distribuerte treningsarbeidsbelastninger må synkronisere gradients på tvers av titalls eller hundrevis av GPU-er, og enhver nettverksflaskehals påvirker treningstiden direkte.

Strøm og kjøling

En enkelt 8-GPU Hopper-server trekker 6 til 10 kW. En Blackwell-basert HGX-server går over 14 kW, og et fullt GB200 NVL72-rack lander på 120 kW, sammenlignet med 5 til 8 kW for et tradisjonelt compute-rack. Dette endrer datasenterdesign fundamentalt. Luftkjøling når grensen rundt 30 kW per rack. Væskekjøling er ikke lenger en luksus, det er den eneste måten å huse moderne AI-maskinvare på.

---

Kubernetes for GPU-arbeidsbelastninger

Standard Kubernetes behandler compute-ressurser som utskiftbare, der en CPU-kjerne er lik en annen. GPU-er bryter fullstendig med denne forutsetningen. En arbeidsbelastning som trenger 8 GPU-er med NVLink-interconnect kan ikke spres tilfeldig på tvers av noder.

NVIDIA GPU Operator

Vi deployer NVIDIA GPU Operator på alle GPU-noder. Den håndterer hele livssyklusen: drivere, container runtimes, device plugins og monitoring-eksportører. Når en ny GPU-node blir med i klyngen, installerer operatoren automatisk drivere, konfigurerer container runtime for GPU passthrough og registrerer GPU-ressurser hos Kubernetes-scheduleren.

Multi-Instance GPU (MIG)

Ikke alle arbeidsbelastninger trenger en hel GPU. Små inferensmodeller trenger kanskje bare en brøkdel av en H100s kapasitet. MIG lar oss partisjonere en enkelt fysisk GPU i opptil syv isolerte instanser, hver med dedikert minne og compute-ressurser.

I stedet for at en liten modell bare bruker 10 % av en GPUs compute-kapasitet, lar MIG oss pakke flere modeller på samme kort. Dette forbedrer utnyttelsesgraden og kostnadseffektiviteten dramatisk.

Topologi-bevisst planlegging

For distribuerte treningsjobber som krever flere GPU-er, er plasseringen ekstremt viktig. Åtte GPU-er på én enkelt node koblet via NVLink (900 GB/s) vil trene 2-3 ganger raskere enn åtte GPU-er spredt over flere noder som kommuniserer over selv 400GbE. Vår scheduler bruker tilpassede topologi-begrensninger og NUMA-bevisst planlegging for å sikre at multi-GPU-arbeidsbelastninger plasseres på den mest effektive maskinvarekonfigurasjonen.

---

Inferens i stor skala

Trening får all oppmerksomheten, men inferens er der de fleste GPU-sykluser faktisk blir brukt. Å kjøre modeller i produksjon med lav latency og høy gjennomstrømming krever sin egen serie med ingeniørmessige utfordringer.

Model Serving

Vi bruker en kombinasjon av serving-rammeverk avhengig av arbeidsbelastningen:

Batching-strategier

Nøkkelen til effektiv GPU-inferens er å holde maskinvaren mettet. Dynamisk batching samler innkommende forespørsler og grupperer dem før de sendes til GPU-en. Continuous batching går lenger: når individuelle forespørsler i en batch fullføres, settes nye forespørsler umiddelbart inn uten å vente på at den lengste forespørselen er ferdig.

Latency vs. Throughput

Hver inferens-deployering innebærer et kompromiss. Vi konfigurerer dette per arbeidsbelastning:

Workload Type

Batch Size

Priority

Use Case

Real-time chat

Small (1-4)

Latency

Customer-facing AI assistants

API endpoints

Medium (8-32)

Balanced

Developer APIs, search

Bulk processing

Large (64+)

Throughput

Document analysis, batch embeddings

---

Tilpassede modeller: LoRA Fine-Tuning & Data Pipelines

Rå inferens er bare halvparten av historien. De fleste virksomheter trenger modeller tilpasset sitt spesifikke domene, trent på egne data, med sitt eget språk og sin egen kontekst. Det er her vår finjusteringsplattform kommer inn.

LoRA Fine-Tuning i stor skala

Full finjustering av en 70B-parametermodell krever hundrevis av GB GPU-minne og flere dagers compute. LoRA (Low-Rank Adaptation) endrer spillereglene, ved å trene små adapter-matriser i stedet for å endre alle modellvekter, oppnår vi tilsvarende kvalitet mens vi bare endrer mindre enn 0,1 % av parametrene.

Vår plattform håndterer hele LoRA-arbeidsflyten: datasettforberedelse, orkestrering av treningsjobber, adapter-håndtering og deployering. Last opp dine data, konfigurer hyperparametere, og vi tar oss av resten, planlegger trening på tilgjengelige GPU-er, overvåker loss-kurver og deployer automatisk det beste checkpointet.

Data Pipelines: Scraping og prosessering

Finjustering er bare så god som dataene dine. Vår plattform inkluderer en komplett data-pipeline for å bygge høykvalitets treningsdatasett, fra web scraping og dokumentinnhenting til rensing, deduplisering og formatering.

Enterprise Data Integrations

Finjustering og RAG er bare nyttig hvis du faktisk får tilgang til dataene dine. Vår plattform kobler seg direkte til systemene der forretningskunnskapen din ligger, uten manuelle eksporter, CSV-opplastinger eller kopiering av dokumenter.

Chat og samtalehåndtering

Når modellen din er finjustert, trenger den et produksjonsklart serving-lag som håndterer kompleksiteten i virkelige samtaler.

RBAC: Detaljert tilgangskontroll

I et miljø med flere team bør ikke alle ha tilgang til alt. Vår plattform tilbyr finmasket rollebasert tilgangskontroll på to viktige dimensjoner: modeller og MCP-verktøy.

Hele løkken, scrape domene-data, rens og formater det, finjuster en LoRA-adapter, deploy den bak en chat-API med RAG og guardrails, kjører helt og holdent på vår plattform. Ingen sammenkobling av fem ulike verktøy fra fem forskjellige leverandører.

---

Autoskalering i praksis

Den interaktive historien viste autoskalering på et overordnet nivå, etterspørselen øker, nye pods starter, nye noder provisioneres. I praksis er GPU-autoskalering betydelig mer kompleks enn CPU-autoskalering.

Tilpassede GPU-metrikk

Standard Kubernetes HPA skalerer basert på CPU og minne, noe som er ubrukelig for GPU-arbeidsbelastninger. Vi deployer tilpassede metrics-adaptere som eksponerer GPU-spesifikke signaler:

HPA overvåker disse metrikkene og skalerer antallet inferens-pods deretter. Når etterspørselen synker, skalerer pods like aggressivt ned igjen.

Cluster autoskalering

Når HPA legger til flere pods enn det gjeldende klyngen kan håndtere, provisionerer Cluster Autoscaler nye GPU-noder fra vår warm pool. Hele prosessen, IPMI-boot, OS-installasjon via PXE, GPU Operator-oppsett og cluster join, tar minutter, ikke timer.

Kostnadsoptimalisering

---

Sikkerhet og Zero Trust

GPU-infrastruktur håndterer noen av de mest verdifulle dataene i enhver virksomhet, proprietære modeller, treningsdata og inferens-innganger som kan inneholde sensitiv kundeinformasjon. Sikkerhet kan ikke være en ettertanke.

Nettverksisolasjon

Hver tenants GPU-arbeidsbelastninger kjører i isolerte nettverksnamespaces med Kubernetes NetworkPolicies som håndhever strenge ingress/egress-regler. GPU-til-GPU trenings-trafikk er segregert på dedikerte VLAN-er. Kontrollplanet kommuniserer utelukkende over mutual TLS.

Kryptert inferens

Data i transitt er kryptert ende-til-ende, fra klientforespørselen gjennom load balancer, inn i inferens-poden og tilbake. For kunder med sensitive arbeidsbelastninger tilbyr vi også confidential computing, der modellvekter og inferens-data forblir kryptert i GPU-minnet via maskinvare-TEE-funksjoner i nyere NVIDIA- og AMD-akseleratorer. Dette er i samsvar med GDPRs dataminimeringskrav rett ut av boksen, og full per-handling audit logging er tilgjengelig for kunder som trenger det til sine egne compliance-programmer.

---

Resultatet: Infrastruktur som bare fungerer

Når alle disse lagene fungerer sammen, fysisk infrastruktur, nettverk, Kubernetes-orkestrering, GPU-bevisst planlegging, intelligent autoskalering og zero-trust-sikkerhet, får du en plattform der AI-team kan fokusere på å bygge modeller i stedet for å administrere infrastruktur.

Deploy en modell, sett dine latens- og throughput-mål, og plattformen håndterer resten: skalere GPU-er opp og ned etter etterspørsel, rute trafikk for optimal ytelse, og holde alt sikkert og kompatibelt.

Det er det ZeroSubnet leverer. Ikke bare GPU-er i et rack, men en komplett, administrert plattform for AI-infrastruktur i alle skalaer. Hvis du bygger AI-applikasjoner og bruker for mye tid på infrastruktur, kom å prat med oss.