The GPU timing side channel is not exotic hardware. It reads only the attacker's own buffer, times each load every 5 microseconds, and turns a 3-microsecond median latency shift into a model fingerprint. Branislav Brzak of Stealthium measured this on NVIDIA H100 MIG slices and an NVSwitch server, separating what the signal reveals from what it cannot.
If you run an LLM on a shared cloud GPU, a co-tenant can learn which model you run, how fast it decodes and what kind of work it is doing without ever reading your data. The talk was published in October 2026, and the underlying barrier leak comes from the Behind Bars paper at USENIX Security.
How a GPU timing side channel reveals your LLM
A GPU timing side channel lets a co-tenant infer which LLM you run, how fast it decodes and what kind of text it generates by timing the attacker's own memory reads. No victim memory is read, no root access is needed and no traditional exploit is used. Branislav Brzak, a cybersecurity researcher at Stealthium, presented the work in a talk published in October 2026.
The attack rests on one hardware behaviour: a GPU memory barrier issued by one instance takes effect in every L2 partition on the board. In an NVIDIA H100 MIG (Multi-Instance GPU) deployment, compute units, VRAM, bandwidth quotas and L2 cache are partitioned per instance, and there is no cross-instance eviction, so L2 is not shared in that sense. The memory barrier is. A busy tenant makes every other tenant slightly slower, and the timing difference is measurable.
In the demonstrated setup the victim ran an 8-billion-parameter model on a slice with three compute units and 48 GB of VRAM, while the attacker used a single compute unit and 10 GB of VRAM.
The attacker primitive has three steps: load from the attacker's own small buffer, measure the load latency, repeat every 5 microseconds. To the naked eye, an idle tenant and a tenant serving an LLM look identical. The median latency difference is 3 microseconds. For the attacker, those 3 microseconds are enough to recover everything described below.
Brzak credits the underlying primitive and the MIG memory-barrier leak to the researchers behind the Behind Bars paper at USENIX Security, not to his own team.
Framing matters here. The talk separates what timing can recover from what it cannot. Model identity, architecture depth, decode rate, activity periods, token counts and response size are recoverable in the tested setup. Actual prompts, answers and content are not.
What the MIG experiments measured on H100 hardware
The measurements come from real NVIDIA H100 GPUs serving real LLMs on MIG slices. The victim ran an 8-billion-parameter model on a slice with three compute units and 48 GB of VRAM while the attacker used one compute unit and 10 GB. Brzak reports that model, architecture and depth were identified with 97% accuracy, and decode speed with 99.3% accuracy.
Those figures belong to the specific tested configurations, not to shared GPUs in general. Brzak states plainly that these are results from the setups he tested rather than a claim that every shared deployment leaks equally. Treat the percentages as configuration-specific measurements from a single research effort.
The per-token signal has structure worth understanding. A latency trace shows one burst per token, and its frequency spectrum carries a fundamental frequency of 881 Hz that corresponds to tokens per second, plus harmonics because each token is a mix of distinct frequencies rather than one clean tone. A single token in the time domain showed 39 peaks: green elevations marked layer invocations and orange ones marked extra processing between layers.
Decode rate alone is a weak fingerprint. Brzak measured Qwen 3 8B and Llama 3 8B decoding within 1.6% of each other in token rate, so speed alone cannot separate them. It narrows the candidate list without confirming an identity, which is why the layer-counting step matters.
Layer counting and the 0.028 integer distance
Layer counting turns a noisy timing trace into a model fingerprint by folding and averaging a trace once per model instead of once per token. The result is a bit count that lands close to an integer. Across 22 traces, the mean distance from an integer was 0.028, which Brzak calls the revealing detail.
The logic is that a fixed hardware artifact divided by different token rates would produce fractions, not whole numbers. Each count resolves to the model's layer count plus one to three additional peaks, and each model keeps its own signal fingerprint combining timing and harmonic structure.
This is not a trained machine-learning classifier. There is no training set, no labels and no fitting, and the method is under 30 lines of code. It checks each candidate depth from 16 to 48, measures how strongly that depth's expected signature appears in the real trace, and picks the best fit. For Qwen 3 8B, 36 layers won by 4.5 times over the next candidate.
Because it is a best-fit test rather than a lookup table, it can also work on models it has never seen, including proprietary and unreleased ones, since nothing had to have been seen first. The classifier also emits a confidence level, and in the reported tests only two of the least confident answers turned out to be wrong.
The same method distinguishes fine-tunes and installations that share a base model, because architecture and layer count stay fixed. Meta's Llama 3 8B has 32 layers, Llama 3.1 8B keeps the same 32-layer base with small updates, and DeepSeek's R1 distill on an 8B Llama base builds on that. Per-layer timing differences between them came to median latency changes of only 1.6 nanoseconds, and the classifier still separated them.
Workload inference depends on speculative decoding
Workload inference classifies whether the model is producing prose, code, JSON or retrieval output from timing alone. It assigns a verdict every half second based on the previous 5 seconds of timing data. Of 40 half-second verdicts, 31 were correct, and four whole responses were identified correctly by majority voting in the reported run.
A condition applies to that result, and it changes who is at risk. The measurement was taken with speculative decoding enabled, which is optional in vLLM and not the default. The mechanism is that how predictable the text is changes how many drafted tokens are accepted per step, which changes step timing, and that shift is the signal being captured.
Across 11 tested configurations covering dense and mixture-of-experts models in BF16 and FP8, the same figure shape appeared every time, with very different intensities. Brzak cites dispersion of 70.2% for GPT versus 20B and 0.9% for GLM 4 9B, and notes that prose was the fastest in 11 runs where chance alone would give one in four.
The honest scope is narrow. The workload-inference result applies to the demonstrated setup with speculative decoding active. It is not a general claim that any shared GPU reveals the category of text being generated.
The NVSwitch experiment: 890 nanoseconds to 300 microseconds
The NVSwitch experiment removes MIG from the picture entirely. The setup was a server with eight H100 GPUs connected through an NVSwitch fabric. The victim ran tensor parallelism across GPU 0 and GPU 1, while the attacker needed only any other GPU in the same server, GPU 2 in this case.
Peer access over NVSwitch is an intentional feature, not a bug being exploited. It is how multi-GPU jobs normally work. MIG also cannot coexist with tensor parallelism on the same device, so this is a different population of deployments rather than the same attack repeated with a new label.
On GPU 2, the attacker issues a memory-fetch pointer that resolves to memory actually on GPU 0 over NVLink and times each hop along the path. An idle hop takes about 890 nanoseconds, and once the victim starts working it rises to 300 microseconds. Across three half-second captures, token counts were visible to the naked eye.
What is lost at this distance is the layer bits, which fall below the noise floor. Over NVLink the fingerprints that remain are mainly temporal rather than layer counts. In an identical server configuration tested against five models, Brzak reports model identification at 79.2% accuracy, and the method fails exactly where a temporal signal should fail: Llama 3.5 8B and the R1 distill are both 8-billion-parameter models decoding within 3 Hz of each other, so they blur where MIG layer counts would have separated them cleanly.
The two configurations compared
MIG and NVLink partitioning are not stronger and weaker versions of one control. They expose different populations of deployments and leak different information.
| MIG slices | NVSwitch / NVLink | |
|---|---|---|
| Attacker placement | Same physical GPU | Any other GPU in the server |
| Peer-to-peer access | Not available | Available and intentional |
| Tensor parallelism | Cannot coexist with MIG | Enabled across GPU 0 and GPU 1 |
| Model identification | 97% (model, architecture, depth) | 79.2% |
| Layer-count fingerprint | Preserved | Lost below the noise floor |
| Residual signal | Full timing plus layer bits | Mainly temporal |
| Idle-to-busy latency shift | 3 microseconds median | 890 nanoseconds to 300 microseconds |
A 20% figure is the chance baseline to read the 79.2% against. A worse signal-to-noise ratio is not the same thing as security.
Detection: 3,000 kernel relaunches and 40 KB
Detection is possible, and Brzak reports that Stealthium's own product flagged the attack immediately. The product monitors every kernel launch across GPUs, analyses suspicious workloads and routes them into an alerting pipeline. That is a vendor-reported detection result from the speaker's own organisation, not an independent evaluation by third parties.
Two behaviours stood out in the flagged workload. A single kernel was relaunched roughly 3,000 times, hitting exactly the same 40 kilobytes of memory repeatedly instead of advancing to new data. Only 1 kilobyte of data was sent back to the CPU the whole time, because the timing itself was the payload rather than the output.
The probe from start to finish took under 600 milliseconds, with fewer than 50 tokens of response, and it was caught before the answer was even half written. The signature is a workload that reads the same small buffer in a tight loop and returns almost nothing to the host, which is not what useful inference looks like.
What operators can actually do about it
Operators control tenant placement, the tradeoffs between isolation options, and host-side visibility, so those three levers are where the defence conversation belongs. Brzak closes with exactly those three points rather than a product pitch.
- Do not place MIG slices belonging to an untrusted tenant next to a sensitive model. Placement is a decision an operator actually owns, and it is the simplest control available.
- Understand the tradeoffs between the two configurations tested. MIG rules out peer-to-peer communication, which means no tensor parallelism inside MIG. NVLink partitioning limits what leaks to timing alone, at the cost of losing layer counts, but a worse signal-to-noise ratio is not the same as security.
- Watch the GPU itself. Ensure the host infrastructure actively checks whether a malicious workload is running on the hardware, since that is where these probes are visible in kernel behaviour.
The 79.2% NVLink figure against a 20% baseline is still a real fingerprint rather than noise, which is the distinction Brzak stresses.
Evidence limits in this GPU timing side channel work
Evidence limits matter more here than the headline numbers. The H100 MIG and NVSwitch results come from one research effort in the tested configurations, and the vendor detection result comes from the same organisation that presented the attack. No independent third-party reproduction is described in the talk.
The hardware scope is narrow by design. These findings concern NVIDIA H100 GPUs with MIG or NVSwitch topologies, and nothing in the evidence establishes that AMD, Intel or other accelerators behave the same way. Hardware portability claims would need separate measurements.
The workload classifier depends on speculative decoding, which was on in the tests and is optional in vLLM. On deployments without it, the workload-inference result should not be assumed to carry over. Speed-only fingerprinting remains weak, as the 1.6% token-rate gap between two 8-billion-parameter models shows.
The broader lesson is that memory and compute isolation do not eliminate signals from hardware operations that span the whole device. Time was not isolated in either configuration Brzak tested, and that is the claim worth keeping.
FAQ: GPU timing side channel questions
Can a GPU co-tenant really identify my LLM?
In the configurations Branislav Brzak tested, yes. Model, architecture and depth were identified with 97% accuracy on MIG slices, and over NVSwitch model identification reached 79.2%. These are configuration-specific results from one research effort, not a guarantee about every shared deployment.
Does the attack read my model's memory or prompts?
No. The attacker only reads and times its own memory buffer. The talk states that prompts, responses and content are not recovered, only timing-derived properties such as model depth, decode rate, activity periods and workload category.
Why does a GPU memory barrier leak across MIG instances?
A memory fence issued by one instance still takes effect in every L2 partition on the board, even though compute units, VRAM, bandwidth quotas and L2 cache are partitioned. Brzak credits the barrier leak to the Behind Bars paper at USENIX Security.
What is the 0.028 figure in the layer-counting method?
It is the mean distance from an integer across 22 traces when a trace is folded and averaged once per model. Whole numbers rather than fractions indicate a real structural signal, since a fixed hardware artifact divided by differing token rates would produce fractions.
When does workload inference work?
Only in the tested setup with speculative decoding enabled, which is optional in vLLM and not the default. Predictability of the text changes how many drafted tokens are accepted per step, shifting step timing. With 40 half-second verdicts, 31 were correct.
How did Stealthium detect the probing workload?
A single kernel was relaunched about 3,000 times against the same 40 kilobytes of memory, and only 1 kilobyte returned to the CPU because timing was the payload. The probe finished in under 600 milliseconds with fewer than 50 tokens of response.
Does MIG give weaker or stronger protection than NVLink partitioning?
MIG loses peer-to-peer communication, which rules out tensor parallelism inside MIG, but it preserves layer-count fingerprints. NVLink partitioning keeps peer access and limits what leaks to timing, though 79.2% against a 20% baseline is still a real fingerprint.
Should I treat 79.2% accuracy as safe?
A weaker signal-to-noise ratio is not the same as security. Above a 20% chance baseline, 79.2% still carries information about which model is running, and the tested setup lost layer bits below the noise floor rather than removing the signal entirely.
Where should defensive effort go first?
Tenant placement is the lever operators own most directly, followed by understanding the isolation and communication tradeoffs of MIG versus NVLink partitioning, and then host-side monitoring that watches kernel behaviour on the GPU itself for repeated probing patterns.
Which models were used in the tests?
Qwen 3 8B ran on the victim slice during the MIG captures, and the layer-counting method separated it from Llama 3 8B and Llama 3.1 8B at 32 layers each, plus a DeepSeek R1 distill on an 8B Llama base. The NVSwitch test ran against five models.
Taking a video talk further
Research talks like this one carry a lot of detail that never survives a slide deck skim: the barrier leak, the 0.028 integer distance, the 79.2% NVLink figure and the caveats that define where each result applies. If you have knowledge like this sitting inside a YouTube video, whether it is a technical explanation, an interview or a lesson you recorded, Skala Blog turns that recording into a written article. Paste the YouTube URL at Skala Blog, transcribe the video and generate a draft you can edit. For developers working through this kind of low-level security material, Crazystack and the Crazystack Typescript track are a useful place to build the systems background that makes the mechanisms legible, and communities such as Gustavo Dev Doido and the Bootcamp do Dev Doido cover similar ground for people learning in public.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits