The Memory Wars: Why the Future Karpathy, Musk, and Jim Fan See Requires 16-Hi HBM

The Memory Wars: Why the Future Karpathy, Musk, and Jim Fan See Requires 16-Hi HBM

This is my first time trying out X's article feature—apologies if the formatting is rough. A polished version will be up on my Substack shortly. And to everyone reading: Happy New Year! 🎉

"Weekends are for philosophy." — @ramahluwalia

Ram's right. So let's step back from the spec sheets and ask what we're actually witnessing.

This week, Karpathy posted something that stopped me cold:

I've never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse and between. I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year and a failure to claim the boost feels decidedly like skill issue. There's a new programmable layer of abstraction to master (in addition to the usual layers below) involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering. Clearly some powerful alien tool was handed around except it comes with no manual and everyone has to figure out how to hold it and operate it, while the resulting magnitude 9 earthquake is rocking the profession. Roll up your sleeves to not fall behind.

Dec 26, 2025 · 5:36 PM UTC

2,557
7,307
2,900
55,226
17,097,702

This is Karpathy—the guy who built Tesla's Autopilot, who was skeptical about current models just two months ago on Dwarkesh's podcast—now saying he feels behind.

What changed? The inference layer got good enough. And it's about to get dramatically better.

The same week, Electronic Times broke news that NVIDIA requested 16-Hi HBM deliveries from Samsung, SK Hynix, and Micron by Q4 2026. This isn't a research timeline—it's a production order.

These two data points are connected. The infrastructure buildout happening right now—16-Hi HBM, 3D-stacked SRAM, the $20B Groq licensing deal—is what makes Karpathy's "10X more powerful" possible. And it reveals why the AI chip competition may already be over.

Nvidia just pulled the HBM roadmap forward. 16-Hi HBM. Never mass-produced. Wafer thinning to ~30µm. Bonding layers <10µm. Thermals on a knife edge. Samsung, SK Hynix, Micron sprint because $NVDA says jump. This isn’t memory. It’s AI infrastructure.
Samsung, SK, and Micron Clash Over 16-HI HBM… Nvidia Orders Development Samsung Electronics, SK Hynix, and Micron have entered the race to develop 16-HI High Bandwidth Memory (HBM). This is because Nvidia, the world's largest AI semiconductor company, has requested supply for the second half of next year. The 16-HI HBM is a product that has never been commercialized before, and the company that first solves various technical challenges, such as DRAM stacking, is expected to seize dominance in the next-generation market. According to comprehensive reporting by the Electronic Times on the 28th, it has been identified that Nvidia requested domestic and foreign memory manufacturers to deliver 16-HI HBM by the fourth quarter of next year. Consequently, Samsung Electronics, SK Hynix, and Micron have commenced full-scale development work for the mass production supply of 16-HI HBM. Although concrete contracts have not yet been signed, it is reported that discussions are underway internally regarding even initial production volumes. An industry official familiar with the matter stated, "Following the supply of 12-HI HBM4, a request for 16-HI supply has also been made, so we are establishing a very fast development schedule," adding, "Performance evaluation could begin as early as before the third quarter of next year." Currently, the 12-HI version of HBM4 is scheduled for mass supply early next year, but dealings for the next product, the 16-HI version, have accelerated. Another high-ranking industry official suggested the possibility of it being named HBM4E, saying, "It is likely that the product will be 16-HI HBM4, but the generation or name could change depending on performance and mass production timing." The 16-HI stack is an HBM that the three memory companies have never commercialized. Currently, what is being provided as prototypes to Nvidia and entering mass production is the 12-HI HBM4. Since it is an unprecedentedly high-stack HBM being attempted for the first time in the semiconductor industry, observations suggest that technical challenges will be formidable. Above all, there are concerns about the thin wafer thickness. While existing 12-HI HBM has a wafer thickness of about 50 micrometers (㎛), it is reported that this must be reduced to around 30㎛ to stack 16 layers. The HBM4 thickness standard defined by JEDEC (Joint Electron Device Engineering Council) is 775㎛. It is about 50㎛ thicker than the existing HBM3E (725㎛). This leeway was given because implementing thin HBM becomes more difficult as the number of layers increases. However, the prevailing opinion is that JEDEC will not further increase the thickness for this 16-HI HBM. This means more DRAMs must be stacked within 775㎛. If the thickness becomes thinner, improvements in wafer processing technology are necessary. Technology to cut and polish (CMP) the wafer without breaking it is required. Because of these technical issues, it has been confirmed that some memory manufacturers have introduced new wafer processing equipment. HBM is implemented by vertically stacking and attaching DRAMs, and this bonding process is also identified as a technical hurdle. Since more DRAM wafers need to be attached compared to the existing 12-HI stacks, thinner bonding materials are essential. Currently, Samsung Electronics and Micron are proceeding with the bonding process using Thermal Compression Non-Conductive Film (TC-NCF), while SK Hynix uses Mass Reflow Molded Underfill (MR-MUF). An industry official said, "The current bonding material thickness is around 10㎛, and to stack more DRAMs, this must be reduced to secure competitiveness," adding, "Dissipating the heat generated after bonding is also a challenge." $NVDA

