Presented by F5
As enterprises pour billions into GPU infrastructure for AI workloads, many are discovering that their expensive compute resources sit idle far more than expected. The culprit isn’t the hardware. It’s the often-invisible data delivery layer between storage and compute that’s starving GPUs of the information they need.
“While people are focusing their attention, justifiably so, on GPUs, because they’re very significant investments, those are rarely the limiting factor,” says Mark Menger, solutions architect at F5. “They’re capable of more work. They’re waiting on data.”
AI performance increasingly depends on an independent, programmable control point between AI frameworks and object storage — one that most enterprises haven’t deliberately architected. As AI workloads scale, bottlenecks and instability happens when AI frameworks are tightly coupled to specific storage endpoints during scaling events, failures, and cloud transitions.
“Traditional storage access patterns were not designed for highly parallel, bursty, multi-consumer AI workloads,” says Maggie Stringfellow, VP, product management – BIG-IP. “Efficient AI data movement requires a distinct data delivery layer designed to abstract, optimize, and secure data flows independently of storage systems, because GPU economics make inefficiency immediately visible and expensive.”
Why AI workloads overwhelm object storage
These bidirectional patterns include massive ingestion from continuous data capture, simulation output, and model checkpoints. Combined with read-intensive training and inference workloads, they stress the tightly coupled infrastructure upon which the storage systems are reliant.
While storage vendors have done significant work in scaling the data throughput into and out of their systems, that focus on throughput alone creates knock-on effects across the switching, traffic management, and security layers coupled to storage.
The stress on S3-compatible systems from AI workloads is multidimensional and differs significantly from traditional application patterns. It’s less about raw throughput and more about concurrency, metadata pressure, and fan-out considerations. Training and fine-tuning create particularly challenging patterns, like massive parallel reads of small to mid-size objects. These workloads also involve repeated passes through training data across epochs and periodic checkpoint write bursts.
RAG workloads introduce their own complexity through request amplification. A single request can fan out into dozens or hundreds of additional data chunks, cascading into further detail, related chunks, and more complex documents. The stress concentration is less about capacity, storage system speed, and more about request management and traffic shaping.
The risks of tightly coupling AI frameworks to storage
When AI frameworks connect directly to storage endpoints without an intermediate delivery layer, operational fragility compounds quickly during scaling events, failures, and cloud transitions, which can have major consequences.
“Any instability in the storage service now has an uncontained blast radius,” Menger says. “Anything here becomes a system failure, not a storage failure. Or frankly, aberrant behavior in one application can have knock-on effects to all consumers of that storage service.”
Menger describes a pattern he’s seen with three different customers, where tight coupling cascaded into complete system failures.
“We see large training or fine-tuning workloads overwhelm the storage infrastructure, and the storage infrastructure goes down,” he explains. “At that scale, the recovery is never measured in seconds. Minutes if you’re lucky. Usually hours. The GPUs are now not being fed. They’re starved for data. These high value resources, for that entire time the system is down, are negative ROI.”
How an independent data delivery layer improves GPU utilization and stability
The financial impact of introducing an independent data delivery layer extends beyond preventing catastrophic failures.
Decoupling allows data access to be optimized independently of storage hardware, improving GPU utilization by reducing idle time and contention while improving cost predictability and system performance as scale increases, Stringfellow says.
“It enables intelligent caching, traffic shaping, and protocol optimization closer to compute, which lowers cloud egress and storage amplification costs,” she explains. “Operationally, this isolation protects storage systems from unbounded AI access patterns, resulting in more predictable cost behavior and stable performance under growth and variability.”
Using a programmable control point between compute and storage
F5’s answer is to position its Application Delivery and Security Platform, powered by BIG-IP, as a “storage front door” that provides health-aware routing, hotspot avoidance, policy enforcement, and security controls without requiring application rewrites.
“Introducing a delivery tier in between compute and storage helps define boundaries of accountability,” Menger says. “Compute is about execution. Storage is about durability. Delivery is about reliability.”
The programmable control point, which uses event-based, conditional logic rather than generative AI, enables intelligent traffic management that goes beyond simple load balancing. Routing decisions are based on real backend health, using intelligent health awareness to detect early signs of trouble. This includes monitoring leading indicators of trouble. And when problems emerge, the system can isolate misbehaving components without taking down the entire service.
“An independent, programmable data delivery layer becomes necessary because it allows policy, optimization, security, and traffic control to be applied uniformly across both ingestion and consumption paths without modifying storage systems or AI frameworks,” Stringfellow says. “By decoupling data access from storage implementation, organizations can safely absorb bursty writes, optimize reads, and protect backend systems from unbounded AI access patterns.”
Handling security issues in AI data delivery
AI isn’t just pushing storage teams on throughput, it’s forcing them to treat data movement as both a performance and security problem, Stringfellow says. Security can no longer be assumed simply because data sits deep in the data center. AI introduces automated, high-volume access patterns that must be authenticated, encrypted, and governed at speed. That’s where F5 BIG-IP comes into play.
“F5 BIG-IP sits directly in the AI data path to deliver high-throughput access to object storage while enforcing policy, inspecting traffic, and making payload-informed traffic management decisions,” Stringfellow says. “Feeding GPUs quickly is necessary, but not sufficient; storage teams now need confidence that AI data flows are optimized, controlled, and secure.”
Why data delivery will define AI scalability
Looking ahead, the requirements for data delivery will only intensify, Stringfellow says.
“AI data delivery will shift from bulk optimization toward real-time, policy-driven data orchestration across distributed systems,” she says. “Agentic and RAG-based architectures will require fine-grained runtime control over latency, access scope, and delegated trust boundaries. Enterprises should start treating data delivery as programmable infrastructure, not a byproduct of storage or networking. The organizations that do this early will scale faster and with less risk.”
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.
