SK hynix Opens HBF to the Industry, but the Real Test Is Hardware

SK hynix has released the first High Bandwidth Flash specification, turning a proposed AI memory layer into an open technical blueprint. The August 4 announcement surfaced widely through Google News, but the important conflict sits beneath the headline. HBF promises capacities up to 512GB and bandwidth reaching 3.0TB/s, yet no commercial HBF system has validated those targets.

The specification, developed with Sandisk through the Open Compute Project, describes NAND flash positioned between High Bandwidth Memory and conventional solid-state drives. It targets AI inference, where accelerators repeatedly read large model weights while serving user requests. Google and AI processor developer Tenstorrent have joined the consortium, giving the effort prospective users beyond its two memory suppliers.

This is not OpenAI announcing a memory technology. “Open” describes the specification and its development model, not the ChatGPT maker. The real contest is between an open, capacity-first memory layer and the established practice of placing models primarily in expensive HBM. SK hynix now has a specification, credible partners, and ambitious targets. It still needs working silicon, accelerator support, and production economics.

SK hynix Turns HBF Into an Open Specification

The release gives system designers a common HBF target, but it does not give them a finished product.

SK hynix and Sandisk introduced the specification as the Future of Memory and Storage conference opened in Santa Clara, California. The event ran from August 4 through August 6, 2026. Their announcement followed roughly six months of standardization work under an Open Compute Project workstream.

The companies had launched that workstream at Sandisk’s Milpitas headquarters on February 25. They initially described HBF as a new layer between HBM and SSD storage. The newly released specification gives that concept defined capacities, performance classes, interfaces, packaging requirements, and reliability guidelines.

The first version covers packages using eight-high or 16-high NAND die configurations. Maximum capacity reaches 512GB per stack. Three performance grades span approximately 0.4TB/s to 3.0TB/s, according to the published announcement and subsequent technical reporting.

The range matters because HBF is not one fixed performance point. Lower grades can emphasize capacity and efficiency, while later implementations can pursue bandwidth closer to advanced HBM. That flexibility also means the 3.0TB/s ceiling should not be mistaken for a shipping first-generation guarantee.

HBF uses NAND flash, the nonvolatile technology found in SSDs, rather than the DRAM used by HBM. Nonvolatile memory retains stored data without continuous power. However, ordinary NAND cannot feed an AI accelerator at anything close to HBM speeds.

HBF addresses that gap by stacking specialized NAND dies and accessing many internal arrays in parallel. A logic base die manages those connections and presents a much wider path to the processor. The resulting package resembles the close-coupled design philosophy of HBM while preserving NAND’s density advantage.

The specification also adopts Universal Chiplet Interconnect Express, or UCIe, for connections between HBF and host processors. UCIe is an open die-to-die interconnect that lets chiplets exchange data inside one package. Its inclusion gives CPU, GPU, and accelerator designers a shared integration path.

The UCIe specification does not make interoperability automatic. Vendors still need controllers, memory management, error handling, packaging, firmware, and software support. It does reduce the risk that each HBF supplier creates an incompatible physical link.

The release through the Open Compute Project is equally important. OCP specifications aim to establish shared requirements that multiple companies can implement. Its contribution framework distinguishes broad base specifications from detailed, manufacturing-ready product documents.

That distinction defines the present state of HBF. SK hynix and Sandisk have moved the idea beyond slides and private discussions. They have not delivered a manufacturing-ready component that server makers can order and qualify.

For readers arriving through Google News, that difference is the first fact to remember. SK hynix unveiled a standard specification, not a commercially available 512GB memory stack. The announcement defines the destination and some of the roads leading there.

Why AI Inference Needs Another Memory Layer

HBF exists because AI inference needs both fast access and much more capacity than HBM economically provides.

Training receives most public attention, but inference turns a trained model into a continuously operated service. During inference, processors repeatedly access model weights, attention data, and cached context. Larger models and longer conversations increase the amount of data that must remain near compute.

HBM serves the fastest portion of that workload. It stacks DRAM dies beside an accelerator and connects them through a wide interface. That design provides exceptional bandwidth and low latency, but capacity remains limited and manufacturing is complex.

SSDs solve the capacity problem at a lower cost per bit. However, data must travel through storage controllers and interfaces before reaching the accelerator. That path introduces latency and provides much less bandwidth than package-level memory.

System builders therefore face an uncomfortable choice. They can purchase more HBM-equipped accelerators to hold a large model, even when compute resources remain underused. Alternatively, they can move model data from SSDs and accept slower responses.

