Hvad er et AI-datacenter? [Video og quiz]

Kort svar: Et AI-datacenter er et med høj tæthed , hvor strøm, køling, struktur og lagerplads er styret af trænings- og servermodeller, ikke et serverrum med ekstra GPU'er. Chippene får berømmelsen; bygningen bestemmer , om de fungerer. Hvis billederne ikke kan forlade det, skal der eftermonteres en lille celle; de ​​fleste teams bør leje.

Vigtige konklusioner:

Chips vs. bygning: Strøm, køling, struktur og lagring afgør, om acceleratorerne virker.

Steder, ikke paladser: Ombyt to racks, når data ikke kan forlades; køb ikke en campus.

Gennemsnit vs. median: Ved otte kørsler genstartes medianen; brug 18-timers gennemsnittet.

Modstand mod misbrug: Angiv ikke en PUE for to racks i en blandet hal.

Illustrative resultater: Otte kørsler er et lille kort, ikke en produktionsbesparelse på 50%.

Artikler du måske har lyst til at læse efter denne:

🔗 Er AI pålidelig? Video og quiz
Udforsk AI-pålidelighed gennem en engagerende video og interaktiv quiz.

🔗 Sådan bruger du AI i hverdagen
Opdag praktiske måder, hvorpå AI kan forenkle hverdagens opgaver og rutiner.

🔗 Sådan bruger du AI på arbejdet
Lær praktiske måder at bruge AI til smartere produktivitet på arbejdspladsen.

🔗 Kan AI tænke selvstændigt?
Forstå om kunstig intelligens oprigtigt kan tænke selvstændigt eller ræsonnere.

Hvordan det adskiller sig fra et "normalt" datacenter

Traditionelle haller optimerer til blandede arbejdsbelastninger og oppetid på tværs af mange små tjenester. Du er opmærksom på redundans, ja, og på PUE som koncept - ekstra energi, som bygningen bruger for at levere en watt computerkraft. Du designer typisk ikke hver korridor omkring et rack, der opfører sig som en bærbar varmeanlæg.

AI-sites vender forholdstallene om. Tætheden stiger. Netværket bliver et stof, som træningsjobbet ikke kan halte uden. Lagring skal holde kontrolpunkter i gang, ellers står acceleratorer inaktive, som væddeløbsheste i en trafikprop.

Der er også en kulturel forskel. Enterprise ops tænker i supportanmodninger og ændringsvinduer. AI ops tænker i jobkøer og den dårlige følelse, når en node dør sent i en lang periode. Jeg gætter på, at man stadig kan kalde begge dele "datacentre", fordi det er de. Betegnelsen skjuler bare VVS-systemet.

Ikke en moralsk rangordning. Forskellige maskiner, samme efternavn.

GPU'er, acceleratorer og racket, der sluger strøm

Går man på et traditionelt hævet gulv, ser stativene næsten høflige ud. Går man på en række med kunstig intelligens, ser det ud som om, de vil sluge hele bygningen.

Den mest fremtrædende hardware er ikke en smart CPU. Det er acceleratorbakken: GPU'er eller andre AI-chips, pakket ind i servere, derefter racks og derefter rækker, der deler et højbåndbredde-struktur. GPU-forbindelser syr chips sammen til noget, der kan foregive at være én kæmpe accelerator; klyngestrukturen gør det samme trick på rækkeskala. Parallel træning fungerer kun, hvis disse forbindelser forbliver tykke og forudsigelige. Mist det, og din "klynge" er en bunke dyre arbejdsstationer, der deler et postnummer.

Strømmen følger chipsene. Ikke en klodset kontor-PDU. Megawatt IT-belastning, når en hal er fyldt - jeg vil ikke opfinde et tal. Tætheden pr. rack er plottwisten. Færre racks. Hvert enkelt en lille ovn. Den begrænsende faktor er ofte transformerstationen, ikke ønskelisten over GPU'er. Du ved, hvordan det er: indkøb ønsker flere acceleratorer; forsyningsselskabet ønsker en lang samtale og en meget stor check.