Dec 28, 2025 · 6:43 AM UTC

6
55
4
308
35,329

Why AI Is Starving for Memory

Before we dive into the architecture wars, let's establish the core problem:

AI models are growing faster than our ability to feed them data.

A 70B parameter model like Llama 3 requires 140GB just to store weights. Add a 128K-token context window and the KV cache consumes 40GB per user. Serve 10 users simultaneously? That's 400GB just for the cache.

The KV cache formula reveals the exponential scaling problem:

KV Cache = 2 Ă— 2 Ă— head_dim Ă— n_heads Ă— n_layers Ă— seq_length Ă— batch_size

For a 70B model at 1 million tokens context (Gemini-scale), the KV cache alone reaches ~312GB per user. Serving 100 concurrent users would require 31TB of memory.

GPT-4's estimated 1.76T parameters require ~3.5TB in FP16. By 2028, we're looking at 10T+ parameter models requiring 5TB minimum.

The 99% Idle Problem

Here's the dirty secret of AI inference: your $40,000 H100 runs at less than 1% utilization during decode.

Why? The arithmetic intensity mismatch.

H100 specs: 990 TFLOPS BF16 compute, 3.35 TB/s HBM bandwidth. That's optimized for 295 FLOPs per byte accessed.

But inference decode? Each token generation loads the entire model weights from HBM, performs roughly 2 FLOPs per byte, then waits. The GPU is literally idle 99% of the time, waiting for memory.

Training achieves 100-1000+ FLOPs/byte through batch parallelism. Prefill processes prompts in parallel. But decode's sequential, token-by-token generation leaves tensor cores starving.

This is the "memory wall"—and it's why training and inference require fundamentally different architectures.

HBM vs SRAM: The Physics

Two types of memory, two different tradeoffs:

HBM (High Bandwidth Memory):

  • Capacity: 80GB → 192GB → 1TB by 2027
  • Bandwidth: 3.35 TB/s (H100) → 8 TB/s (B200) → 32 TB/s (Rubin Ultra)
  • Latency: 100-150 nanoseconds
  • Best for: Training, prefill, storing large models

SRAM (On-Chip Static RAM):

  • Capacity: 50MB (H100 L2) → 230MB (Groq LPU)
  • Bandwidth: 12 TB/s (H100 L2) → 80 TB/s (Groq internal)
  • Latency: 0.5-2 nanoseconds — 50-100Ă— faster than HBM
  • Best for: Inference decode, low-latency applications

The memory wall exists because FLOPS scale ~750× every 2 years while DRAM bandwidth scales only ~1.6×. From V100 to H100, NVIDIA's compute-to-bandwidth ratio doubled from 139:1 to 295:1—making GPUs progressively worse-suited for memory-bound inference.

The Puzzle Pieces

Piece 1: The 16-Hi HBM Race

NVIDIA wants 16 DRAM layers stacked within JEDEC's 775ÎĽm height limit. The physics are brutal:

  • Current 12-Hi HBM4 uses 50ÎĽm wafers
  • 16-Hi requires 30ÎĽm—silicon so thin it's translucent
  • Bonding layers must shrink from ~10ÎĽm to even thinner
  • Heat dissipation across 16 active DRAM layers? Unsolved at scale

Samsung uses TC-NCF bonding. SK Hynix uses MR-MUF. Both are racing to solve wafer thinning without shattering. New equipment has been deployed.

SK Hynix is ahead. The winner captures $50B+ in annual HBM revenue by 2028.

Piece 2: The SRAM Scaling Wall

SRAM density has effectively stalled:

  • TSMC N5: ~0.021 µm² bitcell area
  • TSMC N3E: barely better
  • TSMC N2: ~0.0175 µm², ~38 Mb/mm² density

You can't add meaningful SRAM to a monolithic die without burning obscene wafer area. This is physics, not engineering.

This is Groq's moat—and limitation. Their LPU crams 230MB SRAM with 80 TB/s internal bandwidth, achieving 276 tokens/sec on Llama 3.3 70B versus 60-100 on GPUs. But holding that model requires 576 chips across 8 racks.

Piece 3: The $20B Groq Deal

