Sandisk and SK hynix’s HBF Standard Claim Still Needs Proof

Sandisk and SK hynix reached Google News with a striking claim: the partners released the first Open Compute Project specification for High Bandwidth Flash.

The headline sounds like a decisive step toward an industry standard. Yet the companies’ accessible announcements describe an OCP workstream and the start of standardization, not a completed specification.

That distinction matters because High Bandwidth Flash, or HBF, is still a proposed memory class rather than a widely tested commercial product. HBF places stacked NAND flash near AI processors, seeking greater capacity than high-bandwidth memory while offering more bandwidth than conventional storage.

The central contest is not simply Sandisk against another memory manufacturer. It is HBF’s promise of abundant inference memory against the latency, endurance, software, and manufacturing advantages of established HBM systems.

Sandisk supplies deep NAND and wafer-bonding experience. SK hynix brings HBM design, packaging, and high-volume manufacturing expertise. Their cooperation gives HBF more credibility, but partnership announcements cannot substitute for interoperable hardware or an approved public standard.

The resulting story is more consequential than an ordinary specification update. It tests whether AI infrastructure can add a practical memory tier between expensive HBM and comparatively distant SSD storage.

What Google News Does and Does Not Confirm

The confirmed event is an organized standardization effort, while the claimed release of a finished OCP specification remains difficult to verify publicly.

On February 25, 2026, Sandisk and SK hynix held an HBF standardization kickoff at Sandisk’s headquarters in Milpitas, California. Both companies said they would form a dedicated workstream under the Open Compute Project.

Their stated goal is to develop HBF as an industry standard for AI inference infrastructure. The workstream provides a forum for defining technical requirements and encouraging participation beyond the two founding companies.

That is meaningful progress. An OCP workstream can expose a proposal to system builders, chip designers, cloud operators, and other memory suppliers before products become fixed.

However, starting that process differs from releasing an approved technical specification. SK hynix’s HBF standardization announcement says the partners would launch the workstream and begin standardization work.

Sandisk’s corresponding OCP initiative also presents the event as a beginning. It does not identify a final specification version, approval date, public document number, or compliance program.

Those missing details create a verification gap around the headline circulating through Google News. An aggregation appearance confirms that publishers carried the claim, not that OCP completed its technical review.

A released specification normally leaves a clearer trail. Readers should expect a document title, version number, revision history, governance status, and downloadable technical content.

A mature standard also defines what independent vendors must implement. That could include electrical interfaces, command behavior, packaging dimensions, thermal limits, reliability targets, and interoperability rules.

None of this means the reported specification is necessarily fictitious. A preliminary contribution, draft, or newly submitted document might exist without being easily indexed.

The cautious conclusion is narrower. Publicly accessible first-party materials confirm the workstream, but they do not independently establish a completed OCP specification.

That gap should shape the article’s interpretation. The important change is that two major memory companies are placing HBF inside a recognized open-infrastructure process.

The unresolved question is how far that process has progressed. Until OCP publishes identifiable documentation, “first specification” should be treated as a reported claim rather than a settled milestone.

Why AI Inference Needs Another Memory Tier

HBF targets the widening space between fast, capacity-constrained HBM and large SSDs that sit too far from accelerators.

AI inference repeatedly reads model weights and temporary attention data while generating responses. Large models can therefore demand both high capacity and sustained movement of data into processors.

HBM handles this job well because it places vertically stacked DRAM close to an accelerator. Wide interfaces move data faster than conventional server memory can manage.

The tradeoff is capacity, manufacturing complexity, and limited package space. Adding more HBM stacks raises system costs and consumes valuable area around the processor.

Enterprise SSDs provide far more capacity, but their block-oriented interfaces and storage paths add latency. They cannot simply behave like HBM beside a GPU.

HBF proposes a middle tier. It stacks NAND flash using packaging concepts associated with HBM, then connects that capacity through a wide, high-bandwidth path.

