Sandisk and SK hynix Release an Open HBF Spec, but the Hardware Test Comes Next

Sandisk and SK hynix released the first open High Bandwidth Flash specification on August 4, only six months after launching their standards group. The announcement reached Google News with an unusually concrete promise for an emerging memory technology: capacities up to 512GB and bandwidth reaching 3TB/s.

That combination targets a widening gap inside AI systems. High Bandwidth Memory, or HBM, supplies speed near processors but remains limited in capacity. Solid-state drives provide far more capacity, yet sit too far from the processor for many latency-sensitive inference tasks.

High Bandwidth Flash, known as HBF, is designed to occupy the layer between them. Sandisk and SK hynix are not proposing that NAND flash replace every HBM stack. They want systems to use HBM for the hottest data and HBF for larger working sets that still need rapid access.

The specification makes that architecture easier for processor designers to evaluate. It does not establish that HBF can deliver its advertised performance in production hardware. The real contest is therefore not Sandisk against SK hynix. It is the open specification against the engineering and adoption work still required.

The HBF Specification Turns a Memory Idea Into a Shared Target

The release gives processor, packaging, and software teams a common HBF design target, but it does not deliver a finished product.

SK hynix announced the specification alongside Sandisk at FMS 2026 in Santa Clara, California. The event runs from August 4 through August 6 and focuses on memory and storage technology.

The companies published the work through the Open Compute Project, or OCP, an industry organization focused on open data center infrastructure. That choice matters because HBF needs participation beyond two memory suppliers.

According to the HBF specification announcement, the initial design supports two physical configurations. An eight-die stack provides one option, while a 16-die stack supports the highest announced capacity.

The specification covers capacity up to 512GB. It also defines three performance grades spanning approximately 0.4TB/s to 3TB/s of bandwidth.

Those grades let system designers match HBF implementations to different workload and cost requirements. A lower grade could support less demanding inference tasks without forcing every design toward the most complex package.

The release also addresses electrical characteristics, packaging reliability, processor connections, and software input and output guidelines. Those details move HBF beyond a presentation concept and toward something engineering teams can review.

The processor connection uses Universal Chiplet Interconnect Express, or UCIe. UCIe is an open package-level interface that connects separate semiconductor dies inside one system.

The official UCIe specifications cover physical connections, protocols, software behavior, and compliance testing. Using that interface reduces the need for HBF to depend on one processor vendor’s private connection.

It also creates a route for HBF to connect with CPUs, GPUs, and other accelerators. That flexibility is central to the open-standard argument because AI infrastructure includes more than one processor architecture.

However, an interface standard does not automatically create interoperability. Vendors still need controllers, packaging methods, firmware, drivers, memory-management policies, and compliance tests that work together.

That distinction is easy to lose in a short Google News headline. Sandisk and SK hynix released a specification, not generally available HBF modules or production AI servers.

Their speed is still notable. Sandisk and SK hynix announced their original standardization partnership in August 2025. They launched the OCP workstream in February 2026 and produced this first specification roughly six months later.

Google and AI processor developer Tenstorrent now participate in the consortium, according to SK hynix. Their presence gives the project valuable input from both the workload and processor sides.

Neither company has announced a qualified production system using the specification. No independent benchmark has yet established the bandwidth, latency, endurance, or energy performance of a conforming commercial device.

The open document therefore changes what the industry can discuss. Instead of debating an undefined memory category, engineers can examine stack sizes, bandwidth grades, interfaces, packaging expectations, and software requirements.

That is the immediate event. The larger issue is why AI inference needs another memory layer at all.

Why AI Inference Is Putting HBM and SSDs Under Pressure

HBF exists because inference increasingly needs HBM-like access to data sets that are too large to keep entirely in HBM.

AI training receives much of the infrastructure attention, but inference creates a different memory problem. Training builds a model. Inference repeatedly runs that model to answer requests, generate media, use tools, or operate an agent.

A deployed service may need model weights, attention data, cached tokens, retrieval indexes, and application context. Keeping every active data set in the fastest memory becomes difficult as models and concurrent workloads grow.

HBM places stacks of DRAM close to a processor and connects them through a wide interface. This design provides high bandwidth for accelerators that must move large quantities of data quickly.

Its strengths do not remove physical constraints. Package space, manufacturing complexity, power, capacity, and supply all shape how much HBM can sit beside each processor.

