HBF Capacity Far Exceeds HBM but Cannot Fully Replace It: Cost Advantages Coexist with Access Limitations
Nashnova编辑部
Sandisk's High Bandwidth Flash (HBF) delivers 8–16× the capacity of HBM at a fraction of the per-GB cost, but NAND's inherent latency and write-endurance limits mean it can only supplement HBM, not replace it.
What exactly is HBF, and how does it differ from HBM?
HBM is built on DRAM — a fast memory medium that stores data in transistor-capacitor pairs. It offers low latency and fine-grained random access, sitting right next to the GPU as its immediate data supply.
HBF is built on NAND — the flash memory in phones and SSDs. A 3D array stacks storage cells vertically inside each die, then a CBA logic base (control circuitry bonded directly beneath the die) packages multiple high-density dies into one stack. Massive capacity, but every read must move an entire page of data.
This means → the core gap is not packaging but the underlying medium. DRAM is inherently fast and small-grained; NAND is inherently dense and cheap but slower, with limited write endurance. Packaging can push NAND's aggregate read bandwidth to 1.6 TB/s, but it cannot erase the higher per-access latency or the finite write life.
512 GB in one stack — where does the capacity edge come from?
HBF's density advantage comes from two layers of "multi-layer" stacking: each NAND die already contains a vertical multi-layer array internally; HBF then stacks 16 of these high-density dies into a single package, reaching 512 GB raw capacity in generation one.
In plain terms = each die is already a high-rise building; HBF fits 16 high-rises onto the same footprint. HBM's "multi-layer" only adds more buildings, but each one is far shorter.
This means → matching 512 GB with HBM would require 16 stacks of 32 GB, roughly 11 of 48 GB, or 8 of 64 GB. HBF's real value is letting model weights that could not physically fit near the GPU — due to slot limits — finally sit close to the compute.
NAND also offers non-volatility (data survives power-off) and no periodic refresh. But Sandisk has not published full read/write power curves; the logic base and interface still draw continuous power.
Is "8–16× cheaper" a reliable number?
Cost breaks into three layers. Layer one is bit cost — silicon area per GB. NAND's vertical arrays genuinely undercut DRAM here; this is HBF's most solid cost source.
Layer two is device cost: add the CBA logic base, bonding, UCIe interface, packaging, testing, ECC overhead, and yield-loss allocation. Layer three is system cost — customers may still need HBM as a hot cache, more complex scheduling software, and must absorb GPU idle time and extra energy from prefetch misses.
In plain terms = NAND's "raw material" is indeed cheap, but after packaging and system integration, the actual savings depend on whether packaging premiums and software scheduling can keep up. Sandisk's 8–16× figure is a theoretical projection — no volume pricing, full bill of materials, or independent yield data has been disclosed.
Can the "only 2.2% performance gap" claim be trusted?
That number comes from Sandisk's internal simulation: Llama 3.1, 405 billion parameters, 8-bit weights, single-kernel execution — a very specific scenario that cannot be extrapolated to all models and access patterns.
Sandisk's own fact-sheet footnotes explicitly acknowledge that HBF has higher latency and larger page sizes than HBM.
This reflects a narrow sweet spot: HBF excels at read-heavy, sequential weight loading in large-model inference. Once frequent random writes or fine-grained access enter the picture, NAND's weaknesses are amplified.
What key information has Sandisk left undisclosed?
Sandisk has not revealed whether first-generation HBF operates in SLC, MLC, or TLC mode — higher bits per cell raise density but increase error-correction pressure and programming time.
The 512 GB figure is raw capacity. After bad-block management, wear leveling, and system reserves, the usable capacity exposed to the accelerator remains undisclosed.
This means → until volume-production data arrives, HBF's capacity and cost advantages remain at the stage of "theoretical projection within the vendor's own framework." Whether it can achieve large-scale substitution ultimately depends on whether system-level software scheduling can effectively hide NAND latency — a question that will only be answered when the first customer deployments report real numbers.
Content is for reference only, not financial advice.