OCP 首日现场记：机架、光互连与内存

01 · OCP 首日 机架 互连与内存

在 Credo 的展台上，有一块透明罩子下面的电路板。两根黑色的光纤引出线接在板上，连接处能看到蓝紫色的光。旁边的屏幕上，密密麻麻排着上千个通道的位置。工程师给我的一个数字是，单个通道大约一点六吉比特每秒。这个速率放在今天的数据中心里，其实很低。但把它们并起来，整条连接就到了每个方向一点六太比特每秒。

同一天，另一场演讲正在讨论四百四十八 G 的电通道。一个方向把每条通道推得越来越快，另一个方向把通道做得越来越多。这两件事放在一起，特别适合从系统角度想一想。

欢迎收听系统边界，System Boundary。我是 Zach，本期使用我授权的 V2 合成声音。今天把 OCP 首日的几场演讲和展会观察连起来讲。页面下方有配套幻灯片和现场照片，可以跟着音频翻页。我们先看推理机架怎样组织，再看电和光的连接，最后回到内存，以及这些东西该怎样做验证。

• 图文来源：现场 P19、P23、P31；三组 session

02 · Astera 的开放机架

Astera Labs 这场演讲，题目是 Bring Your Own XPU。它面向的，是希望把自己的计算芯片放进一个可扩展系统的团队。Astera 的产品从重定时器、PCIe 交换芯片，到 CXL 内存连接和管理软件，覆盖的是计算芯片周围那些必须配合工作的部分。

现场的机架图，把计算托盘、交换 fabric、内存资源和连接托盘分开。这样做的一个实际好处，是计算芯片和互连的更新节奏可以不同。换一代计算芯片，不一定要求所有资源都跟着重新设计。反过来，系统需要更多外部内存或更远的连接时，也可以先调整对应部分。

但开放机架真正给设计团队出的题，是先想清楚扩展目标。假设我们有一张推理卡，现在跑不下更长的上下文。原因可能是本地内存容量不足，也可能是内存带宽跟不上，还有可能是多卡之间搬数据太慢。三种情况需要的系统完全不同。把它们都写成需要扩展，很容易在后面的接口选择上走偏。

所以我看这张图时，最想补上的，是每一条路径上的数据类型。模型权重在哪里，临时激活在哪里，KV cache 在哪里，哪个阶段会跨卡通信。位置画清楚以后，才有办法判断交换芯片的端口和外部内存到底值不值得加。

• 图文来源：OCP1-09、OCP1-13；S08

03 · PCIe fabric 的有效吞吐

在具体实现上，Astera 展示了 Scorpio X 系列的三百二十 lane PCIe 六代交换能力，以及多计算单元组成的机架方案。通道数量很醒目，不过有用的吞吐最终还要通过软件和拓扑兑现。

举个工程上的例子。如果两个加速器能直接做点对点的数据传输，路径就可能绕开主机内存。可是这个可能，取决于设备、平台固件和软件栈是否真的支持相应事务。即使两台设备都标着同一代 PCIe，应用能用到的路径也不一定一样。再往上，还有流控、队列深度，以及请求和返回经过的交换层数。

当系统里只有一条流量时，峰值带宽通常不难测。多个计算单元同时交换激活，或者同时迁移 KV cache，热点就会出现。我们需要知道最慢的那一小部分请求被拖了多久，因为推理服务的体验经常由尾延迟决定。

这也是 Astera 把 COSMOS 这类管理软件和芯片放在一起介绍的原因。链路训练、健康状态、拓扑发现和出错后的定位，都会消耗系统工程时间。对要做完整产品的团队，供应商能提供多清楚的可观测性，和端口本身的性能同样值得评估。

• 图文来源：现场 P33–42；S08

04 · MoE 通信中的多播与归约

这场演讲里，和推理负载联系最紧的，是 Hypercast 和网络内计算。理解它们，可以从混合专家模型开始。一个 token 经过路由后，会送给选中的专家。专家分布在不同计算单元时，数据就要跨互连分发。

