A Krea úgy futtatja az inferenciát, hogy közben a kutatásé a GPU

A kutatás kapja a GPU-kat, a gyártás mégsem áll le

A Krea kutatási és éles, vagyis gyártási feladatai ugyanazokat a GPU-klasztereket használják. A cég nem választja külön a két környezetet, ezért a kutatási tréningek és a weboldalon futó tartalomgenerálás ugyanazokért az erőforrásokért versenyeznek.

A vállalat szerint a GPU-k szinte mindig értékesebbek kutatási célra. A klaszterek beszerzésekor a GPU-k minőségét és az InfiniBand hálózati kapcsolatot helyezik előtérbe, miközben az árat is ésszerű szinten tartják. Emiatt a kutatók időnként a teljes klasztert lefoglalják tréningekhez.

Ez önmagában ronthatná a felhasználói élményt, ha a gyártási inferencia leállna. A Krea célja ezért az volt, hogy a kutatók megkaphassák az összes GPU-t, a tartalomgenerálás pedig akkor is működjön, amikor a klaszter fizikailag teljes terhelés alatt áll.

Virtual Kubeletre építették a megoldást

A rendszer alapja a Virtual Kubelet, röviden VK. A Kubernetesben minden csomóponton fut egy Kubelet nevű háttérfolyamat, amely regisztrálja a csomópontot az apiservernél, elindítja a hozzá rendelt podok konténereit, majd visszajelzi azok állapotát.

A Virtual Kubelet ezt a működést emulálja. Maga is Kubernetes-podként fut, miközben csomópontként regisztrálja magát. Mivel a Krea teljes mértékben irányítja ezt a csomópontot, azt jelenti a Kubernetes felé, hogy gyakorlatilag korlátlan GPU-kapacitással rendelkezik. A podokat így külső helyeken is el lehet indítani és kezelni.

A Krea először az interLink nevű, Virtual Kubeletre épülő projektet próbálta használni, de a cég szerint az túl korlátozott volt, és hibákat is tartalmazott. Ezért már korán úgy döntöttek, hogy közvetlenül a Virtual Kubeletre építik fel saját rendszerüket.

Külső szolgáltatók és önjavító működés

A Krea az úgynevezett External Providers, vagyis külső szolgáltatók köré szervezte a rendszert. Ezek választják el egymástól a Kuberneteshez kapcsolódó általános működést és az egyes szolgáltatók kezelését. Egy új szolgáltató hozzáadásakor elég megvalósítani a vele való kommunikáció alapjait, a rendszer többi része a feloldást, az induláskor és futás közben végzett egyeztetést, a szemétgyűjtést, valamint a Kubernetes-állapot megfelelő átültetését kezeli.

A megoldás teljesen állapotmentes. A működéshez szükséges állapot újra előállítható a klaszteren és a külső szolgáltatón futó elemekből. Ha a Virtual Kubelet-pod újraindul, a rendszer a Krea szerint képes ott folytatni, ahol korábban abbahagyta.

A Kubernetes automatikus képességei is felhasználhatók. Ha például egy Horizontal Pod Autoscaler által kezelt példány meghibásodik vagy kiesik a külső szolgáltatónál, a helyes állapotjelentés alapján a Kubernetes új podot hoz létre a pótlására. Ehhez az szükséges, hogy a külső szolgáltató oldalán minden pod külön azonosítható legyen.

Egy VK kezeli az összes szolgáltatót

A Krea két architektúra között választhatott: minden szolgáltatóhoz külön Virtual Kubelet-podot használ, vagy egyetlen VK-ra bízza az összes szolgáltató kezelését és a feladatok szétosztását. A vállalat a második megoldást választotta. A Kubernetes így ugyanúgy ütemezhet podot a VK-csomópontra, mint bármely másik klasztercsomópontra.

A következő bejegyzésben a Krea a GPU-k ütemezését tervezi bemutatni. A cég szerint arról írnak majd, hogyan biztosítják a klaszter magas kihasználtságát, és hogyan működik a leterhelési rendszer akkor, amikor elfogy a rendelkezésre álló GPU-kapacitás.