32.1.1. Tokengenerálási időzítés elemzése

A nyelvi modellek működésének egyik leginkább elhanyagolt, mégis árulkodó aspektusa a sebesség. Nem a teljes válasz generálásának ideje, hanem az egyes tokenek közötti, ezredmásodpercekben mérhető szünet. Ez a mikroszkopikus időkülönbség egy rejtett információs csatornát, egy mellékcsatornát nyit meg, amelyen keresztül a modell belső működéséről szerezhetünk információkat anélkül, hogy közvetlenül a belső állapotaihoz férnénk hozzá.

A tokengenerálási időzítés elemzése azon a feltételezésen alapul, hogy nem minden token „születik” egyenlő számítási költséggel. A modellnek bizonyos tokenek előállításához több, másokhoz kevesebb műveletet kell elvégeznie. Red teamerként a feladatunk az, hogy ezeket az apró időkülönbségeket mérjük, rögzítsük és mintázatokat keressünk bennük.

Mi okozza az időzítési különbségeket?

A generálási idő változékonyságának több forrása is lehet, amelyek együttesen alkotják a mérhető jelet. Ezek megértése kulcsfontosságú az elemzéshez.

• Számítási útvonalak a modellen belül: A modern architektúrák, különösen a Mixture-of-Experts (MoE) modellek, nem aktiválják a teljes hálózatot minden egyes token generálásakor. A bemenettől függően különböző „szakértő” alhálózatok lépnek működésbe. Egy ritkább vagy összetettebb téma feldolgozása más számítási útvonalat és így eltérő időzítést eredményezhet.
• Feltételes logika és „őrszavak”: A modellek gyakran tartalmaznak belső logikát, például biztonsági szűrőket vagy speciális formázási szabályokat. Ha a generált tartalom egy ilyen szabályt aktivál (pl. egy tiltott szóhoz közelít), a modell egy extra ellenőrzési körön mehet keresztül, ami mérhető késleltetést okoz.
• Tokenizer és token-komplexitás: Bár a tokenizálás a generálás előtt történik, a predikció során a modellnek a lehetséges következő tokenek nagy terét kell kezelnie. Egy ritka, több al-szóból álló tokenhez kapcsolódó valószínűségi eloszlás számítása eltérhet egy gyakori, egyetlen ID-val rendelkező tokenétől.
• Hardveres és rendszerszintű hatások: A GPU-k gyorsítótárazási mechanizmusai (amelyekről a következő fejezetekben részletesen lesz szó), a rendszer terheltsége és a hálózati késleltetés (jitter) mind zajt visznek a mérésbe. A sikeres támadás egyik kulcsa ezen zajok kiszűrése vagy a jel-zaj viszony javítása.

A támadás lépései: Méréstől az értelmezésig

A tokengenerálási időzítés elemzése egy módszeres folyamat, amely precíz mérést és statisztikai elemzést igényel.

1. A mérési környezet előkészítése

A legfontosabb a stabil és alacsony zajszintű környezet. Ideális esetben a mérést végző kliens és a modellt futtató szerver között a hálózati kapcsolat a lehető legstabilabb és leggyorsabb (pl. ugyanazon adatközponton belül). A cél a hálózati jitter minimalizálása, hogy a mért időkülönbségek valóban a modell számítási idejét tükrözzék.

2. Adatgyűjtés: Az idők rögzítése

A méréshez olyan API végpontra van szükség, amely támogatja a streamelt válaszadást, vagyis tokenenként küldi vissza az eredményt. Egy egyszerű Python szkripttel rögzíthetjük az egyes tokenek beérkezése között eltelt időt.

# Pszeudokód a tokengenerálási idők mérésére
import time
import hypothetical_api_client as api

prompt = "A mesterséges intelligencia biztonságának egyik..."
token_timings = []

# A streamelt válasz indítása
response_stream = api.generate_stream(prompt)

# Az első token előtti időpont rögzítése
last_token_time = time.monotonic()

for token in response_stream:
 current_time = time.monotonic()
 # Az előző token óta eltelt idő kiszámítása milliszekundumban
 time_delta_ms = (current_time - last_token_time) * 1000
 token_timings.append((token, time_delta_ms))
 
 print(f"Token: '{token.strip()}' | Idő: {time_delta_ms:.2f} ms")
 
 # A következő méréshez elmentjük az aktuális időpontot
 last_token_time = current_time

3. Adattisztítás és elemzés

A nyers adatok zajosak lesznek. El kell távolítani a kiugró értékeket (outliereket), amelyeket valószínűleg hálózati anomáliák okoztak. Több mérés átlagolásával csökkenthető a zaj és kiemelhetők a konzisztens mintázatok. Az elemzés során azt keressük, hogy bizonyos tokenek vagy tokensorozatok generálása szisztematikusan tovább tart-e, mint másoké.

Red Teaming alkalmazások és védekezés

Ezzel a technikával egy red teamer több célt is elérhet:

• Modell-architektúra feltérképezése: A különböző promptokra adott időzítési válaszok mintázatai utalhatnak arra, hogy a modell sűrű (dense) vagy ritka (pl. MoE) architektúrát használ-e.
• Rejtett szűrők és szabályok azonosítása: Ha bizonyos témájú vagy stílusú szövegek generálása során konzisztens lassulást tapasztalunk, az rejtett tartalomszűrőkre vagy moderációs logikára utalhat. Ezeket a „lassú zónákat” célzottan vizsgálva feltárhatjuk a modell belső korlátait.
• Információszivárgás a promptról: Bár ez egy fejlettebb támadás, extrém esetekben a kimeneti tokenek generálási ideje finom utalásokat tehet a feldolgozás alatt álló, de rejtett prompt tartalmára is.

Védekezési stratégiák

A szolgáltatók több módon is nehezíthetik az ilyen típusú elemzéseket:

• Időzítési zaj hozzáadása (Jitter): A válaszok közé szándékosan beiktatott, véletlenszerű késleltetések elfedhetik a valódi számítási időkülönbségeket.
• Válaszok pufferelése (Batching): Ahelyett, hogy minden tokent azonnal elküldenének, a szerver összegyűjthet néhányat, és egyben küldheti el őket. Ez elmossa az egyes tokenek generálási idejét.
• Konstans idejű műveletek (ritka): Elméletileg lehetséges olyan kódot írni, amely mindig ugyanannyi ideig fut, függetlenül a bemenettől. A komplex LLM-ek esetében ez azonban rendkívül nehezen megvalósítható és jelentős teljesítménycsökkenéssel járna.

Ez a támadási vektor rávilágít, hogy a biztonsági elemzésnek túl kell tekintenie a puszta kimeneteken. A metaadatok, mint például az időzítés, gyakran többet árulnak el a rendszerről, mint maga a generált tartalom. A következő fejezetben még mélyebbre ásunk, és megvizsgáljuk, hogyan használhatók ki a hardveres gyorsítótárak időzítési különbségei.