Aanvallen op inferentieoptimalisatie
Aanvallen op speculatieve decodering, kwetsbaarheden in batching, exploitatie van continuous batching, en hoe optimalisatie voor snelheid beveiligingsgaten creëert in LLM-inferentie.
Productie-LLM-deployments optimaliseren agressief voor throughput en latency. Inferentieoptimalisaties -- speculatieve decodering, continuous batching, flash attention, tensorparallellisme -- introduceren elk een eigen aanvalsoppervlak. De kernspanning is dat het delen van computatie over verzoeken heen de efficiëntie verbetert maar interferentiekanalen tussen verzoeken creëert.
Aanvallen op speculatieve decodering
Speculatieve decodering gebruikt een klein draft-model om tokens te voorspellen die het grote doelmodel verifieert. Geaccepteerde voorspellingen slaan dure forward passes van het doelmodel over.
Architectuur
┌──────────────┐ Candidate tokens ┌──────────────┐
│ Draft Model │ ──────────────────────── │ Target Model │
│ (1-3B) │ "The quick brown fox" │ (70B+) │
│ Fast, cheap │ ────────────────────────│ Slow, accurate│
└──────────────┘ Accept/Reject └──────────────┘Aanvalsvector: Manipulatie van het draft-model
Het draft-model is kleiner, minder robuust en vaak minder gealigned dan het doelmodel. Als een aanvaller het draft-model kan manipuleren (via supply chain of modelvervanging), omzeilen geaccepteerde tokens de veiligheidseigenschappen van het doelmodel:
| Scenario | Aanval | Impact |
|---|---|---|
| Gecompromitteerd draft-model | Vervang draft door een model dat schadelijke tokens genereert | Schadelijke tokens geaccepteerd als ze de verificatie van het doelwit doorstaan |
| Distillatie van draft-model | Extraheer het gedrag van het draft-model via API | Onthult interne generatiepatronen |
| Exploitatie van acceptatiegraad | Ontwerp invoer die de draft-acceptatie maximaliseert | Vermindert toezicht door het doelmodel |
# Verificatie bij speculatieve decodering
def speculative_verify(draft_tokens, target_model, prompt):
"""Target model checks draft predictions in parallel."""
target_logits = target_model(prompt + draft_tokens)
accepted = []
for i, token in enumerate(draft_tokens):
draft_prob = draft_model_prob(token, context=prompt + accepted)
target_prob = target_logits[i].softmax(-1)[token].item()
# Accepteer als het doelmodel het eens is (gemodificeerde rejection sampling)
if random.random() < min(1, target_prob / draft_prob):
accepted.append(token)
else:
# Hersample uit aangepaste verdeling
corrected = resample(target_logits[i], draft_logits[i])
accepted.append(corrected)
break # verwerp resterende draft-tokens
return acceptedKwetsbaarheden in continuous batching
Continuous batching (ook wel iteration-level batching genoemd) voegt verzoeken dynamisch toe aan en verwijdert ze uit een lopende batch. Dit creëert verschillende kanalen tussen verzoeken.
Cross-request-interferentie
In een continuous batch delen alle verzoeken dezelfde forward pass door het model. Hoewel verzoeken aparte KV-caches en attentiemaskers gebruiken, delen ze:
| Gedeelde resource | Interferentiekanaal | Waarneembaar signaal |
|---|---|---|
| GPU-compute | Latencyvariatie op basis van batchsamenstelling | Timing-zijkanaal |
| Geheugenbandbreedte | Grote verzoeken vertragen alle verzoeken in de batch | Throughput-correlatie |
| Batch-scheduling | Prioriteit/volgorde beïnvloedt generatiekwaliteit | Informatie over wachtrijpositie |
| Tensor cores | Gedeelde matrixvermenigvuldigingshardware | Power-/thermische zijkanalen |
Timing-zijkanaal via batching
import time
import asyncio
async def probe_batch_occupancy(api_url: str) -> dict:
"""Measure latency variance to infer batch occupancy.
High variance = dynamic batching with variable load.
Consistent fast = low occupancy.
Consistent slow = high occupancy."""
latencies = []
for _ in range(50):
start = time.perf_counter()
await send_request(api_url, "Hello", max_tokens=1)
latencies.append(time.perf_counter() - start)
await asyncio.sleep(0.1)
return {
"mean": sum(latencies) / len(latencies),
"variance": variance(latencies),
"min": min(latencies),
"max": max(latencies),
}Beveiligingsoverwegingen bij flash attention
Flash Attention berekent exacte attentie maar verandert het geheugentoegangspatroon. Hoewel het wiskundig identieke resultaten produceert als standaardattentie, kunnen implementatiebugs kwetsbaarheden creëren:
| Aandachtspunt | Risiconiveau | Mitigatie |
|---|---|---|
| Numerieke precisieverschillen | Laag | Flash Attention is wiskundig exact |
| Bugs in custom CUDA-kernels | Gemiddeld | Geheugenveiligheidsproblemen in C++/CUDA-code |
| Effecten op tegelgrenzen | Laag | Randgevallen op blokgrenzen |
| Maskerverwerking | Gemiddeld | Onjuiste attentie-maskering kan cross-sequence-attentie lekken |
Zijkanalen bij tensorparallellisme
Tensorparallellisme splitst modellagen over GPU's. Communicatie tussen GPU's (via NVLink of InfiniBand) creëert netwerk-waarneembare zijkanalen:
Exploiteerbare signalen
- Communicatievolume -- De grootte van activatietensoren correleert met de lengte van de invoersequentie
- Timingpatronen -- AllReduce-synchronisatie creëert waarneembare latencypatronen
- Geheugenallocatie -- GPU-geheugengebruik is op gedeelde systemen zichtbaar via NVIDIA-management-API's
# Op gedeelde GPU-systemen, monitor het geheugengebruik van peer-GPU's
# om de inferentiepatronen van andere tenants af te leiden
import pynvml
pynvml.nvmlInit()
def monitor_peer_gpu_memory(gpu_indices: list, duration_s: float):
"""Sample GPU memory usage to detect inference activity."""
samples = []
start = time.time()
while time.time() - start < duration_s:
snapshot = {}
for idx in gpu_indices:
handle = pynvml.nvmlDeviceGetHandleByIndex(idx)
info = pynvml.nvmlDeviceGetMemoryInfo(handle)
snapshot[idx] = info.used
samples.append(snapshot)
time.sleep(0.01)
return samplesAfwegingsmatrix voor optimalisatie versus beveiliging
| Optimalisatie | Throughput-winst | Beveiligingsrisico | Aanbevolen mitigatie |
|---|---|---|---|
| Speculatieve decodering | 2-3x | Manipulatie van draft-model, verminderde verificatie | Verifieer de herkomst van het draft-model, monitor acceptatiegraden |
| Continuous batching | 3-5x | Timing tussen verzoeken, resource-interferentie | Verzoekisolatie voor gevoelige workloads |
| Prefix-caching | 2-4x | Cross-tenant-cachelekkage | Tenant-gescopete cachesleutels |
| Quantisatie | 2-4x geheugen | Veiligheidsdegradatie | Benchmark de veiligheid op de doelprecisie |
| Tensorparallellisme | Maakt grote modellen mogelijk | Zijkanalen tussen GPU's | Netwerkisolatie, versleutelde communicatie |
| Flash Attention | 2-4x snelheid | Minimaal (exacte berekening) | Verifieer maskerverwerking bij integratie |
Assessment-methodologie
Breng de inferentiestack in kaart
Identificeer welke optimalisaties zijn ingeschakeld: speculatieve decodering, continuous batching, prefix-caching, quantisatieniveau, parallellismestrategie.
Test cross-request-interferentie
Stuur gelijktijdige verzoeken met bekende inhoud en meet of de kenmerken van het ene verzoek (lengte, inhoud, timing) waarneembaar zijn vanuit een ander verzoek.
Profileer timing-zijkanalen
Meet latencyverdelingen onder wisselende serverbelasting om de informatielekkage via timing te karakteriseren.
Verifieer de integriteit van het draft-model
Als speculatieve decodering wordt gebruikt, verifieer dan onafhankelijk de herkomst en de veiligheidseigenschappen van het draft-model.
Documenteer afwegingen
Rapporteer welke optimalisaties welk risiconiveau creëren, met aanbevelingen voor het specifieke dreigingsmodel van de deployment.
Gerelateerde onderwerpen
- Aanvalsvectoren op modelarchitectuur -- Overzicht van het architectuuraanvalsoppervlak
- KV-cache-vergiftiging -- Cachespecifieke aanvallen
- Quantisatieaanvallen -- Risico's van precisiereductie
- API-beveiliging -- Inferentiebeveiliging op applicatieniveau
Wat is het belangrijkste beveiligingsaandachtspunt bij speculatieve decodering in LLM-inferentie?
Referenties
- Fast Inference from Transformers via Speculative Decoding (Leviathan et al., 2023) -- Speculative decoding
- Orca: A Distributed Serving System for Transformer-Based Generative Models (Yu et al., 2022) -- Continuous batching