Nvidia 通过自定义内存控制设计绕开 JEDEC HBM 标准

Nvidia 正在将内存控制移入内存堆叠结构，挑战 AI 处理器与其所连接内存之间的传统分工。“Nvidia 绕开 JEDEC HBM 标准”描述了这一转变，但需要限定：Nvidia 宣布的是一种自定义架构，而非行业标准的消失。其 NVHBM 设计面向高带宽内存（HBM），即置于 AI 处理器旁的堆叠式内存。

时点同样重要。Nvidia 于 2026 年 8 月 26 日宣布 NVHBM，随后 10 月 26 日的报道再次引发了市场对其标准化影响的关注。核心竞争在于 Nvidia 的协调式实现方案，与通过半导体标准组织 JEDEC 制定的广泛共享接口之间的较量。这一区别比将该公告视为突发性的行业断裂更重要。

对于加速器设计者和企业买家而言，问题很实际：更紧密的协调能带来什么，又会附带哪些依赖关系？AMD 提供了有参考价值的竞争坐标，而 Amazon 的 Annapurna Labs 是 Nvidia 首个公开点名的 NVHBM 合作者。这两项信息都不能证明整个市场已选择相同方向。

“Nvidia 绕开 JEDEC HBM 标准”实际意味着什么

已获证实的变化，关乎内存控制位于何处，以及由谁定义具体实现。

内存控制器负责调度和管理处理器与内存之间的数据交换。Nvidia 的设计将其自定义控制器置于 HBM 基底芯片内，即堆叠内存层下方的逻辑芯片。该公司将此描述为处理器封装内功能分配方式的改变。

Nvidia 的 NVHBM 公告介绍了一种面向多家内存供应商的共享实现方案，并将 Annapurna Labs 列为首个合作者。这为该提案带来了明确的合作伙伴，但合作本身并不能证明其已具备量产就绪条件。

公司规范与行业标准之间的区别需要谨慎对待。多家制造商可以依据由单一平台所有者控制的规范进行生产。因此，供应商多样性并不自动意味着该接口拥有与独立维护标准相同的治理模式或可移植性。

反过来，定制化也不能证明内存堆叠结构的每一部分都放弃了标准化技术。该公告支持的是一个更狭义的结论：Nvidia 正在定义一种替代性的控制器布局与集成路径。关于完全不兼容的说法，需要更多文档佐证。

应在这一边界下解读 10 月的报道。这项定制 HBM 设计之所以受到关注，是因为它转移了传统上与加速器相关的职责。标题捕捉到了战略性偏离，但并未证明 JEDEC 的退出，或全行业的替代。

这一差别改变了新闻判断。真正重要的发展，是 Nvidia 试图让其架构成为其他芯片设计者的集成选项。当外部公司围绕某种内存设计来组织自己的产品时，这种设计便具有战略意义。

架构方向的宣布与已部署系统的改变之间也存在差异。现有加速器无法通过软件更新获得这种布局。其收益取决于围绕新接口设计并完成验证的硬件。

因此，读者应区分公告日期、报道日期和最终产品上市日期。这些代表不同的里程碑。将它们混为一谈，会造成某项提案已成为出货中的市场标准的印象。

将“Nvidia 绕开 JEDEC HBM 标准”理解为一项架构和治理层面的主张时，这一表述最有用。若将其延伸为标准不再重要的主张，则会产生误导。下一个问题是，设计者为何会接受一条协调程度更高的路径。

定制加速器设计者面临新的集成选择

NVHBM 为芯片设计者提供了一条潜在捷径，同时也带来另一种需要评估的平台依赖。

构建定制加速器不只是选择计算电路。设计者还必须让内存、封装、电气特性和软件协同工作。经过验证的子系统具有吸引力，因为这些边界上的故障可能削弱一颗原本出色的处理器设计。

Nvidia 将 NVHBM 定位于 NVLink Fusion 之中，这是其将定制处理器纳入 Nvidia 互连基础设施的计划。考虑采用该路线的加速器设计者，必须在更广泛的平台关系之外，一并评估这种内存布局。即使技术上仍有区别，这些决策也会相互影响。

压力首先落在自行设计芯片的组织身上。它们必须决定哪些组件能形成战略差异化，哪些组件适合借助外部专业能力。内存集成正处在这条边界的核心位置。

拥有控制器意味着设计者直接承担一个重要子系统的责任。采用他人的实现方案，则可能将工程投入转向其他优先事项。两种选择都不会消除工作；它们只是改变了团队承担责任的位置，以及对合作伙伴形成依赖的位置。

设想一家为自身推理服务开发加速器的假设性云运营商，推理即运行已训练 AI 模型的过程。其团队可能优先考虑执行单元、软件支持和部署一致性。若共享内存实现能减少集成工作，同时不限制这些优先事项，它就会具有吸引力。

这仍是一项有条件的商业论点。该运营商需要获得有关文档、验证覆盖范围、供应商认证和长期支持的证据。单一的带宽标题数字，无法说明这种布局是否适合其开发进度。

内存制造商面临相关的选择。支持一项定制实现可以深化客户关系，但也会将工程投入绑定到特定架构。其商业价值取决于相关工作能够在多大范围内复用，以及产品能否可靠地交付给客户。

企业买家在更下游的位置体验这一选择。他们通常选择服务器、云实例或托管服务，而非内存控制器。他们受到的影响会体现在可用性、支持的配置、迁移选项以及成品系统的性能特征上。

拥有多家内存供应商的平台或可提供有用的制造灵活性。但这种灵活性未必延伸到将加速器设计迁移至另一种控制器架构。采购团队应分别评估这些不同形式的灵活性。

因此，眼前的压力是一项设计决策，而不是被迫进行的替换周期。规划未来硬件的组织必须比较集成式开发路径与保留更多子系统选择控制权之间的差异。现有客户在改变基础设施计划前，需要产品层面的具体证据。

这也解释了为何公开点名的合作者比未具名的意向表达更重要。Annapurna Labs 为观察者提供了一个可关注实现细节的对象。决定性的证据将关乎最终建成、支持和交付的内容。

Nvidia NVHBM 将硅片资源分配置于论证核心

其技术论据建立在重新分配稀缺的处理器资源之上，而非仅仅连接更快的内存。

计算芯片是包含处理器主要电路的硅片。分配给内存控制功能的空间，无法同时容纳其他电路。将这些功能移往别处会改变设计者的资源分配选择，但不会将这些功能从系统中移除。

据 Nvidia 称，NVHBM 可提供最高 30% 的内存带宽提升、15% 的 HBM 功耗降低，以及最高 25% 的额外计算芯片面积。其比较对象为标准 HBM4E，即增强版 HBM 世代。这些是公司主张，而非经独立验证的应用结果。

每个数字的分母不同。带宽衡量单位时间内传输的数据量。HBM 功耗针对内存子系统。可用计算芯片面积则涉及布局机会。它们都不能直接替代整体系统速度或设施总能耗。

最有力的架构论据在于，这些资源会相互作用。处理器需要足够的数据传输，才能让其执行电路持续发挥作用。当内存访问仍是限制因素时，额外电路的价值有限；而在其他条件受限时，额外带宽的价值同样有限。

这种相互作用使工作负载选择至关重要。受内存限制的工作负载会花费大量时间等待数据传输，而非执行算术运算。这类工作负载可能会受益于更高的可用带宽，但其实际响应仍取决于完整系统。

例如，假设性的模型服务部署可能在生成响应时反复获取模型数据。另一种部署则可能花费更多时间在处理器之间通信。同样的内存改进会对这两类部署产生不同影响。

Nvidia 的 NVHBM 架构还介绍了一种更小的自定义 PHY，即在芯片之间传输信号的物理接口电路。该公司将这一重新设计与降低集成约束联系起来。其更广泛的性能主张仍需依据具体工作负载进行评估。

这种迁移并不会让控制器消失。它改变的是设计者制造、验证和连接控制器的位置。分析应当追踪工作如何跨越封装边界，而不应将腾出的处理器空间视作系统复杂性的整体消除。

回收的空间也代表一种机会，而非成品规格。设计者必须决定在其中放置什么，并确认最终布局是否满足其他约束。更多可用面积并不会自动转化为成比例增加的有效计算能力。

同样，更低的内存功耗并不能证明服务器功耗会以相同比例下降。其他组件仍在消耗能源。供应商也可能将部分效率收益用于提升吞吐量，而不是降低系统总能耗。

这些区别解释了为何不应将这些百分比相加，得出一项综合收益。它们描述的是不同属性，并且可能存在重叠影响。买家需要的是在可比运行条件下测得的结果，而不是对无关联主张进行算术运算。

由此形成的论点很具体：Nvidia NVHBM 试图改善内存访问、处理器面积与子系统功耗之间的平衡。该平衡能否造就更好的商业化系统，仍取决于产品和工作负载。

标准 HBM 与定制 HBM 并非互斥的未来

定制化创造了另一条设计路径，但并不能证明广泛共享的内存接口已经走到终点。

Micron 在 Nvidia 宣布 NVHBM 之前，就已描述过面向客户的基础裸片定制。其 2025 年 9 月的 HBM4E 开发资料讨论了标准产品和定制选项，并将 TSMC 列为基础逻辑裸片的制造合作伙伴。

这段历史之所以重要，是因为它将该提议置于内存供应商与处理器设计商加强协作这一更广泛趋势中。但这并不意味着每个定制内存项目都等同。所有权、接口、认证责任和获取条件都可能存在显著差异。

Micron 表示有意同时提供两种路径，也削弱了简单的替代叙事。供应商可以在推进定制化的同时，继续服务使用标准产品的客户。商业上的共存是可信的可能性，尽管其最终规模仍不确定。

JEDEC 的工作同样不止于维持不变的接口。其公开资料将 SPHBM4，即标准封装高带宽内存（Standard Package High Bandwidth Memory），列为实现 HBM4 级带宽的另一条路径。因此，该组织的内存标准为评估“标准化已无法应对封装约束”的说法提供了背景。

不应将 SPHBM4 和 NVHBM 视为可互换的名称。对改变内存集成方式的共同兴趣，并不能证明二者具有相同的架构或认证要求。直接比较需要各项实现的技术文档。

AMD 提供了一个具体的竞争参照，但并非完美的实验对照。其 MI350 内存规格列出 288GB HBM3E 内存和最高 8TB/s 的理论峰值带宽。这些公开规格描述的是不同的产品和内存代际。

关键启示在于，加速器竞争已同时涉及内存容量、带宽、计算设计和软件。仅孤立地考察一项预期改进，无法得出架构比较的结论。完整系统必须运行可比的工作负载。

AMD 的规格还说明了，买方为何应避免将已出货的配置与尚未明确的未来基线进行比较。容量和理论带宽是有用的起点，但本身无法揭示应用吞吐量、利用率或运营适用性。

这正是核心矛盾变得清晰之处。共享的行业接口支持不同路线图的组织之间进行协作。由平台定义的实现，则可以围绕一组更具体的假设追求更紧密的优化。

这种权衡并不意味着任一路径在所有情况下都更优。需求特殊的芯片设计商可能重视直接控制；另一家则可能更倾向于成熟的集成方案，以便团队将精力集中在其他方面。

对于企业而言，只要评估保持严谨，实现方式的多样性可能是有益的。买方可以比较每种设计带来的后果，而不是根据规格是否冠以标准机构名称来作出选择。更难的问题是：在系统的有效生命周期内，哪些依赖关系仍可接受。

因此，标准讨论应纳入对产品成熟度和架构控制力的更大范围评估中。在可比系统出现之前就宣布胜负，只会以品牌竞争取代技术分析。

性能主张留下了重要的未解问题

现有证据对设计方向的支持，比对普遍性能或供应链结果的支持更为有力。

“最高可达”意味着特定条件下的上限，并不描述每位买方都应预期的结果。若没有匹配的基线和工作负载说明，将这一上限套用于现有部署只能是推测。

所审阅的公告并未针对每一种商业场景，建立可独立复现的比较。即使相关机制听起来合理，这一限制也应保持可见。合理性与已证明的收益，属于不同的证据阶段。

一项有用的基准测试应说明处理器配置、内存配置、软件环境和工作负载，还应解释比较是否保持容量、功耗限制和运行条件不变。否则，读者无法分离表面改进的来源。

延迟，即响应或操作完成前的等待时间，与吞吐量同样重要。一个整体处理更多工作的系统，仍可能无法满足交互式服务的响应要求。只要会影响采购决策，性能报告就应同时披露二者。

