Hva er et AI-datasenter? [Video og quiz]

Kort svar: Et AI-datasenter er et med høy tetthet der strøm, kjøling, struktur og lagring er rettet mot trenings- og servermodeller, ikke et serverrom med ekstra GPU-er. Brikkene får berømmelsen; bygningen bestemmer om de fungerer. Hvis bildene ikke kan forlates, ettermonter en liten celle; de ​​fleste team bør leie.

Viktige konklusjoner:

Brikker vs. bygging: Strøm, kjøling, struktur og lagring avgjør om akseleratorene fungerer.

Steder, ikke palasser: Ettermonter to rack når data ikke kan forlates; ikke kjøp en campus.

Gjennomsnitt vs. median: Ved åtte kjøringer starter medianen hid på nytt; bruk 18-timers gjennomsnittet.

Motstand mot misbruk: Ikke oppgi en PUE for to rack i en blandet hall.

Illustrative resultater: Åtte kjøringer er et lite kart, ikke en produksjonsbesparelse på 50 %.

Artikler du kanskje vil lese etter denne:

🔗 Er AI pålitelig? Video og quiz
Utforsk AI-pålitelighet gjennom en engasjerende video og interaktiv quiz.

🔗 Slik bruker du AI i hverdagen
Oppdag praktiske måter AI kan forenkle hverdagsoppgaver og rutiner.

🔗 Slik bruker du AI på jobb
Lær praktiske måter å bruke AI for smartere produktivitet på arbeidsplassen.

🔗 Kan AI tenke selvstendig?
Forstå om kunstig intelligens virkelig kan tenke selvstendig eller resonnere.

Hvordan det skiller seg fra et «vanlig» datasenter

Tradisjonelle haller optimaliserer for blandede arbeidsbelastninger og oppetid på tvers av mange små tjenester. Dere bryr dere om redundans, ja, og om PUE som konsept – ekstra energi bygningen forbrenner for å levere en watt med datakraft. Dere designer vanligvis ikke hver korridor rundt et rack som oppfører seg som en bærbar varmeanleggspark.

AI-nettsteder snur forholdstallene. Tettheten øker. Nettverket blir et stoff som treningsjobben ikke kan halte av gårde uten. Lagring må holde kontrollpunktene i gang, ellers står akseleratorene inaktive, som veddeløpshester i en trafikkork.

Det er også en kulturell forskjell. Enterprise ops tenker i billetter og endringsvinduer. AI-opers tenker i jobbkøer og den kvalme følelsen når en node dør sent i en lang periode. Jeg antar at man fortsatt kan kalle begge deler «datasentre», for det er de. Betegnelsen skjuler bare rørleggerarbeidet.

Ikke en moralsk rangering. Forskjellige maskiner, samme familienavn.

GPU-er, akseleratorer og racket som spiser strøm

Går du på et tradisjonelt hevet gulv, ser stativene nesten høflige ut. Går du på en rekke med kunstig intelligens, ser det ut som om de vil svelge hele bygningen.

Den mest fremtredende maskinvaren er ikke en smart CPU. Det er akseleratorbrettet: GPU-er eller andre AI-brikker, pakket inn i servere, deretter rack, deretter rader som deler en høybåndbreddestruktur. GPU-er kobler sammen brikker til noe som kan late som om de er én gigantisk akselerator; klyngestrukturen gjør det samme trikset på radskala. Parallell trening fungerer bare hvis disse koblingene forblir fete og forutsigbare. Mister du det, er "klyngen" din en haug med dyre arbeidsstasjoner som deler postnummer.

Strømmen følger brikkene. Ikke en klumpete kontor-PDU. Megawatt med IT-belastning når en hall fylles opp – jeg skal ikke finne opp et tall. Tetthet per rack er den store vridningen. Færre rack. Hvert rack er en liten ovn. Den begrensende faktoren er ofte transformatorstasjonen, ikke ønskelisten over GPU-er. Du vet hvordan det er: innkjøpsavdelingen ønsker flere akseleratorer; forsyningsselskapet ønsker en lang samtale og en veldig stor sjekk.

