OCP2026大会折射AI基础设施全栈趋势

要回答这个问题， 我们首先要弄清楚OCP这个会的特点。OCP，正如它名字Open Compute Project所说那样，是一个行业开放交流讨论的平台。会员公司都可以在这个平台上就某个问题或痛点，发起项目，吸引其他公司来共同参与讨论，共同定义针对该问题的规范和标准。 正因为如此，你可以看到绝大部分OCP上的演讲最后都有Call to Action，呼吁更多的公司参与到演讲者所推的项目中；而一个相近/类似的问题可能有多个工作组在运作，他们给出的方案可能截然不同。这也意味着，某个工作组在OCP上发布了一个标准并不意味着行业达成了某项共识，它仅意味着一些公司就某个问题提供了他们的方案，至于这个方案能否成功， 还要看它能否被行业的其他公司采纳和落地。 所以，抱着寻找答案的心态参会恐怕不是打开OCP的正确方式；但是，若我们抱着寻找问题的视角来看待OCP，就可以过滤掉噪音，理清背后的逻辑。

基于上述原则，我们根据实际的参会观察和会议材料，梳理了如下几条行业发展脉络，供大家参考。

AI集群的 Scale-Up和 Scale-Out网络的分离已经形成行业共识，但Scale-Up网络到底采用何种协议，依然存在多个阵营。 在本次OCP上，我们看到了多个演讲分别涵盖了SUE-T（Scale-Up Ethernet Transport），ESUN（Ethernet Scale-Up Network）和UALink；在开场的主题演讲上，Lisa Su提到AMD会支持UAL over Ethernet和ESUN。这种混沌的状态也导致了在ESUN的论坛上， 有观众直接发出了既有UALink，何生ESUN的灵魂拷问。针对这一问题，演讲嘉宾的回答是：

“It's not UAL versus Ethernet. It's a question of basically, am I enabling the whole AI ecosystem for open collaboration and open system that can address the requirements for the market very quickly because the timelines are shortening.”，以及，“There is a large amount of ecosystem in Ethernet out there, which we believe can help drive this ecosystem much faster.”

这里的关键词是“快”：Time-to-Market快，生态构建快，这确实是一个理由。但是从工程师的角度看，这个回答并未触及技术核心。事实上，ESUN和UAL并不能进行Apple-to-Apple的比较，因为ESUN不参与传输层的定义，而UAL定义了包含协议层、传输层、链路层和物理层在内的完整的栈。 因此，合理的比较应该是SUE-T+ESUN和UALink的对比。SUE-T每帧只发往一个目的地，交换机根据目的地进行帧转发， 发生Incast时，容易造成Head-of-Line Blocking；而UAL的DL Flit（640B）内部的TL Flit（64B）可以有不同的目的地，UAL交换机会对TL Flit逐个解析和转发到目标GPU对应的端口的Egress缓冲区，再重新组装成DL Flit发送， 长尾延时会好很多。当然，这也意味着我们需要做专门针对UAL的交换机，从而导致了UALink生态构建需要一定的时间。这大概也是为什么AMD作为UAL的发起者，要先支持UAL over Ethernet的原因。

那么，Scale-Across网络又是怎么回事呢？当前AI 训练算力需求依然在快速增长，当训练集群规模达到数十万颗 GPU 时，单园区的电力需求可达吉瓦级别，一般的电网已经无力承载。于是就有了将地理上分散的多个数据中心园区编织成一个逻辑上的单一 AI 集群，使不同园区的 GPU 能够协同训练同一个模型。这个不同AI数据中心之间的网络就是Scale-Across网络。

图片来源：《Scale-Across Networking（Panel Discussion）》，第40页

