uutiset

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Valittu osoitteesta imbue.com

Kirjoittaja: Imbue Team

Koneen sydän -kokoelma

Toimittaja: panda

Tiedämme, että LLM on koulutettu laajamittaisissa tietokoneklustereissa käyttäen valtavaa dataa. Machine Heart on ottanut käyttöön monia menetelmiä ja teknologioita auttaakseen ja parantamaan LLM-koulutusprosessia. Tänään haluamme jakaa artikkelin, joka perehtyy syvälle taustalla olevaan teknologiaan ja esittelee, kuinka joukko "paljaita metalleja", joissa ei ole edes käyttöjärjestelmää, muutetaan tietokoneklusteriksi LLM-koulutusta varten.

Tämä artikkeli on peräisin Imbuelta, tekoälystartupilta, joka pyrkii saavuttamaan yleisen älykkyyden ymmärtämällä, miten koneet ajattelevat.

Tietenkään "paljaan metallin" muuttaminen tietokoneklusteriksi LLM:n koulutusta varten ei ole helppo prosessi, täynnä tutkimista ja kokeiluja, mutta Imbue koulutti lopulta onnistuneesti LLM:n 70 miljardilla parametrilla monia hyödyllisiä kokemuksia prosessissa.

Tämä artikkeli tarjoaa perusteellisen johdannon tiimin koko prosessiin oman LLM-koulutusinfrastruktuurin rakentamiseen ja jakaa monia työkaluja ja komentosarjoja, jotka he kirjoittivat helpottaakseen seurantaa, tarkastusta ja virheiden korjaamista.

Jos olet kiinnostunut rakentamaan omaa LLM-koulutusinfrastruktuuriasi tai olet kiinnostunut LLM:n tekemisestä, tämä artikkeli kannattaa lukea ja kerätä.

Seuraava on Imbue-tiimin artikkelin alkuperäinen teksti.

esittely

Pieni tutkija- ja insinööritiimimme käytti useita kuukausia 70 miljardin parametrin mallin kouluttamiseen alusta alkaen omalla infrastruktuurillamme, ja malli suoriutui nollasta mallia paremmin päättelyyn liittyvissä tehtävissä.

Tänään jaamme tarvittavan infrastruktuurin perustamisprosessin: alkuperäisen klusterin kokoamisesta ja käyttöjärjestelmän asentamisesta automaattisen palautuksen asettamiseen, kun koulutuksen aikana havaitaan virheitä. Kerromme kohtaamistamme haasteista ja ratkaisuista jokaisessa vaiheessa. Näiden oppien lisäksi julkaisemme myös monia matkan varrella kehittämiämme skriptejä, jotta muiden tiimien on helpompi luoda vakaa infrastruktuuri omaa malliharjoittelua varten.

Koko prosessin ajan insinööritiimimme työskenteli Voltage Parkin kanssa tietokoneklustereiden valmistelemiseksi ja perustan rakentamiseksi tuotantosovelluksille. Tämä koko prosessi sisältää:

1. Määritä jokainen kone

2. Määritä InfiniBand

3. Varmista, että kone on täysin terve

4. Diagnosoi yleiset harjoitusongelmat

5. Paranna infrastruktuurityökaluja

Jokainen vaihe on kuvattu yksityiskohtaisesti alla.

Taustaa: Miten se tehtiin

Tavoitteemme laskennan suorittamisessa on varmistaa nopea kokeilu suurilla kielimalleilla. Tätä varten tarvitsemme suuren määrän nopeita GPU:ita ja nopeaa tiedonsiirtoa näiden GPU:iden välillä.

Tämä artikkeli keskittyy klusteriin, joka sisältää 4088 H100-grafiikkasuoritinta, jotka on jaettu 511 tietokoneeseen tai 8 GPU:ta per tietokone. Syy siihen, miksi grafiikkasuorittimella varustettuja tietokoneita on 511, johtuu siitä, että jotkin yhteydet on varattava Unified Fabric Manager -solmulle, jonka tehtävänä on hallita InfiniBand-verkkoa. 511 GPU:lla varustetuissa isännissä jokainen GPU on kytketty suoraan ConnectX-7-verkkokorttiin, joka voi lähettää dataa 400 Gbps:n nopeudella mille tahansa InfiniBand-verkon grafiikkasuorittimelle.

InfiniBand-verkkotopologiamme on teoriassa "täysin ei-esto", mikä mahdollistaa GPU:n kommunikoinnin toistensa kanssa suurimmalla nopeudella. Tätä varten käytämme kolmikerroksista InfiniBand-verkkoarkkitehtuuria: kolmikerroksisia InfiniBand-kytkimiä. Oikeilla yhteyksillä tämä korkea suorituskyky voidaan saavuttaa koko verkossa. Seuraavassa kuvassa on yleiskatsaus tästä InfiniBand-verkosta:

Huomaa, että verkkoa harjoitettaessa tiedonsiirto tapahtuu InfiniBandin, ei Ethernetin kautta. Vaikka nämä koneet on kytketty myös Ethernetiin, tämän verkon tehtävänä on siirtää tietoja, kuten tietojoukkoja ja tarkistuspisteitä. Jos käytät Ethernetiä tiedon lähettämiseen, nopeus on paljon hitaampi, koska tiedot kulkevat ensin GPU:sta CPU:hun ja sitten ulos 100 Gbps:n Ethernet-kortin kautta. Vaikka on myös mahdollista harjoitella Ethernetin kautta käyttämällä RDMA over Converged Ethernet -tekniikkaa (RoCE), joka vaatii paljon lisätyötä sekä laitteisto- että ohjelmistopuolella ja on yleensä vähemmän luotettava kuin InfiniBand. Lisätietoja on tässä asiakirjassa: https://arxiv.org/pdf/2402.15627

On myös toissijainen Ethernet, jota käytetään vain konfigurointiin ja hallintaan, ja se tarjoaa pääsyn BIOSiin (Basic Input Output System), virtalähteeseen ja muihin ohjausliitäntöihin matalan tason koneliitäntöille. Ilman tätä hallintaverkkoa meidän olisi määritettävä jokainen solmu manuaalisesti USB-ohjaimen, näppäimistön ja näytön kautta. Tämä ei ole kestävä lähestymistapa tilanteissa, joissa on satoja koneita.

Suorituskykyisen koulutuksen saavuttaminen tässä klusterissa edellyttää, että kaikki komponentit (InfiniBand, Ethernet, GPU ja itse solmut) toimivat lähes täydellisesti. Jos jokin näistä yli 12 000 yhteydestä on hieman epävakaa, se voi hidastaa yleistä harjoittelua.

Tämän artikkelin loppuosassa kerrotaan, kuinka saada kaikki toimimaan täydellisesti ja vakaasti.

Prosessi: Kuinka muuttaa paljas metalli täysin toimivaksi klusteriksi

Määritä jokainen kone

