Egy saját szerveren futó nyelvi modell ugyanúgy válaszol a kérdésekre, mint egy felhős szolgáltatás. A különbség az, hogy a kérdés, a csatolt dokumentum és a válasz is a szervezet hálózatán belül marad. Cserébe mindaz, amit eddig a szolgáltató végzett, házon belülre kerül: a hardver, a modell kiválasztása, a frissítés, a hozzáférés és a napló.
Mikor indokolt a saját infrastruktúra
A leggyakoribb ok maga az adat. Ha a modellnek ügyféladatot, szerződést, műszaki dokumentációt vagy forráskódot kell feldolgoznia, felhős szolgáltatásnál ez az adat egy külső fél rendszerén halad át. Személyes adatnál ez a GDPR szerint adatfeldolgozói viszony, amelyhez szerződés és a szolgáltató ellenőrzése kell. Más adatnál titoktartási megállapodás vagy belső szabály tilthatja a kiadást. Helyben futó modellnél a kérés el sem hagyja a hálózatot.
Egy internettől elzárt környezetben felhős szolgáltatás nem is érhető el, ott a helyi modell az egyetlen lehetőség. Az ellenőrizhetőség is számít: helyi telepítésnél a szervezet dönti el, melyik modellverzió fut, mikor frissül, mit naplóz a rendszer és meddig őrzi. A felhős modell viselkedése a szolgáltató ütemezése szerint változhat, ami egy dokumentált, jóváhagyott folyamatnál gondot okozhat.
Az ellenérvek is számítanak. Egy szervezet által ésszerűen üzemeltethető hardveren jellemzően kisebb modellek futnak, mint amilyeneket a nagy felhőszolgáltatók kínálnak, így a hosszú, többlépéses következtetést kívánó feladatokban gyengébb eredmény várható. Összefoglalásra, keresésre, osztályozásra és dokumentumfeldolgozásra viszont sokszor elegendők. Az üzemeltetés, a biztonsági frissítés és a hibaelhárítás is a szervezet dolga lesz. A tervezés ezért a konkrét feladattal kezdődjön: milyen kérdésekre kell válaszolni, milyen adatból, hány felhasználónak és mekkora válaszidővel.
Modellméret, memória és kvantálás
A nyelvi modell méretét a paraméterek számával adják meg, a modellek nevében ezt gyakran milliárdban jelölik (7B, 70B). A paraméterek a modell súlyai. Futás közben mindegyiknek a memóriában kell lennie, lehetőleg a GPU saját memóriájában, mert a válasz így készül el gyorsan.
A szükséges memória jó közelítéssel a paraméterszám és a paraméterenkénti bájtszám szorzata. 16 bites pontosságnál egy paraméter 2 bájt, így egy 7 milliárd paraméteres modell súlyai nagyjából 14 GB-ot foglalnak, egy 70 milliárdosé 140 GB körül. Ehhez jön még a futás közben használt memória.
A kontextus is memóriát kér
A modell a már feldolgozott szöveg (a beszélgetés és a csatolt dokumentum) köztes számítási eredményeit egy gyorsítótárban tartja (KV-cache). Ennek mérete a kontextus hosszával és az egyszerre kiszolgált kérések számával együtt nő. Egy modell, amely egy felhasználóval kényelmesen elfér a GPU-n, több párhuzamos, hosszú dokumentumos kérésnél kifuthat a memóriából, vagy sorba állítja a kéréseket. A méretezéshez ezért a várható terhelést is ismerni kell, a modell mérete önmagában kevés.
Kvantálás
A kvantálás a súlyok számábrázolását teszi kisebb pontosságúvá, például 16 bitről 8 vagy 4 bitre. 8 biten a modell nagyjából feleannyi, 4 biten negyedannyi memóriát kér, így olyan gépen is elfut, amelyen az eredeti változat nem. Ennek ára a minőség: 8 biten a romlás jellemzően csekély, 4 biten és alatta már mérhető, és feladatonként eltérő. Hogy egy konkrét felhasználásnál ez mennyit számít, azt saját méréssel lehet eldönteni, a valódi munkából vett mintakérdésekkel és előre rögzített elvárt válaszokkal.
GPU nélkül a modell processzoron és rendszermemórián is futtatható, csak lényegesen lassabban. Kipróbálásra és egy-két felhasználóra ez is elég lehet, több felhasználós üzemre ritkán.
Nyílt súlyú modellek és licencfeltételek
A helyben futtatható modellek többsége nyílt súlyú (open-weight): a súlyfájlok letölthetők, de a modell ettől még nem feltétlenül nyílt forráskódú. A tanítóadat és a tanítás menete jellemzően nem nyilvános, a felhasználást pedig a modellhez adott licenc szabályozza. Az Open Source Initiative 2024-ben kiadott meghatározása (Open Source AI Definition 1.0) a nyílt forráskódú AI-tól a súlyokon túl a kód és a tanítóadatról szóló részletes leírás közzétételét is elvárja.
A licencek erősen eltérnek egymástól. Egy részük szabványos, engedékeny nyílt forráskódú licenc, például Apache 2.0 vagy MIT, amely a kereskedelmi felhasználást is megengedi. Mások saját feltételeket szabnak. Korlátozhatják a kereskedelmi használatot, egy felhasználószám felett külön engedélyhez köthetik, elfogadható használati szabályzatot csatolhatnak, vagy előírhatják, hogy a származékos modell nevében jelölni kell az eredetet. Olyan feltétel is előfordul, amely a modell kimenetére vonatkozik, például tiltja, hogy más modellek tanítására használják.
Bevezetés előtt ezért írjuk le, melyik modell melyik verziója fut, honnan származik, milyen licenc alatt áll, és ez a licenc megengedi-e a tervezett felhasználást. Egy saját licencű modell közösség által feltöltött, finomhangolt változatát jellemzően az eredeti modell licencfeltételei is kötik, akkor is, ha a feltöltő mást tüntet fel. A fájl tartalmáért a feltöltő felel, független ellenőrzésen jellemzően nem esett át.
A modellfájl is támadási felület
A letöltött súlyfájl a szoftveres ellátási lánc része, ugyanúgy, mint egy függőség vagy egy konténerkép. Egyes elterjedt modellformátumok a Python pickle-mechanizmusára épülnek, amely betöltéskor tetszőleges kódot is futtathat. Modellt csak megbízható forrásból töltsünk le, a közzétett ellenőrzőösszeget egyeztetni kell, és olyan formátumot célszerű választani, amely csak a súlyokat tárolja, végrehajtható kódot nem. Az ellátási lánc elleni támadásról a fogalomtárban is van leírás.
Futtatókörnyezet és felhasználói felület
Alul a hardver és az operációs rendszer áll, a GPU-hoz tartozó meghajtóval és programkönyvtárakkal. Erre épül a következtetési szerver (inference server), amely betölti a modellt, fogadja a kéréseket, és a párhuzamosan érkezőket kötegekbe szervezi, hogy a GPU ne álljon üresen. A legtöbb ilyen szerver HTTP-n érhető el, sokszor a felhős nyelvimodell-szolgáltatások elterjedt API-formátumával kompatibilis felülettel. Így a meglévő eszközök és programkönyvtárak kis módosítással ráköthetők.
A felhasználó ebből csak a legfelső réteget látja. Ez lehet böngészőből elérhető csevegőfelület, egy meglévő alkalmazásba épített funkció vagy egy belső tudásbázis-kereső. Utóbbi jellemzően RAG (retrieval-augmented generation) elven működik: a rendszer a kérdéshez előbb kikeresi a releváns dokumentumrészleteket egy indexből, és ezeket adja át a modellnek a válaszhoz. A modellt így nem kell a szervezet dokumentumain újratanítani, a válasz mellett pedig megjelenhet, melyik dokumentumból származik.
A futtatókörnyezetet gyakran konténerben telepítik. Ez megkönnyíti a verziók rögzítését és a visszaállást, de a konténerkép is külső forrásból jön, ezért rá ugyanaz a forrás- és ellenőrzőösszeg-vizsgálat vonatkozik, mint a modellfájlra.
Hozzáférés-kezelés és naplózás
A helyi modell attól még nem biztonságos, hogy helyben fut. A következtetési szerverek egy része alapbeállításban hitelesítés nélkül fogad kéréseket. Ha ilyenkor minden hálózati interfészen figyel, a belső hálózatról bárki használhatja, rosszabb esetben a betöltött modellt is lecserélheti. Az API-t ezért csak a felhasználói felület vagy egy hitelesítő átjáró érje el, a felhasználók pedig a szervezet meglévő identitáskezelésén keresztül, SSO-val lépjenek be.
A dokumentumok jogosultságai
Egy RAG-alapú keresőnél a legnagyobb kockázat, hogy a rendszer olyan dokumentumrészletet tesz a válaszba, amelyet a kérdező az eredeti helyén nem nyithatna meg. Az indexnek ezért meg kell őriznie a forrásdokumentumok jogosultságait, és a keresést a kérdező felhasználó nevében kell elvégeznie. Ha az index egyetlen, mindenhez hozzáférő szolgáltatásfiókkal épül fel, a modell bárkinek kiadhatja a teljes dokumentumtár tartalmát, aki megfelelően kérdez.
A helyi futtatás a prompt-injekció ellen sem véd. Ha egy feldolgozott dokumentumba rejtett utasítás kerül, a modell a saját szerveren is követheti. Ahol a modell eszközöket hívhat vagy más rendszerekbe írhat, a jogosultságait a feladathoz szükséges minimumra kell szűkíteni. A további kockázatokat a vállalati AI-bevezetés kockázatairól szóló cikk tárgyalja.
Mit naplózzunk
Egy incidens vagy egy panasz kivizsgálásához tudni kell, ki, mikor, melyik modellel mit kérdezett, milyen dokumentumrészleteket kapott hozzá a modell, és mi lett a válasz. Helyi telepítésnél ez a napló a szervezet saját rendszerében keletkezik. A napló maga is érzékeny, hiszen a kérdésekben és a válaszokban ugyanaz az adat szerepel, amelyet a helyi telepítés védeni hivatott. A hozzáférést ezért szűkíteni kell, a megőrzési időt meg kell határozni, személyes adatnál pedig ezt az adatkezelési tájékoztatóban is rögzíteni.
Az üzemeltetési események, például a modell betöltése, a konfiguráció változása vagy a sikertelen bejelentkezés, a többi rendszer naplójával együtt a központi naplógyűjtőbe valók. Hogy ott mit és mennyi ideig érdemes őrizni, arról a naplózásról szóló cikk szól.
Internettől elzárt hálózatban
Air-gap hálózatban a telepítés és a frissítés is offline történik. A modellfájl, a konténerképek, az operációsrendszer-csomagok és a programfüggőségek egy internetre kötött előkészítő gépen állnak össze, és ellenőrzött adathordozón vagy egyirányú átjárón jutnak be a zárt hálózatba. A behozott fájlok ellenőrzőösszegét a zárt oldalon újra egyeztetni kell, az adathordozót pedig kártevőkeresésen kell átvinni.
Gyakori meglepetés, hogy egy komponens az első indításkor letöltene valamit: egy hiányzó modellrészt, egy tokenizálót vagy egy frissítést. Zárt hálózatban ez hibával leáll. A telepítést ezért előbb egy szintén elzárt tesztkörnyezetben kell végigpróbálni, ahol az is kiderül, ha egy szoftver telemetriát küldene, vagy a licence online aktiválást kér.
A frissítés zárt hálózatban sem maradhat el. A futtatókörnyezet sebezhetőségeit ugyanúgy javítani kell, mint bármely más szoftverét, csak itt minden javítás behozatala tervezett munka. Előre le kell írni, ki állítja össze a frissítési csomagot, ki ellenőrzi, hogyan próbálják ki a tesztkörnyezetben, és hogyan lehet visszaállni a korábbi verzióra, ha az új modell rosszabbul válaszol.
Kapcsolódó szolgáltatás: Helyi (on-prem) AI telepítés →