En lidt tåbelig metafor, jeg ikke kan ryste af: hønsehuset er et sultent dyr. Du kan avle et hurtigere et. Du skal stadig fodre det, og du skal stadig muge varmen ud. Springer du nogen af ​​dem over, bliver det en meget dyr brevpresser.

Strøm, varme og køleproblemet

Strøm ind. Varme ud. Det er hele religionen.

Højdensitetsreoler afgiver varme på en måde, som luften aldrig rigtig har været bedt om at håndtere. Du kan presse luften hårdere - varmevekslere i bagdøren, varmere gange, smart indeslutning - og det virker til et vist punkt. Så dukker væsken op:

• Direkte-til-chip-køling

• Kølevæskesløjfer, der får anlægsrummet til at ligne et kemisk værk

• Fordybelse i et par designs, som stadig forbløffer folk, der mener, at vand og serveringspersonale ikke bør dele en sætning

Intet af dette er glamourøst. Det er alt sammen produktet, for en speeder, der gasser, er en, du allerede har betalt for og ikke kan udnytte fuldt ud.

PUE betyder stadig noget. Det er et forhold, ikke en personlighed. Operatørerne jagter det, fordi hver watt brugt på ventilatorer og pumper er en watt, der ikke gik til en GPU. Jeg vil ikke citere et "typisk" tal; klimaet og hvordan man trækker grænsen flytter det, og falsk præcision er værre end ingen. Vand er også en del af historien. Nogle planter nipper. Nogle sluger. Fordampningskøling er effektiv, indtil floden eller en tørke gør det politisk.

Netværk: Hvorfor stoffet er lige så vigtigt som chipsene

Folk fotograferer GPU'erne. De burde fotografere switchene.

Træning er en samtale. Tusindvis af acceleratorer, der udveksler gradienter, parametre og dele af en model i tæt synkronisering. Hvis strukturen jitter, venter hele jobbet på det langsomste hop. Derfor er AI-haller besatte af netværk med høj båndbredde, lav latenstid og topologier, der ikke folder sig på midten, når et link fejler. InfiniBand-agtige strukturer, Ethernet i samme rolle, GPU-forbindelser inde i boksen, kabler, der skal være rigtige første gang.

Inferens er en anden snak. Modelserving fokuserer på haleforsinkelse - det langsomme svar, ikke det gennemsnitlige. Batch vs. realtid splitter personligheden. En træningsklynge ønsker fed, kollektiv, alt-til-alle-agtig bevægelse. En serverflåde ønsker mange mindre anmodninger og isolation uden trafikpropper ved load balancer.

Fejlen, mens jeg er her: folk behandler netværket som VVS og pommes frites som restauranten. I denne bygning er VVS restauranten. Hvis du fejler det, køber du et køkken, der ikke kan tage imod levering.

Træning vs. inferens: to bygninger, nogle gange bogstaveligt talt

Træning er en kampagne. Du samler en klynge, fodrer den med data, foretager religiøse checkpoints, kører i timevis eller ugevis og beder til, at strukturen forbliver uforstyrret. Batch-tung, båndbredde-sulten, stille tålmodig - indtil en fejlende node tager en bid af kørslen. Én død accelerator i et tæt koblet job kan sætte hele koret i stå.

Inferens er en butiksfacade. Modeller, der allerede er trænet, besvarer nu spørgsmål, klassificerer billeder og genererer tekst. Latens er vigtig. En lidt ældre accelerator i nærheden af ​​kunden kan slå en glamourøs en et kontinent væk.

Så du får en opdeling. Træningscampusser jagter magt, jord og tæthed. Inferenssteder jagter latenstid og tilstedeværelse. Hybride haller findes også, fordi kapital ikke er uendelig. Tja - ikke altid to bygninger. Nogle gange én hal med et fløjlsreb og to kølende loops.

Det er også her, colocation, hyperscale-campusser og on-prem-forks finder sted. Hyperscalers bygger i skalaer, der får resten af ​​os til at se ud, som om vi arrangerer møbler. Colos sælger tæthed i rack. On-prem sker stadig, når data ikke kan forlades.

Lagringsgennemstrømning, kontrolpunkter og sultne chips

Ingen sætter det parallelle filsystem på forsiden af ​​brochuren.

Træningsdata skal ankomme hurtigt nok til, at GPU'er ikke halter. Checkpoints skal lande, så et nedbrud ikke spilder en uge. Modelvægte skal indlæses, før en serverreplika er live. Lagringsgennemstrømning - ikke kun kapacitet - er den stille flaskehals. Du kan bruge en formue på acceleratorer og sulte dem ud med et høfligt array designet til virtuelle maskiner.

Mønsteret er velkendt: en skinnende klynge, en jobkø og I/O-ventetider, der stirrer tilbage som en uhøflig faktura. Clustering af beregninger uden at klynge datastien er, hvordan man får en meget dyr inaktiv løsning. Hold chipsene fyldt, eller indrøm, at du har købt en skulptur.

Software, orkestrering og det uglamourøse operationslag

Hardware er kendisskabet. Planlæggere gør arbejdet.

Et AI-datacenter er nytteløst, hvis job ikke kan finde GPU'er, hvis to teams ikke kan dele en klynge uden kamp, ​​hvis en mislykket rang ikke kan erstattes, hvis firmwaren driver, indtil strukturen fejler i slowmotion. Orkestrering, observerbarhed, strømforbrugsbegrænsning - det uglamourøse operationslag, som er sådan du ved, at det betyder noget.

Jeg har en svaghed for dette lag. Og hvor et forkert konfigureret netværkskort efterligner et køleproblem en hel eftermiddag ... det finder man ud af på den hårde måde.

Når en node dør midt i et forløb

En node dør. Ændringsvinduer kolliderer stadig med træningskørsler, der er ligeglade med din kalender. Du planlægger store job i grupper, afgrænser inferenspuljer, skriver runbooks til fejl, der ser ud som "jobbet er langsomt", indtil de ser ud som "jobbet er dødt". Redundans betyder stadig noget - strøm, køling, stier, lagerplads - men fejltilstanden er mindre pæn end den gamle "ni-af-oppetid"-slide. Inferens: replikér, dræn den syge node, bliv ved med at svare. Træning ønsker checkpoints, ikke optimisme.

Beliggenhed, vand, elnet og naboer

Du sætter ikke en af ​​disse ved siden af ​​et sommerhus for udsigtens skyld.

Nettilslutning er ofte den egentlige proces ved valg af lokation. Jord er let at finde sammenlignet med en transformerstation og et forsyningsselskab, der har andre kunder. Vand til køling, hvis man bruger det, bliver et problem for naboerne, så snart nedbøren er voldsom. Støj. Visuel volumen. Varme ved et skel. Planlægningsudvalg opdager meninger om "skyen", i det øjeblik den har brug for en mark og en flod.

Latens trækker den anden vej. Inferens kan lide at være tæt på brugere og forbindelser. Træning kan gemme sig i billigere energimarkeder og køligere klimaer. Branchen taler, som om der findes ét perfekt sted. Det er der ikke. Der er et kompromis med en pressemeddelelse.

Resterende varme og den ubudne ovn

Brochurer elsker denne del. Led spildvarmen ind i hjem, pools, drivhuse; det er en dejlig sætning. Nogle gange er distriktsløjfen ægte. Nogle gange er campus det forkerte sted, og varmen stiger stadig op i luften. Jeg er skeptisk over for brochureversionen; jeg er ikke skeptisk over for fysikken.

Hvem har brug for en (og hvem burde leje i stedet)

De fleste mennesker behøver ikke at eje en af ​​disse haller.

Den skarpe liste:

• Hyperskalere, fordi produktet er flåden

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