Scale-Across带来了它特有的挑战， 如下图所示。 其中最根本的挑战是超长的RTT（Round-Trip Time）：光速延迟使得 RTT 从Scale-Out的微秒级跃升到Scale-Across的毫秒级，传统基于 RTT 反馈的拥塞控制机制（如 ECN、PFC）在长延迟链路上基本没法收敛。 Scale-Across 需要的是"Back-to-Sender"（BTS）机制，让拥塞或故障信息以更低的延迟返回发送端，而不是等待完整的 RTT 反馈。同时，由于本地流量（低 RTT）和跨域流量（高 RTT）在同一网络中共存，拥塞控制机制必须能够区分这两种截然不同的延迟特征，避免相互干扰。

图片来源：《Scale-Across Networking（Panel Discussion）》，第46页

有意思的是， Scale-Across在国内提得相对较少，因为以国内电网的能力，支撑起GW级数据中心似乎不是问题。 这就出现了一个鲜明的对照：在OCP上，有论坛在探讨Scale-Across，与此同时，China Subforum的主题是GW AIDC怎么搞。 不能说我们可以完全避开Scale-Across，但国内强大的电网， 至少让Scale-Across的迫切性延后了不少时间。 这就带来了OCP上的另一个热点：数据中心供电。

数据中心供电这个track异常火热， 能容下200多人的房间座无虚席，且过道上也挤满了人，没有任何一个其他的track有这么高的听众密度。 不过，这也不意外：当今世界，面对AIDC这个吞电巨兽， 除了中国以外，恐怕没有任何一个国家可以从容应对，行业聚集在一起寻找共识也是必然。

AI 工作负载对功率密度的需求呈指数级增长，单机架功率从传统的 10-20kW 跃升至 100kW 甚至兆瓦级别。传统的交流配电架构在转换效率、功率密度和可靠性方面已接近物理极限。800VDC 架构允许从中压电网直接整流到 800V 直流，再通过 DC-DC 转换器降压到负载所需的电压（如 48V 或 12V），可将配电效率提升 5-10%，同时支持更高的功率密度。共识已成， 具体工程化部署时还有两方面的考量：

• 功率机架设计（1MW 级别）与液冷一体化设计。当机架级功率需求突破 1MW 大关，传统的空气冷却已无法满足散热需求，液冷成为必然选择。功率机架设计需要与液冷系统深度集成：功率 shelf 本身需要液冷散热，母线排（busbar）的布局需要避开冷却管路，功率模块的热设计需要考虑冷却液温度对效率的影响。

• 与现有基础设施的兼容性与过渡路径。尽管 800VDC 优势明显，但数据中心行业拥有庞大的交流基础设施存量。如何在保护既有投资的前提下平滑过渡到直流架构，也是数据中心运营商面临的挑战。OCP会上提出了多种过渡方案：sidecar 电源系统（与交流 UPS 并行部署）、混合架构（部分机架采用 800VDC，部分保留交流）、以及"any rack everywhere"理念（通过标准化接口使机架在任何数据中心都能部署）。汽车行业向 800V 架构迁移的经验也被借鉴到数据中心领域。

尽管800VDC提升了供电效率， 但也增加了安全方面的风险。 确保高压直流的安全性也是行业关注的一个焦点，主要有如下几个方面：

• 直流电弧特性与防护策略。与交流电不同，直流电没有自然过零点，电弧一旦形成便难以自熄。800V 直流系统中的电弧能量可达交流系统的数倍，对设备和人员安全构成严重威胁。因此，行业需要制定针对性的防护策略，包括电弧检测算法、快速隔离机制、以及设备间距和绝缘材料的设计规范。

• 固态断路器（SSCB）与直流故障管理器。传统机械断路器在直流系统中的分断速度慢、寿命有限，无法满足 800VDC 系统的保护需求。固态断路器采用功率半导体器件（如 SiC MOSFET），可在微秒级时间内切断故障电流，且无机械磨损。