En litt tåpelig metafor jeg ikke kan riste av meg: brettet er et sultent dyr. Du kan avle et raskere dyr. Du må fortsatt mate det, og du må fortsatt møkke ut varmen. Hopp over noen av dem, og det blir en veldig kostbar brevvekter.

Kraft, varme og kjøleproblemet

Strøm inn. Varme ut. Det er hele religionen.

Høydensitetsstativer avgir varme på en måte luften aldri egentlig ble bedt om å håndtere. Du kan presse luften hardere – varmevekslere i bakdøren, varmere ganger, smart inneslutning – og det fungerer til en viss grad. Da dukker væsken opp:

• Direkte-til-brikke-kjøling

• Kjølevæskesløyfer som får maskinrommet til å se ut som et kjemisk verk

• Fordypning i noen få design, noe som fortsatt forbløffer folk som mener at vann og serveringspersonale ikke burde dele en setning

Ingenting av dette er glamorøst. Alt er produktet, for en gasspedal som gasser er en du allerede har betalt for og ikke kan bruke fullt ut.

PUE betyr fortsatt noe. Det er et forholdstall, ikke en personlighet. Operatørene jager det fordi hver watt som brukes på vifter og pumper er en watt som ikke gikk til et GPU. Jeg vil ikke sitere et "typisk" tall; klima og hvordan du trekker grensen flytter det, og falsk presisjon er verre enn ingenting. Vann er også med i historien. Noen planter nipper. Noen sluker. Fordampningskjøling er effektivt inntil elven eller en tørke gjør det politisk.

Nettverksbygging: hvorfor stoffet er like viktig som brikkene

Folk fotograferer GPU-ene. De burde fotografere bryterne.

Trening er en samtale. Tusenvis av akseleratorer som utveksler gradienter, parametere og deler av en modell, i tett synkronisering. Hvis strukturen dirrer, venter hele jobben på det tregeste hoppet. Det er derfor AI-haller er besatt av nettverk med høy båndbredde, lav latens og topologier som ikke brettes i to når en kobling svikter. InfiniBand-aktige strukturer, Ethernet i samme rolle, GPU-sammenkoblinger inne i boksen, kabling som må være riktig første gang.

Inferens er en annen diskusjon. Modellservering bryr seg om haleforsinkelse – det langsomme svaret, ikke det gjennomsnittlige. Batch vs. sanntid splitter personligheten. En treningsklynge ønsker fet, kollektiv, alt-til-alle-aktig bevegelse. En serverende flåte ønsker mange mindre forespørsler og isolasjon, uten trafikkork ved lastbalansereren.

Feilen, mens jeg er her: folk behandler nettverket som rørleggerarbeid og pommes frites som restauranten. I denne bygningen er rørleggerarbeidet restauranten. Feiler du det, kjøper du et kjøkken som ikke kan ta imot levering.

Trening vs. inferens: to bygninger, noen ganger bokstavelig talt

Trening er en kampanje. Du setter sammen en klynge, mater den med data, sjekker den religiøst, kjører i timer eller uker, og ber om at strukturen forblir hendelsesfri. Massevis av batcher, båndbreddesulten, stille tålmodig – helt til en feilet node tar en bit av løpet. Én død akselerator i en tett koblet jobb kan stoppe hele koret.

Inferens er en butikkfasade. Modeller som allerede er trent, svarer nå på spørsmål, klassifiserer bilder, genererer tekst. Latens er viktig. En litt eldre akselerator i nærheten av kunden kan slå en glamorøs en et kontinent unna.

Så du får en splittelse. Treningscampuser jager makt, land og tetthet. Inferenssteder jager latens og tilstedeværelse. Hybride haller finnes også, fordi kapital ikke er uendelig. Vel - ikke alltid to bygninger. Noen ganger én hall med et fløyelstau og to kjøleløkker.

Det er også her samlokalisering, hyperskala-campuser og lokale forgreninger skjer. Hyperskalere bygger i skalaer som får resten av oss til å se ut som om vi arrangerer møbler. Samlokaliseringer selger tetthet i stativet. Lokalt samarbeid skjer fortsatt når data ikke kan forlates.

