High Bandwidth Flash is being pitched as a way to give AI accelerators far more local memory capacity than today’s High Bandwidth Memory, but the Hot Chips 2026 discussion makes the trade-off clear: HBF is closer to on-package flash storage than to a simple HBM substitute. Tom’s Hardware reports that OXMIQ Labs, a GPU intellectual-property company, presented HBF use-case scenarios at Hot Chips 2026 and argued that the technology cannot replace HBM across most workloads. Chips and Cheese’s Hot Chips write-up reaches a similar practical conclusion from the software side: HBF may be useful, but only where systems and runtimes are built around its limits. The core idea is to take NAND flash, the technology used in solid-state drives, and place it in an HBM-like physical arrangement near a compute chip. Chips and Cheese says HBF cubes could sit on the same package as the processor, potentially alongside HBM. The goal is to provide much higher capacity than HBM while retaining enough bandwidth to be useful for some machine-learning workloads. Tom’s Hardware says the emerging HBF specification includes three grades. Grade 1 uses an 8-high 256GB NAND stack with an 8 GT/s UCIe interface and 384 GB/s of bandwidth. Grade 2 moves to a 512GB stack, a 16 GT/s UCIe interface, and 1.536 TB/s. Grade 3 keeps 512GB of capacity and reaches 3.072 TB/s using 32 GT/s UCIe 2.0, though Tom’s Hardware notes there is no clear timing for availability. The capacity economics are the attraction. According to Tom’s Hardware, OXMIQ frames HBF as delivering 8–16 times more capacity than HBM at roughly the same cost. But OXMIQ’s point is that the relevant metric is not just dollars per gigabyte. It is also dollars per unit of bandwidth, and HBF becomes less attractive as the workload needs faster delivery of those bytes to the processor. OXMIQ’s rack-level example shows the split. Tom’s Hardware reports that OXMIQ modeled a 72-GPU rack running the 1-trillion-parameter Kimi-K2 model at FP4. At cost and power parity, an HBM-only setup offered 20.7 TB of memory and 1,584 TB/s of aggregate bandwidth. Replacing HBM with HBF raised capacity to 294.9 TB, or 14 times more, but cut aggregate bandwidth to 922 TB/s. A hybrid HBM-HBF configuration landed at 89.3 TB and between 279 TB/s and 1,418 TB/s, depending on workload conditions. That makes HBF attractive when capacity is what limits system utilization. Tom’s Hardware says the HBF-only configuration would let each GPU hold its own Kimi-K2 instance and run 72 model instances per rack, while the HBM-only setup would need eight GPUs per instance and run nine instances per rack. But as simultaneous users and token-generation rates rise, the lower-bandwidth HBF design can become the bottleneck, while the HBM-heavy rack can make better use of bandwidth and deliver lower cost per token, according to the report. The software constraints are just as important. Chips and Cheese says HBF accesses are not like normal memory loads from HBM. Software must use direct memory access to move data between HBF and DRAM or HBM, and HBF prefers large, aligned transfers rather than fine-grained random access. The write-up also says host software may need to handle flash-management duties such as wear leveling and data retention, making HBF a non-plug-and-play technology. The plausible AI uses are therefore narrow. Chips and Cheese cites vLLM as one runtime example: mixture-of-experts weights could sit in HBF, with active experts copied into HBM when needed. KV cache placement could also work in sparse-attention designs that read only a subset of tokens each step, leaving most cache data cold in flash. Another possible use is replicating more model weights across GPUs to reduce cross-device communication, though Chips and Cheese stresses that moving data out of flash is still not cheap. The broader takeaway from both reports is that HBF is a specialized tier for large, relatively cold datasets—not inexpensive HBM with a different label. Who benefits: HBF could benefit accelerator designers and inference operators whose workloads are constrained by memory capacity rather than raw bandwidth. Workloads with cold model data, some mixture-of-experts patterns, or sparse cache access are the clearest candidates in the provided reports. Who's exposed: Teams treating HBF as a broad HBM replacement are exposed to disappointing performance. Bandwidth-bound inference and software stacks that cannot schedule explicit data movement are the weak fit.