NVIDIA’s Vera BlueField-4 STX storage processor posted sizeable gains in storage-service microbenchmarks, with the company reporting up to 3.67× higher CRC32C throughput, 3.29× faster compression, 3.26× faster Reed-Solomon recovery and 3.21× more throughput in a compression-plus-encryption pipeline than an unnamed x86 system. The practical takeaway for storage architects is narrower, but significant: NVIDIA is trying to move the CPU work that sits between NVMe media and AI inference—integrity checks, erasure-code repair, compression, encryption and metadata-adjacent processing—into a dedicated Arm-based storage processor rather than allowing it to consume the host CPUs that run agent tools and orchestration.
The results, published August 3 by NVIDIA’s Technical Blog, are the first detailed performance figures attached to the Vera BlueField-4 STX concept that NVIDIA introduced with its 2026 Vera Rubin platform. They show why NVIDIA sees context storage and KV-cache handling as a compute problem rather than merely a flash-capacity problem. But they are not a system benchmark, and they do not establish a token-per-second gain for any deployed AI stack.
That distinction is the central point. These figures make a credible case that Vera has substantial CPU headroom for selected storage primitives. They do not yet prove that replacing conventional controllers or x86 storage nodes with STX will yield the same multipliers in a real Ceph, Lustre, object-storage, parallel-file-system, or enterprise NAS deployment.
NVIDIA tested encryption, decryption, Reed-Solomon recovery, CRC32C checksumming, compression, decompression, and a two-stage compression-then-encryption write pipeline. The company says the tests were run in one process with data already resident in memory, deliberately excluding file I/O, disks, networking, application startup and other external bottlenecks.
That makes the numbers useful for identifying a potential choke point, but it also sharply defines what they do not measure. An AI storage platform must still contend with NVMe queueing, PCIe topology, flash behavior under sustained writes, network congestion, storage software locks, metadata lookup latency, erasure-coding layouts, replica traffic and recovery contention. A processor that is three times faster at an in-memory checksum or compression task can still produce little user-visible improvement if the production path is constrained elsewhere.
NVIDIA explicitly says end-to-end testing remains necessary to quantify complete storage-system or GPU-performance outcomes. That caveat is not boilerplate. It means the advertised gains should be read as component-level throughput rather than a deployment sizing guide.
The company’s position is that those components are increasingly important because agentic AI performs repeated reads and writes around every model invocation. A request may involve retrieval, persistent memory, tool execution, intermediate artifacts and key-value cache reuse, all while multiple agents operate concurrently. Storage processing is therefore more than background housekeeping: encrypting, validating, compressing and reconstructing data can enter the latency-sensitive path that supplies data to CPUs and GPUs.
That is also why the ratios are more consequential for service density than for a single request. The first likely benefit of a faster storage-side processor is not that one small prompt returns instantly. It is that a storage node can keep applying enterprise data services under concurrency without turning encryption, compression or integrity validation into the point where a larger AI cluster waits.
The processor at issue here uses 88 NVIDIA-designed Olympus cores, supports 176 Spatial Multithreading threads, and is Armv9.2 compatible. NVIDIA attributes its storage results to the combination of those cores with a 164 MB unified L3 cache, the Scalable Coherency Fabric, and SOCAMM2 LPDDR5X memory. The company cites up to 3.4 TB/s of fabric bisection bandwidth and up to 1.2 TB/s of aggregate memory bandwidth.
Those specifications point to the actual architectural bet. Storage data services are often neither cleanly compute-bound nor cleanly I/O-bound. A CRC routine, a compression codec or an erasure-code recovery operation can be limited by instruction throughput, cache behavior, memory bandwidth, synchronization or some combination of all four. NVIDIA is putting a server-class Arm CPU directly into the storage data path, with high-bandwidth memory and coherent shared cache designed to keep many parallel streams moving.
The design also gives NVIDIA a more complete vertical stack. Vera CPUs run agent-side tools and orchestration in the larger Vera Rubin platform; BlueField-4 STX puts the same CPU architecture into the storage tier; ConnectX-9 and Spectrum-X connect the tiers; and DOCA supplies the programming and service framework. For buyers already committed to NVIDIA’s AI-factory architecture, this promises fewer host CPU cycles spent on data movement and storage services. For everyone else, it introduces another specialized processor and software layer to operate.
NVIDIA’s STX product page confirms that this is a modular foundation rather than a retail storage appliance. It lists partners including AIC, ASUS, Cloudian, DDN, Dell, HPE, IBM, NetApp, Nutanix, Supermicro, VAST Data and WEKA. Tom’s Hardware reported in March that partner STX-based platforms were expected in the second half of 2026. NVIDIA’s public page still presents STX as a platform that customers can register interest in, rather than detailing broadly available systems, configurations or pricing.
NVIDIA also reports up to 3.26× higher Reed-Solomon recovery throughput. Reed-Solomon coding is commonly used in erasure-coded storage systems to create redundancy and reconstruct data when fragments, drives or nodes are unavailable. The published chart shows Vera’s recovery result rising from roughly 1.5× the x86 result with one thread to 3.26× at eight threads, then falling to 2.72× at 16 threads. That is still a substantial reported advantage, but it is also a reminder that scaling is workload-specific rather than linear.
For compression, NVIDIA reports up to 3.29× higher throughput and says the lead held across measured thread counts. Decompression reached up to 1.72× higher throughput under concurrency. These are different operations with different operational consequences: write-side compression can lower capacity and network requirements, while decompression determines how quickly compacted data can be returned to an application.
AES-128 encryption and decryption produced more modest gains: up to 1.43× for encryption and 1.29× for decryption. Those numbers may be the more realistic indicator for deployments where hardware-accelerated AES is already effective on current x86 servers. They also make the 3×-class checksum and compression results less likely to be interpreted as a blanket Arm-versus-x86 claim. The gains depend on the primitive, its native instructions, the implementation and the thread count.
The 3.21× pipeline result is more useful than any single primitive, but it still represents only a two-stage memory-resident path: compression followed by encryption. A real storage write can additionally include checksumming, deduplication, replication or erasure encoding, metadata updates, journaling, transport and persistence to media. NVIDIA has demonstrated that its advantage survives one sequential combination of CPU-heavy work. It has not published a result for the wider production sequence.
But the published article refers only to “the x86 CPU.” It does not identify the rival processor model in the body of the post, nor does it provide a like-for-like system bill of materials in the results themselves. There is no published total-node result, no stated SSD count, no network configuration, no storage software stack and no application-level measurement in the article.
Those omissions prevent administrators from answering basic procurement questions: Is the comparison against a contemporary high-core-count server CPU or an older, lower-power part? Were the platforms configured for equivalent power, memory capacity and core counts? How do the results change when encryption is handled by a hardware accelerator, or when the storage software has its own SIMD, threading and checksum optimizations?
NVIDIA does make one important methodological choice explicit: Arm and x86 were allowed to use comparable implementations optimized for their native instructions. That is appropriate for showing attainable performance on each architecture. It also means the figures should not be used to infer that a generic, unchanged x86 software deployment will behave identically after being ported to Vera. The software path is part of the result.
No independent outlet has yet reported a reproduction of these exact tests or published an STX appliance benchmark using a production storage stack. The independent reporting so far has centered on the architecture’s goal—serving KV cache and long-context inference without routing all traffic through host CPUs—rather than validating NVIDIA’s newly published primitive-level ratios.
The immediate action is therefore diligence, not migration. Organizations evaluating NVIDIA-centered AI storage should ask vendors for end-to-end measurements using their intended storage stack and data layout, with encryption, data protection, compression, network transport and flash included. They should also require latency percentiles under concurrent inference traffic, rebuild behavior during a simulated drive or node failure, CPU utilization on both hosts and storage processors, and a clear account of how DOCA components fit into support and incident-response procedures.
NVIDIA has shown that Vera can accelerate several building blocks that storage systems execute constantly. The missing proof is whether those gains survive the queues, failures, metadata paths and software layers that define real storage. Until STX partners publish that evidence, the benchmark should be treated as a strong architectural signal—and not as a 3× performance promise for an AI storage deployment.
That distinction is the central point. These figures make a credible case that Vera has substantial CPU headroom for selected storage primitives. They do not yet prove that replacing conventional controllers or x86 storage nodes with STX will yield the same multipliers in a real Ceph, Lustre, object-storage, parallel-file-system, or enterprise NAS deployment.
The benchmark is about CPU work, not SSD speed
NVIDIA tested encryption, decryption, Reed-Solomon recovery, CRC32C checksumming, compression, decompression, and a two-stage compression-then-encryption write pipeline. The company says the tests were run in one process with data already resident in memory, deliberately excluding file I/O, disks, networking, application startup and other external bottlenecks.That makes the numbers useful for identifying a potential choke point, but it also sharply defines what they do not measure. An AI storage platform must still contend with NVMe queueing, PCIe topology, flash behavior under sustained writes, network congestion, storage software locks, metadata lookup latency, erasure-coding layouts, replica traffic and recovery contention. A processor that is three times faster at an in-memory checksum or compression task can still produce little user-visible improvement if the production path is constrained elsewhere.
NVIDIA explicitly says end-to-end testing remains necessary to quantify complete storage-system or GPU-performance outcomes. That caveat is not boilerplate. It means the advertised gains should be read as component-level throughput rather than a deployment sizing guide.
The company’s position is that those components are increasingly important because agentic AI performs repeated reads and writes around every model invocation. A request may involve retrieval, persistent memory, tool execution, intermediate artifacts and key-value cache reuse, all while multiple agents operate concurrently. Storage processing is therefore more than background housekeeping: encrypting, validating, compressing and reconstructing data can enter the latency-sensitive path that supplies data to CPUs and GPUs.
That is also why the ratios are more consequential for service density than for a single request. The first likely benefit of a faster storage-side processor is not that one small prompt returns instantly. It is that a storage node can keep applying enterprise data services under concurrency without turning encryption, compression or integrity validation into the point where a larger AI cluster waits.
Vera BlueField-4 STX is not the ordinary BlueField-4 DPU
NVIDIA’s naming makes this easy to misread. The conventional BlueField-4 DPU described in NVIDIA’s wider networking material uses a 64-core Grace CPU and is positioned for networking, infrastructure offload, security and host-resource isolation. Vera BlueField-4 STX is a separate storage-oriented processor configuration that combines the Vera CPU with ConnectX-9 networking, NVMe access, in-silicon security and NVIDIA’s DOCA software stack.The processor at issue here uses 88 NVIDIA-designed Olympus cores, supports 176 Spatial Multithreading threads, and is Armv9.2 compatible. NVIDIA attributes its storage results to the combination of those cores with a 164 MB unified L3 cache, the Scalable Coherency Fabric, and SOCAMM2 LPDDR5X memory. The company cites up to 3.4 TB/s of fabric bisection bandwidth and up to 1.2 TB/s of aggregate memory bandwidth.
Those specifications point to the actual architectural bet. Storage data services are often neither cleanly compute-bound nor cleanly I/O-bound. A CRC routine, a compression codec or an erasure-code recovery operation can be limited by instruction throughput, cache behavior, memory bandwidth, synchronization or some combination of all four. NVIDIA is putting a server-class Arm CPU directly into the storage data path, with high-bandwidth memory and coherent shared cache designed to keep many parallel streams moving.
The design also gives NVIDIA a more complete vertical stack. Vera CPUs run agent-side tools and orchestration in the larger Vera Rubin platform; BlueField-4 STX puts the same CPU architecture into the storage tier; ConnectX-9 and Spectrum-X connect the tiers; and DOCA supplies the programming and service framework. For buyers already committed to NVIDIA’s AI-factory architecture, this promises fewer host CPU cycles spent on data movement and storage services. For everyone else, it introduces another specialized processor and software layer to operate.
NVIDIA’s STX product page confirms that this is a modular foundation rather than a retail storage appliance. It lists partners including AIC, ASUS, Cloudian, DDN, Dell, HPE, IBM, NetApp, Nutanix, Supermicro, VAST Data and WEKA. Tom’s Hardware reported in March that partner STX-based platforms were expected in the second half of 2026. NVIDIA’s public page still presents STX as a platform that customers can register interest in, rather than detailing broadly available systems, configurations or pricing.
The biggest results are in checksums, recovery and compression
The top-line result—3.67× greater CRC32C throughput at 16 threads—deserves more attention than the smaller AES figures. CRC32C is not a security control; it is a fast integrity check used to detect accidental corruption. Storage systems may calculate it repeatedly on write paths, read paths and buffer copies. When it becomes an appreciable CPU cost, a faster implementation can remove a surprisingly mundane but persistent source of overhead.NVIDIA also reports up to 3.26× higher Reed-Solomon recovery throughput. Reed-Solomon coding is commonly used in erasure-coded storage systems to create redundancy and reconstruct data when fragments, drives or nodes are unavailable. The published chart shows Vera’s recovery result rising from roughly 1.5× the x86 result with one thread to 3.26× at eight threads, then falling to 2.72× at 16 threads. That is still a substantial reported advantage, but it is also a reminder that scaling is workload-specific rather than linear.
For compression, NVIDIA reports up to 3.29× higher throughput and says the lead held across measured thread counts. Decompression reached up to 1.72× higher throughput under concurrency. These are different operations with different operational consequences: write-side compression can lower capacity and network requirements, while decompression determines how quickly compacted data can be returned to an application.
AES-128 encryption and decryption produced more modest gains: up to 1.43× for encryption and 1.29× for decryption. Those numbers may be the more realistic indicator for deployments where hardware-accelerated AES is already effective on current x86 servers. They also make the 3×-class checksum and compression results less likely to be interpreted as a blanket Arm-versus-x86 claim. The gains depend on the primitive, its native instructions, the implementation and the thread count.
The 3.21× pipeline result is more useful than any single primitive, but it still represents only a two-stage memory-resident path: compression followed by encryption. A real storage write can additionally include checksumming, deduplication, replication or erasure encoding, metadata updates, journaling, transport and persistence to media. NVIDIA has demonstrated that its advantage survives one sequential combination of CPU-heavy work. It has not published a result for the wider production sequence.
The comparison leaves out the information buyers need
NVIDIA says its test framework controlled buffer sizes, thread counts, CPU placement, timing, validation and result collection, and that source code, scripts, fixed versions, configurations and results can reproduce the work. It also names OpenSSL, Zstandard and LZ4 among the common libraries involved, using implementations optimized for the native Arm and x86 instructions available to each processor.But the published article refers only to “the x86 CPU.” It does not identify the rival processor model in the body of the post, nor does it provide a like-for-like system bill of materials in the results themselves. There is no published total-node result, no stated SSD count, no network configuration, no storage software stack and no application-level measurement in the article.
Those omissions prevent administrators from answering basic procurement questions: Is the comparison against a contemporary high-core-count server CPU or an older, lower-power part? Were the platforms configured for equivalent power, memory capacity and core counts? How do the results change when encryption is handled by a hardware accelerator, or when the storage software has its own SIMD, threading and checksum optimizations?
NVIDIA does make one important methodological choice explicit: Arm and x86 were allowed to use comparable implementations optimized for their native instructions. That is appropriate for showing attainable performance on each architecture. It also means the figures should not be used to infer that a generic, unchanged x86 software deployment will behave identically after being ported to Vera. The software path is part of the result.
No independent outlet has yet reported a reproduction of these exact tests or published an STX appliance benchmark using a production storage stack. The independent reporting so far has centered on the architecture’s goal—serving KV cache and long-context inference without routing all traffic through host CPUs—rather than validating NVIDIA’s newly published primitive-level ratios.
What Windows and infrastructure teams should watch next
This is enterprise AI infrastructure news, not a Windows Server feature announcement. Windows administrators are more likely to encounter it through vendor-built STX systems, GPU clusters, AI data platforms or object and file storage products than through a driver package they install on an existing server.The immediate action is therefore diligence, not migration. Organizations evaluating NVIDIA-centered AI storage should ask vendors for end-to-end measurements using their intended storage stack and data layout, with encryption, data protection, compression, network transport and flash included. They should also require latency percentiles under concurrent inference traffic, rebuild behavior during a simulated drive or node failure, CPU utilization on both hosts and storage processors, and a clear account of how DOCA components fit into support and incident-response procedures.
NVIDIA has shown that Vera can accelerate several building blocks that storage systems execute constantly. The missing proof is whether those gains survive the queues, failures, metadata paths and software layers that define real storage. Until STX partners publish that evidence, the benchmark should be treated as a strong architectural signal—and not as a 3× performance promise for an AI storage deployment.
References
- Primary source: NVIDIA Developer
Published: 2026-08-03T16:00:00+00:00
Loading…
developer.nvidia.com - Related coverage: developer.nvidia.com
Loading…
developer.nvidia.com - Related coverage: nvidia.com
Loading…
www.nvidia.com - Related coverage: nvidianews.nvidia.com
Loading…
nvidianews.nvidia.com - Related coverage: nvidia.com
NVIDIA Vera CPU
Revolutionizes the modern data center with an advanced architecture and over 2x the performance of the prior-generation processor.www.nvidia.com - Related coverage: nvidianews.nvidia.com
Loading…
nvidianews.nvidia.com - Related coverage: tomshardware.com
Nvidia launches BlueField-4 STX storage architecture for agentic AI at GTC 2026 | Tom's Hardware
Eight cloud providers have committed to early adoption.www.tomshardware.com - Related coverage: pradeepstechpoints.wordpress.com
Loading…
pradeepstechpoints.wordpress.com - Related coverage: gadgetsnow.indiatimes.com
Loading…
gadgetsnow.indiatimes.com