// TOM'S HARDWARE US — HARDWARE & GADGET
Hot Chips 2026: High Bandwidth Flash promises massive bandwidth and capacity, but its usability is extremely limited — new memory format strikes a balance between HBM and NAND flash
Will it ever take off, if it does not make sense for a broad set of AI workloads?
When you purchase through links on our site, we may earn an affiliate commission. Here’s how it works.
OXMIQ Labs, a GPU IP company, revealed at Hot Chips 2026 that High Bandwidth Flash (HBF) cannot replace High Bandwidth Memory (HBM) across the vast majority of workloads. For some, HBF could emerge as a specialized memory tier for huge but relatively cold datasets. For others, HBF can do more harm than good.
When SanDisk unveiled its High-Bandwidth Flash (HBF) concept in early 2025, the technology pledged to equip AI accelerators with terabytes of relatively inexpensive memory and reduce the need for traditional High-Bandwidth Memory (HBM), a promise that raised a number of doubts from the very beginning.
The emerging HBF specification includes three performance grades. Grade 1 uses an 8-Hi 256GB NAND stack with an 8 GT/s UCIe interface and 384 GB/s bandwidth. Grade 2 uses a 512GB NAND stack with a 16 GT/s UCIe interface and supports 1.536 TB/s bandwidth. Grade 3 reaches 3.072 TB/s using 32 GT/s UCIe 2.0 while retaining the same 512 GB capacity.
Since HBF relies on 3D NAND, it supports read block sizes between 64 bytes and 4 kilobytes, 4KB writes, and 4KB page sizes. While HBF Grade 1 can barely compete against contemporary HBM, HBF Grade 3 can compete against HBM4E, though we have no idea when such memory will be available. However, the main feature of HBF is not necessarily performance per se, but 8 – 16 times more capacity than HBM at roughly the same cost.
Indeed, OXMIQ believes that HBF should be viewed as a high-capacity memory technology rather than inexpensive HBM. Memory economics depend not only on how many gigabytes an application needs to store, but also on how quickly those bytes must be delivered to the processor. As bandwidth demand rises, adding inexpensive but relatively slow HBF eventually becomes less economical than using HBM, according to estimates by OXMIQ.
OXMIQ demonstrated the trade-off by modeling a 72-GPU rack running the 1-trillion-parameter Kimi-K2 model at FP4. At cost and power parity, an HBM-only configuration provides 20.7 TB of memory and 1,584 TB/s of aggregate bandwidth. Replacing HBM with HBF increases rack capacity by 14 times to a whopping 294.9 TB, but reduces aggregate bandwidth to 922 TB/s. A hybrid configuration with HBM and HBF provides 89.3 TB and between 279 TB/s and 1,418 TB/s, depending on workload conditions. The difference between HBM and HBF bandwidth is the reason why HBF looks excellent when memory capacity limits the system. However, HBF eventually loses when bandwidth/throughput becomes the limiting factor.
In OXMIQ's model, an HBF-only configuration enables each GPU to hold its own Kimi-K2 instance and run 72 model instances per rack. Whereas an HBM-only configuration requires eight GPUs to hold each model instance (meaning compute performance gets wasted) and can therefore run only nine instances per rack. This makes HBF particularly attractive when memory capacity determines the number of GPUs required. However, as the number of simultaneous users and their token-generation rate increase, HBF's lower bandwidth becomes the bottleneck, while the HBM-based rack can make better use of its substantially higher memory bandwidth and ultimately deliver lower cost per token, according to OXMIQ's model.
As a result, HBF can dramatically reduce the number of GPUs needed simply to accommodate a very large model (i.e., enable one HBF-equipped GPU to do the capacity job of eight HBM-equipped GPUs). Nonetheless, if the objective is maximum inference throughput from a fully utilized rack, HBM may remain the better, more economical choice. At the end of the presentation, OXMIQ concludes: 'HBM for the rack, HBF for the box.'