SK hynix AI 基础设施分析称：架构如今决定性能上限

SK hynix 正围绕一个直接矛盾重新定义其 AI 基础设施战略：更快的处理器已不再必然带来更快或更高效的 AI 服务。其 10 月 2 日发布的分析认为，内存所处位置、互连设计以及数据移动方式，如今决定了应用实际能够利用多少加速器性能。

这一结论反映出 AI 工作负载的变化。训练仍需要庞大的计算资源，但生产环境的投入正越来越多地流向推理、长上下文、推理循环以及持续运行的 AI Agent。这些工作负载需要反复检索模型权重、中间结果和已存储的上下文。

因此，主要竞争已不再是芯片厂商之间的较量，而是以处理器为中心的设计与以内存为中心的架构之争。NVIDIA、云服务提供商、内存制造商和系统构建商都在作出回应，尽管它们掌控的是技术栈的不同部分。

SK hynix AI 基础设施分析重新定义瓶颈

重要变化并非来自一款新的 SK hynix 芯片，而是对 AI 性能定义的扩展。

该公司最新的infrastructure analysis将计算视为更大数据路径中的一个环节。信息从存储进入内存，穿过缓存与互连，最终流向加速器；结果随后又会沿着这一层级中的部分路径返回。

每一次传输都会增加延迟并消耗能量。当 GPU 花时间等待数据或与其他加速器交换信息时，更快的 GPU 无法消除这些成本。

这一论点挑战了塑造通用计算的、以处理器为中心的模型。该模型将数据送往中央处理器，执行所需操作，再将结果移往其他位置。缓存、预取、多线程和乱序执行有助于掩盖延迟，但也增加了软硬件复杂性。

SK hynix 表示，这种失衡已变得严重。该公司援引研究估计，一次 DRAM 访问所需能量可能是一项简单算术运算的 150 至 2,000 倍。它还援引研究称，对于大型机器学习模型，内存访问和数据移动消耗的系统能耗超过 90%。

这些数字并不适用于所有模型或部署。不同芯片、内存技术、精度格式和工作负载模式会产生不同结果。但它们仍说明了为何提升算术吞吐量，可能只能带来令人失望的系统级收益。

大语言模型推理让这种失衡更容易观察。每生成一个 token，模型都需要读取权重，并查阅处理先前 token 时生成的信息。更强的推理能力并不会消除这一行为，反而往往会延长序列，并增加需要保留的状态量。

键值缓存，即 KV cache，会存储先前 token 的注意力数据，使模型无需重新计算整个上下文。它节省了计算，但会占用内存；其规模也会随着上下文变长和并发会话增多而扩大。

这带来了与模型训练不同的容量问题。训练集群通常可以处理规模庞大且预先规划的批次，而推理服务必须应对不可预测的请求、不同的上下文长度以及面向用户的延迟目标。

Agentic 应用又增加了一层复杂性。一个 Agent 可以生成文本、调用工具、等待结果、将结果加入上下文，然后开始下一轮推理。加速器可能会在高强度处理与空闲状态间交替，而其会话数据仍然具有价值。

NVIDIA 在自身的agentic inference材料中也描述了同样的压力。它将 KV cache 增长、不规则的工具等待以及较低 GPU 利用率视为长时间运行 Agent 的基础设施问题。

两家公司从不同的商业立场切入这一问题。NVIDIA 销售加速计算平台，而 SK hynix 提供为这些平台供给数据的内存产品。不过，它们的诊断结论仍有重叠：有用的性能取决于处理器、内存、存储、网络和软件之间的协调。

SK hynix 也在提出一项战略主张。如果内存成为一等设计要素，内存供应商将获得更大的系统架构影响力。它们的作用不再仅限于提供容量或带宽更高的组件。

因此，这项发布更像是对竞争走向的声明，而非一次产品发布。SK hynix 希望买方评估完整的数据路径，而不是孤立的处理器规格。

这一变化构成了本文的核心张力。AI 基础设施的采购与营销长期围绕计算能力展开，但推理经济性正日益取决于能否持续为这些算力供给数据。

推理让内存成为限制性资源

推理将优化目标从完成最大规模计算，转变为以可接受的系统成本交付响应迅速的 token。

训练任务消耗大量电力和算力，但有明确的起点和终点。推理则是一项持续运行的服务。每个用户提示都会带来时限、状态和数据移动，运营者必须持续管理这些因素。

聊天机器人已经需要反复访问内存，因为语言模型一次只生成一个 token。推理系统可能在给出最终答案前生成许多内部 token。Agent 则可能跨多个工具和外部数据源重复这一过程。

上下文长度会进一步加重负担。模型必须保留其注意力层之后可能会使用的信息。注意力层决定了可用上下文中的哪些部分对下一次计算具有重要性。

KV cache 避免了重复此前的注意力计算，但代价是将压力转移至内存。容量决定能够保持活跃状态的会话数量，带宽则决定系统能够多快地检索这些会话的状态。

高带宽内存，即 HBM，解决了其中一部分问题。HBM 通过垂直堆叠内存芯片，并将高带宽内存置于加速器附近。这种布局能够比距离处理器更远的传统内存更快地提供数据。

SK hynix 显然有理由强调 HBM，因为它是主要供应商之一。不过，该公司并不认为仅靠 HBM 就能解决瓶颈。其分析指出，完整路径还必须包括存储、网络、内存控制器和互连。

这一限定很重要。当数据位于较慢层级，或必须跨越拥塞链路时，昂贵的加速器仍可能处于等待状态。在加速器旁增加更快的内存，只会改善真正使用该内存的数据传输。

容量也可能与速度发生冲突。最快的内存层级资源稀缺，且为每个活跃会话配置的成本很高。较慢的 DRAM 和存储提供更多容量，但在层级之间移动缓存上下文可能引入延迟。

因此，生产系统需要部署策略。频繁复用的信息应保留在加速器附近；不活跃的上下文可以移往其他层级，前提是系统能在模型再次需要它之前将其取回。

NVIDIA 的cache management文档将缓存复用和路由描述为核心优化目标。请求应被发送至已持有有用上下文的工作节点，从而减少不必要的传输和重复计算。

这使服务软件成为架构论点的一部分。硬件提供容量和传输路径，但软件决定模型状态存放在哪里，也决定状态何时移动以及由哪个处理器处理下一个请求。

因此，运营衡量单位也发生变化。每秒请求数仍然有用，但无法完整描述一个会执行多次顺序模型调用的 Agent。运营者还需要理解 token、活跃上下文、缓存复用、延迟和硬件占用率。

压力落在云服务提供商和企业基础设施团队身上。他们必须依据工作负载行为进行配置，而非只看加速器数量这一醒目指标。一个失衡的集群可能拥有可观的算力，却只能提供较低的 token 吞吐量。

开发者同样会受到影响。长期保留每一段对话的应用可能会推高内存需求。反复发送大型提示，或在工作节点之间随机转移请求的 Agent 设计，可能会削弱缓存复用效果。

这并不意味着开发者必须成为芯片架构师，而是意味着应用行为如今会更直接地影响基础设施效率。上下文管理、请求路由和模型选择，都可能改变应用底层的数据移动量。

工程团队还需要保留能够将应用决策与观察到的基础设施行为关联起来的记录。可搜索的engineering knowledge base可以跨团队保留基准测试假设、部署变更和事故发现。

更大的影响在于经济性。买方不能仅凭峰值每秒运算次数估算推理效率。他们必须了解当上下文增长、会话暂停以及请求争夺内存时，系统会如何运行。

这正是 SK hynix 的 AI 基础设施论点此刻具有重要意义的原因。推理让架构从实现细节变成产品成本与响应能力的一部分。

真正的竞争是架构与组件速度之争

主要对手并非另一家内存供应商，而是“更快的单个组件会自动带来更快 AI 系统”这一信念。

