Sandisk HBF vs HBM: Who Wins the AI Near-Compute Memory Race

Executive Verdict

HBM wins the performance race, but HBF may win the capacity-economics race. That distinction is more important than declaring one technology the universal winner.

High Bandwidth Memory remains the preferred near-compute memory for AI training, low-latency inference, frequently updated data, activations, key-value caches, and workloads with irregular access. Its combination of high throughput, low latency, byte-addressable operation, and mature accelerator integration is extremely difficult to replace.

Sandisk’s High Bandwidth Flash, developed as an open ecosystem initiative with SK hynix, attacks a different bottleneck: AI models and inference datasets are growing faster than affordable HBM capacity. HBF uses highly parallel NAND flash to place hundreds of gigabytes—and potentially much more in future systems—close to an AI processor. The first announced open HBF specification covers capacities up to 512 GB and performance grades reaching 3.0 TB/s through a UCIe-based interface.

The most likely outcome is therefore not “HBF or HBM.” It is HBF plus HBM: HBM for the hottest and most latency-sensitive data, HBF for large read-mostly model weights and embeddings, and SSDs for colder persistent storage. In that hierarchical future, both technologies can win—but they win different parts of the workload.

01 · Strategic Context

Why the AI Near-Compute Memory Race Matters

The artificial intelligence industry is often described as a competition for more computing power. That description is incomplete. Modern accelerators can perform an extraordinary number of mathematical operations, but only when data reaches their execution units quickly enough. If weights, activations, embeddings, and cache entries arrive too slowly, expensive silicon remains underutilized. The problem is increasingly not how many operations a processor can theoretically perform, but how efficiently the surrounding memory system can feed it.

This is the AI memory wall. Model parameter counts have expanded, context windows have grown, inference demand has multiplied, and mixture-of-experts architectures have created enormous pools of potentially active weights. At the same time, each accelerator package offers finite memory capacity. Organizations frequently purchase additional GPUs not because they need more arithmetic, but because a model does not fit in the memory attached to fewer devices.

That creates an expensive mismatch. A distributed deployment requires high-speed links between accelerators, more servers, larger network fabrics, more power, and more complex scheduling. Communication can become a performance bottleneck, while some processing cores remain underused. In other words, operators may be forced to buy compute in order to acquire memory.

HBM became the dominant answer because it places stacked DRAM immediately beside the processor and supplies extremely high bandwidth through a very wide interface. It is a foundational technology behind today’s leading AI GPUs and accelerators. However, HBM is costly to produce, difficult to package, concentrated among a small number of suppliers, and less dense than NAND flash.

Sandisk’s HBF enters the market with a provocative proposition: what if the AI industry could place a very large pool of persistent flash near the processor, organize it for extreme parallelism, and deliver enough aggregate bandwidth to support model inference? It would not need to match every characteristic of HBM. It would only need to keep the accelerator sufficiently busy at a significantly lower cost per stored bit.

The race therefore concerns more than component market share. It will influence accelerator architecture, server design, cloud economics, NAND demand, advanced packaging, AI model design, and the competitive balance among semiconductor suppliers. The winner will not necessarily be the device with the highest specification. It will be the architecture that delivers the lowest cost per useful AI result while meeting latency, quality, reliability, and power requirements.

02 · The Incumbent

Understanding HBM: The Performance Champion

High Bandwidth Memory is a form of vertically stacked synchronous DRAM designed to deliver far more bandwidth than conventional memory modules within a compact package. Multiple DRAM dies are connected using through-silicon vias and placed on top of a base or logic die. Thousands of connections provide a very wide interface, allowing data to move at lower clock speeds per pin while still achieving enormous aggregate throughput.

HBM stacks are normally positioned beside a GPU, CPU, or AI accelerator on an interposer or advanced substrate. Physical proximity reduces the distance traveled by data and improves energy efficiency compared with driving equivalent bandwidth through narrower off-package interfaces. The accelerator can access HBM as high-performance device memory, making it suitable for workloads with intense and rapidly changing data requirements.