Kun ensimmäinen Ethernet-yhteys klusteriin on muodostettu hallintaverkon kautta, saadaan käyttöoikeustiedot baseboard-hallintaohjaimeen (BMC). BMC on erillinen palveluprosessori, joka valvoo isäntäjärjestelmiä etäältä ja on yleensä yhdistetty erilliseen verkkoon. Sen avulla voimme käyttää konetta ikään kuin olisimme paikalla, ja lisäksi se tarjoaa API:t laitteiston kunnosta, BIOS-asetuksista ja virranhallinnasta.

Kun nämä komponentit ovat paikallaan, voimme kääriä hihat ja aloittaa klusterin perustamisen.

Vaihe 0: Määritä ensin kone

Aloitimme asentamalla Ubuntu 22.04:n palvelimelle iDRAC:in (Dell's Baseboard Management Controller) avulla ja määritimme sitten kaiken muun tähän käyttöjärjestelmään perustuvan. Yksi iDRACin ominaisuuksista on sallia ISO-otostiedostojen asentaminen ja käynnistäminen paikalliselta tietokoneelta ja tarjota virtuaalinen konsoli selaimen kautta. Ihannetapauksessa tämä on prosessin ainoa manuaalinen asennusvaihe.

Vaihe 1: Asenna käyttöjärjestelmä jokaiseen koneeseen

Kun olet määrittänyt ensimmäisen koneen, jatka Ubuntun Metal-as-a-Service (MAAS) -ohjelmiston asentamista muiden palvelimien määrittämiseen. iDRAC-käynnistys- ja automaatiotyökalu käyttää PXE-protokollaa (Preboot Execution Environment Protocol) ohjeistamaan jokaista konetta käynnistymään verkosta ja määrittämään MAAS:n vastaamaan PXE-käynnistyspyyntöihin. Suorittaessaan ensimmäistä verkkokäynnistystä palvelin hankkii IP:n ja alkuperäisen ytimen MAAS:lta Dynamic IP Allocation Protocol DHCP:n kautta ilman, että sen tarvitsee asentaa mitään paikalliselle asemalle. Tämä on perusympäristö toistettavien käyttöjärjestelmien asennuksien automatisoimiseksi. Teoriassa meidän on vain odotettava ensimmäistä käynnistystä ja kaikki hoidetaan. Käytännössä MAAS-integraatio BMC:n kanssa on kuitenkin epäluotettavaa, joten käytämme iDRAC API:a kerätäksemme etukäteen jokaisen koneen MAC-osoitteen (ainutlaatuinen fyysinen laitteistotunniste).

Koko tämän harjoitusprosessin ajan MAAS on usein nikamapinon luotettavampi komponentti. Kohtasimme kuitenkin alussa ongelmia, jotka olivat ainutlaatuisia asennuksessamme. Esimerkiksi kun määritin ensimmäisiä koneita, en voinut asentaa mitään apt:n kautta HTTPS-sertifikaatin vahvistusongelmien vuoksi, koska kellot olivat niin erilaiset. Tähän liittyen, koska MAAS-palvelimen on oltava vastuussa monista asioista (DHCP-palvelin, DNS-palvelin isäntänimien ratkaisemiseen IP-osoitteiksi, HTTP-välityspalvelin isännän ja virallisen Ubuntu-pakettipalvelimen välillä, NTP-palvelin, pilvi-init-konfiguraatioiden hallinta, maadoitus totuustietokanta, jota käytetään yhdistämään MAC-osoite IP-osoitteeseen isäntänimeen mukautettuihin metatietoihin), joten meidän on vaikea ratkaista näitä ongelmia perimmäisestä syystä. Lisäksi ongelmana on MAAS-kokoonpanon elinkaaren oppimiskäyrä, koska suunnittelun tavoitteena on käsitellä monimutkaisuutta, joka liittyy uusien käyttöönottojen hallintaan ja solmujen asteittaiseen siirtymiseen ja erilaisiin virheenkorjaus/epäterveellisiin välitiloihin.

Vaihe 2: Diagnosoi rikki kone

Havaitsimme, että noin 10 % koneista ei käynnistynyt, lähinnä palvelimen fyysisten ongelmien vuoksi. Tämä on yleinen skenaario suurten GPU-klustereiden määrittämisessä. Tapaamiamme tilanteita ovat: puuttuvat tai väärät verkkokaapelit, iDRAC:n laitteisto-ongelmat, vaurioituneet virtalähteet, vaurioituneet NVME-ajurit (haihtumattoman muistin nopeat) ohjaimet, puuttuvat sisäiset linjat, verkkokortit tai GPU:t eivät näy. Tarkistimme nämä ongelmat automaattisesti, palautimme jotkin koneet Delliin uudelleentestattavaksi ja lähetimme asianmukaiset työmääräykset palvelinkeskuksen henkilökunnalle. Yksi etu klusterin itse määrittämisessä on se, että voimme heti käyttää terveitä koneita odotellessamme joidenkin koneiden huoltoa.

Vaihe 3: Pienin elinkelpoinen havaittava kone

Jatkamme seuraavilla asetuksilla jokaisella palvelimella:

1. Docker (jotta helpotetaan palveluiden ja koulutustöiden suorittamista)

2. Datakeskuksen GPU-ohjain

3. Prometheus-solmun vientityökalu (käytetään vakaan laitteiston/käyttöjärjestelmän ilmaisimen datavirran vientiin)

4.DCGM-vientityökalu (käytetään lisäosoittimien, kuten grafiikkasuorittimen tilan, kellon ja käytön, viemiseen NVIDIA GPU:sta)

5. RAIDZ ZFS -pooli kaikille ei-käyttöjärjestelmän ohjaimille, jonka avulla kone voi jatkaa toimintaansa, vaikka ajuri epäonnistuu, samalla kun se tarjoaa läpinäkyvän pakkauksen ilmaiseksi (tämä on erityisen hyödyllistä pelkkää tekstiä sisältäville tietosarjoille ja toistuville lokeille - suhteellisen Tämän käyttäminen työkalu lisää tyypillisesti käytettävissä olevaa tilaa jopa 10 kertaa verrattuna siihen, että tätä työkalua ei käytetä)

Suoritamme sitten GPU:n perusdiagnostiikan määrittääksemme, toimiiko grafiikkasuoritin yleensä kunnolla – kaikki mikä ei toimi, johtaa yleensä laitteistoongelmiin muutaman tunnin sisällä.

Tänä aikana kohtasimme kaistanleveyden pullonkauloja yrittäessämme asentaa paketteja kaikkiin 400 solmuun samanaikaisesti. Tämä on ensimmäinen kerta, kun olemme saaneet korkean lämpötilan ylikuumenemisvaroituksia useista konesalissamme olevista komponenteista. Nämä ensimmäiset lämmitysongelmat on suurelta osin ratkaistu laiteohjelmistopäivitysten avulla.

Vaihe 4: Yhden solmun GPU-koulutus

Seuraava askel on varmistaa, että jokainen kone pystyy käsittelemään todellisia GPU-työkuormia yksin. Monet koneet eivät pysty tekemään tätä, ja ongelmia ovat mm.

Grafiikkasuorittimeen liittyvät virheet, jotka voidaan yleensä ratkaista asettamalla GPU-kortti uudelleen korttipaikkaan: Liu'uta 200 kiloa painava palvelin ulos telineestä, irrota kaikki kaapelit kannen ja grafiikkasuorittimen välillä ja irrota GPU, asenna GPU uudelleen ja sitten kytke kaapelit uudelleen ja työnnä palvelin takaisin telineeseen.

Ubuntu-palvelinlokien mukaan monet GPU:n ja PCIe-väylän tai verkkokortin väliset kaapelit antoivat tämän virheen: "rajoitettu leveys: x4 < x16". PCIe-kytkinväylän laiteohjelmiston päivityksen jälkeen havaitsimme, että noin neljäsosa isännistä vaati sisäisten PCIe-kaapeleiden uudelleenasennusta - oletettavasti siksi, että kotelon ja GPU:n väliset kaapelit ovat melko hauraita, eli aina kun GPU:ta huolletaan, nämä kaapelit työnnetään tai vedetään ulos.

Oli muutamia sekalaisia ​​katkoksia, jotka vaikuttivat myös useisiin isänteihin. Dell auttoi meitä ratkaisemaan joitain ongelmia laiteohjelmistopäivityksen yhteydessä:

NVMe-asema ei osoittanut häiriöitä, mutta lukitsi koko koneen koskettaessa.

Kiintolevyt näkyvät satunnaisessa järjestyksessä Linuxissa, mikä aiheuttaa sekaannusta MAAS-järjestelmässä ja aiheuttaa käyttöjärjestelmän asennuksen väärälle asemalle.

Lämpötilalukema on väärä, minkä vuoksi tuuletin käy koko ajan täydellä nopeudella. Syynä voi olla NVIDIA-ohjaimen ongelma, joka ratkaistaan ​​päivittämällä ohjainversio.

Prosessorin dynaaminen skaalaus meni käsistä, mikä rajoitti toimivat ytimet 2 GHz:iin.

Suoraa GPU-GPU-yhteyttä (GDR tai GPUDirect RDMA Peer Memory Client) ei voi käyttää onnistuneesti.

Määritä InfiniBand

Vaihe 0: Asenna UFM

Yksi InfiniBandin etu on sen keskitetty suunnittelu, jolloin koko verkossa on yksi aivo. Siksi meidän tarvitsee käsitellä vain yhtä 320 verkkokytkimen esiintymää koko verkkorakenteessa. Ensimmäinen tehtävämme oli selvittää, mikä kytkin kytkei mitkä koneet, sitten liittää se kytkentäkaavioon ja nimetä ne uudelleen kytkimen fyysisen sijainnin perusteella.

Vaihe 1: Uudelleenjohdotus

Aluksi UFM ei pystynyt havaitsemaan niitä 320 kytkintä, puhumattakaan isännistä, joiden piti olla kankaassa. Kuultuamme palvelinkeskuskumppaneitamme vahvistimme, että kytkimet olivat päällä ja johdotettu, mutta emme silti pystyneet havaitsemaan niitä. Verkkokaapelointiluetteloa tarkastellessamme havaitsimme, että verkkorakenteen huipputason suunnittelu oli virheellinen: yhtenäisyyden sijaan rakenne jaettiin kahdeksaan irrotettuun verkkoon, joilla ei ollut yhteistä reitityspolkua. Uudelleenjohdotuksen jälkeen lisäsimme tarkistusvaiheen varmistaaksemme, että kaikki fyysiset liitännät ovat uuden rakenteen mukaisia.

Vaihe 2: Kymmenen tuhatta lämpötilahälytystä (hälytys)

Kun fyysiset johdotusongelmat oli ratkaistu, InfiniBand loi onnistuneesti yhteydet kaikkiin verkkokankaan InfiniBand-kytkimiin. Lähes jokainen kytkinportti alkoi kuitenkin ilmoittaa liian korkeista lämpötiloista, joskus yli 70 °C:n, vaikka ne eivät lähettäneet tietoja. Huomasimme, että ongelma johtui avoimesta tilasta kytkinten välillä samassa telineessä, mikä sai kuumaa ilmaa virtaamaan takaisin eteen. Palvelinkeskuskumppanimme auttoi meitä diagnosoimaan ongelman nopeasti ja kehittämään asianmukaisen ratkaisun.

Vaihe 3: 1800 hälytystä

Monilla porteilla on myös korkea virheprosentti tai ne siirtyvät edestakaisin normaalin ja vioittun tilan välillä, jota kutsutaan "flappingiksi". Nämä ongelmat ilmenevät vain silloin, kun portteja todella käytetään, joten niitä on vaikea havaita etukäteen, koska koko rakenteemme koostuu 10 000 erittäin redundantista linkistä. Palvelinkeskuskumppanimme auttoi puhdistamaan ja asentamaan uudelleen hälyttimen portit, ja poistimme jäljellä olevat hälytyslähetin-vastaanottimet käytöstä odottaessamme vaihtoa.

Vaikka InfiniBand kestää laitteistovikoja, kun noin 10 % kudoksesta alkaa epäonnistua, ominaisuudet, kuten mukautuva reititys, eivät toimi luotettavasti ottamaan huomioon satunnaisen kadonneen linkin.

Tänä aikana suoritimme menestyksekkäästi monisolmukoulutusta 100-200 koneella. Prosessimme on hieman improvisoitu: toisinaan pyöritämme satunnaisia ​​solmuja, tarkkailemme niiden suorituskykyä ja yritämme sitten pitää mahdollisimman monet niistä käynnissä. Tämän menetelmän avulla voimme löytää luotettavan osajoukon InfiniBand-verkkorakenteesta, mutta se on erittäin vaikeaa, koska joka kerta meidän on vaihdettava harjoitteluun käytettyjä solmuja, mikä muuttaa oletusarvoista InfiniBand-linkkiä.

Vaihe 4: InfiniBand palaa kuin hullu

InfiniBand-ongelmien diagnosoimiseksi tehokkaammin suunnittelimme koko klusterin työtaakan, joka työnsi mahdollisimman paljon dataa kudoksen jokaisen portin läpi samanaikaisesti. Tämä eroaa suuren, täysin pienentävän työmäärän käyttämisestä koko klusterissa, mikä edellyttää NCCL:n käyttöä yksittäisten solmujen välisen viestinnän optimoimiseksi käyttämällä NVLinkkiä GPU-viestintään Server PCIe Module (SXM) -paikkojen kautta.

Sen sijaan valitsimme raakavoiman ja onnistuimme helposti. UFM alkaa antaa hälytyksiä, kun tiedonsiirron määrä useimmissa porteissa ylittää 97 % teoreettisesta kapasiteetista, ja jotkin kytkimet menevät tilapäisesti alas. Jokainen portti, jonka luulimme selvinneen päivän loppuun, oli riittävän vankka, ja loput poistettiin käytöstä tai poistettiin korjauksia odotellessa.

Vaihe 5: GPUDirect RDMA

Mahdollistaaksemme GPU-viestinnän ilman prosessorin ylimääräistä laskentaa otimme käyttöön GPUDirect RDMA -nimisen ominaisuuden, joka mahdollistaa suoran viestinnän InfiniBand-verkkokorttien välillä. Tämä sisältää kaksi keskeistä vaihetta:

1. Käynnistä ylimääräinen ydinmoduuli

2. Varmista, että PCIe Access Control Service (ACS) on poistettu käytöstä, jotta vältät välittömät jumiutumiset (välittömät jumittumiset).

Vaihe 6: Laajenna "kultainen" palvelin

GPU-klusterin rakentaminen uusimmalla laitteistolla on peukalosääntönä varauduttava siihen, että noin 3 % koneistasi epäonnistuu joka viikko.

On kuitenkin syytä huomata: jokaisella koneella ei ole tasaista 3 %:n vikaa, mutta pienellä osalla käsittelemättömiä koneita esiintyy erilaisia ​​ongelmia toistuvasti, kunnes ne korjataan kunnolla. Tämä korostaa suuren määrän koneita samassa verkkorakenteessa edut. Sen sijaan, että etsisimme vain satunnaisia ​​koneita suuren mittakaavan harjoittelua varten, kuten lyönti-mooli nähdäksesi, mikä hajoaa, lähestymistapamme on keskittyä luotettaviksi tiedettyjen palvelimien, "kultaisten" palvelimien skaalaamiseen.

Vaihe 7: Huolto

InfiniBandin ylläpito sisältää ensisijaisesti vastaamisen UFM-hälytyksiin, viallisten kaapeleiden ja lähetin-vastaanottimien vaihtamisen sekä ajoittain vaikeampien virheiden (kuten kytkinvikojen) diagnosoinnin. Laajamittaiseen kunnossapitoon johtavat yleensä kaksi tekijää:

1. Laiteohjelmistopäivitykset, varsinkin kun vain puolet klusterista on suorittanut päivityksen, voivat johtaa vioittuneeseen UFM-tilaan ja vaatia UFM-uudelleenkäynnistyksen kaikissa InfiniBand-kytkimissä.

2. GPU-laatikot käynnistetään massiivisesti uudelleen samaan aikaan, mikä saattaa lisätä UFM-tilaan suuren määrän päivityksiä ja vaatia myös UFM-palvelun uudelleenkäynnistyksen.

Varmista, että kone on täysin terve

Matkan varrella löysimme useita tapoja, joilla yksittäiset koneet voivat toimia virheellisesti tai hidastaa harjoittelua. Monet näistä vikatiloista eivät ole heti ilmeisiä, joten kirjoitimme useita kuntotarkistuskomentosarjat tarkistaaksemme, oliko isäntä tarpeeksi terve. Julkaisimme koodin täällä: https://github.com/imbue-ai/cluster-health

Huomaa, että monet näistä terveystarkastuksista ovat erityisiä ajonaikaisessa ympäristössämme eivätkä välttämättä liity taustalla olevaan laitteistoon, eivätkä ne ole välttämättä helppo korjata tai automatisoida. Tämä oli suunniteltu: saavuttaaksemme yleistavoitteen saada koneemme valmiiksi koulutukseen, halusimme yhden sisääntulopisteen, joka voisi vastata suoraan kyllä ​​tai ei ja joka voisi tiivistää useita hienoja yksityiskohtia.

GPU:n kuntotarkastus

Tarkistimme, että GPU:iden määrä oli oikea, että ECC (Error Correction Code) -tarkistus on käytössä ja ettei ECC-virheitä ollut. Tarkistimme myös, että NVLink-topologia (joka yhdistää GPU:t toisiinsa) on toiminnassa ilman virheitä.

Levytilan kuntotarkastus

Tarkistimme, ylittääkö isännän levytilan käyttöaste 95 %.

Dockerin terveystarkastus

Tarkistimme, että Docker voi ajaa säilöjä GPU:n ollessa kytkettynä (eli NVIDIA Container Runtime toimii oikein) ja että valvontaan/analyysiin liittyvät Docker-säilöt on aktivoitu ja niillä on oikeat isäntäoikeudet.

Dmesg terveystarkastus

Tarkistimme dmesg:stä laitteiston Xids- tai SXid-virheitä (NVIDIA-grafiikkasuorittimien tai GPU-välisten NVIDIA-kytkimien aiheuttamia vikoja). Luemme myös kaikki dmesg-lokirivit varmistaaksemme, että ne voidaan luokitella Common/Expected Log Lines -luetteloon.

iDRAC-terveystarkastus

Tarkistimme koneen iDRAC-virheitä, jotka jättivät huomioimatta ei-vakavia virheilmoituksia. Tämä on Dell-tietokoneille tarkoitettu tarkistus, joten se ei sisälly avoimeen lähdekoodiimme.

Levyn kuntotarkastus

Tarkistimme, että zpool on asennettu, että Docker on liitetty siihen oikein ja että se voi todella saavuttaa sen ilman prosessoria lukitsematta.

InfiniBand Health Check

Tarkistimme, onko InfiniBandin virheprosentti lisääntynyt ja/tai oliko ohjaimen laiteohjelmisto vanhentunut.

Nvlink terveystarkastus

Tarkistimme koneen NVLink-virheitä. Käytännössä tämä ei näytä aiheuttavan harjoitteluhäiriöitä, mutta saattaa hidastaa harjoittelua.

DDR:n terveystarkastus

Tarkistimme, onko GDR käytössä koneessa.

VBIOS terveystarkastus

Tarkistimme, että GPU:n VBIOS-versio ja H100-jalustan laiteohjelmisto olivat ajan tasalla.

Flintin terveystarkastus

Tarkistimme flintillä ja hca_self_testillä, että Mellanox OFED -ohjain, verkkokortin laiteohjelmisto ja lähetin-vastaanottimen laiteohjelmisto ovat oikeat versiot ja että ne on käännetty oikein NVIDIA-ohjaimelle.

PSB:n terveystarkastus

Kyselimme PCIe-laitteilta, olivatko GPU:n, PSB:n (PCIe Switch Bus) ja verkkokortin väliset yhteyden nopeus ja leveys sitä mitä odotimme. Tarkistimme myös, että kytkimen laiteohjelmisto on ajan tasalla. Tämän käsikirjoituksen on kehittänyt Dell, ei Imbue, joten emme voi jakaa sitä tällä hetkellä.

Näiden nopeiden terveystarkastusten lisäksi teemme myös joitain monimutkaisempia terveystarkastuksia, kuten:

Alusta matriisilaskelmat PyTorchin avulla ja mittaa NVLinkin kaistanleveyttä ja GPU:n laskentanopeutta ja muistia. Asetimme sopivat GDR-liput InfiniBandin ja NVLinkin testaamiseksi.

Käytä ib_write_bw:tä ja –use_cudaa tietojen lähettämiseen IB-kortin kautta ja mittaa PCIe- ja InfiniBand-kortin kaistanleveyttä. Tämä prosessi kesti pitkään (noin 15 minuuttia) varmistaakseen, että lepattava InfiniBand-linkki löytyi.

Suorita usean solmun diagnostiikkaajo tarkistaaksesi NCCL:n alustuskyvyn ja sen, pysähtyykö se satunnaisesti. Jos taukoja on, haarukka NCCL-koodimme lisää ylimääräistä kirjaamista. Tämä kestää 12–24 tuntia ongelman havaitsemiseen, joten suoritamme tämän yleensä vain uusissa solmuissa tai kun epäilemme ongelmaa.

Tarkista DCGM-viennistä GPU-kellon kuristustapahtumat (pois lukien odotetut gpu_idle ja power_cap). Näiden tehotapahtumien tarkistamiseksi paras tapa on suorittaa usean solmun koulutus, joka tarkistaa kaikki GPU:t, InfiniBand-kortit sekä CPU:t ja levyt samanaikaisesti.

Diagnosoi yleiset koulutusongelmat

Kun laitteisto toimii oikein, koulutus voi alkaa.

Tässä osiossa jaetaan joitain tiettyjä virheenkorjausvaiheita ja oivalluksia, jotka perustuvat kokemukseemme, joka perustuu laajan kielimallikoulutuksen suorittamiseen klusterissamme.

Kaatuu käynnistyksen yhteydessä

Tämä on tavallaan paras bugi, jonka voit kohdata, koska se on (teoreettisesti) helppo toistaa ja toistaa.

Tarkistimme ensin, että koodimme käytiin oikeilla versioilla, kokoonpanoilla ja ympäristömuuttujilla. Vaikka perustiedot, pidimme tämän kriittisenä: sen varmistaminen, että käynnistyskoulutusprosessi on toistettava ja helppo tarkistaa. Yksi syy on se, että väliabstraktit, kuten Docker-kuvan välimuisti tai läpinäkymättömät salaiset kokoonpanot, voivat aiheuttaa sekaannusta.

Toinen suorittamamme perustarkistus on varmistaa, että kaikki koneet ovat online-tilassa ja että pinojäljet ​​tai lähetetyt lokit voidaan helposti koota ja tarkastaa. Käytimme Loki-, Prometheus- ja Grafana-ohjelmistopinoja, mutta mikä tahansa sopiva lokin yhdistämis- tai seuranta SaaS-työkalu käy. Koska nämä harjoitusajot ovat synkronisia ja hajautettuja luonteeltaan, ensimmäinen virhe johtaa usein toisiinsa liittymättömien virheiden sarjaan. Terveystarkastukset voivat myös auttaa havaitsemaan välittömästi virheet, kuten vioittunut kiintolevy tai puuttuva tai virheellinen GPU.

Rakensimme järjestelmän, joka käynnistyy automaattisesti uudelleen vian sattuessa, mikä tekee lokien ja virheiden yhdistämisestä entistä tärkeämpää, jotta vältytään sekavista virheistä eri uudelleenkäynnistyksistä. Joitakin yleisiä kohtaamiamme virheitä ovat:

1. Virheet, kuten "Eteenpäin suuntautuva järjestys vaihtelee riveissä: sijoitus 0 kerää 43 parametria, kun taas sijoitus 1228 kerää 1 parametria". Löysimme tämän PyTorchin Fully Sharded Data Parallel (FSDP) -toteutuksen oudoksi piirteeksi, joka ratkesi uudelleenkäynnistyksellä.

2. GPU out of memory (OOM) -virhe, joka näyttää tältä: "CUDA muisti loppu. Yritti varata..." Tarkistamalla kokoonpanomme ja koodimme useita kertoja ja kumoamalla viimeisimmät koodimuutokset (johtuen virheellisistä PyTorch-laitemäärityksistä aikana käynnistyksen jälkeen, mikä johti GPU#0:n liialliseen käyttöön), korjasimme nämä ongelmat.

3. CPU/RAM Out of Memory (OOM) -virheet Näitä virheitä ei ole helppo löytää virhelokista, ja ne voidaan yleensä havaita Docker-säilön ulkopuolella olevan isännän dmesg-lokin kautta. Kun OOM Killer pyytää pysäyttämään haaroittuneen prosessin tai verkkoverkon, voimme nähdä, että ne ilmenevät pääasiassa nimellä CalledProcessError tai ConnectionError. Kun OOM Killer -kutsu havaitaan dmesg:stä, me mieluummin hylkäämme kuntotarkastuksen ja käynnistämme laatikon uudelleen. Tarkistimme myös koodipolkumme riittävän manuaalisen roskienkeräyksen varalta (alla on osio tämän poistamisesta käytöstä) ja tarkistimme myös odottamattomien laskutoimitusten tai tensoreiden siirtämisen prosessorille.

Törmäys harjoituksen aikana

Ensimmäinen prioriteetti on automatisoida järjestelmä niin, että se voi automaattisesti suorittaa kaikki kuntotarkastukset uudelleen ja käynnistää sen sitten uudelleen, jos epäterveellistä isäntä ei löydy. Havaitsimme joitain satunnaisia ​​laitteistovirheitä, mukaan lukien Xid- ja SXid-virheet, jotka voivat aiheuttaa ajon kaatumisen lähettämättä merkityksellistä Python-pinojäljitystä. Jotkut ongelmat, kuten rivien uudelleenkartoitus, voidaan korjata käynnistämällä uudelleen. Muut ongelmat, kuten korjaamattomat ECC-virheet, vaativat usein laitteiston huoltoa tai osien vaihtoa.

Lisäksi havaitsimme, että virheelliset harjoitustiedot voivat myös aiheuttaa kaatumisia. Jos esimerkiksi korpuksessa on erittäin suuri yksittäinen asiakirja, se voi aiheuttaa grafiikkasuorittimessa tai prosessorissa muistin lopussa -virheen. Tämän ongelman estämiseksi käytämme täysin determinististä tiedonlataajaa, mikä tekee jokaisen kaatumisen helposti toistettavissa sidottuna epookkiin tai askelnumeroihin. Olemme havainneet, että tietojen lataamisen poistaminen käytöstä tai väärennettyjen tietojen (kuten täysin nollatietojen) korvaaminen auttaa varmistamaan, onko virheen perimmäinen syy tiedoissa.

Lopuksi voi myös olla hyödyllistä tallentaa verkon ja yleisten solmujen kuntotilastoja metrien yhdistämismenetelmien avulla. Ongelmat, kuten lyhyt Ethernet-yhteyden katkeaminen tai vähän levytilaa, eivät välttämättä näy hyödyllisinä virheilmoituksina, mutta ne voidaan helposti korreloida kerättyjen tietojen kanssa.

Pysy ilman pinon jälkiä (myöhemmin saattaa ilmetä aikakatkaisuongelmia)

Koska näistä ongelmista ei ole hyödyllistä tietoa ja koska niiden luotettava toistaminen on vaikeaa, tämäntyyppisten virheiden virheenkorjaus voi olla turhauttavaa.

Yksi mieleenpainuvimmista virhetyypeistä liittyy seuraavankaltaisiin virheilmoituksiin:

Watchdog kiinnittyi kollektiivisen toiminnan aikakatkaisu: WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) kesti 600351 millisekuntia ennen aikakatkaisua

Ja kaikki koulutusajon GPU-työntekijät antoivat tällaisia ​​virheilmoituksia.

Tämä tarkoittaa, että yksi tai useampi isäntä ei pystynyt suorittamaan NCCL-toimintoa loppuun tai NCCL- ja InfiniBand-yhteydet kaatui, minkä seurauksena kaikki muut isännät juuttuivat tensoritoimintoon samaan aikaan, kunnes NCCL_TIMEOUT-aikakatkaisu saavutettiin. Valitettavasti NCCL-ohjelmistokirjaston luonteen vuoksi on vaikea löytää isäntä, jolla on ongelma.

Olemme tehneet joitain muutoksia NCCL-ohjelmistokirjaston kirjaamiseen, katso haarukkaversiomme: https://github.com/boweiliu/nccl. Tämä saattaa paremmin paljastaa viestit tai toiminnot, jotka suoritetaan kaatumisen sattuessa, ja siten määrittää, mikä isäntä tai GPU saattaa estää sen toiminnan.

Huomaa, että huonosti toimivien isäntien tunnistamiseksi meidän on usein selvitettävä, mitkä isännät eivät luo tiettyjä lokiviestejä. Tällaisten viestien puuttuminen osoittaa, että tämän isännän työntekijä on jäänyt jälkeen tai kaatunut.

Muut reagoimattomat tilanteet, joissa ei ole saatavilla virheilmoituksia, liittyvät yleensä laitteistoongelmiin, kuten aiemmin mainittuihin Xid/SXid/ECC-virheisiin, jotka aiheuttavat NVIDIA-ohjaimen tai NVIDIA Docker -viestintäohjaimen lukkiutumisen. Erottaaksemme NCCL-jumittumisen kuljettajien jumiutumisesta ja kilpailuolosuhteista tai umpikujasta Python-koodissa käytämme Py-Spyn ja GNU Project Debuggerin (GDB) kaltaisia ​​työkaluja jumiutuneiden prosessien virheenkorjaukseen reaaliajassa. Yksi erityinen ongelma havaittiin käyttämällä tätä lähestymistapaa: Python-säikeen asetusvirheen vuoksi emme pystyneet käynnistämään oikein kahdeksaa monisäikeistä NCCL GPU -prosessia joillakin isännillä, jotka kohtasivat kilpailutilanteen alustuskoodivaiheessa ennen PyTorchia.

Harjoittelun hidastuminen (MFU:lla mitattuna)

Työkalujen puute tekee tämäntyyppisestä ongelmasta vielä turhauttavamman kuin edellinen. Py-Spyn, pinojäljityksen ja GDB:n käytön lisäksi käytimme myös NVIDIA Nsightia ja profilointityökaluja, joista osaa on vaikea käyttää erittäin hajautetuissa olosuhteissa.

Valitettavasti yleiseen hidastumiseen tai pienempään nopeuteen on monia syitä kuin aiemmin osoitettu mallin liukulukukäyttö (MFU).

Ensinnäkin on hyödyllistä tarkistaa kokoonpano-, koodi- ja ympäristömuuttujat useita kertoja. Kokemamiamme virheitä ovat muun muassa väärä malli, väärä eräkoko, väärät UFM- tai NCCL-asetukset, CUDA_DEVICE_MAX_CONNECTIONS virhettä. Tämä johtaa optimaalista huonompaan suorituskykyyn.

Mielestämme on myös hyödyllistä mitata hetkellinen (eli eräkohtainen) MFU (eikä tasoitettu tai ikkunallinen keskiarvo), koska tasoittamattomat MFU-käyrät auttavat usein diagnosoimaan ongelmaluokkia. Ongelmia, jotka hidastavat harjoittelua, ovat:

Aloita harjoittelu heti erittäin alhaisesta MFU:sta (alle kymmenesosa odotetusta) ja pysy vakaana

Tämä on todennäköisesti InfiniBand-verkkoyhteyden laitteisto-ongelma, kuten T2- tai T3-kerroksen kytkimen kaatuminen. GPU:n ja NIC:n väliset laitteisto-ongelmat voivat myös aiheuttaa tämän tilanteen, jolloin dmesg ilmoittaa seuraavanlaisen virheen: PCIe x16 -kaistat rajoittavat…

Aloita harjoittelu heti 30 %:sta odotetusta MFU:sta ja pidä paikallaan

Tämä voi johtua virheellisistä GDR-asetuksista yhdellä isännällä (NVIDIA-vertaismuisti) tai virheellisistä GDR-ympäristömuuttujista.

Aloita harjoittelu välittömästi noin 60-80 %:sta odotetusta MFU:sta ja pysy vakaana

Yleisin syy on InfiniBand-linkin huono tai viallinen laatu, erityisesti InfiniBand NIC:hen liittyvä virhe yksittäisessä GPU:ssa, mikä saa NCCL:n yrittämään reitittää liikennettä alkuperäisen NVLinkin kautta ja käyttämään NIC:tä toisessa saman isännän GPU:ssa. Prosessorin kuristus voi myös aiheuttaa tämän ongelman, mikä edellyttää joidenkin isäntien BIOS-asetusten säätämistä.

Äkillinen valtava hidastuminen (10-kertainen) tiettyjen tietoerien käsittelyssä, ja tämä tapahtuu melko usein

Tässä on pohjimmiltaan kyse tarkistuspisteistä tai arvioinnista - tämä voidaan varmistaa tarkistamalla aikakausien tai vaiheiden lukumäärä. Ärsyttävästi, jos asetat automaattisen hälytyksen, kun MFU on epänormaali, näkyviin tulee monia vääriä hälytyksiä.

Äkillinen valtava hidastuminen (10x pudotus) tiettyjen tietoerien käsittelyssä

Tämä tapahtuu satunnaisesti ja melko harvoin (noin kerran 15 minuutin välein), ja sitä seuraa välittömästi täydellinen paluu hyvään MFU:han.

Yleisin syy näyttää olevan se, että muut suoritinintensiiviset työkuormat ajoitetaan käynnissä olevalle isännälle. Huomasimme, että sen sijaan, että olisi luotu profilointityökaluja tiettyjen isäntien tunnistamiseksi, oli helpompi seurata suoritinta karkeasti PID:n avulla. Syynä voivat olla satunnaiset verkkoyhteysongelmat, kuten tiedonlatauksen pullonkaulat. Valvoimme datalatauksia, tarkistuspisteitä ja mittareita kaikkien ei-NCCL-koodien varalta ja lisäsimme Python-koodin ajoituslokeja, jotka osoittautuivat erittäin luotettaviksi.

MFU hidastuu asteittain käytön aikana, mutta palaa 100 %:iin jokaisen uudelleenkäynnistyksen jälkeen

Teoriassa syynä voi olla kytkimen kuumeneminen, mutta emme ole koskaan nähneet tällaista tapahtuvan. Käytimme kuitenkin Python- ja NVIDIA-profiileja määrittääksemme, että suorituskyvyn heikkenemisen syy näyttää olevan automaattinen roskien kerääminen.

Näitä hidastuksia tehdessämme virheenkorjauksen havaitsimme, että suorituskyvyn oli melkein pakko laskea ajoittain. Koulutuksen edetessä tällä laskulla on kasvava vaikutus hajautettuun tietojenkäsittelyyn. Tämä sai meidät epäilemään, että pudotuksen syy saattaa liittyä automaattiseen jätteiden keräämiseen - olettamuksen, jonka vahvistimme analysoimalla ja testaamalla. Kun poistimme automaattisen roskankeruun käytöstä ja asetimme roskien keräyksen vain tietyin väliajoin kaikilla isännillä, tämä suorituskyvyn "pudotus" katosi.

Käytimme ZeRO-3:een perustuvaa synkronista hajautettua harjoitusalgoritmia FSDP. Estotoiminnon aikana yhden työntekijän prosessi, joka suorittaa roskienkeruuta, voi hidastaa kaikkia muita työntekijöitä. Jos sinulla on satoja työntekijöiden prosesseja, tämä voi aiheuttaa merkittäviä hidastuksia.

Suorituskyky on aluksi hyvä, sitten laskee yhtäkkiä (70 prosenttiin odotetusta) ja jatkuu korkealla taajuudella (15 sekunnin välein)

Havaitsimme tämän liittyvän NVIDIA GPU:iden "kellon kuristussyihin", jotka voidaan ratkaista asianmukaisilla NVIDIA DCGM:n asetuksilla. Lämpöongelmat (korkea grafiikkasuorittimen lämpötila tai isännän jäähdytystuulettimen vika / tehon heikkeneminen) tai virtalähteen vika voivat aiheuttaa tämän ongelman. Lisäksi, kun maksimoimme kaikki 8 GPU:n ja 8x NIC InfiniBand -käytön sekä suorittimen/RAM-/levyn, joillakin isännillämme, joilla on tietty virtalähdelaitteisto, on jänniteongelmia, mutta ne käyttävät vain niitä kaikkia (yleensä vain käytössä. Tämä tapahtuu vain varsinainen harjoituslenkki).

Hyvä suorituskyky, mutta tavallista enemmän kohinaa (korkean taajuuden valkoisen kohinan varianssi 90–100 % odotetusta MFU:sta)

Tämä liittyy myös InfiniBand-laitteistoon, mutta johtuu yleensä jonkinasteisesta suorituskyvyn heikkenemisestä tai tärinästä verkon ylempänä olevissa linkeissä, eikä T2-kerroksen vähemmän redundanttisista isännistä.

Valitettavasti monia näistä ongelmista on vaikea määrittää tietylle isännälle, ja InfiniBandiin liittyviä ongelmia on erityisen vaikea havaita InfiniBand-kytkintekniikan topologiatietoisen luonteen vuoksi. InfiniBand näyttää suosivan vierekkäisiä isäntiä InfiniBandin rasvapuussa, kun taas UFM voi reitittää paketteja epäsymmetrisillä linkin nopeuksilla.

Seuraava on yksinkertainen yhteenveto/vuokaavio/täydellisyyden tarkistuslista suorituskyvyn ongelmien vianmääritykseen:

Toimiiko tämä järjestelmä ennen kunnolla?

Mitä muutoksia olet tehnyt viime aikoina (kuten koodin yhdistäminen, ohjainten päivittäminen)?

Onko ohjaamasi isäntä terve? Toimivatko kaikki riippuvaiset palvelusi normaalisti, mukaan lukien kolmannen osapuolen SaaS, kuten Docker Hub, GitHub jne.?

Voitko olla varma, että käyttämäsi koodi, ympäristö, kokoonpano, versio, isäntäluettelo, sijoitusjärjestys ja satunnainen siemen ovat täsmälleen samat kuin viime kerralla? (Jos tällainen tarkistus voitaisiin toteuttaa.)

Onko ongelma toistettava?

Miten se liittyy muihin asioihin? Muut prosessit? Päivittäiset crontab ajoitetut tehtävät? Isäntä vai DCGM tai UFM-ilmaisin?

Mittaako työkalusi näitä mittareita oikein?

Jatkuuko ongelma käytettäessä koodin poistettua versiota (pienempien mallien, väärennetyn datan, tarkistuspisteiden tallentamatta tai lataamatta jättämistä varten)?

Paranna infrastruktuurityökaluja

Kun olet suorittanut yllä olevat vaiheet, olet matkalla saavuttamaan hyvää suorituskykyä harjoittaessasi malliasi... ainakin siihen asti, kunnes jokin rikkoutuu.

Tässä osiossa esitellään joitain työkaluja ja järjestelmiä, joilla varmistetaan johdonmukainen koulutus, mutta ihannetapauksessa ne edellyttävät mahdollisimman vähän ihmisen puuttumista. Koska olemme pieni tiimi, meillä ei ole tarpeeksi työvoimaa manuaalisten korjausten tekemiseen, joten haluamme myös automatisoida tämän prosessin mahdollisimman pitkälle.

Lähes kaikki harjoittelun aikana kohtaamamme ongelmat voivat johtua koneen tai verkkokomponenttien viasta. Tämäntyyppiset viat ovat yleisiä suurissa klustereissa, joten lähestymistapamme on poistaa vialliset kone- ja verkkokomponentit automaattisesti käytöstä ja lähettää korjauspyyntö.

koneen toimintahäiriö

Kehitimme järjestelmän, joka käynnistyy automaattisesti uudelleen viimeisimmästä tarkistuspisteestä, jos ajo kaatuu. Tässä uudelleenkäynnistysprosessissa jokaisen käytettävissä olevan koneen kunto tarkistetaan ensin, minkä jälkeen jokainen kone luokitellaan sen läpäisemien kuntotarkastuksen tulosten perusteella. Tämän jälkeen harjoitus yritetään käynnistää uudelleen terveimmällä koneella.

Verkkokomponentin vika

UFM havaitsi kaikki havaitsemamme verkkovirheet ja kirjasi ne UFM-tapahtumalokiin, joten vastaus oli yksinkertainen: jäsennä UFM-loki ja ryhdy tarvittaviin toimiin.

UFM-tapahtumajärjestelmä on erittäin monimutkainen ja sisältää kymmeniä tapahtumatyyppejä. Käytännössä havaitsimme kuitenkin, että vain harvat tapahtumat olivat ongelmallisia, lähinnä linkkien epäonnistumisesta tai suurista symbolivirhetekniikoista. Kun nämä tapahtumat on tunnistettu, voimme kirjoittaa komentosarjoja jäsentääkseen UFM-tapahtumalokin, poistaa käytöstä viimeaikaisiin tapahtumiin liittyvät linkit ja portit, pyytää ylläpitotyömääräyksiä näille verkkokomponenteille ja ottaa nämä komponentit uudelleen käyttöön huollon päätyttyä.

paikallinen peilitiedostojärjestelmä

Näille suurille hajautetuille koulutuksille on jo pitkään havaittu, että klusterin ja Ethernetin välisen tiedonvaihdon nopeus on pullonkaula. Jaetun Ethernet-yhteyden kaistanleveys on noin 10 Gbit/s. Tämä kaistanleveys voi kyllästyä nopeasti, jos sadat työntekijät lataavat tietojoukkoja ja mallintavat tarkistuspisteitä samanaikaisesti.

Tätä tarkoitusta varten päätimme rakentaa klusteriimme paikallisen tiedostojärjestelmän pilvitallennustilan peiliksi, joka on pohjimmiltaan välimuistitila, joka voi vähentää S3:sta luettavien tiedostojen määrää. Klusterin vaihtuvuuden huomioon ottamiseksi (eli kun kone poistetaan käytöstä tai vaihdetaan huoltosyistä), meillä on kolme kopiota kustakin tiedostosta ja käytämme johdonmukaista tiivistystä kuormituksen jakamiseksi tasaisesti suorituskyvyn maksimoimiseksi klusterin vaihtuvuuden aikana. Vähennä tiedoston liikettä merkittävästi. Koska klusterilla on rajoitetusti levytilaa, jouduimme kehittämään työkaluja tiedostojen elinkaaren seurantaan ja tarpeettomien tiedostojen poistamiseen.

Paikallinen hajautettu Docker-rekisteri

Käytimme Krakenia, joka on loistava avoimen lähdekoodin ohjelmisto Docker-kuvien siirtämiseen pisteestä pisteeseen. Ohjelmiston kanssa meillä ei ollut juuri mitään ongelmia, mikä oli meille yllättävää, kun otetaan huomioon tehtäviemme ja toteutuksen monimutkaisuus. Työkalun osoite: https://github.com/uber/kraken

Erilaisia ​​suorituskyvyn seurantatyökaluja

Asensimme oletusarvoisen Torch-analysaattorin ja NVIDIAn Nsight Systemsin. Jälkimmäinen auttaa meitä ymmärtämään tarkan ajan, joka tarvitaan eteenpäin/taakse-ajoihin ja NCCL-viestintään, ja lisäksi auttaa meitä määrittämään, tuleeko tietystä mallin koosta ja työntekijöiden määrästä pullonkaula. Nsight Systemsin käyttö on kuitenkin hieman hankalaa, koska se vaatii Dockerin ajamisen etuoikeutetussa tilassa, mikä edellyttää suorituskyvyn seurantatapahtumiin liittyvien turvatarkistuksia poistamista käytöstä, ja sen konfiguraation tallentaminen vaatii usein koko koulutusprosessin pysäyttämistä.

Lisäksi olemme kirjoittaneet työkaluja hitaiden harjoituserien havaitsemiseen ja niiden mahdollisten syiden ymmärtämiseen. Löysimme tämän hyödyllisenä. Hyödyllisin työkalu valvoo, kuinka kauan kukin erä kestää, ja hylkää työntekijän pinojäljityksen, jos erä on liian hidas - mikä helpottaa pienten laitteisto- tai ohjelmisto-ongelmien löytämistä.

Jaa koneet eri ryhmiin löytääksesi epäonnistuneet isännät

Ensimmäisten klusterin käyttökuukausien aikana (kun terveystarkastukset eivät olleet niin perusteellisia kuin nykyään) kohtasimme usein tilanteen, jossa koneryhmässä harjoittelussa tapahtui vika, mutta ei ollut selvää, missä koneessa ongelma oli. . Viallisten isäntien löytämiseksi kehitimme työkaluja, joiden avulla on helppo jakaa koneita eri ryhmiin ja suorittaa pienempiä koulutuksia jokaiselle koneryhmälle.

Jos esimerkiksi harjoitusajo 48 koneella epäonnistuu, suorita pienempi harjoitusajo kuudella 8 koneen ryhmällä ja suorita sitten pienempi harjoitus 8 6 koneen ryhmällä. Tyypillisesti vain yksi ajo kahdesta vaiheesta epäonnistuu, mikä antaa meille luottamusta päätellä, että kone, joka epäonnistuu molemmissa vaiheissa, on viallinen.

Pohdintaa ja opittuja asioita

Infrastruktuurin perustamisen ja ylläpidon aikana saimme hyödyllisiä opetuksia:

Yksi hyödyllinen tapa on vaihtaa koneiden sijaintia. Ajon aikana voi olla hyödyllistä käyttää 10-20 % enemmän koneita kuin tarvitaan, jotta koulutus voidaan helposti aloittaa uudelleen konevian sattuessa. Klusteriverkkojen määrittäminen siten, että jokainen kone on tiiviisti kytketty jokaiseen toiseen koneeseen, mahdollistaa näiden koneiden minkä tahansa toimivan osajoukon käytön.

Testejä ja automaattisia ratkaisuja kannattaa kirjoittaa jokaiseen kohtaamasi laitteisto- tai ohjelmistovikaan, koska jokainen koulutuksessa havaittu ongelma toistuu. Samoin jokaiselle epäselvälle virheilmoitukselle kannattaa kirjoittaa työkalu, joka selittää virheen paremmin.

Uusittavuus on hyvän tieteellisen tutkimuksen avain. Yksi suurista periaatteista, jonka omaksuimme heti, oli: "Vaihda vain yksi asia kerrallaan", jopa yksinkertaisissa asioissa.

Luota, mutta myös varmista. Aina kun otamme käyttöön ulkoisia työkaluja tai uusia ihmisiä (joko yrityksen sisältä tai ulkopuolelta), tarkistamme heidän väitteensä, varsinkin jos myöhemmät vaiheet riippuvat näistä väitteistä.

Tee yhteenveto

Suurten kielimallien kouluttaminen vaatii alusta alkaen monimutkaista infrastruktuuria. Päätimme osallistua infrastruktuurin perustamisen yksityiskohtiin, koska uskomme, että on tärkeää ymmärtää täysin käyttämiämme järjestelmiä ja koska uskomme, että se on tehokkaampaa.

Nyt, kun olemme käyneet läpi prosessin, olemme iloisia, että valitsimme tämän lähestymistavan – infrastruktuurimme täydellinen hallinta ja kyky tehdä helposti virheenkorjaus kaikilla abstraktiotasoilla on osoittautunut kriittiseksi arvoksi. Vaikka tämä prosessi vaati paljon valvontaa ja iterointia, sen avulla saimme syvällisen ymmärryksen taustalla olevasta työnkulusta, rakentaa joukon työkaluja varmistaaksemme isännän terveyden, oppia automatisoimaan järjestelmän jatkuvan sujuvan koulutuksen varmistamiseksi ja lopulta rakentamaan Joukko infrastruktuuria, jonka avulla voimme kouluttaa nopeasti ja iteratiivisesti huippuluokan kielimalleja.

Tämä infrastruktuurin rakennusprosessi heijastaa perusmetodologiaamme tekoälyagenttien tutkimiseen ja rakentamiseen: yksityiskohtien tutkiminen, olemassa olevien prosessien jatkuva parantaminen ja hyödyllisten työkalujen ja järjestelmien rakentaminen, jotta motivoitunut tiimimme voi vastata suurempiin haasteisiin.