• 负载平滑、故障穿越与备份电源设计。AI 工作负载具有高度动态特性（如训练任务的启停、推理请求的波动），对电源系统的瞬态响应能力提出严苛要求。同时，电网故障或设备失效时，系统需要具备故障穿越能力（ride-through），在不影响 IT 负载的前提下维持供电。这要求备份电源（如电池、超级电容）能够快速响应，并在 800VDC 母线上实现无缝切换。本次OCP上也探讨了多种负载平滑和故障穿越技术，包括能量存储系统的优化配置和控制策略。

无论是Scale-Up网络还是GW级数据中心，都反映了一个基本的事实：当前系统集成的密度和复杂度在急剧攀升。 这就带来了一个极为现实的问题：系统如何确保可观测性，从而在出现问题的时候可以快速定位根因。当前的Telemetry在各个系统层级上，各自为政，没有统一的ID，时间和语义；一旦跨越层级边界，Telemetry数据无法进行关联，导致系统层面的Debug异常困难。 而要解决这一问题，构建在集群层面的统一的遥测架构就显得尤为迫切，这里包含两方面：工具的收敛和数据的统一。

图片来源：《Unified Full-Stack Telemetry for AI Systems》第6页

• Redfish 流式遥测增强与别名支持。传统 Redfish 采用轮询模式获取数据，在高并发场景下效率低下。流式遥测（Streaming Telemetry）通过推送模式实时发送数据，大幅降低延迟和网络开销。别名支持（Aliasing）则允许为同一指标定义多个访问路径，简化客户端集成。这些增强使 Redfish 能够支撑 AI 集群对实时性的严苛要求（如 GPU 温度、功耗的毫秒级监控）。

• OpenBMC 作为 OCP 孵化的开源 BMC 固件，已在多家超大规模数据中心部署，并且积累了大量实际运维中的经验教训：性能瓶颈（如高并发下的响应延迟）、可靠性问题（如内存泄漏、看门狗超时）、以及扩展性挑战（如管理数万台服务器的资源消耗）等。这些反馈推动了 OpenBMC 的持续优化，包括架构重构、性能调优和自动化运维工具的开发。

• 时钟对齐的遥测数据（BMC → GPU → 集群）。AI 训练任务中，性能瓶颈可能出现在任何层级：芯片级（GPU 过热降频）、机架级（电源限流）、集群级（网络拥塞）。要准确定位问题，需要将不同层级的遥测数据在时间轴上对齐。但 BMC、GPU、交换机等设备的时钟往往不同步，导致数据无法关联。本次OCP上，包括Intel在内的厂商，开始直面这一问题，旨在实现从 BMC 到 GPU 再到整个集群的时钟同步方案，使运维人员能够在统一时间线上分析多层级指标，快速定位根因。

• 从性能遥测到平台约束发现。传统遥测主要用于监控和告警，属于被动响应。全栈遥测的更高目标是通过数据分析主动发现平台约束（如热设计余量不足、电源分配瓶颈、网络拓扑限制），比如，将遥测数据与机器学习结合，建立平台性能模型，预测潜在瓶颈，并在问题发生前采取预防措施（如动态调整工作负载分布、优化冷却策略）。阿里云服务器也已经在这些方面展开探索和应用。

• 大规模遥测数据聚合管道。超大规模数据中心拥有数十万台服务器，每台服务器产生数百个指标，每秒采样一次。如此海量的遥测数据对聚合、传输和存储系统提出巨大挑战。一些数据聚合技术，比如，边缘计算（在机架或 TOR 交换机上进行初步聚合）、数据压缩和降采样、以及时序数据库的优化使用就显得十分重要。它能够确保系统在可接受的资源消耗下处理海量的遥测数据。

• 机架级基础设施的统一遥测。现代 AI 机架包含计算节点、存储节点、网络设备、电源模块、冷却系统等多种组件，来自不同厂商，使用不同的管理协议。统一遥测框架通过标准化数据模型和接口，将异构组件的指标整合到统一平台，简化运维复杂度，实现机架级遥测的数据采集、传输、处理和可视化的完整链路。