HBF attempts to create a third option. It places hundreds of gigabytes of persistent NAND much closer to the processor and accesses that NAND through highly parallel channels. Frequently changing data can remain in HBM, while larger weight sets can sit in HBF.

This approach is particularly relevant to mixture-of-experts models. Such models contain many specialized parameter groups but activate only a subset for each token. Their total capacity requirement can be enormous, even when each inference step touches a smaller working set.

A capacity-first tier could hold more experts near each accelerator. Software would move active data into HBM or access it directly from HBF, depending on the eventual architecture. Either method could reduce transfers from remote SSDs and lower the number of accelerators needed solely for memory capacity.

Sandisk previously modeled HBF using Meta’s Llama 3.1 405B model. The company said simulated weight-reading performance came within 2.2 percent of a hypothetical system with unlimited HBM capacity. That result remains a company simulation, not an independent production benchmark.

Its HBF architecture analysis also described a 16-die stack holding 512GB. Sandisk said the design could closely match HBM4’s footprint, stack height, and power profile. Those are development targets until physical products undergo testing.

The comparison should not imply that NAND has become DRAM. HBM retains fundamental latency and endurance advantages. HBF is intended to complement HBM for read-heavy inference workloads, not replace every byte of accelerator memory.

That positioning separates the announcement from another faster-SSD story. HBF moves flash into the processor package and exposes it through a memory-oriented interface. The architecture changes where data sits, how processors reach it, and how systems divide work across memory tiers.

It could also affect AI service costs. If one accelerator can address substantially more model data, operators may need fewer replicated systems for capacity-bound workloads. That would matter when memory capacity, rather than arithmetic throughput, determines server count.

The opportunity extends beyond frontier models. Retrieval systems, recommendation engines, and vector search workloads maintain large collections of data that processors read repeatedly. Edge systems could also keep larger models locally without relying on constant transfers from slower storage.

None of those scenarios is guaranteed. Software must place data intelligently across HBM, HBF, and SSDs. Workloads with frequent writes or strict latency requirements may remain poor fits. HBF’s value depends on matching the right data to the right tier.

The Main Contest Is HBF Capacity Against HBM Dependence

SK hynix is not trying to beat HBM at every task; it is challenging the assumption that inference must fit primarily inside HBM.

That distinction makes the HBF proposal more credible. A direct NAND-versus-DRAM contest would expose NAND’s latency and endurance limitations. A tiered design instead asks whether every model weight deserves space in the fastest and most expensive memory.

Under the initial specification, one HBF stack can hold up to 512GB. Current HBM stacks provide far less capacity, even as new generations increase density. HBF can therefore place a much larger persistent data pool beside the accelerator.

The highest HBF performance class reaches a stated 3.0TB/s. That figure enters the bandwidth territory associated with individual next-generation HBM stacks. However, the specification covers a wide range beginning near 0.4TB/s, and bandwidth alone does not reveal access latency.

A processor can also use several HBM stacks simultaneously. Comparing one HBF stack with one HBM stack does not describe the bandwidth of an entire accelerator. Real systems will probably combine both technologies and assign each a different role.

The open specification pressures more than HBM suppliers. It also challenges accelerator vendors that control tightly integrated memory systems. Nvidia, AMD, Google, and other chip designers must decide whether HBF adds enough value to justify new controllers, packages, and software.

Google’s participation gives the consortium an important source of workload knowledge. Google operates large AI services and designs its own Tensor Processing Units. Its involvement signals that at least one hyperscale operator sees value in exploring a capacity-rich memory tier.

It does not confirm adoption in a future TPU. The consortium announcement contains no Google product commitment, deployment schedule, or purchase volume. Participation can influence a standard without producing a commercial device.

Tenstorrent brings a different perspective. The company develops AI processors and uses chiplet-oriented, open architecture strategies. HBF connected through UCIe aligns with that approach, although Tenstorrent has not announced a shipping processor containing HBF.

The companies absent from the announcement matter as much as those present. Nvidia, AMD, Intel, Micron, Samsung, Kioxia, Broadcom, Marvell, and Qualcomm were not identified as participants. Their eventual support would expand the supplier and processor ecosystem.

An open specification can lower adoption barriers, but it also changes competitive dynamics. SK hynix and Sandisk are sharing enough of the interface to encourage other implementations. If HBF succeeds, competitors could enter and push prices or margins lower.

That is the necessary trade for becoming a standard. A proprietary interface can protect one supplier but struggle to gain broad processor support. An open interface can attract adoption while moving competition toward manufacturing, packaging, yield, and controller quality.

