PaperlayerView exact revision on arXiv

Source-linked AI summary

SparLeak: Privacy Leakage from Sparse Attention in LLM Inference on Shared GPUs

Fahao Chen, Linkang Du, Jinhao Zhou, Peng Li, Zhou Su

arXiv:2609.38830v1cs.LGcs.CR

TL;DR

Sparse attention makes long-context inference more efficient, but its secret-dependent GPU memory accesses create a privacy side channel. SpaRLeaK extracts phase-specific traces and reconstructs approximate sparsity patterns to infer query attributes and recover generated tokens. It reports average attack success rates of 90.9% and 87.3%, respectively.

  • Problem

    Sparse attention’s input-dependent KV-cache accesses create observable contention in shared GPU micro-architectural components, exposing a previously unexplored privacy side channel.

    Source: §1 · p. 1

  • Method

    SpaRLeaK extracts cumulative prefill and step-wise decoding traces, reconstructs approximate token-level sparsity profiles, and uses profiling-based learning for attribute inference and token recovery.

    Source: §1 · p. 2

  • Results

    90.9% average attack success for query attribute inference and 87.3% for autoregressive token recovery are reported across a broad range of configurations.

    Source: §1 · p. 2

  • Takeaways & Limitations

    SIMA patterns expose sensitive information through shared GPU resources during both prefill and decoding, making sparse-attention inference a privacy risk in the evaluated serving settings.

    Source: §1 · p. 1, §9 · p. 13

    A window of length Δ may not align perfectly with one decoding step because of scheduling jitter.

    Source: §4.2.2 · p. 7

Abstract

from arXiv · show

Sparse attention is widely used to accelerate long-context inference in modern large language models (LLMs), but its input-dependent execution behavior introduces previously unexplored privacy risks. We identify a new GPU micro-architectural side channel, termed Sparsity-Induced Memory Access (SIMA), which arises from secret-dependent key-value cache access patterns induced by sparse attention. Based on this observation, we present SparLeak, a phase-aware side-channel attack that extracts SIMA traces during LLM inference and enables two practical privacy extractions: query attribute inference from prefill-phase traces and autoregressive response reconstruction from decoding-phase traces. By reconstructing approximate token-level sparsity profiles from page-level observations and applying profiling-based learning, SparLeak accurately recovers sensitive information, including user-query attributes and private LLM response content. Extensive evaluation across three LLM architectures, three sparse attention mechanisms, and three privacy-sensitive datasets shows that SparLeak achieves average attack success rates of 90.9% for attribute inference and 87.3% for response reconstruction under real-world LLM serving settings, highlighting the significance to account for SIMA leakage when deploying sparse-attention-based LLM systems. We provide anonymized SIMA traces, trained attack models, evaluation scripts, and documentation as artifacts at https://anonymous.4open.science/r/Janus_artifacts/.

1 Introduction

Sparse attention reduces the cost of long-context LLM inference by selecting a subset of tokens, but those input-dependent choices create observable GPU memory-access patterns. SpaRLeaK turns these patterns into phase-specific attacks on private queries and generated responses.

1 Introduction

  • Sparse attention creates secret-dependent KV-cache accesses that contend in shared GPU caches and TLBs, exposing a side channel termed SIMA.These internal accesses are not directly exposed through the LLM service interface.Source: §1 · p. 1
  • Unlike prior timing, network-traffic, and embedding-cache side channels, SIMA is model-intrinsic and spans both prefill and decoding phases.The introduction characterizes this breadth as enabling broader and more persistent privacy leakage.Source: §1 · p. 1
  • SpaRLeaK extracts cumulative prefill traces with an L2-cache Invalidate+Compare primitive and step-wise decoding traces with a TLB-based Evict+Reload primitive.It distinguishes phases from GPU execution dynamics.Source: §1 · p. 2
  • SpaRLeaK reconstructs approximate token-level sparsity from page-level traces, then uses offline profiling to map the patterns to query attributes or generated tokens.The learned mapping is applied at runtime without access to the victim’s model, prompts, or outputs.Source: §1 · p. 2
  • 90.9% average attack success for query attribute inference and 87.3% for autoregressive token recovery demonstrate leakage across both attack targets.The evaluation spans multiple LLMs, sparse-attention mechanisms, and privacy-sensitive datasets.Source: §1 · p. 2
  • SpaRLeaK retains over 90% of its original attack effectiveness under realistic system noise and model evolution, while input-independent randomness reduces effectiveness at the cost of inference quality.The introduction identifies randomness as a potential mitigation with a quality trade-off.Source: §1 · p. 3

2 Background and Motivation

The section explains how sparse attention changes LLM inference and why its phase-dependent sparsity patterns can reveal information about prompts and generated responses.

2.1 Large Language Models Inference

  • Sparse attention reduces computation and memory overhead by selecting only a subset of tokens, while inference uses a prefill phase followed by autoregressive decoding with a reused KV cache.The section classifies sparse-attention methods as activation-based saliency, block-level scoring, or learned predictors.Source: §2.1 · p. 3
  • GPU page-level KV accesses aggregate multiple tokens, translating sparse token selection into data-dependent memory-access patterns.The KV cache is stored in GPU memory and managed at page granularity.Source: §2.1 · p. 3