Successive HBM generations have increased per-pin speed, stack height, capacity, and total bandwidth. HBM3 and HBM3E enabled the current generation of AI systems, while HBM4 expands the interface and moves more logic into the base die. HBM4 is designed to support greater customization and closer integration with host processors, reinforcing HBM’s role as part of the accelerator architecture rather than a detachable commodity.

These strengths explain HBM’s premium. HBM is not merely expensive DRAM. It combines specialized dies, wafer thinning, vertical interconnects, difficult assembly, extensive testing, and advanced co-packaging with valuable compute silicon. A failure in one component can reduce the yield or value of the complete package. Capacity must also be reserved well in advance, and only a few companies possess the manufacturing expertise required to supply leading products at scale.

HBM’s other limitation is density. DRAM prioritizes access speed rather than maximum bits per physical area. Increasing stack height helps, but thermal, mechanical, yield, and packaging constraints limit how much capacity can be placed around one accelerator. HBM is therefore extraordinarily capable but scarce, expensive, and finite—the exact combination that creates an opportunity for HBF.

03 · The Challenger

Understanding Sandisk HBF: Flash Moves Next to Compute

High Bandwidth Flash is a new category intended to combine the density and cost structure of 3D NAND with the parallel interfaces and close processor integration associated with high-bandwidth memory. Sandisk introduced the concept publicly as an AI inference solution and has worked with SK hynix on an open specification intended to build a broader ecosystem.

HBF should not be confused with an ordinary solid-state drive. An enterprise SSD places NAND behind a controller and connects to a host through interfaces such as PCI Express and NVMe. That architecture is flexible, persistent, and mature, but the protocol path and limited host connection prevent the accelerator from reaching all internal NAND resources with HBM-like parallelism.

HBF reorganizes the system. Large numbers of NAND dies and internal planes operate concurrently, and a wide chip-to-chip connection links the memory subsystem much more directly to an accelerator. Controllers schedule many outstanding reads, perform error correction, manage flash media, and deliver large data streams. AI compilers and runtimes can place tensors according to expected execution order, allowing data to be prefetched before a compute unit needs it.

In August 2026, SK hynix and Sandisk announced the first open HBF standard through the Open Compute Project. The reported specification defines two stack configurations, capacities reaching 512 GB, and three bandwidth grades spanning approximately 0.4 TB/s to 3.0 TB/s. It uses UCIe technology for die-to-die communication, reflecting the industry’s movement toward chiplet-based systems.

Sandisk has also described a longer-term vision in which HBF offers roughly eight to sixteen times the capacity of an HBM-based alternative at a similar package footprint or cost point, depending on product assumptions. Such comparisons are directional rather than guarantees. Commercial capacity, performance, yield, and price will vary by generation and implementation.

The essential idea is simple: HBF does not try to turn NAND into DRAM. It uses density, parallelism, prediction, and system co-design to make NAND useful as near-compute AI memory.

04 · Technical Comparison

Two Architectures Built Around Different Physical Strengths

The HBF-versus-HBM debate begins with the memory cells. DRAM stores each bit using a capacitor that must be refreshed but can be read and changed quickly. NAND stores charge in non-volatile cells arranged in strings and pages. It offers much higher density and retains information without power, but reads take longer and writes require page programming and block erasure.

HBM turns DRAM into a high-bandwidth device by vertically stacking dies and providing a very wide interface. The processor can request relatively fine-grained data with low latency. HBF takes a different route: it combines many slower flash operations until their aggregate data flow becomes extremely large. Its controller may issue requests across dies, channels, planes, and banks simultaneously.

This is the difference between latency and throughput. Imagine one delivery vehicle that can complete a short trip almost immediately. That resembles HBM. HBF resembles a fleet whose individual trips take longer but which can carry an enormous combined load when properly coordinated. If an application urgently needs one unpredictable item, HBM wins. If it can request many predictable items in advance, HBF can keep a large pipeline full.

A complete HBF implementation will probably include fast buffers. Controller SRAM, local DRAM, accelerator cache, or a smaller HBM pool can absorb metadata, activations, writes, and repeatedly accessed tensors. Consequently, the real architectural contest is not between pure HBM and pure HBF systems. It is between different ratios and management policies across multiple tiers.

