Wat is een AI-datacenter? [Video en quiz]

Kort antwoord: Een AI-datacenter is een met een hoge dichtheid waar stroom, koeling, infrastructuur en opslag zijn afgestemd op het trainen en hosten van modellen, en niet zomaar een serverruimte met extra GPU's. De chips krijgen de aandacht; het gebouw bepaalt of ze werken. Als de datacenters niet elders kunnen worden gevestigd, is een kleine datacenterruimte aan te raden; de meeste teams zouden een ruimte moeten huren.

Belangrijkste conclusies:

Chips versus gebouw: Stroomvoorziening, koeling, materiaal en opslag bepalen of de accelerators werken.

Plaatsen, geen paleizen: Installeer twee racks achteraf als de data niet weg kan; koop geen campus.

Gemiddelde versus mediaan: Bij acht runs verborg de mediaan herstarts; gebruik het gemiddelde over 18 uur.

Weerstand tegen misbruik: Geef geen PUE-waarde op voor twee racks in een gemengde zaal.

Illustratieve resultaten: Acht runs vertegenwoordigen een kleine kaart, geen productiebesparing van 50%.

Artikelen die u wellicht interessant vindt om na dit artikel te lezen:

🔗 Is AI betrouwbaar? Video en quiz
Ontdek de betrouwbaarheid van AI met een boeiende video en een interactieve quiz.

🔗 Hoe AI in het dagelijks leven te gebruiken
Ontdek praktische manieren waarop AI dagelijkse taken en routines kan vereenvoudigen.

🔗 Hoe AI op het werk te gebruiken:
Leer praktische manieren om AI in te zetten voor een hogere productiviteit op de werkvloer.

🔗 Kan AI zelfstandig denken?
Ontdek of kunstmatige intelligentie echt zelfstandig kan denken of redeneren.

Hoe verschilt het van een "normaal" datacenter?

Traditionele hallen zijn geoptimaliseerd voor gemengde workloads en uptime voor veel kleine services. Redundantie is belangrijk, natuurlijk, en PUE als concept – de extra energie die het gebouw verbruikt om één watt aan rekenkracht te leveren. Maar je ontwerpt doorgaans niet elke gang rond een rack dat zich gedraagt ​​als een mobiele kachel.

AI-sites draaien de verhoudingen om. De dichtheid neemt toe. Het netwerk wordt een essentieel onderdeel waar de training niet zonder kan. Opslag moet ervoor zorgen dat controlepunten in beweging blijven, anders staan ​​accelerators stil, als racepaarden in een file.

Er is ook een cultureel verschil. Enterprise-operations denkt in tickets en wijzigingsvensters. AI-operations denkt in taakwachtrijen en het nare gevoel wanneer een node aan het einde van een lange run uitvalt. Je zou ze allebei nog steeds "datacenters" kunnen noemen, want dat zijn ze ook. Het label verhult alleen de onderliggende infrastructuur.

Geen morele rangschikking. Verschillende machines, dezelfde familienaam.

GPU's, accelerators en het stroomverslindende rack

Loop over een traditioneel verhoogd platform en de stellingen zien er bijna netjes uit. Loop over een rij met AI-systemen en ze lijken het hele gebouw te willen opslokken.

De meest opvallende hardware is niet een slimme CPU. Het is de accelerator-tray: GPU's of andere AI-chips, verpakt in servers, vervolgens in racks, en dan in rijen die een breedbandnetwerk delen. GPU-interconnecties verbinden de chips tot iets dat zich kan voordoen als één gigantische accelerator; het clusternetwerk doet hetzelfde op rijniveau. Parallel trainen werkt alleen als die verbindingen breed en voorspelbaar blijven. Als dat niet lukt, is je "cluster" niet meer dan een stapel dure werkstations die hetzelfde adres delen.

Stroom volgt de chips. Geen lompe kantoor-PDU. Megawatts aan IT-belasting zodra een hal vol is – ik ga geen getal verzinnen. De dichtheid per rack is de clou. Minder racks. Elk rack is een kleine oven. De beperkende factor is vaak het onderstation, niet de wensenlijst met GPU's. Je kent het wel: de inkoopafdeling wil meer accelerators; de energieleverancier wil een lang gesprek en een flinke cheque.

Een ietwat onzinnige metafoor die ik maar niet uit mijn hoofd krijg: het rek is een hongerig dier. Je kunt een sneller exemplaar fokken. Maar je moet het nog steeds voeren en de warmtebron blijven verwijderen. Sla je een van beide over, dan wordt het een peperduur papieren gewicht.