Sandisk’s published HBF fact sheet describes a first-generation target of 1.6 terabytes per second. It also lists 256 gigabits per die and 512 gigabytes in a 16-die stack.

Those figures are company targets, not independent benchmark results. They nevertheless explain why infrastructure designers are interested.

A 512-gigabyte HBF stack would hold substantially more data than a typical HBM package. Multiple stacks could keep larger model components near accelerators instead of fetching them repeatedly from SSDs.

The design is especially relevant to inference because many deployments perform far more reads than writes. NAND tolerates limited program and erase cycles, but read-heavy model-serving workloads can reduce that disadvantage.

Useful applications could include storing model weights, retrieval indexes, or portions of the key-value cache. A key-value cache stores attention data created while a model processes and generates a sequence.

None of those uses makes HBF equivalent to HBM. NAND has higher access latency than DRAM, so software must place data according to workload behavior.

Frequently accessed information would remain in HBM. Larger or less latency-sensitive data could move into HBF, while SSDs retain colder datasets and durable storage.

This tiered arrangement shifts complexity rather than removing it. Accelerators, compilers, operating systems, and serving frameworks must know where data belongs and when it should move.

The mechanism resembles a memory hierarchy more than a direct replacement. Processors already use registers, caches, system memory, and storage because no single technology optimizes every requirement.

HBF extends that hierarchy closer to the accelerator. Its value depends on keeping enough useful data nearby without exposing NAND’s latency at critical execution moments.

The timing also reflects a change in AI infrastructure priorities. Training dominated the first wave of accelerator spending, while inference is becoming a larger operational burden.

Training often rewards maximum bandwidth for a scheduled job. Inference must balance latency, capacity, utilization, and power across repeated requests.

Larger context windows increase that pressure. So do mixture-of-experts models, which activate selected model components but still require systems to store and retrieve extensive weights.

Sandisk started presenting HBF publicly in 2025. Its August 2025 collaboration agreement said first memory samples were targeted for the second half of 2026.

The same announcement targeted samples of initial HBF-equipped inference devices for early 2027. Those dates remain targets until customers receive and validate working hardware.

That schedule makes standardization urgent. Vendors need stable assumptions before committing accelerator interfaces, packages, controllers, cooling systems, and software to an unfamiliar memory tier.

HBF’s Real Opponent Is the Existing HBM System

Sandisk and SK hynix must prove that extra NAND capacity offsets the cost of adding latency, software complexity, and another package technology.

HBF is often described as an HBM alternative, but that framing oversimplifies the competitive position. Initial HBF systems are more likely to complement HBM than eliminate it.

HBM provides low-latency, high-throughput working memory for accelerators. HBF seeks to hold larger read-heavy datasets near the same compute resources.

That creates a demanding benchmark. HBF does not merely need to outperform an SSD. It must improve complete inference systems enough to justify redesigning them.

The relevant metric is not peak bandwidth alone. Operators care about tokens per second, time to first token, concurrent users, energy consumption, accelerator utilization, and total system cost.

A high headline bandwidth can coexist with poor application performance. Random accesses, controller overhead, data movement, and cache misses can determine actual results.

Sandisk says its CMOS directly Bonded to Array technology connects control circuitry directly to a NAND array. The approach seeks shorter data paths and greater parallelism than a conventional SSD controller provides.

SK hynix contributes experience with through-silicon vias, stack assembly, thermal management, and HBM production. That packaging knowledge addresses a different part of the problem.

The partnership is therefore complementary. Sandisk understands high-density flash, while SK hynix operates at the center of the current HBM market.

It also creates an unusual strategic tension. SK hynix benefits from strong HBM demand, yet it is helping develop a technology positioned below HBM in the memory hierarchy.

The apparent contradiction makes sense if HBF expands the overall market. SK hynix can protect its HBM role while participating in a second tier that might otherwise develop without it.

This is not necessarily a zero-sum contest. An inference accelerator could use HBM for active computation and HBF for model capacity, increasing demand for both.