组件改进仍然重要。更快的加速器能更早完成算术运算，更高带宽的内存能更快地为其供给数据，更好的网络能在节点间移动信息。问题出现在买方将这些规格视为彼此独立、能够简单叠加时。

系统性能取决于最慢的关键路径。当处理器在等待模型权重时，即使算术单元闲置，也不会创造价值。如果其连接无法按所需速率提供数据，增加内存容量同样无济于事。

以处理器为中心的系统试图通过日益复杂的机制加以补偿。多级缓存将频繁使用的信息保留在计算资源附近；预取器预测下一步所需数据；并行线程帮助处理器在停顿期间执行其他工作。

这些方法仍然有用，但 AI 工作负载暴露了它们的局限。模型参数和上下文可能超出本地缓存容量。访问模式会在预填充、token 生成、检索、工具执行和多 Agent 协作之间变化。

以内存为中心的计算从另一个问题出发。架构师不再首先询问数据能够多快抵达中央处理器，而是询问数据已经位于何处。随后，他们围绕该位置布置计算资源和传输路径。

这种方法并不要求每项操作都在内存内部完成。有些数据适合存放在 GPU 旁的 HBM 中，另一些信息可以驻留于由多台设备共享的池化内存中。某些操作则可以在靠近内存的加速器上运行。

具体采用何种安排取决于工作负载。模型架构、批处理大小、上下文长度、延迟要求和并发请求数量都会改变其中的平衡。网络拓扑和软件调度还会进一步改变这一平衡。

这种可变性解释了为何可重构基础设施会受到关注。固定服务器配置会按预先设定的比例捆绑处理器和内存。当一种资源耗尽时，另一种资源可能仍未被充分利用。

解耦系统将资源拆分为资源池。CPU、加速器、内存、存储和网络可以围绕工作负载需求进行组合。内存密集型服务可以从更大的资源池中获取容量，而不必复制其他所有组件。

资源池化并非没有代价。远程访问通常会增加延迟并占用互连带宽。共享资源也可能成为新的争用点。只有当灵活性节省的成本超过通信成本时，这种架构才能成功。

这正是 SK hynix 论点中的核心转变。更快地传输更多数据并不总是最佳答案。更好的设计可能是根本避免移动数据。

随着 AI 转向推理，这一原则变得更加重要。训练偏向于具备高计算密度的大型同步集群。推理则呈现出多样化的请求形态，以及更严格的响应时间要求。

同一套基础设施可能同时服务于短提示词、文档分析、代码生成和长时间运行的智能体。每种工作负载对内存容量、带宽、存储和通信的需求都不同。

静态集群可能针对一种配置进行了优化，却在另一种配置上表现不佳。可重构的资源部署有望提高利用率，但它同样需要强大的编排软件。缺乏智能调度的硬件灵活性，可能只是将瓶颈转移到了别处。

NVIDIA 自身的设计表明，加速器厂商已经认识到这一问题。其 NVLink fabric 通过专用高带宽路径连接 GPU，使其能够超越普通外围接口进行协同。

这并不否定 SK hynix 的立场。它反而证实，处理器性能日益依赖于内存和通信架构。竞争的关键问题在于：谁控制这一架构，以及其组成部分能够以多开放的方式互操作。

专有的纵向扩展互连网络可提供高度集成的性能。开放互连标准则可提供更广泛的设备选择与内存扩展能力。没有任何一种方式能自动在所有工作负载中胜出。

云服务提供商可能会同时采用两种方式。紧密连接的加速器可处理通信密集型模型操作，而池化内存则支持更大的上下文或活跃度较低的数据。对于能够容忍更长检索时间的信息，存储可以提供另一层容量层级。

因此，不应将以处理器为中心和以内存为中心的标签理解为绝对分类。现代系统结合了两者。真正有意义的区别是，设计将哪一种成本视为根本限制。

以处理器为中心的设计假定计算资源稀缺，因此将数据移动到计算资源附近。以内存为中心的设计则将数据移动视为稀缺资源，因此将更多计算部署在数据周围。推理正在强化第二种假设。

CXL、NVLink 和近内存处理如何分工

没有任何单一互连技术或加速器能够解决数据问题，因为内存扩展、GPU 通信和本地处理承担着不同功能。

Compute Express Link，即 CXL，提供了处理器、加速器和内存设备之间具备缓存一致性的连接。缓存一致性使组件能够对共享数据保持一致视图，而无需手动复制每一次更新。

CXL 可以支持内存扩展和资源池化。系统能够提供超出单个处理器物理直连内存之外的容量。当平台和软件支持这种安排时，多个设备也可以从共享资源中获取容量。

这种灵活性旨在解决闲置容量问题。一台服务器或加速器可能缺少内存，而另一台设备却有未使用的空间。资源池化创造了根据当前工作负载分配容量的机会。

CXL 还支持将内存与本地处理相结合的设备。近内存设备无需将完整数据集发送到中央加速器，而是可以在本地执行部分操作，随后返回更小的结果。

NVLink 和 NVSwitch 则处理系统的另一部分。NVLink 在 NVIDIA 处理器和加速器之间提供高带宽连接。NVSwitch 扩展这些路径，使更大规模的 GPU 群组能够通过交换网络进行通信。

大型模型通常会将参数和中间值分布在多个加速器上。这些设备必须交换激活值、部分结果和同步消息。通信缓慢会削弱增加更多 GPU 所带来的收益。

因此，CXL 强调灵活的内存访问和扩展，而 NVLink 强调高度协同的加速器通信。它们可以服务于同一个更广泛的目标，但并不承担相同角色。

近内存加速将这一设计进一步推进。计算被移入内存设备内部或其附近，从而减少在系统中传输的数据量。当操作能够以有限通信在本地运行时，这种方式最为有效。

Tesseract 提供了一个较早的研究案例。其设计者将处理单元分布在 3D 堆叠内存附近，并在这些单元之间划分图数据。每个单元处理本地数据，仅在必要时交换消息。

2015 年的 Tesseract study 报告称，在五种图工作负载中，平均性能提升达到十倍。该研究还称，与所评估的传统系统相比，平均能耗降低了 87%。

这些结果来自图处理，而非现代生产级语言模型服务。该实验仍展示了这一架构原则：当处理能力和内存带宽同步增长时，性能可以随之扩展。

一个较新的项目将类似理念应用于语言模型推理。CENT，即 CXL-Enabled GPU-Free System，将 CXL 内存扩展与位于内存库附近的处理单元结合起来。

同行评审的 CENT research 报告称，在相近平均功耗下，其相对于选定 GPU 基线实现了 2.3 倍更高吞吐量和 2.3 倍更低能耗。该研究还称，每美元可生成的 token 数量提升了 5.2 倍。

这些数字需要谨慎解读。它们描述的是作者建模和评估的架构、工作负载、基线和假设。它们并不能证明无 GPU 推理已准备好取代主流加速器部署。

不过，CENT 对主导性设计提出了压力测试。自回归推理会逐个生成 token，其算术强度通常低于训练。算术强度衡量的是每移动一个单位数据所完成的计算量。

算术强度低的工作负载可能受内存限制。当内存无法足够快地供应数据时，增加更多计算单元的收益有限。专用近内存设计可以针对这种不匹配进行优化。

架构上的问题在于：能够迁移多少工作而不产生新的协调成本。注意力机制、模型层和分布式通信无法完美划分。部分操作仍需要来自多个设备的结果。

编程支持也构成另一项障碍。开发者已依赖成熟的 GPU 框架、优化内核和部署工具。新的近内存架构必须与这些软件集成，或证明高成本迁移是合理的。

可观测性也会变得更加困难。分布式系统可以在加速器、内存控制器和存储层之间移动计算。运维人员需要了解在整条路径中，时间和能耗分别消耗在何处。