Stroom, warmte en het koelprobleem

Elektriciteit erin. Warmte eruit. Dat is de hele religie.

Opslagrekken met een hoge dichtheid voeren warmte af op een manier waarvoor lucht eigenlijk nooit bedoeld was. Je kunt lucht harder laten werken - warmtewisselaars in de achterdeuren, warmere gangpaden, slimme afscherming - en dat werkt tot op zekere hoogte. Dan komt vloeistof in beeld:

• Directe koeling van de chip

• Koelcircuits die de machinekamer eruit laten zien als een chemische fabriek

• Een paar ontwerpen die nog steeds mensen verbazen die denken dat water en servers geen zin met elkaar zouden moeten delen

Niets hiervan is glamoureus. Het hoort allemaal bij het product, want een gaspedaal dat de prestaties beperkt, is er een waar je al voor betaald hebt en die je niet volledig kunt benutten.

PUE is nog steeds belangrijk. Het is een verhouding, geen persoonlijkheidskenmerk. Operators streven ernaar omdat elke watt die aan ventilatoren en pompen wordt besteed, een watt is die niet naar een GPU gaat. Ik zal geen "typisch" cijfer noemen; het klimaat en hoe je de grens trekt, beïnvloeden het, en schijnprecisie is erger dan geen precisie. Water speelt ook een rol. Sommige planten hebben kleine slokjes. Andere slurpen. Verdampingskoeling is efficiënt totdat de rivier of een droogte het politiek maakt.

Netwerken: waarom de infrastructuur net zo belangrijk is als de chips

Mensen fotograferen de GPU's. Ze zouden de switches moeten fotograferen.

Training is een gesprek. Duizenden accelerators wisselen gradiënten, parameters en fragmenten van een model uit, in perfecte synchronisatie. Als de verbinding hapert, loopt de hele taak vast op de traagste schakel. Daarom zijn AI-afdelingen zo geobsedeerd door netwerken met hoge bandbreedte, lage latentie en topologieën die niet in elkaar zakken als een verbinding uitvalt. InfiniBand-achtige netwerken, Ethernet in dezelfde rol, GPU-interconnecties in de behuizing, bekabeling die in één keer goed moet zijn.

Inferentie is een ander verhaal. Model serving geeft om staartlatentie – het langzaamste antwoord, niet het gemiddelde. Batchverwerking versus realtimeverwerking maakt een groot verschil. Een trainingscluster wil grote, collectieve, min of meer all-to-all-bewegingen. Een serving fleet wil veel kleinere verzoeken en isolatie, zonder opstoppingen bij de load balancer.

Nu ik het er toch over heb: mensen beschouwen het netwerk als de waterleiding en de chips als het restaurant. In dit gebouw is de waterleiding het restaurant. Als je dat niet begrijpt, koop je een keuken die geen leveringen kan aannemen.

Training versus inferentie: twee gebouwen, soms letterlijk

Training is een campagne. Je bouwt een cluster, voert er data in, maakt nauwgezet checkpoints, laat het uren of weken draaien en hoopt dat alles soepel verloopt. Batchgewijs, bandbreedteverslindend, en geduldig – totdat een defecte node de hele run stillegt. Eén uitgevallen accelerator in een nauw gekoppelde taak kan het hele proces tot stilstand brengen.

Inferentie is als een etalage. Getrainde modellen beantwoorden nu vragen, classificeren afbeeldingen en genereren tekst. Latentie is belangrijk. Een iets oudere accelerator dicht bij de klant kan een geavanceerde accelerator aan de andere kant van het continent verslaan.

Je krijgt dus een tweedeling. Trainingscampussen richten zich op stroomvoorziening, grond en dichtheid. Inferentiecentra richten zich op lage latentie en beschikbaarheid. Er bestaan ​​ook hybride gebouwen, want kapitaal is niet oneindig. Nou ja, niet altijd twee gebouwen. Soms één gebouw met een fluwelen afzetkoord en twee koelcircuits.

Dit is ook waar colocatie, hyperscale campussen en on-premise oplossingen elkaar afwisselen. Hyperscalers bouwen op een schaal die voor de rest van ons eruitziet alsof we meubels aan het herschikken zijn. Colocatiebedrijven verkopen opslagcapaciteit per rack. On-premise oplossingen blijven relevant wanneer data niet mag worden geëxporteerd.

Opslagcapaciteit, controlepunten en hongerige chips

Niemand zet het parallelle bestandssysteem op de omslag van de brochure.

