A Pydantic CI-költsége 18 200 dollárra nőtt, majd 5700-ra esett

Az AI-használattal együtt ugrott meg a CI-számla

A Pydantic közlése szerint a Logfire GitHub Actions-folyamatai a Pydantic AWS-fiókjában indított, ideiglenes EC2-futtatókon futnak a RunsOn segítségével. A Logfire a pydantic/platform repositoryban készül. Korábban a vállalat GitHub Actions, Depot és Ubicloud kombinációját használta a folyamatos integrációs infrastruktúrához.

A CI költsége 2026 áprilisában 3813 dollár, májusban 3665 dollár, júniusban 3990 dollár, júliusban 10 778 dollár, augusztusban pedig 18 200 dollár volt. A Pydantic szerint a növekedést az okozta, hogy a csapat AI-eszközöket kezdett használni, és jelentősen több munkát szállított.

Augusztus 30-ig a Logfire csapata 2032 pull requestet egyesített. Egy azonos létszámú csapat 2025 azonos, 30 napos időszakában 365 pull requestig jutott. A pydantic/platform fő CI-folyamata májusban 4194, júniusban 6669, júliusban 11 919, augusztus 30-ig pedig 20 659 alkalommal futott le.

A GitHub maradt a vezérlőréteg

A RunsOn használatával a GitHub továbbra is vezérli a munkafolyamatokat, miközben az új EC2-futtatók a Pydantic AWS-fiókjában indulnak el, majd a feladat befejezésekor megszűnnek. A vállalatnak így nem kellett lecserélnie a GitHub CI-vezérlőrétegét, illetve saját runnerplatformot építenie a gépek, a hálózat, a tárhely és a költségek kezeléséhez.

A telepítés és a GitHubhoz való csatlakoztatás után a hagyományos feladatoknál főként a futtatócímkét kellett módosítani, valamint hozzáadni a RunsOn beállítási műveletét. A konténerépítésekhez további gyorsítótár- és regisztrációs módosításokra volt szükség.

A Pydantic szerint a GitHub Actions és a felügyelt runner-szolgáltatások segítségével a csapat saját futtatóflotta működtetése nélkül jutott el havi több mint egymillió runnerpercig. Ezen a szinten azonban nagyobb kontrollt akartak afelett, hogy milyen gépekért fizetnek. A RunsOn a futtatók életciklusát kezeli, míg a vállalat továbbra is az AWS-fiókot, a gépkatalógust, a kapacitásstratégiát, a tárhelyet, a gyorsítótár szabályait, a kvótákat és a telemetriát kezeli.

Spot gépek és célzott kapacitáskezelés

A PydOn közlése szerint a RunsOn 22 napi feladatnál kitermeli a saját költségét, ezt a küszöböt a Pydantic már korábban túllépte. A futtatókatalógus az egymagos ARM-gépektől a 16 magos image-építőkig terjed. A legtöbb Python-, TypeScript-, agentikus és vezérlősík-feladat Gravitonon fut, míg az x64 gépeket a konténerépítésekhez és az ezt igénylő tesztekhez használják.

Az egyes előbeállítások több, használható EC2-családot tartalmaznak, így a Spot-allokátor több kapacitásmedence közül választhat. A RunsOn Magic Cache rendszere a futtatók közelében szolgálja ki a meglévő actions/cache hívásokat, a tartós EBS-lemezek pedig megőrzik a költséges BuildKit-állapotot.

A Pydantic nem minden feladathoz Spot példányokat használ. Az összeolvasási sor ellenőrzése, a kiadások közzététele, a telepítések és a drága újraindítású feladatok On-Demand kapacitáson futnak. A hosszú, megszakításra érzékeny feladatok kapacitásoptimalizált Spot-elhelyezést, a rövidebbek ár és kapacitás szerint optimalizált elhelyezést kapnak. A privát telepítés három rendelkezésre állási zónára terjed ki, és egy áramköri megszakító megszakítási hullám után átmenetileg On-Demand gépekre irányítja az új feladatokat.

Nagyobb terhelés mellett lett olcsóbb a működés

2026 augusztusában a Pydantic 1 230 264 runnerpercet mért, szeptemberben viszont már 1 617 654-et. Ennek ellenére a teljes szeptemberi CI-költség 5700 dollárra csökkent. Ez az összeg a RunsOn licencét, valamint az AWS számítási, EBS-, S3-gyorsítótár-tárolási és adatátviteli költségeit is tartalmazza.

A vállalat három gyakorlati szabályt emelt ki: Spot kapacitást ott használ, ahol olcsón újra lehet próbálni a feladatot, az összeolvasási sort és a kiadási útvonalakat On-Demand kapacitáson tartja, a gépeket pedig a kritikus út késleltetési céljához méretezi. Emellett a gyorsítótárat a számítás közelében tartja, és csak addig őrzi meg, amíg várhatóan újra felhasználják.

A bejelentés alapján a Pydantic az AI által megnövelt fejlesztési és tesztelési mennyiséget nem a feladatok visszafogásával kezelte. A builds és a tesztek futtatási helyét változtatta meg, majd a gépeket, a gyorsítótárakat és a kapacitást a terhelés növekedéséhez igazította.