05 · Performance

Bandwidth Headlines Do Not Tell the Whole Story

The first HBF specification’s upper bandwidth grade of 3.0 TB/s is important because it places HBF in a performance class relevant to accelerators rather than conventional storage. However, comparing that number directly with an HBM specification can be misleading. Peak interface bandwidth is only one part of application performance.

HBM combines bandwidth with short, predictable access latency. It can respond efficiently to random and dependent memory requests. HBF must create enough parallel work to hide the longer latency of NAND. If a runtime knows which tensor will be needed next, it can begin reading early. If a model generates an unexpected branch or expert selection, the accelerator may have to wait.

Request size matters as well. HBF will be strongest when transferring large blocks or tensor tiles. HBM handles small and large accesses more naturally. Queue depth is another variable: a flash system needs many operations in flight to expose its full aggregate throughput. An interactive inference request with a small batch may offer less parallelism than a high-throughput service handling thousands of concurrent users.

Sandisk has discussed simulation results in which an HBF-backed design performed within approximately 2.2 percent of an idealized system with sufficient HBM for a selected inference workload. This suggests that software can hide much of the media latency under favorable conditions. It does not mean that HBF has HBM-equivalent latency, nor does it establish identical results across models and service patterns.

Real HBF products must also cope with error correction, media variation, thermal throttling, bad-block replacement, firmware activity, and simultaneous reads and writes. These factors do not appear fully in every simulation. Independent testing on production silicon will therefore be the decisive milestone.

For predictable, bandwidth-bound inference, HBF could become highly competitive. For latency-sensitive, irregular, write-intensive, or dependency-heavy processing, HBM retains a decisive advantage. Performance does not produce one universal winner because AI workloads do not generate one universal memory pattern.

06 · Scale

Capacity Is HBF’s Strongest Weapon

NAND’s density is the foundation of the HBF business case. Modern 3D NAND stacks large numbers of memory layers vertically, enabling far more bits per die than DRAM. The first open HBF specification reaching 512 GB per stack illustrates this advantage. Multiple stacks around an accelerator could create a terabyte-class near-compute memory pool without requiring the same number of expensive HBM stacks.

This changes model placement. A large language model that cannot fit on one conventional accelerator is usually partitioned across several devices or partly offloaded to host memory and storage. Both strategies introduce data movement. Tensor parallelism, pipeline parallelism, and expert parallelism require communication between processors. Host offloading consumes PCIe or fabric bandwidth and may raise latency.

Greater local capacity could allow an accelerator to hold a complete quantized model, a larger collection of experts, several customer-specific models, or extensive embedding tables. It could also improve multi-tenancy by keeping more models resident and reducing cold-start delays when demand moves among endpoints.

Capacity can indirectly increase compute efficiency. If operators currently deploy eight accelerators to obtain enough HBM but require the arithmetic performance of only four, a more capacious memory tier may reduce the device count. Savings extend beyond processors to interconnects, switches, server boards, power supplies, cooling, rack space, and software licenses.

However, capacity has value only when data can be accessed quickly enough. Placing four terabytes next to an accelerator would not help if the processor frequently stalls. The correct metric is usable capacity at the required throughput and latency. HBF’s success will depend on maintaining bandwidth as capacity scales and preventing controller contention from turning a large memory pool into slow storage.

HBM vendors are not standing still. HBM4 supports taller stacks and larger dies, while future generations will continue raising capacity and bandwidth. Model compression, lower-precision formats, pruning, distillation, and sparsity also reduce memory requirements. HBF’s density advantage is substantial, but the capacity target will continue moving.

07 · Commercial Economics

Cost per Gigabyte Favors HBF; Cost per Token Is More Complicated

NAND flash is generally much less expensive per bit than DRAM. It benefits from high density, enormous global manufacturing volumes, and a competitive supply base developed for smartphones, PCs, enterprise storage, and data centers. This makes HBF’s capacity economics fundamentally attractive.