如果同一份数据需要发给多个目标，源端重复发送会占用额外带宽。Hypercast 提供有选择的多播能力，让 fabric 承担一部分复制和分发。另一边，多个节点的结果需要合并时，就出现归约。网络内计算希望把某些归约操作放到通信路径上，减少数据来回搬运。

这里最有意思的，是交换 fabric 开始理解常见的通信形状。一对多和多对一，原来只是应用软件的行为，现在可以在互连里得到专门支持。当然，收益跟负载关系很大。专家选择很稀疏、目标高度集中，或者计算与通信能够充分重叠时，结果都会不同。

因此，评估这类平台时，我会先准备几种真实的通信矩阵。单模型多卡、专家并行、预填充与解码分离，各自测一遍。然后保留相同计算任务和数据规模，对比通信耗时、拥塞程度，以及一条链路恢复时业务损失了多少工作。这样得到的结论，能直接进入架构预算。

• 图文来源：OCP1-05、OCP1-07；S08

05 · 外部 KV cache 的访问路径

展台上的 Leo CXL 方案，把刚才的机架问题进一步落到了 KV cache。长上下文推理需要保存越来越多的历史状态，外部内存可以提供容量，但每次访问都要经过具体的链路。

我们可以设想一个分层系统。当前 token 经常访问的数据，留在计算器件附近。访问较少的历史片段放到外部容量层，提前预取或按需调入。这个方案好不好，取决于访问的时间规律。命中率提高一点，可能省下很多链路往返。预取判断失误，又会把带宽浪费在暂时用不到的数据上。

所以外部 KV cache 的评估，需要同时测容量和时间。增加容量后能接纳多少并发，首个 token 的等待有没有增加，长请求会不会挤压短请求，以及多个任务同时迁移时会不会造成队头阻塞。软件的数据放置策略，要和硬件接口一起看。

Astera 这一组材料给我的启发是，推理卡扩到机架以后，产品边界确实会变大。计算芯片之外，内存层级、通信库和管理软件都变成性能的一部分。接下来 OIF 的演讲，则把镜头拉到一条连接本身，看看速率继续提高时，电通道会发生什么。

• 图文来源：现场 P41–42；S08

06 · 448G 的通道分类

OIF 这组分享有三位讲者。TE 从连接器和物理结构切入，Cisco 关注系统通道，Broadcom 讨论调制和接收机。把三个视角放在一起，才能理解四百四十八 G 每 lane 为什么难。

先说一个最基本的区别。同样的数据率，封装附近的短连接，和穿过一段主板再经过连接器的连接，承受的损耗、反射和串扰完全不同。OIF 用 XSR、VSR、MR、LR，以及 Linear 等应用类别组织这些讨论。它们帮助行业对齐不同距离和位置上的要求，具体接口协议还在持续推进。

现在公开的 VSR 工作目标里，可以看到至少两百毫米的主机走线、二十毫米的模块走线和一个连接器。这个描述很有价值，因为它把一个抽象的高速接口，变成了可搭建、可仿真、可测量的通道。

对芯片团队来说，选 SerDes 之前最好就把这条通道画出来。封装逃线有多长，过几个过孔，连接器怎样放，温度覆盖多大范围。短距离接口的低功耗优势，来自通道真的足够短、足够可控。只有名称叫短距，实际走线却很复杂，接收机最终还是得为那些损耗付出代价。

• 图文来源：OCP2-01–08；S09–S10

07 · PAM4 与 PAM6 的带宽取舍

讨论调制方式时，现场反复出现 PAM4 和 PAM6。PAM4 有四个幅度电平，理想情况下，一个符号可以表达两个比特。PAM6 使用六个电平，单位符号承载的信息更多，所以在相同数据率下，可以降低符号率。

做一个理想换算。两百二十四吉比特每秒的 PAM4，奈奎斯特频率约五十六吉赫兹。数据率翻到四百四十八 G，PAM4 就来到约一百一十二吉赫兹。换成 PAM6，理想奈奎斯特频率约八十六点七吉赫兹。实际编码有开销，但这个比较说明，为什么带宽压力会把更多电平带进讨论。

接着看付出的代价。如果总摆幅相同，六个电平之间的距离比四个电平更小。噪声、非线性和串扰就更容易把接收判决推错。于是调制方式需要和接收机、均衡、纠错一起设计。