2.2 Motivation

  • Prefill sparsity is highly skewed and varies across layers and heads, while each decoding step selectively activates a small fraction of context tokens.The distinct structures motivate a phase-aware view of sparsity-induced leakage.Source: §2.2 · p. 4
  • Changing one query attribute while holding the prompt structure and length fixed can reshape prefill sparsity, suggesting a signal for inferring semantic attributes without recovering exact prompt text.The motivating example varies illness category while keeping other attributes and the system prompt identical.Source: §2.2 · pp. 4–5
  • Different generated tokens, including semantically related tokens, induce distinguishable decoding sparsity patterns because attention depends on the current token and prior generated context.These token-dependent patterns motivate autoregressive token recovery across decoding steps.Source: §2.2 · p. 5

3 Attack Overview

SpaRLeaK assumes a co-resident spy can observe GPU micro-architectural effects during a victim’s sparse-attention inference. Its workflow extracts phase-aware traces, reconstructs approximate token-level patterns, and uses them to infer private information.

3.1 Threat Model

  • The threat model places an unprivileged spy process on the same physical GPU as a victim using sparse-attention inference with a public, fixed system-prompt template.The victim’s user query and generated response remain private.Source: §3.1 · p. 5
  • The spy measures its own probes to monitor L2-cache activity and TLB residency, requiring neither privileged counters nor access to victim memory.The adversary does not control GPU scheduling or exact execution timing.Source: §3.1 · p. 5

3.2 Attack Workflow

  • SpaRLeaK extracts cumulative prefill and step-wise decoding traces, reconstructs approximate token-level sparsity, then trains lightweight MLP classifiers for query-attribute inference and token recovery.The stages use calibrated probe mappings and exploit sparsity locality and statistical regularity.Source: §3.2 · p. 6

4 Phase-Aware SIMA Trace Extraction

SpaRLeaK distinguishes prefill from decoding through GPU execution patterns, then extracts phase-specific SIMA traces: cumulative page-access estimates during prefill and step-wise observations during decoding.

4.1 Prefill and Decoding Distinction

  • Prefill’s concentrated, compute-heavy GPU-kernel burst contrasts with decoding’s long, near-periodic token-generation trace.The attack uses these distinct execution patterns to distinguish the phases.Source: §4.1 · p. 6

4.2 SIMA Trace Extraction

  • During prefill, calibrated L2-cache replacement effects estimate how frequently each monitored prompt-side KV page is accessed, yielding a cumulative SIMA trace.The measurement captures relative page-level sparsity, not exact access counts or runtime addresses.Source: §4.2.1 · p. 6, Figure 8 · p. 7
  • During decoding, TLB Evict+Reload probes detect page access at each generation step, producing a binary, step-wise SIMA trace.A conflicting attacker probe page’s translation may be displaced by victim access; a reload above a calibrated latency threshold marks the page as accessed.Source: §4.2.2 · p. 7, Figure 9 · p. 7
  • Adjacent-window measurements are combined by majority vote to tolerate probing windows that misalign with decoding steps because of scheduling jitter or noise.The probing-window length is set to approximately cover one generation step.Source: §4.2.2 · pp. 7–8

5 Sparsity Pattern Reconstruction

Page-level SIMA observations lose intra-page token detail, so SpaRLeaK reconstructs approximate token-level sparsity using patterns associated with prefill frequency and decoding-time locality.

5 Sparsity Pattern Reconstruction

  • Page-level observations compress multiple token activations and lose intra-page detail, while uniform allocation would miss sparse attention’s non-uniform structure.The reconstruction methods use statistical cues in page-level traces to recover approximate token-level patterns.Source: §5.1 · p. 8, §5 · p. 8

5.1 Prefill-Phase Sparsity Reconstruction

  • Higher-frequency prefill pages tend to contain more skewed, long-tailed token activation, while lower-frequency pages tend to have flatter distributions.SpaRLeaK uses each page’s observed frequency to set token-level concentration while preserving consistency with that page-level frequency.Source: §5.1 · p. 8

5.2 Decoding-Phase Sparsity Reconstruction

  • During decoding, pages with denser local page-level activation tend to contain more active tokens; SpaRLeaK uses local page-activation density to reconstruct a representative token pattern.The reconstructed pattern preserves observed page-level signals and step-wise spatial structure.Source: §5.2 · pp. 8–9

6 Sparsity-Guided Inference Attack

SpaRLeaK uses reconstructed sparsity profiles in two profiling-based attacks: classifying semantic attributes of prompts from prefill traces and recovering response tokens from decoding traces.

6 Sparsity-Guided Inference Attack

  • The inference attacks map reconstructed token-level sparsity profiles to private information using models trained offline on profiles paired with known labels or tokens.Query attribute inference uses prefill traces; autoregressive token recovery uses decoding traces.Source: §6.1 · p. 9, §6.2 · p. 9, §6 · p. 9