NVIDIA didn't pay $20B for Groq's chips. They paid for validation that SRAM-centric, deterministic architectures win at inference. Groq's compiler-driven dataflow with static scheduling achieves higher Model FLOPs Utilization in low-batch scenarios.

NVIDIA is absorbing that insight into their roadmap.

Piece 4: The Pouladian Cheat Code

Here's what I've been calling the architectural pattern that lets NVIDIA neutralize every competitor:

NVIDIA Feynman (2028) won't fight SRAM physics. It routes around them: 3D-stacked SRAM using AMD X3D-style hybrid bonding.

Calling Nvidia Feynman a GPU misses the point. It’s Nvidia quietly shipping a custom ASIC killer: deterministic dataflow + stacked SRAM + HBM hierarchy Same platform. Every workload. No stranded silicon. Check mate $nvda
Groq LPU blocks will first appears in 2028 in Feynman (the post Rubin generation). Deterministic, compiler-driven dataflow with static low-latency scheduling and Higher Model Floats Utilization (MFU) in low-batch scenarios will give Feynman immense inference performance boost in the favorable workloads. But the SRAM scaling stall on monolithic dies is brutal: bitcell area barely budged from N5 (~0.021 µm²) through N3E, and even N2 only gets to ~0.0175 µm² with ~38 Mb/mm² density. That's a very costly usage of wafer area. NVIDIA Feynman on TSMC A16 with backside power + full GAA will face this SRAM barrier/cost physics. So what's the solution? Simple, it's to make separated SRAM dies and stack them on top of the main compute die aka AMD X3D. Backside power delivery simplifies high-density hybrid bonding on the top surface, making 3D-stacked vertically integrated SRAM more practical, ie without front-side routing nightmares. So expect Feynman cores to mix logic/compute die on A16 for max density/perf + stacked SRAM on a cheaper/mature node for insane on-package bandwidth without monolithic density penalties. This keeps HBM for capacity (training/prefill) while SRAM stacking fixes low-latency decode MFU, exactly Pouladian "cheat code." Well done Nvidia, you just killed every ASIC chance to succeed...

Dec 28, 2025 · 5:33 AM UTC

15
28
174
20,901
  • Compute die: TSMC A16 with backside power delivery + GAA transistors. Maximum logic density.
  • SRAM die: Separate chips on cheaper, mature nodes. Stacked vertically via hybrid bonding.
  • HBM: 16-Hi stacks (48-64GB each) for capacity—training, prefill, large context windows.

Backside power delivery is the key enabler. Traditional chips route power and data on the front surface, creating congestion. A16 moves power to the back, freeing the front for high-density hybrid bonding—making 3D SRAM stacking practical without front-side routing nightmares.

Result: HBM capacity for weights + stacked SRAM bandwidth for low-latency decode. Best of both worlds.

The Roadmap

  • 2025-2026: HBM3E and 12-Hi HBM4 ramp. B200 with 192GB, 8 TB/s.
  • 2026-2027: 16-Hi HBM4 qualification. Q4 2026 delivery per NVIDIA request.
  • 2027: Rubin Ultra — 1TB HBM4E per GPU, 32 TB/s bandwidth. NVL576 configuration: 147TB total memory.
  • 2028+: Feynman — A16 compute + 3D-stacked SRAM + 16-Hi HBM4. Training monopoly retained, inference gap closed.

What Dies

Groq's standalone thesis: The $20B licensing deal is both validation and warning. Their deterministic architecture is genuinely innovative—NVIDIA paid to learn from it. But once Feynman ships with 3D-stacked SRAM, the latency gap that justified 576-chip deployments narrows considerably.

Custom ASIC differentiation: Google TPU, Amazon Trainium, Cerebras—the window is closing. Custom silicon makes sense for hyperscaler internal workloads, but when NVIDIA addresses inference efficiency through packaging rather than architectural overhaul, the ROI on separate hardware stacks becomes questionable.

AMD's catch-up strategy: MI300X's 192GB HBM3 is impressive. But if Feynman combines equivalent capacity with dramatically higher on-package bandwidth, AMD needs a packaging response—not just a process node catch-up.

What This Means for 2030

Back to philosophy.

We're witnessing construction of an infrastructure layer that makes AI inference effectively infinite and nearly free at the margin. When Feynman ships with terabytes of addressable memory and stacked SRAM for sub-millisecond responses, the bottleneck shifts from "can we run this model?" to "what should we ask it?"

This is why Karpathy feels behind. The capability is arriving faster than our ability to conceptualize what to do with it.

Jim Fan at NVIDIA shared his own anxiety this week:

Everyone's freaking out about vibe coding. In the holiday spirit, allow me to share my anxiety on the wild west of robotics. 3 lessons I learned in 2025. 1. Hardware is ahead of software, but hardware reliability severely limits software iteration speed. We've seen exquisite engineering arts like Optimus, e-Atlas, Figure, Neo, G1, etc. Our best AI has not squeezed all the juice out of these frontier hardware. The body is more capable than what the brain can command. Yet babysitting these robots demands an entire operation team. Unlike humans, robots don't heal from bruises. Overheating, broken motors, bizarre firmware issues haunt us daily. Mistakes are irreversible and unforgiving. My patience was the only thing that scaled. 2. Benchmarking is still an epic disaster in robotics. LLM normies thought MMLU & SWE-Bench are common sense. Hold your 🍺 for robotics. No one agrees on anything: hardware platform, task definition, scoring rubrics, simulator, or real world setups. Everyone is SOTA, by definition, on the benchmark they define on the fly for each news announcement. Everyone cherry-picks the nicest looking demo out of 100 retries. We gotta do better as a field in 2026 and stop treating reproducibility and scientific discipline as second-class citizens. 3. VLM-based VLA feels wrong. VLA stands for "vision-language-action" model and has been the dominant approach for robot brains. Recipe is simple: take a pretrained VLM checkpoint and graft an action module on top. But if you think about it, VLMs are hyper-optimized to hill-climb benchmarks like visual question answering. This implies two problems: (1) most parameters in VLMs are for language & knowledge, not for physics; (2) visual encoders are actively tuned to *discard* low-level details, because Q&A only requires high-level understanding. But minute details matter a lot for dexterity. There's no reason for VLA's performance to scale as VLM parameters scale. Pretraining is misaligned. Video world model seems to be a much better pretraining objective for robot policy. I'm betting big on it.

Dec 28, 2025 · 6:11 PM UTC

133
239
78
1,618
299,832

Read that last point carefully: "Video world model seems to be a much better pretraining objective for robot policy."

Video world models are memory monsters. They need to encode spatial relationships, physics, temporal dynamics—everything VLMs throw away. This is why the memory infrastructure we're discussing matters for Physical AI. You can't run embodied intelligence on memory-starved chips. The 16-Hi HBM and stacked SRAM aren't just for chatbots generating tokens. They're for robots understanding the physical world.

Karpathy feels behind on software. Jim Fan is anxious about hardware-software alignment in robotics. Both are pointing at the same thing: capability is arriving faster than our frameworks can absorb it.

The abundance angle: Infinite inference means AI companions everywhere. A doctor in rural Kenya accessing diagnostic AI rivaling the best specialists. Every student with a personalized tutor that never tires. Scientific research accelerating as AI runs millions of hypothesis tests overnight. Democratization of intelligence—not as metaphor, but as infrastructure.

Elon Musk frames it more directly:

Am changing the Tesla mission wording from: Sustainable Abundance To Amazing Abundance

Dec 24, 2025 · 7:39 PM UTC

5,201
6,051
955
101,720
18,079,708

Musk has been consistent: "There will be universal high income—not universal basic income—universal high income. There'll be no shortage of goods or services." He predicts work becomes optional within 10-20 years.

But here's what Musk, Karpathy, and Jim Fan are all circling around: this abundance requires infrastructure. You can't run trillion-parameter models on today's memory-starved chips. You can't deploy video world models for robotics without terabytes of fast memory. You can't make everyone wealthy through AI if the AI can't actually run.

The 16-Hi HBM war, the 3D-stacked SRAM, the Groq licensing deal—this is the infrastructure layer that makes their visions possible.

The consolidation angle: But who controls this infrastructure? NVIDIA's architectural dominance means they set terms for how AI deploys. Every hyperscaler, startup, government AI initiative runs on their roadmap. The Groq deal shows NVIDIA absorbing potential disruption rather than competing with it. By 2030, "AI infrastructure" and "NVIDIA" may be synonymous.

The synthesis: Perhaps both are true simultaneously. The transistor democratized computation while Intel dominated for decades. The internet democratized information while a handful of platforms captured most of the value. AI may democratize intelligence while NVIDIA captures the infrastructure rent.

What's philosophically novel is the speed. Previous infrastructure buildouts—railroads, electricity, internet—took decades. NVIDIA is compressing the AI infrastructure buildout into a 5-year roadmap that's already visible. We can see the 2028 endgame today, in the 16-Hi HBM specs and the Groq licensing terms.

The question for 2030 isn't whether we'll have abundant AI inference. That's settled.

The question is what we'll build with it—and whether we're ready for a world where the limiting factor on intelligence is no longer silicon, but imagination.

Karpathy isn't behind. He's just realizing how fast the ground is moving.

Time to Accelerate!

Ben