Will HBF Create Upside for Sandisk?

HBF's name leads many investors into technical misunderstanding. The technology itself also remains contested, on access latency, endurance under repeated writes, heat and packaging yield.

Earlier this year I reviewed the H3 paper published by SK hynix on what HBF means technically and where its limits are.

This article analyzes the HBF that Sandisk presented at its Investor Day and in related public materials, and estimates bottom up how much the technology could move Sandisk’s share price if it reaches commercial deployment.

The report judges HBF’s commercialization prospects in four steps.

Section 1 compares the four architectures Sandisk presented in terms of data placement, write load and latency, and identifies which configuration is technically most realistic. It focuses on what the presentation did not sufficiently explain, namely KV cache write burden, prefetch, heat and endurance, and examines the conditions under which each architecture holds.

Section 2 examines HBF’s competing technologies, asks why HBF is needed relative to them, and tests whether it can lower system TCO despite its complex packaging cost.

Section 3 compares the platform structures of Google, Meta, Tenstorrent and NVIDIA, and analyzes technically why Google and Meta have a relatively strong incentive to evaluate HBF while NVIDIA is judged unlikely to.

Finally, Section 4 uses accelerator unit pools, HBF attach rates and stacks per accelerator at Google and Meta to derive Sandisk’s direct HBF revenue bottom up, and separates the second-order effects on product mix, NAND wafer absorption and revenue structure that could matter more to the share price.

For investors who have wondered how HBF actually works and what it could mean for Sandisk’s revenue and share price, this article is written for you.

Disclaimer

This document is prepared for information purposes using public information and the author’s own analysis, and does not constitute a recommendation to buy or sell any security. Product specifications, participating companies and public roadmaps rely on disclosures from the companies and standards bodies involved. Items that have not been disclosed, including HBF and HBM data placement, cost structure and customer-level adoption likelihood, are identified as analytical assumptions or inference. Specifications, commercialization timing and customer adoption may change, and responsibility for investment decisions and their outcomes rests with the investor.

CONTENTS

1. Technical feasibility: comparing the four configurations

2. Economics: alternatives and capacity per package

3. Customer adoption

4. HBF’s economic impact: a Google and Meta bottom-up model

The four configurations differ in what data HBF handles and whether HBM remains. HBF Only fills every stack site with HBF and stores both weights and KV cache there. HBF (+HBM) replaces only part of the stacks, splitting the roles with HBM.

HBM/HBF Cached places HBM as a front-end cache and stores weights and KV cache in HBF. Disaggregated separates prefill from decode and puts HBF on the decode accelerator to hold decode weights and KV cache.

The technical assessment that follows uses these data placement differences as its basis.

The first question is what role HBF can play in real inference workloads.

The four configurations differ in the data HBF handles and whether HBM remains. The comparison therefore uses write load, access pattern and latency sensitivity on a common basis rather than capacity alone.

HBF Only fills every stack site with HBF and uses no HBM. Because both model weights and KV cache reside in HBF, the configuration gains capacity but must also absorb the continuous write load of the KV cache directly.

In internal testing presented at Investor Day, four HBF-only accelerators matched the token-per-second throughput of eight HBM-only accelerators.

By the company’s explanation, the performance gap arises when HBM runs short of KV cache capacity, pushing some data into system memory and lowering GPU utilization. HBF relieves that capacity constraint by providing larger on-package capacity.

The company cited this as 8x capital efficiency and 2x GPU efficiency. The comparison is internal, however, and key premises such as GPU capacity and numeric precision may differ from real deployments.

The case for HBF Only therefore has to be verified in two steps.

First, whether the same on-package capacity shortfall still occurs on the latest accelerators and at lower inference precision.

Second, whether HBF can absorb the KV cache write load along with its thermal and endurance requirements.

The first issue is the comparison conditions.

The presentation used 192GB of HBM per GPU and BF16 to derive 960GB of weights for a 480B model, and concluded that eight accelerators were required once KV cache was included. Applying FP8 reduces the same weights to 480GB, and in the 288GB-per-GPU environment this report uses as its basis, the weights themselves fit within the combined HBM capacity of two accelerators.

The HBM left after loading weights can serve KV cache and runtime, though the actual headroom depends on KV cache, activation and runtime configuration. The capacity shortfall the presentation assumes may therefore be weaker than stated, but that does not mean two accelerators are sufficient for the entire serving footprint.

The second issue is the write behavior of the KV cache.

In HBF Only, KV cache is written directly to HBF. New data is written on every token and discarded when the session ends, so unlike read-dominant model weights it produces a continuous write load. NAND flash carries cell endurance limits under repeated writes. Any structure that writes KV cache directly to HBF must therefore treat write lifetime and thermal management as design variables.

