SwarmIO: GPU-Centric SSD Emulation

• SwarmIO is an SSD emulation framework for massively parallel, GPU-centric storage that enables realistic, end-to-end performance evaluation under high IOPS workloads.
• It uses a distributed service unit architecture combined with Intel DSA offloading to overcome CPU bottlenecks and efficiently emulate GPU-initiated control and data paths.
• The framework achieves up to 38.6 MIOPS with a 303.9x speedup over NVMeVirt while maintaining high fidelity with low error rates in IOPS and latency.

Searching arXiv for the exact term and closely related usage to ground the article in the relevant paper and disambiguate similarly named systems. SwarmIO is an SSD emulation framework for massively parallel, GPU-centric storage, designed to enable end-to-end, real-time performance evaluation of storage systems built around GPU-initiated I/O and IOPS-optimized SSDs (Kim et al., 8 Apr 2026). It targets a regime in which GPUs submit massive numbers of fine-grained, random reads directly to SSDs, while storage devices are expected to scale toward ultra-high random-read IOPS. In that setting, SwarmIO addresses a specific gap: no existing framework enables quantitative end-to-end evaluation of storage systems optimized for GPU-initiated I/O, and conventional SSD emulators become bottlenecked by frontend scalability, software overhead in GPU-initiated control and data path emulation, and timing-model maintenance at extremely high request rates.

1. Problem setting and design objectives

SwarmIO is motivated by a shift in which storage acts less as a passive capacity tier and more as an active memory-like tier for AI workloads. The motivating applications include RAG, recommendation systems, and agentic AI, all of which generate massive numbers of fine-grained, random reads. With GPU-initiated I/O, the GPU submits requests directly to SSDs, bypassing the CPU I/O stack, and can generate tens to hundreds of MIOPS. By contrast, today’s enterprise SSDs still top out around ~3 MIOPS, while future SSDs are expected to target 10–100 MIOPS. This creates a “chicken-and-egg” problem: devices targeting that range are being designed, but are not broadly available, and the available emulation infrastructure cannot faithfully model them under real GPU-initiated I/O workloads (Kim et al., 8 Apr 2026).

The framework is therefore organized around three explicit goals: frontend scalability, efficient emulation of GPU-initiated I/O paths, and low maintenance overhead for high-fidelity timing models. The paper states that SwarmIO is built with a fundamental goal of reaching 100 MIOPS, while the evaluated system sustains up to 40 MIOPS. This design point places SwarmIO less in the tradition of conventional host-centric NVMe emulation and more in the study of IOPS-limited, GPU-centric storage architectures.

2. System architecture

SwarmIO is implemented as a Linux kernel module and extends NVMeVirt’s idea of a software-defined virtual PCIe NVMe device, but replaces NVMeVirt’s centralized design with a distributed “service unit” architecture. A service unit is the modular operational unit in the system. Each service unit contains one dispatcher thread, one or more worker threads, one DSA group for hardware-accelerated transfers, and assigned NVMe submission/completion queue pairs. The request path is explicitly structured: the dispatcher polls SQ doorbells and fetches requests, computes each request’s target completion time using a global timing model, places requests into worker local queues, and workers perform data transfers and later post completions once the model’s target time has elapsed (Kim et al., 8 Apr 2026).

Frontend scalability is achieved first by partitioning NVMe queue pairs across multiple service units, so that each dispatcher handles only a subset of SQ/CQ pairs. This avoids the bottleneck of a single centralized dispatcher sequentially scanning all SQ doorbells. It is then reinforced by coalesced request fetching. When a doorbell indicates new submissions, SwarmIO gathers a batch of SQ entries into a reserved CPU memory fetch buffer. This is specifically effective for GPU-initiated I/O because GPU warps often submit multiple requests to the same SQ together, many warps interleave submissions so requests accumulate, and fetching them together reduces PCIe transaction overhead. To support larger transfers, the emulator sets the NVMe Contiguous Queues Required (CQR) bit so that queue entries are physically contiguous.