Lagringsgjennomstrømning, kontrollpunkter og sultne brikker

Ingen setter det parallelle filsystemet på forsiden av brosjyren.

Treningsdata må ankomme raskt nok til at GPU-ene ikke vipper med føttene. Kontrollpunkter må lande slik at et krasj ikke kaster bort en uke. Modellvekter må lastes inn før en serverreplika er live. Lagringsgjennomstrømning – ikke bare kapasitet – er den stille flaskehalsen. Du kan bruke en formue på akseleratorer og sulte dem ut med en høflig array designet for virtuelle maskiner.

Mønsteret er kjent: en skinnende klynge, en jobbkø og I/O-venting som stirrer tilbake som en uhøflig faktura. Klyngebasert beregning uten å klynge datastien er slik du får en veldig dyr inaktiv løsning. Hold brikkene matet eller innrøm at du kjøpte en skulptur.

Programvare, orkestrering og det lite glamorøse operasjonslaget

Maskinvare er kjendisen. Planleggere gjør jobben.

Et AI-datasenter er ubrukelig hvis jobber ikke finner GPU-er, hvis to team ikke kan dele en klynge uten slåsskamp, ​​hvis en mislykket rang ikke kan erstattes, hvis fastvaren driver til strukturen feiler i sakte film. Orkestrering, observerbarhet, strømbegrensning – det lite glamorøse operasjonslaget, som er slik du vet at det betyr noe.

Jeg har en svakhet for dette laget. Og der et feilkonfigurert nettverkskort imiterer et kjøleproblem en hel ettermiddag ... det finner man ut på den harde måten.

Når en node dør midt i prosessen

En node dør. Endringsvinduer kolliderer fortsatt med treningskjøringer som ikke bryr seg om kalenderen din. Du planlegger store jobber i gruppe, gjerder av inferenspooler, skriver runbooks for feil som ser ut som "jobben er treg" helt til de ser ut som "jobben er død". Redundans betyr fortsatt noe - strøm, kjøling, stier, lagring - men feilmodusen er mindre ryddig enn den gamle ni-av-oppetid-sliden. Inferens: replika, tøm den syke noden, fortsett å svare. Trening ønsker kontrollpunkter, ikke optimisme.

Beliggenhet, vann, strømnett og naboer

Du legger ikke en av disse ved siden av en hytte for utsiktens skyld.

Netttilkobling er ofte den virkelige prosessen med valg av tomt. Tomt er enkelt sammenlignet med en transformatorstasjon og et forsyningsselskap som har andre kunder. Vann til kjøling, hvis du bruker det, blir et naboproblem så snart nedbøren er kraftig. Støy. Visuell volum. Varme ved et grensegjerde. Planleggingskomiteer oppdager meninger om «skyen» i det øyeblikket den trenger et jorde og en elv.

Latens trekker den andre veien. Inferens liker å være i nærheten av brukere og sammenkoblinger. Opplæring kan gjemme seg i billigere strømmarkeder og kjøligere klima. Bransjen snakker som om det finnes ett perfekt sted. Det finnes ikke. Det er et kompromiss med en pressemelding.

Restvarme og den ubudne ovnen

Brosjyrer elsker denne delen. Spol spillvarmen inn i hjem, bassenger, drivhus; det er en fin setning. Noen ganger er distriktsløkken ekte. Noen ganger er campus på feil sted, og varmen går fortsatt ut i luften. Jeg er skeptisk til brosjyreversjonen; jeg er ikke skeptisk til fysikken.

Hvem trenger en (og hvem burde leie i stedet)

De fleste trenger ikke å eie en av disse hallene.

Den stive listen:

• Hyperskalere, fordi produktet er flåten

• Labs, når køtid er flaskehalsen, eller data ikke kan forlates

• En bank, sykehusgruppe, myndigheter eller produsenter med et hemmelig datasett – lokalt eller privat – kan være rasjonelt, selv om det er tull

