---
title: "Storage IOPS, Throughput and Latency: Which Number Does the GPU Offer Establish?"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/gpu-storage-iops-throughput-latency-comparison"
last-updated: "2026-10-20"
---

# Storage IOPS, Throughput and Latency: Which Number Does the GPU Offer Establish?

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

IOPS counts storage operations per second; byte throughput counts data transferred per second; latency measures how long a request takes to complete at a stated boundary. An offer establishes a useful performance comparison only when the request sizes, counted operations, workload conditions and response requirements agree. A larger headline number alone cannot establish that the storage will serve the intended GPU workload better.

## Identify the count and the clock

A storage line in a GPU proposal might advertise IOPS, GB/s or a latency value. Each needs a different denominator. IOPS means input/output operations per second. Request size describes bytes per operation. Byte throughput describes bytes per second. Completion latency is elapsed time between the identified request start and its completion acknowledgement.

The word throughput can itself be ambiguous: SNIA's benchmarking discussion describes its use for both operation rate and byte rate. This article uses byte throughput for a quantity such as MB/s or MiB/s. Keep the unit beside the number rather than comparing two claims because both use the word throughput.

Also identify the population: one drive, one volume, one client or a complete shared system. An aggregate system rate is not a measured per-client rate after division by the client count. Random and sequential describe access order; either pattern has operation counts, transferred bytes and request latencies. Neither pattern belongs exclusively to one metric.

References: [A1](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html), [S1](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0)

## Convert IOPS to bytes without changing the claim

For completed data operations counted at the same boundary over the same interval, multiply operations per second by bytes per counted operation. If sizes vary, use the operation-weighted average size from that same population, or sum the actual counted bytes. A nominal request size from a different workload cannot complete the calculation.

Consider two wholly fictional operating points. Point A stipulates 100,000 completed operations/s, each transferring 4 KiB. The byte rate is 100,000 × 4 × 1,024 = 409,600,000 B/s, or 390.625 MiB/s. Point B stipulates 4,000 completed operations/s, each transferring 256 KiB. Its byte rate is 4,000 × 256 × 1,024 = 1,048,576,000 B/s, or 1,000 MiB/s.

A has 25 times as many operations per second; B has 2.56 times the byte rate. The request sizes differ by a factor of 64, so these are different workloads. Neither point identifies a measured device, proves a sustainable rate or supplies a latency result. The arithmetic exposes what the units mean; it cannot choose a real product.

Preserve the prefixes. One KiB is 1,024 B and one MiB is 1,048,576 B; one kB is 1,000 B and one MB is 1,000,000 B. Thus A is also 409.6 MB/s and B is 1,048.576 MB/s. Those are conversions of the same byte counts, not additional performance. If an offer's MB/s label uses an unstated convention, resolve it before comparing.