Trainingsdata moeten snel genoeg binnenkomen zodat GPU's niet overbelast raken. Checkpoints moeten op tijd worden geladen, zodat een crash niet een week aan data verspilt. Modelgewichten moeten geladen zijn voordat een serverreplica live is. De opslagdoorvoer – niet alleen de capaciteit – is de stille bottleneck. Je kunt een fortuin uitgeven aan accelerators en ze vervolgens uithongeren met een bescheiden opslagarray die ontworpen is voor virtuele machines.

Het patroon is bekend: een glanzend cluster, een wachtrij voor taken en een I/O-wachtrij die je aanstaart als een onvriendelijke factuur. Het clusteren van rekenkracht zonder het clusteren van het datapad leidt tot zeer kostbare inactiviteit. Zorg dat de chips blijven draaien, anders geef je toe dat je een kunstwerk hebt gekocht.

Software, orkestratie en de minder glamoureuze operationele laag

De hardware is de ster. De planners doen het werk.

Een AI-datacenter is nutteloos als taken geen GPU's kunnen vinden, als twee teams geen cluster kunnen delen zonder ruzie te maken, als een defecte rank niet kan worden vervangen, of als de firmware veroudert totdat het hele netwerk in slow motion uitvalt. Orchestratie, observability, stroombeperking - de onopvallende operationele laag, die juist laat zien dat het ertoe doet.

Ik heb een zwak voor deze laag. En als een verkeerd geconfigureerde netwerkkaart een hele middag lang een koelprobleem simuleert... dan kom je daar op de harde manier achter.

Wanneer een knooppunt tijdens de uitvoering uitvalt

Een node valt uit. Wijzigingsvensters botsen nog steeds met trainingsruns die zich niets aantrekken van je agenda. Je plant grote taken in groepen, isoleert inferentiepools en schrijft runbooks voor fouten die er eerst uitzien als "de taak is traag" totdat ze eruitzien als "de taak is mislukt". Redundantie blijft belangrijk - stroomvoorziening, koeling, paden, opslag - maar de faalmodus is minder overzichtelijk dan de oude 'negen procent uptime'-slide. Inferentie: repliceer, ontlaad de defecte node, blijf antwoorden. Training heeft checkpoints nodig, geen optimisme.

Ligging, water, elektriciteitsnet en buren

Je zet er niet eentje naast een huisje neer voor het uitzicht.

Aansluiting op het elektriciteitsnet is vaak de doorslaggevende factor bij de locatiekeuze. Grond is relatief eenvoudig te verkrijgen in vergelijking met een onderstation en een nutsbedrijf met andere klanten. Water voor koeling, indien nodig, wordt een probleem voor de buren zodra het hard regent. Geluidsoverlast. Visuele impact. Warmte bij de erfafscheiding. Plancommissies krijgen pas een mening over "de cloud" als er een veld en een rivier nodig zijn.

Latentie werkt de andere kant op. Inferentie werkt het beste in de buurt van gebruikers en interconnecties. Training kan zich verschuilen in markten met lagere energieprijzen en koelere klimaten. De industrie doet alsof er één perfecte locatie bestaat. Die bestaat niet. Er is een compromis nodig, zoals blijkt uit een persbericht.

Restwarmte en de ongenode oven

Brochures zijn dol op dit stukje. Leid de restwarmte naar huizen, zwembaden, kassen; het is een mooie zin. Soms is de wijkcirculatie echt zo. Soms ligt de campus op de verkeerde plek en verdwijnt de warmte alsnog in de lucht. Ik ben sceptisch over de brochureversie; ik ben niet sceptisch over de natuurkundige principes.

Wie heeft er een nodig (en wie kan er beter een huren)?

De meeste mensen hoeven geen eigenaar te zijn van zo'n zaal.

De onbewerkte opsomming:

• Hyperscalers, omdat het product de vloot is

• Laboratoria, wanneer de wachttijd het knelpunt vormt, of wanneer gegevens niet kunnen worden afgevoerd

• Een bank, ziekenhuisgroep, overheid of fabrikant met een geheime dataset - lokaal opgeslagen of in een eigen colocatiecentrum - kan rationeel handelen, zelfs als het omslachtig is

Iedereen zou moeten huren. Colocatie met AI-ready dichtheid. Een cloudreservering. Een beheerd cluster. Je krijgt de accelerators zonder zelf een energiecentrale te hoeven beheren. De romantiek verdwijnt zodra iemand je om 3 uur 's nachts vraagt ​​wie er dienst heeft voor het koelsysteem.