这也解释了为什么某一段链路可能偏向 PAM6，另一段仍然适合 PAM4。高频衰减严重时，减少带宽很有吸引力。通道很短、信号质量很好时，增加电平带来的复杂度可能没有必要。设计的答案，藏在具体通道的频率响应和噪声预算里。

• 图文来源：OCP2-13–25；S09；理想映射复算

08 · 封装与连接器消耗眼图裕量

当频率进入这个范围，过去看起来很小的结构细节，会变成明显的信号问题。封装焊球、过孔的残桩、连接器的过渡，都可能产生反射。差分对两根线的传播时间不一致，还会造成模式转换，把我们希望保留的差分能量转到别的模式上。

如果只盯着整条通道的插入损耗曲线，有些问题会被掩盖。平均损耗不高，不代表某个频段没有很深的凹陷。总长度很短，也不代表每个过渡都设计得好。现场关于连接器和布线的讨论，提醒我们把每个不连续点单独拿出来检查。

一种应对方式是 CPC，也就是把电缆的连接位置靠近芯片，减少高损耗的 PCB 路径。它能缓解电气压力，同时改变机械和运维的工作方式。电缆怎样固定，散热器周围有没有空间，现场能不能更换，插拔对周边器件有什么影响，这些问题会一起出现。

因此，高速 IO die 的评估最好由封装、板级和芯片团队一起完成。先约定一组真实通道，再讨论发射摆幅和均衡深度。这样可以看清哪些功耗是接口本身需要的，哪些是为具体物理结构补偿的。

• 图文来源：OCP2 物理通道部分；S09

09 · 接收机复杂度与系统延迟

接收机里的处理也不能只看某个算法能把误码率改善多少。前馈均衡、判决反馈均衡、更复杂的序列检测，以及内部纠错，各自都消耗功耗和时间。有的设计能容忍更差的通道，却可能增加固定延迟。还有的处理会改变错误的分布，让错误集中成一串。

这时，纠错能力和重传机制就必须接上来考虑。平均误码率相同，两条链路对业务的影响仍可能不同。一条是零散错误，另一条偶尔出现长串错误，后者更可能把整个包或事务打断。

把这场演讲和展台上的 MicroLED 放在一起看，就能理解两条路线各自把困难放在哪里。高速窄通道花更多精力处理带宽和信噪比。低速宽并行降低单通道速率，却增加了驱动、接收、时钟和物理接口的数量。数量一多，阵列一致性、良率、光纤耦合和通道管理就成了大问题。

比较方案时，我会把有效吞吐、整跳能耗和故障后的恢复放在同一张表里。这样才不会一边拿最好的器件数字，另一边拿完整产品数字。下一场 Meta 的分享，恰好提供了一个很具体的例子，告诉我们链路进入生产系统以后该怎样评价。

• 图文来源：OCP2-20–25；S09

10 · Meta 的 LPO 生产配置

Meta 这场分享讨论线性可插拔光模块，也就是 LPO。传统带重定时的模块，在模块内部做较多数字信号处理。LPO 把模块内的数据路径简化，主机 SerDes 就要承担更多均衡和链路管理工作。

它吸引人的地方很直接，少一些高速处理，模块的功耗和发热就有机会降下来。但系统设计者随后会问，这些工作转移到主机侧以后，实际网络会不会更难用。Meta 的价值在于，它拿出了生产网络和实验室两组数据。

先看生产配置。现场材料写的是大约四千个模块，四个月运行时间。两个四百 G 的 FR4 组合以八百 G 模式工作，在 DTSW 到 EDSW 的一跳连接上，两端都使用 LPO，其余网络仍然采用带重定时的光模块，软件是 FBOSS。

这些条件需要和结果一起记下来。它们告诉我们，数据来自一个有明确边界的部署范围。这里既有光模块，也有主机 SerDes、交换平台和软件版本。把这几项记录完整，后面的故障统计才能解释清楚，也才能决定哪些验证方法适合迁移到自己的系统。

• 图文来源：Meta 上传照片与录音；生产配置页

