A PyTorch új CI-rendszere az egyedi gyorsítók tesztelését segíti
A PyTorch Cross-Repository CI Relay rendszere egységesebb kapcsolatot kínál a PyTorch és a külső fejlesztésű gyorsítók között. A Torch Spyre erre építve olyan tesztelési folyamatot alakított ki, amely kód- és futási adatok alapján választja ki a hardver szempontjából fontos teszteket.
- A CRCR a PyTorch és a külső gyorsítóprojektek CI-folyamatait kapcsolja össze.
- A Torch Spyre kód- és futási adatok alapján választja ki a releváns teszteket.
- A tesztek indoklása a konfigurációban marad, így a döntések felülvizsgálhatók.
- A rendszer az új operátorok és a változó PyTorch-tesztek kezelését is támogatja.
- A Torch Spyre elérte a CRCR L2 integrációs szintjét.
Közös felület a PyTorch és a külső gyorsítók között
A PyTorch szeptember 30-án bemutatott bejegyzése szerint a Cross-Repository CI Relay, röviden CRCR, szabványos módot ad a PyTorch-on kívül fejlesztett gyorsítóprojekteknek arra, hogy bekapcsolódjanak az upstream, vagyis a központi PyTorch-kódbázis folyamataiba.
A rendszer képes változásokat küldeni a külső tárolókban futó folyamatos integrációs folyamatoknak, az eredményeket pedig közvetlenül megjeleníti a PyTorch felülvizsgálóinak. A regressziók egy közös nézetben, a PyTorch CI CRCR HUD felületén követhetők. Az alapintegrációhoz engedélyezési lista, egy, a repository_dispatch eseményre figyelő munkafolyamat, valamint egy összetett visszahívási művelet szükséges.
A CRCR négy integrációs szintet kínál. A projektek fokozatosan juthatnak el az értesítések fogadásától az eredmények HUD-on történő jelentésén át addig, hogy a külső kód az upstream pull requestek ellenőrzésében is részt vegyen.
A Torch Spyre három változóval számol
A Torch Spyre az IBM Spyre Accelerator PyTorch-háttérrendszereként mélyen kapcsolódik a PyTorch külső bővítési felületeihez. Emiatt a tesztelésnek egyszerre kell figyelembe vennie a gyorsító saját háttérkódját, a PyTorch központi kódját és a folyamatosan változó tesztcsomagot.
Mindhárom területen megjelenhetnek regressziók. Egy új PyTorch-módosítás, a háttérrendszer frissítése vagy egy teszt megváltoztatása is okozhat hibát. A legfontosabb kombináció ezért a háttérkód, a PyTorch-mag és a tesztcsomag legfrissebb állapota. Ez segíthet a regressziók azonosításában, különösen akkor, ha az előző sikeres futás óta csak az upstream kód változott.
A CRCR egyes kombinációkat külön feladatként is képes jelenteni a HUD-on. Így külön követhetők például az eltérő háttérverziókhoz kapcsolódó eredmények és regressziók.
Ügynöki folyamat választja ki a releváns teszteket
A PyTorch több tízezer tesztje miatt a kézi kiválasztás és a lista folyamatos karbantartása nehezen skálázható. A Torch Spyre ezért négylépcsős, ügynöki folyamatot épített ki.
Az első lépés a tesztfát szűkíti a háttérrendszer által használt PyTorch-bővítési pontok és a megadott hatókör alapján. Ha egy háttér például nem használja a torch.dynamo részt, vagy még nem támogatja az automatikus deriválást, az ehhez kapcsolódó területek kihagyhatók.
Ezt követően egy Repository Memory Generator kereshető indexet készít a jelöltekről. Az index szimbólumokat, fájlokat, nyelvi modell által készített összefoglalókat és tesztenkénti beágyazásokat tartalmaz. A következő kiválasztási lépés a háttérkódot, a dokumentációt és a támogatott operátorok metaadatait vizsgálja, majd a teszteket a kötelezően sikeres, illetve a kihagyandó kategóriába sorolja. Az egyes döntések indoklása bekerül a konfigurációba.
A kiválasztott tesztek valódi hardveren is lefutnak. A folyamat a futási naplók alapján újraértékeli a listát, így olyan futásidejű hibák és numerikus eltérések is feltárhatók, amelyek statikus elemzéssel nem látszanak. Az eredmény fájlonkénti konfiguráció, több ezer név szerint kezelt tesztesettel.
Új operátorok és PyTorch-verziók kezelése
Új operátor engedélyezésekor a rendszer feltérképezi, hogy az egyes tesztek mely operátorokat használják. Ehhez fordított index készül, amely egy operátort a hozzá kapcsolódó tesztek teljes listájával kapcsol össze. Az eager útvonalon ezt a TorchDispatchMode, a fordítási útvonalon pedig a TORCH_LOGS segítségével gyűjtik össze.
Az operátort használó tesztek nem kerülnek automatikusan a végső készletbe, mert egy teszt más, a háttér által nem támogatott PyTorch-funkciókat is igénybe vehet. A második kiválasztási ügynök ezért további szűrést végez.
PyTorch-verziófrissítéskor a tesztcsomagban megjelenő új, módosított vagy törölt tesztek bekerülhetnek a repository memory frissített állapotába. A forrás szerint így a kiválasztást a változásokra lehet korlátozni, a teljes feldolgozás megismétlése nélkül.
A PyTorch szerint a megközelítés nem Torch Spyre-specifikus. A gyorsító a konfiguráció mögött marad, miközben a CI-logika általánosítható. A projekt fejlesztői a PyTorch csapatával együtt szeretnék a felhasználható részeket upstreamelni, a PyTorch OpenReget természetes referenciapontként kezelve.