HBM carries multiple premiums. It uses advanced DRAM dies, through-silicon vias, die stacking, demanding test procedures, and scarce packaging capacity. It is also closely tied to expensive accelerators. Demand has grown rapidly enough to support premium supplier margins and long-term capacity agreements.

HBF will not cost the same as commodity SSD NAND. It requires selected media, high-performance controllers, wide interfaces, stacked packaging, substrates, error correction, firmware, testing, and accelerator qualification. If it shares advanced packaging resources with processors, some of the cost bottlenecks associated with HBM may remain. HBF should therefore be viewed as premium flash rather than inexpensive storage placed beside a GPU.

Even so, its lower media cost and greater density could reduce the cost of near-compute capacity dramatically. The greatest savings may come from system consolidation. A company might use fewer accelerators, reduce network traffic, shorten model-loading time, or host more models on each server. These benefits can matter more than the price difference between memory packages.

There are also hidden costs. Developers may need to optimize models for tiered placement. Operators need monitoring, endurance management, security procedures, and failure recovery. Early HBF products may lack a broad supplier base, raising procurement risk. If software cannot keep the accelerator busy, a lower-cost memory package can make the overall system more expensive per token.

The proper comparison includes:

• Capital cost: accelerators, memory, controllers, packaging, servers, and networking.
• Operating cost: power, cooling, maintenance, orchestration, and software engineering.
• Utilization: how much of the accelerator’s compute capability produces useful work.
• Service quality: throughput, first-token latency, tail latency, availability, and model quality.
• Fleet flexibility: model-switching speed, multi-tenancy, capacity pooling, and upgrade risk.

HBF is likely to win cost-sensitive, capacity-heavy inference deployments. HBM will continue winning where its higher price directly produces better utilization or enables service levels that flash cannot meet.

08 · Data-Center Efficiency

Power, Cooling, and Sustainability

Memory consumes energy both while storing information and while moving it. HBM is designed to transfer data efficiently over short, wide connections, but DRAM cells require refresh. HBF is non-volatile and does not need refresh to preserve model weights. NAND can provide lower standby energy per stored bit, which becomes meaningful when storing hundreds of gigabytes or terabytes.

Persistence may also reduce repeated loading. An HBM-based accelerator generally reloads model weights after startup, reset, or reallocation. HBF may retain them, potentially shortening recovery and reducing traffic from SSDs and host memory. In large fleets, model initialization and migration consume real energy and time.

However, peak HBF operation is not equivalent to idle flash storage. Achieving terabytes per second requires many NAND resources to work simultaneously. Controllers perform scheduling, buffering, address translation, wear management, and intensive error correction. Wide UCIe links and package I/O consume power. Thermal concentration can be challenging when flash stacks sit beside a high-wattage accelerator.

HBM also has a performance-efficiency advantage: completing work faster can lower total energy per result even if instantaneous power is high. If HBF causes processor stalls or extends request duration, the accelerator continues consuming energy while producing fewer tokens.

The industry therefore needs measurements of energy per delivered byte and energy per token under complete workloads. Vendors should report idle, average, and peak package power; cooling requirements; throttling behavior; and performance across realistic temperature ranges. HBF may ultimately improve rack-level efficiency by reducing accelerator count and data movement, but this benefit must be demonstrated rather than inferred from NAND’s non-volatility alone.

09 · Workload Fit

Training vs Inference: The Clearest Division of Labor

Why HBM Dominates Training

AI training repeatedly reads and updates parameters, gradients, optimizer states, and activations. Data dependencies are complex, and synchronization among accelerators is frequent. Memory must support high write bandwidth, low latency, fine-grained access, and consistent behavior. DRAM is naturally suited to these requirements.

Flash creates difficulties. NAND writes are slower than reads, occur in larger units, and eventually require erase operations. Frequent updates produce wear and write amplification. A controller could buffer or reorganize writes, but doing so adds complexity, power, latency, and additional fast memory. HBF may support checkpoint storage, model staging, or selected read-mostly training data, but it is unlikely to replace HBM as the primary training workspace.

