A GPU that cannot be fed is capacity you already paid for and cannot spend.
On 29 September 2026, NetApp announced NetApp Novus at Insight: a disaggregated storage architecture aimed at AI factories and neoclouds, built to exceed 100 TB/s aggregate throughput under a single namespace. The press claim is blunt. Under traditional architectures, GPU utilization can drop below 30% when the factory cannot deliver data fast enough. Chief Product Officer Syam Nair put the economics in one line: AI factories struggle when data cannot keep up.
The mismatch is the point
Flash closed the storage gap for CPU-era apps. GPUs reopened it. In a CRN interview, NetApp’s chief platform and technology officer Arindam Banerjee sketched the scale: a single GPU on high-bandwidth memory can crunch on the order of 8 TB/s, while operators planning 50,000–100,000 GPU clusters talk about holding a constant ~2 GB/s per GPU — roughly 100 TB/s of namespace bandwidth. Miss that line rate and the most expensive asset in the hall sits waiting.
That is the same capacity argument as stranded watts are idle GPUs, moved from the power domain to the data path. Unused headroom under a megawatt budget strands silicon. A namespace that cannot keep up strands it too — with the lights still on and the watt-hours still billed.
What Novus claims to change
Novus’s architectural bet is disaggregation. Metadata services (Novus Data Director on qualified Supermicro infrastructure) sit apart from the ONTAP data plane on AFF A90 systems. Metadata is small, transactional I/O; data is large and sequential. Sharing the same hardware makes both hard to scale. Split them, and metadata, bandwidth, and capacity can grow independently under one namespace over industry-standard pNFS/NFS — without a proprietary client, per Banerjee’s framing in CRN and Blocks & Files.
| Layer | Role | Initial hardware |
|---|---|---|
| Novus Data Director | Metadata / namespace federation | Qualified Supermicro servers |
| ONTAP data services | Resilient data plane | AFF A90 |
| Client access | Parallel file I/O | Standards-based pNFS/NFS |
Omdia’s Tony Palmer, quoted in the Business Wire release, says modeling from audited scaling projects 100 TB/s sequential read with dozens of exabytes of effective capacity. That is vendor-cited analyst modeling, not an independent public benchmark suite — treat the ceiling as a design target until operators publish their own numbers.
Why this is a capacity story
Exact match leaves capacity idle reclaims flash that near-duplicates waste. DPU Arm alone cannot buy the link shrinks bytes only when the reduce path is cheaper than sending them raw. Storage feed rate is the third lever: how many useful GPU-seconds you extract from silicon already racked. Compression that cuts bytes moved, fabric maps that avoid hot links, and namespaces that can actually deliver the working set all buy the same thing — more work per watt and per dollar of accelerator.
None of this retires the need for more arrays when corpora explode. It changes whether the arrays you already bought are the reason GPUs sit at 5–30% busy. Operators still have to validate line rates on their mix — training ingest, checkpoint storms, and multi-tenant inference look different. The announcement’s useful claim is architectural: separate the metadata choke from the data firehose, keep a single namespace, and size bandwidth to the GPU fleet rather than hope HPC-era storage scales by accident.
The next AI factories will still buy GPUs. The open question is how many of those GPUs spend their lives waiting on a feed that never arrives.