VAST Data’s AMD Blocks Bet Challenges Nvidia’s AI Infrastructure Grip

VAST Data has expanded its AMD partnership across six infrastructure layers, turning the amd blocks story into a direct challenge to Nvidia-centered AI systems.

The agreement connects VAST’s AI Operating System with sixth-generation AMD EPYC processors, Instinct GPUs, Helios racks, Pensando networking, ROCm software, and shared inference storage. VAST will also use EPYC chips inside its next CBox and EBox hardware.

That scope matters more than another compatibility announcement. VAST already has close ties to Nvidia and the cloud providers deploying Nvidia accelerators. It is now building an AMD path that reaches from stored data to generated tokens.

The shift reflects a broader change in AI spending. Training remains important, but enterprises increasingly need infrastructure for continuous inference, reasoning agents, and retrieval-based applications. Those workloads repeatedly move models, prompts, and reusable context between storage, memory, CPUs, and GPUs.

AMD supplies the compute components. VAST wants to coordinate the data surrounding them. If their design works under production loads, buyers gain a more complete alternative to Nvidia’s integrated infrastructure model.

The central question is not whether AMD can ship a fast accelerator. It is whether AMD and its partners can make an entire AI system behave like one product.

The AMD Blocks Partnership Reaches Beyond GPU Support

VAST is treating AMD as an infrastructure foundation, not an accelerator option added at the end of a sales cycle.

The expanded collaboration was disclosed around AMD’s Advancing AI 2026 event in San Francisco on July 22 and 23. The companies described a common platform for training, inference, reinforcement learning, and agentic AI.

The first commitment concerns VAST’s own appliances. Sixth-generation EPYC processors, previously known by the Venice code name, will power the sixth generation of VAST CBox systems and the third generation of EBox systems.

CBox systems run data services and metadata operations within the VAST architecture. EBox systems provide the underlying storage capacity and data paths. Putting EPYC processors into both product lines gives AMD a role inside VAST’s platform, even when customers use other accelerators.

The new EPYC generation supports PCI Express 6.0. That interconnect provides twice the theoretical bandwidth of PCI Express 5.0, which can improve movement between processors, storage, networking devices, and attached accelerators.

VAST says the additional bandwidth should help its file, object, database, warehouse, and event-streaming services. However, application performance will still depend on software behavior, queue depth, network design, and workload concurrency.

The collaboration also covers an AI Infrastructure Reference Architecture developed with DriveNets. The design combines VAST AI OS, AMD Helios rack-scale systems, and DriveNets AI Fabric networking.

A reference architecture is a documented deployment pattern with component choices, sizing guidance, and validated connections. It reduces design work, but it is not proof that every customer workload will meet the same performance target.

The planned guidance spans model training, inference, reinforcement learning, and key-value cache workloads. A key-value cache, usually shortened to KV cache, stores attention data that a language model can reuse while generating later tokens.

TensorMesh and EmbeddedLLM are participating in additional inference work. Their involvement extends the project beyond processor qualification and into software deployment for production agent applications.

The original coverage also names seven AI cloud providers using AMD-related services: 5C, Core42, Crusoe, EmbeddedLLM, Phanos.AI, TensorWave, and Vultr.

That customer list shows existing deployment activity, but it does not reveal how much capacity each provider operates. It also does not establish whether customers use the complete VAST, AMD, and DriveNets design.

Still, the range of commitments makes this broader than a certification badge. AMD enters the VAST product roadmap, its reference architecture, its inference software, and its customer deployment story.

The partnership therefore creates a measurable test. Buyers can judge it through released systems, documented designs, public benchmarks, and production references rather than general statements about openness.

Inference Turns Stored Context Into a Compute Problem

The partnership is arriving now because inference makes data movement part of the critical path for every answer.

Traditional model training concentrates immense computation into scheduled runs. Production inference behaves differently. It serves many concurrent requests, maintains user context, retrieves external information, and often generates long reasoning sequences.

That pattern can leave expensive accelerators waiting. A GPU may have sufficient arithmetic capacity but still stall while the system loads model weights, retrieves documents, or reconstructs previously generated context.

VAST argues that inference is fundamentally a data problem. The claim is directionally credible, although compute, networking, and software scheduling remain equally important in many deployments.