11 · LPO 的生产中断统计

生产结果里，Meta 把带重定时的链路作为比较基准。LPO 的链路中断约为基准的一半，影响业务的失败约为基准的二点六分之一。只看最后六十天，链路中断进一步降到基准的八点四分之一。

我觉得最后这个时间窗口尤其值得留意。系统上线后，软件会调整，运维团队会学习，故障定位也会更准确。改善随运行阶段变化，说明我们评估连接技术时，应该把运行成熟度记录下来。

从业务角度，中断的价值也不只是一条告警。假设推理请求正在跨多个计算单元传递状态，一次链路恢复可能触发重试，增加尾延迟，甚至让部分工作重新执行。训练任务则可能损失更多已经投入的计算。因此，中断次数、每次恢复时间、丢失的工作量，最好分别统计。

这样的统计方式，对还处在原型阶段的光链路也很有用。早期就把设备日志、误码计数和业务事件放到同一时间轴上，后面碰到偶发问题时，就能判断先发生的是温度变化、误码上升、链路重训，还是管理软件超时。光链路可观测性的价值，会随着系统规模扩大而放大。

• 图文来源：Meta 生产结果原始照片；相对值按现场标注

12 · Meta 的长期实验室验证

实验室这边，Meta 使用大约一千个模块，在 MiniPack3 平台上做光回环，累计了两百九十六万 link-hours，观察到零次模块归因的失败。这里的 link-hours，可以理解成所有受测链路有效运行时间的总和。它比只说连续跑了多少天，更方便比较不同规模的测试。

功耗和热的数据也很具体。在相同固定风扇转速下，模块功耗降低百分之四十六，温度降低十七点五摄氏度。这个结果能解释 LPO 的吸引力。模块附近的热压力下降，会影响器件工作点，也会改变系统散热的余量。

但整机是否省下同样比例的电，还要把主机 SerDes 的处理和风扇策略纳入测量。我们可以先在相同风扇条件下比较模块自身，再换成实际控制策略比较整机。分两步做，结果更容易解释。

这组实验对应每 lane 一百 G 的代际。往两百 G 或其他光源路线迁移时，需要重新建立自己的通道和环境基线。可复用的是验证的组织方法，包括测试时长、受测数量、失败归因和环境条件。把这些记录好，零次失败这个观察结果才有明确的统计背景。

• 图文来源：Meta 实验室结果照片；上传演讲资料

13 · 误码与光功率的长期漂移

Meta 还展示了更细的信号质量数据。纠错之前的误码率，中位数大约是十的负九次方。两组 FEC bin 的典型值都是二，最差值在线性模块一侧是五，带重定时一侧是七。具体测试平台的 bin 定义要保留，但把分布和最差通道一起报告，这个习惯值得直接借用。

光功率方面，现场给了八条 lane、一百零四天的观察。峰峰变化不超过零点二五 dB，单条通道漂移不超过零点零四 dB。对光电系统，长时间的小幅变化往往比一张漂亮的瞬时眼图更接近实际使用问题。

我们可以把原型验证分成几个连续步骤。先建立逐通道的基线，再改变温度和供电条件，接着做长时间运行，最后加入故障注入。比如让某条通道变弱，观察监测什么时候发现异常，备用通道什么时候接管，以及接管过程中有效吞吐和事务延迟怎样变化。

这就把 Meta 和 Credo 两部分接上了。Meta 在使用者一侧看持续可用性，Credo 则尝试把一部分可靠性直接做进物理链路。下面回到展台，仔细看那一排发光器件和成束的光纤。

• 图文来源：Meta 长期漂移与 FEC 结果原图

14 · Credo 的产品与技术背景

Credo 原来的强项，是高速连接芯片和有源线缆，包括 SerDes、gearbox、重定时，以及链路诊断软件。它在二零二五年收购了做 MicroLED 光互连的 Hyperlume。这段背景很有帮助，因为我们在展台上看到的，已经是把高速电接口、光器件和管理能力组合起来的一条连接产品线。

十月十二日的官方发布，把一点六 T 的 ZeroFlap Active Light Cable，也就是 ALC，定位在机架排尺度的连接。公开设计目标包括最长五十米、每端十二瓦，并计划在二零二七年交付。现场标牌也给出了相同的关键数字。

