HBM 之父金正浩：GPU 利用率仅 10%-30%，AI 的真正瓶颈是内存

AI芯片自研国产替代算力基建推理优化模型性价比端侧部署

2026-07-06 10:31

65 浏览

0 点赞

AI 速览

KAIST教授金正浩提出AI算力瓶颈在内存而非GPU，挑战传统以GPU为中心的叙事。核心事实 - 核心论断：AI推理中GPU实际工作时间仅占10%-30%，主要时间等待内存数据传输 - 架构演进：提出HBF（高带宽闪存）作为下一代大容量存储，替代或扩展HBM - 产业影响：若验证成立，将改变半导体投资方向，利好韩国存储厂商如SK海力士避坑提示 - 适用边界：该结论主要针对自回归推理场景，Prefill阶段和批量推理中GPU利用率较高 - 立场偏差：作者为HBM领域专家，观点可能偏向内存侧，需结合多方数据交叉验证价值点帮助理解AI推理阶段的性能瓶颈变化，预判未来算力硬件架构从计算向内存集成的转型趋势。

7月6日消息，韩国科学技术院（KAIST）教授、被称为"HBM 之父"的金正浩近日接受视频专访，系统性阐述了他对 AI 算力格局的判断。核心论断是：AI 的本质是内存而非 GPU，在推理过程中 GPU 的实际工作时间仅占 10% 至 30%，其余时间都在等待内存数据传输。这一观点直接挑战了以 GPU 为中心的 AI 算力叙事。金正浩的判断基于他在 HBM 领域超过十年的研究经历和对推理负载特征的分析，但"AI=内存"这一定性是否适用于所有场景，仍需与实际系统的瓶颈数据交叉验证。

"即使部署 100 万台 GPU，实际工作时间可能只有 10%"

金正浩在访谈中给出的核心数字是：即便部署 100 万台 GPU，实际有效工作时间可能只有 10% 至 20%，算法优化后最高不超过 30%。他的解释是，每当 AI 模型输出一个词，系统就需要从 HBM 中读取数据、传给 GPU 计算、再写回内存，读写过程几乎占满全部时间，GPU 在这期间处于空闲等待。

这一判断的背景是 AI 正在从训练时代转向推理时代。训练阶段 GPU 的算力利用率相对较高，数据可以提前分批加载、并行处理。但推理阶段的特征是实时、序列化输出，每步都依赖前一步的结果，内存的读写带宽直接决定了推理速度。金正浩认为，在推理主导的时代，"谁更强——Google、OpenAI 还是 Anthropic——是由内存决定的"。

从 HBM 到 HBF：他提出的下一代内存架构

金正浩将当前 HBM 类比为"手边的参考书"，承担短期高速数据存取功能。但 HBM 容量正接近物理极限。他更看好 HBF（高带宽闪存，High Bandwidth Flash），通过堆叠 NAND 闪存实现远超 HBM 的存储容量，充当 AI 系统的"长期记忆"。

他描述的最终架构形态是垂直堆叠的 3D 结构：底层为 HBF 提供大容量存储，中层为 HBM 提供高速数据传输，顶层放置 GPU 负责计算和散热。GPU 在这一架构中不再是核心主导者，而是嵌入内存系统中的计算组件。SK 海力士已提出相关"H3 架构"方案，将 HBF 定位为 HBM 的二级扩展存储。金正浩预计 HBF 工程样品将在 2027 年前后出现，最早到 2028 年可能被 Google、英伟达或 AMD 率先采用。

GPU 瓶颈论是否成立，取决于推理负载的实际构成

金正浩的论述在逻辑上自洽，但"AI=内存"的结论需要限定条件。他描述的 GPU 低利用率场景主要适用于自回归推理——逐词生成的序列化输出过程。在 prefill 阶段（一次性处理长输入）和批量推理场景中，GPU 的计算密度更高，内存瓶颈的严重程度有所不同。将推理阶段的特定环节推广为"AI 的本质"，存在以偏概全的风险。

但他指出的方向——GPU 在推理阶段利用率远低于训练阶段——有多方面的旁证。英伟达自身在 Hopper 和 Blackwell 架构中持续提升 HBM 容量和带宽的优先级，也侧面印证了内存正在成为系统性能的关键约束。金正浩作为 HBM 技术的核心参与者，他的判断天然偏向内存侧，这一立场应在引用时考虑在内。真正需要讨论的或许不是"AI 的本质是否是内存"，而是在推理规模持续扩大的趋势下，GPU 与内存之间的投资比例应如何调整。

接下来要看 HBF 的实际进展和英伟达的架构回应

如果金正浩的判断在实践中得到验证，最直接的影响将落在半导体产业投资方向上。SK 海力士和三星在 HBM 领域的领先地位可能延伸到 HBF 时代，韩国在全球 AI 供应链中的权重将进一步上升。英伟达需要回答的问题是：如果 GPU 利用率在推理场景中确实触顶，下一代架构是继续追求计算密度，还是转向以内存系统为中心的集成方案。HBF 的工程样品进度和英伟达下一代架构的内存配比，是验证"内存中心计算"是否成立的两个最近信号。

好文章，需要你的鼓励

# 报错信息分析与调试指南 ## 任务说明请分析用户提供的报错信息，推测可能的错误原因，并提供系统性的调试步骤。 ## 分析要求 1. **错误类型识别** - 确定是语法错误、运行时错误、逻辑错误还是环境配置错误 - 识别具体的错误类别（如空指针、数组越界、类型不匹配等） 2. **原因推测** - 基于错误信息中的关键线索进行合理推断 - 考虑常见的导致此类错误的编程场景 - 分析可能的代码问题或环境问题 3. **调试步骤** - 提供从简单到复杂的逐步调试方法 - 包括代码检查、日志添加、环境验证等具体操作 - 给出预防类似错误的最佳实践建议 ## 输出格式 - **错误类型**：[具体的错误分类] - **可能原因**： 1. [原因1] 2. [原因2] 3. [原因3] - **调试步骤**： 1. [步骤1] 2. [步骤2] 3. [步骤3] 4. [步骤4] - **解决方案**：[具体的修复建议] ## 示例 **输入**：【报错信息】 ``` TypeError: Cannot read property 'length' of undefined at processData (app.js:25:18) at main (app.js:10:5) ``` **输出**： - **错误类型**：运行时错误 - TypeError - **可能原因**： 1. 变量未正确初始化就被访问其 length 属性 2. 函数参数传递了 undefined 值 3. 异步操作中数据还未加载完成就尝试访问 - **调试步骤**： 1. 检查 app.js 第25行附近的变量声明和赋值 2. 在访问 length 属性前添加类型检查：`if (variable && variable.length)` 3. 使用 console.log() 输出相关变量的值确认其状态 4. 检查函数调用时传入的参数是否正确 - **解决方案**：在访问对象属性前先验证对象是否存在，或确保变量在使用前已被正确初始化。