Long prompts and multi-turn conversations expand the KV cache associated with each active request. Keeping every cache entry in GPU memory delivers low latency, but accelerator memory is limited and expensive.

Deleting the cache saves space but forces the model to recompute earlier attention states. Moving selected entries to host memory or shared storage creates another option, provided the system can retrieve them quickly enough.

VAST and AMD are testing that third route. Their integration combines Instinct GPUs, AMD Infinity Context, ROCm software, and VAST storage to offload reusable KV cache entries.

The data path uses AMD’s Pensando Pollara 400 network interface card. It moves information between GPU memory and VAST’s NVMe storage over NFS using TCP or remote direct memory access.

Remote direct memory access, or RDMA, lets one system access another system’s memory with limited CPU involvement. In the right network, it can reduce latency and processor overhead during repeated transfers.

VAST also plans automated cache lifecycle controls. Administrators could apply policies that expire and delete stored context containing personal, confidential, or regulated information.

That feature addresses a less visible consequence of cache offloading. Once transient model state moves into shared storage, it becomes governed data rather than temporary GPU memory.

Enterprises must know which user or application created the cache, how long it remains available, and whether another tenant can access it. They also need deletion controls that work across replicas and recovery systems.

Shared context could improve utilization in several situations. A customer-support agent might reuse a long product manual across thousands of conversations. A coding assistant might retain repository context across related tasks.

A research system could preserve processed documents while several agents examine the same evidence. A reasoning service could move inactive conversations out of accelerator memory, then restore them when users return.

These scenarios explain why storage vendors are moving closer to inference software. Their role no longer ends when a model checkpoint reaches a GPU cluster.

VAST’s architecture, called Disaggregated Shared Everything, separates compute and storage resources while presenting a common data space. The company says this model supports multiple protocols, isolated tenants, and a global namespace.

The design fits AI clouds that must serve many customers from common infrastructure. It also creates more dependencies across the storage, network, runtime, and accelerator layers.

VAST reported early tests using an Instinct MI355X GPU. The company says remote cache offloading delivered a ninefold improvement in time to first token and 9.7 times greater token throughput.

Time to first token measures the delay before a model starts responding. Token throughput measures how much generated output the system produces over time, especially under concurrent demand.

Those figures came from a specific comparison between cache offloading to local host memory and a remote VAST partition over NFS with RDMA. They were not results against Nvidia hardware or a complete production environment.

The distinction is important. The numbers support a storage mechanism under tested conditions. They do not establish that every VAST and AMD deployment will produce a ninefold improvement.

Even so, the experiment identifies the mechanism behind the partnership. The companies are not claiming that storage makes a GPU intrinsically faster. They are trying to reduce repeated work and keep accelerators occupied.

AMD Needs Partners to Counter Nvidia’s Integrated Stack

The main contest is an open, partner-built AMD system against Nvidia’s tightly coordinated infrastructure stack.

Nvidia’s advantage extends beyond accelerator performance. CUDA, networking, systems, libraries, deployment tools, and established operational knowledge all reduce friction for buyers.

That installed base shapes purchasing decisions. An enterprise choosing Nvidia can often find experienced engineers, tested frameworks, managed cloud capacity, and existing deployment templates.

AMD has been addressing the same problem by building more of the surrounding platform. Its strategy combines EPYC CPUs, Instinct GPUs, Pensando networking, Helios racks, and ROCm software.

VAST fills a notable gap in that collection. It supplies data services capable of feeding accelerators, holding model assets, managing inference context, and supporting applications around the models.

The competitive logic is clear. AMD does not need to own every layer if partners can integrate those layers into a coherent system.

That approach can preserve buyer choice. An AI cloud might combine VAST data services with AMD accelerators today, then retain some Nvidia capacity for workloads tied to CUDA.

VAST also benefits from avoiding dependence on one GPU supplier. Its customers increasingly want access to several accelerator types because availability, workload fit, and software requirements differ.

The company is not abandoning Nvidia. Its deeper AMD work instead positions VAST as common data infrastructure across heterogeneous AI fleets.

This makes the amd blocks strategy a form of modular competition. Each block has a defined role, but the complete system depends on standards and engineering between vendors.

AMD has been repeating that pattern elsewhere. Its Nutanix partnership combines EPYC, Instinct, ROCm, cloud orchestration, and enterprise lifecycle management.

