Az AI stack kérdése, amivel előbb-utóbb minden fejlesztőcsapat szembesül

Előbb-utóbb minden engineering csapat feltesz magának egy kérdést, ami utólag már evidencia: Miért adjuk ki ennyi fejlesztői infrastruktúrát külső szolgáltatóknak?

Ez nem költői kérdés, és nem is arról szól, hogy teljesen el kellene hagyni a hostelt AI szolgáltatásokat. Inkább egy gyakorlati infrastruktúra-szempont, amivel egyre több csapat kezd el komolyan foglalkozni, ahogy az AI-alapú kódszerkesztő eszközök a mindennapi munkafolyamatok részévé válnak.

Nemrég bukkantam egy érdekes esettanulmányra, ami pontosan megmutatja, miért fontos ez a téma. A Parity-nél egy kisebb csapat úgy döntött, hogy elindít egy úgynevezett "20%-os kísérletet" – lényegében néhány engineer kapott szabad kezet, hogy kipróbálják, működhetnek-e saját hostelt AI modellek valós fejlesztési feladatokra. Ami egy délutános próbának indult, hetekig tartott: 25 mérnök összesen közel 13 milliárd tokent dolgozott fel egy saját menedzselt inference környezetben.

A számok elgondolkodtatóak. Az első három napban több mint 3 milliárd tokent dolgoztak fel, nagyjából 0,10 dollár per millió token GPU számítási költségen. A teljes hónapra körülbelül 1200 dollár jött ki. Ez nem semmi, de nem is az a brutálisan drága megoldás, amit sokan feltételeznek, amikor meghallják, hogy "saját hostolt AI".

A valódi költség nem ott van, ahol gondolnád

Itt a legfontosabb felismerés: bár a GPU költségek valódiak, valójában ez volt a kisebb kiadás. A nagyobb befektetés az engineering idő volt – az infrastruktúra beállítása, a teljesítmény benchmarkingolása, és a rendszer megbízható működtetésének megtanulása.

Ezt a mintát látom újra és újra az infrastruktúra döntéseknél. A közvetlen költségek láthatók és könnyen tervezhetők. A rejtett költségek azok az idők és figyelem, amit a csapat az új rendszerek üzemeltetési tudásának felépítésére fordít. A Parity csapatának feltételezése az, hogy ez a tudás kamatozik – hogy az infrastruktúra, benchmarkok és üzemeltetési playbookok mostani megépítésével olyan képességekbe fektetnek, amelyek a jövőbeli workloadoknál is megtérülnek.

Ez a gondolkodás ismerős lehet bárkinek, aki döntött már cloud hosting, container orchestration vagy managed database ügyben. Mérlegeled az operatív komplexitást a kapott kontroll, költségmegtakarítás és stratégiai rugalmasság ellenében. Néha a managed megoldás nyer. Néha megérinti a stack tulajdonlása.

Mit jelent a "sima architektúra" a gyakorlatban

Ami tetszett a Parity write-upjában, az a részletes architektúra leírás. Nem valami egyedi, házilag épített inference clustert futtattak. A stackjük kellemesen egyszerű volt:

Egy közös interface réteg (LiteLLM-et használtak) ül a fejlesztői eszközök és a kéréseket kiszolgáló modellek között. Az interface mögött a vLLM végzi a model servinget. A GPU kapacitás felhőszolgáltatótól bérelt infrastruktúrán fut. Az egész setupot tudatosan úgy tervezték, hogy az engineererek megtarthassák a megszokott kódszerkesztő környezetüket és kliensoldali eszközeiket, miközben a csapat rugalmasságot élvez arról, mely modellek és szolgáltatók dolgoznak a közös endpoint mögött.

Ez az a kulcsfelismerés, amit sok csapat elmulaszt, amikor elsöprően elutasítja a saját hostolt opciókat: nem kell választanod a kontroll és a kényelem között. Egy jól megtervezett abstraction layer azt jelenti, hogy a fejlesztők ugyanazokat az eszközöket használják, mint eddig. A különbség csak annyi, hogy te döntöd el, melyik modell válaszol, milyen adatok kerülnek logolásra, és hogyan oszlanak meg a költségek.

Gondolj bele úgy, mint a DNS kezelésbe. A fejlesztőknek nem kell érteniük a DNS propagáció bonyolultságát ahhoz, hogy hatékonyan használják a domain neveket. Egy tiszta interfészen keresztül kommunikálnak. De az interface mögött valaki tudatos döntéseket hozott a nameserverekről, TTL-ekről és redundanciáról. Ugyanez az elv érvényes itt is.

Mit mondanak nekünk a számok

A Parity kísérletének operatív adatai azok, ahol a dolog igazán hasznossá válik a hasonló setupokat fontolgató csapatok számára. Követték a context hosszokat, a request parallelismát, a throughputot és a queue timeokat valós fejlesztési workflowk mentén.

Néhány szembetűnő szám:

