Similar to HBM, HBF relies on multiple memory dies that have been stacked together, but instead of DRAM, it utilizes NAND flash to increase storage capacity.
What's the lifetime on the flash memory in such a setup? I mean, if you're constantly shoveling 3TB/sec into said flash memory, even if you have a lot of memory behind that interface, I'd think that it'd have a limited life.
thinks
Maybe if the stuff is rarely-written? Like, say you use HBF for static data that you mostly just read, like the model edge weights, and HBM-accessed DRAM just for the dynamic stuff?
reads more
Oh. Maybe this is really more a replacement for M.2 or whatever is currently used for flash on compute servers, not as an HBM alternative:
Its primary role will be to complement capacity limits rather than outright replace HBM. LLMs can be processed through HBM, which is immediately required for computing, with HBF storing data in a larger capacity.
Might eliminate the need to load a model from flash to DRAM, if it can just be used directly from flash.
considers
That might legitimately reduce demand for DRAM. Like, a lot of AI DRAM usage is (presently, though might change for more-advances AI) for data that doesn't change much. Like, you're only putting it in DRAM so that the parallel compute hardware has fast access to it, not because it needs to be written to much.
EDIT: It also might provide parallel compute manufacturers a way to price-discriminate between more-price-sensitive GPU (gaming) users and AI (often much less price-sensitive) users via a route other than capping on-card DRAM for gaming users. It'd kind of suck for gaming users if texture memory gets capped because GPU makers don't want to cannibalize their AI market. If you make your parallel compute cards have a ton of onboard flash, that's something that gaming users don't care about
they need their memory to be mutable
but AI users do.
I think that it's fine technically
the ML family of languages have extensive static typing functionality that I like
but Rust has enough overlap in functionality and has greater uptake. (I say this not having spent enough time to really come up to speed on Rust myself.) A quarter century back, ocaml was the language that I was most impressed with for strong static typing functionality. In 2026, I think I'd probably look at Rust and only go to ocaml if Rust doesn't suit your needs.
As to whether it can be a "daily driver"...I mean, you can use any language daily. I do think that it's hard to appreciate how helpful it is to have all the examples and library support and tools until you move from a popular language to a less-used one and suddenly discover that you want something that isn't there.
So can you use it? Sure. Is it the first option I'd recommend to someone who
and I assume that this is why you're looking at it, if your alternative is Python
wants to move to a statically-typed language? No. Is it a terrible choice? No, it'd also be a long way from the bottom of the list that I'd recommend.