AMD committed an equity investment and engineering funding in that agreement. The commercial structure differs from the VAST announcement, but both target enterprises seeking an alternative to vertically integrated AI platforms.

AMD has also worked with Red Hat, Oracle, Microsoft, major model developers, and inference software projects. Its software ecosystem includes frameworks and model providers that can reduce application-level compatibility gaps.

VAST contributes at a different level. It focuses on the path from stored information to active model context, where inefficient movement can erase gains delivered by faster processors.

AMD’s Helios design further raises the stakes. Helios packages CPUs, GPUs, networking, and software into a rack-scale system rather than asking customers to assemble accelerator servers independently.

Independent analyst Steve McDowell described the 2026 Helios configuration as 72 MI455X GPUs and 18 Venice CPUs in one liquid-cooled rack. His Helios analysis frames AMD’s challenge as converting hardware progress into deployed capacity comparable with Nvidia’s scale.

The VAST and DriveNets reference architecture surrounds that rack with data and scale-out networking. Together, those components move AMD closer to a purchasable system rather than a catalog of chips.

However, modularity introduces coordination costs. Customers need aligned firmware, drivers, network settings, storage policies, runtime versions, observability, and support escalation.

Nvidia can resolve more of those issues within one corporate structure. An AMD-based design distributes responsibility across several companies.

That difference is the central trade. A partner-built stack offers flexibility and negotiating leverage, but its operational experience must approach the consistency of a tightly integrated platform.

VAST can reduce that burden through documented reference designs and tested configurations. It cannot eliminate the need for joint support across independent suppliers.

The market pressure falls first on Nvidia-centered AI cloud providers and enterprises planning their next capacity cycle. They now have another architecture to evaluate before extending a single-vendor footprint.

It also pressures AMD. Public partnerships raise expectations for available systems, repeatable benchmarks, and customers willing to run valuable workloads outside Nvidia’s environment.

The 9.7x Result Needs a Production Reality Check

VAST’s cache benchmark is encouraging, but its narrow baseline cannot settle the business case for the combined architecture.

The reported 9.7-fold throughput gain compares two cache placement methods within an AMD-based test. It does not compare complete AMD and Nvidia systems, nor does it disclose an industry-standard benchmark.

Many details can change the result. Cache size, prompt length, request concurrency, model architecture, available host memory, storage distance, network congestion, and cache hit rate all affect performance.

The choice of baseline matters especially. Local host memory sounds faster than remote storage, but capacity pressure and access patterns can reverse that expectation under high concurrency.

A remote VAST partition can pool capacity across servers and preserve more reusable context. If the local-memory baseline frequently evicts useful entries, remote storage may avoid substantial recomputation.

That is a valid system benefit. It still requires buyers to understand exactly when it appears.

VAST acknowledges that relative speedups depend on the underlying hardware. A system with different compute capacity or storage latency can produce a different ratio.

Production workloads also mix request types. Some conversations are short and gain little from persistent cache. Others contain large contexts but return too infrequently to justify keeping their state.

Cache reuse creates another uncertainty. Offloading produces value only when a later request can reuse stored information more cheaply than recomputing it.

Administrators therefore need admission and eviction policies. The system must decide which entries deserve storage, which should remain in accelerator memory, and which should disappear.

Security controls require equal scrutiny. A stored KV cache can encode sensitive information from prompts, retrieved documents, and previous model output.

Automated deletion policies help, but buyers will need evidence covering tenant isolation, encryption, access logs, replication, backup behavior, and verifiable erasure.

Inference quality also enters the picture. A stale or incorrectly associated cache could produce invalid output, cross-user contamination, or difficult debugging failures.

The collaboration announcement describes lifecycle management, but it does not publish a complete threat model. It also does not explain how policy enforcement works across every supported inference runtime.

Operational ownership remains unresolved. A latency problem might originate in ROCm, the model server, Pollara networking, DriveNets fabric, NFS settings, VAST software, or the application itself.

Reference architectures can define supported versions and diagnostic procedures. Customer references will reveal whether those procedures work during real incidents.

The same caution applies to AMD’s broader performance statements. Internal tests can guide evaluation, but buyers should reproduce results with their models, prompts, concurrency, and service-level targets.

An enterprise should compare total system behavior rather than accelerator specifications alone. Important measures include completed requests per rack, first-token latency, output-token latency, energy use, cache hit rates, failure recovery, and engineering time.