SK hynix understands both sides of that calculation. The company became a major force in AI memory through HBM manufacturing and close accelerator partnerships. With HBF, it can connect its DRAM expertise, NAND portfolio, and advanced packaging capabilities.

Sandisk contributes the original HBF concept and NAND process technology. Its 2025 standardization agreement targeted comparable HBM bandwidth with eight to 16 times more capacity. It also set an initial sampling roadmap.

The partnership therefore combines complementary incentives. Sandisk wants flash to move closer to AI compute. SK hynix wants to supply more of the memory hierarchy rather than protecting HBM as the only premium layer.

This is why the story is larger than its Google News framing. The first specification creates a venue where memory makers, processor designers, and cloud operators can negotiate a shared architecture. The winner will not be determined by the document alone.

The Specification Still Has a Hardware Credibility Gap

HBF’s largest risk is simple: its most attractive numbers describe a specification and vendor projections, not qualified production silicon.

Delivering 512GB in a dense stack introduces manufacturing challenges. Sixteen specialized NAND dies must connect reliably through advanced packaging. The stack needs acceptable thermal behavior, manageable warpage, sufficient yield, and a logic die capable of coordinating massive parallelism.

Bandwidth creates another challenge. NAND arrays must operate concurrently to approach the proposed performance classes. The controller must schedule reads, correct errors, manage bad blocks, and maintain predictable service under demanding workloads.

Latency remains less clearly defined than bandwidth. A 3.0TB/s peak rate says how much data can move under favorable conditions. It does not say how quickly a small request returns or how performance changes under irregular access patterns.

AI inference often streams large model weights, which suits flash better than random transactional writes. However, attention caches and other runtime state can change rapidly. Those structures may still require HBM or conventional DRAM.

Endurance also needs field evidence. HBF is based on NAND, which supports a finite number of program and erase cycles. Read-heavy model storage reduces that concern, but production systems still need updates, rebalancing, and fault recovery.

Power claims need independent validation as well. NAND retains data without refresh power, giving it a theoretical advantage over DRAM. Yet the base die, wide interface, error correction, and parallel array access all consume energy.

Sandisk’s earlier fact sheet described a first-generation target of 1.6TB/s and 512GB in a 16-die stack. It also claimed one of the lowest costs per bit among memory technologies. Neither SK hynix nor Sandisk has published a final commercial price or verified total system cost.

The economics will include more than NAND dies. Advanced packaging, the controller base die, UCIe integration, cooling, board design, and software development all add costs. Yield losses become especially important in tall stacks containing many components.

The specification’s broad 0.4TB/s to 3.0TB/s range creates another uncertainty. It can support several product generations, but it makes general claims about “HBF performance” less useful. Buyers will need to examine the grade, capacity, latency, endurance, and power of each implementation.

There is also an adoption loop. Memory suppliers need processor commitments before investing heavily in production. Processor vendors want reliable samples and multiple suppliers before redesigning packages. Cloud operators want tested systems before rewriting memory management software.

Open standards can break that loop by giving every participant a stable target. They cannot remove the financial risk. The HBF consortium must convert interest into reference designs, controllers, validation tools, and purchase commitments.

The most favorable public roadmap came from Sandisk in 2025. It targeted first HBF memory samples during the second half of 2026. It expected samples of AI inference devices using HBF in early 2027.

The sampling roadmap has not become a volume-production schedule. Samples allow partners to test feasibility. They do not establish yield, availability, or data-center reliability.

That gap should shape how readers interpret the announcement. SK hynix did not prove that HBF resolves the inference memory wall. It published a detailed proposal for building and connecting the relevant hardware.

The strongest skeptical view is not that HBF lacks a useful purpose. The memory-capacity problem is real, and tiered architectures are an established engineering response. The concern is whether this particular implementation can deliver enough benefit after latency, packaging, software, and cost are counted.

Open HBF Puts Pressure on the Wider Memory Market

The specification forces memory and accelerator companies to respond, even if they decide not to adopt HBF.

Samsung and Micron compete directly with SK hynix in HBM. Kioxia competes in NAND and shares manufacturing ties with Sandisk. Each now faces a choice between participating, developing a compatible implementation, or promoting a different answer.

Joining would strengthen HBF’s legitimacy but expose participants to a standard shaped initially by SK hynix and Sandisk. Remaining outside preserves strategic independence but risks letting two competitors define an emerging interface.

Accelerator vendors face a similar calculation. A capacity-rich flash tier could let them support larger models without adding equivalent HBM capacity. It could also complicate package design and weaken the simplicity of their existing memory architecture.