Alle andre burde leie. Samlokalisering med AI-klar tetthet. En skyreservasjon. En administrert klynge. Du får akseleratorene uten å også bli kraftverksoperatør. Romantikken forsvinner første gang noen spør hvem som er på vakt for kjølevæskesløyfen klokken 03.00.

Det er en stolthetsgreie, det må jeg innrømme. Å eie klyngen føles som å eie prediksjonsmidlene. Så kommer strømregningen, og stoltheten setter seg ned.

Hva bygningen er til for

Så, hva er et AI-datasenter? En spesialisert campus med høy tetthet der akseleratorer, strømforsyning, kjøling, struktur og lagring er organisert rundt opplærings- og serveringsmodeller – ikke generell IT med en GPU i hjørnet. Det ser ut som et lager. Det oppfører seg som et kraftverk som gjør matematikk.

Hvis du ikke husker noe annet: brikkene får berømmelsen; transformatorstasjonen, kjølevæsken og nettverket avgjør om disse brikkene var en god idé. Opplæring og slutninger kan dele tak; de vil fortsatt ha forskjellige manerer. De fleste organisasjoner burde leie. Noen få burde bygge. Naboer vil legge merke til det uansett.

Skyen har alltid hatt en bygning. Nå til dags har bygningen meninger.

Eksempel fra den virkelige verden: En treningscelle med to rack når bildene ikke kan forlate

Scenario

Tomos er infrastrukturleder hos Kestrel Precision, en produsent med 400 ansatte i West Midlands. De har allerede en liten lokale hall: ERP, fildeling, virtuelle maskiner, det blandede nabolaget denne artikkelen startet med. Luftkjøling. Vanlig Ethernet. Et SAN som er perfekt for kontordisker.

Maskinsynsteamet må trene en inspeksjonsmodell på fabrikkstillbilder. Stillbildene kan ikke forlate stedet. De viser en prosess selskapet ikke vil legge på en skydisk, selv ikke en privat en. Procurements løsning er fire servere med dobbel akselerator og et lysbilde med tittelen «vårt AI-datasenter». Serverne plasseres i to eksisterende rack, fordi det er plass, og plassen føltes som en begrensning.

Det er det ikke. Innen to uker høres GPU-ene travle ut, før de gasser stille. Jobber kryper når et kontrollpunkt treffer SAN-et. En node dør klokken elleve, og kjøringen er bare ... borte. Tomos har ikke unnlatt å kjøpe brikker. Han har kjøpt en haug med dyre arbeidsstasjoner som deler postnummer. Bygningen var fortsatt en enterprisehall.

De trenger ikke en campus, en ny transformatorstasjon eller en elv. De trenger en liten celle som oppfører seg som et AI-datasenter i miniatyr: strøm som rackene faktisk kan holde, varme som forsvinner uten å koke brikkene, et stoff som treningsjobben kan snakke over, lagring som kan ta et kontrollpunkt, og en runbook for når en node dør. Fordi bildene ikke kan forsvinne, er ikke løsningen å leie et kolofonbur førti minutter unna. Det er å ettermontere to rack.

Hva cellen trenger

• Et målt strømbudsjett på den raden, fra PDU-ene, ikke fra GPU-ønskelisten. Hvis den ekstra kapasiteten ikke kan mate de fire serverne ved treningsbelastning, stopper samtalen der, og de ser på en tettere farge, ikke et mirakel

• Luftkjøling ble aldri bedt om å håndtere med denne tettheten: varmevekslere i bakdøren hvis hallen kan ta dem, eller en liten væskesløyfe hvis den kan ta det i stedet. Hvis ingen av delene, går ikke serverne inn

• En dedikert høybåndbreddestruktur mellom de fire nodene, ikke kontorets Ethernet. Hvis leverandøren bare har en 10 Gb-svitsj i katalogen, er ikke det en klynge

• Lokal rask lagring for kontrollpunkter og treningssharder, ikke VM SAN

• En planlegger, et kontrollpunktintervall og en skriftlig omstartsbane. Maskinvare er kjendisen. Dette laget er jobben