The Investor Day materials and keynote disclosed to date do not specify those limits or the management policy.

Published on August 12, 2026, Li et al. (2026, arXiv:2608.11668) evaluated HBF-based KV serving using four production traces and five dense and MoE models. Write traffic exceeded read traffic across every trace, thermal limits were reached before peak bandwidth, and TLC configurations wore out faster than the SSD pool being replaced. The conclusion is that without SSD-class write management, storing transient KV cache directly in HBF is not sustainable. HBF Only has no HBM cache or write buffer, so it is the most exposed to that constraint.

Follow-up studies released on August 14 assess HBF in more conditional terms.

Son et al. (2026, arXiv:2608.13868) finds that HBF can raise batch size and throughput and reduce GPU count, but only on the premise of read bandwidth close to HBM and substantial endurance improvement.

Kim et al. (2026, arXiv:2608.14333) reports 1.94x throughput from a structure that separates immutable weights from mutable KV cache and supplies them over two parallel paths. Both are simulations, and both point to data type and movement path separation mattering more than capacity.

Taken together, I judge HBF Only to have low applicability to general conversational inference.

The more plausible fit is batch-style workloads that generate limited KV cache while repeatedly reading large weights or reference data. Where session counts and context lengths keep growing, KV write load rises and the applicable range narrows without additional write-management technology.

HBF (+HBM) configures k of N stack sites as HBF and keeps the rest as HBM. The essential feature is that data placement between HBF and HBM can be split according to workload characteristics.

This article takes as its base case a configuration that places model weights in HBF and KV cache in HBM. That separates the continuous KV cache write load, the largest constraint in HBF Only, from HBF.

The company has not disclosed the value of k, the data placement criteria between HBF and HBM, or the software policy. The assessment below therefore rests on the analytical assumption that weights sit in HBF and KV cache remains in HBM.

That assumption aligns reasonably well with HBF’s physical characteristics and the access profile of model weights.

First, model weights are written at load time and thereafter mostly read during inference, so the endurance burden from repeated writes is limited.

Second, weight access is dominated by large sequential reads at layer granularity, which matches NAND’s page-level read behavior comparatively well. It wastes less of each page read than small random access would.

Third, where the next required weight location is predictable, prefetch can overlap flash’s microsecond-class read latency with computation. Actual performance depends on prefetch accuracy and software scheduling.

The study cited above likewise assessed read-dominant model weights as a comparatively good fit for HBF, provided that placement is selective and that write budgeting and thermal control are in place.

Under this report’s assumptions, at k=4 node memory capacity rises from 288GB to 2.2TB while total bandwidth falls from 22TB/s to 17.4TB/s. As k increases, HBF capacity expands but HBM capacity and bandwidth decline.

The optimal k therefore depends jointly on weight size, KV cache demand and the bandwidth loss that can be tolerated.

HBF (+HBM) applies best under two conditions.

First, model weights must be large enough, in the hundreds of GB or more, that HBM alone cannot hold them. Second, data placement and prefetch must be optimizable alongside the accelerator software. The remaining item to verify is whether throughput and latency hold at target levels once prefetch is applied.

HBM/HBF Cached uses HBM as a low-latency cache tier and stores both model weights and KV cache in HBF. It reduces the frequency of HBF access relative to HBF Only, but the write constraint persists as long as KV data lands in HBF.

This configuration favors services where identical or similar contexts are referenced repeatedly and a high cache hit rate can be sustained. Document-grounded question answering and workloads that repeatedly reference the same codebase are plausible candidates. In general conversational services where context differs sharply by session, HBF access and write load rise and applicability falls.

The Disaggregated configuration separates prefill and decode accelerators. In the published diagram, GDDR is used on the prefill side while decode-side HBF stores decode weights and KV cache.

The assessment differs by data type. Decode weights are read-dominant after the initial load and fit HBF well. KV cache still requires write management, since new K and V are written on every token even during decode.

Separate from technical feasibility, the economics against competing architectures also need checking. The comparison cases in this report already include disaggregated designs that use no HBF, such as a GDDR7-based prefill accelerator and an SRAM rack for decode. For an HBF-based disaggregated design to be adopted, it must demonstrate an advantage in cost per token or system efficiency over those designs.

The relative appeal of the four configurations comes down to what data sits in HBF and how much writing that data generates. Placing read-dominant model weights in HBF carries a light endurance burden, while writing KV cache directly to HBF adds write management and thermal control on top.

The following sections provide an in depth analysis of the HBF architecture.

The analysis examines alternative technologies that could compete with HBF, the technical factors that could nevertheless support HBF adoption, the types of customers most likely to deploy it, and whether NVIDIA could become one of them.

Finally, a proprietary analytical model is used to assess how HBF commercialization could affect Sandisk’s share price.