Nvidia’s position deserves particular attention because its accelerators anchor much of the current AI infrastructure market. Nvidia has not announced HBF adoption. Without support from leading accelerator platforms, HBF could remain limited to custom silicon and specialized inference systems.

Google’s participation partially offsets that risk. A hyperscaler with custom processors can adopt a new memory architecture without waiting for a merchant GPU roadmap. A successful internal deployment could provide technical evidence and meaningful volume.

Tenstorrent can test whether the open interface works for a smaller processor ecosystem. Its participation also broadens the consortium beyond established memory and cloud companies. However, neither participant currently guarantees mass-market acceptance.

The HBF effort follows an established pattern in data-center hardware. A few companies define a common interface, publish it through an industry organization, and recruit users before products mature. Success depends on whether competitors perceive interoperability as more valuable than control.

HBM followed a different institutional path through JEDEC standards and close coordination among memory suppliers and processor designers. HBF’s OCP route puts cloud operators and system architects closer to the specification process.

That approach fits the intended workload. AI inference infrastructure spans processors, memory, storage, networking, orchestration, and application software. Optimizing only the memory component would miss important system bottlenecks.

A 512GB HBF stack cannot improve performance when software repeatedly requests tiny, scattered blocks. It becomes more useful when compilers and runtimes arrange weights for long sequential reads. System architecture determines whether the advertised bandwidth becomes productive work.

Developers may therefore encounter HBF through software before they touch hardware specifications. Frameworks will need allocation policies, profiling tools, and placement controls. Operators will need observability across HBM, HBF, and SSD tiers.

This resembles the broader work of managing information by relevance and access frequency. A searchable knowledge base also separates active context from larger retained collections. HBF applies a related hierarchy to machine data at hardware speed.

The analogy has limits, but the principle is useful. The fastest resource remains scarce. Systems improve when they keep immediately needed information close and move less urgent material into a larger supporting layer.

That is HBF’s strategic argument. It does not need to replace HBM to become important. It needs to make HBM capacity less decisive for a meaningful set of inference workloads.

What to Watch After the Google News Headlines Fade

Three signals will determine whether HBF becomes an AI memory standard or remains an ambitious paper architecture.

The first signal is physical sample delivery. Sandisk’s public roadmap targeted HBF memory samples in the second half of 2026. Working packages would let partners measure latency, sustained bandwidth, endurance, thermals, and power under repeatable conditions.

Results near the stated performance classes would strengthen the case that massively parallel NAND can serve as near-processor memory. Delays or large gaps between peak and sustained performance would weaken the specification’s capacity-first argument.

The most useful benchmark would compare complete systems, not isolated packages. It should measure tokens per second, time to first token, energy per token, and total server cost. It should also disclose how much data remains in HBM.

The second signal is a named processor design. Google and Tenstorrent have joined the consortium, but neither has announced a production accelerator with HBF. A concrete chip, package, or reference platform would show that integration work has moved beyond advisory participation.

An early 2027 inference-device sample, matching Sandisk’s earlier schedule, would support the consortium’s execution claims. Silence from processor partners would suggest that packaging or software work remains unresolved.

Nvidia, AMD, or another merchant accelerator vendor joining would be especially significant. Their participation would expand HBF beyond custom systems and improve its chances of attracting multiple memory suppliers.

The third signal is wider supplier and software support. An open standard becomes resilient when independent companies can build compatible components. Samsung, Micron, Kioxia, controller vendors, packaging companies, and cloud operators are therefore critical.

Software support matters just as much. AI frameworks must recognize HBF as a distinct tier and place data according to access patterns. Without that layer, developers would face manual tuning and inconsistent performance.

SK hynix’s August announcement establishes an important checkpoint. The company and Sandisk have defined capacities, performance grades, stack configurations, connectivity, and reliability goals. Google and Tenstorrent have added credible industry participation.

The announcement does not settle the harder questions. No public production system has shown the claimed balance of capacity, bandwidth, latency, power, and cost. No leading merchant accelerator has committed to the interface.

Readers following the story through Google News should watch those three signals rather than another round of theoretical comparisons. Look for measured silicon, a named accelerator, and additional independent implementers.

If all three appear, HBF can become a practical complement to HBM and SSDs. If only specifications and simulations accumulate, the industry will continue addressing inference capacity through more HBM, conventional storage, and software optimization.

The next decisive headline should therefore contain a product name and measured workload results. Until then, SK hynix has opened a promising route through the AI memory wall, but the hardware has not crossed it.