• En inngjerdet inferensboks for fabrikklinjen, atskilt fra treningspratten, fordi serveringen ønsker haleforsinkelse og isolasjon, ikke et kollektivt

• Tillatelse til å logge strøm, GPU-klokker, gasshendelser og jobbens veggklokke. Hvis de ikke kan inspisere disse, vil de fotografere GPU-ene og overse bryterne

Eksempelinstruksjon

Tomos setter dette frem i fasilitetsbeskrivelsen, i et vanlig språk:

Ikke kall dette en AI-campus. Bygg en treningscelle med to rack i den eksisterende hallen for fire servere med dobbel akselerator. Fabrikkbildene forblir på stedet. Suksess er: de fire nodene fullfører en 12-epokers inspeksjons- og treningsoppskrift uten termisk gasspjeld, skriver et sjekkpunkt på minutter, ikke titalls minutter, og fortsetter fra det sjekkpunktet når vi med vilje dreper en rang. Kjøling må holde GPU-ene på treningsklokkene sine. Nettverk må være en struktur som de fire boksene deler, ikke en bane gjennom kontorstakken. Lagring må mate brikkene. Hvis varmevekslere bakdøren ikke passer, si ifra og stopp. Ikke oppgi en PUE for to rack i en blandet hall. Det tallet ville være teater.

Så legger han dette inn i selve treningsjobben:

Sjekkpunkt hvert 30. minutt til den lokale hurtigpoolen. Hvis en rang dør, start på nytt fra det siste komplette sjekkepunktet. Ikke vent på SAN. Ikke fortsett treningen mens klokkene har gått ned fra heat. Logg det og stopp slik at vi kan se stallen.

En god time ser slik ut: alle åtte GPU-er på treningsklokker, kontrollpunktfilen landet, jobben fortsatt i takt. En dårlig time ser slik ut: vifter på full guffe, klokker nede, kontrollpunkt 2 % skrevet etter ti minutter, og noen på kontoret sier «klyngen er oppe». Oppe er ikke trening.

Hvordan teste det

De skriver testen før ettermonteringen, som er hele poenget med å ikke stole på en demo.

• Den samme 12-epokeroppskriften, de samme 120 000 inspeksjonsbildene, åtte kjøringer

• Tidspunktet er veggklokke til en ferdig oppskrift, inkludert eventuell omstart, målt fra jobbinnsending til siste kontrollpunkt i epoke 12

• En overseelse av varme: GPU-klokkene holder seg på treningsmålet for løpeturen. En gasspådrag er en feil selv om jobben til slutt fullføres

• Et pass på lagring: skrivetid for kontrollpunkt, median og verste, fra jobbloggen

• Et pass på stoff: jobben står ikke i kollektiv ventetid mens en rang er syk. Hvis de ikke kan se den ventetiden, er ikke instrumenteringen ferdig

• To av åtte løp får en rang drept på et fast trinn, med vilje, for å teste omstartsbanen

• Inferens er en separat test med 200 bilder fra fabrikklinjen til den inngjerdede serveboksen. Treningssuksess teller ikke som servesuksess

• De registrerer rackeffekt fra PDU-ene i 15-minutters prøver, slik at ingen trenger å oppfinne en megawatt

Aksept for å kalle cellen «KI-klar»: 8 av 8 oppskrifter fullføres; 0 av 8 viser termisk gasspjeld; begge drepte kjøringene gjenopptas; kontrollpunktene forblir i løpet av minutter. Hvis de ikke får det til, har de fortsatt et serverrom med fancy grafikkort.

Resultat

Illustrativt resultat, fra en oppdiktet test med åtte løp, ikke et publisert Kestrel-tall.

Forutsetninger: fire servere med dobbel akselerator i to rack; én inspeksjonsmodell; 120 000 stillbilder; åtte kjøringer av en fast 12-epokers oppskrift; veggklokke inkluderer omstarter inntil oppskriften er ferdig; gass betyr et logget fall fra treningsklokken; kontrollpunktstid er skrivetiden, ikke ønsket; rackstrøm er PDU-prøver, ikke en campus PUE.