A kérések 99%-a 500 ezer token alatti contextet használt. Több mint az idő felében a rendszer pontosan egyetlen konkurens kérést szolgált ki. A csúcsterhelésnél 168 ezer token per másodperc prefill feldolgozást láttak, átlagos time to first tokennel körülbelül 3,34 másodperc.

A request shapek eloszlása fontos történetet mesél. A legtöbb időben az inference infrastruktúra viszonylag szerény, single-threaded kéréseket kezel fejlesztőktől. Azok a párhuzamos kérési szcenáriók, amelyek igazán megterhelik a rendszert, a kivételek, nem a szabályok.

Ennek gyakorlati következményei vannak a kapacitástervezésre. Nem feltétlenül kell a csúcs-párhuzamos terhelésre méretezned az esetek többségében. Egy jól megtervezett rendszer dinamikusan skálázódhat, miközben az alapköltségek ésszerűek maradnak.

A stratégiai kérdés: kontroll vs. kényelem

Itt van az igazi érték az ilyen kísérletekben: megtanítják az iparágnak, mit jelent a gyakorlatban az "AI infrastruktúra függetlenség".

Érdekes átmeneti időszakban vagyunk. Az AI-alapú kódszerkesztő eszközök elengedhetetlenné válnak a csapatok szoftverfejlesztési munkájában, de az iparág még mindig keresi, mit jelent ezeket a workloadokat felelősségteljesen futtatni. Az adatmegőrzéssel, költség-előrejelezhetőséggel, modell elérhetőséggel és vendor lock-in-nel kapcsolatos kérdések mind valós aggodalmak, amelyeket a fejlesztőcsapatok komolyan kezdenek venni.

A Parity kísérlete azt sugallja, hogy a saját hostolt inference sokkal elérhetőbb, mint sokan gondolnák. Nem kell hatalmas engineering szervezet vagy egyedi hardver az induláshoz. Világos követelmények kellenek, értelmes architektúra, és hajlandóság az operatív tudásba fektetni.

Hogy ez a trade-off értelmes-e, az teljesen a kontextustól függ. De az, hogy egyáltalán életképes opció, megérdemli, hogy megértsük – különösen ahogy az AI eszközök egyre mélyebben integrálódnak a szoftverek szállításának módjába.

Hol helyezkedik el ez a cloud hosting tájban

Cloud infrastruktúra szempontból ez a trend érdekes következményekkel jár. Az a képesség, hogy GPU kapacitást bérelj ahelyett, hogy megvásárolnád, jelentősen csökkenti a belépési küszöböt. Megkapod a saját hostolt infrastruktúra operatív rugalmasságát anélkül, hogy hardvert kellene vásárolnod és karbantartanod.

Ez ugyanaz az evolúció, amit más cloud computing területeken láttunk. A managed services elvonják a komplexitást, de a kontrollt is. A cloud infrastruktúrán futó saját hostolt opciók több kontrollt adnak, miközben nem要求的 физическое оборудование.

Az olyan platformokra építkező csapatoknak, mint a Vibe Hosting, a kérdés az: hogyan akarsz AI képességeket fogyasztani? Szereted a teljesen menedzselt AI szolgáltatások egyszerűségét? Vagy értékeled a képességet, hogy modelleket cserélhess, kontrollálhasd a költségeket, és pontosan lásd, mi történik a motorháztető alatt?

Az őszinte válasz a legtöbb mai csapatnak valószínűleg a hibrid megközelítés – managed szolgáltatásokat használnak egyes workloadokra, miközben építik a saját hostolt képességeket másokra. A kulcs az, hogy megértsd, mit áldozol el mindkét irányban.

A lényeg

A szoftverfejlesztéshez használt saját hostolt AI már nem elméleti gyakorlat, és nem is csak nagyvállalati környezetekre jellemző megközelítés, ahol dedikált ML infrastruktúra csapatok dolgoznak. Az eszközök érettebbé váltak, a költségek csökkentek, és az operatív minták egyre világosabbak.

Hogy saját inference infrastruktúrát futtatsz-e vagy maradsz a hostelt szolgáltatóknál, a trade-offok megértése alapvető tudás lesz az engineering vezetők számára. Azok a csapatok, amelyik most veszik a fáradságot, hogy megtanulják ezeket a leckéket, jobb helyzetben lesznek, amikor az AI eszközök tovább fejlődnek.

Az AI jövője a fejlesztésben nem csak arról szól, melyik modelleket használod – arról szól, ki kontrollálja a stacket, amelyen ezek a modellek futnak. És ez a kérdés komoly megfontolást érdemel minden csapattól, amelyik komolyan veszi a fejlesztési infrastruktúráját.

Ti milyen megközelítést alkalmaztok az AI infrastruktúrában? Teljesen a hostelt szolgáltatásokra alapoztok, vagy felfedezitek a saját hostolt opciókat? Az AI infrastruktúra függetlenségről szóló beszélgetés épp csak elkezdődött.