This organization preserves timing control in the emulator while making request ingestion itself scale with GPU-generated parallelism. A plausible implication is that SwarmIO’s central architectural move is not simply faster copying, but the decomposition of the emulation pipeline into independently scalable frontend and backend units.

3. Emulation of GPU-initiated control and data paths

The central control-path and data-path difficulty arises because, under GPU-initiated I/O, both I/O queues and buffers live in GPU memory. An emulator must therefore move request metadata and data over PCIe peer-to-peer paths. In NVMeVirt, this is emulated in software using CPU workers that repeatedly map GPU physical addresses to CPU virtual addresses, copy data, and unmap the addresses again. The paper reports that this dynamic map/unmap overhead accounts for 98.8% of total transfer latency in a microbenchmark, and that with 32 threads the emulated per-request transfer latency reaches 94 μs, limiting throughput to only 0.34 MIOPS (Kim et al., 8 Apr 2026).

SwarmIO’s answer is to offload copy operations to the Intel Data Streaming Accelerator (DSA). DSA is used for both dispatcher-side request fetching and worker-side storage data transfers. The design uses batch descriptors so that one descriptor can represent many copy operations, asynchronous offloading so CPU threads can continue executing while DSA transfers proceed, and multiple in-flight batches to exploit DSA pipelining. The paper further argues that Linux’s generic DMAEngine API is too abstract for this use case, and therefore introduces a DSA-aware kernel-level API with per-thread offloading contexts, direct batch descriptor programming, asynchronous issue, timeout-driven pending batch issuance, and timeout-driven waiting for the oldest in-flight batch.

This design replaces CPU-thread scaling with accelerator-assisted transfer orchestration. The significance is methodological as much as empirical: SwarmIO treats GPU-initiated I/O emulation as a control/data movement problem that must itself be parallelized in a device-aware manner, rather than as a conventional host-side software path that can be optimized only by adding CPU workers.

4. Timing model and fidelity

SwarmIO retains a global timing model shared across dispatchers. The paper explicitly rejects per-dispatcher timing models as inaccurate, because if only a few queues are active, a local model could underrepresent global load and fail to emulate real SSD behavior correctly. At the same time, naively updating a shared global model per request would create excessive lock contention and serialization. SwarmIO therefore introduces aggregated timing model updates: each dispatcher fetches a set of requests, computes the aggregate effect on resource availability, enters the critical section only once per batch, and applies updates in a single step. Each request’s completion time is still derived in order of appearance in the SQ, so synchronization overhead is amortized without discarding the intended timing semantics (Kim et al., 8 Apr 2026).

The timing model builds on NVMeVirt’s simple model, parameterized by maximum throughput $T_{max}$ and minimum latency $L_{min}$. Requests are decomposed into unit operations that occupy scheduling instances for a fixed scheduling time, and a request’s target completion time is derived from the time it can be scheduled, the scheduling occupation time, and the minimum latency constraint. The framework is validated against a real Solidigm D7-PS1010 SSD calibrated to 50 μs minimum latency and 2.47 MIOPS peak random-read throughput. The reported average relative IOPS error is 7.7% for fio and 7.4% for BaM, while the average relative end-to-end latency error under GPU-initiated I/O is 2.8%. By contrast, NVMeVirt is reported as accurate enough for CPU-centric I/O but unable to sustain target throughput under GPU-initiated I/O, with end-to-end latency 17.4–63.7x higher than the physical SSD.

These results position fidelity not as an afterthought but as a co-equal design target with scalability. SwarmIO’s model is simple in parameterization yet deliberately engineered so that fidelity does not collapse at the request rates that matter for GPU-centric systems.

5. Performance, scalability, and application study