Før ettermonteringen, GPU-er i vanlige luftkjølte rack på kontorets Ethernet og VM SAN:

• 5 av 8 løp fullført på første forsøk. Median veggklokke blant disse fem: 14 timer

• 3 av 8 måtte starte på nytt etter en blokkering rundt time 11 (to etter at en node døde med et foreldet sjekkpunkt, ett etter at et sjekkpunkt fylte SAN-et). Øyeblikkelig nytt forsøk, ingen venting over natten i klokken: 11 timer bortkastet pluss et 14-timers andre forsøk, eller 25 timer til en ferdig oppskrift på disse tre

• Gjennomsnittlig tid til ferdig oppskrift for alle åtte, inkludert omstarter: 18 timer. (Fem klokken 14, tre klokken 25. Medianen for alle åtte er fortsatt 14, noe som ville skjule omstartene. Det er derfor gjennomsnittet er grunnlinjen her.)

• Termisk gasspådrag logget på 7 av 8 kjøringer. Median tid ved redusert klokke: 3 timer i et 14-timers forsøk

• Skrivetid for kontrollpunkt: median 22 minutter

• Rang-kill var ikke en test de kunne bestå. De hadde ikke en løpebok. De to utilsiktede dødsfallene var funnet

• Topp IT-belastning på de to stativene under trening: omtrent 18 kW. Roemaskinen hadde wattene. Den hadde ikke kjøling eller stoff

Etter varmevekslere bakdøren på de to rackene, en dedikert struktur mellom de fire nodene, et lite NVMe-basseng for kontrollpunkter, 30-minutters kontrollpunkting og en omstarts-runbook:

• 8 av 8 fullførte på første forsøk. Median veggklokke: 9 timer

• Termisk gasspjeld: 0 av 8

• Sjekkpunktskriving: median 90 sekunder. Verst i settet: 3 minutter

• De to bevisste rangdrepene ble begge gjenopptatt fra det siste 30-minutters kontrollpunktet. Ekstra veggklokke på de to løpene: omtrent 40 minutter hver, inkludert diagnose, så de to satt i nesten 9 timer og 40 minutter. Gjennomsnitt over åtte stillestående runder til 9 timer

• Topp IT-belastning fortsatt rundt 18 kW. Samme brikker. Ulik bygningsoppførsel

På tvers av dette utvalget falt gjennomsnittlig tid til en ferdig oppskrift fra 18 timer til 9 timer, eller 9 timer hver, 72 timer over åtte kjøringer. Ferdig første gang gikk fra 5 av 8 til 8 av 8. Gasshastigheten gikk fra 7 av 8 til 0 av 8. Det siste tallet er det som sier om de kjøpte akseleratorer eller brevpressere. De vil ikke kalle tidsendringen en 50 % besparelse i produksjonen. Åtte kjøringer er et lite, enkelt sett.

Disse tallene er et eksempelestimat basert på den oppgitte testen, et lite utvalg, én modell og én blandet hall. De er ikke en PUE, ikke en megawatt på campus, og ikke bevis på at Kestrel burde bygge et treningssted på et jorde. Gjennomgang av loggene satt innenfor de 9 timene; de ​​skjulte det ikke. Tallet på 18 kW er en avrundet PDU-avlesning, ikke en faktura for strøm. De konverterte ikke de 72 timene til en kostnad, fordi fabrikkens blandede strømpris ville ha utgjort en falsk forretningsplan.

Servesjekken var separat og mindre: 200 linjebilder til den inngjerdede boksen, alt på stedet. Det er slutning, ikke trening. Å blande de to ville ha vært hybridhall-feilen i miniatyr.

Hva kan gå galt

• Innkjøpsavdelingen kaller stadig fire servere «AI-datasenteret». Etiketten skjuler rørleggerarbeidet, og det neste kjøpet er flere GPU-er til den samme sykegangen

• Bakdørsvekslere går inn, og ingen setter i gang vannsiden. Viftene roper fortsatt. Klokkene går fortsatt ned

