Vissza a felfedezéshez
HírekFejlesztés AI-val

A Databricks szerint nyolcszorosára nőtt a tréningfeladatok száma az AI-ügynökök mellett

A Databricks saját AI Runtime rendszerében ügynökök futtatnak párhuzamos kísérleteket, az infrastruktúra terhelését pedig állapotellenőrzés, ütemezés és szabályozott adatkezelés fogja össze.

Párhuzamos kutatási kísérletek követett tanítási állomásokon, elkülönített hibás állomással és visszaállított ellenőrzőponttal.
CurioFuse · AI-illusztráció
Ebben a cikkben

Több kísérlet mellett máshová kerül a szűk keresztmetszet

A Databricks szerint AI-kutatói már szoftveres ügynökökkel javasoltatnak modellmódosításokat, indítanak párhuzamos tréningeket, értékelik az eredményeket és választják ki a következő próbát. A cég október 15-i mérnöki írása szerint az AI Functions kutatási terheléseiben nyolcszorosára nőtt a tréningfeladatok száma. Ez a szám a feladatok mennyiségét jelzi, nem a modellminőség, a kutatói termelékenység vagy a költséghatékonyság nyolcszoros javulását.

A munkafolyamat a Databricks AI Runtime, röviden AIR nevű, kiszolgáló nélküli GPU-szolgáltatásán fut. A kutatócsoport a rendszer tavalyi fejlesztési kezdete óta belső korai felhasználó. Ugyanez a csapat dokumentumfeldolgozó és strukturált adatkinyerő funkciókon is dolgozik. A Databricks közlése szerint a kísérletek a kis hibakeresési futásoktól a több száz GPU-n napokig vagy hetekig tartó tréningekig terjednek; a modellek mérete néhány milliárdtól közel ezermilliárd paraméterig ér.

Az ügynökök mögött hibatűrő infrastruktúra kell

Egy önálló kísérleti ciklus több munkát indíthat, mint egy ember, aki sorban kezeli a feladatokat, de a hétköznapi hibákat is megsokszorozza. Egy hosszú, elosztott futás elveszíthet egy gépet, GPU-k közötti kommunikációs hibába ütközhet, túlmelegedés vagy teljesítménykorlátozás lassíthatja, illetve illesztőprogram-probléma állíthatja le. A Databricks szerint az AIR indulás előtt ellenőrzi a gépeket, futás közben figyeli a hardvert és a hálózatot, hiba után pedig kizárja az egészségtelen csomópontokat a későbbi ütemezésből.

A kutatók parancssori felületről küldik be a munkákat, a környezetet pedig egyedi konténerekbe csomagolják, így hasonló szoftver mozoghat a helyi fejlesztéstől a nagy futásokig. A platform az MLflow kísérletkövető rendszerben rögzíti a paramétereket, naplókat és mérőszámokat. Az ügynökök ezeket lekérhetik, majd ezek alapján választhatják ki a következő próbát. A Unity Catalog ismerős fájlrendszerként teszi elérhetővé a szabályozott kutatási adatokat, míg a prioritási és megszakítási szabályok döntik el, melyik munka kapja a szűkös GPU-kat. A cég szerint az alacsonyabb prioritású kísérletek a hétvégi szabad kapacitást is felhasználhatják.

Belső esettanulmány, nyilvános előzetes szolgáltatás

A termékdokumentáció az AIR-t nyilvános előzetes, vagyis Public Preview állapotú szolgáltatásként jelöli, nem általánosan elérhető termékként. Kiszolgáló nélküli GPU-s számítást, előre összeállított környezeteket, notebookos és fejlesztőkörnyezeti hozzáférést, parancssori és ügynöki munkafolyamatokat, Ray-támogatást, adatbetöltőket és MLflow-megfigyelhetőséget sorol fel. Az előzetes állapot azért lényeges, mert a funkciók és működési feltételek még változhatnak.

A Databricks írása a saját platformját használó saját kutatók részletes esete. Nem közöl abszolút feladatszámot, hibaarányt, teljes GPU-fogyasztást, kísérletenkénti költséget, sem azt, hogy a több próba jobb éles modellekhez vezetett-e. A megalapozott következtetés ezért architekturális: amikor az ügynökök folyamatosan indíthatnak kísérleteket, a gyors feladatindítás, a hibák utáni helyreállás, az ütemezés, a kísérletek eredetének követése és az ellenőrzött adathozzáférés a kutatási módszer részévé válik. A nyolcszoros növekedés az aktivitás bővülését mutatja, annak értékét önmagában nem.

Források(2)

Források és alapelvekJavítás jelzése