随着计算域扩大，互连介质开始影响系统的扩展边界。芯片之间的连线距离、机柜布局、布线密度，以及维持信号质量所需的功耗，逐渐成为与带宽同等重要的设计条件。Dell 在本次 OCP 的分享中将高速铜连接的距离约束称为系统层面的“铜墙”。具体而言，在每通道 200 Gb/s 时，无源铜连接的传输距离通常只有几米；当每通道速率提高到 400 Gb/s 及以上时，电连接的可达距离预计将进一步缩短至不足 1 米。有源铜缆和电通道设计仍在延长铜的适用距离，光则为突破距离和密度限制提供了新的空间。因此，铜光边界需要结合具体拓扑和完整链路成本确定。

光互连自身也存在不同的演进方向。NPO、CPO 将光电转换向芯片靠近，以缩短高速电通道；另一条值得关注的路线是 Slow-and-Wide，通过更多并行光通道、较低的单通道速率提供总带宽。Credo 的微发光器件方案体现了后一种思路。不过，更多通道也意味着更复杂的光纤、连接器和封装组织，接口适配的功耗同样需要计入。Credo 对相关 ALC 产品标注的量产时间是 2027 年，其功耗、成本和可靠性主张仍需要结合产品阶段与实际部署条件理解。

图：Credo 的并行光通道架构。主机接口经 Gearbox（速率与通道数转换）和交叉开关连接到密集阵列，分别组织数据、备用和管理通道。来源：《Optics that Beat Copper on Reliability, Power, AND Cost》，第 6 页（原图局部）。

光互连能否达到大规模计算系统所需的可靠性，一直是部署中的核心顾虑。本次 OCP 的讨论提供了更多生产运行和系统验证的证据。Meta 报告了约 4,000 个 LPO 模块、四个月的生产观察，场景限定为其分布式交换网络（DSF）的单跳连接，单通道速率为 100 Gb/s，并给出了与传统带重定时光模块的对比。另一场分享披露了 51.2T CPO 的系统级可靠性、可用性和可维护性评估，同时将 102.4T 列为后续目标，并展示了概念验证方案。这些材料说明，可靠性必须落实到具体实现和运行条件，单凭 LPO、NPO 或 CPO 的名称，难以判断谁更可靠。

更深一层的变化，是评价指标开始关注计算任务能否连续运行。平均误码率较低，仍可能存在会触发重试或链路中断的突发错误；多个通道共用激光器、连接器或光引擎时，还可能同时失效。一次短暂中断影响几个通道，能否切换到备用路径，GPU、固件和集合通信库是否允许降带宽继续运行，都关系到故障最终会损失多少计算时间。由此，光器件冗余、链路恢复和系统容错需要共同设计。

故障定位也需要更完整的证据。Credo 展示的增强遥测方案分别观察交换机侧电通道、光路径和服务器侧电通道，并支持从交换机读取远端模块信息、持久保存带时间戳的事件记录。这些机制有助于还原短暂中断前的状态，判断问题发生在哪一段，再选择清洁、重插、更换或隔离等处理动作。材料已给出具体试验，实际选型时还需确认各项能力在目标产品中的支持情况及规模部署表现。

光电路交换（OCS）进一步把优化范围扩展到连接拓扑。通过改变光路，可以调整不同计算资源之间的连接关系，为动态带宽分配和工作负载感知的拓扑提供可能。

图：工作负载感知拓扑的用例示意。紫色路径展示了绕过 Spine 或 Leaf 电分组交换机的光连接，并与原有交换路径共存。来源：《Optically-Accelerated AI Clusters Enabled by Interoperable Multi-Vendor OCSs: Use Cases and Opportunities》，第 9 页。

光开关完成切换之后，收发器还需要恢复时钟、完成均衡并稳定链路，软件也需要完成调度和状态更新。因此，快速 OCS 能否支撑 AI 负载的细粒度调度，需要结合端到端重配置时间和业务收益验证，器件切换速度只是其中一个环节。

