32.1.2. KV-gyorsítótár mellékcsatornák

Láttuk, hogy a tokengenerálás sebessége árulkodó lehet. De mi okozza pontosan ezeket a finom időkülönbségeket? Az egyik legfőbb gyanúsított, és egyben a Transformer architektúrák egyik kulcsfontosságú optimalizációs eleme, a Key-Value (KV) gyorsítótár. Ez az a komponens, ami lehetővé teszi a modellek számára, hogy ne kelljen minden egyes új token generálásakor a teljes kontextust újraértelmezniük. És éppen ez az optimalizáció nyitja meg az egyik legérdekesebb időzítésen alapuló mellékcsatornát.

A KV-gyorsítótár Anatómája

Mielőtt a támadásba belemerülnénk, tisztázzuk, mi is ez a bizonyos gyorsítótár. A Transformer modellek figyelmi mechanizmusa (attention mechanism) minden tokenhez három vektort számol: a Query (Q), a Key (K) és a Value (V) vektort. Az autoregresszív generálás során a modellnek az eddigi összes token K és V vektorára szüksége van ahhoz, hogy a következő token valószínűségeit kiszámolja.

A KV-gyorsítótár egy egyszerű, de zseniális trükk: ahelyett, hogy minden lépésben újra és újra kiszámolná a korábbi tokenek K és V vektorait, a modell eltárolja őket. Amikor a következő tokent generálja, csak az utolsó token Q, K és V vektorait kell kiszámítania, majd a korábbi K és V vektorokat előveszi a gyorsítótárból. Ez drámaian felgyorsítja a generálást.

A Támadási Felület: Cache Hit vs. Cache Miss

A támadás logikája a klasszikus gyorsítótár-alapú mellékcsatornák elvét követi. A végrehajtási idő attól függ, hogy a szükséges adatok már a gyorsítótárban vannak-e (találat, cache hit) vagy sem (kihagyás, cache miss).

• Cache Miss (kihagyás): Ha egy prompt feldolgozása során a modellnek minden K és V vektort a nulláról kell kiszámítania, mert azok nincsenek a gyorsítótárban, a feldolgozás lassabb lesz. Ez történik egy teljesen új, egyedi kérésnél.
• Cache Hit (találat): Ha a prompt egy olyan prefixszel (előtaggal) kezdődik, amelynek K és V vektorai már a gyorsítótárban vannak egy korábbi kérésből, a modellnek nem kell újraszámolnia őket. Egyszerűen újrahasznosítja a tárolt értékeket, ami jelentősen gyorsabb feldolgozást eredményez.

Ez a különbség – a gyorsabb feldolgozás cache hit esetén – egy mérhető időbeli jel, amit a támadó kiaknázhat. Különösen veszélyes megosztott (multi-tenant) környezetekben, ahol ugyanaz a modellpéldány több felhasználót szolgál ki, és a gyorsítótár állapota átszivároghat a kérések között.

Gyakorlati Kiaknázás: Rendszerpromptok Kitalálása

A KV-gyorsítótár támadás egyik leggyakoribb célja a rejtett rendszerpromptok (system prompt) tartalmának kinyerése. A támadó iteratívan, karakterről karakterre vagy szóról szóra próbálja kitalálni a promptot. Minden egyes tipp egy új kérés, amely a tippelt prefixszel kezdődik. Ha a válaszidő hirtelen lecsökken, a támadó tudja, hogy eltalált egy érvényes részt a rendszerpromptból.

Tegyük fel, hogy a rendszerprompt így kezdődik: "Te egy segítőkész asszisztens vagy a Contoso cégtől. Szigorúan tilos...". A támadó a következőképpen haladhat:

Ez a módszer, bár aprólékos, rendkívül hatékony lehet, különösen automatizálva. A támadónak csupán egy precíz időmérési képességre van szüksége az API hívásokhoz.

# Pszeudokód a KV-gyorsítótár alapú prefix tesztelésére
import time

# A cél API végpont
API_ENDPOINT = "https://api.szolgaltato.com/v1/generate"

def meresi_ido(prompt):
 """Egy adott prompt feldolgozási idejét méri."""
 start_time = time.perf_counter()
 # Itt történik a tényleges API hívás
 call_api(API_ENDPOINT, prompt)
 end_time = time.perf_counter()
 return (end_time - start_time) * 1000 # Milliszekundumban

# 1. Alapvonal mérése egy valószínűtlen stringgel
baseline_time = meresi_ido("xyz_random_string_xyz")
print(f"Alap mérési idő: {baseline_time:.2f} ms")

# 2. Tesztelendő prefixek listája
# Egy valós támadásban ezt egy szótár vagy generátor adná
prefixes_to_test = ["Te egy", "Te egy barátságos", "Te egy segítőkész"]

for prefix in prefixes_to_test:
 # A méréshez a prefixet egyedi tartalommal egészítjük ki,
 # hogy elkerüljük a teljes kérés gyorsítótárazását.
 test_prompt = prefix + " [RANDOM_SUFFIX]"
 
 current_time = meresi_ido(test_prompt)
 
 # Ha az idő szignifikánsan alacsonyabb az alapvonalnál, találat van
 if baseline_time - current_time > 20: # 20ms küszöbérték
 print(f"[TALÁLAT] Prefix: '{prefix}', Idő: {current_time:.2f} ms")
 else:
 print(f"[NINCS] Prefix: '{prefix}', Idő: {current_time:.2f} ms")

Védekezési Stratégiák

A KV-gyorsítótár mellékcsatornák elleni védekezés a támadás gyökerét célozza: az információ megosztását a kérések között.

1. Gyorsítótár-particionálás (Cache Partitioning)

A leghatékonyabb védekezés. A szolgáltató minden felhasználóhoz, munkamenethez vagy akár minden egyes API kéréshez egy teljesen elkülönített KV-gyorsítótárat rendel. Ezzel fizikailag megakadályozza, hogy az egyik felhasználó kérése befolyásolja a másikét. Bár ez növeli a memóriaigényt, a biztonsági előnyei jelentősek.

2. Prefix gyorsítótárazás kikapcsolása

Egyes rendszerek lehetővé teszik a megosztott prefixek gyorsítótárazásának letiltását. Ilyenkor a rendszerpromptot minden alkalommal újra feldolgozza a modell, ami megszünteti a támadási vektort, de csökkenti a teljesítményt.

Összefoglalva, a KV-gyorsítótár egy kétélű fegyver. Miközben elengedhetetlen a modern LLM-ek hatékony működéséhez, egyben egy finom, de erőteljes mellékcsatornát is teremt. Red Teamerként ennek a mechanizmusnak a megértése kulcsfontosságú a rejtett információk feltárásához és a rendszerek valós biztonsági szintjének felméréséhez.