这条路线把高速主机通道拆成大量低速光通道。单条光通道采用相对简单的 NRZ 调制，用空间并行补回总带宽。它瞄准的是铜连接距离受限，而传统光模块的功耗和成本又偏高的那一段应用空间。

对合作方来说，Credo 的角色可以理解为连接系统的整合者。发光器件供应商、光纤和连接器供应商，以及电接口芯片团队，需要在一个实际链路里配合工作。现场原型恰好让我们看到这些接口具体长什么样。

• 图文来源：P54；S01–S02；C01

15 · 蓝色发光区域与光纤接口

现在这页是我现场拍的近照。透明保护罩下面，板上两处连接区域发出蓝紫色的光，黑色引出线从连接头往外延伸。另一张带环境的照片里，可以看到 ams OSRAM 的 Micro Emitters 标牌。现场交流中，工程师也说发光器件来自 OSRAM。

我特意把这张照片保留下来，是因为它把抽象的光互连变成了可以讨论的装配对象。光源、耦合区域、连接头、固定结构，以及周边的电路，需要在有限空间里同时成立。合作讨论可以直接从这些位置开始。

例如，发光阵列和光纤之间怎样定位，装配偏差会引入多少损耗，连接头受到外力时，力会不会传到光学耦合位置。多条通道聚在一起以后，单个接口的面积、纤束弯曲和维护空间，都要进入设计。

照片中的颜色保留了当时相机看到的样子。具体工作波长、材料结构和耦合尺寸，仍然要由器件资料给出。对这次演示，我们把现场看到的蓝色发光实物，与工程师关于 MicroLED 的介绍放在一起记录，就能为后续交流留下清楚的对象。

• 图文来源：P23–25；现场工程师交流

16 · 8 组 128 lane 的带宽组织

展台界面上最值得核对的，是通道的组织方式。页面明确写着，每侧八组，每组两百 G，点开一组可以看一百二十八条 lane 的状态。八组乘起来，是每个方向一点六太比特每秒，也就是一千零二十四个可显示的通道位置。

把一组的两百吉比特每秒除以一百二十八，得到一点五六二五吉比特每秒。这个数量级，和工程师口述的单通道约一点六 G 很接近。

界面里的位置数、物理发光点的数量，以及最终承载有效数据的通道数，需要保留各自的层次。因为现场架构图同时出现了数据、备用和管理通道。要准确计算净荷带宽，还需要知道这些通道怎样映射，以及有没有编码和管理开销。

宽并行架构的工程味道，也正是在这里体现出来。单条通道很简单，但整个系统要让上千条通道工作在同一个节奏里。时钟怎样分发，通道间时延怎样对齐，某一条出问题后怎样替换，都会直接影响产品的可用性。

• 图文来源：P26、P31–32；现场口述与算术复核

17 · Gearbox 与通道重映射

架构图把主机接口接到 gearbox，再经过 crossbar，连到发光阵列。Gearbox 负责高速通道和多条低速通道之间的数据组织。Crossbar 提供重新安排通道映射的能力。旁边还有管理控制器，配合数据、备用和管理通道工作。

这样就能理解备用通道的作用。某条光路变弱时，系统希望先通过监测发现变化，再把逻辑数据搬到健康的备用位置。应用看到的逻辑连接尽量保持连续，底下的物理通道可以发生替换。

这种机制需要光学和数字电路共同配合。监测指标是否足够敏感，切换阈值怎样避免来回抖动，重映射时数据怎样对齐，都要在真实流量下验证。只有把切换过程测出来，才能知道它对尾延迟、错误突发和业务重试有什么影响。

现场工程师确认相关芯片由他们内部设计。我们问到更细的工艺节点和模拟数字集成方式时，对方表示暂时无法公开。现阶段最有价值的后续资料，是接口和测试结果。知道怎样连接、怎样控制、怎样测量，就可以先启动一轮具体的工程评估。

• 图文来源：P30；现场口述；S02

18 · 单通道能耗与整条线缆功耗