连接可重构之后，还需要验证每次调整是否得到预期拓扑。OCS 本身不检查数据包，端口有光或交叉连接配置成功，仍不足以证明两端连接正确。Oracle 与 Lumentum 因此提出，将预检查、连接配置、端到端验证和失败回滚纳入同一变更流程；Google 的接口工作则尝试统一连接意图、实际状态和恢复行为。这些工作仍在推进，跨厂商接口与行为的一致性，将直接影响 OCS 的集成和运维成本。

我们的体会是，光互连的价值正在由链路指标延伸到系统运行结果。距离、带宽密度和能效共同限定计算域的扩展空间，故障隔离与恢复影响资源能否持续工作，拓扑调度则影响资源能否被有效组织起来。评估技术路线时，需要把这三方面放在同一套系统条件下讨论。

本次 OCP 的内存讨论，已经延伸到计算、数据和服务如何组织。SK hynix 的 MARS（Memory-centric AI Rack System）尝试让计算与内存资源分别扩展，共享对象覆盖模型、KV Cache、模型流水线中间结果和图计算数据。Samsung 面向 2030 的愿景则提出从 Memory Fabric 出发，按工作负载配置计算。这些方案的成熟度不同，但共同提出了一个问题：当数据规模和访问需求不再与计算资源同步增长，内存是否还应该主要依附于单个计算节点配置？阿里云提出的 UMX（Unified Memory Extension）也沿着计算与容量分离、资源统一组织的方向展开。

图：磐久 UMX 的架构方向。通过 UALink 与 CXL 互连，将 GPU、CPU 与池化的 DRAM、SCM、NAND 容量层连接，支持计算与内存、存储资源的分离组织。来源：《Beyond DRAM: Persistent Memory via Compute Interconnects for AI》，第 13 页（原图局部）。

KV Cache 是推动这一变化的重要负载，但内存共享的价值并不限于保存上下文。模型流水线中的中间结果可以在不同计算阶段之间复用，图计算可以减少数据切分与搬运，多个服务实例也可能共享相同数据。需要同时看到，资源统一管理并不意味着所有访问都具有相同的时延和带宽。MARS 明确区分机架内 CXL 与机架间 RDMA；Samsung 的架构也保留不同局部性范围，要求数据放置匹配实际的 token 执行路径。

不同类型的 KV Cache 数据，对内存容量和带宽的要求也不同。Micron 的建模表明，工作集超过某一层的容量后，缓存驱逐会降低有效复用率；较低并发下成立的收益，未必能延续到高并发。该框架还区分跨会话共享前缀与会话内活跃上下文：前者更侧重保留容量，后者更受读取带宽和访问时限约束。因此，我们需要分别核算工作集、读写热度和取回成本，从而判断新增容量能减少多少重算、改善多少响应时间。

容量与带宽的取舍，也推动了介质、模组和互连的协同探索。Nallasway 结合 LPDDR5X、短距串行互连、模块化供电与散热，探索 XPU 周边的内存组织，目前正从概念设计走向 PoC；SK hynix 则将基于 NAND 的 HBF 定位在 HBM 与企业级 SSD 之间，并给出了标准与产品路线图。两者分别从内存模组和非易失性容量层出发，拓展计算设备周边的内存选择。

阿里云的 Beyond DRAM 分享介绍了自研非易失性内存 AliSCM：以相变存储器（PCM）构建字节可寻址的容量层，通过 CXL 2.0 接口接入系统，并披露了部署情况和 KV 卸载实验。下一代方案进一步探索通过 UALink 接入 GPU 的 Scale-Up Fabric，为 GPU 扩展可用容量。

图：AliSCM 产品介绍，包括 CXL 2.0 Type-3 接口、控制器与 PCM 介质架构，以及报告列出的性能指标。来源：《Beyond DRAM: Persistent Memory via Compute Interconnects for AI》，第 4 页。

