MLPerf Storage now measures KV cache and vector database performance for the first time

MLCommons published the MLPerf Storage v3.0 results on 1 September 2026. The round added two tests that did not exist in the benchmark before, both aimed at the storage sitting underneath model serving rather than model training. Nineteen organizations submitted.

The two new tests

The first is a KV cache test. MLCommons describes it as measuring "storage performance for LLM inference cache read/write operations", and explains the reason plainly: KV caching is a widely used technique for speeding up transformer inference, particularly autoregressive models such as LLMs. Until this round there was no shared way to compare how storage handled that traffic.

The second is a vector database test, which MLCommons says "measures storage performance for vector indexing and querying workloads". That covers the storage side of a retrieval setup, which is the part teams usually size by guessing.

The round also reports on the S3 object storage access layer added to the suite. Approximately one sixth of the submissions in this round used it.

The spread is the finding

The published power efficiency figures are wide enough to be the story on their own. MLCommons reports that on-premises submissions for the checkpointing write test reached a median of 14 GB per second per watt, with a maximum of 201. For the UNet3D read test, submissions reached a median of 34 GB per second per watt with a maximum of 277.

A maximum roughly fourteen times the median on one test, and eight times on the other, is a very large range for systems all running the same defined workload. MLCommons says as much in its own words: there is a wide range of power efficiencies in the results, and ample room for further improvement. That is the organization running the benchmark describing its own round, and it is a more useful sentence than any single winning number.

Of the nineteen submitters, eleven were submitting for the first time, among them Azure, NVIDIA, Nebius, XSKY and OpenLake.

The practical value here is a comparison point that nobody selling storage controls. Teams putting a model into production usually reach the storage question late, after the GPU decision is made, and at that point the only available numbers are the ones vendors publish about themselves. A KV cache figure measured under a defined workload, submitted by nineteen parties and published in one place, is a different kind of input: it can be checked, and results from different vendors can be set beside each other without translating between two marketing pages. The measured spread also suggests the choice is worth making deliberately, because on these numbers picking badly costs far more than a few percent.

Both new tests are one round old, so the field is thin and the results should be read as a starting baseline rather than a settled ranking.

Source

MLPerf Storage v3.0 results, MLCommons, 1 September 2026. Surfaced through OpenLake's account of its own submission.