Why HBF Targets Inference

Inference is generally read-dominant. Once deployed, model weights may remain unchanged for days or months. Every request reads these weights to generate output. Transformer layers execute in a largely known order, enabling compilers to predict which tensors will be needed and schedule HBF reads early.

High-throughput inference adds parallelism. Multiple requests can be batched, allowing controllers to distribute reads across many flash channels. The model-serving system can keep a deep pipeline active and hide individual read latency behind ongoing computation. Large tensor transfers also align better with NAND access granularity than small random writes.

Not all inference is equally suitable. Interactive applications with very small batches place greater emphasis on first-token latency. Sparse mixture-of-experts models may choose experts dynamically, making access less predictable. Long-context workloads create large key-value caches that are updated continuously and may remain better suited to HBM or DRAM. Recommendation systems can generate irregular embedding lookups.

The optimal design separates data by behavior. Stable weights and cold experts go to HBF. Activations, current key-value caches, frequently selected experts, and control data remain in HBM. Model servers move tensors between tiers according to predicted demand. This division converts HBF from a risky HBM substitute into a valuable capacity multiplier.

10 · Ecosystem

Software Will Determine Whether HBF Becomes Memory or Remains Storage

HBM is easy for software to understand because it behaves like high-performance device memory. HBF introduces a tier with different latency, access granularity, persistence, endurance, and write behavior. Exposing all of those details to AI developers would limit adoption. The ecosystem must make HBF efficient without making it difficult to use.

Compilers can play a central role. They already understand graph structure, tensor dimensions, operation order, and dependencies. A compiler can distribute weights across HBF channels, align data for large transfers, schedule prefetches, and overlap movement with computation. It can also identify tensors that should remain in HBM because they are small, frequently reused, dynamically updated, or latency-sensitive.

Runtimes must handle changing conditions. Expert popularity varies by workload. Model traffic rises and falls. Context lengths differ. A static placement plan may perform well during testing but poorly in production. Runtime software needs telemetry and adaptive policies for promotion, eviction, replication, and prefetching.

The programming model is another major decision. HBF could appear as a separately managed device, an extension of accelerator memory, a tensor-addressable resource, or part of a unified virtual address space. Explicit control can produce excellent performance but demands developer effort. Transparent paging is convenient but may generate unpredictable stalls. A balanced approach may use automatic defaults with APIs for advanced optimization.

Standards matter because software investment follows market scale. The Sandisk and SK hynix decision to publish an open HBF specification through the Open Compute Project is strategically significant. UCIe provides a broadly supported die-to-die foundation. Yet an electrical interface is only the beginning. The ecosystem also needs common management, telemetry, reliability, discovery, security, and software abstractions.

Operational tools must report channel utilization, queue depth, cache hit rate, latency distribution, temperature, corrected errors, bad blocks, remaining endurance, and model residency. Schedulers must understand that a server has multiple memory tiers and place workloads accordingly. Security software must manage persistent weights when hardware changes owners or tenants.

HBM wins the software race today because its ecosystem is mature. HBF’s long-term competitiveness will depend less on whether a prototype reaches a bandwidth target and more on whether mainstream frameworks can use it automatically.

11 · Operational Risk

Endurance, Reliability, Persistence, and Security

HBM and HBF fail in different ways. DRAM can experience transient or permanent errors, but it does not wear out through ordinary writes in the way NAND does. Flash cells tolerate a finite number of program-and-erase cycles. HBF controllers therefore require wear leveling, bad-block management, overprovisioning, error correction, and data-retention monitoring.

The read-heavy nature of model inference reduces the endurance problem. Weights can be programmed once and read many times. Nevertheless, production systems perform model updates, tenant changes, cache writes, logging, metadata updates, and recovery operations. If designers treat HBF as ordinary writable memory, endurance could deteriorate more quickly than expected.

Retention also varies with NAND type, wear, and temperature. AI accelerator packages operate in demanding thermal environments. Controllers must preserve data integrity near high-power processors and verify that model weights have not silently changed. Strong error correction and end-to-end checksums will be essential.