• Strukturen er en enkelt svitsj uten ekstra bane. Én lenke som ikke fungerer, og «klyngen» er igjen fire arbeidsstasjoner

• Kontrollpunktene forblir på SAN-et fordi NVMe-poolen var i «fase to». Fase to ankommer ikke før neste døde node

• De oppgir en PUE for to rack i en blandet hall. Klima, avgrensning og resten av ERP-rekken gjør det forholdet til et kostyme

• Trening og servering deler stoffet. En kontrollpunktsflom får fabrikklinjen til å vente. Haleforsinkelse er produktet der, ikke tetthet

• En node dør, og noen behandler den som en oppetidsbillett i stedet for en omstart av et kontrollpunkt. Enterprise-operasjoner og AI-operasjoner snakker forbi hverandre en hel ettermiddag

• De kunne ha leid et bur, men bildene kan ikke forlate det. Å glemme den begrensningen sender dem inn i en samtale i skyen de må slappe av i

Praktisk takeaway

Det som er et AI-datasenter i denne formen, er ikke et lager og ikke en GPU-faktura. Det er cellen som lar akseleratorer fullføre løpet: strøm de kan holde, varme som forsvinner, en fiberstruktur, et kontrollpunkt og noen på kroken når en rang dør. Kestrel trengte ikke en campus. De trengte to rack for å slutte å late som. De fleste lag burde leie den oppførselen. Noen få, med et hemmelig datasett og en hall som kan tåle varmen, burde bygge en celle og avvise sliden.

Vanlige spørsmål

Hva er et AI-datasenter?

Et databehandlingssted med høy tetthet der strøm, kjøling, nettverk og lagring er rettet mot parallell trening og modellservering, ikke ryddige rader med generelle servere. Det er designet slik at et stort antall akseleratorer kan trene og betjene modeller uten å smelte, stoppe opp på nettverket eller vente på disk. En vanlig enterprise-hall er et blandet nabolag. En AI-hall er en monokultur der verdienheten er akseleratoren, for eksempel GPU-er eller TPU-lignende brikker. Det ser ut som et lager og oppfører seg som et kraftverk som gjør matematikk.

Hvordan er et AI-datasenter forskjellig fra et vanlig datasenter?

Tradisjonelle haller optimaliserer for blandede arbeidsbelastninger og oppetid på tvers av mange små tjenester. AI-nettsteder snur på forholdstallene: tettheten øker, nettverket blir et stoff opplæringsjobben ikke kan halte uten, og lagring må holde kontrollpunktene i gang, ellers står akseleratorene inaktive. Enterprise ops tenker i saker og endringsvinduer. AI ops tenker i jobbkøer og den kvalme følelsen når en node dør sent i en lang periode. Du kan fortsatt kalle begge datasentrene. Etiketten skjuler bare rørleggerarbeidet.

Hvorfor bruker AI-datasentre så mye strøm?

Den mest fremtredende maskinvaren er ikke en smart CPU. Det er akseleratorbrettet: GPU-er eller andre AI-brikker, pakket inn i servere, deretter rack, deretter rader som deler en høybåndbreddestruktur. Tetthet per rack er plott-twisten: færre rack, hvert av dem en liten ovn. Megawatt med IT-belastning dukker opp når en hall fylles opp, selv om det ikke er verdt det å finne opp et typisk tall. Den begrensende faktoren er ofte transformatorstasjonen, ikke ønskelisten over GPU-er.

Hvordan kjøles AI-datasentre ned?

Høydensitetsrack avgir varme på en måte luften aldri egentlig ble bedt om å håndtere. Du kan presse luften hardere med varmevekslere bakdøren, varmere ganger og smart inneslutning. Da dukker væsken opp: direkte-til-brikke-kjøling, kjølevæskesløyfer og immersion i noen få design. En akselerator som struper er en du allerede har betalt for og ikke kan bruke fullt ut. PUE er fortsatt viktig fordi hver watt brukt på vifter og pumper er en watt som ikke gikk til et GPU. Vann er også en del av historien: noen planter nipper, noen gulper.

