SK hynix Sets the First HBF Standard, and the Google Hynix Link Raises the Stakes

SK hynix has released the first High Bandwidth Flash specification, only six months after starting its standardization consortium with Sandisk. The google hynix connection adds an important customer-side voice, because Google is now participating alongside AI processor developer Tenstorrent.

The specification defines HBF capacities up to 512GB and bandwidth grades ranging from about 0.4TB/s to 3.0TB/s. HBF is flash memory packaged for much faster processor access than a conventional solid-state drive. It is meant to complement high-bandwidth memory, not replace it across every workload.

That distinction creates the real tension. HBM provides the speed that modern accelerators need, but its capacity, power, packaging, and supply constraints shape entire AI systems. SK hynix and Sandisk are proposing another tier for data that needs high bandwidth without occupying scarce HBM capacity.

Google’s presence gives that proposal more credibility, but participation is not deployment. The consortium still needs working silicon, dependable software, and evidence that NAND latency and endurance fit production inference. Those tests will determine whether HBF becomes infrastructure or remains an attractive specification.

SK hynix Turns HBF From a Proposal Into an Open Specification

The first specification gives processor designers a shared technical target, but it does not yet establish a commercial product.

SK hynix announced the specification on August 4, during the opening of FMS 2026 in Santa Clara, California. The conference runs through August 6 and brings together memory, storage, processor, and data-center companies.

The release follows a standardization effort started with Sandisk in February 2026. That initiative itself followed an initial partnership between the companies in August 2025. Moving from a partnership to a published specification within six months is unusually quick for a new memory category.

According to the HBF specifications, the design supports 8-high and 16-high NAND die stacks. Its capacity ceiling reaches 512GB, while three performance grades span roughly 0.4TB/s to 3.0TB/s.

These ranges matter because HBF is not presented as one fixed product. The grades allow designers to balance bandwidth, capacity, packaging complexity, and system requirements. A deployment optimized for model weights may need a different configuration from one serving retrieval data.

The standard also adopts UCIe, or Universal Chiplet Interconnect Express. UCIe is an open interface for connecting different semiconductor chiplets inside one package or system.

Using UCIe should reduce dependence on a proprietary processor link. In principle, HBF could connect with different CPUs, GPUs, and AI accelerators that support compatible implementations. That flexibility is essential if HBF is supposed to become an industry tier.

The document also covers electrical characteristics, die-stack reliability, packaging, and software input-output guidance. Those details move the project beyond a concept diagram. They give memory suppliers, processor companies, and software developers common engineering boundaries.

SK hynix and Sandisk disclosed the specification through the Open Compute Project. The standardization launch created a dedicated OCP workstream rather than a closed bilateral format.

That choice matters for adoption. A processor company will resist designing around a memory tier controlled by one supplier. An open specification offers a clearer route to multiple implementations, broader tooling, and shared software support.

However, openness does not guarantee interoperability. Vendors still need to turn specifications into compatible controllers, packages, firmware, and runtime behavior. Certification and reference implementations will matter as much as the document itself.

The first HBF standard therefore changes the discussion without settling it. The industry now has a defined architecture to evaluate. It does not yet have production evidence showing that architecture delivers its promised economics.

Why the Google Hynix Connection Matters for AI Inference

Google’s participation signals that HBF is being shaped with hyperscale workloads in view, not only by companies seeking another NAND market.

SK hynix says Google and Tenstorrent are participating in the consortium. Google DeepMind Senior Staff Engineer Xiaoyu Ma is also scheduled to join an August 6 panel with executives from SK hynix and Sandisk.

The panel title, “Breaking the Memory Wall with High Bandwidth Flash,” identifies the target problem. AI processors can perform calculations quickly, but performance suffers when useful data cannot reach them at a matching rate.

Inference makes that problem harder. Training builds a model, while inference runs the model to answer requests. Production systems repeatedly move model weights, attention data, embeddings, and cached context through constrained memory hierarchies.

Longer context windows add pressure through the key-value cache. A KV cache stores intermediate attention data so a model does not recompute earlier tokens during generation. Its size grows as requests become longer or more numerous.

