Why Memory Stocks Move Together: HBM, AI Accelerators, and What Developers Should Know

← Back to Blog

On 28–29 July 2026, an unusual cluster trended simultaneously in US search: sk hynix, mu stock (Micron), sndk stock (Sandisk), stx stock (Seagate), alongside nvda stock and amd stock.

That is not a coincidence, and it is not really a finance story. It is a story about a specific piece of hardware — High Bandwidth Memory — and why it has become the constraint on AI infrastructure.

This post explains the technical picture. It is not investment advice, and I have no view on whether any of these companies is worth buying.

The bottleneck is not compute

The intuitive model of an AI accelerator is that it is fast because it does a lot of arithmetic. That is true, and it is not the limiting factor.

Modern accelerators are memory-bandwidth bound for most transformer inference workloads. The arithmetic units spend a significant fraction of their time idle, waiting for weights to arrive from memory. You can see this in the roofline: for a given model, throughput is often determined by how fast you can stream parameters, not by peak FLOPS.

A rough sense of the scale. Serving a large model at low latency means moving its weights through the compute units repeatedly. If you have tens of gigabytes of parameters and you want tokens out at interactive speed, you need memory bandwidth measured in terabytes per second — not gigabytes.

Conventional DDR memory cannot do this. A typical DDR5 channel delivers tens of GB/s. You would need an implausible number of channels, and the pin count alone makes it physically impossible on a package.

What HBM does differently

High Bandwidth Memory solves this by changing the geometry rather than the speed.

Instead of placing memory chips beside the processor and connecting them with a narrow, fast bus, HBM stacks DRAM dies vertically — eight or twelve high — and connects them with thousands of vertical connections called through-silicon vias. The stack sits on the same package as the accelerator, linked by a silicon interposer.

The result is a bus that is enormously wide rather than enormously fast: on the order of 1,024 bits per stack versus 64 for a DDR channel. Bandwidth is width times clock, so you get very large numbers at moderate clock speeds, which also keeps power per bit down.

The trade-offs are real:

It cannot be upgraded. HBM is on the package. The memory capacity of an accelerator is fixed at manufacture, which is why a card's VRAM figure determines what models it can hold.
Yield is punishing. Stacking eight dies means a defect in any one can waste the whole stack.
Packaging is the constraint. Advanced packaging capacity — TSMC's CoWoS in particular — has been a harder limit on AI accelerator supply than the logic dies themselves.

That last point is the crux. When people say AI hardware is supply constrained, the constraint has frequently been packaging and memory, not the processor.

Why these particular companies

SK Hynix and Micron manufacture HBM. Along with Samsung, that is essentially the entire market — three companies. When AI infrastructure demand moves, their outlook moves, because HBM commands a substantial price premium over commodity DRAM and consumes wafer capacity that would otherwise produce it.

Sandisk and Seagate are a different layer. They make NAND flash and hard drives — storage, not memory. They correlate because AI training pipelines need enormous datasets held somewhere, and inference infrastructure needs checkpoints, model weights at rest, and vector indices. The demand is real but structurally different from HBM.

Nvidia and AMD buy HBM. Their accelerator output is gated partly by how much of it they can secure.

So the cluster trending together reflects one supply chain being repriced at once, from the accelerator down through memory to storage.

What this means if you build software

You are unlikely to buy HBM. But the constraint shapes decisions you do make.

VRAM determines what you can run. Because HBM capacity is fixed at manufacture, the practical question for self-hosting a model is whether its weights fit. Quantisation — running at 8-bit or 4-bit instead of 16 — is popular not primarily because it is faster, but because it makes the weights fit in memory you already have.

Batching helps more than it looks like it should. If you are memory-bandwidth bound, processing several requests against the same weights amortises the cost of streaming those weights. This is why inference servers batch aggressively, and why per-request latency and total throughput trade off against each other.

Context length is expensive in a specific way. The KV cache grows with sequence length and lives in the same constrained memory. Long context does not just cost compute — it competes with the model weights for the scarcest resource on the card.

"Just add more GPUs" has a bandwidth cost. Splitting a model across cards means weights and activations crossing an interconnect that is slower than on-package memory. Sometimes that is fine; sometimes it is the new bottleneck.

The honest caveat

Search interest is not analysis. mu stock trending tells you people are searching, not why, and earnings dates alone produce these spikes routinely. The structural HBM story above is real and well documented — but on any given day, a stock moves for reasons that have nothing to do with the technology.

Treat the technical picture as durable and the daily movement as noise.

Working with the data

If you are pulling this kind of infrastructure data from an API — pricing feeds, telemetry, benchmark results — you will spend a fair amount of time reading minified JSON responses. A JSON formatter makes them readable in one click, and because ours runs entirely in the browser, your API keys never leave your machine.

For structuring the data you produce, our JSON best practices guide covers the details that matter here — particularly never using floats for monetary values, since JSON numbers are IEEE 754 doubles and cannot represent 0.1 exactly.