从成本视角看，PCM 和 HBF 的核心收益，是以更低的单位容量成本扩展 AI 系统的数据承载能力，让容量增长不再完全依赖 DRAM。PCM 的字节寻址和读写能力，使其能够承接可更新的 KV Cache 等内存数据；HBF 则发挥 NAND 的高密度优势，通过高带宽接口服务模型权重等读多写少的大容量数据。这样的分层设计，可以把 HBM、DRAM 留给对时延和带宽最敏感的工作集，把大容量数据放到成本更低的介质上，从而在相同预算下容纳更大的模型、保留更多可复用数据，或在满足同等容量需求时降低内存配置成本。对于能够复用 KV Cache 的推理负载，更大的保留容量还可以减少缓存驱逐后的重复计算，提高计算资源的有效利用率。

近存计算（PNM）和近数据处理也在本届 OCP 上受到关注，重点是在数据附近完成筛选、变换和复用管理，减少跨互连搬运。Marvell 对 XPU 直接访问的分析指出，即使减少了 CPU 中转，同步、轮询、访问保护、I/O 放大和依赖等待仍然存在；因此，它进一步讨论将数据变换、分层放置和部分处理移到数据附近。SK hynix 的计算共享内存池则展示了池侧 KV 选择、前缀 token 复用等具体实践。这些案例关注的是内存设备侧的处理能力。

另一个门槛，是把池中容量变成应用能够正确使用的资源。CMS 的编排设计区分由操作系统管理的通用内存与由应用显式管理的内存区域，并把全局分配、节点执行和容器配置分开。不同路径对应用适配、运行期扩缩容和权限预配置的要求不同。容量能够按需分配之后，共享、迁移与隔离仍需相应的软件机制；内存资源的分配、回收及其与推理软件的衔接，也需要与设备能力同步设计。

在架构探索之外，Meta 的 CXL 分享提供了规模运行的另一面：从设备枚举、链路训练到运行时内存错误，系统需要把主机日志、带外心跳和设备遥测结合起来。它特别指出，不同的 DIMM、控制器或固件故障，可能最终表现为同一种主机读超时；设备符合协议规范，也可能仍然难以在大规模环境中定位问题。这意味着，扩展内存的产品能力还必须包含故障发现、隔离、诊断与恢复。

这些材料给我们的启发是，内存的设计边界正在从器件和单机扩展到整个服务。哪些数据留在计算附近，哪些容量适合共享，哪些操作值得移到数据附近，以及出现故障后影响多大范围，需要一起决定。对于我们的产品规划，应先把工作集、访问依赖、复用价值和服务目标量化，再选择介质、互连和控制器能力。

SK hynix 展示了 SSD 参与推理性能优化的具体案例。在 H100、Qwen3-14B、100% 缓存命中的微基准中，经过数据块大小和 I/O 路径优化，SSD 后端的首 token 延迟达到主机 DRAM 基线的约 1.07—1.14 倍。其价值在于取回并复用已计算的 KV，减少重复 Prefill。这里接近的是给定条件下的端到端响应时间，报告同时展示了 SSD 读取完成时间的波动。因此，存储参与推理性能优化，需要同时验证有效搬运带宽、缓存复用和响应稳定性。

响应稳定性还取决于关键读取与后台流量如何共享设备。在多方联合的 I/O 优先级报告中，Google 展示了按 NAND 介质占用时间进行仲裁、改善高优先级读取尾延迟的实验；本次讨论的 NVMe I/O 优先级扩展仍处于提案阶段，端到端优先级也是后续工作。对推理缓存而言，这提示我们同时验证聚合带宽、混合读写下的高分位完成时间，以及后台任务能否持续推进，并把优先级从应用请求传递到设备调度。