Non-volatility creates both a benefit and a security responsibility. Persistent model weights may accelerate startup, but they can remain on a package after a workload ends. Proprietary models are valuable intellectual property. Multi-tenant cloud operators need encryption, key destruction, secure erase, attestation, access control, and auditable sanitization procedures.

HBM’s volatility naturally removes data after power loss, although live systems still require strong isolation. HBF requires storage-class security controls inside a memory-like component. This is not an unsolvable problem—self-encrypting drives already implement similar concepts—but it increases controller and operational complexity.

Enterprise adoption will require published specifications for uncorrectable error rates, data retention, endurance, failure recovery, thermal limits, firmware update procedures, and expected service life. Buyers should not assume that a flash product is enterprise-ready merely because it has an accelerator-class interface.

12 · Semiconductor Manufacturing

Packaging Is Both an HBF Opportunity and a Constraint

HBM’s rise has made advanced packaging a strategic part of the semiconductor industry. Memory stacks must be placed beside large processors with thousands of connections, high power density, and strict signal-integrity requirements. Interposers, substrates, assembly capacity, and testing have all become potential bottlenecks.

HBF may relieve pressure on HBM wafer supply, but it does not eliminate sophisticated packaging. A 3.0 TB/s interface requires extensive connectivity. Multiple flash stacks, controllers, and an accelerator must communicate reliably while remaining within package area, power, and thermal limits. NAND dies also need stacking, testing, and known-good-die strategies.

UCIe can make integration more modular. An accelerator company may combine compute chiplets, HBM controllers, HBF controllers, and I/O dies in a common package or system. Standardized die-to-die links could reduce proprietary development and enable suppliers to mix technologies from different manufacturing processes.

Modularity introduces trade-offs. Additional chiplets and interfaces consume area and power. Testing becomes more complex, and a failure in one component can affect an expensive assembly. Repairability is limited when memory is tightly integrated with compute. Vendors may explore replaceable modules or package-level partitions, but every extra connector risks reducing bandwidth or increasing latency.

Manufacturing yield will be crucial to HBF pricing. NAND bits are inexpensive, but a high-capacity stack contains many dies. Suppliers need effective die selection, redundancy, and fault isolation. The first products may command substantial premiums until volume improves yields and spreads engineering cost across more units.

HBM has an established manufacturing learning curve and customer qualification base. HBF has the theoretical density advantage, but its package economics remain to be proven in volume. The winner of the memory race will be decided partly in assembly and testing facilities—not only in memory-cell laboratories.

13 · Competitive Landscape

How HBF Could Reshape the AI Memory Supply Chain

The HBM market is led by a small group of DRAM suppliers—SK hynix, Samsung, and Micron—working closely with accelerator designers, foundries, and packaging providers. Rapid AI demand has elevated HBM from a specialized graphics technology to one of the semiconductor industry’s most valuable product categories.

HBF offers NAND specialists a path into the same high-value AI infrastructure market. For Sandisk, the opportunity is strategically important. Conventional NAND markets are highly cyclical, and oversupply can produce severe price pressure. A differentiated near-compute product could improve margins, deepen relationships with cloud providers, and create demand for advanced flash generations.

SK hynix’s participation demonstrates that the market is not necessarily a simple conflict between flash companies and HBM companies. SK hynix has leadership positions in both HBM and NAND-related technologies. It can benefit from a heterogeneous hierarchy in which customers purchase premium HBM for active data and HBF for capacity.

The open-standard strategy may encourage additional suppliers, controller designers, accelerator vendors, and cloud operators to participate. A multi-vendor ecosystem would reduce buyer concerns about lock-in and supply continuity. It could also accelerate software support because developers can target a common platform.

On the other hand, leading accelerator companies may prefer proprietary solutions. They control valuable hardware and software platforms and may decide that larger HBM pools, custom memory controllers, compressed weight formats, pooled memory, or advanced SSD offloading provide sufficient results. HBF adoption depends on securing processor integration, not merely manufacturing memory stacks.