Er speelt zeker een zekere trots mee, dat geef ik toe. Het bezitten van het cluster voelt alsof je de middelen bezit om alles te voorspellen. Maar dan komt de elektriciteitsrekening, en verdwijnt die trots als sneeuw voor de zon.

Waarvoor dient het gebouw?

Wat is een AI-datacenter? Een gespecialiseerde campus met een hoge dichtheid waar accelerators, stroomvoorziening, koeling, infrastructuur en opslag zijn georganiseerd rond het trainen en hosten van modellen – niet rond algemene IT met een GPU in een hoekje. Het ziet eruit als een magazijn. Het functioneert als een energiecentrale die wiskundige berekeningen uitvoert.

Onthoud vooral dit: de chips krijgen de roem; het onderstation, de koelvloeistof en het netwerk bepalen of die chips een goed idee waren. Training en inferentie kunnen onder één dak plaatsvinden; ze vereisen nog steeds verschillende manieren. De meeste organisaties zouden moeten huren. Een paar zouden moeten bouwen. De buren zullen het hoe dan ook merken.

De cloud had altijd al een gebouw. ​​Tegenwoordig heeft dat gebouw meningen.

Praktisch voorbeeld: een trainingscel met twee racks waar de beelden niet uit kunnen

Scenario

Tomos is infrastructuurverantwoordelijke bij Kestrel Precision, een fabrikant met 400 medewerkers in de West Midlands. Ze hebben al een kleine, op locatie gevestigde infrastructuur: ERP, gedeelde mappen, virtuele machines, de gemengde omgeving waarmee dit artikel begon. Luchtkoeling. Standaard Ethernet. Een SAN die prima geschikt is voor kantoorharde schijven.

Het machinevisieteam moet een inspectiemodel trainen op destillatie-installaties in de fabriek. Deze installaties mogen de locatie niet verlaten. Ze tonen een proces dat het bedrijf niet in de cloud wil opslaan, zelfs niet in een privécloud. De oplossing van de inkoopafdeling bestaat uit vier dual-accelerator servers en een presentatie met de titel "ons AI-datacenter". De servers worden in twee bestaande racks geplaatst, omdat daar ruimte is, en ruimte bleek de beperkende factor te zijn.

Dat klopt niet. Binnen twee weken lijken de GPU's druk bezig te zijn en vervolgens schakelen ze stilletjes uit. Taken lopen vast wanneer een checkpoint de SAN bereikt. Een node valt na elf uur uit en de hele run is gewoon... verloren. Tomos heeft niet nagelaten chips te kopen. Hij heeft een heleboel dure werkstations gekocht die allemaal onder hetzelfde adres vallen. Het gebouw was nog steeds een bedrijfsverzamelgebouw.

Ze hebben geen campus, een nieuw onderstation of een rivier nodig. Ze hebben een kleine cel nodig die functioneert als een miniatuur AI-datacenter: stroom die de racks daadwerkelijk aankunnen, warmte die kan ontsnappen zonder de chips te beschadigen, een netwerk waarover de trainingstaak kan communiceren, opslagruimte voor checkpoints en een draaiboek voor het geval een node uitvalt. Omdat de beelden niet mogen worden afgevoerd, is het huren van een colocatiecentrum op veertig minuten afstand geen oplossing. Het aanpassen van twee racks is dat wel.

Wat de cel nodig heeft

• Een gemeten energiebudget voor die rij, gebaseerd op de PDU's, niet op de GPU-wensenlijst. Als de reservecapaciteit de vier servers niet kan voeden tijdens de trainingsbelasting, stopt het gesprek daar en kijken ze naar een dichtere colocatie, geen wondermiddel

• Het koelen van de lucht bij deze dichtheid was nooit nodig: warmtewisselaars in de achterdeur als de hal dat toelaat, of een kleine vloeistofkringloop als dat mogelijk is. Als geen van beide opties mogelijk is, worden de servers er niet geplaatst

• Een speciaal, breedbandig netwerk tussen de vier knooppunten, niet het kantoor-Ethernet. Als de leverancier alleen een 10 Gb-switch in de catalogus heeft, is dat geen cluster

• Lokale, snelle opslag voor checkpoints en trainingsshards, niet de VM SAN

• Een scheduler, een checkpoint-interval en een geschreven herstartpad. De hardware is de ster. Deze laag is het werk

• Een afgeschermde inferentiebox voor de productielijn, gescheiden van het trainingsgeklets, omdat serveren staartlatentie en isolatie vereist, geen collectieve aanpak

• Toestemming om gegevens te registreren over stroomverbruik, GPU-klokfrequentie, throttling-gebeurtenissen en de totale uitvoeringstijd van taken. Als ze die gegevens niet kunnen inspecteren, zullen ze de GPU's fotograferen en de schakelaars over het hoofd zien

Voorbeeldinstructie

Tomos verwoordt dit in de faciliteitenbeschrijving in gewone taal:

Noem dit geen AI-campus. Bouw een trainingscel met twee racks in de bestaande hal voor vier dual-accelerator servers. De fabrieksimages blijven op locatie. Succes betekent: de vier nodes voltooien een inspectietraining van 12 epochs zonder thermische throttling, schrijven een checkpoint in minuten in plaats van tientallen minuten, en hervatten vanaf dat checkpoint wanneer we een run opzettelijk stoppen. Koeling moet de GPU's op hun trainingskloksnelheid houden. Netwerken moet een gedeelde infrastructuur vormen voor die vier servers, geen pad door de kantooromgeving. Opslag moet de chips van stroom voorzien. Als warmtewisselaars aan de achterkant niet passen, zeg dat dan en stop. Noem geen PUE voor twee racks in een gemengde hal. Dat getal zou pure show zijn.

Vervolgens verwerkt hij dit in de trainingsopdracht zelf:

Checkpoint elke 30 minuten bij de lokale snelle pool. Als een rang uitvalt, begin dan opnieuw vanaf het laatst voltooide checkpoint. Wacht niet op de SAN. Blijf niet trainen als de klokken door hitte zijn gedaald. Registreer het en stop, zodat we de vertraging kunnen zien.

Een goed uur ziet er zo uit: alle acht GPU's draaien op trainingsklokfrequentie, checkpointbestand is opgeslagen, de taak loopt nog steeds synchroon. Een slecht uur ziet er zo uit: ventilatoren draaien op volle toeren, klokfrequentie omlaag, checkpointbestand is na tien minuten voor 2% geschreven en iemand op kantoor zegt: "Het cluster draait". Draaien is niet hetzelfde als trainen.

Hoe test je het?

Ze schrijven de test vóór de aanpassing, en dat is nu juist de hele reden waarom je een demo niet moet vertrouwen.

• Hetzelfde recept met 12 fasen, dezelfde 120.000 inspectieketels, acht runs

• De tijdmeting is gebaseerd op de werkelijke tijd tot een voltooid recept, inclusief eventuele herstarts, gemeten vanaf het moment dat de taak is ingediend tot het laatste controlepunt van epoch 12

• Een oververhittingsoverschrijding: de GPU-kloksnelheid blijft tijdens de uitvoering op de trainingsdoelwaarde. Een throttle-gebeurtenis wordt als mislukt beschouwd, zelfs als de taak uiteindelijk wordt voltooid

• Een overzicht van de opslag: checkpoint-schrijftijd, mediaan en slechtste waarde, uit het taaklogboek

• Een tip over de stof: het werk blijft niet in collectieve wachtstand staan ​​totdat een rang gezond is. Als ze die wachtstand niet zien, wordt de instrumentatie niet uitgevoerd

• In twee van de acht runs wordt een rang opzettelijk op een vast punt uitgeschakeld om het herstartpad te testen

• Inferentie is een aparte test met 200 afbeeldingen, die losstaat van de productielijn en de afgesloten serveerbox. Succes tijdens de training telt niet mee voor succes bij het serveren

• Ze registreren het stroomverbruik van de PDU's in de racks met intervallen van 15 minuten, zodat niemand een megawatt hoeft uit te vinden

Acceptatiecriteria voor het bestempelen van de cel als "AI-klaar": 8 van de 8 recepten zijn voltooid; 0 van de 8 vertonen thermische beperking; beide afgebroken processen worden hervat; checkpoints blijven binnen enkele minuten. Mochten ze dat niet halen, dan hebben ze in ieder geval nog een serverruimte met geavanceerde grafische kaarten.

Resultaat

Illustratief resultaat, afkomstig van een verzonnen test met acht runs, geen gepubliceerd cijfer van Kestrel.

Aannames: vier dual-accelerator servers in twee racks; één inspectiemodel; 120.000 stilstaande beelden; acht runs van een vast recept van 12 epochs; de kloktijd omvat herstarts totdat het recept is voltooid; throttle betekent een geregistreerde daling van de trainingsklok; checkpointtijd is de schrijftijd, niet de gewenste tijd; rackvermogen is PDU-samples, niet een campus-PUE.