Hvorfor er nettverk like viktig som GPU-ene?

Trening er en samtale: tusenvis av akseleratorer som utveksler gradienter, parametere og skjær av en modell i tett synkronisering. Hvis strukturen dirrer, venter hele jobben på det tregeste hoppet. Det er derfor AI-haller er besatt av nettverk med høy båndbredde, lav latens, InfiniBand-aktige strukturer eller Ethernet i samme rolle, og topologier som ikke brettes i to når en lenke svikter. Inferens bryr seg om haleforsinkelse, mange mindre forespørsler og isolasjon. I denne bygningen er rørleggerarbeidet restauranten.

Hva brukes et AI-datasenter til: trening eller inferens?

Trening er en kampanje: sett sammen en klynge, mat den med data, sjekk den religiøst, og kjør i timer eller uker. Inferens er en butikkfasade: modeller som allerede er trent, svarer nå, med latens som betyr noe. Treningscampuser jager makt, land og tetthet. Inferenssteder jager latens og tilstedeværelse. Hybride haller eksisterer fordi kapital ikke er uendelig, noen ganger én hall med to kjøleløkker. En litt eldre akselerator i nærheten av kunden kan slå en glamorøs en et kontinent unna.

Hvorfor er lagring viktig i et AI-datasenter?

Treningsdata må ankomme raskt nok til at GPU-ene ikke vipper med føttene. Kontrollpunkter må lande slik at et krasj ikke kaster bort en uke. Modellvekter må lastes før en serverreplika er live. Lagringsgjennomstrømning, ikke bare kapasitet, er den stille flaskehalsen. Du kan bruke en formue på akseleratorer og sulte dem ut med en høflig array designet for virtuelle maskiner.

Hva skjer når en node dør midt i prosessen?

Én død akselerator i en tett koblet treningsjobb kan stoppe hele koret. Trening ønsker kontrollpunkter, ikke optimisme. Inferens tapper den syke noden, holder en replika i gang og forblir aktiv. Endringsvinduer kolliderer fortsatt med treningskjøringer som ikke bryr seg om kalenderen din. Redundans er fortsatt viktig for strøm, kjøling, stier og lagring, men feilmodusen er mindre ryddig enn den gamle nedturen.

Hvilken innvirkning har et AI-datasenter på strømnettet, vannet og naboene?

Netttilkobling er ofte den virkelige prosessen med valg av sted. Tomt er enkelt sammenlignet med en transformatorstasjon og et forsyningsselskap som har andre kunder. Vann til kjøling, hvis du bruker det, blir et naboproblem så snart nedbøren er kraftig, sammen med støy, visuell volum og varme ved et grensegjerde. Opplæring kan gjemme seg i billigere kraftmarkeder og kjøligere klima. Inferens liker å være i nærheten av brukere. Det finnes ikke ett perfekt sted. Det er et kompromiss med en pressemelding.

Trenger jeg å eie et AI-datasenter, eller bør jeg leie?

De fleste trenger ikke å eie en av disse hallene. Hyperskalere bygger fordi produktet er flåten. Laboratorier bygger når køtid er flaskehalsen eller data ikke kan forlates. En bank, et sykehus, en myndighet eller en produsent med et hemmelig datasett kan gjøre lokal eller privat samlokalisering rasjonell. Alle andre bør leie: AI-klar samlokalisering, en skyreservasjon eller en administrert klynge. Du får akseleratorene uten å bli kraftverksoperatør.

Referanser

1. IEA - www.iea.org

2. LBNL - datacenters.lbl.gov

3. Det grønne nettet - www.thegreengrid.org

4. LBNL - datacenters.lbl.gov

5. LBNL - datacenters.lbl.gov

6. Uptime Institute - journal.uptimeinstitute.com

7. NVIDIA - developer.nvidia.com

8. NVIDIA - docs.nvidia.com

9. NVIDIA - docs.nvidia.com

10. NVIDIA - docs.nvidia.com

11. Google Cloud – docs.cloud.google.com

Finn den nyeste AI-en i den offisielle AI-assistentbutikken

Om oss