A reproducible interference benchmark for GPU multi-tenancy on an NVIDIA H100 PCIe 80 GB. It co-locates a measured victim tenant with a deliberately greedy antagonist on the same GPU and asks what each sharing mechanism costs a data-management workload, in two regimes that disagree: bandwidth-bound relational batch processing, and latency-sensitive stream processing judged on its tail.
This is the measurement artifact behind a paper under review: the benchmark, the analysis, and the per-cell aggregates every reported number is computed from.
Four mechanisms plus one tuning knob, compared at matched hardware (one shared 2g.20gb
instance against two partitioned 1g.10gb instances cut from the same silicon):
| shares | isolates | |
|---|---|---|
| Time-slicing (default) | everything; one context at a time | nothing |
| MPS | SMs, L2, memory controllers, concurrently | correctness only |
| MPS + SM cap | as MPS, with a per-client SM budget | SM share, not bandwidth |
| MIG | nothing below the instance boundary | SMs, L2 slices, memory channels |
| Docker | the device is passed through | nothing on the GPU |
Each mechanism is reported over four crossed load planes, both tenants' load varying over the same grid, rather than at a single operating point.
- The mechanism choice depends on the objective. Between two saturating batch tenants, sharing can increase aggregate throughput over partitioning (521 GB/s under MPS against 478 under MIG at matched 3 GB working sets) while reducing the measured tenant to roughly half its solo rate. MIG gives the most stable own-solo service.
- Against a sustained batch antagonist a streaming victim fares better under time-slicing than under uncapped MPS, and MIG stays close to its own-solo baseline.
- Sustained bottleneck pressure is an organizing hypothesis, not a demonstrated mechanism. Larger events, continuous batch execution and more sustained tenants all increase interference, which is consistent with it; isolating the cause would need direct counter measurements.
- An MPS SM cap improves service against one antagonist (at the standard cell, from ~47 ms and 90% drops to at most 2.4% drops at sub-ms tails) but does not remain effective as the number of capped antagonists grows.
- Docker behaves like bare-process time-slicing in most measured cells, with one large outlier retained for investigation. These results characterize isolated operator kernels rather than complete data systems.
orchestrator/ expands a campaign design into cells and runs them
worker/ the measured tenant (CUDA): batch and open-loop streaming drivers
kernels/ the three instruments plus a hash-join probe (CUDA)
analysis/ cell aggregation and loading
scripts/ figure builders (make_*.py), campaigns (run_*.sh), aggregation
results/agg/ per-campaign aggregates: the basis for every figure
results/figures/ the renders behind the manuscript's figures
results/raw/ is 211 GB of per-event CSVs archived on the lab host, not in git. The committed
aggregates carry one row per measured cell, which is what every reported number is computed
from; figures rebuild from them with python3 scripts/make_<name>.py.
Requires an H100 (or another MIG-capable GPU) with the instances the arms expect, CUDA 12.5, and
nvidia-cuda-mps-control on the path. Nothing needs root: the harness verifies the environment
rather than imposing it.
make && make selftest
./scripts/discover_mig.sh
./scripts/run_s17_max1.shEach cell is measured three times with paired arrival seeds across mechanisms, in shuffled order. Two gates run before a cell's numbers count: MPS engagement is read from the daemon log, and a liveness check confirms the antagonist covered the victim's entire measured window.
- One GPU model, driver, MIG layout and operating point.
- Compact single-operator kernels, not full pipelines with windowed state.
- Deliberately adversarial antagonists, so headline numbers bound the worst case.
- Whole-board energy; per-instance attribution needs tooling that was not available.
- The arrival path saturates near 65 k events/s; cells above that ceiling are reported as true completion rates rather than credited with the offered load.
- Run-to-run ranges over three repetitions, not confidence intervals.
MIT (LICENSE); citation metadata in CITATION.cff.
Aaron Louis Eidt · TU Berlin, DIMA.
The paper's cross-tenant leakage study (C1) by Hoang Khang Nguyen is published separately.