Vóór de modernisering waren de GPU's in gewone, luchtgekoelde racks aangesloten op het kantoor-Ethernet en het VM SAN:

• 5 van de 8 runs werden in één keer voltooid. De mediane tijd die deze vijf runs nodig hadden was 14 uur

• Drie van de acht moesten opnieuw beginnen na een vastloop rond het elfde uur (twee nadat een node vastliep met een verouderd checkpoint, één nadat een checkpoint de SAN had gevuld). Direct opnieuw proberen, geen wachttijd van een nacht: 11 uur verspild plus een tweede poging van 14 uur, of 25 uur voor een voltooid recept voor die drie

• De gemiddelde bereidingstijd van alle acht recepten, inclusief herstarts, bedroeg 18 uur. (Vijf recepten duurden 14 uur, drie 25 uur. De mediaan van alle acht recepten is nog steeds 14 uur, waardoor de herstarts niet meetellen. Daarom is het gemiddelde hier de basislijn.)

• Thermische beperking geconstateerd tijdens 7 van de 8 runs. Gemiddelde tijd met verlaagde kloksnelheid: 3 uur tijdens een poging van 14 uur

• Checkpoint schrijven: mediaan 22 minuten

• Het doden van tegenstanders was geen test die ze konden doorstaan. Ze hadden geen draaiboek. De twee onopzettelijke doden waren het bewijs

• De piekbelasting van de IT-systemen op de twee racks tijdens de training bedroeg ongeveer 18 kW. De rij had het vermogen, maar niet de koeling of de benodigde materialen

Na de warmtewisselaars aan de achterzijde van die twee racks, een speciaal netwerk tussen de vier nodes, een kleine NVMe-pool voor checkpoints, checkpointing om de 30 minuten en een runbook voor herstarten:

• 8 van de 8 voltooid in één keer. Gemiddelde tijd op de klok: 9 uur

• Thermische smoorklep: 0 van 8

• Checkpoint schrijven: mediaan 90 seconden. Slechtste tijd in de reeks: 3 minuten

• De twee opzettelijke kills werden beide hervat vanaf het laatste checkpoint van 30 minuten. Extra speeltijd bij die twee runs: ongeveer 40 minuten per run, inclusief diagnose, dus die twee runs duurden in totaal bijna 9 uur en 40 minuten. Het gemiddelde over acht runs komt nog steeds uit op 9 uur

• De piekbelasting van de IT-systemen ligt nog steeds rond de 18 kW. Dezelfde chips. Ander gedrag van het gebouw

In deze steekproef daalde de gemiddelde tijd voor een voltooid recept van 18 uur naar 9 uur, oftewel 9 uur per recept, in totaal 72 uur over acht runs. Het percentage recepten dat in één keer klaar was, daalde van 5 van de 8 naar 8 van de 8. Het percentage recepten dat in één keer klaar was, daalde van 7 van de 8 naar 0 van de 8. Dat laatste cijfer geeft aan of ze daadwerkelijk iets hebben gekocht of dat het nu om accelerators of om papieren gewichten ging. Ze zullen de tijdsbesparing niet een besparing van 50% in de productie noemen. Acht runs is een kleine, makkelijke steekproef.

Deze cijfers zijn een voorbeeldschatting gebaseerd op de genoemde test, een kleine steekproef, één model en één gemengde hal. Ze vertegenwoordigen geen PUE (Power Usage Efficiency), geen campusmegawatt en zijn geen bewijs dat Kestrel een trainingslocatie in een veld zou moeten bouwen. De controle van de logboeken vond plaats binnen de 9 uur; dat hebben ze niet verborgen gehouden. Het cijfer van 18 kW is een afgeronde PDU-waarde, geen energierekening. Ze hebben de 72 uur niet omgerekend naar kosten, omdat het gemiddelde elektriciteitstarief van de fabriek een onjuiste businesscase zou hebben opgeleverd.

De serveercontrole was apart en kleiner: 200 regelafbeeldingen in het afgebakende vak, allemaal ter plaatse. Dat is een gevolgtrekking, geen training. Het combineren van de twee zou een miniatuurversie zijn geweest van de hybride zaalfout.

Wat kan er misgaan?

• De inkoopafdeling noemt vier servers steevast "het AI-datacenter". Die benaming verhult de onderliggende infrastructuur, en de volgende aankoop betreft meer GPU's voor hetzelfde gebrekkige systeem