The harder competition concerns system architecture. Current AI servers already connect accelerators to HBM, host DRAM, NVMe storage, and networked storage.

HBF must earn a place inside that hierarchy. Every new tier adds controllers, scheduling decisions, failure modes, validation requirements, and procurement dependencies.

Software support becomes decisive. A serving framework must know which tensors or cache segments can tolerate HBF latency.

Poor placement could stall an expensive accelerator while it waits for flash. Good placement could let the same accelerator serve a larger model or more simultaneous requests.

Developers will need profiling tools that expose those effects. Automatic placement could eventually hide some complexity, but early systems will probably require workload-specific tuning.

Standards help by giving software teams a stable target. They also reduce the risk that each accelerator vendor implements an incompatible interface.

OCP is relevant because its membership includes cloud and data-center participants that can evaluate system-level tradeoffs. Their involvement would give HBF stronger validation than two suppliers acting alone.

Yet an open workstream does not guarantee broad adoption. Samsung, Micron, Kioxia, accelerator designers, and hyperscale operators must decide whether the proposed interface serves their interests.

Some vendors might prefer CXL-attached memory, larger HBM configurations, compressed model formats, or faster SSD architectures. CXL is an interconnect that supports memory expansion and sharing between processors and devices.

These routes can overlap with HBF. They can also reduce the need to place NAND in an HBM-like package.

HBF therefore faces an installed-system opponent, not a single company. Existing HBM-centered architectures already have production tools, customer relationships, and software support.

Sandisk and SK hynix can challenge that position only with evidence from complete systems. A specification is useful, but repeatable workload results will decide whether the new tier survives.

What the HBF Specification Claim Still Cannot Answer

The largest uncertainty is not whether stacked NAND can move data quickly, but whether commercial systems can use it predictably and economically.

The first unresolved issue is latency. Sandisk has promoted a substantial sequential bandwidth target, but bandwidth does not describe every access pattern.

Inference workloads can retrieve small, scattered pieces of data. HBF must show how controllers and software handle those requests without creating long processor stalls.

The second issue is write endurance. NAND cells withstand fewer writes than DRAM, and inference systems continuously update some forms of temporary state.

Read-dominant model weights fit HBF’s strengths. Write-intensive cache behavior could expose its limitations unless systems redirect writes or manage wear effectively.

The third issue is thermal behavior. Stacking many NAND dies with logic increases density near accelerators that already generate substantial heat.

Lower power per stored bit would help, but package-level cooling remains a system problem. Vendors must publish operating limits under sustained workloads.

Manufacturing yield creates another risk. A package containing numerous bonded dies can lose economic value if defects reduce the number of usable stacks.

Sandisk’s bonding process and SK hynix’s packaging experience address this challenge. Neither company has yet provided public, independently tested yield or reliability data for commercial HBF.

Interoperability is equally uncertain. A true standard should allow components from different suppliers to work with shared controllers and software.

A document developed mainly around one supplier’s technology might be open in name but difficult for competitors to implement. OCP review can reduce that risk if participation becomes broad.

Intellectual-property terms also matter. System builders need to understand which interface elements are open and which depend on licensed manufacturing processes.

An electrical specification would not automatically standardize physical fabrication. Companies can share interfaces while protecting their bonding, controller, and NAND designs.

The timeline deserves scrutiny. Sandisk previously targeted initial HBF samples for the second half of 2026 and HBF-equipped device samples for early 2027.

Those targets imply that silicon validation, specification work, and customer integration are proceeding in parallel. Parallel development saves time but increases the cost of late design changes.

A truly approved OCP document would reduce some uncertainty. It would still leave manufacturing readiness, software maturity, and workload performance unanswered.

Industry reporting has also presented conflicting commercialization horizons. Some coverage points to samples around 2026 and 2027, while broader roadmaps place mature HBF deployment later.

That difference can reflect separate milestones rather than a direct contradiction. Engineering samples can arrive years before high-volume, widely interoperable products.