Other technologies will compete for the same architectural space. CXL expands memory beyond the local processor package. High-performance NVMe and GPU-direct storage can reduce data-path overhead. LPDDR and other DRAM types offer lower-cost capacity for some inference accelerators. On-chip SRAM, embedded DRAM, and emerging non-volatile memories address narrower segments. Software techniques such as quantization and sparsity reduce the amount of physical memory needed.

HBF’s strongest position is between HBM and SSDs. It must be much denser and less expensive than HBM while being substantially closer, wider, and more predictable than conventional storage. If it becomes too costly, buyers will choose more HBM. If it remains too storage-like, buyers will use familiar SSD architectures.

14 · Deployment Guide

Which Technology Fits Which AI Workload?

15 · Head-to-Head Result

HBF vs HBM Scorecard

16 · Strategic Outlook

The 2026–2030 Near-Compute Memory Roadmap

2026–2027: Standards and Validation

The first stage centers on specification work, engineering samples, controllers, package integration, and software prototypes. Demonstrations must move beyond peak interface measurements to real inference performance. Accelerator vendors and hyperscalers will test model placement, latency hiding, endurance, thermals, and error handling.

2027–2028: Targeted Deployments

If silicon meets expectations, early production systems will probably focus on controlled inference environments. Vendors may optimize hardware and software for selected model families, large batches, recommendation workloads, or multi-model serving. These deployments will provide the first credible cost-per-token evidence.

2028–2030: Hierarchical Memory Platforms

Broader adoption will require support across compilers, serving frameworks, cloud schedulers, and observability tools. HBF could become a standard tier on inference accelerators, especially if multiple suppliers deliver interoperable products. Systems may combine SRAM, HBM, HBF, CXL-attached memory, and SSDs under automated data-placement software.

During the same period, HBM will continue improving. HBM4 and later generations will provide more bandwidth, capacity, and logic customization. Supply will expand, and packaging technologies will mature. HBF is therefore competing against a moving target rather than today’s HBM products.

AI models will evolve too. Lower precision reduces weight size, while mixture-of-experts designs increase total capacity but activate only selected parameters. Longer contexts create more dynamic cache demand. Agentic systems may load many specialized models and retrieval indexes. These trends are favorable to heterogeneous memory because they produce data with different temperatures and access characteristics.

The most likely market structure is segmentation rather than displacement. Premium training accelerators will remain heavily dependent on HBM. Throughput-oriented inference accelerators may use a smaller HBM pool plus large HBF capacity. Cost-optimized edge products may combine LPDDR, HBF, and on-chip memory. SSDs will continue holding datasets, checkpoints, and cold models outside the near-compute domain.

17 · Final Verdict

Who Wins the AI Near-Compute Memory Race?

HBM wins when performance cannot be compromised. It remains unmatched for low-latency access, frequent writes, training, dynamic cache data, and mature integration with high-end accelerators. Any claim that NAND will simply replace HBM ignores fundamental media behavior and the enormous investment already supporting HBM platforms.

HBF wins when capacity and cost determine system scale. It can potentially place hundreds of gigabytes or terabytes of persistent model data close to compute. For read-heavy inference, sufficient parallelism and intelligent prefetching may deliver application performance close to much more expensive all-HBM configurations.

The hybrid architecture wins overall. AI data does not have one access pattern. Model weights may remain static, activations change rapidly, key-value caches grow dynamically, expert popularity shifts, and checkpoints need persistence. Assigning every byte to premium HBM is economically inefficient, while forcing every operation onto HBF would sacrifice latency and write performance.

The future system will use HBM as the accelerator’s active workspace and HBF as a massive near-compute capacity tier. Software will move tensors according to temperature, predictability, and service requirements. Conventional SSDs and pooled memory will remain behind both layers.

Sandisk does not need HBF to defeat HBM in every category. It needs HBF to prevent HBM from being required for every model byte. If production hardware validates the announced bandwidth, capacity, power, reliability, and cost targets, that objective is commercially realistic.

Overall conclusion: HBM remains the near-compute performance champion, HBF is the most credible challenger for capacity-oriented AI inference, and heterogeneous memory is the likely winner of the race