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.
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)
- How our AI Research team uses AI RuntimeEllenőrizve:
- Databricks AI RuntimeEllenőrizve: