A3 · Reasoning 模型普及让 HBM 容量需求结构性上一台阶 (但 token 口径需精细化)

命题表述

OpenAI o-series、Anthropic reasoning Claude、Gemini Deep Thinking 这类 test-time compute 模型, 显著增加 HBM 容量(而非仅带宽)需求。但需要精细区分:

• 可见输出 tokens: 非 reasoning 模型 ~500 tokens / reasoning 模型 ~5,000-50,000 tokens (思维链在内)
• 持续 KV cache 内存占用: 与 batch size, context length, model 大小, KV cache 压缩技术(GQA, MQA, paged attention, prefix caching)综合相关
• 每 query KV cache 需求: 当前 200K context Llama-70B 单 query ~10GB, 1M context 50GB+

不能简单把"输出 50,000 tokens" → "HBM 容量需求 100x"。两者关系受多个对冲因素调节: speculative decoding、KV cache compression、prefix caching、MoE routing 都可能在某种程度上缓解 HBM 容量压力。

但即使考虑所有缓解因素, reasoning workload 占比上升仍然会显著提升 HBM 容量需求 — 这是 A1、A2 命题的关键驱动机制。

概率档位说明: v1 给的是 yes, v2 仍维持 yes 但更靠近 yes / neutral 边界 — 主要不确定性在于 KV compression 等技术能在多大程度上缓解容量压力。

概率档位历史

关联机制

• reasoning_workload: Reasoning 模型作为新的工作负载类型
• kv_cache_scaling: KV cache 与 context length 和 batch size 的关系
• test_time_compute: 推理时计算的范式转变

关联指标

• reasoning_workload_share: Reasoning model 在 LLM API 调用中占比 (估算)
• avg_context_length: 商用 LLM 平均 context 长度
• kv_cache_per_query: 单次 query 平均 KV cache 占用

交易表达

• long_hynix_leaps: HBM 容量需求超预期受益最大
• long_hbm_capacity_thesis: 偏好高容量 HBM 产品的设备/制程提供商

复盘锚点

每季度跟踪 OpenAI / Anthropic / Google 公开披露的 reasoning model 使用占比。如果占比 12 个月内未超过 30%,reconsider 命题档位。

修订说明 (v2 vs v1)

专家反馈采纳: 完全采纳 — "50,000 tokens 不能直接等同于持久 KV cache。要拆成 average generated tokens、context length、batch size、KV compression、prefix caching、MoE routing、speculative decoding"。