A modellünk elkészült, leteszteltük, és a 2.1.3. fejezetben látott életciklus végén járunk: a telepítésnél. De hova is telepítjük? A döntés, hogy egy AI modell egy távoli, nagy teljesítményű szerveren (felhő) vagy közvetlenül a felhasználói eszközön (edge) fusson, alapjaiban határozza meg a rendszer viselkedését, teljesítményét és – ami számunkra a legfontosabb – a támadási felületét.
Mi a lényegi különbség? Egy analógia
Képzeld el, hogy egy komplex matematikai problémát kell megoldanod. Két lehetőséged van:
- Felhő (Cloud): Felhívod a világ legjobb matematikus professzorát. Bediktálod neki a problémát (adatküldés), ő a szuperszámítógépeivel megoldja (feldolgozás), majd visszamondja neked a választ (eredmény). Gyors és hihetetlenül pontos, de időbe telik a kommunikáció, és a professzornak tudnia kell a problémádról.
- Edge: Előveszed a zsebedből a saját számológépedet. Azonnal bepötyögöd a feladatot, és azonnal megkapod a választ. Lehet, hogy a számológéped nem tud olyan bonyolult dolgokat, mint a professzor, de villámgyors, nem kell hozzá telefonvonal (internet), és senki más nem tudja, mit számolsz.
Ez a két véglet írja le a felhő és az edge alapú AI rendszerek közötti alapvető különbséget. A „hol történik a számítás?” kérdésre adott válasz mindent megváltoztat.
A két architektúra vizuálisan
Egy diagram többet mond ezer szónál. Az alábbi ábra a két modell adatfolyamát és számítási helyszínét mutatja be.
Összehasonlító táblázat
A döntés a két architektúra között mindig kompromisszumokkal jár. Az alábbi táblázat összefoglalja a legfontosabb szempontokat.
| Szempont | Felhő alapú (Cloud) | Edge alapú |
|---|---|---|
| Válaszidő (Latency) | Magasabb (hálózati késleltetés miatt) | Nagyon alacsony (azonnali, helyi feldolgozás) |
| Sávszélesség-igény | Magas (folyamatos adatküldés szükséges) | Alacsony (csak a modell frissítéséhez kell) |
| Offline működés | Nem lehetséges | Teljes mértékben lehetséges |
| Adatvédelem (Privacy) | Kockázatosabb (adatok elhagyják az eszközt) | Magasabb (az adatok helyben maradnak) |
| Számítási kapacitás | Gyakorlatilag korlátlan | Erősen korlátozott (az eszköz hardverétől függ) |
| Skálázhatóság | Kiváló (szerver oldalon könnyen bővíthető) | Nehézkes (minden eszközt külön kell kezelni) |
| Modell frissítése | Egyszerű (egy helyen kell frissíteni a modellt) | Bonyolult (minden eszközre el kell juttatni a frissítést) |
| Költségek | Folyamatos működési költség (szerver bérlés, adatforgalom) | Magasabb kezdeti fejlesztési költség, alacsonyabb működési költség |
Hogyan néz ki ez a gyakorlatban?
Nézzünk egy egyszerű pszeudokódot egy képfelismerő alkalmazáshoz mindkét esetben.
Felhő alapú megközelítés
# Kliens oldali kód (pl. egy mobilalkalmazásban)
def felismeres_felhoben(kep_fajl):
# 1. A képet elküldjük egy távoli API-nak
api_valasz = api_kliens.post("https://api.aicegoldala.hu/kepfelismero", files={'image': kep_fajl})
# 2. Várjuk a választ a szerverről
if api_valasz.status_code == 200:
return api_valasz.json()['eredmeny'] # Pl. {"eredmeny": "macska"}
else:
return "Hiba a feldolgozás során"Edge alapú megközelítés
# Kliens oldali kód (minden az eszközön történik)
# A 'helyi_modell' már korábban letöltésre került az eszközre
def felismeres_eszkozon(kep_adat):
# 1. Betöltjük a képet a modell számára megfelelő formátumba
elokeszitett_kep = kep_feldolgozo(kep_adat)
# 2. Helyben, az eszközön futtatjuk az inferenciát
eredmeny = helyi_modell.predict(elokeszitett_kep) # Pl. "macska"
return eredmenyA különbség egyértelmű: a felhő modell egy hálózati kérést indít, míg az edge modell egy helyi függvényhívást hajt végre.
AI Red Teaming szempontok: Hol támadjunk?
Red Teamerként az architektúra kiválasztása alapvetően meghatározza a lehetséges támadási vektorokat. A kérdés nem az, hogy „melyik a biztonságosabb?”, hanem az, hogy „hol vannak a gyenge pontok az adott implementációban?”.
Támadási felületek a felhőben
- API végpontok: Az API a rendszer kapuja. Támadható hitelesítési hibákkal, jogosultságkezelési problémákkal (pl. IDOR), rate limiting hiányosságaival (DoS), vagy a bemeneti adatok manipulálásával (pl. adverzárius támadások payloadként).
- Adatátvitel: A kliens és a szerver közötti kommunikáció lehallgatható (Man-in-the-Middle), ha a titkosítás gyenge vagy hibásan van implementálva.
- Szerver oldali sebezhetőségek: A teljes szerverinfrastruktúra támadható: operációs rendszer, konténerizációs technológia (Docker, Kubernetes), adatbázisok. Egy sikeres behatolás az összes felhasználó adatát veszélyeztetheti.
- Több-bérlős (Multi-tenant) környezet: Ha a szolgáltató több ügyfelet szolgál ki ugyanazon az infrastruktúrán, egy másik ügyfél elleni támadás vagy konfigurációs hiba a mi rendszerünket is érintheti.
Támadási felületek az Edge eszközökön
- Fizikai hozzáférés: Az eszköz ellopható, szétszedhető. Ezzel hozzáférhetővé válhat a rajta tárolt, esetleg titkosítatlan modell, ami a legértékesebb szellemi tulajdon.
- Modell-lopás (Model Extraction): Akár fizikai hozzáférés nélkül is, az eszköz API-jának ismételt lekérdezésével (ha van ilyen) megkísérelhető a modell viselkedésének lemásolása, egy „pótlék” modell létrehozása.
- Oldalcsatorna-támadások (Side-channel attacks): Fejlett támadások, ahol az eszköz energiafogyasztásának, elektromágneses sugárzásának vagy végrehajtási idejének mérésével lehet következtetni a modell belső működésére vagy a felhasznált adatokra.
- Frissítési mechanizmus: Hogyan kapja meg az eszköz a modellfrissítéseket? Ha ez a csatorna nem biztonságos, egy támadó rosszindulatú modellt juttathat az eszközre. Egy elosztott rendszerben ez katasztrofális lehet.
A hibrid megközelítés
A gyakorlatban gyakran nem tiszta edge vagy felhő megoldásokkal találkozunk. Sok rendszer hibrid módon működik. Például:
- Egy egyszerű, kisebb modell fut az eszközön a gyors reakciókhoz (pl. „Hey Siri” kulcsszó felismerése), de a komplexebb kéréseket (pl. „Milyen idő lesz holnap Budapesten?”) már a felhő dolgozza fel.
- A modellek tanítása a felhőben történik a hatalmas adathalmazokon, de maga az inferencia (a modell használata) az edge eszközökön. Ezt a folyamatot nevezik néha „Federated Learning”-nek is, ahol a tanítási folyamat egy része is kikerül az eszközökre anélkül, hogy a nyers felhasználói adatok elhagynák azt.
Red Teamerként ez azt jelenti, hogy mindkét világ támadási felületeit ismerned kell, és azt is, hogyan hatnak egymásra. Egy kompromittált edge eszköz például szolgáltathat adatokat egy felhő elleni támadáshoz, és fordítva.