NVIDIA’s storage announcement at the Future of Memory and Storage conference puts a sharper point on a problem AI infrastructure teams already see in production: GPUs are becoming fast enough that getting data into and out of them, safely and predictably, is the limiting factor. The company says it is open-sourcing the cuFile APIs and the underlying vertical storage software stack used by GPUDirect Storage, while expanding its Storage-Next initiative and SCADA data-access framework for GPU-driven storage.
The immediate operational takeaway is more restrained than NVIDIA’s announcement suggests. There is no evidence yet of a generally available open-source cuFile release, public repository, license, supported-kernel matrix, or migration path for existing GPUDirect Storage deployments. NVIDIA has announced an important direction, but storage architects should treat it as a roadmap event until the code and compatibility details arrive.
NVIDIA’s own existing GPUDirect Storage documentation still describes the user-level
That gap is the story hidden beneath the FMS launch language. Open APIs are useful; an open implementation is more consequential. Enterprise buyers will need to see which one NVIDIA has actually delivered before they can judge whether cuFile becomes a broadly portable storage interface or remains a CUDA-adjacent acceleration layer controlled primarily by NVIDIA’s platform releases.
The technical premise behind the announcement is credible. Traditional storage I/O usually flows through the host CPU and system memory before data reaches a GPU. GPUDirect Storage is designed to reduce copies and CPU involvement by enabling more direct transfers between supported storage devices and GPU memory buffers.
That approach becomes more relevant with agentic inference, retrieval pipelines, model checkpointing, vector and document ingestion, and long-context workloads. Those jobs repeatedly pull data that is too large or too expensive to retain entirely in GPU high-bandwidth memory. NVIDIA’s SCADA, short for scaled, accelerated data access, is its proposed way to let many GPU threads request selected data from storage rather than having a CPU marshal every request.
NVIDIA is framing this as a new memory tier, rather than a conventional SSD performance upgrade. The company’s Vera Rubin architecture includes CMX Context Memory Storage, a tier intended to hold and reuse inference context such as KV cache data outside the most expensive GPU memory. NVIDIA’s earlier technical materials positioned BlueField-4 STX as the rack-scale storage and data-services component of that design.
The important distinction is that flash storage does not become DRAM simply because a GPU can address it more directly. Even a fast PCIe Gen6 NVMe SSD remains orders of magnitude slower than HBM for latency-sensitive reads. The value of this architecture is selective retrieval and caching: keep the working set in HBM where possible, place less immediately active context on fast flash, and avoid consuming host CPU cycles just to move bytes between tiers.
For AI operators, that can improve GPU utilization when a workload is currently waiting on a CPU-bound data path. It does not eliminate the need to measure queue depth, access locality, tail latency, file-system behavior, SSD endurance, PCIe topology, and the cost of cache misses. A long-context inference service that continually fetches small, random blocks will behave very differently from a checkpointing pipeline that streams large sequential writes.
There is independent evidence that the initiative is moving beyond slides. Micron described SCADA in March as the software cornerstone of Storage-Next and demonstrated it with a Micron 9650 PCIe Gen6 SSD, Broadcom PEX90000 switching and an H3 Platform PCIe Gen6 server. Wiwynn also showed a SCADA server at Computex, according to Tom’s Hardware, demonstrating that vendors are beginning to build physical systems around NVIDIA’s model.
But those demonstrations underscore the practical constraint: this is an emerging high-end server architecture, not a generic feature that can be switched on in a typical storage array. The demonstrated stack relies on PCIe Gen6-era servers, high-performance enterprise flash, compatible switches, tuned software, and an NVIDIA GPU platform. It will take time for an interoperable design to become broadly deployable in enterprise clusters.
NVIDIA also has not attached a product availability date, reference hardware bill of materials, supported file-system list, or performance guarantee to the Storage-Next announcement. Nor has it said whether existing BlueField, GPUDirect Storage or AI Enterprise customers can adopt the new stack through a software update, or whether they will need BlueField-4 STX and Vera Rubin-era systems.
That omission matters more than the size of the partner list. Storage standards become meaningful when a buyer can mix components, retain supportability, and get repeatable behavior under load. Until vendors publish those boundaries, Storage-Next is a coordinated engineering program, not a procurement specification.
The company has separately said that Vera contains 88 Olympus CPU cores and can provide up to 1.2 TB/s of memory bandwidth. Those are meaningful specifications for data-intensive CPU work. A storage platform that must encrypt and compress data at high request rates can otherwise shift the bottleneck from the GPU to host-side services.
Still, the 3.21x result is a vendor benchmark, not a universal storage result. NVIDIA’s announcement does not identify the x86 processor used for comparison, the encryption algorithm, compression ratio, data type, core count, memory configuration, power envelope, or whether the test represents local NVMe, networked storage, or a synthetic pipeline. Those details will determine whether the result translates to an organization’s workloads.
IT teams should read that number as evidence of where NVIDIA expects CPU work to land in an AI factory: heavily parallel, bandwidth-hungry and security-aware. They should not use it as a basis for a platform-refresh business case without an independently reproducible benchmark using their own encryption settings, storage stack and datasets.
SCADA’s stated model separates high-speed user-space work from a privileged component that establishes the approved relationship between an application and its storage resources. NVIDIA says that control plane follows standard Linux security protocols while keeping the performance-critical data path out of the trusted computing base where possible.
That design resembles the broader least privilege principle that storage and virtualization teams already use: applications should receive access to the data and devices they are authorized to use, while a privileged layer configures and enforces the boundaries. The claim is promising, but the public announcement supplies no detailed threat model, code, audit record, key-management description, multi-tenant isolation guarantees, or guidance for incident response when a GPU-initiated request is denied or misbehaves.
NVIDIA links this work conceptually to the Open Secure AI Alliance, launched in late July. That association needs some care. The alliance is a broader AI security coalition; CrowdStrike and Red Hat have independently confirmed their participation. Yet reports on the alliance from TechRadar, Tom’s Hardware and others say Google and Meta are not listed among its inaugural members, despite NVIDIA’s FMS post naming Google, Intel, NVIDIA and Meta as inaugural maintainers of a site for open contributions.
The most likely explanation is that NVIDIA is referring to a separate open-source governance effort or contribution site, rather than the Open Secure AI Alliance itself. NVIDIA’s announcement does not clearly distinguish the two. For enterprises assessing governance, that ambiguity is not trivial: maintainers, alliance members, code owners and supported vendors are different roles, and each carries a different accountability model.
That does not make the announcement irrelevant to Windows-heavy organizations. AI training and inference clusters often run Linux even where identity, endpoint management, file services, development tooling and business applications remain on Windows. The effect may be indirect: Windows infrastructure teams could see larger Linux GPU clusters consuming shared network, flash, backup, key-management and observability capacity.
But there is no basis to assume that a Windows Server deployment can adopt these APIs, gain GPU-to-storage acceleration, or use NVIDIA’s claimed Linux security model. Any organization planning mixed Windows and Linux AI infrastructure should demand explicit support statements for SMB, NFS, object storage, NVMe over Fabrics, Active Directory integration, Kubernetes distributions, hypervisors, backup tooling and telemetry before treating Storage-Next as a cross-platform storage strategy.
NVIDIA has correctly identified that AI’s next capacity problem is no longer confined to GPU compute or HBM supply. The company is trying to turn storage from a passive persistence layer into an active, accelerated and policy-controlled part of inference. The open-source announcement could make that direction more credible—but only when NVIDIA publishes the code, the license, supported configurations and a clear line between what developers can inspect, what vendors can modify, and what customers can deploy today.
NVIDIA’s own existing GPUDirect Storage documentation still describes the user-level
libcufile.so implementation as closed-source software. Its published documentation has long discussed a future in which operating-system support could be upstreamed into open-source Linux, but that is materially different from releasing NVIDIA’s present cuFile implementation and the supporting storage stack. At publication time, NVIDIA’s public GitHub organization does not show a cuFile project matching the newly announced scope.That gap is the story hidden beneath the FMS launch language. Open APIs are useful; an open implementation is more consequential. Enterprise buyers will need to see which one NVIDIA has actually delivered before they can judge whether cuFile becomes a broadly portable storage interface or remains a CUDA-adjacent acceleration layer controlled primarily by NVIDIA’s platform releases.
GPU-Initiated Storage Changes the Bottleneck
The technical premise behind the announcement is credible. Traditional storage I/O usually flows through the host CPU and system memory before data reaches a GPU. GPUDirect Storage is designed to reduce copies and CPU involvement by enabling more direct transfers between supported storage devices and GPU memory buffers.That approach becomes more relevant with agentic inference, retrieval pipelines, model checkpointing, vector and document ingestion, and long-context workloads. Those jobs repeatedly pull data that is too large or too expensive to retain entirely in GPU high-bandwidth memory. NVIDIA’s SCADA, short for scaled, accelerated data access, is its proposed way to let many GPU threads request selected data from storage rather than having a CPU marshal every request.
NVIDIA is framing this as a new memory tier, rather than a conventional SSD performance upgrade. The company’s Vera Rubin architecture includes CMX Context Memory Storage, a tier intended to hold and reuse inference context such as KV cache data outside the most expensive GPU memory. NVIDIA’s earlier technical materials positioned BlueField-4 STX as the rack-scale storage and data-services component of that design.
The important distinction is that flash storage does not become DRAM simply because a GPU can address it more directly. Even a fast PCIe Gen6 NVMe SSD remains orders of magnitude slower than HBM for latency-sensitive reads. The value of this architecture is selective retrieval and caching: keep the working set in HBM where possible, place less immediately active context on fast flash, and avoid consuming host CPU cycles just to move bytes between tiers.
For AI operators, that can improve GPU utilization when a workload is currently waiting on a CPU-bound data path. It does not eliminate the need to measure queue depth, access locality, tail latency, file-system behavior, SSD endurance, PCIe topology, and the cost of cache misses. A long-context inference service that continually fetches small, random blocks will behave very differently from a checkpointing pipeline that streams large sequential writes.
Storage-Next Has Partners, but Few Shipping Commitments
NVIDIA says Storage-Next now brings together more than 40 storage and flash vendors, controller suppliers, cooling and orchestration companies, and standards bodies. DDN, KIOXIA and Micron are among the named participants. The initiative is intended to coordinate hardware, software and security behavior around GPU-initiated data access, then turn those choices into interoperable industry standards.There is independent evidence that the initiative is moving beyond slides. Micron described SCADA in March as the software cornerstone of Storage-Next and demonstrated it with a Micron 9650 PCIe Gen6 SSD, Broadcom PEX90000 switching and an H3 Platform PCIe Gen6 server. Wiwynn also showed a SCADA server at Computex, according to Tom’s Hardware, demonstrating that vendors are beginning to build physical systems around NVIDIA’s model.
But those demonstrations underscore the practical constraint: this is an emerging high-end server architecture, not a generic feature that can be switched on in a typical storage array. The demonstrated stack relies on PCIe Gen6-era servers, high-performance enterprise flash, compatible switches, tuned software, and an NVIDIA GPU platform. It will take time for an interoperable design to become broadly deployable in enterprise clusters.
NVIDIA also has not attached a product availability date, reference hardware bill of materials, supported file-system list, or performance guarantee to the Storage-Next announcement. Nor has it said whether existing BlueField, GPUDirect Storage or AI Enterprise customers can adopt the new stack through a software update, or whether they will need BlueField-4 STX and Vera Rubin-era systems.
That omission matters more than the size of the partner list. Storage standards become meaningful when a buyer can mix components, retain supportability, and get repeatable behavior under load. Until vendors publish those boundaries, Storage-Next is a coordinated engineering program, not a procurement specification.
The Vera Benchmark Needs Its Fine Print
NVIDIA also cited a technical benchmark in which the Vera CPU delivered up to 3.21 times higher throughput than an x86 CPU in a two-stage compression and encryption pipeline. The claim tracks with NVIDIA’s broader position that Vera’s Arm-based CPU architecture, LPDDR5X bandwidth and high core count are built for the service-side work that accompanies AI: compression, encryption, verification, orchestration and data transformation.The company has separately said that Vera contains 88 Olympus CPU cores and can provide up to 1.2 TB/s of memory bandwidth. Those are meaningful specifications for data-intensive CPU work. A storage platform that must encrypt and compress data at high request rates can otherwise shift the bottleneck from the GPU to host-side services.
Still, the 3.21x result is a vendor benchmark, not a universal storage result. NVIDIA’s announcement does not identify the x86 processor used for comparison, the encryption algorithm, compression ratio, data type, core count, memory configuration, power envelope, or whether the test represents local NVMe, networked storage, or a synthetic pipeline. Those details will determine whether the result translates to an organization’s workloads.
IT teams should read that number as evidence of where NVIDIA expects CPU work to land in an AI factory: heavily parallel, bandwidth-hungry and security-aware. They should not use it as a basis for a platform-refresh business case without an independently reproducible benchmark using their own encryption settings, storage stack and datasets.
Security Is the Necessary Part of Direct Access
NVIDIA’s most useful technical point is also the least glamorous one. Direct GPU access to storage cannot mean giving unprivileged application code unrestricted access to devices or memory mappings. A fast path that sidesteps Linux security controls would replace an I/O bottleneck with a serious isolation problem.SCADA’s stated model separates high-speed user-space work from a privileged component that establishes the approved relationship between an application and its storage resources. NVIDIA says that control plane follows standard Linux security protocols while keeping the performance-critical data path out of the trusted computing base where possible.
That design resembles the broader least privilege principle that storage and virtualization teams already use: applications should receive access to the data and devices they are authorized to use, while a privileged layer configures and enforces the boundaries. The claim is promising, but the public announcement supplies no detailed threat model, code, audit record, key-management description, multi-tenant isolation guarantees, or guidance for incident response when a GPU-initiated request is denied or misbehaves.
NVIDIA links this work conceptually to the Open Secure AI Alliance, launched in late July. That association needs some care. The alliance is a broader AI security coalition; CrowdStrike and Red Hat have independently confirmed their participation. Yet reports on the alliance from TechRadar, Tom’s Hardware and others say Google and Meta are not listed among its inaugural members, despite NVIDIA’s FMS post naming Google, Intel, NVIDIA and Meta as inaugural maintainers of a site for open contributions.
The most likely explanation is that NVIDIA is referring to a separate open-source governance effort or contribution site, rather than the Open Secure AI Alliance itself. NVIDIA’s announcement does not clearly distinguish the two. For enterprises assessing governance, that ambiguity is not trivial: maintainers, alliance members, code owners and supported vendors are different roles, and each carries a different accountability model.
Linux First Means Windows Is Outside the Announced Path
Windows administrators should notice the language NVIDIA chose. The security architecture is explicitly described as adhering to standard Linux protocols, and GPUDirect Storage has historically been documented around Linux environments and Linux-oriented storage-driver integration. NVIDIA did not announce Windows support for the newly open-sourced cuFile stack, SCADA, or Storage-Next.That does not make the announcement irrelevant to Windows-heavy organizations. AI training and inference clusters often run Linux even where identity, endpoint management, file services, development tooling and business applications remain on Windows. The effect may be indirect: Windows infrastructure teams could see larger Linux GPU clusters consuming shared network, flash, backup, key-management and observability capacity.
But there is no basis to assume that a Windows Server deployment can adopt these APIs, gain GPU-to-storage acceleration, or use NVIDIA’s claimed Linux security model. Any organization planning mixed Windows and Linux AI infrastructure should demand explicit support statements for SMB, NFS, object storage, NVMe over Fabrics, Active Directory integration, Kubernetes distributions, hypervisors, backup tooling and telemetry before treating Storage-Next as a cross-platform storage strategy.
NVIDIA has correctly identified that AI’s next capacity problem is no longer confined to GPU compute or HBM supply. The company is trying to turn storage from a passive persistence layer into an active, accelerated and policy-controlled part of inference. The open-source announcement could make that direction more credible—but only when NVIDIA publishes the code, the license, supported configurations and a clear line between what developers can inspect, what vendors can modify, and what customers can deploy today.
References
- Primary source: NVIDIA Blog
Published: 2026-08-04T15:00:47+00:00
As AI Increases Demands on Memory, Storage Steps Up | NVIDIA Blog
At FMS, NVIDIA shows how accelerated computing enables AI applications to access storage directly — fast enough to act like memory and secure by design.blogs.nvidia.com - Related coverage: micron.com
From breakthrough to deployment path: SCADA at NVIDIA GTC 2026 | Micron Technology Inc.
Discover Micron SSD innovations and performance breakthroughs. From breakthrough demo to deployment path scada on production grade pcie gen6 hardware at NVIDIA GTC 2026.www.micron.com - Related coverage: tomshardware.com
- Related coverage: jp.micron.com
- Related coverage: tomshardware.com
'PCIe Gen7 development has already started,' says Silicon Motion's Alex Chou — Nvidia's Storage Next initiative is becoming a focal point | Tom's Hardware
SMI has big plans for data centers.www.tomshardware.com - Related coverage: docs.nvidia.com
- Related coverage: docs.nvidia.com
1. Overview Guide — GPUDirect Storage Overview Guide
docs.nvidia.com
- Related coverage: sciencedirect.com