安全边界同样需要关注。共享内存池必须隔离不同工作负载和租户。持久化的智能体上下文可能包含敏感提示词、检索到的文档、凭证或工具结果。

这些问题并不否定这一设计。它们说明，架构决定的不只是基准测试速度。可靠性、隔离性、可编程性和调度能力，都是生产性能的一部分。

研究结果并非生产证明

以内存为中心的设计拥有可信证据支持，但最强的结果仍然高度依赖具体工作负载，无法保证部署经济性。

SK hynix 的文章结合了已发表研究和行业预测。这些研究支持“数据移动可能主导能耗和延迟”这一主张，但并未证明某一种架构将成为标准。

Tesseract 展示了图工作负载上的近内存处理。CENT 则评估了一种面向语言模型推理、雄心勃勃的 CXL 架构设计。两者都有助于确立技术可行性，但生产服务会引入研究原型无法完全复现的限制。

真实部署需要支持不断变化的模型、精度格式、上下文策略和延迟目标。它们还要应对故障、软件升级、嘈杂邻居和流量峰值。任何架构都必须在这些条件下保持性能。

比较结果可能高度依赖于所选基线。批处理或缓存复用能力较弱的 GPU 平台可能显得效率低下。高度优化的服务栈则可以在不改变底层硬件的情况下提高利用率。

模型演进带来了另一项不确定性。能够缩小 KV 缓存的技术可能减轻内存压力。量化通过使用更少的位来表示数值，可以缩小模型和缓存占用空间。改进的注意力机制能够改变访问模式。

软件同样可以避免不必要的数据移动。前缀缓存会复用共享的提示词片段。缓存感知路由会将相关请求导向持有相关状态的工作节点。解耦的预填充和解码会将不同阶段分配给专门的资源池。

NVIDIA 的 multi-tier cache 方法将 KV 数据分布在 GPU HBM、CPU 内存、本地 NVMe 存储和远程存储之间。这是一种围绕 GPU 基础设施构建的、以内存为中心的应对方式。

这对于竞争格局的理解很重要。以内存为中心的计算不一定会取代 GPU。它可以通过减少 GPU 在数据管理上消耗的工作量，提升 GPU 的有效利用率。

近内存处理器还面临制造和标准化问题。增加逻辑可能影响面积、热特性、良率和产品成本。新设备需要稳定的接口，云服务运营商才能大规模部署它们。

CXL 带来了灵活性，但 CXL 连接并不等同于本地 HBM。容量、带宽和延迟处于不同位置。工作负载部署必须尊重这些差异。

解耦可以提高资源利用率，同时增加通信量。若远程资源池服务于过多设备，可能会出现拥塞。位置不当的操作可能比在固定服务器中传输得更远。

因此，若按字面理解，SK hynix 主张中最强的一种表述过于宽泛。架构不能取代组件性能。缓慢的处理器、薄弱的内存或受限的网络，均可能限制系统。

更站得住脚的结论是，架构决定了有多少组件性能能够真正被利用。更快的组件依然具有价值，但其价值取决于数据部署和协调方式。

商业激励也应纳入解读。SK hynix 会在客户将内存视为战略性系统资源时受益。NVIDIA 则会在客户采用高度集成的加速平台和专有互连网络时受益。

这些激励因素并不意味着任何一方的论点就是错误的。它们只会让独立基准测试变得更加重要。买家需要能够反映其模型、会话时长、请求模式和可靠性要求的测试。

成本比较不应只涵盖硬件采购。电力、散热、机架空间、利用率、软件开发、运维和迁移都会影响总成本。专用设计可能节省能源，却需要更多工程支持。

基准测试还应报告尾延迟，即衡量响应时间分布末端较慢请求的指标。平均吞吐量可能掩盖用户能够直接感受到的停顿。

持续运行的智能体带来了更多问题。让上下文保持在近处可以提升响应速度，但空闲会话会占用稀缺的内存。激进的驱逐策略能够节省容量，却会在智能体恢复运行时迫使系统进行高成本重载。