Under GPU-initiated I/O, SwarmIO reaches 9.8 MIOPS with one DSA device and 38.6 MIOPS with four DSA devices at a 40 MIOPS target. The paper’s main scalability result is a 303.9x speedup over NVMeVirt, while the abstract and contributions section also mention 307.7x; the evaluation section’s headline number is 303.9x. SwarmIO sustains more than 96.6% of the configured target IOPS up to 40 MIOPS, and the paper attributes the current limit to platform DSA resources rather than a fundamental limitation of the design, projecting that a 100 MIOPS target is feasible with more DSA resources (Kim et al., 8 Apr 2026).

The ablation study resolves where these gains arise. Frontend optimizations—distributed dispatching, DSA-accelerated fetching, and coalesced fetching—yield up to 52.6 MIOPS frontend throughput and a 537.2x speedup over the baseline NVMeVirt frontend. Under GPU-initiated I/O, adding DSA fetching gives up to 2.8x speedup, adding coalescing gives up to 6.2x speedup, and combining all three performs best. On the timing side, scalability stalls beyond 10 MIOPS without aggregated timing model updates; with them, SwarmIO scales to 40 MIOPS with 16 service units, giving a 3.6x speedup over the baseline timing-update design.

A compact summary of the principal quantitative results is useful:

Aspect	Result	Context
Sustained performance	38.6 MIOPS	Four DSA devices at a 40 MIOPS target
End-to-end speedup vs NVMeVirt	303.9x	GPU-initiated I/O scalability result
Frontend throughput	52.6 MIOPS	With distributed dispatching, DSA fetching, and coalescing
Frontend speedup	537.2x	Over baseline NVMeVirt frontend
Fidelity	7.7%, 7.4%, 2.8%	Average relative IOPS error for fio, BaM, and latency error

The paper’s case study uses GPU-accelerated on-disk vector search with CAGRA, a BIGANN-100M dataset, a 71.5 GB index, a 2 GB GPU memory budget for the emulated setup, and 512 bytes SSD block size. When SSD IOPS increases from 2.5 MIOPS to 40 MIOPS, CAGRA search achieves up to 9.7x end-to-end speedup at batch size 256. The study also shows that the optimal search width depends on the SSD IOPS budget: at 5 MIOPS or below, search width 2 is best, whereas at 10 MIOPS or above, search width 4 becomes faster. The paper identifies this as evidence that future software should be IOPS-aware, not just GPU-aware.

6. Terminological scope and research significance

The name “SwarmIO” is potentially misleading outside storage systems because several arXiv papers use closely related “swarm” terminology for unrelated domains. “Distributed Swarm Intelligence” describes a distributed web application for interactive visualization and distributed execution of Particle Swarm Optimization using Ray, Panel, and Bokeh, but it is not about a system named SwarmIO (Kanjula et al., 2023). “Swarm-Enabling Technology for Multi-Robot Systems” presents a modular swarm-enabling unit and the marabunta library for retrofitting general-purpose robots into decentralized swarms, again without using “SwarmIO” as the formal system name (Chamanbaz et al., 2017). Other similarly named systems include ByteDance’s hybrid CDN/P2P video distribution system “Swarm” (Wei et al., 2024) and the aerial-swarm state-estimation systems “Swarm-LIO” and “Swarm-LIO2” (Zhu et al., 2022, Zhu et al., 2024). In this literature landscape, SwarmIO refers specifically to a storage-systems emulator for GPU-initiated I/O, not to swarm robotics, swarm intelligence, or peer-to-peer distribution.

Within that narrower scope, SwarmIO’s significance lies in two claims made by the paper. First, it makes end-to-end evaluation possible for GPU-centric storage systems that rely on GPU-initiated I/O and ultra-high-IOPS SSDs. Second, it enables realistic exploration of future storage-device scaling before the underlying hardware is broadly available. This suggests a broader methodological role: as storage becomes increasingly parallel, low-latency, and tightly coupled to accelerators, emulation frameworks must model not only device timing but also the concurrency structure of the software and interconnect path that drive those devices. SwarmIO is presented as an emulation substrate for exactly that regime.