• En bank, hospitalsgruppe, regering eller producent med et hemmeligt datasæt - on-prem eller et privat kolofonbur - kan være rationelt, selvom det er et fupnummer

Alle andre burde leje. Colocation med AI-klar tæthed. En cloud-reservation. En administreret klynge. Du får acceleratorerne uden også at blive kraftværksoperatør. Romantikken forsvinder første gang nogen spørger, hvem der er på vagt til kølevæskekredsløbet klokken 3 om natten.

Der er noget med stolthed, det må jeg indrømme. At eje klyngen føles som at eje midlerne til at forudsige. Så ankommer elregningen, og stoltheden sætter sig.

Hvad bygningen er til for

Så hvad er et AI-datacenter? En specialiseret campus med høj tæthed, hvor acceleratorer, strømforsyning, køling, fabric og lagring er organiseret omkring trænings- og serveringsmodeller - ikke generel IT med en GPU i hjørnet. Det ligner et lager. Det opfører sig som et kraftværk, der laver matematik.

Hvis du ikke husker andet: chipsene får berømmelsen; transformerstationen, kølevæsken og netværket afgør, om disse chips var en god idé. Træning og inferens kan dele tag; de ønsker stadig forskellige manerer. De fleste organisationer bør leje. Nogle få bør bygge. Naboer vil bemærke det under alle omstændigheder.

Skyen har altid haft en bygning. Nu om dage har bygningen meninger.

Eksempel fra den virkelige verden: En træningscelle med to racks, når billederne ikke kan forlade

Scenarie

Tomos er infrastrukturchef hos Kestrel Precision, en producent med 400 ansatte i West Midlands. De har allerede en lille on-prem-hal: ERP, fildeling, virtuelle maskiner, det blandede nabolag, som denne artikel startede med. Luftkøling. Almindeligt Ethernet. Et SAN, der er perfekt til kontordiske.

Maskinvisionsteamet skal træne en inspektionsmodel på fabrikkens stillbilleder. Stillbillederne må ikke forlade stedet. De viser en proces, som virksomheden ikke vil lægge på en clouddisk, selv ikke en privat en. Procurements løsning er fire servere med dobbelt accelerator og et slide med titlen "vores AI-datacenter". Serverne placeres i to eksisterende racks, fordi der er plads, og pladsen føltes som en begrænsning.

Det er det ikke. Inden for to uger lyder GPU'erne travle, men så bremser de stille og roligt. Job crawler, når et checkpoint rammer SAN'et. En node dør klokken elleve, og kørslen er bare... væk. Tomos har ikke undladt at købe chips. Han har købt en bunke dyre arbejdsstationer, der deler et postnummer. Bygningen var stadig en enterprisehal.

De behøver ikke en campus, en ny transformerstation eller en flod. De har brug for en lille celle, der opfører sig som et AI-datacenter i miniature: strøm som rackene rent faktisk kan indeholde, varme der forlader uden at tilberede chipsene, et stof, som træningsjobbet kan kommunikere over, lagerplads der kan håndtere et checkpoint, og en runbook til når en node dør. Fordi billederne ikke kan forlade systemet, er leje af et colo-bur fyrre minutter væk ikke løsningen. Det er at eftermontere to racks.

Hvad cellen har brug for

• Et målt strømforbrugsbudget på den række, fra PDU'erne, ikke fra GPU'ens ønskeliste. Hvis den ekstra kapacitet ikke kan forsyne de fire servere ved træningsbelastning, stopper samtalen der, og de ser på en tættere farve, ikke et mirakel

• Køling af luften er aldrig blevet bedt om at håndtere ved denne tæthed: varmevekslere i bagdøren, hvis hallen kan klare dem, eller en lille væskesløjfe, hvis den kan klare det i stedet. Hvis ingen af ​​delene er i brug, går serverne ikke ind

• En dedikeret højbåndbreddestruktur mellem de fire noder, ikke kontorets Ethernet. Hvis leverandøren kun har en 10 Gb switch i kataloget, er det ikke en klynge

