SK hynix：AI 的瓶颈已从算力转向数据
SK hynix Newsroom 发布了一项鲜明观点：尽管加速器速度不断提升，AI 性能正日益取决于数据传输，而非数据处理本身。这份 9 月 3 日的分析指出，推理和智能体 AI 正在暴露出仅靠原始计算能力无法解决的内存限制。
这一立场挑战了行业熟悉的评判标准。AI 基础设施通常通过 GPU 数量、浮点性能和模型规模进行比较。SK hynix 认为，当处理器不得不等待模型权重、缓存上下文和中间结果时，这些数字便会产生误导。
这家公司销售内存产品，因此显然有动力支持这种解读。但这一根本问题早于当下的 AI 热潮。早在 HBM 成为战略性组件之前三十年，研究人员就已描述过处理器与内存之间不断扩大的差距。
新的问题并不是算力是否仍然重要——它显然重要。问题在于，当实际服务需要长上下文、反复调用工具以及低响应延迟时，增加算力是否依然是最有效的答案。
SK hynix 重新定义 AI 基础设施竞赛
SK hynix 希望基础设施采购方依据持续的数据流，而非仅凭理论算力来评估系统。
该公司的内存瓶颈分析由 KAIST 教授 Hoi-Jun Yoo 撰写。免责声明称，其中观点未必代表公司的官方立场。即便如此，这篇文章的发布仍契合 SK hynix 更广泛的努力：将内存架构置于 AI 基础设施规划的核心位置。
文章区分了加速器的理论性能和实用系统性能。处理器每秒可以执行大量运算，但前提是所需数据能够及时抵达。无论标称容量多高，数据传输缓慢都会让执行单元处于等待状态。
当企业从模型训练转向持续推理时，这一区别尤为重要。训练通常处理大批量数据，有助于让更多加速器单元保持忙碌。生产环境中的推理往往必须快速响应单个请求，因此更难凑齐大批量任务。
智能体 AI 又带来了另一层压力。一个智能体可能规划多个步骤、调用外部工具、检查结果、修订计划，并继续生成 token。每一步都会创建或检索必须在系统某处持续可用的状态。
由此形成的工作负载，需要在存储、系统内存、加速器内存和片上缓存之间频繁传输数据。延迟会在每个边界处累积。增加处理器并不会自动消除这些传输。
SK hynix 将此描述为瓶颈位置的转移。这一论点并不意味着所有工作负载都已受内存限制。它的意思是，仅凭加速器性能，无法完整预测真实服务的表现。
这一限定很重要。以矩阵运算为主的训练操作仍可能受算力限制，而 token 生成通常面临更强的带宽约束。提示词处理和 token 解码也可能给同一加速器的不同部分带来压力。
因此，有价值的洞察比标题更具体：AI 基础设施正变得依赖具体工作负载，而推理会暴露峰值算力指标所掩盖的弱点。
这种重新定义同时给加速器厂商、云服务运营商和模型开发者带来压力。每一方都必须证明，在真实需求下，其系统能够持续为昂贵的计算单元提供数据。
这也改变了采购方应提出的问题。买方需要关注每秒 token 数、首个 token 时间、token 间延迟、批处理表现、内存容量和功耗等指标。单一的峰值性能数字无法独自回答这些问题。
对开发者而言，这种变化体现为应用层问题：更长的对话会变慢，并发用户会争夺内存，智能体工作流会产生不均衡的需求。基础设施设计因而会一路影响到用户体验。
这并非一项新的内存产品公告，而是试图重新定义整个 AI 市场所采用的性能标准。SK hynix 希望内存部署与数据传输被视为首要设计决策。
推理让上下文成为内存问题
向推理的转变，使已存储的上下文从被动的应用历史变成了主动的性能成本。
大型语言模型按顺序生成回答。每个新 token 都依赖此前 token 相关的信息，因此系统在生成答案时会持续回访先前的上下文。
Transformer 通过键值缓存避免重复进行此前的每一次计算，通常称为 KV 缓存。它存储早期 token 的注意力数据，使模型可以在生成过程中复用这些数据。
缓存节省了计算，但会消耗内存。其规模会随序列长度、模型结构、精度、批次大小和并发请求数量增长。因此，更长的上下文以更高的存储和数据传输需求，换取减少重复计算。
SK hynix 给出了一个醒目的例子。其文章称，一个以 16 位精度存储的 700 亿参数模型，仅权重就需要约 140 GB 内存。在某些长上下文环境中，KV 缓存甚至可能需要更多内存。
这一比较不应被视为通用的容量公式。实际 KV 缓存需求高度取决于模型架构和服务配置。诸如分组查询注意力等技术，可能显著改变结果。
不过，其机制已经确立。每个活跃请求都可能占用不同数量的加速器内存，且在请求持续期间，这种分配会一直保留。长时间运行的智能体使这种占用时长尤为重要。
以处理多份文档的研究智能体为例。它会阅读来源、保留指令、生成查询、接收工具输出，并撰写最终回复。用户看到的答案可能很短，但执行轨迹可能长得多。
客户支持智能体也有类似模式。它可能检索账户历史、查阅政策文件、调用计费服务，并比较多个可能的解决方案。每项操作都会增加上下文或需要新的数据。
这些工作负载会产生两类相关约束。容量决定内存中可容纳多少活跃请求；带宽决定模型为每个生成的 token 检索所需信息的速度。
当内存容量不足时，运营方必须缩小批次、缩短上下文、将模型分布到更多加速器上，或通过更慢的内存层级移动数据。每种选择都会改变成本、延迟或输出质量。
当带宽不足时，算术单元会等待权重或缓存状态。在同一受限数据路径中增加更多算术能力，可能只会带来令人失望的收益。
逐 token 解码期间的压力会进一步增加，因为每一步在重新访问模型数据前执行的工作有限。与大规模训练批次相比，这种行为通常较少有机会复用已加载的信息。
智能体 AI 也使需求更难预测。一个请求可能在单次回复后结束，另一个则可能启动许多工具并持续数分钟。静态内存分配会在这种波动下浪费容量。
这正是推理优化成为一门系统工程的原因。模型架构、服务软件、内存层级、调度和请求设计，都会影响同一种面向用户的延迟。
对企业采购方而言，其影响超出芯片选择。AI 服务必须高效传输检索到的文档、模型状态、用户上下文和工具结果。即使加速器内存表现良好，缓慢的存储或网络仍然可能被用户感知。
一个可搜索的知识库说明了这种应用层依赖关系。当文档检索、索引或上下文组装拖慢每一次回答时，快速生成的价值就所剩无几。
因此，AI 内存瓶颈并非单一组件故障，而是一条链路：其中最慢的关键传输可能限制整个请求。
Hynix Newsroom 的论点聚焦数据传输
Hynix Newsroom 的论点扭转了十年来“算力优先”的思维，但并未声称 GPU 已变得不重要。
其思想基础是“内存墙”——处理器与为其供给数据的内存系统之间不断扩大的性能差距。William Wulf 和 Sally McKee 在 20 世纪 90 年代为这一问题赋予了沿用至今的名称。
他们的内存墙论文比较了迅速提升的处理器性能与 DRAM 访问性能较慢的提升速度。论文警告称，内存延迟可能会吞噬更快处理器所带来的收益。
SK hynix 引用了历史数据：处理器性能的年提升率约为 60%，而 DRAM 访问速度约为 7%。这些数字描述的是论文所处的历史背景，并非当前的年度预测。
现代硬件通过更大的缓存、预取、并行内存通道、堆叠内存、先进封装和更快互连来缩小这一差距。软件也通过重组数据处理方式来改善局部性。
然而，AI 放大了这个老问题。大型模型包含大量权重、激活值和临时状态。长上下文推理会反复访问其中部分信息，而用户又期待交互式响应时间。
因此，核心竞争是在算力优先扩展与数据感知型系统设计之间展开。前一路线优先考虑更多加速器和更高的峰值算术吞吐量；后一路线则围绕真实数据路径，协调计算、内存、软件、存储和网络。
这两条路线并不相互排斥。每个有用的 AI 系统都需要算力，高带宽内存通常也紧邻加速器。冲突在于：下一单位的工程投入和资本，应优先解决哪一种约束。
运营商可以增加加速器，但这些设备在共享模型状态和请求流量时必须相互通信。分布式部署模型也可能引入互连传输，以另一种瓶颈替代原有瓶颈。
芯片设计者可以增加算术单元，但封装必须具备足够带宽来供给它们。更高的内存带宽可能需要更多 HBM 堆栈、更宽的接口、额外功耗或更复杂的封装。
模型开发者可以扩展上下文窗口，但只有服务基础设施能够高效处理扩大的缓存时，用户才能从中受益。宣称的上下文长度与可负担的并发使用并不是同一项成就。
这改变了面临压力的主体。加速器厂商必须报告完整系统的结果，而不能只展示孤立的算术模块。云服务提供商则必须展现在真实请求模式下的有效性能。
内存供应商不能只交付更快的组件。他们必须与处理器、封装、软件和数据中心团队协作，因为物理上的邻近并不保证高效执行。
开发者同样承担部分责任。不佳的请求调度、过多的上下文、低效的检索或不必要的智能体循环，都会造成更好的硬件也无法完全掩盖的数据传输负担。
商业影响十分重大，因为 AI 加速器属于昂贵资产。当这些设备等待数据时，利用率便会下降，而更低的利用率会提高每个生成 token 的基础设施成本。
能耗进一步强化了这一压力。在不同层级间移动数据会消耗能量，而闲置的计算资源仍会占用昂贵的基础设施。缩短数据路径可以同时提升性能与效率。
然而，没有任何单一利用率指标能够描述整个市场。结果会因模型、序列长度、批量大小、数据类型、调度器和硬件而异。供应商基准测试往往会选择对特定架构更有利的条件。
因此，买方需要与自身工作负载挂钩的测量结果。面对大型代码仓库的编程智能体，与一次简短的聊天机器人交互并不相同。图像生成也不同于检索密集型文档分析。
若将其理解为对测量方式的修正，Hynix Newsroom 的论点最具说服力。峰值算力仍然必不可少，但它已不再能充分代表实际交付的 AI 性能。
软件可以延展内存能力，但无法消除这道墙
软件可以减少不必要的数据传输和闲置容量，但每种技术都存在特定于工作负载的限制。
FlashAttention 展示了：即使不改变模型的数学输出，仅改变数据移动方式也能带来多大改进。它将注意力运算划分为更适合装入高速片上 SRAM 的分块。
原始的 FlashAttention 研究 将该算法描述为具备输入输出感知能力。它减少了高带宽内存与 SRAM 之间的读取和写入，而不只是降低算术运算次数。
这一差异支持了 SK hynix 更广泛的论点。该算法通过遵循内存层级结构来加速注意力计算。即使使用相同的加速器，减少数据移动也能带来更快的执行速度。
PagedAttention 解决的是另一类问题。KV 缓存分配会随着请求开始、扩展、完成或分支而变化。为不确定的请求长度预留连续内存，可能造成碎片化，并让昂贵容量处于闲置状态。
PagedAttention 研究 将虚拟内存理念应用于 KV 缓存管理。其 vLLM 实现报告称，在相近延迟下，吞吐量比被评估的服务系统高出两到四倍。
这些结果属于该研究的特定测试条件，后续系统也已发展出其他分配方法。它们仍然说明，无需增加加速器，内存管理就可能显著改变服务经济性。
量化采用了另一条路径。它以更少的比特表示权重、激活值或缓存状态。将一个数值从 16 位降至 8 位或 4 位，可以降低内存需求和传输数据量。
其代价是精度。一些模型能够很好地适应激进量化，另一些则会损失准确性，或需要谨慎校准。专用格式还需要硬件和软件支持，理论节省才能转化为实际收益。
推测式解码使用较小模型提出多个 token，再由较大模型一并验证。成功的候选提议可以减少昂贵的串行解码步骤。
其收益取决于接受率和工作负载行为。质量不佳的候选提议会增加工作量，却无法带来相应进展。辅助模型本身也需要资源和协调。
模型架构可以从更根本的层面减轻压力。分组查询注意力在多个注意力头之间共享键和值表示，相比传统多头注意力缩小了 KV 缓存。
检索策略也可以避免将所有可能的文档都放入提示词中。设计良好的系统会检索聚焦的子集，从而减少上下文长度和无关处理。
但检索也引入了另一条数据路径。文档必须在生成前完成索引、搜索、选择和交付。应用程序可能将瓶颈从加速器内存转移到存储、网络或检索软件。
智能体开发者也面临类似取舍。将每个工具输出都保留在实时提示词中能够保护上下文，但会加速缓存增长。摘要化或将状态外部化可以节省内存，但也可能丢失细节。
个人知识库可以将持久信息保留在模型即时上下文之外。应用程序仍需进行严谨检索，才能在恰当时机找回相关材料。
SK hynix 认为，部分压缩技术正接近理论极限。这是一种与公司立场一致的解读，尤其是因为其提出的下一步有利于新的内存产品和架构。
软件进展曾多次超出预期，因此现在断言已经走到终点仍为时过早。更好的模型、稀疏计算、改进的调度器、缓存复用和请求路由，仍可减少内存流量。
软件与硬件之间也不存在固定边界。FlashAttention 之所以有效，是因为软件理解内存层级结构。量化格式在加速器能够高效执行时也会变得更有价值。
最可信的结论并非软件优化已经结束，而是未来收益需要协同设计，让算法和硬件围绕相同的数据移动约束共同开发。
HBM、CXL、HBF 和 PIM 提供了不同答案
硬件应对方案正分化为多个内存层级，因为容量、带宽、延迟和成本无法同时实现最大化。
高带宽内存，即 HBM，会垂直堆叠 DRAM 芯片，并将其放置在加速器附近。贯穿硅通孔连接这些芯片，形成宽接口，以移动大规模数据。
HBM 针对带宽和距离问题，但并未消除所有限制。容量仍然有限，封装复杂，先进堆叠方案还会争夺制造资源。
尽管如此，这项技术已成为现代加速器的核心。AMD 为其 MI350 accelerator 标示了 288 GB 的 HBM3E 容量和最高每秒 8 TB 的带宽。
这些规格是供应商声明，而非独立工作负载结果。它们也揭示了竞争方向：加速器设计商如今会将内存容量和带宽与算术性能并列宣传。
因此，Nvidia、AMD 和定制加速器开发商竞争的是完整套件。相关产品包括计算芯片、HBM、互连、网络、软件库和系统级扩展能力。
Samsung Electronics、Micron 和 SK hynix 在先进内存领域也面临类似竞争。它们供应通过认证的 HBM 产品的能力，会影响加速器供货、封装进度和系统设计选择。
SK hynix 还强调了高带宽闪存，即 HBF。该概念试图利用 NAND 闪存构建一个容量高于 HBM 的层级，同时目标带宽远高于传统存储。
对于无法经济地容纳在 HBM 中的大型模型权重或缓存数据，HBF 可能有所帮助。然而，它仍是一种发展中的方案，而非对成熟加速器内存的成熟替代品。
闪存的延迟、耐久性和访问特征与 DRAM 不同。因此，有关可比带宽的说法必须在特定系统设计和工作负载中加以评估。
Compute Express Link，即 CXL，解决的是资源共享问题。它在处理器、内存设备和加速器之间提供一致性连接，使系统能够扩展或池化内存。
CXL 内存标准 在 2.0 版本中引入了交换和内存池化。池化可以让容量在工作负载需要的位置可用，从而提高利用率。
与位于加速器封装上的内存相比，CXL 也增加了距离。扩展容量很有价值，但不同层级的访问延迟和带宽各不相同。
这项取舍使放置策略变得至关重要。高频访问数据应靠近计算资源，而较冷的数据可以放入更大但更慢的资源池。软件必须决定什么要移动、何时移动，以及何处留存。
存内处理，即 PIM，采用了相反的物理路径。它将部分计算放在内存附近或内存之中，从而减少将数据传回独立处理器的需求。
PIM 对于由数据移动而非复杂控制主导的运算很有吸引力。要实现采用，需要合适的编程模型、有价值的工作负载、制造支持，以及与既有软件的集成。
这些技术没有任何一种能独自解决 AI 内存瓶颈。HBM 改善本地带宽，HBF 目标是新的容量层级，CXL 扩展共享能力，PIM 则减少特定的数据传输。
正在形成的架构类似于一个受管理的层级。小型高速缓存最靠近计算资源。HBM 保存活跃权重和状态。其他内存和存储层级则以更远的距离提供不断扩展的容量。
成功取决于将正确的数据放在正确的层级。当迁移开销超过节省下来的容量时，大型内存池几乎没有收益。当软件触发可避免的数据传输时，高速 HBM 同样会令人失望。
这正是 SK hynix 论点带来的主要压力。供应商不能再孤立地优化单个组件。它们的产品必须在封装、服务器、机架和软件框架之间协同工作。
竞争优势很可能来自集成，而不是某一项单独规格。能够协调加速器设计、内存布局、互连行为和服务软件的供应商，才能将组件转化为持续的应用性能。
数据优先的论点仍须证明什么
下一个考验是：以内存为中心的设计能否在多样化 AI 工作负载中带来更优的生产经济性。
第一个值得关注的信号是独立推理基准测试。结果应涵盖长上下文、并发请求、智能体循环和混合提示词长度，而不是单一有利配置。
如果更高的内存带宽在这些条件下持续改善每秒 token 数和延迟，SK hynix 的论点就会更具说服力。若收益微弱，则表明计算或软件仍是主要限制。
基准测试报告还需要包含功耗和利用率测量。一个系统若生成了更多 token，却消耗了大幅更多的能量，并不一定改善了部署经济性。
第二个信号是新内存层级的采用情况。HBM 需求已表明带宽很重要，但 HBF、池化 CXL 内存和 PIM 面临更困难的集成问题。
生产部署将验证这些技术是否能在演示之外解决客户问题。反复延迟、狭窄的应用场景或糟糕的软件支持，都会削弱架构正在快速转变的说法。
第三个信号是下一波软件效率提升。新的注意力算法、缓存压缩、状态复用、稀疏模型和调度方法，可以在硬件必须承接之前减少数据移动。
强劲的软件收益并不会推翻内存墙。它们会改变买方应将资金投入何处，并推迟新硬件变得必要的时间点。
SK hynix 也需要为与其商业地位相关的主张提供独立证据。当基础设施规划为内存赋予更大的预算和战略角色时，该公司将从中受益。
因此，其论点应接受不利于 HBM 供应商的工作负载检验。小型模型、短提示词、边缘部署和高度优化的推理系统，可能会呈现不同的约束。
“数据，而非算力”这句话之所以有用，是因为它打破了一种过时的假设。然而若从字面理解，它又制造了一种错误的二分法。AI 系统两者都需要，而且随着工程师改进每一层，瓶颈也会随之转移。
一款获得更快内存的应用，可能会变得受算力限制。更快的加速器可能暴露网络约束。更好的网络又可能揭示存储缓慢或检索效率低下的问题。
长期有效的经验是：衡量完整的请求路径。团队应追踪数据存放在哪里、移动频率如何、处理器等待多久，以及哪些传输主导了能源消耗。
对开发者而言，这意味着要将上下文视为一种需要管理的资源。提示词、检索到的文档、工具输出和智能体历史记录，都会带来基础设施成本，而这些成本往往隐藏在一次简单的 API 调用背后。
对企业采购方而言，这意味着在承诺采用某个平台之前，应先测试真实应用。加速器的峰值规格无法预测每一种模型、上下文长度或并发模式下的表现。
对芯片和云服务提供商而言，这意味着应发布更透明的系统结果。客户需要可重复的测量数据，将内存设计与延迟、吞吐量、利用率和功耗关联起来。
Hynix Newsroom 的分析方向是正确的：AI 竞争正在超越算术吞吐量。只有当数据感知型系统能在供应商控制的演示之外带来可重复的收益时，其中最有力的主张才能得到证明。
如今，实际问题已经可以量化：你的 AI 工作负载将时间花在何处——计算、等待内存、检索外部数据，还是在不同层级之间迁移状态？在购买另一块加速器之前，应先回答这个问题。