同一原则也适用于功耗。买方需要清晰的测量边界，以及对工作负载实际完成内容的说明。若其他环节增加的活动抵消了节省，单个组件的较低功耗意义有限。

集成方面也存在未解问题。采用定制控制器的内存堆叠，需要设计、制造、封装和验证责任方之间的协调。商业安排必须使故障处理和支持义务保持可控。

这些是需要调查的问题，并非架构存在缺陷的证据。公开公告往往早于详细的实现信息。恰当的做法是指出缺失的证据，而不是将每一个未披露参数都转化为假定的问题。

供应商参与也需要类似的精确表述。建立多来源供应的意向，不同于多家供应商已完成认证；认证又不同于可靠的大批量供货。每个里程碑降低的是不同类型的不确定性。

获取条件同样重要。若客户无法获得所需的文档或支持，即使子系统在技术上很有吸引力，也只能提供有限的战略灵活性。反之，明确的支持承诺可能使协调的平台比独立组装每个组件更具可行性。

因此，商业集中度应通过具体依赖关系来评估：哪家组织控制版本修订？谁验证替换件？组件发生变更时会怎样？这些问题比笼统地将架构描述为开放或封闭更能揭示实情。

“Nvidia 绕过 JEDEC HBM 标准”这一表述并不能回答这些问题。它指出了一种方向转变，但其后果取决于实现细节。若将标题视为已成定局的市场结论，就会抹去最重要的不确定性。

持审慎态度的立场很直接：Nvidia 已阐述了一项可信的优化策略，但买方仍需要可比产品和运营层面的证据。这是验证标准，而非对失败的预测。

什么能让 NVHBM 成为已获证明的平台优势

接下来的证据应将该架构与具名产品、已认证的供应来源及可复现的工作负载结果联系起来。

未来数月首先值得关注的信号，是来自 Annapurna Labs 或其他具名协作者的产品级细节。一项有价值的披露应明确实现方式、开发阶段和相关部署计划。缺少这些细节的另一份合作声明，能增加的证据较少。

这样的披露将强化外部芯片设计商看到了该安排实际价值的论点，也将显示这条集成路径能够支持某一具体产品。持续沉默则会让该公告的商业覆盖范围悬而未决。

第二个信号是供应商认证和供货信息。观察者应关注具名的内存供应商、清楚说明的验证里程碑，以及对同一目标实现的支持。这些细节将使 Nvidia 的多供应商目标更容易评估。

仅有供应商名称还不够。客户需要知道替代方案是否满足产品要求，以及切换是否需要进一步验证。可行替代方案的证据将强化韧性论点；认证未解决则会限制这一论点。

第三个信号是可复现的系统测试。最有价值的结果应在公开配置和运行限制下比较相关工作负载，并报告完成的有效工作量、响应表现以及具有清晰边界的功耗测量。

强劲的结果将把架构推理与客户结果联系起来。结果不一有助于识别该设计的适用场景。即使单个组件指标有所改善，若结果显示在相关工作负载下收益甚微，任何广泛优势的主张都将被削弱。

这些信号应按这一顺序评估，因为它们回答的问题逐步变得更难。产品确立实现目标；认证确立实际采购能力；工作负载测试则验证完整系统是否交付客户所需的收益。

这并不要求宣布 JEDEC 已无关紧要。一个行业可以同时支持通用标准和专门化实现，不同买方会选择不同的折中方案。证据将显示每条路径存在多少需求。

对开发者而言，有用的问题是：可获得的平台能否改善他们实际运行的工作负载。对企业买方而言，问题是这些改进能否经受采购、部署、支持和迁移要求的考验。架构之所以重要，是因为它塑造了这些结果。

在改变硬件路线图之前，应围绕这些问题建立证据档案。记录确切基线、工作负载、测量边界以及每项供应商承诺的成熟度。将厂商预测与独立复现的结果分开。比较公告和技术文档的团队，可以使用可搜索的知识库，在采购讨论中保留这些背景信息。当产品规格、认证更新或独立测量结果出现时，再重新评估。Nvidia 偏离传统 HBM 集成方式值得关注，但采购决策需要比架构标题更严格的标准。哪项已发布的结果能够证明你的工作负载获得了实质改进？又有哪些未解决的依赖关系会阻止部署？