Build1 distinct publisher3 min readPublished
The figure comes from a conference demo scanning a 4K video, and the same talk sets a target closer to 50 Gbit/s. The reason today's loaders still stage shards on disk turns out to be PyTorch's worker model.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The 13 Gbit/s comes out of the payload's own geometry. Three columns, roughly 8 million pixels a frame, 60 frames a second [2] is 1.44 billion values per second, which at 13 Gbit/s leaves about 9 bits for each value [1]. That is a 4K RGB video at 60fps carried at roughly a byte per channel. The scan moved what the video required.
The target rate stated in the same talk is higher: about 50 Gbit/s of compressed bytes, with the right codec making the pipeline effectively ten times faster than the compressed rate [12]. Take both numbers as given and the demo ran at a bit over a quarter of the target ingest rate [2], while the target implies something near 500 Gbit/s of logical bytes arriving at the model [3]. The second number is a compression ratio in bandwidth clothing, and it holds for exactly as long as your columns compress like the columns in the claim.
For the demo rate to transfer, a few things have to be true of your data. The samples have to be columnar with projections worth pruning, since the saving in the second clip comes from never reading the other columns [5]. The codec has to decode in parallel on the device [11]. And the GPU has to have capacity to spare, which is what this material says least about: the consumer in the demo was a visualisation, and the transcript does not describe a training step competing for the same device [15].
The best engineering in the talk is diagnostic. The NVMe hop in webdataset-style loaders [8] is not a storage preference. PyTorch is Python, Python discourages threads, so the loader runs multiple worker processes, and those processes avoid fetching the same shard twice by persisting it to disk [10]. The disk is the deduplication mechanism. Anyone removing the hop has to put that coordination somewhere else, and this transcript does not say where the Vortex scan puts it [16].
The talk is titled "From S3 to GPU in One Copy" [13]. The path it actually describes runs from S3, through the network card, over the CPU, and to the GPU [3]. Those two are compatible if the CPU only handles descriptors, but the excerpt neither counts copies nor names a DMA route, so on this evidence the single-copy figure belongs to the title rather than the transcript.
The wider claim, that loader design and not accelerator count sets training throughput, rests here on two named bottlenecks, CPU decompression and NVMe throughput [9], plus the argument that an idle GPU is pure opportunity cost [6]. Onur Satici of SpiralDB, who helps maintain Vortex under the Linux Foundation [1], calls this the movement tax, and names a second one, the decision tax of iterating on data mixes and curricula [7][14], which the excerpt breaks off before pricing. That is diagnosis rather than measurement. The useful step before either buying GPUs or re-encoding a dataset is finding out which of the two bottlenecks binds on your own loader.
Ranked by verification strength, evidence, and original report placement.
Onur Satici works at SpiralDB and helps maintain Vortex, an open-source columnar file format under the Linux Foundation.
The demo Vortex file has three columns, one per colour, with a row per video frame; each frame contains around 8 million pixels because the video is 4K, at 60 frames per second.
The demo processes that data at around 13 gigabits per second from S3, through the network card, over the CPU, and to the GPU.
Because that much data cannot be downlinked to a laptop, the GPU re-encodes the frames into H.264, wraps them into TCP buffers and sends them over an SSH tunnel for display.
A second clip visualises column or projection pruning: when only one column is named in the projection expression, only the bytes associated with that column flow through the same pipeline, keeping the same bandwidth.
Satici argues GPUs are expensive, and each time they idle it is expensive and an opportunity cost of not doing valuable work.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 4, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The streaming edit is a software layer: proxies, stubs and an ffmpeg hook on storage you own1 distinct publisher
build
Iceberg won the table format war, then left the maintenance layer to you1 distinct publisher
build
Six specifications decide whether an agent can move off the harness it was built on1 distinct publisher
product
Agent protocols now share one landlord: A2A joins MCP and AGENTS.md at the Linux Foundation1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One stage, one speaker, no second measurement
Every figure — 13 Gbit/s, 50 Gbit/s, the tenfold compression multiplier — comes from the person who maintains the format, on hardware he never names. What raises this above a slide deck is that the mechanism is specific enough to check dimensionally: 4K at 60fps across three channels is about 1.44 billion values a second, and 13 Gbit/s leaves roughly nine bits per value, which is a believable number for lightly compressed pixel data. The architecture claims hang together. Nobody outside the project has timed them.
A demo, not a user
Linux Foundation governance is a home, not a customer. This reporting names no team training on the path, no deployment, no install or download count — and the one workload it does show terminates in a video window rather than a training step. Scoring adoption from a stage demo would be inventing a user base the talk never claims.
Demo rate below the talk's own promise
Unusually, the headline number is the conservative one. 13 Gbit/s is what ran; the same talk gestures at 50 Gbit/s of compressed bytes with a tenfold effective multiplier, which is roughly 500 Gbit/s of logical data reaching a model — some forty times what was shown. The overstatement is therefore in the destination, not the demonstration, and two gaps keep it there: the shown pipeline ends in an H.264 re-encode for a laptop, and having identified disk staging as PyTorch's cross-worker deduplication mechanism, the talk removes the disk without saying what takes over that job.
The format's maintainer, on the format's behalf
Satici is paid by SpiralDB and maintains Vortex; the venue is a conference stage, where the currency is mindshare. He states the affiliation up front, which is the honest version of this posture — but the baseline chosen (webdataset, MosaicML streaming), the metrics chosen, and the framing of idle GPUs as a tax all point the same direction as the project being promoted, and InfoQ's transcript adds no counterweight.
Certain what was said, unsure what it holds up to
A full transcript is a good artefact: it makes both the claims and the silences legible, and we can see exactly where the argument stops. What we cannot do with a single vendor talk and no reproduction is confirm the throughput, validate the bottleneck diagnosis, or judge whether one-copy loading survives contact with a real training loop and a real worker pool.