Agentic systems can compound the issue. An AI agent may plan, call tools, inspect files, retrieve records, and preserve state across many steps. Each activity adds data movement and can keep a request active longer.

SK hynix Executive Vice President Kim Chun-sung and Vice President Kang Uk-song are presenting tiered memory as the answer. Tiered memory places data in several memory types according to speed, capacity, cost, and access patterns.

Under that model, HBM remains closest to the accelerator for the hottest data. HBF holds larger, mostly read-oriented data sets that still require substantial bandwidth. Conventional SSDs provide another, slower level with greater distance and capacity.

The google hynix relationship matters because Google operates AI services and develops its own tensor processing units. Its engineers can evaluate the proposal against real accelerator, compiler, model, and data-center requirements.

That does not mean Google has committed to buying SK hynix HBF. The official announcement identifies consortium participation, not a supply contract or deployment schedule. It also does not identify which Google systems might use the technology.

Even so, customer-side involvement can prevent a standard from reflecting only a memory supplier’s priorities. Hyperscalers care about failure handling, fleet management, software portability, repairability, and total system utilization.

Tenstorrent adds a different perspective. It develops AI processors and RISC-V technology outside the dominant GPU architecture. Its participation supports the consortium’s claim that HBF should work across processor types.

Together, Google and Tenstorrent broaden the project beyond SK hynix and Sandisk. One represents hyperscale AI operations, while the other represents alternative accelerator design. Both can expose assumptions that memory vendors might otherwise miss.

The important signal is architectural interest, not endorsement of finished hardware. HBF now has participants capable of testing whether its interface matches actual inference systems. Their continued involvement will be more meaningful than their names on the launch announcement.

HBF Creates a New Tier Instead of Replacing HBM

The central mechanism is data placement: HBF only works if systems keep latency-sensitive data in HBM and move suitable data into flash.

HBM uses stacked DRAM dies and wide interfaces to provide very high bandwidth near a processor. HBF borrows the stacked, wide-interface idea but uses NAND flash for greater capacity and persistent storage.

NAND retains data without power and offers much greater density than DRAM. It also has higher read latency, slower writes, and limited program-erase endurance. Those differences prevent HBF from acting like a simple HBM substitute.

The 3.0TB/s upper grade is therefore only one part of the performance story. Peak bandwidth describes how much data can move under favorable conditions. It does not capture the delay before small or irregular reads return.

That gap is important for AI workloads. Model weights are generally read repeatedly and change infrequently during inference, which suits flash better. KV caches receive ongoing writes, making them a harder fit.

A June 2026 research paper asked whether high-bandwidth flash was sufficient as the second memory tier. The authors’ memory-tier analysis modeled HBF against on-package LPDDR and coherent attached memory.

Their model found that different properties dominated different workloads. Capacity reduced the number of model replicas, bandwidth affected data delivery, and write support determined whether a tier could absorb KV-cache traffic.

The paper also modeled about 20 microseconds of NAND read latency. That delay reduced effective bandwidth for scattered, small accesses, even when nominal HBF bandwidth was high.

The research was analytical rather than a measurement of commercial HBF silicon. Its assumptions should not be treated as a verdict on SK hynix hardware. Still, it identifies a credible pressure test for the architecture.

Another July paper proposed FlashAccel, an architecture for using HBF during large-model inference. The FlashAccel study focused on higher-capacity flash while addressing low bandwidth utilization and write limitations.

These studies point toward software as the hidden requirement. A runtime must identify hot and cold data, predict access patterns, and move information without stalling the accelerator.

That process cannot add excessive copying. Moving the same data repeatedly between SSD, HBF, and HBM would consume bandwidth and energy. Poor placement could erase the capacity advantage.

The processor link also needs to preserve useful throughput under realistic access patterns. UCIe provides a common interconnect foundation, but controllers and software determine how applications experience the tier.

HBF’s strongest early use may involve model weights, retrieval indexes, or relatively stable expert parameters. These data sets can be large, heavily read, and less write-intensive than active KV caches.

Mixture-of-experts models offer a clear example. Such models activate selected expert components for each token rather than using every parameter. Less frequently used experts might sit in HBF until the runtime needs them.

This arrangement could let a system keep a larger model close to each accelerator. It might reduce transfers from remote storage or reduce the number of devices needed to hold model weights.