现场另一个容易引起兴趣的数字，是每比特一个皮焦耳。先把算术做清楚。一个皮焦耳每比特，乘以每秒一点六吉比特，就是每条通道一点六毫瓦。

如果想继续换算电流，还需要供电电压。假设这部分功耗来自一伏供电，平均等效电流就是一点六毫安。两伏时约零点八毫安，三伏时约零点五三毫安。LED 的瞬时驱动电流，还取决于偏置、摆幅和数据占空比，所以这里算的是指定供电下的平均等效值。

再看完整产品。按每端十二瓦，两端一共二十四瓦。如果两个方向都以一点六太比特每秒满载，总带宽是三点二太比特每秒，折算约七点五皮焦耳每比特。如果只用一个方向的一点六 T 做分母，在两端仍消耗二十四瓦的假设下，结果就是十五皮焦耳每比特。

这几组数字放在同一页，能帮助合作方把功耗拆开讨论。高速主机接口、gearbox、时钟、发射和接收前端，以及管理和备用资源，各自占多少。完成这张功耗分解表后，才知道下一步优化应该花在光源、驱动电路，还是端点的数据处理上。

• 图文来源：现场口述；P54；S01–S02；基于明确假设复算

19 · 连接器与背板决定扩展密度

现场还有一张背板方向的展示，写到百分之十五的超额配置，以及盲插连接。把这张图和实物线缆放在一起看，会发现光互连的扩展，最终受到物理接口很强的约束。

上千个通道需要稳定地穿过连接器。阵列间距、定位公差、清洁方式和插拔寿命，都可能决定实际交付成本。备用通道也占物理资源，因此冗余比例必须和良率、维修策略一起设计。现场背板图展示的是进一步扩展的架构方向，具体指标要按相应产品阶段讨论。

会期的官方消息补上了产业分工。Credo 发起了 OCP 的短距微发射器光互连工作，简称 SRMO。ams OSRAM 宣布参与，贡献微发射器、微探测器、CMOS 和先进封装相关能力。SENKO 则在连接器接口上参与讨论。目标规范覆盖信号、功耗效率、并行度、模块和连接器等内容，计划在二零二七年推进审批。

对潜在合作方，这给了一个很明确的入口。光源团队可以谈器件工作点，驱动团队可以谈电接口，封装团队可以谈耦合和装配，纤路团队可以谈接口与维护。把这些接口写清楚，演示才有机会成为可重复制造和交付的系统。

• 图文来源：P22、P55；S03；C02

20 · VCSEL 并行光连接

接着看另一条并行路线，VCSEL。它是一种垂直腔面发射激光器。Lumentum、Astera Labs 和 Corning 的联合展示，把一千零六十纳米的二维 VCSEL 和光探测阵列、光纤，以及 PCIe 平台放在一起。

公开材料介绍了每通道三十二吉比特每秒的 NRZ，以及 PCIe 五代的链路演示。和刚才单通道约一点六 G 的 MicroLED 展示相比，它把单通道速率提高了一大截，因此达到相同总带宽所需的通道数可能更少。

相应地，驱动带宽、接收前端和光学耦合也要适应更高的单通道速率。阵列间距、散热、光功率分布和光纤连接，仍然是系统工程的核心。我们不能只拿一个发光器件的峰值速率来比较，还要把接收机和完整装配一起带上。

这条路线特别值得做成实物对照。用相同的有效吞吐和应用距离，比较 MicroLED 与 VCSEL 的端点功耗、面积、纤数和制造步骤。这样就能知道，减少通道数带来的封装收益，是否足以抵消单通道电路和器件上的额外要求。

• 图文来源：P35–40；S05

21 · Lightmatter 用 WDM 提高每纤带宽

Lightmatter 展示的 Passage EVK100，提供了第三种很不同的组织方式。它把多个波长放进同一根光纤，用波分复用提高每纤带宽。现场配置写到十六个波长和一百一十二 G PAM4，对应每根光纤单方向一点六太比特每秒，并使用两百米单模光纤回环。

这里，最醒目的量是每根光纤可以承载多少数据。对于机架和封装，纤数减少会影响连接器面积、布线和装配。为了得到这些收益，系统需要硅光器件、光源、波长管理，以及匹配的电接口能力。