高密度 QLC 是近年来存储领域的重要方向。大普微已于 2026 年 8 月在 FMS 上，通过性能测试视频展示 512 TB R6060 QLC SSD。单盘容量持续提升，有助于提高存储密度、降低系统成本，也让故障处理的经济代价更加突出：仅因局部介质错误就更换整盘，会损失更多健康容量，并带来更大的数据迁移与重建开销。

围绕这一问题，Meta 讨论了在系统冗余保护下，通过读取其他副本、局部修复和验证，尽可能保留健康介质的处理思路；Micron 的 Near-Line SSD 则提出 Failure-in-Place（FIP），允许单盘在有效容量低于标称值后继续使用，由集群统一预留和调配备用容量，并按单盘剩余有效容量决定退役时机。不同机制的适用条件和部署成熟度仍需分别评估，但它们指向同一个问题：当盘越来越大，系统如何在局部修复、整盘更换和重建成本之间取得平衡。这将直接影响大容量 QLC 的部署经济性。

Micron 用一个容量规划算例量化了这一收益：1,000 块单盘 1,024 TB 的 SSD，每颗 NAND die 为 4 Tb，保留 10% 性能 OP，假设 die 年故障率为 0.1%、使用寿命为 10 年。在其模型中，每盘独立预留 42 颗 die（约 1.9%）时，单盘在十年内备用容量不足的概率约为 0.014%，对应整个集群至少一块盘备用容量不足的概率约为 13%；改为 FIP，在集群层面共享备用容量后，作者估算约 1% 的预留即可达到相近的集群备用容量不足风险。故障备用比例由 1.9% 降至 1%，减少约 0.9 个百分点，备用空间节省接近一半；按 1,024 PB 的标称容量近似折算，可释放约 9.2 PB 空间，与报告给出的约 10 PB 收益相近。这一收益来自各盘备用余量的共享，性能 OP 和数据保护冗余仍需保留。

写入调度同样需要应用与设备协同。Meta 展示了 QLC 的 SLC 缓存耗尽后持续写性能下降的情况，并讨论依据主机侧近期写入记录分散突发流量。它也明确表示，主机并不知道设备内部的实时垃圾回收状态，相关遥测仍需要进一步协作。Micron 则围绕大块、追加式云存储负载设计 Near-Line SSD 的映射粒度、容量布局和成本目标。这说明，容量型 SSD 的经济性，需要建立在明确的目标负载上。

Samsung 的 FDP 实验从数据生命周期切入，在特定合成轨迹回放中，将写放大从 2.600 降至 1.425。这一结果表明，FDP 为缓解 KV Cache 卸载到 SSD 带来的写放大与耐久压力，提供了一条值得进一步验证的路径。工程上值得探索的是，打通推理框架到存储后端的信息传递，将 KV 的预期保留时间、更新与淘汰模式映射为放置标识，再通过 FDP 引导盘内放置，让生命周期相近的数据尽量共同回收。分类的关键是数据何时更新、何时失效，仅依据读取冷热还不够。

图：Samsung 的 FDP 数据放置机制与合成 LMCache 存储轨迹回放结果。图中保留了测试配置与适用范围说明。来源：《Vertical Optimizations for KV$ Infrastructure》，第 6 页。

SanDisk 则从 QLC 编程方式切入，讨论通过可读的首轮编程，减少对主机写入数据的 pSLC 暂存需求。Samsung 与 SanDisk 的方案分别从主机参与的数据放置和介质内部处理入手，提醒我们把写放大、保护性暂存、内部搬运和功耗共同纳入成本核算。

AI 存储的产品定义需要进一步贴近服务行为。用于推理缓存的设备，要证明它能以合适的代价及时返回有价值的数据；用于容量层的设备，要证明它能在持续写入和故障条件下保留足够的有效服务能力。采购价格、标称容量和峰值带宽仍是基础指标，而系统搬运成本、写入耐久性、故障处理和实际利用率，将共同决定最终经济性。