• De warmtewisselaars aan de achterdeur worden geplaatst en niemand neemt de wateraansluiting in gebruik. De ventilatoren blijven schreeuwen. De klokken blijven dalen

• De infrastructuur bestaat uit één enkele switch zonder reservepad. Bij één defecte verbinding bestaat het "cluster" weer uit vier werkstations

• Checkpoints blijven op de SAN staan ​​omdat de NVMe-pool zich in "fase twee" bevond. Fase twee wordt pas bereikt na het uitvallen van het volgende knooppunt

• Ze geven een PUE-waarde op voor twee racks in een gemengde zaal. Klimaat, begrenzing en de rest van de ERP-rij maken die verhouding tot een onrealistisch gegeven

• Training en dienstverlening zijn onlosmakelijk met elkaar verbonden. Een overstroming bij een controlepost zorgt ervoor dat de productielijn moet wachten. De vertraging is het gevolg, niet de dichtheid

• Een node valt uit en iemand behandelt het als een uptime-ticket in plaats van een checkpoint-herstart. Enterprise-operations en AI-operations praten een hele middag langs elkaar heen

• Ze hadden een kooi kunnen huren, ware het niet dat de beelden er niet uit kunnen. Door die beperking te vergeten, belanden ze in een soort cloudgesprek dat ze later weer tot rust zullen moeten brengen

Praktische tips

Wat een AI-datacenter in deze vorm is, is geen magazijn en ook geen factuur voor een GPU. Het is de cel die accelerators in staat stelt hun werk af te maken: een cel die ze kunnen vasthouden, een cel die warmte kan afvoeren, een infrastructuur, een controlepunt en iemand die de verantwoordelijkheid draagt ​​als een accelerator uitvalt. Kestrel had geen campus nodig. Ze hadden twee racks nodig om te stoppen met doen alsof. De meeste teams zouden dat gedrag moeten overnemen. Een paar teams, met een geheime dataset en een ruimte die de hitte aankan, zouden een cel moeten bouwen en de rest weigeren.

Veelgestelde vragen

Wat is een AI-datacenter?

Een computercentrum met hoge dichtheid waar stroomvoorziening, koeling, netwerken en opslag volledig zijn afgestemd op parallelle training en het serveren van modellen, in plaats van op nette rijen algemene servers. Het is zo ontworpen dat enorme aantallen accelerators modellen kunnen trainen en serveren zonder oververhitting, netwerkproblemen of wachttijden op de schijf. Een gewone bedrijfshal is een gemengde buurt. Een AI-hal is een monocultuur waarvan de waarde-eenheid de accelerator is, zoals GPU's of TPU-chips. Het ziet eruit als een magazijn en gedraagt ​​zich als een energiecentrale die berekeningen uitvoert.

Wat is het verschil tussen een AI-datacenter en een gewoon datacenter?

Traditionele datacenters zijn geoptimaliseerd voor gemengde workloads en uptime voor een groot aantal kleine services. AI-sites draaien de verhoudingen om: de dichtheid neemt toe, het netwerk wordt een onmisbare infrastructuur voor de trainingstaak en de opslag moet ervoor zorgen dat checkpoints blijven draaien, anders staan ​​accelerators stil. Enterprise operations denkt in tickets en wijzigingsvensters. AI operations denkt in taakwachtrijen en het nare gevoel wanneer een node het begeeft aan het einde van een lange run. Je zou ze allebei nog steeds datacenters kunnen noemen. Het label verhult alleen de onderliggende infrastructuur.

Waarom verbruiken AI-datacenters zoveel stroom?

De meest opvallende hardware is niet een slimme CPU. Het is de accelerator-tray: GPU's of andere AI-chips, verpakt in servers, vervolgens in racks, en dan in rijen die een breedbandnetwerk delen. De dichtheid per rack is de verrassing: minder racks, elk een kleine oven. Megawatts aan IT-belasting ontstaan ​​zodra een hal vol is, hoewel het niet de moeite waard is om een ​​typisch cijfer te verzinnen. De beperkende factor is vaak het onderstation, niet de gewenste GPU's.

Hoe worden AI-datacenters gekoeld?

Racks met een hoge dichtheid voeren warmte af op een manier waarvoor lucht eigenlijk nooit bedoeld was. Je kunt lucht harder laten werken met warmtewisselaars aan de achterkant, warmere gangpaden en slimme afscherming. Dan komt vloeistofkoeling in beeld: directe koeling van de chip, koelcircuits en onderdompeling in sommige ontwerpen. Een accelerator die de prestaties terugschroeft, is er een waar je al voor betaald hebt en die je niet volledig kunt benutten. PUE blijft belangrijk, want elke watt die aan ventilatoren en pompen wordt besteed, is een watt die niet naar de GPU gaat. Water speelt ook een rol: sommige planten nippen, andere slurpen.