• Lokal hurtig lagring til checkpoints og træningsshards, ikke VM SAN'et

• En planlægger, et kontrolpunktsinterval og en skriftlig genstartssti. Hardware er kendissen. Dette lag er jobbet

• En indhegnet inferensboks til fabrikslinjen, adskilt fra træningssnakken, fordi serveringen ønsker haleforsinkelse og isolation, ikke en kollektiv

• Tilladelse til at logge strøm, GPU-ure, drosselshændelser og job-vægur. Hvis de ikke kan inspicere disse, vil de fotografere GPU'erne og overse kontakterne

Eksempelinstruktion

Tomos skriver dette i facilitetsbeskrivelsen, i almindeligt sprog:

Kald ikke dette en AI-campus. Byg en træningscelle med to racks i den eksisterende hal til fire servere med dobbelt accelerator. Fabriksbillederne forbliver på stedet. Succes er: de fire noder gennemfører en 12-epokers inspektions- og træningsopskrift uden termisk drossel, skriver et checkpoint på minutter, ikke ti minutter, og genoptager fra det checkpoint, når vi med vilje dræber en rang. Køling skal holde GPU'erne på deres træningsure. Netværk skal være et struktur, som de fire bokse deler, ikke en sti gennem kontorstakken. Lager skal forsyne chipsene. Hvis varmevekslere i bagdøren ikke passer, så sig det og stop. Angiv ikke en PUE for to racks i en blandet hal. Det tal ville være teater.

Så sætter han dette ind i selve træningsjobbet:

Checkpoint hvert 30. minut til den lokale hurtige pool. Hvis en rang dør, genstart fra det sidste komplette checkpoint. Vent ikke på SAN'en. Fortsæt ikke træningen, mens urene er faldet fra heat. Log det og stop, så vi kan se stallen.

En god time ser sådan ud: alle otte GPU'er ved træningsure, checkpoint-filen er landet, jobbet stadig i lockstep. En dårlig time ser sådan ud: blæsere på fuld hastighed, ure er nede, checkpoint 2% skrevet efter ti minutter, og nogen på kontoret siger "klyngen er oppe". Oppe er ikke træning.

Sådan tester du det

De skriver testen før eftermonteringen, hvilket er hele pointen med ikke at stole på en demo.

• Den samme opskrift fra 12 epoker, de samme 120.000 inspektionsbilleder, otte kørsler

• Timingen er vægur til en færdig opskrift, inklusive enhver genstart, målt fra jobannonce til sidste kontrolpunkt i epoke 12

• En overraskelse af varme: GPU-ure forbliver på træningsmålet under løbet. En gashændelse er en fejl, selvom jobbet til sidst afsluttes

• En forsømmelse af lagring: skrivetid ved kontrolpunkt, median og værst, fra jobloggen

• En pass på materialet: jobbet venter ikke kollektivt, mens en rang er sund. Hvis de ikke kan se den ventetid, er instrumenteringen ikke færdig

• To af otte løb får en rang dræbt på et fast trin, med vilje, for at teste genstartsstien

• Inferens er en separat test med 200 billeder fra fabrikslinjen til den indhegnede serveboks. Træningssucces tæller ikke som servesucces

• De registrerer rack-effekt fra PDU'erne i 15-minutters prøver, så ingen behøver at opfinde en megawatt

Accept af at kalde cellen "AI-klar": 8 ud af 8 opskrifter er færdige; 0 ud af 8 viser termisk gasregulering; begge afbrudte kørsel genoptages; kontrolpunkter forbliver i minutter. Hvis de ikke gør det, har de stadig et serverrum med smarte grafikkort.

Resultat

Illustrativt resultat fra en opdigtet test med otte løb, ikke et offentliggjort Kestrel-tal.

