Portworx Is the Kubernetes Data Layer for AI

AI is often discussed as a compute problem: finding enough GPUs for training, fine-tuning, or inference. But GPU availability is only part of the operational picture. Before a model can serve its first request, its data must be in the right place, on the right storage, and available under policies that provide the necessary protection for data, model artifacts, and all of the work product surrounding them:

• Before inference starts: pre-stage reusable model data locally so scale-out and recovery don’t depend on repeated remote downloads.
• When workloads are provisioned: select local NVMe, array, or cloud storage according to workload needs.
• When infrastructure needs change: move stateful Kubernetes applications and their data between cloud and on-premises clusters through a policy-driven migration workflow.
• At distributed edge sites: inference is moving closer to where data is created. Support local inference with resilient site storage, even when WAN connectivity is intermittent.

As we discussed in our webinar on data challenges for AI, Portworx addresses the data-management requirements arising across the entire AI lifecycle. The same Kubernetes platform may run data prep, feature engineering, training, inference, and RAG services. Each has different expectations for locality, durability, sharing, recovery, and mobility.

Warm the Nodes with Data Before You Start the Inference Engine

Starting an inference engine like vLLM is more than starting a container. The serving engine has to locate model artifacts, load checkpoint files, initialize its runtime, and transfer weights into GPU memory before it can accept traffic. For large models, the weights alone can be tens or hundreds of gigabytes.

When every new pod independently downloads those files from a remote repository, shared storage system, or object store, scale-out becomes dependent on network bandwidth, storage contention, and repeated data movement. That’s a storage-dependent part of inference cold- start that platform teams can address before a pod is scheduled.

Pre-staged volumes is a planned capability of Portworx (expected Q1 2027, scope and availability subject to change) that provides a Kubernetes-native pattern for doing exactly that. Instead of treating a model as a file set every pod must acquire independently, your pipeline hydrates one source volume; Portworx distributes equivalent node-local copies.

With pre-staged volumes, the inference engine startup process can avoid downloading multiple copies of weights from a remote repository:

• Hydrate one source PVC with a versioned model bundle from an approved repository.
• Distribute equivalent copies across the cluster’s eligible worker nodes.
• Confirm each required copy is ready.
• Schedule an inference pod to run only where its local copy is available.

This pattern also changes planning for recovery and upgrades. When a node fails, a replacement pod can be scheduled on a surviving node that already has a ready copy. And when a new model revision is introduced, teams can run a blue/green generation workflow: stage and validate the new model version, distribute it, shift consumers, then retire the previous generation after the rollback window.

Use Local NVMe and FlashArray Storage on the Same Node  

An enterprise may have GPU nodes with local disks for AI workloads, while those same nodes may also be connected to FlashArray.  Until now, local-disk and FlashArray Cloud Drive storage had to live on separate nodes, creating artificial partitions and potentially leaving compute or storage resources stranded.

Portworx Flexible Storage for AI Workloads (now available in Early Access) provides mixed-storage support that enables local-disk-backed pools and FlashArray Cloud Drive-backed pools to coexist on the same Kubernetes node.  Applications use configured StorageClasses to target the appropriate storage pools, allowing platform teams to support workloads with different storage requirements without separating them solely by backend type.

The result is a more practical operating model for heterogeneous infrastructure:

• Place performance-sensitive AI or GPU data on local NVMe where appropriate.
• Serve other stateful workloads from FlashArray-backed pools on the same node.
• Avoid separate infrastructure solely because workloads require different media.
• Evolve from local-only or FlashArray Cloud Drive-only environments toward mixed storage without redesigning every workload placement decision.

For platform teams, the value isn’t simply more storage choices. It’s a way to standardize heterogeneous infrastructure behind a Kubernetes-native operating model: define capacity declaratively, offer governed StorageClass choices, and evolve the mix of local and FlashArray-backed storage as application requirements change.

Hybrid Cloud Mobility for AI Workloads

A training sprint, fine-tuning run, or inference spike may require temporary GPU capacity that’s not available on premises. Later, cost, data gravity, governance, or steady-state operations may favor bringing the workload back.

Portworx supports a hybrid cloud operating model for AI with an application-aware Kubernetes migration workflow. A workload can run on a Portworx-enabled Kubernetes cluster in a public cloud and on a Portworx-enabled cluster on premises, with each site using storage native to that environment; Portworx provides the Kubernetes-native data layer and migration workflow that connects the two.

Portworx gives teams a repeatable way to move application state once teams decide where a workload should run.  That simplifies cloud bursting and repatriation for stateful Kubernetes applications.

Run AI at the Edge, Where Data Happens

A retail store, factory, hospital, or far-edge telecom site may need to analyze video, sensor data, images, or transactions near the point of creation, where round-trip latency, bandwidth constraints, data-sovereignty requirements, or intermittent connectivity make a cloud-only serving path impractical.

Portworx for Edge is designed for that operating environment: small Kubernetes clusters of up to five nodes, local storage, synchronous replication, local snapshots, and operation through WAN interruptions. Within the site, replicated local volumes keep stateful inference-adjacent services and application data available when a node fails.  That means an inference service will continue to serve the model already present at the site rather than depending on a live connection to a central repository or cloud service.

Portworx for Edge provides the persistent, resilient Kubernetes data layer that lets organizations operate inference at distributed sites with minimal on-site intervention.

Portworx Delivers Data Readiness for AI

Portworx gives platform teams a consistent Kubernetes data layer for operating AI across the lifecycle: stage approved model data on the nodes where inference will run, match each workload to the storage it needs, move application state between cloud and on-premises environments as infrastructure requirements change, and keep stateful services resilient at distributed edge sites. Rather than leaving data placement, recovery readiness, and workload mobility to one-off scripts or application teams, platform teams can apply repeatable, policy-driven workflows. 

The result? A data layer that enables AI platforms to operate stateful workloads reliably as models, locations, and business needs evolve.

What’s Next?

Portworx is a data platform for all your modern application workloads.  Join our upcoming hands-on lab, One Copy, Zero Compromise: Portworx KDS on OpenShift, to work directly with Portworx Kube Datastore (KDS) backed by Everpure FlashArray. You’ll provision and manage stateful workloads, see capacity scale dynamically as demand grows, and explore how to maintain resilience without host-side replicas – all practical foundations for running modern virtualized applications with enterprise performance and efficient data protection.