Waarom is netwerken net zo belangrijk als de GPU's?

Training is een gesprek: duizenden accelerators wisselen gradiënten, parameters en fragmenten van een model in perfecte synchronisatie uit. Als de infrastructuur hapert, wacht de hele taak op de traagste schakel. Daarom is AI zo geobsedeerd door netwerken met hoge bandbreedte, lage latentie, InfiniBand-achtige infrastructuren of Ethernet in dezelfde rol, en topologieën die niet in elkaar storten wanneer een verbinding uitvalt. Inferentie draait om lage staartlatentie, veel kleinere verzoeken en isolatie. In dit gebouw is het sanitair het restaurant.

Waarvoor wordt een AI-datacenter gebruikt: voor training of voor inferentie?

Training is een campagne: een cluster samenstellen, data eraan toevoegen, regelmatig checkpoints maken en uren of wekenlang laten draaien. Inferentie is een etalage: reeds getrainde modellen die nu antwoorden geven, met een latentie die ertoe doet. Trainingscampussen streven naar stroom, grond en dichtheid. Inferentiecentra streven naar lage latentie en beschikbaarheid. Hybride hallen bestaan ​​omdat kapitaal niet oneindig is, soms één hal met twee koelcircuits. Een iets oudere accelerator dicht bij de klant kan een glamoureuze accelerator aan de andere kant van het continent verslaan.

Waarom is opslag zo belangrijk in een AI-datacenter?

Trainingsdata moeten snel genoeg binnenkomen zodat GPU's niet overbelast raken. Checkpoints moeten op tijd worden geladen, zodat een crash niet een week aan data verspilt. Modelgewichten moeten geladen zijn voordat een serverreplica live is. De opslagdoorvoer, en niet alleen de capaciteit, is de stille bottleneck. Je kunt een fortuin uitgeven aan accelerators en ze vervolgens uithongeren met een bescheiden opslagarray die ontworpen is voor virtuele machines.

Wat gebeurt er als een node tijdens de uitvoering uitvalt?

Eén defecte accelerator in een nauw gekoppelde trainingstaak kan het hele proces stilleggen. Training vereist controlepunten, geen optimisme. Inferentie ontlast de defecte node, zorgt ervoor dat een replica blijft reageren en blijft operationeel. Wijzigingsvensters botsen nog steeds met trainingsruns die zich niets aantrekken van uw planning. Redundantie blijft belangrijk voor stroomvoorziening, koeling, paden en opslag, maar de faalmodus is minder overzichtelijk dan de oude 'negen procent uptime'-benadering.

Wat is de impact van een AI-datacenter op het elektriciteitsnet, het water en de omwonenden?

De aansluiting op het elektriciteitsnet is vaak de doorslaggevende factor bij de locatiekeuze. Grond is relatief eenvoudig te verkrijgen in vergelijking met een onderstation en een nutsbedrijf met andere klanten. Water voor koeling, indien nodig, wordt al snel een probleem voor de buren zodra het hard regent, net als geluidsoverlast, visuele hinder en warmte bij de erfafscheiding. Energiebedrijven kunnen profiteren van goedkopere energiemarkten en koelere klimaten. Energiebedrijven willen graag in de buurt van gebruikers gevestigd zijn. Er bestaat geen perfecte locatie. Een compromis is vaak nodig.

Moet ik een eigen AI-datacenter bezitten, of kan ik er een huren?

De meeste mensen hoeven geen eigen datacenter te bezitten. Hyperscalers bouwen datacenters omdat hun product de dataopslag is. Labs bouwen datacenters wanneer wachttijden een knelpunt vormen of data niet kan worden afgevoerd. Een bank, ziekenhuis, overheid of fabrikant met een vertrouwelijke dataset kan een on-premise of een eigen colocatiecentrum rendabel vinden. Alle anderen zouden moeten huren: AI-ready colocatie, een cloudreservering of een beheerd cluster. Zo krijg je de accelerators zonder zelf een energiecentrale te hoeven beheren.

Referenties

1. IEA - www.iea.org

2. LBNL - datacenters.lbl.gov

3. The Green Grid - 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

Vind de nieuwste AI in de officiële AI Assistant Store

Over ons