However, an expert selected at unpredictable times creates irregular reads. NAND latency then becomes important, even when aggregate bandwidth looks adequate. Prefetching can help only when software predicts demand accurately.

HBF also creates packaging and thermal questions. Stacked NAND, controller logic, links, and nearby accelerators all produce heat. The standard includes packaging and reliability guidance, but implementations must validate those limits.

SK hynix describes HBF as a bridge between HBM and SSDs. That is the right conceptual frame. Its value depends on filling the gap without inheriting too many weaknesses from either side.

The First Standard Still Faces a Silicon Reality Check

HBF’s largest uncertainty is whether real systems can turn impressive capacity and bandwidth specifications into predictable application performance.

The FMS announcement contains no independently measured HBF benchmark. It does not report latency, endurance, application throughput, error rates, thermal limits, or power consumption for commercial hardware.

It also does not name a production date for SK hynix HBF. Sandisk previously indicated that initial HBF samples were planned for 2026, followed by devices integrating HBF for AI inference in early 2027.

Roadmaps can change. Manufacturing stacked NAND with a high-speed logic interface requires yield, packaging, controller, and thermal work. A standard can align interfaces without solving those production challenges.

Workload suitability presents another risk. Flash favors reads and persistent data, while inference systems increasingly create large dynamic caches. If HBF cannot accept enough writes, architects need another tier for that traffic.

That does not make HBF irrelevant. It narrows the jobs it can perform efficiently. The design may excel with weights and indexes while performing poorly with rapidly changing state.

Software maturity is another constraint. Accelerators already depend on complex runtimes for memory allocation, batching, caching, quantization, and scheduling. Adding HBF introduces another placement decision into that stack.

Developers will need visibility into where data resides and why it moves. Otherwise, a model can meet laboratory throughput targets while producing unstable tail latency in production.

Tail latency measures the slowest portion of requests rather than the average. It matters because a few delayed memory fetches can violate an interactive service’s response target.

The standard’s three bandwidth grades could also fragment performance expectations. A system designed around Grade 3 behavior might not translate cleanly to a lower grade. Software needs dependable capability discovery and fallback behavior.

Interoperability remains unproven as well. An open interface should allow several processor and memory combinations. Actual compatibility will depend on electrical behavior, firmware, packaging, and error-management details.

Google’s involvement does not remove these risks. The google hynix link increases confidence that relevant questions are entering the design process. It does not provide a public benchmark or deployment commitment.

Competition will pressure the HBF approach from several directions. Samsung, Micron, and other memory producers can expand HBM capacity or develop alternative stacked-flash designs. CXL-attached memory can provide another capacity tier.

LPDDR placed near an accelerator offers lower latency and full writability, though with different density and power tradeoffs. Direct GPU-to-storage technologies can also improve access to conventional SSDs without creating HBF.

These approaches are not mutually exclusive. A future server could use HBM, LPDDR, HBF, CXL memory, and SSDs together. That flexibility also raises complexity and makes each additional tier justify its cost.

The most credible case for HBF will not come from a peak specification alone. It will come from lower system cost, better energy efficiency, or greater throughput under a defined production workload.

Independent results should compare complete systems, not isolated memory devices. Useful measurements include tokens per second, time to first token, tail latency, energy per token, and accelerator utilization.

Reliability results will matter too. Data centers need predictable error correction, component lifetimes, service procedures, and failure isolation. A persistent memory tier near expensive processors cannot become an operational weak point.

SK hynix says HBF will expand the boundary between memory and storage. That framing is reasonable, but the boundary exists because the technologies behave differently. Engineering cannot erase those differences through naming.

SK hynix Pairs HBF With 375-Layer NAND

The FMS display links the HBF standard to a broader effort to make NAND more useful inside power-constrained AI infrastructure.

SK hynix is also showing its tenth-generation, 375-layer 4D NAND wafer and related products for the first time. The technology remains under development.

The company says the new NAND improves performance per watt by 2.5 times compared with its previous generation. That figure is a company claim and has not received independent validation in the announcement.

SK hynix plans to begin mass production of enterprise SSDs using the NAND in early 2027. The company is positioning those drives for high-performance, high-capacity data-center workloads.

