SanDisk HBF Comparison Faces Questions Over HBM Bandwidth, BF16 and NAND Endurance

SanDisk’s ambitious High Bandwidth Flash strategy is drawing new technical scrutiny after slides from its 2026 Investor Day compared an HBF equipped AI accelerator with a conventional HBM configuration. The presentation showed both systems delivering approximately 12.8 TB/s of aggregate memory bandwidth, while the HBF configuration offered as much as 4 TB of attached capacity compared with 192 GB of HBM. The comparison successfully demonstrates the enormous capacity advantage SanDisk is targeting, but it has also raised questions about whether the selected HBM specifications, numerical precision, and workload assumptions provide a representative picture of where competing AI memory will stand when HBF reaches broader deployment.

The bandwidth comparison deserves particular attention. SanDisk’s Investor Day example effectively assigns around 1.6 TB/s per stack to an 8 stack HBM configuration. That is already below currently announced next generation products. Samsung HBM4E, for example, reaches up to 3.6 TB/s per stack at 16 Gbps. An equivalent 8 stack configuration would therefore provide as much as 28.8 TB/s, more than twice the bandwidth used for HBM in SanDisk’s comparison. Even current Samsung HBM4 reaches up to 3.3 TB/s per stack, while Micron HBM4 already exceeds 2.8 TB/s.

They are deliberately misrepresenting HBM performance
For some reason, they fix the bandwidth of both HBM & HBF stacks at 1.6TB/s (12.8/8)
Secondly, nobody serves models on bf16 anymore
Most models are served on fp4 or fp8
So a Qwen 480B should occupy 240GB to 480GB depending on… https://t.co/I19HOYo5LJ

— Zephyr (@zephyr_z9) August 14, 2026

That does not necessarily make SanDisk’s slide incorrect. If the objective was to compare HBF and HBM at an intentionally matched 12.8 TB/s system bandwidth, normalizing both technologies can illustrate what HBF gains in capacity when bandwidth is held constant. The problem is that such a comparison can become misleading if interpreted as representing the maximum performance available from future HBM systems. This distinction matters because HBF is expected to coexist with rapidly advancing HBM rather than compete against a frozen generation of the technology. SanDisk and SK hynix have already established an open HBF specification supporting capacities up to 512 GB per package with bandwidth ranging from approximately 0.4 TB/s to 3.0 TB/s, using UCIe connectivity to integrate the technology with CPUs, GPUs, and other accelerators.

Been sitting on my HBF notes for the past 2 weeks

But $SNDK investor day update made me realize how manipulative they are on narrative, for two reasons:

> comparing HBF GPU and HBM GPU without showing write endurance (100k+ cycles, inherent NAND characteristic, vs unlimited for…

— sigma capitalist (@phithetasigma) August 13, 2026

The second controversy surrounds SanDisk’s use of BF16 for its model capacity comparison. BF16 requires 16 bits for each value, while modern AI accelerators increasingly support significantly narrower formats including FP8 and FP4. NVIDIA Blackwell hardware supports FP4, FP8, FP16, and BF16 Tensor Core processing, while NVIDIA has specifically optimized its newer architectures for formats such as NVFP4 to improve inference efficiency. Using FP8 instead of BF16 can approximately halve the raw memory required to store model weights, while FP4 can reduce it further, making a model appear considerably less constrained by HBM capacity.

However, describing BF16 as obsolete would also oversimplify the issue. BF16 remains directly supported by current NVIDIA data center hardware and continues to be relevant for workloads where greater numerical range or precision is required. Different models, layers, caches, and operations can also use mixed numerical formats. The more defensible criticism is therefore that BF16 represents a capacity intensive scenario that strengthens HBF’s apparent advantage, rather than that BF16 has no legitimate role in modern inference.

The much larger technical question is write endurance. HBF is built from NAND rather than DRAM, and NAND cells have finite program and erase endurance. This matters particularly for KV cache workloads because newly generated cache data can involve frequent writes as inference requests progress. HBM, being DRAM based, does not face the same NAND program and erase cycle limitation. SanDisk has primarily positioned HBF around inference workloads where large quantities of relatively static information, especially model weights, can be stored close to the accelerator and read repeatedly. Its own earlier HBF technical explanation demonstrated simulated performance within 2.2% of theoretically unlimited HBM when reading pretrained 8 bit weights from a Llama 3.1 405B model.

Recent independent research reinforces why workload placement matters. A new paper examining HBF for KV oriented LLM serving found that simply replacing an SSD based KV storage tier with HBF could actually reduce overall serving performance in the tested configurations. The researchers found that transient KV traffic became write intensive, could push an HBF stack toward thermal limits before reaching theoretical peak bandwidth, and could cause TLC NAND to wear more quickly than a capacity matched SSD pool. Importantly, the researchers did not conclude that HBF itself is fundamentally unsuitable. Instead, they argued that it should operate as a selective memory tier with carefully controlled writes, thermal management, and workloads that exploit its enormous capacity without treating it as a direct substitute for DRAM.

That closely matches the more realistic architecture already emerging around HBF, that could store model weights while HBM handles dynamic KV cache, the strongest implementation may combine both technologies. HBM would retain frequently modified data and latency sensitive workloads, while HBF would provide hundreds of gigabytes or potentially several terabytes of nearby capacity for largely static model weights and reusable information. This approach uses NAND and DRAM for the workloads where each technology has the strongest characteristics rather than attempting to make HBF replace HBM entirely.

SanDisk’s broader HBF strategy remains technically significant. Together with SK hynix, the company has already moved the technology from a proprietary concept toward an open specification, with Google and Tenstorrent participating in the ecosystem. The first specification supports 512 GB packages and up to 3.0 TB/s, while SanDisk previously said initial HBF samples were targeted for 2H 2026 and early AI inference devices using the technology for 2027. The company also emphasized HBF during its August 13 Investor Day as an important part of its strategy for increasingly storage intensive AI inference.

SanDisk does not need HBF to defeat HBM on every specification for the technology to succeed. Its strongest argument is capacity. Putting hundreds of gigabytes of NAND extremely close to an accelerator could reduce the need to add expensive GPUs simply because a model, cache, or data set cannot fit inside available HBM.

The Investor Day comparison nevertheless deserves context. Holding HBM at 12.8 TB/s while future HBM4E products can already theoretically deliver far more bandwidth makes HBF look stronger than a maximum specification comparison would. Using BF16 similarly increases the apparent memory pressure compared with FP8 or FP4 deployments. Neither assumption automatically invalidates the demonstration, but both substantially influence the outcome.

Write endurance is the harder engineering problem because bandwidth cannot remove the physical limitations of NAND. HBF therefore looks considerably more convincing as a massive read focused tier for model weights and selected reusable data than as universal memory for continuously changing KV cache. If SanDisk, SK hynix, accelerator designers, and software developers can manage that hierarchy intelligently, HBF does not need to replace HBM. It could create an entirely new layer between HBM and SSD storage.

Do you think HBF can become a standard memory tier for AI inference, or will NAND latency and write endurance keep HBM dominant for data located directly beside the accelerator?