References: [U1](https://physics.nist.gov/cuu/Units/binary.html)

## Locate the counted operation before using its size

An application read, an operating-system request and a storage-service operation can occupy different counting boundaries. SNIA emphasizes that two IOPS figures need the same vantage point. A count taken inside an array should not silently become the count seen by a client.

Amazon EBS provides a concrete implementation example. Its documentation explains that eligible small sequential requests may be merged and larger requests may be split for EBS operation accounting. It also describes differences between counts observed inside an instance and those recorded by EBS. These are EBS-specific behaviors, not rules for every SSD, filesystem or storage service.

Consequently, multiplying an EBS operation count by an application's original request size can combine mismatched populations. Use the size of the operations actually counted at the selected boundary. Ask the supplier where both the operation count and byte count originate, and how any splitting or merging is represented. A mismatch can be an accounting difference without establishing that either reported number is wrong.

References: [S1](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0), [A1](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)

## Read latency alongside concurrency and offered work

Taking the reciprocal of aggregate IOPS gives time per counted completion in the aggregate. It does not generally give the elapsed time experienced by an individual request. Several requests can be in progress together, while a client can also pause before supplying more work.

An ideal fictional example makes the difference visible. Stipulate that each request takes exactly 2 ms, with no gaps between successive batches. One request at a time produces 500 completions/s. Eight fully overlapping requests, each still taking 2 ms, produce 4,000 completions/s. The higher aggregate rate has not reduced any request's latency. These are stipulated timing relationships, not measured storage behavior or a recommended concurrency setting.

SNIA's discussion distinguishes both concurrency and client idle time when interpreting operation rates. AWS likewise notes that a client offering insufficient I/O may not use its provisioned performance. A low observed rate therefore does not, by itself, establish a storage ceiling. Conversely, a high rate achieved with many outstanding requests does not establish response time for a lightly concurrent workload. Retain the actual offered load and achieved concurrency; prescribing a queue depth would require a different, configuration-specific evaluation.

References: [S1](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0), [A1](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html)

## Keep response evidence attached to the rate

A latency claim needs its start and finish points, read or write population and reported statistic. A mean and a percentile answer different questions. A 99th-percentile value describes a duration within which roughly 99% of the observed requests completed under the report's definition. It is neither the mean nor a guarantee about every future request.

The fio documentation illustrates why the clock matters: it distinguishes submission, completion and total latency, and reports latency percentiles separately. Its workload description also distinguishes access pattern, request size, I/O depth and the generating processes or threads. These are useful interpretation fields even when the supplier uses another measurement tool.

Compare the rate and response evidence from the same operating point. A supplier's highest byte rate from one workload and lowest latency from another do not establish that both occur together. For a write claim, retain what the stated completion acknowledges. For any result, retain the error or failed-request treatment rather than assuming that a large issued-request count represents successful completed work.

References: [F1](https://fio.readthedocs.io/en/latest/fio_doc.html)

## Decide what the offer actually supports

Request evidence for the intended read/write mix, request-size distribution and access order, with concurrency, cache or buffering state, working-set size, measurement duration and response conditions visible. Retain the actual hardware/software configuration and whether the number is a specification, provisioned limit or observed result. The fio documentation treats workload size, buffering and timed measurement as distinct inputs; matching only the drive model leaves those conditions unresolved.

Suppose the buying requirement concerns small reads within an agreed response condition. An offer supplying only a large-request GB/s figure leaves that requirement unanswered, even if its byte rate exceeds another offer's. Ask for the relevant small-request evidence at the required load. If the requirement instead concerns moving a defined volume of data within a window, compare matching byte-rate evidence and its operating conditions. Neither case can borrow the other's headline result.

Use the fictional A and B calculation to detect the mismatch, not to normalize away different workloads. Converting both numbers into MiB/s makes their units comparable; it does not make their request patterns equivalent. A useful shortlist identifies which offer supplies evidence for the actual requirement and which still needs clarification. It does not select the largest value across unlike metrics.

References: [F1](https://fio.readthedocs.io/en/latest/fio_doc.html)

## Carry the selected system into the physical cabling scope

Once the storage and platform owners have selected the system, the physical project needs its equipment identities, approved endpoints, routes and customer-supplied cable assemblies. A network port's nominal link rate does not establish application storage throughput. The storage-network handoff guide linked below explains the connection records without substituting them for workload evidence.

Leviathan's structured cabling service can discuss installation, routing, dressing, labeling and agreed physical connection records. Use the service and project-inquiry links below when that work is needed. Share a nonconfidential equipment and site summary with the approved connection requirements; storage sizing, configuration, tuning and performance evaluation remain with the appointed specialists.

References: [L1](https://www.leviathansystems.co/services/structured-cabling)

## Primary sources

- [A1 — Amazon EBS: I/O characteristics and monitoring](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-io-characteristics.html). Checked 2026-10-19. EBS operation accounting, request splitting and merging, completion timing and offered-I/O context. Product-specific examples help identify measurement boundaries; they do not define universal drive behavior.
- [S1 — SNIA: Storage Performance Benchmarking Q&A](https://www.snia.org/blog/2015/storage-performance-benchmarking-qa-0). Checked 2026-10-19. August 12, 2015 educational discussion of metric terminology, measurement vantage point, concurrency and client idle time. Used for interpretation, without reproducing benchmark results or prescribing queue settings.
- [U1 — NIST: Prefixes for binary multiples](https://physics.nist.gov/cuu/Units/binary.html). Checked 2026-10-19. Binary and decimal prefix definitions support the explicit byte conversions. The two operating points are original fictional arithmetic, not NIST performance measurements.
- [F1 — fio documentation: workload descriptions, timing and latency statistics](https://fio.readthedocs.io/en/latest/fio_doc.html). Checked 2026-10-19. The retrieved documentation identifies revision 3.42 and explains workload inputs and separate submission, completion and total latency statistics. Used to interpret supplied evidence, without benchmark commands, settings or a testing procedure.
- [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-19. Physical installation and connection-record scope, subject to approved endpoints, customer-supplied compatible materials and agreed project requirements.

## Related Leviathan resources

- [GPU storage network handoff: trace the physical connections](/articles/gpu-storage-network-physical-handoff)
- [DGX B200 storage: distinguish boot, cache and dataset-service roles](/articles/b200-deployment-guide)
- [Compare application-level GPU performance](/articles/which-gpu-is-fastest-workload-benchmarks)
- [Structured cabling and fiber installation](/services/structured-cabling)
- [Discuss a storage-facing cabling project](/contact?service=structured-cabling&from=%2Farticles%2Fgpu-storage-iops-throughput-latency-comparison)

## Selected storage equipment needs physical connections?

Share the equipment models, site, approved endpoints and customer-supplied assemblies so our team can discuss the cabling scope, requirements and availability.

[Discuss the scope](/contact?service=structured-cabling&from=/articles/gpu-storage-iops-throughput-latency-comparison)