Vuosikymmenten kuluessa olemme nähneet monenlaista kehitystä konesalien infrassa. Palvelimissa on samanlaiset kuoret kuin 20 vuotta sitten, mutta niiden sisuskalut ovat ihan jotain muuta tarjoten käsittämättömiä suorituskykyjä. Tallennusjärjestelmissä on sama juttu - hiljakseen humisevat tummanpuhuvat laitteet seuraavat edelleen paikalla olevaa asiantuntijaa valojen hiljaa välkehtiessä, mutta kapasiteetti on toiselta planeetalta. Verkkolaitteissa ei ole päästy eroon vilkkuvista valoista ja kaapelihässäköistä, mutta teknologiat ovat kehittyneet VLANeista erilaisten valmistajakohtaisten viritysten kautta standardinmukaisiin CLOS-verkkoihin ja kapasiteetit ovat jopa 100-kertaistuneet.
Ei ole vaikea ennustaa, että vastaava kehitys tulee jatkumaan myös tulevaisuudessa. Pikkuhiljaa kaikki tulee nopeammaksi, suorituskykyisemmäksi ja kustannustehokkaammaksi (per bitti) ja jokainen elinkaaripäivitys kasvattaa oman konesalin mahdollisuuksia pyörittää yrityksen tarjoamia sovelluksia aikaisempaa paremmin.
"Mutta miksi - meillähän on pilvi!", huudahtaa joku. No toki on totta, että yritykset siirtävät tuotantoaan ja työkuormiaan pilveen edelleen, mutta ihan yhtä lailla on totta, että yritykset siirtävät tuotantoaan ja työkuormiaan pois pilvestä. Syitä on useita - pilvi voidaan kokea kalliiksi, regulaatio estää sen käytön tai sieltä puuttuu jotain, joka vaaditaan oman toimialan sovelluksien osalta. Yksi isoista syistä jättää pilvi on oman AI-klusterin pyörittäminen. Vaikka tämä onnistuu toki pilvessäkin, esimerkkinä AWS:n EC2 Capacity Block -palvelu, on siellä erilaisia rajoitteita ja sitä kautta voi syntyä tarve omaan infraan.
AI-klusteri on kuitenkin hyvin erilainen olio kuin perinteinen konesali, jossa ajetaan tavallisia työkuormia. Jotta koneäly pystyisi tuottamaan järkevää tulosta, tarvitaan sen opettamiseen valtavasti dataa ja taustalla oleva hermoverkko voi sisältää miljardeja parametreja. Esimerkiksi kuvien tunnistamisen osalta voidaan puhua jopa 10 miljoonasta näytteestä per kategoria. Näiden siirtäminen tallennusjärjestelmistä työsolmuille ja työsolmujen keskinäinen kommunikaatio vaatii niin nopean ja luotettavan infran kuin mahdollista.
Korkealla tasolla AI-klusterin infraelementit voidaan jakaa seuraavasti:
- Ulkoyhteydet
- Edustaverkko
- Työsolmut
- Tallennusjärjestelmät
- Taustaverkko
Ulkoyhteyksissä ei ole eroja aikaisempaan. Klusterista tarvitaan yhteyksiä esimerkiksi käyttäjäorganisaation laajaverkkoon (WAN), konesalien välille (DCI) tai Internetiin.
Edustaverkkoa käytetään esimerkiksi koulutuksen orkestroinnissa ja API-kutsujen välittämisessä. Se ei varsinaisesti osallistu koneälyn opetusprosessiin ja sen vuoksi sen vaatimukset ovat jonkin verran yksinkertaisemmat kapasiteetin suhteen. Tyypillisissä arkkitehtuureissa edustaverkko toteutetaan CLOS-arkkitehtuurilla kapasiteettien ollessa 100G-tasolla per työsolmu. Edustaverkon teknologiana käytetään aina Ethernettiä ja IP Fabric -mallia.
Työsolmut ovat nykyisin pääsääntöisesti Nvidian H100- tai A100-pohjaisia. Näissä pyöritetään koneälyn oppimiseen ja tulosten esittelyyn tarvittavia algoritmejä. Kuten yllä on mainittu, koneälyn hermoverkko voi koostua miljardeista parametreista (Chat-GPT4:ssä on noin 1800 miljardia) ja sen opettamiseen pienenkin asian osalta voidaan tarvita satojatuhansia tai miljoonia näytteitä. Tämän vuoksi riittävien tulosten saavuttamiseksi laskentaa ei voidaa tehdä yhdessä solmussa vaan solmuja pitää olla useita. Tämä taas asettaa verkolle haasteita tärkeimpien ollessa isot viestit (1-32 MB), alhainen entropia ja herkkyys viipeille. Liikenteen välittämisen nopeuttamiseksi palvelimissa käytetään RDMA-tekniikkaa (Remote Direct Memory Access). Periaatteessa RDMA:n kautta työsolmujen muistit voivat kommunikoida suoraan keskenään ja siten ohittaa viipeitä aiheuttavat komponentit, kuten käyttöjärjestelmän.
Työsolmuista yleisin, Nvidian DGX H100-palvelin sisältää kahdeksan H100-korttia ja kymmenen 400G-verkkokorttia. Verkkokorteista kahdeksan on tarkoitettu työkommunikaatioon ja kaksi muuta muuhun käyttöön. Palvelin on kahdeksan räkkiyksikköä korkea ja sen maksimi tehonkulutus on 10 kW. Konesalin räkki-, sähkö-, ja jäähdytyssuunnittelusta riippuen näitä voi siis olla 2-4 kappaletta per räkki.
Tallennusjärjestelmät ovat AI-optimoituja kokonaisuuksia, joissa ison kapasiteetin lisäksi mahdollistetaan myös tehokas verkko. Esimerkkinä Weka AMD -tallennussolmut, joissa on noin 50 TB tallennuskapasiteettia ja kaksi 200G verkkokorttia tallennusyhteyksiä varten.
Taustaverkko on kokonaisuus, jonka avulla työsolmut kommunikoivat keskenään, sekä tallennusjärjestelmille. Jotta oppiminen tapahtuisi mahdollisimman ripeästi, datan tulee liikkua liukkaasti ja luotettavasti näillä yhteyksillä. Taustaverkko rakennetaan tyyppillisesi joko Infiniband- tai Ethernet/CLOS-teknologioilla.
Infiniband-tekniikkaa on aikaisemmin käytetty yleisesti suurteholaskennassa. Se on suunniteltu toteuttamaan RDMA ja siten se tukee hyvin työsolmujen välisiä yhteyksiä. Se käyttää keskitettyä varauspohjaista järjestelmää liikenteen välittämisessä ja sillä varmistaa korkean kapasiteetin ja liikenteen häviämättömyyden verkon sisällä. Vaikka Infiniband tukee hyvin koneälyn vaatimuksia, sen taustapuolella on korkea hinta, joka on jopa 30-40% kalliimpi kuin vaihtoehtoinen malli.
Ethernet/CLOS-pohjainen verkko on edullisempi ja se osataan yleisesti paremmin, mutta se ei pysty suoraan tukemaan työsolmujen välisiä yhteyksiä. Tähän avuksi on kehitetty ROCEv2 (RDMA over Converged Ethernet versio 2). Kyseessä on mekanismi, joka ottaa RDMA-paketin ja kuljettaa sen eteenpäin UDP/IP-kehystettynä lisättynä muutamalla lisätekniikalla. Nämä ovat PFC (Priority-based Flow Control, 802.1Qbb) ja ECN (Explicit Congestion Notification, RFC 3168). Ensimmäinen mahdollistaa laatuluokkakohtaiset pause-kehykset liikenteen rajoittamiseksi ja toinen tarjoaa verkonlaajuisen tavan signaloida ruuhkatilanteista.
Jotta yllämainitut hienot mekanismit toimisivat kunnolla, kapasiteettia tulee olla reilusti. Jos oletetaan 40 DGX H100-solmun järjestelmä, niin 400G yhteyksiä tarvitaan 320 kappaletta jaettuna kahdeksaan leaf-kytkimeen. Yhteen tulee siis yhteyksiä 16 terabitin verran. Koska järjestelmän suorituskyky edellyttää häviötöntä arkkitehtuuria, jokaisesta leaf-kytkimestä tulee olla tuon verran kapasiteettia myös spine-kytkimiin. Vastaavasti spine-kytkimessä tulee olla 8*16 = 128 Tbit kapasiteettia. Nämä vaatimukset ovat sen verran isoja, että tarvitaan markkinoiden järeimpiä laitteita. Esimerkiksi Juniperin valikoimista PTX-sarjan tai uudet QFX-sarjan tuotteet tulisivat kyseeseen.
Infran suunnittelu AI-käyttöön on siis jotain ihan muuta, kuin perinteisen konesalikokonaisuuden tekeminen. Jos sinulla on kiinnostusta jutella aiheesta lisää vaikka vain teoreettisen pohdiskelun näkökulmasta, niin ota reilusti yhteyttä.