The first open High Bandwidth Flash specification gives AI infrastructure buyers something concrete to examine. It does not give them a reason to postpone a server order.
SK hynix and Sandisk announced the specification at FMS 2026 on 4 August. It describes HBF stacks of up to 512GB, using 8-high or 16-high NAND, with three bandwidth grades from roughly 0.4TB/s to 3.0TB/s. The proposed processor connection uses UCIe. Those are meaningful design details, yet they remain specification details. Buyers cannot presently select HBF beside the GPU, RAM and NVMe options in a mainstream production server configurator.
That distinction matters. A team with an inference service due this year needs hardware that can be delivered, supported and tested now. A team planning a 2027 or 2028 platform should follow HBF closely because it may alter how large model weights are placed around the accelerator.
Our recommendation is simple: do not delay a justified 2026 H200, B200, B300 or RTX PRO deployment solely for HBF. Do make memory tiering, software support and future accelerator compatibility explicit requirements in any longer-lived procurement.
The buyer answer in one minute
HBF is intended to sit between GPU-attached HBM and conventional SSD storage. It uses stacked NAND and a high-bandwidth interface to offer far more capacity than HBM, with much greater proximity to the processor than an ordinary NVMe drive.
The new specification matters for three reasons:
- It gives processor, memory and packaging companies a shared technical target.
- It puts capacity, bandwidth grades, UCIe connectivity and software guidance into an open industry process.
- It makes tiered accelerator memory more credible than a single-vendor concept slide.
It does not yet answer the questions that decide a purchase: which accelerators support it, when qualified systems will ship, what latency and endurance look like under real inference traffic, how software places data across tiers, and who supports the complete platform.
Buy an available platform when the workload and delivery plan justify it. Treat HBF as a roadmap criterion, not as a current substitute for HGX servers, PCIe accelerators or NVMe storage.
What changed at FMS 2026
Sandisk and SK hynix began collaborating on HBF in 2025. In February 2026, the companies formed a dedicated Open Compute Project workstream. The August announcement is the first published standard specification from that effort.
SK hynix states that the specification covers:
| Area | Published specification detail | What a buyer should infer | | --- | --- | --- | | Capacity | Up to 512GB per HBF stack | Large weight sets could be placed much closer to the processor than they are on SSD. | | Stack options | 8-high and 16-high NAND dies | Packaging density is central to the value proposition. | | Bandwidth | Three grades from about 0.4TB/s to 3.0TB/s | HBF is a class with different performance points, not one universal speed. | | Interconnect | UCIe | The design aims for an open chiplet connection rather than a closed processor link. | | Other guidance | Electrical, packaging, reliability and software I/O requirements | Useful integration work remains before a complete supported system exists. |
Google and Tenstorrent are named as participants in the consortium. Their presence is evidence of ecosystem interest, not proof that a particular processor or server supports HBF. No buyer should turn consortium membership into an assumed product commitment.
The FMS programme also placed HBF inside a wider tiered-memory discussion. HBM, host DRAM, CXL memory, HBF and SSD each trade speed, capacity, persistence, cost and placement differently. Future inference systems may use several of them at once.
HBF is not HBM with a different letter
HBM is DRAM positioned beside an accelerator through advanced packaging. It provides the bandwidth and latency needed for active tensor operations, model weights, activations and KV cache. Its capacity is valuable and expensive because it sits in a physically constrained, high-performance part of the package.
HBF is based on NAND. NAND is non-volatile and denser than DRAM, but it has different read, write, latency and endurance behaviour. Stacking NAND and connecting it through UCIe does not erase those physical differences.
The intended relationship is therefore additive. SK hynix describes HBF as a supporting tier while HBM continues to handle the highest-bandwidth work. Sandisk has discussed architectures in which HBM acts as a cache in front of a much larger HBF capacity. That could let an accelerator keep frequently used data in HBM and draw colder weights or other state from HBF.
The placement policy will decide whether this works. A poor policy could move data at the wrong time and stall the processor. A good policy could keep a large model close enough to the compute path without paying for all of its capacity in HBM.
Until production platforms exist, the sensible description is "a proposed new memory tier". Calling HBF an HBM replacement hides the hard system work.
HBF is not a fast SSD either
An NVMe SSD is a block storage device reached through PCIe and an I/O software stack. It is replaceable, serviceable and already well understood by server operators. Drives can hold model files, datasets, checkpoints and colder KV-cache data, but they do not behave like accelerator memory.
HBF is being designed for much tighter processor integration. The UCIe link, die stacking and software I/O guidance point towards a package-level or closely attached role rather than a hot-swappable drive bay. Its value depends on lower data-movement overhead and much higher aggregate bandwidth than ordinary storage paths.
That tighter integration has a cost. Buyers may lose some of the independent serviceability they get from SSDs. Capacity and processor support may be fixed at platform design time. Firmware, drivers, memory placement and failure handling may cross several suppliers.
NVMe remains the practical capacity tier for systems being bought today. HBF may later take over a hotter part of the hierarchy, while SSDs continue to hold datasets, checkpoints, model repositories and colder state. The existing GPUMachines guide to SSD-backed LLM memory covers the decisions buyers can make with available hardware.
The workloads most likely to benefit
HBF is being aimed primarily at inference, and that is a sensible starting point. Inference often needs a large body of model weights to remain available while only part of the model is active at a given moment.
Mixture-of-experts models are an obvious candidate. They can have a very large total parameter count while routing each token through a smaller set of experts. If inactive experts can live in a high-capacity tier and be brought into the hot tier predictably, the system may avoid storing every weight in HBM.
Large recommendation, retrieval and multimodal models may also have data with different temperatures. Long-running agent services can accumulate state and cache. Edge inference could value density and persistence where power and board space prevent large pools of DRAM.
None of those uses is automatic. HBF will be less attractive when the workload repeatedly touches nearly all weights, demands low write latency, changes state heavily or cannot tolerate tier misses. Training is a harder fit because optimiser state, gradients, activations and checkpoint traffic create different write and endurance demands.
Buyers should ask vendors to name the exact data structures placed in HBF. "AI memory" is too vague. Model weights, KV cache, embeddings, expert weights and storage cache each have different access patterns.
Why Sandisk's performance claims need context
Sandisk has said its HBF architecture is intended to offer 8 to 16 times the capacity of HBM while delivering comparable read bandwidth at similar price points. It also published a simulation in which an HBF design running a 405-billion-parameter model was within 2.2 per cent of a hypothetical unlimited-capacity HBM system.
These are vendor targets and simulation results. They are useful for understanding the design goal. They are not independent server benchmarks, purchase prices or compatibility guarantees.
The simulation deliberately removed HBM capacity as a constraint to compare the effect of bandwidth. A production buyer needs the opposite: a complete system comparison that includes real capacity limits, latency, data placement, power, software overhead, failures and cost.
When HBF systems become available, ask for results on the model revision, precision, batch shape and concurrency you plan to operate. A single average throughput number will not reveal tier misses or long-tail latency.
Should you wait before buying H200, B200 or B300?
For most projects, no.
An H200 system can be a sound choice for Hopper-compatible software, high-memory inference, fine-tuning and deployments that need mature availability. B200 and B300 platforms target newer Blackwell workloads, with different memory, interconnect, power and cooling considerations. RTX PRO systems suit a different cost, support and PCIe deployment lane.
HBF does not make those choices obsolete. It is not currently an option that can be added to them. Waiting introduces its own costs: delayed model work, rented capacity, missed service launch dates and engineering time spent designing around unconfirmed hardware.
There are cases where waiting is reasonable. A project with no production deadline, a model that cannot be made economical with current memory, and a 2027 research horizon may prefer a hosted pilot while monitoring HBF. A public procurement that will deliver over several years can ask bidders to describe a migration path to tiered memory.
Do not write "HBF required" into a 2026 tender unless a qualified product exists. Write outcome requirements instead: model capacity, accepted latency, throughput, power envelope, software support, failure recovery and upgrade path.
What to buy now if memory is the problem
First identify which memory is full.
If model weights do not fit, quantisation, tensor parallelism, pipeline parallelism or a higher-memory accelerator may help. If KV cache consumes the margin, context length, batching, cache precision, prefix reuse and offload policy may matter more than total weight capacity. If host staging is the problem, DDR5 population and NUMA placement need attention. If model load times dominate, local or shared NVMe may be the limiting tier.
The practical options today include:
- Higher-capacity accelerators or dense HGX platforms for models that genuinely need scale-up bandwidth.
- Flexible PCIe GPU servers for independent inference replicas, research and mixed accelerator choices.
- CXL-attached or high-capacity host memory where the software can use it effectively.
- Local NVMe for model staging, cache and scratch data.
- Scale-out storage for shared models, datasets and checkpoints.
- Hosted GPUs while a team measures demand or waits for a more suitable product cycle.
These routes can coexist. The right bill of materials follows measured data movement, not a memory acronym.
Questions to put in an HBF request for information
An early HBF procurement conversation should expose uncertainty rather than conceal it.
Ask the platform vendor:
1. Which processor and accelerator revisions have qualified HBF support? 2. Which HBF capacity and bandwidth grade is fitted? 3. Is HBF coherent memory, managed memory, a software-visible device or another class? 4. Which runtime decides what remains in HBM and what moves to HBF? 5. What happens on a tier miss? 6. Which data types and access patterns are supported? 7. How are writes, wear, retention and error correction handled? 8. Can an HBF component be serviced independently? 9. Who owns support across the processor, HBF stack, firmware, runtime and server? 10. What production telemetry exposes bandwidth, latency, placement and errors?
Request an acceptance test with warm and cold states. Include steady traffic, bursts, long contexts, model swaps and a component fault. Measure time to first token, inter-token latency, throughput, power and task completion, not only the memory link.
Architecture points buyers will need to revisit
Software placement
Tiered memory only works when software knows where data should live. Static placement may suit read-mostly weights. Dynamic placement may be needed for experts, cache or multi-tenant services. Both require observability and a way to prevent one workload evicting another's useful data.
Processor links
UCIe provides a shared die-to-die interface, but an interface standard does not define the whole product. Lane count, packaging, controllers, coherence and accelerator integration still determine usable performance.
Power and cooling
More near-processor capacity can reduce data movement, yet dense NAND stacks and controllers still consume power and create heat. The platform's rack power and cooling requirements must be measured as a complete system.
Reliability and service
Non-volatile memory brings endurance, retention and media-management questions. A tier close to the accelerator also changes failure domains. Buyers need to know whether a failed stack degrades capacity, takes an accelerator offline or requires board replacement.
Cluster behaviour
One node with a large local tier may reduce some network transfers. It may also create new placement problems when jobs move between nodes. Cluster schedulers will need awareness of HBF capacity and locality if the tier is not uniform.
Who should track HBF closely
Inference providers serving very large or sparse models should follow qualified platform announcements. So should research teams studying model placement, memory-aware scheduling or chiplet systems. Buyers planning a multi-year AI factory can include HBF in technology watchlists and architecture reviews.
HBF also deserves attention from teams whose current design needs a large number of accelerators mainly to hold weights rather than perform compute. If a future tier reduces that capacity tax, it could change server count and energy use.
The relevant action today is measurement. Record weight residency, HBM utilisation, cache growth, read/write mix and data movement. That evidence will show whether HBF solves a real problem when products arrive.
Who should not wait for it
Do not wait if the present model fits a supported accelerator, the service has a firm launch date and the system has a defensible lifetime cost. Do not wait if your bottleneck is compute, network collectives, storage throughput or weak utilisation rather than memory capacity.
Small inference services may be better served by a workstation, one or two PCIe GPUs, or hosted capacity. Training clusters should not assume an inference-oriented NAND tier will solve activation, optimiser or collective-communication pressure.
A team with no memory telemetry should not buy around HBF yet. It should instrument the current stack first.
How GPUMachines can help
GPUMachines can compare current accelerator platforms, model fit, memory capacity, host RAM, local NVMe, fabric design and deployment routes. For a project being purchased now, that means a configuration based on available, qualified parts.
For longer programmes, we can record HBF as a roadmap requirement and review compatible systems when vendors expose orderable products. We can also help buyers avoid locking a tender to an unshipped component by expressing the requirement as measurable capacity, latency, throughput, support and serviceability.
Start with the GPU cluster configurator when the requirement spans more than one server, then have GPUMachines review the memory and data path against the actual models.
Frequently asked questions
Is HBF available in GPUMachines servers today?
Not as a generally orderable configuration option at the time of writing. The first open specification has been announced, but accelerator support, qualified server products and commercial availability still need to be confirmed.
Will HBF replace HBM?
The published architecture positions HBF as a supporting tier. HBM remains the hot, low-latency memory beside the accelerator. HBF is intended to add much larger NAND-based capacity for suitable data.
Is HBF the same as CXL memory?
No. CXL is a host-oriented interconnect and memory-expansion framework used with DRAM and hybrid devices. HBF is a stacked NAND memory class with UCIe named in the first specification. Both can appear in a tiered system, but their placement and software models differ.
Does 3.0TB/s mean HBF will perform like HBM?
No. Bandwidth is one metric. Latency, access granularity, write behaviour, placement policy and workload locality also matter. The 3.0TB/s figure is the top grade stated in the first specification, not a complete server benchmark.
Which workloads are the best candidates?
Read-heavy inference with large model weights, especially models with colder experts or other data that does not need to occupy HBM continuously, is the clearest candidate. The exact fit must be proven on shipping hardware.
Should HBF appear in a 2027 tender?
It can appear as an option or roadmap item if the delivery schedule allows. The tender should still require a named supported platform, evidence from the buyer's workload and a fallback based on available technology.
Sources and further reading
- SK hynix: first HBF standard specifications at FMS 2026
- SK hynix: HBF standardisation workstream with Sandisk
- Sandisk: Memory-Centric AI and the HBF development target
- FMS 2026 programme: Breaking the Memory Wall with High Bandwidth Flash
Verdict
The first open HBF specification is an important architecture signal. Up to 512GB per stack, graded bandwidth and UCIe connectivity make the proposal specific enough for processor and software teams to work against.
It is still not a reason to freeze a sound 2026 deployment. The ideal buyer response is to purchase current hardware against measured needs, keep the memory hierarchy modular where possible, and ask vendors for a supported HBF path when real systems emerge.
Use the GPUMachines GPU cluster configurator to frame the current compute, memory, network and storage requirement, then ask us to compare it with the HBF-era roadmap rather than guessing which generation will arrive first.