The distinction should remain visible whenever Google News or another aggregator amplifies a compressed headline. “Specification released” does not mean “product shipping.”

Even “product sampling” can refer to limited evaluation units. Customers may test those devices without committing to deployment.

A credible adoption case needs more than internal demonstrations. Independent system builders should publish workloads comparing HBF, HBM, host memory, and SSD configurations.

Those comparisons should control for accelerator type, model size, batch size, context length, power, and latency targets. Otherwise, capacity advantages can obscure performance penalties.

The companies should also clarify failure behavior. Operators need to know how systems isolate bad dies, preserve service availability, and recover when an HBF device fails.

Because HBF uses nonvolatile media, it may create security questions around residual model data. Specifications should define sanitization, access controls, and lifecycle management.

None of these problems invalidates the concept. They explain why the difference between a workstream and a finished standard is important.

The workstream opens the debate. A public specification should turn that debate into requirements that vendors, customers, and independent engineers can test.

Three Signals Will Show Whether HBF Is Becoming Real

The next phase should be judged by a public OCP document, validated samples, and support from companies beyond Sandisk and SK hynix.

The first signal is an identifiable OCP specification. It should include a version, technical scope, governance status, and revision history.

Publication would strengthen the current standardization claim. Continued absence would suggest that headlines moved ahead of the formal process.

The document’s content matters as much as its existence. A narrow mechanical proposal would carry less weight than a specification covering interfaces, commands, reliability, and interoperability.

The second signal is Sandisk’s sampling milestone. The company targeted initial HBF memory samples for the second half of 2026.

Working samples should produce detailed evidence, including random-access latency, sustained bandwidth, endurance, power consumption, thermals, and error behavior.

Independent testing would strengthen the case more than vendor demonstrations. A delay would not kill HBF, but it would weaken the stated path toward early 2027 device samples.

The third signal is participation beyond the founding partners. Watch for accelerator vendors, hyperscalers, server manufacturers, software projects, and additional memory suppliers joining the work.

Broad participation would show that HBF is becoming a shared architecture. Limited participation would leave it closer to a bilateral product strategy.

Samsung, Micron, and Kioxia are especially important comparison points because they possess relevant memory or flash expertise. Their support, competing proposals, or silence will clarify the market’s direction.

Accelerator support matters even more. HBF cannot become useful infrastructure if processors lack suitable controllers, package connections, and memory-management software.

Cloud operators can provide the strongest demand signal. They operate inference fleets large enough for improvements in capacity and energy use to justify architectural changes.

Software commits also deserve attention. Memory-placement support in inference engines, compilers, and orchestration systems would indicate that hardware plans have moved beyond presentations.

Readers following the story through Google News should separate these signals from repeated announcements. Syndicated headlines often make one partnership appear like several independent confirmations.

The underlying record is straightforward. Sandisk and SK hynix agreed to cooperate in August 2025, launched an OCP workstream in February 2026, and outlined future sampling targets.

A newly released specification would be the next distinct milestone, but it needs a verifiable document. Product validation and ecosystem participation must follow.

For developers, HBF could change how models, caches, and retrieval data are placed around accelerators. It could also introduce another performance boundary requiring careful profiling.

Enterprise buyers should ask whether proposed capacity gains improve their actual serving workloads. They should request full-system measurements rather than relying on component bandwidth.

Knowledge workers and AI users will not purchase HBF directly. They could still feel its effects through longer contexts, larger models, or lower inference costs.

Those benefits remain potential outcomes, not confirmed results. The most useful response is to track evidence rather than accept either enthusiastic promotion or premature dismissal.

The standardization effort deserves attention because it addresses a real memory bottleneck. Its success now depends on whether the partners turn an open workstream into testable infrastructure.

Watch for the OCP document first, customer-tested silicon second, and outside participation third. Together, those signals will reveal whether HBF is becoming a standard or remaining a promising proposal.