6.1 Query Attribute Inference

  • Query attribute inference classifies prompt attributes from normalized prefill sparsity profiles, retaining and concatenating features across layers and attention heads.Offline profiles are paired with known attribute labels; normalization removes global scale differences associated with query length and attention activity.Source: §6.1 · p. 9

6.2 Autoregressive Token Recovery

  • Autoregressive token recovery classifies each output token from decoding profiles, augmenting features with prior-step sparsity and restricting predictions to a task-specific profiled candidate set.The candidate set is fixed before online execution, and recovery proceeds sequentially without access to victim outputs.Source: §6.2 · p. 9

7 Evaluation

The evaluation measures phase-specific attack success across LLMs, sparse-attention mechanisms, and privacy-sensitive datasets, then examines reconstruction, practicality, and a possible mitigation. Results show strong attack performance, while randomized sparse selection reduces leakage at a generation-quality cost.

7.1 Evaluation Setup

  • Evaluation spans three LLM families, three sparse-attention mechanism classes, and Healthcare, Financial QA, and Legal QA datasets.The study evaluates phase-specific attack success rates; PASR is the fraction of correct attribute predictions among queries containing the corresponding attribute.Source: §7.1 · pp. 9–10

7.2 Attack Performance

  • Average prefill PASR exceeds 91% across datasets, while DASR ranges from 84.6% to 89.4%, with every setting above 80%.Reconstructed real observations are about 2.5 points below the token-level oracle; page reconstruction keeps performance within approximately one point of that oracle.Source: Table 2 · p. 10, §7.2 · p. 11, Figure 12 · p. 11
  • Learned predictors achieve the highest PASR at around 95.5%, while activation-based methods yield approximately 86.4% PASR and lower DASR.Across LongChat-7B, LLaMA3-8B, and Qwen3-8B, average PASR is approximately 90.6%, 89.4%, and 92.7%, respectively; Qwen3-8B has the highest decoding DASR across datasets.Source: §7.2 · p. 11

7.3 Ablation Study

  • At page size 20, Healthcare PASR falls to 57.45% without reconstruction but remains substantially higher when reconstruction is enabled.Coarser page aggregation increasingly obscures token-level information and degrades both attacks without reconstruction.Source: §7.3 · pp. 11–12, Figure 13 · p. 11

7.4 Practicality Analysis

  • Target-interactive profiling achieves average PASR and DASR of 90.97% and 86.65%, with maximum reductions of only 1.28 and 1.54 percentage points versus replica-based profiling.Spy-process overhead is 1–3% during prefill and 4–6% during decoding, with worst-case slowdown below 8%.Source: §7.4 · p. 12

7.5 Possible Mitigation

  • Increasing random-replacement perturbation reduces attack success rate but also degrades generation quality; at 30%, LLaMA3-8B ROUGE drops from 0.48 to 0.16.The mitigation evaluation uses Financial QA and perturbation intensities from 10% to 30%.Source: §7.5 · p. 12, Table 4 · p. 12

8 Related Work

Prior work on LLM privacy has studied algorithm- or API-level exposure, while side-channel studies have examined timing, network traffic, and CPU-cache signals. SpaRLeaK instead targets sparse-attention memory behavior during inference.

Privacy leakage in LLMs

  • Prior LLM privacy attacks address training-data memorization, membership inference, and prompt attribute inference, typically using outputs or crafted API prompts.SpaRLeaK targets inference-time execution behavior without API-level interaction.Source: §8 · p. 13

Side-channel attacks on LLMs

  • Earlier LLM side channels use latency, encrypted traffic patterns, or embedding-table accesses, whereas SpaRLeaK exploits memory access behavior intrinsic to sparse attention.Its leakage manifests across both prefill and decoding, supporting query attribute inference and autoregressive token recovery.Source: §8 · p. 13
  • Sparse-attention leakage is amplified by sparsity and appears in both prefill and decoding phases.The paper presents this as a unified framework for query attribute inference and autoregressive token recovery.Source: §8 · p. 13

9 Conclusion

The conclusion presents SpaRLeaK as a study of privacy leakage from sparse-attention LLM serving. It uses phase-specific SIMA traces for query attribute inference and token recovery, with evaluations demonstrating effectiveness and robustness.

9 Conclusion

  • SpaRLeaK studies micro-architectural privacy leakage in sparse-attention-based LLM serving.The paper identifies sparsity-induced memory access patterns that expose sensitive information through shared GPU resources.Source: §9 · p. 13
  • Prefill-phase SIMA traces support query attribute inference, while decoding-phase traces support autoregressive token recovery.These are the two inference attacks described in the conclusion.Source: §9 · p. 13
  • Evaluations across multiple LLMs, sparse-attention mechanisms, and datasets demonstrate attack effectiveness and robustness.Source: §9 · p. 13
Loading 2609.38830v1…