Almost every enterprise I speak with has AI pilots. The harder part is turning those pilots into something that can run reliably in production.

That requires more than GPUs. You need an operating model that can keep data moving and accelerators fed, preserve context, and give teams a reliable way to manage distributed AI workloads.

The AI factory work we announced at Pure Accelerate builds on the data foundation we’ve been developing throughout the year. At NVIDIA GTC Berlin (October 20-22, 2026), we’re taking the next step: showing more of the architecture, the implementation behind it, and what we’ve learned building with Red Hat and NVIDIA.

4 things the data plane has to provide

1. Trusted data access

In many production environments, it can still be difficult to establish exactly what produced a model: which data set version, code commit, and evaluation evidence support what’s serving traffic. That requires governed access that respects existing permissions and durable lineage that persists independently of individual tracking tools. For organizations operating under sovereignty or privacy requirements, that governance also extends to derived data such as embeddings.

2. High-performance delivery

AI training creates very different I/O demands at different stages. Data loading drives highly parallel reads, while checkpointing creates large sequential write bursts. The data plane has to handle both without becoming the bottleneck.

Size the write path bandwidth for the checkpoint burst, not the average feed. And don’t rely on GPU utilization alone as a measure of efficiency: A busy GPU isn’t necessarily doing useful work. Goodput is the better measure of whether the system is actually moving training forward.

3. Efficient context handling

As agentic workloads scale, KV cache becomes an infrastructure problem. Long-context and multi-turn sessions can outgrow GPU memory, forcing systems to evict and recompute context that has already been processed.

Our AI token optimization reference architecture goes deeper into how fleet-wide caching and routing can extend that context beyond GPU memory and reduce unnecessary recompute.

4. Support for distributed AI workloads

Distributed AI workloads need both a shared namespace and portable state. Checkpoints have to be written consistently across ranks, and persistent data such as vector indexes, catalog metadata, and session state needs to move with the workload as placement decisions change based on cost, capacity, latency, or sovereignty requirements.

Building the data foundation for production AI

These requirements are shaping our work on the Everpure Data Architecture for Red Hat AI Factory with NVIDIA, spanning training, inference, and hybrid AI environments.

The goal is not to create a single architecture for a single workload. Production AI spans data preparation, training, inference, and increasingly hybrid environments where workloads and data need to move based on performance, cost, capacity, or sovereignty requirements.

Our work with Red Hat and NVIDIA is focused on bringing those layers together: in the Red Hat AI Factory with NVIDIA for the application and orchestration layer running on NVIDIA for accelerated computing, with Red Hat AI Enterprise and NVIDIA AI Enterprise providing the AI software stack, and Everpure for the data plane underneath it. With Everpure™ FlashBlade//S™ earning NVIDIA-Certified Storage certification for the NVIDIA Vera Rubin Platform, that foundation also extends to NVIDIA’s next-generation accelerated computing platform. The NVIDIA Vera Rubin Platform is a POD-scale platform designed for agentic AI, operating as one AI supercomputer to fuel token generation revenue.

We’re applying that work across the AI lifecycle, from governed data preparation through training, inference, and hybrid workload mobility.

Data preparation: Governed data for AI

Production AI starts before training or inference. Enterprise data has to be discovered, prepared, and delivered into AI pipelines while preserving the access controls already applied to it.

Our work with Everpure Data Stream and Red Hat AI is focused on enabling this data readiness layer, helping teams process and prepare unstructured data in place and deliver governed, AI-ready data for AI consumption. This collaboration with Red Hat is continuing to evolve.

From there, we extend the architecture into training, inference, and workload mobility.

Training: Building a repeatable AI factory pipeline

Enterprises moving fine-tuning into production hit four problems:

Utilization: GPUs stay allocated after runs finish and clusters idle between jobs.
Automation: Jobs are launched by hand, but new data has to wait on a person.
Durability: Rank-sharded checkpoints are on local disks, and incomplete ones are found only at restore time.
Governance: Models are promoted with no defensible record of the data, code, and evaluation behind them.

Our training architecture addresses all four. Red Hat AI runs on bare metal, Everpure FlashBlade//S serves both S3 and NFS, and Portworx® FlashBlade® Direct Access provides shared read-write-many volumes. A data set landing in an S3 inbox triggers a fine-tuning run, and Kueue admits it only when the full resource allocation is available. When training completes, the accelerators return to the shared pool. In a capstone run, we fine-tuned Qwen3-32B with DeepSpeed ZeRO-3—every rank wrote its checkpoint shard to the same shared namespace, producing a complete checkpoint that moved to S3 with the lineage and evaluation data needed for promotion.

The build also surfaced practical lessons. In one early run, rank 0 uploaded only the shards it could see locally: Nothing failed, but the checkpoint was incomplete. We also found that admission quotas must cover the full workload request—CPU and memory, not GPUs alone—or a job queues silently without running.

Those details matter when a pipeline has to run reliably in production, not just pass a test.

Inference: Making context part of the data path

Inference creates a different set of requirements.

As context windows grow and agentic applications become more stateful, KV cache can outgrow GPU memory. When that context is evicted and has to be recomputed, expensive accelerator cycles are spent repeating work that has already been done.

Our inference architecture extends the data plane into the serving path. Work underway with Distributed Inference with llm-d combines disaggregated prefill and decode, cache-aware routing, and FlashBlade as a persistent tier for KV cache that can no longer remain in GPU memory.

We’re incorporating this work into a broader inference reference architecture, with the integration on display at GTC Berlin. The full architecture will follow as the work is completed.

Hybrid AI: Keeping workloads and data portable

The same production requirements extend beyond a single environment.

We’re also expanding this work into a hybrid AI factory reference architecture spanning Red Hat AI, NVIDIA accelerated computing, Portworx, and Everpure data infrastructure across on-premises and cloud environments. The goal is to keep data and persistent state portable as workloads shift based on cost, capacity, latency, or sovereignty requirements, without forcing teams to rebuild the data environment around the workload every time it moves.

That work builds on the hybrid AI factory architecture we’ve already developed with Red Hat and NVIDIA and will continue to evolve as these production patterns mature.

These architectures represent one part of how Everpure is helping organizations prepare their data for AI. Everpure Data Stream and Everpure Data Intelligence address complementary needs as organizations move AI into production.

Independent proof at scale

Reference architectures show how the pieces fit together. Benchmarking gives us another way to test whether the underlying data platform can keep up with the workload.

That is where MLPerf Storage v3.0 is useful.

This year, MLCommons added to the MLPerf test suite both checkpointing and KV cache workloads designed around the storage patterns of large-scale AI training and inference. FlashBlade//EXA™ ranked first across every checkpointing and KV cache category we entered in the CLOSED division.

On the inference side, FlashBlade//EXA delivered 85,736 tokens per second for the Llama 3.1 8B storage-only workload and 33,403 tokens per second for the 70B storage-only workload. On the training side, FlashBlade//EXA also demonstrated near-linear scaling as the benchmark increased the number of simulated accelerators.

Together, those results provide independent evidence that the Everpure data plane can sustain the checkpointing and context-management patterns that increasingly define production AI.

The challenge now is extending those capabilities as systems scale and as concurrency, data movement, and context pressure become everyday operational concerns. That’s where we’ll take the conversation next at SC26.