这种权衡类似于计算领域其他场景中的缓存机制，但其规模更大。单个会话可以保留大量上下文和中间状态。数千个并发智能体会让数据放置策略成为一项重大的容量决策。

持怀疑态度的观点并非认为以内存为中心的计算没有价值，而是认为尚未形成一种通用布局。工作负载差异过大，技术栈也仍在持续变化。

SK hynix 展示的是一个方向，而非对现有数据中心的完整替代方案。接下来的证据必须来自可部署的产品、可互操作的系统，以及可复现的工作负载级测量结果。

三个信号将揭示以内存为中心的 AI 能否胜出

只有当新系统能将更少的数据移动转化为真实推理工作负载中可衡量的收益时，这一论点才会得到强化。

第一个信号是围绕池化和分层上下文内存的产品级集成。应关注那些能够在 HBM、DRAM 和存储之间管理 KV 缓存、而无需应用程序处理每一次传输的系统。

关键指标并非理论容量，而是这些系统能否在支持更多并发会话的同时维持延迟水平。较高的缓存命中率和可预测的尾延迟，将支持“架构优先”的论点。

如果上下文经常迟到，这一论点就会被削弱。额外容量将以响应速度为代价。运营商可能会倾向于更多本地内存，或更简单的固定配置。

第二个信号是 CXL 内存池化和近内存处理的更广泛部署。仅靠发布公告无法定论。买家需要可互操作的硬件、操作系统支持、编排工具和应用框架。

成功的部署应证明，共享容量能够提高利用率，而不会压垮互连网络。它们还应记录隔离机制、故障处理方式，以及混合工作负载下的性能表现。

如果 CXL 仍局限于狭窄的扩展角色，以内存为中心的架构仍会推进，但其可重构愿景的发展将更缓慢。专有纵向扩展互连可能继续在高性能部署中保留更多控制权。

第三个信号是衡量完整系统的独立推理基准测试。测试应包括长上下文、多轮智能体、工具等待、缓存驱逐和并发用户。

峰值算力吞吐仍将具有参考价值，但应与 token 延迟、每 token 能耗、内存利用率和网络流量一同呈现。买家还需要来自变化工作负载的结果，而不是某一个经过精心挑选的模型。

若能在多个模型家族中获得证据，将强化 SK hynix 的 AI 基础设施论点。若结果仅限于一种架构或合成流量，则仍会留下更大的不确定性。

读者还应关注厂商之间职责如何转移。内存制造商可能提供更多逻辑、固件和参考架构。加速器公司则可能扩大对存储和上下文管理的控制。

云服务提供商很可能会结合这两种路径。他们可以在加速器、内存池和存储之间构建专有编排层。其规模使其拥有足够的工作负载数据，以动态优化数据放置。

对于开发者和企业买家而言，眼下的经验是务实的：应询问模型权重和上下文在服务的每个阶段位于何处；询问它们移动的频率、跨越哪些链路，以及拥塞时会发生什么。

接着应询问系统是否会测量这些路径。仅凭 GPU 利用率无法解释一项因缓存传输而停滞的服务。仅凭内存容量也无法揭示内存池能否及时交付数据。

AI 智能体让这些问题变得紧迫，因为它们将上下文转化为持续存在的基础设施状态。每一轮推理都可能扩展这一状态，每一次工具调用都可能打断可预测的处理过程。

最终胜出的架构，不会只是把更多内存放在更多计算资源旁边。它将为每种工作负载匹配合适的数据路径，同时控制通信开销。

这一结果需要芯片、互连、存储、服务软件和应用设计之间的协同。没有任何单一规范能够描述由此产生的性能。

因此，下一次基础设施评估的问题很具体：最新投资是否减少了有用数据的移动，还是仅仅增加了另一个快速组件？这一差别将决定 SK hynix 以内存为中心的论点会成为生产标准，还是继续作为一种具有影响力的设计观点存在。