clm_758d6f0299704d7cad84906cbe812533_r1

2025-08-12_scaling-the-memory-wall-the-rise-and-roadmap-of-hbm::HBM25-0024

① SA Source

• Source: 開啟完整 SA 文章
• Section: Bandwidth beats capacity
• Line hint: 209

Context Before

The rest of this piece will discuss OpenAI’s ASIC project, shoreline area challenges, the revolutionary change coming to HBM4 with custom base dies for HBM, the advantages on PHYs, memory controller offload, repeater PHYs, LPDDR + HBM combos, and various beachfront expansion techniques. It will also discuss SRAM, compute under memory, supply chain implications, and Samsung’s struggles.

Bandwidth beats capacity

Evidence

Although every accelerator has strived to design in the most HBM that is attainable, we understand that OpenAI’s ASIC project is going to break this trend. OpenAI is choosing to use 8-Hi HBM4 instead of opting for 16-Hi or even 12-Hi HBM.

Context After

This is because OAI sees 8-Hi offering a much better ratio of bandwidth to capacity at the given cost. Capacity is important, but for inference bandwidth is most often the constraint. With 8-Hi stacks, OAI gets the same bandwidth but at less than half the price per stack. The demands on memory capacity is relieved by the direction of OAI’s inference setup involving high-rank expert parallelism. This involves sharding the individual model experts across a much larger number of GPUs. Spreading the experts thinly leaves much more memory capacity available for KVcache while bandwidth is still the constraint. This is not a free lunch and there are tradeoffs in this equation: increasing world size and sharding workloads across many GPUs is more taxing on the network, a trade-off now faced across the entire industry as more firms adopt high-rank expert parallelism, and this underscores why I/O remains fundamental to everything.

However, this shouldn’t be interpreted as a leading lab calling time on the trend of HBM capacity scaling. OAI will focus more on improving the software, micro-architecture, networking within the broader system so that future generations can become performace/TCO competitive with merchant solutions. Reducing memory costs is a good way to reduce the investment without compromising on the other surface areas for improvement and adding more capacity with higher layers is relatively trivial. OpenAI will still be dependent on GPUs in that timeframe. Rubin Ultra will be there with abundant capacity as model architects will no doubt try to find ways to consume this additional capacity to extract more intelligence. Going for lower capacity is a cheaper, and relative lower risk way for OpenAI to explore different cost and performance tradeoffs for their accelerator.

② Atomic Claim

SemiAnalysis 表示 OpenAI ASIC 將選擇 8-Hi HBM4，而非 12-Hi/16-Hi HBM。

• Epistemic Mode: EXPECTED
• Mapping Status: COMPLETE

③ Semantic Frame

{
  "frame_type": "NARY_RELATION",
  "participants": [
    {
      "node": {
        "id": "02_companies/OpenAI",
        "label": "OpenAI"
      },
      "role": "designer"
    },
    {
      "node": {
        "id": "04_knowledge_base/HBM4",
        "label": "HBM4"
      },
      "role": "memory"
    },
    {
      "node": {
        "id": "04_knowledge_base/ASIC",
        "label": "ASIC"
      },
      "role": "accelerator"
    }
  ],
  "qualifiers": {
    "condition_text": "chooses 8-Hi instead of 12/16-Hi",
    "numeric_mentions": [
      "8-Hi",
      "16-Hi",
      "12-Hi"
    ],
    "temporal_mentions": []
  },
  "relation_type": "OPENAI_HBM4_STACK_CHOICE"
}

④ Canonical Entity Mapping

Role	Surface Label	Canonical Target
designer	OpenAI	OpenAI
memory	HBM4	HBM4
accelerator	ASIC	ASIC

⑤ Human Review

請在 Properties 逐項確認：

• 原文 → Atomic Claim 是否忠實
• Atomic Claim → Semantic Frame 是否忠實
• Canonical Entity mapping 是否正確
• Epistemic mode 是否保留原文語氣
• 最後選擇 review_action

Review state

Markdown 內文不是正式 approval。只有 Apply bridge 寫入的 Decision Ledger event 才是正式決策。