The NAND announcement supports the HBF narrative without proving HBF performance. Both products respond to the same infrastructure pressure: AI systems need more accessible data without unlimited electricity.

Higher-density NAND can increase capacity within a fixed physical footprint. Better performance per watt can also reduce the power spent moving data through storage systems.

Those improvements matter because AI infrastructure is increasingly constrained at the system level. A faster accelerator provides little value when memory, storage, networking, cooling, or power delivery prevents full utilization.

SK hynix is therefore presenting a portfolio rather than one universal memory. Its tiered-memory message spans fast DRAM, stacked HBM, HBF, and enterprise SSDs.

This strategy reflects a practical truth. No single medium provides the lowest latency, highest capacity, strongest endurance, lowest power, and lowest cost simultaneously.

The engineering task is to place each data set in the least expensive tier that still meets its performance target. That principle sounds simple, but workloads change from request to request.

For example, a retrieval system might store billions of vectors representing documents or images. Frequently accessed index segments could remain in faster memory, while colder segments move into HBF or SSDs.

A large inference service might keep active model layers in HBM. Less frequently selected expert weights could reside in HBF, with conventional storage holding full checkpoints and historical versions.

An agent working across enterprise documents creates another possible workload. The system needs model weights, retrieval indexes, tool state, and user context, but those data sets have different access patterns.

Knowledge workers will not interact with HBF directly. They will notice its effect only if services support longer context, larger local indexes, steadier response times, or lower resource use.

Engineering teams will face the integration burden. They must trace memory behavior, tune placement policies, and preserve documentation across hardware and software changes. A searchable engineering knowledge base can help teams retain those decisions.

The broader portfolio also protects SK hynix from a binary HBF outcome. If HBF adoption takes longer, demand for HBM and enterprise SSDs can still grow with AI infrastructure.

However, that portfolio creates a strategic balancing act. HBF must offer enough value to attract customers without simply moving revenue from existing memory products.

Sandisk faces a related challenge from the NAND side. HBF can create a higher-value use for flash, but success requires processor and software partners that storage vendors cannot command alone.

This is why the open standard and consortium participation matter together. The memory suppliers define manufacturable devices, while processor and cloud participants shape a system that can use them.

Three Signals Will Show Whether HBF Is Becoming Real Infrastructure

The next phase must replace consortium momentum with hardware evidence, software support, and repeatable deployments.

The first signal is working HBF silicon measured under production-like inference workloads. Samples should disclose more than peak bandwidth. Latency, endurance, power, thermals, and effective throughput need equal attention.

A sample that sustains useful performance for read-heavy model weights would strengthen the case. Large gaps between nominal and effective bandwidth would weaken it, especially under irregular access.

The second signal is software integration. Major inference runtimes need policies for placing weights, caches, indexes, and intermediate data across HBM, HBF, and storage.

Useful integration should expose metrics and controls rather than hiding every placement decision. Operators need to diagnose page movement, stalls, write pressure, and capacity use.

Support from Google or Tenstorrent software would make the google hynix relationship more concrete. Public code, reference designs, conference results, or documented compatibility would carry more weight than consortium membership alone.

The third signal is broader implementation of the open standard. Additional memory suppliers, processor vendors, or cloud operators would reduce dependence on the two founding companies.

Multiple interoperable products would show that OCP disclosure created a genuine industry interface. Incompatible vendor variants would instead suggest that the standard lacks enough precision or commercial alignment.

FMS 2026 marks the beginning of that validation period, not its conclusion. SK hynix and Sandisk have defined a plausible new memory tier and attracted relevant participants.

They have not yet shown that HBF handles real inference traffic better than competing combinations of HBM, LPDDR, CXL memory, and SSDs. That result must come from systems, not specifications.

For developers and enterprise buyers, the immediate action is to watch workload evidence closely. Ask where model weights, KV caches, and retrieval indexes reside during each benchmark.

Also ask whether reported gains include the full system’s power, software, and hardware costs. A faster memory component does not guarantee a more efficient service.

The first HBF standard makes those tests possible. The coming samples will decide whether the Google, Sandisk, and SK hynix effort becomes a new infrastructure layer or an ambitious specification.