Enterprise SSDs solve a different problem. They hold far more information at a lower cost per bit, and NAND flash retains data without continuous power. Their conventional storage path adds latency and software overhead.

That leaves an architectural gap. Some inference data does not require the lowest possible HBM latency, but it needs faster and more direct access than a conventional SSD path provides.

SK hynix describes HBF as a supporting layer while HBM continues handling the highest-bandwidth work. This tiered-memory model assigns data to different technologies according to access frequency and performance needs.

A large model offers a useful scenario. Frequently used portions could remain in HBM, while less active weights sit in HBF. An SSD could hold data that the system needs less often.

The system would then move information among tiers as workload conditions change. This approach resembles established caching hierarchies, but the capacities, bandwidth requirements, and packaging challenges are much larger.

The benefit depends on placement decisions. If software repeatedly fetches the wrong data from a slower tier, processor cores can wait and overall performance can fall.

HBF must therefore become more than dense flash beside an accelerator. The surrounding system needs controllers and software that predict which data belongs in each memory layer.

Agentic AI strengthens this pressure. An agent can maintain longer histories, consult external knowledge, call software tools, and coordinate several model operations for one user request.

Those workflows create larger and less predictable working sets. They can also keep inference infrastructure busy for longer periods than a single prompt and response.

For developers, the question is not whether every application needs HBF. The question is whether future inference systems need a middle tier that reduces expensive HBM capacity without falling back to ordinary storage.

For enterprise buyers, memory architecture can affect server utilization, response time, power consumption, and the number of models that fit inside one system. Those factors shape operating costs even when users never see the underlying components.

Knowledge workers also have an indirect stake. Larger local context and more persistent agents require infrastructure that can retain and retrieve working data efficiently.

A searchable knowledge base faces a similar placement problem at the application level. Relevant material must reach the model quickly without loading every document into the fastest context layer.

HBF addresses the hardware side of that broader challenge. It attempts to keep more model-related data close enough to computation for practical inference, without treating every bit as premium HBM data.

That creates pressure on processor vendors, cloud operators, and memory suppliers. Each group must decide whether another tier improves the system enough to justify added packaging and software complexity.

Google News Attention Hides the Real Contest: Specification Versus Silicon

The specification is credible enough to attract partners, but only working silicon can prove that HBF belongs beside AI processors.

Sandisk first presented HBF as a NAND-based memory architecture aimed at inference. Its original plan called for initial HBF samples during the second half of 2026.

The company also expected samples of the first inference devices incorporating HBF in early 2027. Those targets were included in its 2025 partnership release.

The August 2026 specification does not confirm that those sample milestones have been completed. It establishes the technical framework that potential products should follow.

Sandisk’s first-generation concept targets 1.6TB/s of read bandwidth and 512GB in a 16-die stack. Later generations are projected to exceed 2TB/s and eventually reach 3.2TB/s.

Those numbers come from Sandisk’s own HBF technical brief. They remain company targets, not independent measurements from commercial systems.

The brief also says a simulated HBF configuration performed within 2.2 percent of an unlimited-capacity HBM model for one specific test. The workload used eight-bit weights from the Llama 3.1 405B model.

That result needs careful interpretation. Sandisk based it on internal testing and simulation, and the comparison assumed unlimited HBM capacity. Actual products will encounter finite capacity, thermal limits, software behavior, and competing data traffic.

NAND also behaves differently from DRAM. It offers density and non-volatility, but generally carries higher access latency and stricter endurance considerations.

HBF’s larger page size can complicate workloads that request small, scattered pieces of data. Moving unnecessary bytes consumes bandwidth and energy even when the headline transfer rate looks strong.

Read-heavy model inference is a plausible starting point because trained weights change less often than many other data structures. More write-intensive uses would place greater pressure on endurance management.

Packaging presents another test. A 16-die stack requires consistent manufacturing, thermal control, signal integrity, and acceptable production yield.

A design can work in simulation yet become costly when assembled at volume. Defects in one component can affect the economics of an entire advanced package.

The 512GB figure is therefore important, but usable capacity is only one part of the product. Buyers will examine latency distribution, sustained bandwidth, error management, temperature, lifetime, and behavior under mixed workloads.