官方给出的能效目标包含光源，这一点在比较时很有用。光源集中供给还是贴近端点，怎样分配功率，温度变化怎样影响波长，都会进入系统预算。

把三条路线并排看，空间并行、提高单通道速率、增加波长数，其实是三种分配带宽的方法。它们各自占用不同的器件、封装和维护资源。对于具体产品，最值得算的是在目标距离和环境下，哪一种组合能稳定提供所需带宽，并且留得出可制造和可维修的余量。

• 图文来源：P11–13；S06–S07

22 · 模块制造与机架散热

展会上还有几类公司，很适合放在这张系统图的外围一起看。InnoLight 和 TeraHop 的模块与光引擎展示，提醒我们从样品走到产品，需要一整套封装、测试和批量交付能力。现场从四百 G、八百 G 到一点六 T，也包括 LPO、近封装和共封装等形态。

Ciena 展示的连接和光引擎方案，把光电的位置进一步推近计算和交换器件。位置越近，高速电路径越容易缩短，但散热、供电和更换方式也会一起变化。nVent 的后门换热器，则让这些问题直接落到机架和设施接口上。

对做光互连的团队，这些公司提供的价值各不相同。器件伙伴解决能否发出和接收到光，模块伙伴解决怎样稳定装成产品，系统和散热伙伴解决产品装进机架后怎样运行。会后的交流对象，可以按自己当前最缺的那一段能力来选。

看完连接，再回到连接到底在搬什么数据。展会上的内存方案很丰富，它们分别把容量、带宽和计算放到了不同位置，这部分对推理系统尤其值得仔细整理。

• 图文来源：P4–10；S16–S20

23 · 推理系统的内存层级

推理系统里的数据，访问规律差别很大。权重通常大量读取，KV cache 随着请求持续增长，检索数据又可能很大但访问比较稀疏。把它们都塞进同一种内存，成本和功耗往往不理想。

因此，展会上的内存产品可以按角色来理解。靠近计算的高带宽内存服务热点数据，CXL 扩展提供额外容量，近内存计算尝试减少数据搬运，HBF 则把更大的闪存容量带到高带宽封装方向。SSD 后备层又是更远的一层。

每多一层，都要问一个很具体的问题，哪些访问会落到这里，平均等待和最慢等待是多少。软件能不能提前知道数据何时会用到，也决定了层级能不能发挥作用。

• 图文来源：P1–3、P41–53；S11–S15

24 · XCENA 的计算内存

XCENA 是一家面向计算内存的芯片公司。MX1 的现场材料把 CXL 三点二、PCIe 六代、DDR5 扩容，以及大量 RISC-V 和数据处理能力放到一起。它希望让一些工作直接在数据附近完成。

例如，检索和预处理有时需要读很多数据，最终只返回很少的结果。如果能在内存附近完成筛选、压缩或部分计算，经过主机接口的数据就会减少。收益来自具体的数据路径，而不是简单地在内存旁边放更多核心。

XCENA 还展示了通过 DRAM 热缓存和 SSD 后备容量扩展访问空间的思路。这个方向很适合长上下文和大容量数据集，但尾延迟会强烈依赖命中率和访问局部性。评估时要带上真实请求，尤其要把缓存未命中的情况单独拿出来看。

现场不同产品分支的成熟度也不同，有的样品已经提供，有的写着二零二七年采样。合作节奏要按具体型号确定。技术交流最需要的是可运行的软件开发包、数据布局示例，以及一套能复现收益的工作负载。

• 图文来源：P1–3；S11–S12

25 · SK hynix 与 Marvell 的 CXL 方案

SK hynix 和 Marvell 的展示，可以帮助我们把内存扩展和近内存计算再分细一点。现场的 CMM-Ax 使用五百一十二 GB 内存，四通道 DDR5，以及十六个 Arm Neoverse V2 核心。它让计算靠近内存，面向检索等数据处理任务。