The expanded collaboration describes improved efficiency and performance. It does not disclose customer pricing, deployment duration, or audited production savings.

That absence is normal for an early architecture announcement. It also means the commercial conclusion remains open.

The amd blocks approach will be credible when multiple customers report predictable deployment and operating results. A large demonstration at a vendor event is useful, but repeatability creates trust.

VAST and AMD also face a moving target. Nvidia continues improving networking, inference software, storage integration, and rack-scale systems.

Other storage companies are pursuing the same GPU-feeding opportunity. Weka, DDN, Dell, HPE, Pure Storage, and cloud-native data platforms all want a larger role in AI infrastructure.

Customers therefore have more than two choices. They can use an integrated Nvidia stack, assemble AMD-based systems, or operate mixed clusters with separate data infrastructure.

The winning route will vary by workload. A company tied to CUDA-specific software may accept less hardware choice to reduce migration work.

An AI cloud serving open models at high concurrency may value accelerator diversity and shared cache capacity more. Large enterprises may prioritize support responsibility and compliance controls over peak benchmark ratios.

These distinctions keep the announcement from becoming a simple AMD-versus-Nvidia scorecard. It is an architectural option that must earn its place through workload-specific evidence.

Three Signals Will Show Whether the Strategy Works

The next phase depends on shipping reference systems, publishing reproducible results, and proving adoption beyond named partnerships.

The first signal is the availability of VAST’s next CBox and EBox generations using sixth-generation EPYC processors. Shipping systems will convert a roadmap commitment into equipment that customers can qualify.

Buyers should watch supported configurations, general availability dates, upgrade paths, and deployment guidance. Broad availability would strengthen the claim that AMD is becoming a standard VAST platform.

Delays or limited configurations would weaken that conclusion. They would suggest the partnership remains more advanced in marketing than in product operations.

The second signal is expanded KV cache testing. Useful disclosure would include models, context lengths, concurrency levels, cache hit rates, network topology, and latency distributions.

The strongest evidence would come from customer-run tests or reproducible benchmark instructions. Results across several models and inference engines would show whether the mechanism transfers beyond one controlled workload.

A repeated improvement would strengthen the case for treating shared storage as active inference infrastructure. Smaller or inconsistent gains would narrow the technology’s addressable use cases.

The third signal is production adoption of the joint reference architecture. Named customers already show interest in AMD capacity, but deployments of the complete design matter more.

Watch for customers connecting Helios racks, DriveNets networking, VAST AI OS, and ROCm-based inference in one supported environment. Their operational reports should include utilization, reliability, and rollout time.

Customer expansion would validate AMD’s partner-led answer to Nvidia’s integration advantage. Isolated pilots would show that technical choice alone does not overcome software familiarity and support complexity.

AMD’s own roadmap adds urgency. The company previously targeted Helios availability during 2026 and reported growing ROCm adoption in its data center strategy.

VAST gives that strategy a stronger data layer. It also creates a demanding test because storage and context management sit directly on the user-visible latency path.

Developers should care because infrastructure choices determine which models, runtimes, and optimization tools remain practical. Better AMD support can reduce dependence on software designed around one accelerator platform.

AI cloud operators should care because unused GPU time directly reduces available service capacity. Shared context can help only if its storage and network costs stay below the recomputation it replaces.

Enterprise buyers should care because inference data has governance requirements. Moving cached context into managed storage can improve control, but it also expands the security boundary.

Knowledge workers will experience the result indirectly. If systems preserve useful context efficiently, assistants can handle longer projects without repeatedly rebuilding the same background.

That outcome also depends on how applications organize source material. A well-maintained AI knowledge base can improve retrieval before any infrastructure optimization begins.

The amd blocks strategy is therefore not a declaration that AMD has displaced Nvidia. It is a plan for making AMD compute easier to deploy as part of a complete inference system.

VAST has committed hardware, software, networking, cache management, and reference designs to that plan. The remaining work is public validation under mixed, sustained customer demand.

Over the next several months, ignore broad claims about openness or AI factories. Look for shipped VAST appliances, reproducible cache results, and customers operating the full architecture.

Those three signals will show whether the partnership creates a credible second path for AI infrastructure, or merely another collection of compatible components.