The three bandwidth grades also create implementation questions. The specification identifies targets, but vendors must show which processors and packages can sustain each grade.

UCIe provides an open interface foundation, not a guarantee that any HBF stack will connect to any accelerator. Compliance programs and reference designs will determine how much interoperability the market actually gets.

This is where Google and Tenstorrent matter. Google brings experience operating large AI services and designing custom accelerators. Tenstorrent can test whether the interface works beyond the dominant GPU model.

Their consortium membership is a positive adoption signal. It is not the same as a purchase commitment, product announcement, or deployment.

The absence of a named shipping processor remains the central verification gap. HBF needs at least one accelerator platform with a controller, package design, software stack, and documented workload benefit.

Without that integration, the standard risks becoming technically interesting but commercially peripheral. The semiconductor industry contains many specifications that never achieved broad production use.

Sandisk and SK hynix improve the odds because their capabilities are complementary. Sandisk contributes NAND design and flash architecture, while SK hynix spans NAND, DRAM, HBM, packaging, and mass production.

Their partnership also reduces the appearance that HBF is merely a proprietary attempt to protect one supplier. OCP publication invites wider review and potential participation.

Still, openness can slow decisions when companies disagree about implementation details. An ecosystem gains reach by accepting more participants, but consensus and compliance work take time.

The specification has cleared the first institutional hurdle. Silicon validation is next, followed by system validation, software support, customer qualification, and production economics.

A headline can treat publication as completion. Hardware markets treat it as the beginning of a longer test.

HBF Complements HBM, and That Tradeoff Defines Its Market

HBF wins only if extra capacity offsets its latency and integration costs without weakening the workloads it is meant to support.

Calling HBF an HBM replacement creates the wrong contest. SK hynix explicitly positions it between HBM and SSDs, with HBM retaining responsibility for the most demanding bandwidth tier.

That distinction protects the architecture from an unrealistic standard. NAND-based HBF does not need to beat DRAM at every operation. It needs to make a larger memory pool useful at acceptable performance.

Sandisk previously said HBF could offer eight to 16 times the capacity of HBM at a similar cost. The current open specification is more restrained, defining configurations and performance grades rather than proving that economic claim.

The capacity comparison will also move over time. HBM suppliers continue increasing stack capacity and bandwidth, so HBF competes against a changing baseline.

HBM benefits from established accelerator support and production demand. Processor roadmaps, packaging investments, memory controllers, and software tools already revolve around it.

HBF starts without that installed base. Its proposed advantage is density, not maturity.

SSDs create pressure from the other side. They cannot match an on-package memory tier, but software and interconnect improvements can make storage more useful for AI workloads.

System designers could decide that enhanced SSD caching provides sufficient performance at lower integration risk. Others could reserve larger HBM pools for premium workloads instead of adding a third tier.

HBF must outperform those alternatives at the complete-system level. A favorable cost per bit does not help if additional controllers, package area, cooling, or software erase the savings.

Energy claims require similar caution. NAND retains information without refresh power, giving it a structural advantage for stored data.

Yet energy use also includes data movement, error correction, controllers, and thermal management. The relevant metric is energy per completed inference, not a component’s isolated power characteristic.

The memory-management layer becomes decisive. Software must identify frequently used data, place it appropriately, and move it before the processor stalls.

This requirement creates opportunities for accelerator vendors and cloud operators. They control scheduling, compiler behavior, model serving, and telemetry that can guide placement.

It also creates lock-in risk. An open physical interface does not ensure that higher-level software remains portable across processors and memory suppliers.

Developers will need tools that expose HBF behavior without forcing every model team to manage pages manually. Otherwise, only the largest infrastructure operators may extract consistent gains.

The first attractive workloads will likely share several characteristics. They will be read-heavy, capacity constrained, tolerant of some extra latency, and important enough to justify specialized hardware.

Large-model serving fits that profile. Retrieval systems, recommendation models, and some multimodal applications could also benefit when active data exceeds practical HBM capacity.

Not every AI task does. Small models that fit comfortably in existing memory gain little from another tier. Latency-sensitive applications with irregular access patterns may prefer HBM despite its capacity limits.

Training presents a harder case because it reads and writes large data structures repeatedly. The initial HBF narrative focuses on inference for good reason.

This tradeoff keeps the announcement grounded. HBF does not erase the memory hierarchy. It adds another level and asks system designers to manage that hierarchy more intelligently.