这里很容易出现一个比较误区。模组本地访问 DDR 的带宽，和主机通过 CXL 读取模组的带宽，是两个不同的位置。近内存计算的意义之一，就是利用本地更宽的数据路径，把主机真正需要的结果送回去。

另一类 CMM-DDR5 模组更直接地承担容量扩展。我们选择哪一种，取决于软件是否愿意把任务放到模组上。如果应用只把它当作远端内存，计算核心可能发挥不了多少作用。愿意调整数据处理流程，才有机会减少跨接口的数据量。

因此，先选一个明确的任务做评估，比泛泛讨论内存墙更有效。比如向量检索、KV 管理或压缩，固定输入数据和结果质量，观察 CPU 占用、系统功耗和请求尾延迟的变化。

• 图文来源：P47–49、P51–53；S13–S14

26 · FAISS 演示的能效复算

Marvell 的 FAISS 演示给了一组可以当场复算的数字。服务器本地 DRAM 的方案，六十四个核心，四万两千五百 QPS，九百瓦。四个 Structera A 的方案，六万六千四百 QPS，四百四十瓦，两组的召回率都标为百分之九十五。

先比吞吐，六万六千四百除以四万两千五百，约是一点五六倍。再比每瓦查询数，前者约四十七，后者约一百五十一，所以能效约三点二倍。现场页脚用了另一个更大的概括数字，我在这里采用可以由表中数据直接复算的三点二倍。

这组展示说明了一个值得验证的方向，部分检索工作靠近内存后，可以减少主机侧的负担。不过，是否适合具体业务，还需要知道索引类型、向量维度、数据规模、batch 和功耗统计范围。

合作交流时，把这些条件作为一个可复现的测试包，比只交换一个倍数更有帮助。团队拿自己的数据跑一遍，才知道收益主要来自减少搬运、更有效的并行，还是任务实现方式的差别。

• 图文来源：P53；按现场表格复算

27 · HBF 面向读密集容量层

HBF，也就是高带宽闪存，是另一个值得跟踪的方向。SK hynix 的现场材料展示了八层和十六层 NAND 堆叠，最高五百一十二 GB 容量，以及零点四到三太字节每秒的不同带宽档位，并提到 UCIe 接口。SK hynix 和 Sandisk 也已经在 OCP 推进相关技术规范。

对推理来说，它吸引人的地方是读密集的大容量数据，比如模型权重。但 NAND 的访问粒度、写入行为和耐久性，和 DRAM 有很大差别。即使峰值读取带宽很高，系统也需要合适的数据布局和调度方式。

我们可以把问题拆得更具体。模型加载时怎样组织数据，运行中哪些部分需要频繁改写，小块随机访问要经过哪些缓冲，软件能否把读取做得足够连续。回答了这些问题，才能决定 HBF 应该放在内存层级的哪一层。

这部分和前面的光互连其实连在一起。内存放得更远或分得更多，互连就要承担相应的数据搬运。计算、内存和连接的取舍，需要在同一个工作负载里闭合。

• 图文来源：P45；S15

28 · 把现场观察变成可测的实验

把一天的材料收回来，我会优先启动两类验证。系统这边，先固定一组推理和检索任务，明确结果质量，再比较本地内存、外部容量和近内存计算。每个方案都记录有效吞吐、尾延迟，以及完整系统的功耗。

链路这边，先建立逐通道的基线，再做温漂、长期运行和故障注入。如果采用宽并行光连接，就把备用通道和重映射一起加进原型。这样光源效率、装配良率和业务连续性之间的关系，会逐渐变得清楚。

和合作企业的讨论，也可以围绕这些实验来组织。器件参数用于选工作点，接口资料用于确定连接方式，样品和软件用于复现系统结果。每次交流最好都能推动一个具体测试，而不是只增加一份参数表。

这次 OCP 首日最有价值的收获，是很多过去分开的事情开始出现在同一个系统里。发光器件旁边有 gearbox，光纤接口旁边有健康监测，内存旁边有计算，机架旁边有散热和维护设计。我们下一步要做的，就是把这些关系放进自己的实验，逐项测清楚。现场照片、计算口径和官方来源，都放在配套幻灯片与节目页面。

• 图文来源：本文工程分析；三组 session 与展台资料