Antagelser: fire servere med dobbelt accelerator i to racks; én inspektionsmodel; 120.000 stillbilleder; otte kørsler af en fast 12-epokers opskrift; vægur inkluderer genstarter, indtil opskriften er færdig; throttle betyder et logget fald fra træningsuret; checkpoint-tid er skrivetiden, ikke ønsket; rack-strøm er PDU-prøver, ikke en campus PUE.

Før eftermonteringen, GPU'er i almindelige luftkølede racks på kontorets Ethernet og VM SAN:

• 5 ud af 8 løb blev gennemført i første forsøg. Median vægur blandt disse fem: 14 timer

• 3 ud af 8 måtte starte forfra efter et stop omkring time 11 (to efter at en node døde med et inaktivt checkpoint, et efter at et checkpoint fyldte SAN'et). Øjeblikkeligt nyt forsøg, ingen ventetid natten over i uret: 11 timer spildt plus et 14-timers andet forsøg, eller 25 timer til en færdig opskrift på disse tre

• Gennemsnitlig tid til en færdig opskrift på tværs af alle otte, inklusive genstarter: 18 timer. (Fem klokken 14, tre klokken 25. Medianen af ​​alle otte er stadig 14, hvilket ville skjule genstarterne. Derfor er gennemsnittet basislinjen her.)

• Termisk gasspjæld logget på 7 ud af 8 kørsler. Median tid ved reduceret ur: 3 timer i et 14-timers forsøg

• Skrivningstid til checkpoint: median 22 minutter

• Rang-drab var ikke en test, de kunne bestå. De havde ikke en løbbog. De to utilsigtede dødsfald var konstateringen

• Peak IT-belastning på de to stativer under træning: omkring 18 kW. Roeenheden havde wattene. Den havde hverken køling eller stoffet

Efter varmevekslere i bagdøren på disse to racks, en dedikeret struktur mellem de fire noder, en lille NVMe-pulje til kontrolpunkter, 30-minutters kontrolpunkter og en genstarts-runbook:

• 8 ud af 8 færdige i første forsøg. Median vægur: 9 timer

• Termisk gasspjæld: 0 af 8

• Checkpoint-skrivning: median 90 sekunder. Dårligst i sættet: 3 minutter

• De to bevidste rang-drab blev begge genoptaget fra det sidste 30-minutters checkpoint. Ekstra vægur på de to løb: omkring 40 minutter hver, inklusive diagnose, så de to sad tæt på 9 timer og 40 minutter. Gennemsnit over otte stillestående runder til 9 timer

• Spidsbelastning på IT stadig omkring 18 kW. Samme chips. Forskellig bygningsadfærd

På tværs af denne stikprøve faldt den gennemsnitlige tid til en færdig opskrift fra 18 timer til 9 timer, eller 9 timer hver, 72 timer over otte kørsler. Færdig første gang gik fra 5 ud af 8 til 8 ud af 8. Gashåndtaget gik fra 7 ud af 8 til 0 ud af 8. Det sidste tal er det, der siger, om de købte acceleratorer eller brevpressere. De vil ikke kalde tidsændringen en 50% besparelse i produktionen. Otte kørsler er et lille, nemt sæt.

Disse tal er et eksempelestimat baseret på den angivne test, en lille stikprøve, én model og én blandet hal. De er ikke en PUE, ikke en campus-megawatt og ikke et bevis på, at Kestrel burde bygge et træningssted på en mark. Gennemgang af logfilerne lå inden for de 9 timer; de skjulte det ikke. Tallet på 18 kW er en afrundet PDU-aflæsning, ikke en forsyningsfaktura. De konverterede ikke de 72 timer til en omkostning, fordi fabrikkens blandede elpris ville have skabt en falsk business case.

Serveringschecken var separat og mindre: 200 linjebilleder til den indhegnede boks, alle på stedet. Det er inferens, ikke træning. At blande de to ville have været hybrid-hal-fejlen i miniature.

Hvad kan gå galt

• Indkøb bliver ved med at kalde fire servere for "AI-datacentret". Mærket skjuler VVS-systemet, og det næste køb er flere GPU'er til den samme sygegang

• Bagdørsvekslere går ind, og ingen tager vandsiden i brug. Ventilatorerne råber stadig. Urene går stadig i gang

• Strukturen er en enkelt switch uden ekstra sti. Én fejlet forbindelse, og "klyngen" er igen fire arbejdsstationer

• Kontrolpunkter forbliver på SAN'et, fordi NVMe-puljen var "fase to". Fase to ankommer ikke før den næste døde node

• De angiver en PUE for to reoler i en blandet hal. Klima, afgrænsning og resten af ​​ERP-rækken gør det forhold til et kostume

• Træning og servering deler stoffet. En oversvømmelse ved et checkpoint får fabrikslinjen til at vente. Haleforsinkelse er produktet der, ikke densiteten

• En node dør, og nogen behandler den som en oppetidsbillet i stedet for en genstart af et checkpoint. Enterprise-operationer og AI-operationer taler forbi hinanden en hel eftermiddag

• De kunne have lejet et bur, bortset fra at billederne ikke kan forlade det. At glemme den begrænsning sender dem ind i en samtale i skyerne, hvor de bliver nødt til at slappe af

Praktisk takeaway

Hvad et AI-datacenter er i denne form, er ikke et lager, og det er ikke en GPU-faktura. Det er den celle, der lader acceleratorer afslutte løbet: strøm de kan holde, varme der forlader, en fabric, et checkpoint og en person på krogen, når en rang dør. Kestrel havde ikke brug for en campus. De havde brug for to racks for at holde op med at lade som om. De fleste hold burde benytte sig af den adfærd. Et par stykker, med et hemmeligt datasæt og en hal, der kan tåle varmen, burde bygge en celle og afvise slidet.

Ofte stillede spørgsmål

Hvad er et AI-datacenter?

Et computeranlæg med høj densitet, hvor strøm, køling, netværk og lagring er centreret omkring parallel træning og modelvisning, ikke ryddelige rækker af generelle servere. Det er designet, så et stort antal acceleratorer kan træne og betjene modeller uden at smelte, gå i stå på netværket eller vente på disken. En almindelig virksomhedshal er et blandet nabolag. En AI-hal er en monokultur, hvis værdienhed er acceleratoren, såsom GPU'er eller TPU-lignende chips. Det ligner et lager og opfører sig som et kraftværk, der laver matematik.

Hvordan adskiller et AI-datacenter sig fra et almindeligt datacenter?

Traditionelle haller optimerer til blandede arbejdsbelastninger og oppetid på tværs af mange små tjenester. AI-sites vender forholdene om: tætheden stiger, netværket bliver et struktur, som træningsjobbet ikke kan halte uden, og lagerplads skal holde checkpoints i gang, ellers sidder acceleratorer inaktive. Enterprise ops tænker i tickets og ændringsvinduer. AI ops tænker i jobkøer og den dårlige fornemmelse, når en node dør sent i en lang periode. Man kan stadig kalde begge datacentre. Etiketten skjuler bare VVS-systemet.

Hvorfor bruger AI-datacentre så meget strøm?

Den mest fremtrædende hardware er ikke en smart CPU. Det er acceleratorbakken: GPU'er eller andre AI-chips, pakket ind i servere, derefter racks, så rækker, der deler en højbåndbreddestruktur. Tætheden pr. rack er plottwisten: færre racks, hvert enkelt en lille ovn. Megawatt IT-belastning dukker op, når en hal er fyldt op, selvom det ikke er umagen værd at opfinde et typisk tal. Den begrænsende faktor er ofte transformerstationen, ikke ønskelisten over GPU'er.

Hvordan køles AI-datacentre?

Højdensitetsracks afleder varme på en måde, som luften aldrig rigtig blev bedt om at håndtere. Du kan presse luften hårdere med varmevekslere bagpå, varmere gange og smart indeslutning. Så dukker væsken op: direkte-til-chip-køling, kølemiddelloops og immersion i et par designs. En accelerator, der drosler, er en, du allerede har betalt for og ikke kan udnytte fuldt ud. PUE betyder stadig noget, fordi hver watt brugt på blæsere og pumper er en watt, der ikke gik til en GPU. Vand er også en del af historien: nogle anlæg nipper, andre sluger.

Hvorfor er netværk lige så vigtigt som GPU'erne?

Træning er en samtale: tusindvis af acceleratorer, der udveksler gradienter, parametre og shards af en model i tæt synkronisering. Hvis strukturen jitter, venter hele jobbet på det langsomste hop. Derfor er AI-haller besatte af netværk med høj båndbredde, lav latenstid, InfiniBand-agtige strukturer eller Ethernet i samme rolle, og topologier, der ikke foldes på midten, når et link fejler. Inferens fokuserer på halelatens, mange mindre anmodninger og isolation. I denne bygning er VVS restauranten.

Hvad bruges et AI-datacenter til: træning eller inferens?

Træning er en kampagne: saml en klynge, giv den data, foretag religiøse checkpoints, og kør i timevis eller ugevis. Inferens er en butiksfacade: modeller, der allerede er trænet, svarer nu, med latenstid, der betyder noget. Træningscampusser jagter magt, land og tæthed. Inferenssteder jagter latenstid og tilstedeværelse. Hybride haller eksisterer, fordi kapital ikke er uendelig, nogle gange én hal med to køleloops. En lidt ældre accelerator i nærheden af ​​kunden kan slå en glamourøs en et kontinent væk.

Hvorfor er lagring vigtig i et AI-datacenter?

Træningsdata skal ankomme hurtigt nok til, at GPU'er ikke halter. Checkpoints skal lande, så et nedbrud ikke spilder en uge. Modelvægte skal indlæses, før en serverreplika er live. Lagringsgennemstrømning, ikke kun kapacitet, er den stille flaskehals. Du kan bruge en formue på acceleratorer og sulte dem ud med et høfligt array designet til virtuelle maskiner.

Hvad sker der, når en node dør midt i processen?

Én død accelerator i et tæt koblet træningsjob kan sætte hele koret i stå. Træning ønsker checkpoints, ikke optimisme. Inferens dræner den syge node, holder en replika i gang og forbliver aktiv. Ændringsvinduer kolliderer stadig med træningskørsler, der er ligeglade med din kalender. Redundans betyder stadig noget for strøm, køling, stier og lagring, men fejltilstanden er mindre pæn end den gamle nedtur med ni-timers oppetid.

Hvad er et AI-datacenters indflydelse på elnettet, vandet og naboerne?

Nettilslutning er ofte den egentlige valgproces for placering. Jord er let sammenlignet med en transformerstation og et forsyningsselskab, der har andre kunder. Vand til køling, hvis du bruger det, bliver et naboproblem, så snart nedbøren er voldsom, sammen med støj, visuel volumen og varme ved et hegn. Træning kan gemme sig i billigere elmarkeder og køligere klimaer. Inferens kan lide at være i nærheden af ​​brugerne. Der findes ikke én perfekt placering. Der er et kompromis med en pressemeddelelse.

Skal jeg eje et AI-datacenter, eller skal jeg leje det?

De fleste mennesker behøver ikke at eje en af ​​disse haller. Hyperscalere bygger, fordi produktet er flåden. Laboratorier bygger, når køtid er flaskehalsen, eller data ikke kan forlades. En bank, et hospital, en regering eller en producent med et hemmeligt datasæt kan gøre on-prem eller et privat colocation-bur rationelt. Alle andre bør leje: AI-klar colocation, en cloud-reservation eller en administreret klynge. Du får acceleratorerne uden at blive kraftværksoperatør.

Referencer

1. IEA - www.iea.org

2. LBNL - datacenters.lbl.gov

3. Det Grønne Net - 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

Find den nyeste AI i den officielle AI-assistentbutik

Om os