SK hynix’s broader strategy reinforces this view. The company promotes a portfolio spanning HBM, conventional DRAM, NAND, enterprise SSDs, and emerging memory layers.

That portfolio can reduce internal competition between HBM and HBF. SK hynix can support whichever combination customers select, although individual product economics will still influence its priorities.

Sandisk has a different incentive. Its concentration in flash makes AI inference an opportunity to move NAND closer to high-value computation.

The partnership aligns those incentives around a common standard. It does not eliminate competition from Samsung, Micron, Kioxia, processor vendors, or alternative memory architectures.

Competitor participation would strengthen HBF as an industry category. It could also weaken Sandisk and SK hynix’s ability to differentiate their products.

That is a healthy tension for an open standard. Broad adoption usually requires suppliers to surrender some control in exchange for a larger market.

Three Signals Will Show Whether HBF Moves Beyond the Headline

The next evidence must come from samples, processor commitments, and measured workloads rather than another specification presentation.

The first signal is working HBF silicon tied to the new specification. Sandisk’s earlier roadmap placed initial samples in the second half of 2026, leaving a limited window for execution.

A useful sample announcement should identify capacity, bandwidth grade, package configuration, and testing status. It should also distinguish internal engineering samples from hardware available to customers.

Independent or customer testing would strengthen the case further. Measured latency, sustained bandwidth, power, endurance, and temperature matter more than a peak transfer figure.

If conforming samples appear on schedule, the specification gains credibility as a product foundation. A delay would suggest that packaging, NAND behavior, controllers, or manufacturing remain unresolved.

The second signal is a named processor or cloud platform. Google and Tenstorrent participate in the consortium, but neither participation nor panel appearances confirm commercial adoption.

A serious commitment would connect HBF to a processor roadmap, reference package, development board, or cloud deployment. It would also identify how software assigns data between HBM and HBF.

Watch for controller support and developer tools alongside the hardware. A memory device without scheduling, profiling, and placement software cannot deliver its full system benefit.

One committed platform would not guarantee an industry standard. It would establish that a processor designer sees enough value to absorb the integration cost.

Several processor or cloud participants would support the open-ecosystem thesis. A single proprietary implementation would narrow HBF’s role and increase dependence on one customer.

The third signal is workload evidence under realistic constraints. Sandisk’s simulation offers a starting hypothesis, but production systems must handle finite HBM, mixed requests, thermal limits, and changing access patterns.

Benchmarks should compare complete configurations, not isolated components. An HBF system needs to show throughput, latency, energy, and cost against larger HBM pools or SSD-backed alternatives.

The most informative tests will cover large-model inference with multiple concurrent users. They should also explain model precision, batch size, context length, caching policy, and processor utilization.

A favorable result would show that HBF keeps expensive compute units busy while supporting larger active models. It would strengthen the case for tiered memory as inference scales.

Weak results would expose the cost of NAND latency or data movement. They might confine HBF to narrower uses where capacity matters more than response time.

The specification’s release through OCP gives researchers and potential adopters a shared basis for those evaluations. The open workstream launch also shows that the companies intend to recruit an ecosystem rather than keep HBF closed.

Readers following the story through Google News should separate each future milestone. A consortium member, a sample, an integrated device, and a production deployment represent very different levels of evidence.

Sandisk and SK hynix have completed the first of those stages. They defined an open architecture with clear capacity, bandwidth, interface, packaging, and software targets.

Now the burden moves from the standards document to engineering teams. They must show that HBF can be manufactured reliably, connected across processors, and managed without creating an expensive new bottleneck.

That result matters beyond two memory companies. Successful HBF hardware would give AI system designers another way to balance capacity, bandwidth, energy, and cost.

Failure would still offer a useful lesson. It would show that the gap between HBM and SSDs cannot be closed simply by packaging dense NAND closer to compute.

The next Google News headline worth opening should therefore contain more than another partnership. Look for measurable silicon, a named processor, and a workload result that another organization can scrutinize.

Until those signals arrive, HBF is an unusually detailed proposal with credible sponsors. It is not yet a proven layer in production AI infrastructure.

Follow the samples, integrations, and benchmarks rather than the announcement count. Which processor vendor will be first to show that open HBF can improve a real inference system?