一张PCIe Gen6扩展卡背后的故事：从“插一张卡”到重新设计服务器架构过去几年，PCIe扩展环境其实一直比较简单。服务器主板提供几个PCIe x16插槽：插GPU；插网卡；插SSD；插DPU。如果插槽不够怎么办？很多工程师第一反应：“加一个PCIe Switch。”但是进入PCIe 5.0、PCIe 6.0时代以后，这个问题开始变复杂。因为现在服务器里面的设备越来越多：AI训练需要多颗GPU；推理服务器需要GPU + 高速NVMe SSD；DPU需要独立PCIe通道；CXL设备开始进入服务器；EDSFF SSD需要大量高速Lane。这时候，传统“主板给几个槽位”的方式已经无法满足需求。真正的问题变成：如何把CPU有限的PCIe Root Complex资源，重新组织成一个高密度、高灵活性的高速互连系统？这也是PCIe Switch存在的价值。最近看到的一款基于Broadcom Atlas3 PEX90144 PCIe Gen6 Switch芯片设计的MCIO Switch Board，就是针对这一类问题设计的高速扩展平台。一、核心芯片：Broadcom PEX90144到底有多强？这张PCIe Gen6 MCIO Switch Board最大的特点，就是采用：Broadcom Atlas3 PCIe Gen6 Switch PEX90144它不是简单的PCIe转接芯片，而是一颗真正面向下一代服务器架构的PCIe Gen6交换芯片。根据规格：支持PCIe Gen6；最大144 Lane；最大72个PCIe Port；可以划分为9个16 Lane Station；支持Managed FW和Unmanaged FW两种模式。简单理解：一颗CPU出来的PCIe资源，通过这颗Switch，可以重新分配成几十个高速设备连接口。如果把传统服务器比作“一条高速公路”，那么PCIe Switch就是一个超级立交桥。CPU只有有限入口：Switch的作用：不是增加CPU本身的PCIe能力；而是重新调度这些高速Lane。二、为什么选择MCIO，而不是传统PCIe插槽？很多工程师第一次看到这张板，会问：为什么不用PCIe Slot？为什么大量使用MCIO？原因很简单：服务器未来不会只有几个PCIe槽。尤其是AI服务器。内部越来越多采用：MCIO；OCP NIC接口；EDSFF SSD；JBOF背板。这张板上一共有：18个PCIe Gen6 MCIO x8连接器其中：8个UMCIO接口；10个标准MCIO接口。其中UMCIO更加灵活。它可以：配置成Root端；配置成Device端；支持单Host；支持Multi-host；支持Virtual Switch模式；支持MR-IOV（需要Managed FW）。而普通MCIO接口主要用于连接：1）如何连接server主机一般建议通过Saniffer提供的PCIe 6.0 retimer卡（2个MCIO Gen6 x8 connector)连接主机端，参见下图。2) GPU/DPU/NIC各类server插卡类扩展通过：MCIO x8转换：x16 AIC Slot Adapter连接：GPU；DPU；NIC。3）NVMe SSD和JBOF存储盘柜扩展通过：MCIO连接：E3.S SSD；E1.S SSD；U.2/U.3 SSD；M.2 SSD4）AI/MI(machine learning)存储节点三、一个典型应用：16颗GPU到底怎么扩？之前很多工程师问：“服务器只有8个GPU槽，如果我要扩展16颗GPU怎么办？”传统方式：买更大的服务器。但是PCIe Switch提供另一种思路。例如：Switch负责：Lane分配；PCIe协议交换；数据转发。对于AI服务器：可以实现：CPU↓PCIe Gen6 Switch↓GPU Cluster↓NVMe SSD Storage形成：GPU + SSD + DPU统一高速互联。手册中也展示了AI/ML场景：通过Switch连接：Host；NVMe SSD；GPU Cluster；支持AI存储和GPUDirect应用。四、PCIe Gen6 SSD测试环境的新玩法对于做PCIe SSD验证的人来说，这类Switch更加重要。因为未来Gen6 SSD测试不会只是：“一块SSD插服务器。”而会变成：为什么？因为企业级SSD测试需要：多盘并发；多端口测试；JBOF环境；压力测试；热插拔；错误注入。例如：一个Gen6 Switch：连接：8 Bay E3.S JBOF里面：8颗PCIe Gen6 SSD。测试人员可以模拟：真实AI服务器存储环境。五、真正有价值的地方：它不是黑盒，而是可以管理很多PCIe Switch产品最大的问题：买回来能跑。但是：出了问题不知道怎么办。这张板提供完整CLI管理能力。通过USB Type-C管理接口：可以访问：UART；I2C；Switch管理接口。板上还有MCU：负责运行CLI命令。下面看看几个工程师最关心的命令。六、PCIe Gen6 Switch常用CLI命令解析1. showport：查看所有PCIe链路状态这是最常用命令。作用：查看所有MCIO Port当前Link状态。例如：测试环境：SSD无法枚举。第一步：showport查看：Link Up/Down；Speed；Lane Width。类似PCIe Analyzer里面查看LTSSM状态。2. lsd：查看电源和温度状态lsd可以查看：MCU温度；风扇转速；12V输入电流；板上关键电压。对于PCIe Gen6高速Switch：电源稳定性非常重要。因为：144 Lane同时工作时，任何电压波动都可能导致：Link Error；Replay；Recovery。3. conrst：模拟设备ResetPCIe测试里面经常需要：重新拉PERST#。命令：conrst可以对MCIO连接设备发送：300ms PERST#。用途：模拟：SSD Reset；Hot Reset；异常恢复。4. ver / sysinfo：确认系统版本测试环境最怕：硬件一样。Firmware不同。因此：ver查看：MCU FW；Atlas3 FW版本。Sysinfo查看：整个Switch Board状态。5. fdl：升级FirmwarePCIe Gen6时代：Firmware越来越重要。fdl支持：MCU升级；Switch FW升级。包括：fdl minifdl mainfdl fwfdl mcu用于不同Firmware区域更新。6. mw / dr / dp / df这些属于高级Debug命令。mw写Switch寄存器：mw <register><data>用于：修改Atlas3寄存器。dr读取Switch寄存器：dr用于：Debug芯片内部状态。dp读取Port寄存器：dp port_number定位：某一个PCIe Port问题。df读取Flash内容：用于：Firmware Debug。这些命令对于普通用户可能不常用，但是对于：PCIe专家；Switch开发人员；高级验证工程师；非常关键。七、这张卡最适合哪些人？场景1：PCIe Gen6设备开发公司例如：开发：GPU；DPU；SSD Controller；NIC；CXL设备。需要：提前搭建Gen6环境。不用等待完整服务器。场景2：AI服务器验证团队未来AI服务器：不会只是：8 GPU。可能：16 GPU；32 GPU；GPU + SSD池。需要：PCIe Switch重新组织资源。场景3：SSD厂商和测试机构尤其是：PCIe Gen6 E3.S SSD。测试：多盘性能；并发压力；热插拔；Fault Injection。场景4：高校和研究机构研究：PCIe拓扑；CXL；GPU互联；Storage Fabric。这类开放平台非常适合教学和研究。八、PCIe Gen6时代，Switch不是扩展，而是重新定义服务器连接方式过去：PCIe Switch只是：“不够插槽时的补丁”。但是进入PCIe 6.0时代：情况正在改变。随着：AI GPU数量增加；NVMe SSD密度增加；CXL设备出现；数据中心架构变化；PCIe Switch正在成为服务器内部的重要基础设施。一张144 Lane的PCIe Gen6 Switch Board，本质上不是一个简单扩展卡。它更像：一个小型PCIe高速交换网络。未来测试PCIe Gen6设备时，真正的问题可能不再是：“有没有插槽？”而是：“有没有能力搭建一个完整、高速、可调试的PCIe生态环境？”这也是为什么下一代PCIe验证平台，需要：Switch + Retimer + Analyzer + Exerciser + SSD + GPU共同组成完整测试体系。PCIe 6.0的时代，连接方式正在改变。而真正懂得如何搭建高速互联环境的人，才有机会提前进入下一代计算平台的核心验证环节。更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

这次交流，起点不是一台设备，而是一批卖到巴西市场的消费类SSD。事情很现实：巴西当地一家大型连锁商超，类似沃尔玛或Best Buy这种消费电子零售渠道，从中国采购消费类SSD，在门店销售给普通用户。问题是，退货率越来越高。有些用户买回去只用了半天，数据丢了，盘也不能用了，最后只能退货。这类问题表面看是售后问题，往深一点看，其实是采购环节的质量筛选问题。过去很多消费类SSD采购，尤其是价格敏感型市场，大家首先看报价：同样容量，谁便宜买谁。但SSD不是一个简单的塑料外壳产品，里面有主控、有NAND闪存、有固件、有坏块管理、有老化筛选流程。供应商一旦为了压价使用低等级颗粒、拆机料，或者选择稳定性较差的主控方案，短期内可能能把报价做下来，但最终风险会转移到渠道商和终端用户身上。这也是这次技术交流的核心：如果客户不做SSD研发，也不准备建设完整产线，只是想在中国采购阶段多一道质量把关，那么到底该选什么样的测试设备？一、先把需求讲清楚：这不是研发验证，而是采购端抽检一开始，我们先解释了巴西客户的实际场景。他们不是SSD工厂，也不是主控芯片公司，更不是企业级SSD研发中心。他们的需求很朴素：在深圳或国内其他供应链渠道采购消费类SSD时，不能只比较报价，还要有一个设备能把盘插进去，自动跑一段测试，最后告诉操作人员这批盘大概靠不靠谱。这和我们平时接触的研发级SSD测试完全不是一类需求。研发测试通常面向主控公司、企业级SSD厂商、数据中心SSD研发团队。比如PCIe SSD的研发验证，会涉及M.2、U.2、U.3、EDSFF等接口，关注协议、性能、功耗、异常处理、链路稳定性、掉盘恢复、固件行为等一整套复杂问题。这样的设备动辄几十万、上百万，甚至几百万人民币，适合研发部门长期使用。但巴西客户不是要做这些。他们要的是一个“够用、简单、便宜、能筛掉明显坏盘”的工具。这个判断非常关键。因为如果把研发级测试工具推荐给他们，技术上当然很强，但成本、学习门槛、使用复杂度都不匹配。反过来，如果只是把SSD插到一台普通电脑上，用软件跑一下，又很难形成批量抽测能力，也不适合普通操作人员长期执行。所以这次选型的方向很快明确下来：找一类偏产线、偏老化、偏批量抽检的SSD测试设备。二、接口先分类：客户主要关心SATA和M.2，PCIe/NVMe占比相对少接下来，双方开始拆解客户手里的SSD类型。根据之前和巴西质量团队沟通的信息，他们采购的消费类SSD里，M.2 SATA比较多，标准2.5英寸SATA也不少，M.2 PCIe/NVMe相对少一些。原因也容易理解：巴西这类消费级零售渠道，对价格非常敏感，SATA SSD虽然在研发端已经不算先进，但在低价消费市场仍然有大量需求。这也带来一个现实问题：我们平时做的高端研发测试设备，更多面向PCIe/NVMe SSD。SATA已经属于比较老的接口，在高端研发工具里反而不一定继续支持。但消费市场并没有完全切换到NVMe，尤其是低价SSD、老电脑升级盘、入门级渠道盘，SATA仍然存在大量出货。因此，设备选型不能只盯着最新协议，而要回到客户手里真实的盘型。供应商给出的第一个方案，是48口纯SATA测试机。这个设备面向2.5英寸标准SATA SSD，如果要测试M.2 SATA，可以额外使用M.2 SATA转2.5英寸SATA的转接板。这类转接板市场上非常常见，通常较容易解决。这个方案的优点很直接：价格经济、接口简单、适合SATA为主的批量抽测。对于只想测试2.5英寸SATA和M.2 SATA的客户来说，它是成本最低的选择。第二类方案，是SATA+PCIe二合一设备，有32口和64口两种配置。这类设备的设计比较有意思。每个测试位置并不是简单地分成“SATA区”和“PCIe区”，而是一个端口对应一组双接口：上面可以插M.2 PCIe/NVMe SSD，下面可以插SATA SSD。也就是说，客户可以根据实际盘型混插，不需要提前把设备严格分成两半。为什么32口和64口价格非常接近？供应商解释得比较直白：64口是在同一套系统资源基础上做更多端口拆分，能同时插更多盘，但共享带宽后，每个盘的测试速度会下降。32口方案端口少一些，但整体速度更高；64口方案端口多一些，更适合看重并发数量、不特别追求单盘速度的场景。这里需要特别强调：这类设备不是为了测试PCIe SSD的极限性能。它内部通过USB桥接和Hub架构连接多路SSD，即使M.2 PCIe端可以兼容PCIe 3.0/4.0盘，实际带宽也会受USB桥接和整机架构限制。换句话说，它适合做功能性读写校验、老化筛查，不适合拿来判断NVMe SSD真实性能。这个边界讲清楚，客户后面就不会误解。三、到底测什么：H2、Burn-in、RDT不是一回事设备方案聊清楚后，双方重点讨论了测试项目。这里出现了几个在SSD生产和检测里经常被混用的词：H2、老化测试、RDT、开卡、K1/K2/K3。这些词如果不解释清楚，客户很容易以为“只要插上去跑一跑”就是完整测试。实际上，不同阶段的测试目的完全不同。1. H2测试：整盘写一遍，再读一遍供应商首先提到的是H2测试。简单说，它就是把整个盘写一遍，再读一遍，验证写进去的数据和读出来的数据是否一致。这类测试最适合采购端抽检。因为客户不是工厂，也没有主控厂商提供的专用量产工具，更不可能重新参与SSD生产流程。他们只是想确认：这个盘容量是不是正常？全盘写读有没有明显错误？跑完一遍以后会不会马上报错、掉盘、数据不一致？对于巴西客户这类场景，H2测试其实非常合适。因为终端用户遇到的很多问题，比如用一会儿就数据丢失、盘不能识别、容量虚标或写入后读取异常，往往可以通过全盘写读校验先筛掉一部分。当然，H2不是万能的。它不能替代完整的研发验证，也不能保证盘长期可靠。但它能把很多明显不靠谱的盘挡在采购阶段。2. Burn-in老化：按时间循环读写，逼出潜在问题第二个测试是老化测试，也就是大家常说的Burn-in。老化测试不是只给SSD通电，而是在设定时间内持续进行读写循环。比如跑几个小时，持续写、读、再写、再读，通过压力运行把一些不稳定的问题提前暴露出来。这类测试在工厂端比较常见，尤其是在SSD完成开卡、坏块初步处理之后，通过老化测试进一步筛出不稳定块或潜在故障盘。测试时间通常会根据容量和工厂经验设定，例如几个小时、六小时、八小时等。对于巴西客户来说，如果只是采购端抽检，默认跑H2已经能满足基本筛选；但如果某个供应商价格很低、风险较高，或者某批次退货率曾经比较高，那么可以增加短时间老化测试，把风险再往前拦一层。3. RDT：不是普通客户能随便做的测试交流中还谈到了RDT。很多人听到RDT，以为它就是“通电老化”。其实从现场讨论看，RDT更接近工厂生产流程里的可靠性诊断环节。RDT通常需要主控厂商提供专用工具或专用程序。盘在第一次开卡后，内部会写入某些测试或自运行程序，设备给盘供电后，盘会自动扫描NAND中的坏块或异常区域。扫描结束后，再通过主控厂商的量产工具重新开卡，把识别出来的问题区域屏蔽掉。所以RDT不是采购端简单买一台设备就能完整执行的。它依赖主控方案、量产软件、固件流程，属于工厂生产和量产环节的一部分。巴西客户作为采购和质量抽检方，原则上不适合去做RDT，也没有必要去做RDT。这点很重要。因为客户真正需要的是“来料抽检”和“供应商筛选”，不是把供应商工厂的生产流程重新做一遍。四、顺着工厂流程，把K1、K2、K3讲明白这次交流里，还有一个很有价值的部分，就是把消费类SSD工厂常说的K1、K2、K3顺了一遍。这些词听起来很土，也很像内部黑话，但在很多SSD小厂、模组厂、产线环境里确实经常出现。它们本质上和“开卡”有关。所谓“开卡”，可以简单理解为：SSD的PCB贴好主控、NAND、电容、电阻等器件之后，这块板子还不能直接当成一个正常硬盘使用。必须通过主控厂商提供的量产工具，对它进行初始化、配置、识别NAND、建立映射关系、处理坏块信息，让电脑能够正常识别它。这一步在行业里常被叫作“开卡”。按照这次交流里的说法，K1、K2、K3大致可以这样理解：K1，是第一次开卡。SSD半成品贴片完成后，先通过主控厂商工具进行第一次初始化，让这块盘能进入后续测试流程。同时，可能会写入一些后续RDT阶段需要用到的测试程序或自运行文件。K1之后，进入RDT。这个阶段主要是通电扫描，让盘自身或主控方案中的测试机制去识别NAND里的坏块和异常区域。RDT本身未必有非常直观的红绿灯结果，更多是工厂按经验和流程去执行。RDT完成后，再进行第二次开卡，这一步就被称为K2。K2的目的，是根据前面RDT发现的问题，把坏块或不可用区域屏蔽掉，让系统后续看不到这些有问题的区域。K2之后，再进行Burn-in老化测试。这个阶段会持续进行读写循环，进一步暴露那些在初期扫描中没有出现、但在压力读写下可能变得不稳定的区域。老化完成后，再进行第三次开卡，也就是K3。K3会把老化过程中发现的新问题再次屏蔽掉。完成之后，这块SSD才更接近可出货状态。这套流程听起来并不复杂，但对消费类SSD质量非常关键。尤其是那些使用低等级颗粒、拆机料或者边角料颗粒的小厂，如果省略或压缩这些流程，短期看成本降下来了，长期看风险一定会转嫁给终端用户。从这个角度看，巴西客户遇到的高退货率，并不是偶然。五、设备的核心价值：不是“高级”，而是普通人能用把测试原理聊清楚后，双方又回到设备本身。这类硬盘老化测试机最大的卖点，不是测试项目多复杂，而是操作足够简单。设备内部可以理解为一套集成好的测试主机和控制系统。供应商介绍，设备自带显示器、键盘、鼠标，软件已经固化在系统里。客户拿到设备后，通电开机即可使用，不需要另外准备电脑。日常使用时，管理员可以先在设置界面选择测试模式，比如H2测试或Burn-in老化测试。如果选择H2，通常不需要再设置复杂参数；盘插进去后，设备会自动进行整盘写入和读取校验。测试完成后，前面板或界面上会通过红绿灯状态告诉操作人员结果：绿灯代表通过，红灯代表失败。这对巴西客户非常重要。因为他们不是要招聘一批SSD测试工程师，也不是要培训操作人员理解PCIe、NAND、固件和坏块管理。他们要的是一个放在采购仓库或质量抽检岗位上的工具，操作工只要会插盘、会看灯、会把合格品和不合格品分开放，就能把流程跑起来。这也是供应商自己强调的优势：设备要做到“傻瓜式”。说得再直白一点，就是普通工人不需要懂SSD，只要会看红绿灯。对于采购型客户来说，这种价值有时比“参数很漂亮”更重要。六、如果发到巴西，还要考虑语言、包装和售后由于终端客户在巴西，设备可能会被放在国内采购点使用，也可能直接发往巴西质量团队使用，所以后面又专门讨论了出口和售后问题。首先是重量。供应商反馈，设备大约30公斤。这个重量对于国际物流来说还可以接受，不属于特别难处理的大型设备。其次是包装。由于这类设备内部本质上有电脑主机、板卡、线缆、固定结构，如果运输中震动过大，即使外包装没有明显破损，内部内存条、主板连接器、线束或固定件也可能松动。这个风险在系统级测试设备跨国运输中并不少见。供应商表示，他们已经有多次发海外的经验，也有专门包装方案，必要时可以打木架加固，目前没有出现过运输后内部松动导致无法开机的问题。第三是语言。设备界面支持中文和英文切换，这对巴西客户非常关键。毕竟质量团队未必懂中文，如果界面只能中文显示，后续沟通和操作都会变得麻烦。第四是文档。现场特别强调，希望供应商提供文字版中文资料，同时需要把资料翻译成英文给巴西质量团队审核。客户需要看到功能描述、操作步骤、接口支持、测试流程、注意事项等内容，然后才能判断是否满足采购需求。售后方面，供应商确认保修期为一年。考虑到设备操作简单，正常情况下不需要复杂培训，只要前期文档和远程沟通做清楚即可。七、从一台设备延伸到更多产线测试需求这次交流虽然围绕巴西客户展开，但后面也聊到了更大的市场背景。我们过去主要做研发级测试工具，客户集中在有研发能力的SSD厂商、主控芯片公司、企业级存储团队和高速接口研发团队。研发工具金额高、技术深、客户使用要求细，但数量通常不会太多。产线测试设备则完全不同。它更看重成本、端口数、操作效率和维护简单性。消费类SSD工厂可能每天要测大量盘，每端口成本必须压低，设备市场竞争也更加激烈。几年前我们也接触过硬盘拷贝机、老化柜、产线测试机这类需求，但因为价格竞争激烈、利润空间有限，所以没有作为主要业务方向。不过现在情况有一点变化。一方面，很多研发型客户开始向生产环节延伸。研发部门在定义产品测试流程时，也会参与产线工具选型，尤其是一些企业级SSD、海外代工、第三方工厂生产的项目。另一方面，中国SSD产业链在向海外转移部分制造能力，例如泰国、马来西亚、墨西哥等地的合同制造场景，也会带来新的产线测试设备需求。Saniffer也推荐这方面的海外代工的资源给各个SSD厂家，这些代工资源都是帮助国际大厂，包括SpaceX这类用户使用的SSD代工。因此，这类设备虽然不是我们的主线业务，但可以作为研发测试工具之外的补充方案。当客户从研发部门问到产线测试、RDT、Burn-in、硬盘拷贝、批量检测时，我们至少要能判断哪些需求适合高端研发工具，哪些需求适合这类低成本产线设备。供应商也介绍了他们的其他产品，包括硬盘拷贝机、UFS相关设备、TF卡测试、NVMe/SATA双协议老化测试柜等。对于硬盘拷贝机，典型应用是一拖多复制系统镜像，比如一个母盘带多个目标盘自动拷贝，适合批量装机或出厂镜像写入，例如1拖16盘。但也要看到边界。比如UFS 5.0这类最新高速接口，真正要做到研发级速度和协议能力，并不是简单说“有钱就能做”。它依赖芯片平台、参考设计、控制器、主机端生态，很多最新平台并不容易买到。所以产线设备和前沿研发设备之间，仍然有明显分工。八、大端口设备怎么做：本质是多套系统堆叠后面双方还讨论了256口、384口这类更大端口数设备的实现方式。供应商解释，大容量机型并不是一台电脑无限扩展几百个端口，而是多套系统堆叠。例如256口可以理解为四套64口系统组合在一个柜体里。每套系统负责自己的端口，前端通过显示切换或物理按键查看不同区域状态。这种架构比较符合实际。因为一台主机的USB、Hub、桥接芯片、控制能力和带宽都是有限的。如果单纯追求端口数，把所有盘都挂到一套系统上，最终速度和稳定性都会受影响。设备内部大致可以理解为两部分：一部分是x86系统，用于运行测试和数据处理；另一部分是ARM控制系统，用于设备控制和状态管理。前端的SATA或PCIe/M.2接口，通过桥接芯片、USB Hub等方式接入系统。这也解释了为什么32口和64口设备虽然价格相同，但测试速度不同。32口相对更适合对单盘速度有一定要求的场景；64口更适合批量抽检，牺牲一些速度换取更多并发端口。对巴西客户来说，如果他们只是从多家供应商中抽样筛选，64口方案未必没有价值。因为他们不是要测极限性能，而是要在可接受时间内筛出明显问题盘。但如果客户更在意每轮测试时间，32口方案会更稳妥。九、日志和追溯：消费类抽检可以，企业级MES还不够最后还聊到一个容易被忽略的问题：测试日志和产品追溯。供应商表示，设备可以生成日志，记录测试时间、端口、速度等信息。但它并不读取或绑定SSD序列号，因此没有办法做到每一块盘和测试记录一一对应。这对消费类小厂抽检影响不大。操作人员看到红灯，把盘拔下来放到不合格区；看到绿灯，就进入后续包装或入库流程。这种模式足够简单，也符合低成本消费类场景。但如果是企业级SSD，情况就完全不同。企业级盘通常需要MES系统追溯，每块盘的序列号、测试项目、测试时间、测试工位、固件版本、批次、工厂、产线、甚至某个机台的日志，都要能关联起来。这样当某块盘在数据中心运行一年后出问题，厂商才能一路追溯到生产和测试环节。所以，这类设备适合消费类SSD批量抽检，不适合直接作为企业级SSD完整MES追溯测试平台。这个边界必须提前讲清楚。十、这次选型的初步结论综合这次交流，如果巴西客户的核心需求是采购端质量把关，而不是研发验证，那么这类SSD老化测试机是一个比较匹配的方向。如果客户确认只测SATA和M.2 SATA，48口纯SATA设备加M.2 SATA转接板，是成本最低的方案。它适合预算较低、SATA盘占绝大多数的场景。如果客户希望兼容M.2 PCIe/NVMe，同时也要覆盖SATA，那么32口或64口SATA+PCIe二合一设备更合适。32口更偏速度和稳定余量，64口更偏并发数量和批量抽检效率。测试策略上，建议默认使用H2整盘写读校验。对于新供应商、低价供应商、历史退货率较高的供应商，可以增加一定时间的Burn-in老化测试。这样既不会把流程搞得太复杂，又能在采购阶段多挡掉一部分高风险产品。至于RDT、K1/K2/K3这些更靠近工厂生产流程的环节，不建议巴西客户直接介入。他们更应该做的是：要求供应商提供明确的出厂测试流程，同时自己用H2和必要的老化抽检做二次筛选。从这次交流看，这个方案的价值不在于“高端”，而在于“落地”。对于一个在海外商超销售消费类SSD的客户来说，真正需要的不是一套复杂的研发实验室，而是一道简单、可执行、能长期坚持的质量门槛。很多时候，消费类SSD出问题，并不是因为市场不知道什么叫测试，而是因为采购链条里没有人愿意为测试留出成本。等到退货率起来、用户数据丢失、品牌信誉受损，再回头补这道工序，其实已经有些晚了。所以，这次设备选型背后真正值得关注的，不只是选48口还是64口，也不是H2还是Burn-in，而是一个更基础的问题：当SSD价格被压到极限以后，谁来为质量负责？如果采购端只看报价，最终买单的一定是用户；如果渠道商愿意在出货前加一道抽检，哪怕只是最基础的全盘写读测试，也可能把很多风险提前挡住。对消费类SSD来说，这也许不是最先进的测试方案，但可能是最现实、最有效的一步。更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

我们最近刚拿到Broadcom PCIe 6.0 retimer 板，该板为2个MCIO x8 in, 2个MICO x8 out，感兴趣的可以可以参考我们之前写的文章：【专题】全球最全面的 PCIe 6.0/CXL 3.0 测试工具方案探讨汇总一文里面的：4.2 PCIe 6.0 Retimer 重定时中继卡，里面有详细的内部结构核图片，我们今天演示的用外壳封起来的该卡。 感兴趣的可以看下面视频演示，没有时间的可以参考下面的文字总结，核心围绕 “Gen6 Switch 单板回环 → 串入 Gen6 Retimer → showport 确认 Gen6 x16” 这条演示主线展开，本次演示分两个环境：一个是单 Switch MCIO 口回环，另一个是用四根线把 Retimer 串在中间再验证 Gen6 链路；同时也记录了红灯/蓝灯指示、Tera Term 管理、showport 结果、Retimer 的 clockselect/conrst 等关键操作。 为了方便工程师观看，我们针对本期视频并处理添加了中文字幕供大家参考。如果想看高清视频建议要在电脑上打开上面的视频链接进行观看！创作不易，欢迎分享到朋友圈或者与朋友讨论！如果想搬运我们的视频请联系我们。 PCIe 6.0 不是插上线就完事：一次 Gen6 Switch + Retimer 回环测试，看懂高速链路到底怎么验证 很多工程师第一次接触 PCIe 6.0 测试环境时，心里都会有一个很朴素的问题： 线插上了，灯也亮了，那是不是就说明链路已经没问题了？ 答案当然没这么简单。 到了 PCIe Gen6 这个速度等级，事情已经不再是“能点亮”那么简单了。你看到一根 MCIO 线缆、一张 Switch 卡、一个 Retimer 小盒子，好像都是普通硬件；但在 64GT/s 的高速链路下面，它们每一个连接器、每一段走线、每一根 cable、每一个 lane 的顺序，都可能影响最终能不能稳定建链。 今天这段演示，表面上看只是一个很简单的回环测试： 先把 Gen6 Switch 的 MCIO 口左右回环，看它能不能跑到 Gen6 x16； 再把一张 Gen6 Retimer 卡串到中间，看经过 Retimer 以后，链路还能不能稳定跑到 Gen6 x16。 但这件事背后，其实非常适合拿来给刚入门的工程师讲清楚三个问题： 第一，PCIe Gen6 Switch 的 MCIO 口到底怎么测？ 第二，Retimer 串在链路中间到底起什么作用？ 第三，为什么高速 PCIe 测试不能只看“灯亮”，还要进管理口看 showport？ 这篇文章就按照现场演示的步骤，把这件事讲清楚。 一、先把场景说清楚：这不是普通“插线测试”，而是 Gen6 链路验证 这次演示使用的是一张新款 Gen6 Switch 卡。 这张卡上带有多个 MCIO 接口。MCIO 是现在高速 PCIe 连接里非常常见的一种小型高速连接器，尤其是在 PCIe Gen5、Gen6 服务器、SSD、Switch、GPU 扩展和测试平台中，经常会看到它。 如果用一个形象的比喻： PCIe Switch 像一个高速立交桥。 MCIO 接口就是立交桥上的匝道。 线缆就是匝道之间的高速路。 Retimer 则像高速路中间的信号再生站。 在低速时代，线稍微长一点、连接器损耗大一点，系统可能还能勉强跑起来。 但到了 PCIe Gen6，链路信号已经非常敏感。信号从 A 点跑到 B 点，途中经过连接器、PCB 走线、线缆、转接板，每经过一段都会有损耗、反射、串扰和抖动。 所以工程师做 Gen6 测试，不是为了证明“线能插上”，而是为了证明： 插上以后能不能 link； link 以后是不是 Gen6； 是不是 x16； 加了 Retimer 以后还能不能稳定； 链路状态在管理软件里是否能真实确认。 这才是这段演示真正有价值的地方。 二、第一个测试环境：单 Switch MCIO 口回环 演示一开始，先做的是比较基础的环境：单 Switch 的 MCIO 口回环。 简单说，就是不用外部设备，也不用 endpoint，只把 Switch 卡上的 MCIO 口用线缆“自己接回自己”。 这听起来有点像自己和自己打电话，但在 PCIe 测试里，这种 loopback 很有用。 它可以帮助工程师先排除很多变量： Switch 本身端口是否正常； MCIO 连接器是否正常； 线缆是否支持目标速率； lane 顺序是否对应正确； 端口之间能不能形成预期链路； 管理软件能不能正确读到链路状态。 这一步相当于高速测试里的“先检查路有没有通”。 演示里使用两根线，从 Switch 左边接到右边。这里特别提醒了一点：对应的 lane 顺序要注意。 这句话对新工程师非常重要。 因为高速 PCIe 不是普通电源线，不是正负极接上就行。PCIe 有 lane，每个 lane 里面有 TX/RX 差分对，x8、x16 又由多条 lane 组合起来。如果 lane 顺序、方向或者连接关系不对，轻则降速降宽，重则根本 link 不起来。 所以单 Switch 回环测试的第一条经验就是： 线缆不是“随便接通”就可以，而是要按正确 lane mapping 接。 三、新款 Switch 卡有哪些变化？ 演示中也顺手介绍了这张新款 Switch 卡和老款相比的一些变化。我们后续看时间允许也会再专门拍摄一下两张新Gen6 switch互联，以及和CX-8连接的视频。 第一，硬件尺寸有轻微变化。 新卡比老款稍微长一点。如果之前没有接触过老款，这个差异其实不需要特别在意；但对于已经有旧测试架、旧机箱、旧固定结构的客户来说，尺寸变化还是值得提前确认。 第二，左侧接口布局调整了。 原来两个 MCIO 口和下面两个 Type-C 管理口的位置，现在做了调换。也就是说，新卡的接口排布更改过。 第三，MCU 管理口位置调整。 之前 MCU 管理口放在上面的 Type-C 口，现在移到了下面。对于现场调试人员来说，这种变化很实际，因为你插管理线的时候，不能再按老习惯找口。 第四，新卡功耗更小。 演示中提到，在空载状态下，这张新卡可以通过 PCIe 插槽取电。也就是说，如果只是像演示这样没有挂很多设备、没有大功率负载，可以不接外部供电。 但这里有一个非常重要的工程建议： 如果平时研发测试要接多个 device，或者要挂一些功耗比较大的设备，还是建议把外接供电口一直接上。 这不是多此一举，而是工程现场的经验。 因为研发测试最怕的不是“理论上能工作”，而是现场反复插拔、换设备、加负载以后，供电状态变得不可控。外接供电提前接好，至少可以减少一个不必要的变量。 高速链路调试本来就已经够麻烦了，不要让供电再来添乱。 四、看灯不是玄学：红灯和蓝灯分别代表什么？ 上电以后，演示里看到一开始有四个红灯在闪烁。 很多人看硬件板卡，容易把灯当成“玄学信号”：亮了就高兴，灭了就紧张。其实每个灯都有明确含义。 这张 Switch 卡上，红灯代表对应 MCIO 口没有 link。 也就是说，如果某个接口旁边有红灯，说明这个接口当前没有建立 PCIe 链路，处于空载或者未连接状态。 如果这个口成功 link，红灯就会消失。 蓝灯则表示当前的建链状态。 演示里提到，如果蓝灯稳定不变，就表示当前已经稳定在 Gen6 速率。 所以在现场调试时，可以先用灯做第一层判断： 红灯还在，说明对应端口没 link； 红灯消失，说明端口开始进入有效连接状态； 蓝灯常亮，说明链路稳定在 Gen6。 但这里也要强调一句： 灯只能做快速观察，不能作为最终验收。 真正确认链路状态，还要进管理软件看端口信息。 五、进入 Tera Term，用 showport 看真实链路状态 演示中使用 Tera Term 作为管理软件，通过管理口进入 Switch 的管理界面，然后执行 showport 查看端口状态。 这一步非常关键。 因为硬件灯只能告诉你“大概连上了没有”，但 showport 可以告诉你更具体的信息： 当前端口速率是多少； 当前端口宽度是多少； 哪些端口是 Gen6； 哪些端口是 Gen5； upstream 在哪里； downstream 或 loopback 端口状态如何。 在第一个单 Switch 回环环境里，showport 结果显示 MCIO 回环相关链路已经是 Gen6 x16。 这说明什么？ 说明两根 MCIO x8 线缆组合起来以后，形成了一个 x16 宽度的 Gen6 链路。 也就是说，单 Switch 自回环环境下，MCIO 口、线缆、lane mapping、Switch 端口状态都达到了预期。 与此同时，showport 里还看到 upstream 是 Gen5 x16。 这个地方也很适合给初级工程师解释一下。 为什么同一张卡上，有的地方是 Gen6 x16，有的地方是 Gen5 x16？ 原因很简单：upstream 是连接 host 的那一侧，也就是通过金手指插到主机上的那一侧。如果当前主机平台本身只支持 Gen5，那么 upstream 显示 Gen5 x16 就是正常现象。 这不是 Switch 不能跑 Gen6，也不是 MCIO 回环失败，而是 host 这一侧的能力决定了 upstream 只能到 Gen5。 工程调试里，这种判断非常重要。 不能看到一个 Gen5 就马上说“板卡不支持 Gen6”。 要先看清楚这是哪一侧端口、连接了什么设备、对端能力是多少。 六、第二个测试环境：把 Gen6 Retimer 串到链路中间 完成单 Switch 回环以后，演示进入第二个环境：Switch + Gen6 Retimer。 这一次，线缆连接方式变了。 前面单 Switch 回环时，只用了两根线，直接从 Switch 左边回到右边。 现在把线缆改成四根：其中两根接到 Retimer 盒子的左侧，另外两根接到 Retimer 盒子的右侧。 也就是说，原来是： Switch 左侧 → 线缆 → Switch 右侧 现在变成： Switch 左侧 → 线缆 → Retimer → 线缆 → Switch 右侧 Retimer 被串到了链路中间。 这一步的目的很明确： 验证当 Gen6 Retimer 插在中间以后，Switch 左右两边回环是否仍然可以稳定跑到 Gen6。 这比单纯 Switch 回环更接近真实工程环境。 因为在真实 PCIe Gen6 系统里，链路往往不会只有一块板和一根短线。它可能经过： 主板走线； 连接器； 线缆； 转接板； Retimer； Switch； endpoint； 测试夹具； 协议分析仪插入点。 每多一个中间环节，就多一个可能影响链路的因素。 Retimer 的作用，就是在高速链路中间对信号进行恢复、重定时、再驱动。它不是简单的被动转接线，而是主动参与链路质量改善的器件。 用一个形象的比喻： PCIe 信号像一队高速奔跑的运动员。 跑得太远以后，队形会散，节奏会乱。 Retimer 像中途补给站，不只是给运动员递水，而是重新整理队形、重新校准节奏，让队伍继续按正确节拍跑下去。 所以 Retimer 对 PCIe Gen5/Gen6 长距离连接、复杂拓扑、线缆扩展非常重要。 七、这个“黑砖头”一样的 Gen6 Retimer 到底是什么？ 演示里这个 Gen6 Retimer 外观看起来像一个黑色小盒子，甚至有点像一块砖。 但它不是普通盒子，里面其实是一张 Gen6 Retimer 转板。外面之所以包起来，是因为做了风扇散热设计。 这也说明一个事实： 到了 PCIe Gen6，Retimer 不是一个可以随便裸放、随便忽略散热的小器件。 它本身也是高速芯片，有功耗，有热量，也需要稳定供电和风扇散热。 演示中提到，这张 Retimer 卡基于 Broadcom 的 Gen6 Retimer 芯片。 盒子上主要有几个接口： 一个 12V 供电口； 一个 Type-C MCU 管理口； 一个 I2C 串口； 左右两侧的 MCIO Gen6 x8 接口。 其中，12V 供电口和 MCU 管理口是日常比较常用的。 I2C 串口一般不太常用，更像是研发调试时使用。 Retimer 的 MCU 管理命令也不复杂。演示里提到，比较常用的主要是两个： 一个是 clockselect，用来修改 clock 模式，比如 CC 或 SRNS； 另一个是 conrst，用来做 reset。 其他命令比如升级、系统信息、风扇调节等，在普通演示和常规测试里不一定高频使用。 这也说明，Retimer 并不是一个完全“黑盒”的东西。真正做测试时，工程师有时候需要进入它的管理界面，确认它的 clock 模式、复位状态、工作状态是否符合当前拓扑要求。 八、CC 和 SRNS 是什么？为什么 Retimer 要改 clock 模式？ 这里稍微补充一点背景，让没接触过 PCIe 时钟架构的工程师也能理解。 PCIe 链路除了有数据线，还要有时钟体系。不同系统里，设备之间的参考时钟关系可能不同。 CC 通常可以理解为 Common Clock，也就是链路两端使用共同参考时钟。 SRNS 可以理解为 Separate Reference Clock No Spread，也就是链路两端使用独立参考时钟，并且没有 SSC 展频。 不同拓扑、不同设备、不同测试环境，对时钟模式的要求可能不同。 如果 clock 模式配置不对，链路可能表现为： 不 link； 只能降速； 偶发掉线； 训练不稳定； Retimer 两侧状态不一致。 所以 Retimer 管理命令里保留 clockselect 很重要。 它让工程师可以根据当前环境，把 Retimer 切到正确时钟模式。 这也是高速测试和普通低速接口测试最大的差别之一： 很多时候，问题不是线没插好，而是时钟架构、链路训练、equalization、Retimer 配置没有匹配。 九、上电顺序：先 Switch，再 Retimer 第二个环境中，演示也强调了上电顺序。 先给 Switch 上电。 再给 Retimer 上电。 这看起来是个小细节，但在实际调试里很有用。 高速 PCIe 系统里，很多问题都发生在上电、复位、链路训练的早期阶段。如果某个设备还没准备好，另一个设备已经开始训练链路，就可能出现链路状态异常。 演示中也提到，新款 Switch 卡空载时可以通过 PCIe 插槽供电；如果平常接多个 device 测试，建议外接供电口也一直接着。它会自己判断使用哪种供电方式，不会产生电流冲突。 这个设计对实验室很友好。 因为工程师不需要每次根据测试环境反复插拔供电线，只要按照推荐方式把外接供电接好，就可以减少现场不确定性。 对于客户现场演示、研发验证、反复换设备的环境来说，这种细节很重要。 十、Retimer 串入以后，灯的状态发生了什么？ 上电以后，演示中观察到一个明显变化： 刚刚左边和右边有四个红灯，表示这些接口没有 link； 上电并完成连接后，红灯都没有了； 取而代之的是两个蓝灯； 蓝灯常亮，说明链路稳定在 Gen6 速率。 这一步其实已经给出一个初步判断： Retimer 串入以后，链路不是断的。 Switch 左右两侧通过 Retimer 能够形成有效连接。 从硬件指示灯看，Gen6 链路状态是 OK 的。 但还是那句话：灯只是第一层判断。 下一步必须进入管理口，继续看 showport。 十一、再次 showport：确认 Gen6 x16，没有问题 演示最后，通过 Type-C 管理口连接到新款 Switch 卡。这里也提醒了一下：新卡的管理口位置放到下面了。 进入管理界面后，执行 showport。 结果显示：Gen6 x16，没有问题。 这就是整个演示的最终结论。 也就是说： 单 Switch MCIO 回环，可以跑到 Gen6 x16； Switch + Gen6 Retimer 串联回环，也可以跑到 Gen6 x16； Retimer 串在中间以后，没有把链路拖垮； MCIO 线缆、Retimer、Switch 端口组合起来，能够完成 Gen6 x16 建链。 对客户来说，这个结果非常直观。 因为很多客户真正关心的不是某颗芯片 datasheet 写了什么，也不是宣传材料说“支持 Gen6”。他们更关心： 线接上以后，实际能不能跑？ Retimer 串进去以后，实际能不能跑？ 管理软件里能不能看到 Gen6 x16？ 现场工程师能不能复现这个结果？ 这次演示回答的就是这些问题。 十二、为什么这个演示对 PCIe 6.0 测试很有代表性？ 这段视频虽然时间不长，但它覆盖了 PCIe Gen6 测试里很典型的几个关键动作。 第一，先做单板回环。 这是把问题简化到最小，先确认 Switch 和 MCIO 口本身是否工作正常。 第二，再加入 Retimer。 这是在基础链路跑通以后，逐步增加复杂度，验证中间主动器件是否影响链路。 第三，看灯，但不只看灯。 红灯、蓝灯可以帮助快速判断端口状态，但最终还是要通过 showport 确认速率和宽度。 第四，注意供电。 空载可以用 PCIe 插槽供电，但真实研发测试建议接外部供电，尤其是接多个 device 或高功耗设备时。 第五，注意管理口。 Switch 有管理口，Retimer 也有管理口。高速测试不是纯硬件插拔，有时候必须进入管理界面修改 clock、reset、查看端口状态。 第六，注意 lane 顺序。 MCIO 回环不是随便两根线接上就行，lane mapping 必须正确。 这些动作看起来很基础，但它们恰恰是高速接口测试的基本功。 十三、给初级工程师的一点现场经验：Gen6 调试不要急着下结论 如果一个刚入门的工程师在现场遇到 PCIe Gen6 link 不起来，很容易马上怀疑： 是不是 Switch 坏了？ 是不是 Retimer 坏了？ 是不是线缆不行？ 是不是板子设计有问题？ 但成熟的调试思路不是这样。 更合理的顺序应该是： 先确认供电。 再确认线缆方向和 lane mapping。 再看红灯是否表示 no link。 再看蓝灯是否稳定。 再进 Switch 管理口看 showport。 再确认 upstream 和 downstream 各自速率。 再确认 host 本身支持 Gen几。 再确认 Retimer clock 模式。 必要时做 Retimer reset。 最后再判断是否需要更换线缆、端口、板卡或设备。 尤其要记住一点： 看到 Gen5 不一定是失败。 要看它出现在哪个端口上。 如果 upstream 连接的是 Gen5 host，那 upstream 显示 Gen5 x16 是正常的。 如果 MCIO 回环目标是 Gen6，而 showport 显示 Gen6 x16，那说明回环链路已经达到预期。 如果某个端口应该 Gen6 x16，却只显示 Gen5 或 x8，那才需要继续排查。 高速 PCIe 测试最怕“一眼看错”。 因为一个错误判断，可能让工程师在错误方向上浪费一整天。 十四、这套 Switch + Retimer 环境能用于哪些测试？ 这套环境不只是为了演示好看，它在实际研发中很有价值。 它可以用于： Gen6 MCIO 线缆验证； Gen6 Switch 端口验证； Gen6 Retimer 功能验证； Switch + Retimer 串联拓扑测试； x8/x16 lane 组合验证； 不同 clock 模式下的链路训练测试； host 为 Gen5、downstream 为 Gen6 的混合代际测试； 后续连接 Gen6 SSD、GPU、NIC、DPU、endpoint EVB 的前置验证。 尤其是对于做 PCIe 6.0 设备研发的团队来说，这类平台非常关键。 因为客户经常不是单独测一张卡，而是要测完整系统： 主机到 Switch； Switch 到 Retimer； Retimer 到 endpoint； endpoint 再返回数据； 中间还可能插协议分析仪、故障注入设备、不同长度线缆、不同转接板。 如果没有一个可控的 Switch + Retimer 测试环境，很多问题只能在整机里碰运气。 而一旦进了整机，变量太多： BIOS 变量； 主板变量； 线缆变量； 散热变量； 供电变量； endpoint 变量； 驱动变量； 操作系统变量。 最后很可能看到的只是“系统不稳定”，却不知道到底哪里不稳定。 这就是测试平台的意义： 把复杂系统拆开，一段一段验证。 先确认 Switch。 再确认 Retimer。 再确认线缆。 再确认 endpoint。 最后再做系统集成。 十五、结语：PCIe Gen6 的门槛，不是“能插上”，而是“能证明” PCIe Gen6 时代，测试工程师要习惯一个事实： 看起来很简单的一根线，背后可能是 64GT/s 的信号完整性问题。 看起来很普通的一个小盒子，里面可能是一颗高速 Retimer 芯片。 看起来只是两个蓝灯常亮，背后其实是 link training、clock mode、lane mapping、equalization、供电和管理配置共同完成的结果。 这次演示最有价值的地方，不是它展示了一堆复杂设备，而是它把一个正确的调试流程讲清楚了： 先做单 Switch 回环； 确认 MCIO 口能到 Gen6 x16； 再把 Retimer 串到中间； 确认经过 Retimer 后仍然能到 Gen6 x16； 最后通过管理口和 showport 给出软件层面的证据。 这才是高速接口验证应该有的样子。 不是靠猜。 不是靠灯。 不是靠宣传页。 而是靠真实连接、真实上电、真实链路、真实 showport 结果。 对于刚接触 PCIe Gen6 的工程师来说，这样的演示很值得反复看。 因为它告诉我们： PCIe 6.0 测试从来不是“插上线，看亮灯”这么简单。 真正的测试，是一步一步把链路里的每个环节都验证清楚。 只有这样，当未来客户把 Gen6 SSD、GPU、NIC、DPU 或自研 endpoint 接上来时，我们才知道问题该从哪里查，也知道结果该怎么证明。 ------------------------------------------------------------------------------- 更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。 欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。  

很多人谈 NAND Flash 测试，第一反应是 SSD 性能：顺序读写、随机读写、IOPS、延迟、带宽。这是个误区，一定要注意NAND Flash 不等于SSD，NAND Flash这是我们平时经常用的SSD的最核心的存储器件。但真正做到芯片级、颗粒级，尤其是把 NAND 用到一些非传统场景里，问题就会变得很不一样。我们最近一次针对NAND Flash测试的技术交流的背景，是一家做存算（CIM/IMC - compute in memory，也叫In-memoy compute）相关产品的用户，在设计过程中发现一个现实问题：系统内部某些NAND存储位置的温度，可能会比原先预估的规格高不少。正常情况下，供应商不会轻易承诺 NAND 颗粒可以长期工作在超过规格的高温环境里；但项目又不能停在“理论上可能有风险”这里。因此，用户希望找一种办法，用少量 NAND 样品先做一次高温下的实际验证。这个需求听起来简单：把 NAND 放到高温下，看看还能不能读写。但真要做起来，里面涉及样品来源、封装兼容、测试温度、测试动作、数据记录、报告形式、测试服务模式、设备是否值得采购等一串问题。两段沟通正是围绕这些问题展开的。一、问题从“少量NAND颗粒能不能测”开始交流一开始，用户的需求还比较初步。用户想采购几颗 232 层左右的 TLC NAND 裸颗粒，数量不多，可能也就几颗到十几颗。目的不是做量产筛选，而是想看看这些 NAND 在高温条件下的一些基础特性，比如高温下的读写表现、Retention 行为，或者某些 Read Disturb 相关现象。这里有一个很现实的约束：用户大概率不会从原厂正式渠道采购大批量样品。因为只是做调研和验证，如果去找原厂买三五颗裸 NAND，原厂一般也不会配合。实际操作中，很可能要通过代理商、渠道商，甚至其他用户资源去找少量样品。这也决定了后面整个讨论的方向：用户并不是要立刻购买一套完整 NAND 特性分析设备，而是想先搞清楚，有没有办法以测试服务的形式，把少量样品测起来。二、NplusT Nanocycler：不是产线筛选机，而是NAND特性分析工具接着，交流转到 NplusT的 NAND 测试设备。这里提到的 NplusT是一家意大利公司，主要做 NAND Flash 测试相关设备，也可以提供测试服务。Saniffer 在国内代理和支持这类设备。NplusT的这类 NAND 测试设备，核心不是产线里那种“上板前测一下能不能用”的低成本筛选机。产线筛选关注的是速度和成本：一晚上测很多颗，只判断颗粒大体能不能贴片，测试项目相对简单。但用户现在要看的不是“这颗 NAND 能不能用”，而是“这颗 NAND 在高温、读写、擦写、干扰、保持等条件下的行为是什么”。这属于特性分析，而不是简单分选。因此，这类设备更适合高校、研究机构、SSD 主控公司、NAND 算法团队，以及需要了解第三方 NAND 颗粒真实行为的研发团队。比如做 LDPC、读重试、磨损管理、Retention 建模、Read Disturb 分析，或者 SSD 主控固件算法优化，都需要真正理解 NAND 颗粒的特性。三、设备形态：桌面小机台、多个独立测试槽、接触式加温交流过程中介绍了设备的大体结构。这类设备不是一个大型温箱，而是比较紧凑的桌面型测试机台，可以放在实验室台面上。标准配置可以包含多个Tester Unit测试模块，每个槽位相对独立控制；如果是多槽配置，中间也会做隔离，避免一个槽位加热影响另一个槽位。它的加温方式也和传统温箱不同。传统温箱是把整个空间升温，而这里更像是接触式加温。NAND 裸颗粒放入 socket 后，上方盖板压住芯片，盖板直接接触 NAND 封装，通过热传导把温度加到芯片上。设备还会监控温度，等温度稳定到设定值后，再执行 Program、Erase、Read、Read Disturb 等测试动作。这种接触式加温的好处是响应更直接，温控对象更贴近被测 NAND 本体。对于少量颗粒、高温快速验证来说，比搭一个大温箱更方便。我们在后续的交流过程中，温度能力进一步明确：设备标称可以支持到 125℃，实际硬件能力可以更高，提到过可到 145℃左右，但长期使用还是应以标称规格为准。用户关心的 95℃以上，甚至 120℃左右的短期测试，原则上落在这类设备可以讨论的范围内。四、样品封装是第一道门槛：BGA152、BGA132、BGA154不能混着看我们交流里很快碰到一个关键问题：NAND 裸颗粒的封装。这类测试设备不是随便拿一颗 NAND 放进去就能测。它需要 socket 与颗粒封装匹配。常见 NAND 封装包括 BGA152、BGA132、BGA154 等。不同厂商、不同代际、不同容量的 NAND，封装可能不同。交流过程中提到，一个 BGA152 socket 可以兼容 BGA132，方法是放置时左右各空一列，按定位点对齐。但 BGA154 与 BGA152/BGA132 并不一定兼容，往往需要另一种 socket 或测试模块。这就引出了后续必须确认的第一件事：用户到底要测哪一家 NAND、哪一代产品、哪一个具体 part number、什么封装形式。比如长江存储YMTC的 X2、X3、X4，不同型号、不同层数、不同容量，封装和 pinout 可能都不同。不能只说“我想测长存 NAND”，必须落实到具体料号。否则设备端无法确认 socket、FPGA 配置、协议支持和测试流程是否匹配。五、软件流程：不是写一堆底层代码，而是拖模块搭测试步骤设备介绍之后，交流转到软件操作。这套系统的软件并不是让工程师从零写底层 NAND 命令，而是提供很多功能模块。用户可以像搭流程一样，把温度控制、Program、Erase、Read、Read Disturb、降温等模块按顺序组合起来。比如一个典型流程可以这样设计：先把温度升到 95℃或 120℃； 等待温度稳定； 执行 Program； 执行 Read； 执行 Read Disturb； 再次 Read； 记录数据； 必要时降温； 最后导出结果。每个模块里都可以设置参数。比如测试哪些 block、哪些 page、读多少次、写入什么 pattern、循环多少轮、Read Disturb 次数是多少、温度设定是多少、每一步之间是否需要等待等。这对用户很重要，因为他们要的不是一个固定测试，而是希望能根据自己关心的问题灵活配置。比如他们可能只想测几个 block，也可能想全片扫一遍；可能想看 Program 后的立即读取，也可能想看高温下短时间放置后的变化；可能只做几百次读扰，也可能做十万次 Read Disturb。六、数据输出：CSV是基础，后处理要提前想清楚交流过程中反复提到，设备在测试过程中会产生大量数据，并且可以导出 CSV。这件事看起来平常，其实很关键。因为 NAND 特性测试不是最后给一个“Pass/Fail”就结束了。用户真正要看的是数据趋势：某个温度下读出来的 bit 是否稳定； Program 时间是否变化； Read Disturb 后错误数是否增加； 高温保持后阈值分布是否漂移； 不同 block、不同 page、不同 die 之间有没有差异； 某些 pattern 是否更容易出问题； 不同样品之间是否有离散性。因此，测试开始前就要想清楚：最终到底要哪些字段、哪些图、哪些统计结果、哪些中间数据。设备可以导 CSV，也有配套软件做后处理；但用户自己也可以用 Excel、Python 或内部分析工具二次处理。这也引出一个很实际的建议：不要只说“帮我测一下 Read Disturb”，而要明确测试后希望看到哪些指标。否则设备跑完后给出一大堆 CSV，用户再回头说“我真正想看的不是这些”，就会浪费测试时间。七、采购设备并不一定划算：少量样品更适合先做测试服务我们交流过程中，双方很快判断出：如果用户只是为了几颗 NAND 样品做一次短期验证，直接采购整套设备不一定划算。一套完整设备不便宜，而且不仅是买硬件，还涉及测试模块、socket、软件、脚本、人员培训和后处理流程。对于长期做 NAND 特性研究的高校、SSD 主控公司或算法团队，这类投入是值得的；但对于只是想先验证几颗颗粒在高温下表现的用户来说，测试服务更合理。因此，当时提出了几种可能路径。第一种，送到 NplusT意大利团队，由原厂帮忙做测试并出报告。 第二种，在 Saniffer 上海办公室使用现有设备做一次小批量测试，必要时让 NplusT工程师远程支持。 第三种，如果现有设备或 socket 不匹配，也可以看看国内已有设备的高校、研究机构或企业用户是否愿意协助做一次测试。 第四种，如果后续需求变成长期、持续、大批量，再考虑采购设备，甚至由 Saniffer 组建相应的测试服务能力。这个判断很务实：先用服务验证需求，再决定是否买设备。对于还处在调研阶段的项目，这是更稳妥的路径。八、为什么高校和SSD主控公司会用这类设备？交流过程中还延伸聊到这类设备的典型用户。高校方面，很多团队会研究 NAND 器件特性、错误模型、Retention、Read Disturb、Program/Erase 行为，以及基于这些特性的纠错算法。比如 LDPC 算法要做得好，就不能只凭规格书写参数，必须理解真实 NAND 在不同温度、不同磨损状态、不同读写条件下的统计行为。企业方面，SSD 主控公司也会用这类设备。主控厂商不一定自己生产 NAND，但它需要适配各种 NAND 供应商的颗粒。不同厂商、不同批次、不同代际的 NAND，读写延迟、错误分布、Retention 行为、Read Disturb 敏感性都不完全一样。主控固件、读重试策略、纠错算法、坏块管理策略，都需要基于这些特性不断优化。用户当前的情况与此类似：他们自己不生产 NAND，而是计划使用第三方 NAND。既然用的是第三方 NAND，就更需要了解它在自己系统场景里的行为，尤其是在温度条件可能超出常规设计预期时。九、交流后半段：样品采购本身也是难点我们交流的后半段还聊到一个很现实的问题：现在想买少量原装 NAND 裸颗粒，并不容易。几年前，找原厂或代理买几颗样品相对容易，甚至有时候打个招呼就能拿到。但现在很多高代际、高容量 NAND 颗粒变得很紧俏。少量采购很难谈，价格也高。有时渠道商手上有货，但要求一次拿走几十颗；如果只买几颗，对方未必愿意卖。更麻烦的是，市场上可能存在拆机料、重新植球料、来源不明的料。对于普通功能验证也许还能勉强用，但对于高温特性测试，这类料风险很大。因为你不知道它之前经历过什么温度、多少擦写、什么焊接条件、是否重新打磨、是否返修过。拿这种样品去做高温测试，最后很难判断问题到底来自 NAND 本身，还是来自样品来源和前处理过程。所以这里形成了一个重要共识：如果要做高温可靠性或特性验证，最好使用原装、未使用、来源可靠的 NAND 颗粒。否则测试结果的解释会非常麻烦。十、后续的交流把需求进一步讲清楚在后续的交流中用户把真实需求讲得更明确了。他们最近在做系统设计热仿真时发现，实际温度在某些情况下可能会比原先预计的规格高很多，可能超过 95℃。而NAND Flash供应商通常不会轻易承诺产品可以在这种高温下长期正常工作。所以用户希望先做一次探索性测试：在大于等于 95℃的环境下，看看 NAND 是否还能正常读写；进一步地，可能希望把温度推到 120℃以上，做短期的读、写、Read Disturb，或者类似短期高温保持的观察。这时候，需求已经从初期交流的“想看看高温特性和 Retention”收敛成了更具体的工程问题：温度：至少 95℃以上，可能到 120℃； 对象：第三方标准 NAND 裸颗粒，可能是长江存储YMTC等厂商； 测试：读、写、Program、Erase、Read Disturb，以及短期高温下的数据变化； 样品量：很少，属于短期验证，不是长期批量测试； 模式：更倾向测试服务，而不是马上采购设备。十一、设备能力再次确认：接触式加温、125℃标称、实际可到更高然后，我们再次确认了设备温度能力。设备通过接触式加温直接加热 NAND 封装，温控相对准确。标称支持到 125℃，实际硬件能力可以更高，提到过大约 145℃。但从工程角度，正式使用仍然建议按照标称规格来规划，尤其是长时间测试。用户想试 120℃左右，这在设备能力范围内是可以讨论的。需要注意的是，测试温度越高，对样品、socket、接触稳定性、测试时间和安全边界的要求越高，测试方案也要写得更清楚。十二、封装和料号再次成为前置条件同时，双方再次强调了封装问题。设备支持的是标准 NAND 协议和标准 NAND 封装。只要是标准 ONFI/Toggle 类 NAND、标准 BGA 封装，理论上可以通过合适 socket 和测试模块来做 Program、Erase、Read、Read Disturb 等动作。但如果是非标准接口、非标准封装、特殊 pinout，就会比较麻烦。因此，用户下一步必须先提供：具体 NAND 厂商； 具体料号； 容量、层数、代际； 封装类型，比如 BGA132、BGA152、BGA154； 是否为原装新料； 预计样品数量。这一步看似琐碎，其实是能不能开测的第一道门槛。没有料号和封装，设备端无法确认 socket 是否匹配；没有样品来源说明，也无法判断测试结果是否可信。十三、测试需求要写成文档：温度、次数、模式、输出结果都要明确本次交流过程中，给用户最明确的建议是：先把测试需求写成文档。这个文档至少要回答三个问题。第一个问题：测什么样品？ 也就是封装、料号、供应商、样品数量、来源是否可靠。第二个问题：怎么测？ 比如温度是 95℃、105℃、120℃，还是多个温度点；每个温度点稳定多久；Program/Erase 做几轮；Read Disturb 做多少次；读写 pattern 是什么；测试哪些 block/page；是否需要高温保持；是否需要降温后复读。第三个问题：要什么结果？ 是只要一个简单报告，还是要完整 CSV；要看哪些参数；是否需要图表；是否要统计 error count、fail bit、page/block 差异、Program time、Read retry、Retention 前后变化等。这一步非常关键。NAND 特性测试不是“把料放进去跑一下”这么简单。测试脚本可以灵活配置，但前提是用户知道自己要验证什么假设。否则测试动作做完了，数据也有了，后处理和结论却很难落地。十四、这不是传统可靠性线，而是一次极端条件下的快速特性摸底我们还区分了一个概念：这次测试不完全等同于传统可靠性测试。传统可靠性测试可能是标准流程、标准温度、标准时长、标准样本数，例如长时间 HTOL、Retention、Endurance 等。而用户这次更像是工程风险摸底：系统某些点可能出现高温，所以先找几颗第三方 NAND，在 95℃甚至 120℃做一次短期验证，看它能不能正常读写，是否出现明显异常。这类测试不一定能直接替代正式可靠性认证，也不能说明产品在所有工况下长期可靠。但它很适合在项目早期回答一个关键问题：这个方向有没有明显风险？如果一上 120℃就读写异常，那设计就要尽早调整；如果短期看起来还可以，后续再决定是否做更完整的可靠性验证。也正因为它是探索性验证，测试服务模式就比直接采购设备更合适。十五、现有设备状态：上海有设备，但要确认socket和可用模块经过确认，上海这边有设备资源，但实际可用状态还要确认。有一台设备可能已经发给无锡用户试用；另有一台设备可能还在上海办公室，但需要确认当前装的是什么 socket、什么测试模块、是否适配用户要测的 NAND 封装。这也再次说明，测试服务能不能很快启动，不只取决于设备本体，还取决于：当前设备是否空闲； socket 是否匹配； 测试模块是否支持目标料号； 脚本是否已有； NplusT是否需要远程支持； 样品是否已经准备好。如果这些都匹配，用户甚至可以把样品带到上海办公室做一次快速验证；如果不匹配，就要考虑更换 socket、找其他已有设备的用户协助，或者送到 NplusT原厂做。十六、下一步安排：先写需求，再拉NplusT意大利团队开Zoom会议最后，双方把下一步动作基本定下来。用户先准备一份需求文档，把样品形态、测试温度、测试动作、循环次数、数据需求写清楚。随后可以在下周一左右内部和内部经理确认，再看是否拉一个 Zoom 会议，把 NplusT意大利工程师也一起叫上，直接讨论可行性。这样做比较高效。因为如果只是口头说“我们想测高温”，NplusT工程师也很难给出准确方案。只有看到具体温度、封装、测试步骤、样品数量、数据输出要求，才能判断：现有设备能否直接做； 是否需要更换 socket； 是否需要定制脚本； 是否需要在上海测，还是送意大利测； 大概周期和费用如何； 最终报告能提供到什么程度。这也给用户内部决策提供了依据：是先做一次小额测试服务，还是后续把它变成持续测试能力。十七、关于样品：一定要尽量避免拆机料、重植球料最后又回到样品来源问题，而且比前面的除部交流更明确。如果要做高温测试，最好不要使用拆机料、重新植球料、来源不清楚的料。因为这类样品可能已经经历过焊接、返修、热冲击，甚至可能被重新打磨过。拿它做高温测试，一旦出问题，很难判断问题来自 NAND 本体、封装损伤、焊球质量，还是之前使用历史。对于这次用户想验证的东西来说，样品来源尤其重要。因为他们关心的是“正常第三方 NAND 在高温下是否还能满足需求”，而不是“某颗来路不明的拆机 NAND 在高温下会不会坏”。因此，样品准备应尽量走可靠渠道。如果买不到少量原装裸颗粒，也可以考虑通过合作用户、原厂窗口、大学实验室或已有样品资源借用少量样品。虽然麻烦，但这一步决定了测试结果能不能被内部认可。十八、这次交流对存算类用户的启发这次交流最有意思的地方在于，用户本身并不是传统 NAND 原厂，也不是普通 SSD 厂商。他们做的是存算相关方向，自己不生产 NAND，而是可能使用第三方 NAND 颗粒构建自己的系统或产品。这类用户面对的挑战很典型：他们不是 NAND 制造商，所以拿不到完整的内部器件模型； 他们不是传统 SSD 主控厂，所以未必有完整 NAND characterization 能力； 但他们又要把 NAND 用到自己的系统里，甚至可能出现更高温、更特殊访问模式、更特殊工作负载； 这时，仅仅相信 datasheet 或供应商口头说明是不够的。因此，他们需要一种“轻量级但足够专业”的方法，先把少量 NAND 颗粒在目标边界条件下测一遍。这就是 NplusT这类 NAND 特性测试设备和测试服务的切入点。十九、这件事真正要解决的，不是买设备，而是回答三个工程问题回看两段交流，表面上大家在聊设备、socket、温度、CSV、服务模式，但真正要回答的是三个工程问题。第一个问题：目标 NAND 在用户真实温度边界下还能不能正常读写？这对应 95℃以上、120℃短期读写、Program/Erase/Read Disturb 等测试。第二个问题：如果出现异常，能不能通过数据判断异常模式？比如是读错误增加、Program 失败、擦除异常、Retention 漂移，还是 Read Disturb 敏感性变强。第三个问题：用户后续要不要建立自己的 NAND 特性分析能力？如果只是一次验证，就做测试服务；如果未来产品持续依赖第三方 NAND，并且访问模式和温度边界都很特殊，那就要考虑长期能力建设。这三个问题，比“设备多少钱”更重要。二十、结语：NAND不是黑盒，尤其在高温和新场景里在传统 SSD 里，很多人习惯把 NAND 看成主控后面的存储介质。主控厂商做固件，NAND 原厂提供颗粒，系统厂商买盘使用，大家按各自角色分工。但到了存算（CIM/IMC - compute in memory/In-memoy compute)、边缘设备、特殊散热条件、非传统访问模式这些新场景里，NAND 就不能再被当成完全黑盒。一颗 NAND 在标准温度下能正常读写，不代表它在 95℃、105℃、120℃下仍然表现稳定。 一颗 NAND 在普通 SSD 里没问题，不代表它在新的访问模式和热环境下没有风险。 一颗来自渠道的 NAND 能点亮，也不代表它适合拿来做高温特性判断。 一个供应商给出的 datasheet，也不能替代用户自己在目标工况下的实测数据。这次交流的价值就在这里：它没有急着把设备卖给用户，而是先把问题拆开——样品是什么封装？温度要到多少？测哪些动作？要什么数据？是一次性服务还是长期能力？样品来源是否可靠？现有 socket 是否适配？是否需要 NplusT原厂参与？对于用户来说，下一步不是马上下单，而是先把需求文档写清楚。只要样品、封装、温度、测试动作和数据目标明确下来，这件事就可以从“我想看看高温下会不会有问题”，变成一套可执行的 NAND 高温特性验证方案。在 NAND 越来越贵、越来越难买、应用场景越来越复杂的今天，这种颗粒级测试能力，已经不只是 NAND 原厂和 SSD 主控厂才需要。任何把第三方 NAND 放进自己系统里的团队，都迟早会遇到类似问题：这颗 NAND，在我的真实环境里，到底靠不靠谱？而答案，最终还是要靠测试数据说话。更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

Gen6 SSD 还没大规模量产，测试环境为什么必须先跑起来？一次 PCIe 6.0 企业级 SSD 测试方案交流复盘PCIe 6.0 SSD 的时代正在靠近，但真正做过研发测试的人都知道，Gen6 SSD 不是“换一块盘、插到服务器里跑一下”这么简单。这一代接口从 PCIe 5.0 到 PCIe 6.0，不只是速率翻倍，更涉及 PAM4、FLIT Mode、链路训练、协议兼容性、低功耗状态、OCP/NVMe 规范、热插拔、电源容忍度、故障注入，以及服务器平台尚未完全成熟之前如何提前搭建研发环境等一整套问题。这次远程交流，正是围绕一家企业级 SSD 团队未来的 Gen6 产品规划展开，客户在深圳，成都，上海和江苏都有研发中心。客户的核心诉求很明确：未来设备不仅要能覆盖 PCIe 6.0，也要兼容 PCIe 5.0、PCIe 4.0 产品线；不仅要能看协议，还要能做研发测试、兼容性测试、热插拔、电压拉偏、功耗分析和故障注入。换句话说，这不是单点工具采购，而是一次 Gen6 SSD 研发测试体系的整体梳理。我们本次交流基本围绕我们去年9月份写的一篇文章展开：【专题】全球最全面的 PCIe 6.0/CXL 3.0 测试工具方案探讨汇总。一、先从接口讲起：Gen6 SSD 到底会是什么形态？会议一开始，工程师先把讨论范围定下来：如果没有特别说明，本次讨论的 PCIe 6.0 SSD 测试，主要指向 EDSFF 形态的企业级 NVMe SSD，尤其是 E3.S、E1.S 这类接口。这个判断背后，其实有一个行业背景。过去国内数据中心和企业级服务器里，PCIe 4.0、PCIe 5.0 SSD 大量采用 U.2 形态。国内互联网大厂、传统数据中心、服务器系统里，U.2 盘的存量非常大。U.3 虽然在规格上也存在，但实际市场渗透率并不高，真正大量使用 U.3 背板和 U.3 SSD 的环境相对有限。M.2 则是另一个方向。它在笔记本、PC、工作站里非常普遍，也有一些服务器或嵌入式场景会用 M.2 SSD。但从企业级大容量、高散热、高可靠性的角度来看，M.2 的空间和散热条件天然受限，更多还是面向客户端、工作站或特定小型化应用。而国际市场从 PCIe 5.0 开始，EDSFF 的存在感明显提升，尤其是 E3.S、E1.S 等形态。EDSFF 从 2017 年左右开始发展，到今天已经成为企业级 SSD 走向高密度、高速率、高散热设计的重要方向。E3.S 更适合主流企业级 SSD，E1.S 则常见于高密度、小尺寸存储部署。因此，我们判断，国内外企业级 SSD 厂商在 Gen6 阶段的主流方向，基本都是以 EDSFF 为核心，尤其是 E3.S，同时也会有部分 E1.S 产品。U.2 会不会继续存在？可能会，但目前还不是很确定。二、客户真正关心的是：一套设备能不能兼容 Gen6、Gen5 和 Gen4？客户随后提出了自己的规划：公司未来会做 PCIe 6.0 产品，但 PCIe 5.0、PCIe 4.0 存量市场不会放弃，所以希望测试设备能够同时覆盖 Gen6、Gen5、Gen4。这也是很多企业级 SSD 厂商现在面对的现实。研发部门要面向下一代产品做准备，但销售和量产还要继续服务现有市场。测试平台如果只能测 Gen6，而不能覆盖 Gen5、Gen4，就会造成设备利用率下降；反过来，如果只买 Gen5 平台，又很快会遇到 Gen6 研发阶段的能力缺口。工程师的回答比较直接：从协议分析、训练器、转接夹具、热插拔、电源测试、功耗分析等方向来看，当前介绍的工具体系基本都按 PCIe Gen1 到 Gen6 的兼容思路来设计。但这里也特别提醒了一点：Gen6 与 Gen5/Gen4 的物理层和协议层差异很大。PCIe 6.0 引入 PAM4 和 FLIT Mode，而 Gen5、Gen4 仍然是 NRZ 体系。因此，真正的协议分析仪必须在逻辑和协议层同时支持两套机制；而一些纯物理转接件、夹具、线缆和背板类工具，则更多取决于信号完整性和连接形态，本身并不理解协议内容。换句话说，测试系统表面看起来都是“接一块盘”，但真正能不能覆盖 Gen6 到 Gen4，要看它是在协议层、链路层、电气层，还是只在机械连接层做兼容。三、U.2 的不确定性：不是客户不关心，而是产业链还没完全定下来随后会议进入一个很关键的讨论：PCIe 6.0 U.2。对于国内企业级 SSD 厂商来说，U.2 是绕不过去的话题。因为国内大量服务器和数据中心存量环境都是 U.2，客户自然会问：如果我未来做 Gen6 U.2 SSD，你们的分析仪和测试系统能不能支持？工程师解释，目前 Gen6 U.2 的最大不确定性之一在连接器。要做真正符合 PCIe 6.0 信号要求的 U.2 背板和连接器，需要连接器厂商完成相应的 Gen6 级别验证。安费诺这类主流连接器厂商的 Gen6 U.2 connector 进度曾多次延后，因此测试夹具厂商也需要等待连接器成熟后才能发布真正可交付的 Gen6 U.2 interposer 或 fixture。这并不意味着测试系统不支持 U.2，而是说：如果今天采购 Gen6 协议分析套装，EDSFF、M.2、AIC、MCIO 等形态可以优先覆盖；U.2 部分则需要等待 Gen6 U.2 connector 完成验证后补齐。方案设计上会预留 U.2 支持，一旦连接器条件成熟，就可以补发相应夹具。工程师还提到一个有意思的行业观察：市场上关于三星是否会推出 Gen6 U.2 SSD 的信息并不完全一致。一方面，曾经有人在客户现场看到过三星 Gen6 U.2 原型盘，并且还做过链路测试；另一方面，也有服务器厂商反馈三星可能不会推出 Gen6 U.2，而更多转向 EDSFF。这说明 Gen6 U.2 不是完全没有可能，但大概率只会是少数厂商、少量型号或过渡性产品，不太可能成为主流方向。这一段讨论的价值在于，它把“客户希望兼容 U.2”的诉求和“产业链是否真正准备好 Gen6 U.2”的现实区分开了。对研发团队来说，设备选型不能只看今天有没有某个接口，还要看未来主流产品形态到底会往哪里走。四、PCIe 6.0 规范已经发布多年，但生态真正成熟是另一回事接下来，工程师梳理了 PCIe 6.0 生态的发展节奏。PCIe 6.0 规范早在 2022 年 1 月已经正式发布。但规范发布之后，并不代表生态马上可用。中间两年多时间里，各类 IP 厂商、芯片厂商、测试仪器厂商、连接器厂商、服务器平台厂商都在分别开发自己的产品和验证环境。真正开始小规模互通测试，大约是在 2024 年 6 月的第一次 PCIe 6.0 Preliminary FYI Workshop。那一次测试结果并不理想，很多设备之间无法稳定互通，问题非常多。到了 2024 年 10 月的第二次测试，情况有所改善，部分厂商开始能够建立真正的 64GT/s 链路。2025 年 3 月的第三次测试继续推进，互通情况进一步改善。2025 年 10 月左右的第四次测试，整体成熟度已经明显提升。2026 年 3 月进行了第五次测试，随后又在 4 月做了 retest，把前一轮暴露的问题继续修正。最终，在 2026 年 5 月的 PCI-SIG 开发者大会上，PCIe 6.0 的物理层和协议层兼容性测试规范正式确定，协议测试供应商SerialTek也进入官方 CTS 体系。这一段信息对 SSD 厂商非常重要。因为它说明，Gen6 生态不是突然从天上掉下来，而是经历了多轮互通、失败、修正、再测试之后，才逐步具备进入正式兼容性测试的基础。对于计划开发 Gen6 SSD 的厂商来说，现在已经不是“观望一下”的阶段，而是要开始准备测试环境、研发流程和合规验证路径。五、为什么不能等 Gen6 服务器成熟以后再开始测？会议中还有一个很现实的问题：如果 Gen6 服务器平台还没大规模上市，SSD 厂商怎么测试自己的 Gen6 SSD？工程师提到，目前一些服务器 CPU 和原型平台已经在验证，但从服务器厂商拿到参考设计，到 EVT、DVT、PVT、Pilot Run，再到大规模量产，中间通常需要较长周期。对于一般企业客户来说，真正能够批量购买成熟的 PCIe 6.0 服务器，可能还要等比较久。但 SSD 厂商不能等到服务器完全成熟之后再启动 Gen6 研发。等服务器买得到时再开始测，产品节奏就已经落后了。所以，Gen6 SSD 的研发测试环境必须提前搭建。这个环境里需要有能够模拟 Root Complex 的训练器，需要有能够抓取双向流量的协议分析仪，需要有 EDSFF/M.2/AIC/MCIO 等不同形态的 interposer 和 fixture，还要有能模拟热插拔、电源波动、故障注入和功耗监测的工具。这其实是本次交流的核心逻辑：在真正的 Gen6 服务器平台全面成熟之前，SSD 厂商需要先用专业测试工具搭出一个可控、可重复、可自动化的研发环境。六、第一类工具：协议分析仪、训练器和 CTS 兼容性测试随后会议进入具体工具介绍。首先是 PCIe 6.0 协议分析仪和训练器SerialTek产品。工程师介绍，这套系统可以用于两类场景。第一类是协议分析，也就是把分析仪串在主机和设备之间，抓取 PCIe 双向流量。不同接口需要不同的 interposer 或 POD，例如 AIC 插卡、MCIO cable、EDSFF E3/E1、M.2，未来还包括 Gen6 U.2。对于服务器环境，特别是 CPU 到背板之间通过 MCIO x8 cable 连接的场景，分析仪可以串在中间观察链路训练和数据传输过程。第二类是训练器，也就是让设备模拟 Root Complex 一侧，主动和 SSD 建链，向 SSD 发送特定 packet、TLP、DLLP 或错误包，观察 SSD 的响应。对于 SSD 厂商来说，这非常有价值，因为研发早期并不一定有成熟服务器平台，训练器可以替代 CPU/Root Complex 角色，帮助验证盘端控制器、固件和链路行为。客户问到一个关键点：同一台设备到底是分析仪，还是训练器？工程师解释，同一套硬件可以按授权配置为 analyzer，也可以配置为 tester/exerciser。如果只启用分析功能，成本会低一些；如果同时启用分析仪、训练器和兼容性测试功能，价格会更高。设备可以通过 Web 管理界面切换 operation mode。切到训练器模式后，它可以模拟 RC 或 Endpoint，并且在训练器模式下也能抓取 trace，用于后续分析。如果预算允许，也可以采用两台设备：一台专门做训练器，一台专门做分析仪。这样可以获得更大 buffer 和更完整的同步分析能力。但对大多数研发团队来说，一台二合一设备通常更经济，训练时也可以记录必要 trace，只是不能同时在另一个真实环境里再独立做分析。七、这代协议分析仪的关键优势：不是“能抓包”，而是能处理大 trace会议里 工程师花了不少时间解释SerialTek PCIe 6.0协议分析仪的架构优势。传统协议分析仪的问题不在于抓不到数据，而是在于抓到大量数据之后，后处理非常慢。传统架构通常需要把 trace 从分析仪导出到 PC，再由 PC 上的客户端软件做解码和分析。这种方式在 PCIe Gen4、Gen5 时代就已经很吃力，到 Gen6 时问题会更加明显。几十 GB、上百 GB 的 trace，如果要靠 PC 单核软件慢慢解码，工程师很可能等几个小时甚至更久，例如1-2天。这套分析仪的思路不同：抓包、存储、解码、后处理都在分析仪内部完成。分析仪内部是高性能服务器架构，并内置 NVMe SSD 用于存储 trace。用户电脑只是通过 Web 界面访问分析结果，不需要把原始数据全部拖回本地。工程师举了一个对比：传统分析仪处理几十 GB trace，导出和解码可能要花几个小时；而这套系统可以在分析仪内部快速完成解码，再通过浏览器访问。对于上百 GB trace，也可以通过链接分享给同事，多个工程师同时打开同一个 trace 进行协同分析，不需要反复拷贝大文件。这对 SSD debug 很重要。因为高速链路问题往往不是一次短抓包就能看清楚的。链路训练、掉盘、低功耗切换、错误恢复、热插拔异常、长时间压力测试后的偶发问题，都可能需要大容量 trace 和快速定位能力。同时，设备支持 RESTful API，可以通过 Python 脚本自动化控制抓包、触发、停止、保存 trace 和分析结果。对需要把协议分析纳入自动化回归测试的团队来说，这一点比单纯手工抓包更关键。八、第二类工具：面向 NVMe/OCP 的 SSD 研发测试平台在协议层工具之后，会议进入 SSD 研发测试平台SanBlaze。工程师介绍的这类平台，核心作用不是看某一次链路训练，而是从 NVMe 协议、命令集、命名空间、管理命令、企业级特性、OCP 规范等角度，对 SSD 做系统性黑盒测试。这类测试平台支持大量 NVMe 测试用例，覆盖 NVMe 基础读写、Admin Command、Namespace 创建/删除/管理、Namespace 多种组合、NVMe-MI、带内管理、VDM、SPDM、安全相关功能、SR-IOV、Dual Port、Data Center NVMe 等方向。对于企业级 SSD 来说，这些内容越来越重要，因为客户不再只看顺序读写性能，而是会看它是否满足云厂商、OCP、NVMe 组织和数据中心规范要求。会议中特别提到了 OCP 2.6 相关测试。工程师说明，OCP 规范在国际云厂商和服务器生态中影响很大，相关测试通常会涉及 UNH-IOL 等实验室流程。对于想进入海外云厂商或国际服务器供应链的企业级 SSD 厂商来说，OCP/NVMe 合规测试不是可选项，而是产品进入目标市场前必须提前准备的门槛。这类平台的价值在于，它能把 SSD 控制器和固件中的问题尽早暴露出来。很多问题如果等到客户服务器环境里才发现，定位成本会非常高；如果在研发阶段通过系统化测试用例提前暴露，修复效率会高很多。九、第三类工具：热插拔、故障注入、电压拉偏和功耗分析随后会议转到 Quarch 公司相关测试模块，这部分非常贴近企业级 SSD 可靠性验证。工程师重点介绍了三个方向：热插拔、故障注入、电源拉偏和功耗监测。首先是热插拔。很多人以为热插拔测试就是“给盘断电再上电”，但这其实不准确。真实热插拔过程中，连接器的不同 pin 脚有长短设计，接触顺序和断开顺序都有规范要求。盘插入背板时，不是所有信号同时接通；盘拔出时，也不是所有信号同时断开。因此，真正的热插拔模拟设备，需要按照规范定义的接触顺序、时间间隔和边带信号行为来模拟插入/拔出过程，而不是简单做电源开关。这对 SSD 稳定性测试非常关键，因为很多掉盘、无法重新枚举、链路恢复失败的问题，只有在接近真实热插拔行为的环境下才会暴露。第二是故障注入。对于 PCIe Gen6 SSD 来说，不能只验证“理想链路下可以跑”。还需要验证 lane 异常、链路错误、信号中断、边带信号异常、错误包等 corner case 下，盘端控制器和固件是否能够正确恢复。故障注入模块可以在特定 lane 或特定信号上制造可控异常，用来观察 SSD 是否符合预期。第三是电源测试。这里 工程师区分了 PPM 和 PAM 两类设备。PPM 是 Programmable Power Module，主要用于主动给盘供电，并模拟不同电压条件。比如把 12V 或 3.3V 做上浮、下拉、抖动或异常变化，观察 SSD 在电压波动下是否稳定。这适合做电源容忍度、电压拉偏和功耗边界测试。PAM 是 Power Analysis Module，更像是被动监测工具。它不主动替代背板供电，而是插在真实服务器背板与 SSD 之间，长时间记录电压、电流、功耗和边带信号。比如一块盘在服务器里跑了三天三夜，凌晨某个时间点突然掉盘，如果怀疑边带信号、供电瞬态或功耗变化导致异常，PAM 就可以回溯对应时间点的数据。工程师特别强调，如果测试目标是“真实服务器背板到底给 SSD 提供了怎样的电压和电流”，就应该用 PAM，而不是 PPM。因为 PPM 一旦接入，就变成 PPM 在给盘供电，而不是原始服务器背板在给盘供电。这个区别在 debug 时非常重要。十、L0p：Gen6 SSD 低功耗测试不能忽略会议中还专门提到 PCIe 低功耗状态，尤其是 L0p。过去在笔记本、移动设备上，大家更熟悉 L1、L1.1、L1.2 这类低功耗状态。它们的特点是链路可以进入更深的省电状态，但恢复时需要一定时间，适合客户端设备和电池供电场景。数据中心不一样。服务器里的 SSD 需要随时响应，不可能频繁进入深度休眠再慢慢唤醒。于是 L0p 的价值就体现出来了：它是在工作状态下进行功耗优化，让链路仍然保持可用，同时降低部分功耗。这对 Gen6 数据中心 SSD 非常关键。随着速率提高，功耗和散热压力都在增加。未来客户不仅会问“你的盘跑多快”，还会问“你的盘在实际业务负载下功耗曲线如何”“是否支持 L0p”“进入和退出低功耗状态是否稳定”“功耗变化和协议状态能否对应起来”。因此，协议分析仪如果能够把 trace 与电压、电流、功耗数据结合起来，就能帮助研发团队从协议行为和电源行为两个维度定位问题。这也是 Gen6 SSD 测试从“性能测试”走向“系统行为测试”的典型体现。十一、第四类工具：没有成熟 Gen6 服务器时，如何搭建测试环境？最后，会议讨论了 Gen6 SSD 测试环境搭建。在真正成熟的 Gen6 服务器批量上市之前，SSD 厂商可以通过PCIe Gen6 switch 卡、Retimer/Redriver、MCIO cable、EDSFF 转接模块、电源模块等组件搭建验证环境。例如，服务器 CPU 或测试平台通过 MCIO x8 cable 连接到背板或转接板，再分出两个 x4 链路连接 E3.S/E1.S SSD。对于研发实验室，也可以使用 Gen6 switch 卡扩展多个下行端口，连接多块 SSD 进行基础验证。但 工程师也提醒，早期测试环境不要一味追求“接很多块盘”。在 Gen6 阶段，信号完整性、供电、散热、Retimer、线缆、背板都会影响稳定性。初期更建议先把一两块盘测稳定，把链路训练、协议行为、功耗和热插拔流程跑清楚，再逐步扩展到更多盘位。如果需要更系统的多盘验证，可以进一步考虑专用 SSD 测试平台或 JBOF/JBOD 类环境，而不是临时堆线搭环境。Gen6 的测试环境越复杂，越需要工具链和夹具体系提前规划，否则很容易陷入“看起来都接上了，但问题到底出在线缆、背板、Retimer、SSD 还是 host 上”的混乱状态。十二、SanBlaze iRiser6 与 Quarch 模块：一个适合集成平台，一个适合真实环境会议后半段还讨论了 SanBlaze 平台里的 iRiser6故障注入模块与 Quarch 模块的区别。SanBlaze 的 iRiser6模块可以集成在 SanBlaze 测试平台内部，用于更精细的故障注入和自动化测试。它与平台测试用例结合得更紧密，适合在一体化测试系统中暴露 SSD 控制器和固件问题。Quarch 模块则更适合插入真实服务器或客户实际测试环境。比如客户要在自己的服务器背板、真实 host、真实线缆环境里观察热插拔、电源、边带信号或故障注入行为，Quarch 模块的灵活性更强。简单来说，SanBlaze 更像是一个完整的研发测试平台，适合系统化、自动化、规范化测试；Quarch 更像是工程现场的可控扰动和测量工具，适合真实环境下的问题复现与 debug。两者不是简单替代关系，而是不同阶段、不同测试场景的互补。十三、这次交流的真正结论：Gen6 SSD 测试不是一台仪器能解决的事回看整场交流，客户一开始问的是“Gen6 SSD 测试设备怎么选”，但讨论到最后，答案已经很清楚：Gen6 SSD 测试不是一台协议分析仪，也不是一台性能测试平台就能全部解决。真正完整的 Gen6 SSD 测试体系，至少包括四层能力：第一层，是协议可见性。也就是通过 PCIe 6.0 协议分析仪看到链路训练、FLIT、TLP、DLLP、错误恢复、低功耗切换等底层行为。第二层，是主动激励能力。也就是通过训练器模拟 Root Complex，主动给 SSD 发包、建链、制造特定场景，在没有成熟 Gen6 服务器时提前验证盘端行为。第三层，是 SSD 研发测试能力。也就是通过 NVMe/OCP/DC NVMe 等测试套件，覆盖命令集、命名空间、管理通道、安全、虚拟化、数据中心规范等系统性测试。第四层，是真实工程环境能力。也就是热插拔、故障注入、电压拉偏、功耗分析、边带信号记录、服务器背板供电监测等可靠性和 debug 能力。Gen6 SSD 的竞争不会只发生在顺序读写性能数字上。真正决定产品能否进入客户验证、能否通过国际规范、能否在数据中心长期稳定运行的，是这些“看不见但非常关键”的工程细节。对于企业级 SSD 厂商来说，PCIe 6.0 的窗口期已经开始。服务器生态可以慢慢成熟，但 SSD 研发测试体系不能等。谁能更早把 Gen6 测试环境搭起来，谁就能更早暴露问题、修复问题、积累互通经验，并在客户真正启动 Gen6 项目时，拿出更成熟、更可信的产品。这也是这次交流最有价值的地方：它没有停留在“某个设备参数如何”，而是把 Gen6 SSD 从接口形态、协议分析、兼容性测试、NVMe/OCP 规范、热插拔、电源、功耗、故障注入到实验室环境搭建，完整串成了一条研发验证路径。PCIe 6.0 SSD 还没有真正大规模铺开，但测试环境必须先跑起来。因为到了 Gen6 这一代，等客户发现问题时再 debug，往往已经太晚了。更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

我们一般的人认为针对NVMe SSD 测试似乎很简单：插上一块盘，跑一下 FIO，看顺序读写、随机读写、IOPS、延迟，再做几轮压力测试，好像就差不多了。但真正做过企业级 SSD 研发的人都知道，这只是最表层的一小部分。一块企业级 NVMe SSD，尤其是 PCIe 5.0/6.0 SSD，真正难测的地方并不只是“跑得快不快”，而是它在各种复杂状态下是否仍然稳定、可控、可解释：主机发出的 NVMe Admin Command 是否响应正确？ Namespace 创建、删除、格式化、切换后数据是否一致？ 掉电、热插拔、PERST#、PWRDIS、PLN/PLA 这些边带信号出现异常时，盘会不会掉线？ 进入 L1.1/L1.2 或更高阶低功耗状态后，能不能按规范醒来？ 支持 ZNS、FDP、SR-IOV、SPDM、TCG Opal、NVMe-MI 之后，固件是否真的按规范实现？ 面对 OCP Cloud SSD、Datacenter NVMe SSD 这些云厂商规范，是否能提前发现不合规项？ 到了 PCIe 6.0，链路速率进入 64GT/s，测试平台本身能不能稳定、可重复、可自动化地驱动被测盘？这就是 SanBlaze 这类 NVMe SSD 研发测试平台存在的意义。它不是一台简单的“性能测试服务器”，而是把主机侧控制、协议测试、功能验证、自动化脚本、功耗/复位/热插拔控制、故障注入和测试报告整合在一起，帮助 SSD 厂商在研发阶段就把问题暴露出来。一、先给没接触过 SSD 测试的工程师讲清楚：NVMe SSD 到底要测什么？很多工程师第一次接触 SSD 测试时，容易把它理解成性能测试。比如顺序读 14GB/s，随机读 300 万 IOPS，延迟多少微秒。这些当然重要，但只靠这些远远不够。一块 NVMe SSD 的测试，至少可以分成六层。第一层是基本枚举和链路训练。主机能不能识别这块盘？PCIe 链路能不能从 Gen1、Gen2、Gen3、Gen4、Gen5，最终训练到目标速率？宽度是 x4 还是降到 x2/x1？有没有大量 Correctable Error？这些属于 PCIe 和 NVMe 初始化的基础问题。第二层是NVMe 命令和协议行为。包括 Identify、Get Log Page、Set Features、Format NVM、Firmware Download/Commit、Create/Delete IO Queue、Create/Delete Namespace、Sanitize、Self-Test 等命令。很多问题不是盘完全不能用，而是某个字段返回错了、某个状态码不符合规范，或者某个 corner case 下固件处理不完整。第三层是数据一致性和压力测试。读写压力、随机访问、长时间运行、断电恢复、写满盘、跨 Namespace、跨 Queue、跨线程、跨温度条件下，数据是否一致，是否出现 silent data corruption。第四层是企业级特性测试。例如 Dual Port、SR-IOV、ZNS、FDP、NVMe-MI、SPDM、TCG Opal、DIF/DIX、CMB/HMB 等。这些功能不是所有 SSD 都支持，但一旦支持，就必须按照规范完整实现，否则在云厂商、服务器厂商或认证实验室那里很容易被打回。第五层是电源、复位、热插拔和低功耗测试。企业级 SSD 不是永远插在理想主板上跑。真实服务器里会有热插拔、掉电、供电波动、PERST# 抖动、PWRDIS、PLN/PLA、CLKREQ#、L1.1/L1.2 等状态。很多“偶发掉盘”问题，恰恰出现在这些状态切换过程中。第六层是合规、认证和报告。如果产品要进入大客户、云厂商或官方认证流程，就不能只说“我们自己测过没问题”，而是要有标准化脚本、可复现日志、完整报告，以及与 NVMe/OCP/UNH-IOL 等生态一致的测试方法。SanBlaze 的价值，正是把这些测试从零散脚本和临时环境，变成一个可控、可重复、可扩展的测试平台。二、SanBlaze 不是单一设备，而是一套 NVMe SSD 测试体系SanBlaze 的核心产品线可以简单理解成三类。第一类是 SBExpress Rackmount / Desktop 测试系统，也就是常见的 RM 系列和 DT 系列。RM 更偏机架式、多盘位、企业级研发验证环境；DT 更偏桌面式、小规模开发、客户端或工程验证环境。第二类是 SBCert / Certified by SANBlaze 测试软件和脚本体系。它不是简单跑几个 benchmark，而是用预封装脚本做 NVMe、OCP、低功耗、Namespace、Power/Reset、Management Interface 等系统测试，并自动生成报告。SanBlaze 官网对 Certified by SANBlaze 的描述很直接：工程师可以选择测试项并启动，系统会标记失败、跳过、警告项，并生成报告。第三类是 iRiser / iRiser+ / iRiser-6 这类精密 riser 和故障注入硬件。它们负责控制 PCIe/NVMe 设备的供电、复位、边带信号、链路信号，甚至做 lane glitch，帮助工程师模拟真实服务器里很难手工制造的异常场景。从公开资料看，SanBlaze 的 SBExpress 平台强调覆盖开发、设计验证、QA 等生命周期，并支持软件可控的硬件属性、自动化测试循环、错误暴露、非一致性检测，以及电压/电流/功耗测量。这也是它和普通服务器测试平台最大的不同：普通服务器主要负责“跑业务”；SanBlaze 更像一个可编程的 NVMe SSD 主机侧测试仪，目标是把盘的协议、固件、电源、边带和异常恢复能力测出来。三、RM6：面向 PCIe 6.0 NVMe SSD 的核心研发测试平台到了 PCIe 6.0，SanBlaze RM6 是最值得重点关注的产品。SanBlaze 在 Gen6 NVMe SSD 测试页面中把 RM6 定位为面向 PCIe Gen6 NVMe SSD 的 Rackmount 测试平台，并强调它是 16-bay 企业级 NVMe 测试设备，支持 PCIe Gen1 到 Gen6。这个“Gen1 到 Gen6”很关键。企业级 SSD 厂商不会突然只做 Gen6，Gen4、Gen5 产品仍然要维护和量产，Gen6 产品则开始进入研发验证。因此，一套测试平台如果只能测 Gen6，利用率不够；如果只能测 Gen4/Gen5，又跟不上新产品节奏。RM6 的价值就在于，它为 Gen6 研发准备，同时向下兼容已有产品线。SanBlaze 还在 2025 年发布资料中提到 RM6 是其 PCIe Gen6 NVMe validation/compliance test system，支持 Gen1 到 Gen6，并集成 SBCert 测试套件。从工程角度看，RM6 适合几类典型场景：第一，Gen6 SSD 控制器和固件研发验证。 SSD 控制器刚 bring-up 时，很多问题不是性能问题，而是枚举、Identify、Queue 创建、Namespace 管理、Firmware Commit、Reset、Power State、Error Log、SMART Log 等基础行为是否稳定。RM6 可以作为可控 host，系统化运行这些测试。第二，Gen6/Gen5/Gen4 多代产品共用平台。 对于 SSD 厂商来说，一套平台能同时覆盖多代产品，可以减少实验室设备割裂。研发可以用它测 Gen6 原型盘，验证团队可以继续测 Gen5 量产盘，FAE 也可以用类似脚本复现客户问题。第三，OCP / Datacenter NVMe / Cloud SSD 规范测试。 现在企业级 SSD 越来越多面向云厂商和 AI 数据中心。客户不仅看 NVMe 标准，还会看 OCP Cloud SSD、Datacenter NVMe SSD 等规范。SanBlaze 宣称其 OCP 2.6 测试套件与 Microsoft Azure 合作开发，并覆盖 OCP NVMe Cloud SSD 与 Datacenter NVMe SSD 相关测试方向。第四，自动化回归测试。 RM6 不是给工程师手工点几下用的。SanBlaze 平台支持 GUI，也支持 Python、REST、CLI/XML API 等自动化方式。SanBlaze 在 DT5CD 页面中明确写到支持 Python、REST、CLI/XML API，并可使用开箱即用的 Certified by SANBlaze 测试或自定义测试。第五，多盘位和批量验证。 RM6 的 16-bay 形态适合实验室做多盘回归、不同固件版本比较、不同 Namespace/Power/Reset 组合测试，也适合在进入认证或客户送测前做集中筛查。一句话概括：RM6 不只是“能插 Gen6 SSD 的服务器”，而是一套围绕 PCIe 6.0 NVMe SSD 研发、预认证和自动化验证设计的测试平台。四、iRiser-6：Gen6 SSD 测试里最容易被低估的一张卡如果说 RM6 负责“系统化测试”，那么 iRiser-6 负责把很多真实环境中的异常变成可控测试。SanBlaze 的 iRiser Family Guide 里列出，iRiser6 是 PCIe Gen6 iRiser，兼容 RM5+ 和 RM6，支持 PCIe lane control / glitching；iRiser6SE 则是不带 lane control / glitching 的标准版本。资料中还提到，iRiser 系列可以精密控制 PCIe/NVMe 供电和控制信号，同时持续监测功耗；电源采样最高接近每秒 100 万次，并且信号动作序列可以达到 10ns 级别的时间精度。这对 SSD 测试非常有意义。因为很多问题不是正常读写能发现的，而是要靠“制造不正常”才能暴露。例如，工程师可以用 iRiser-6 做这些事情：模拟 PERST# 的短脉冲或异常抖动，观察盘是否错误复位。 模拟 PWRDIS、Power Loss Notification、Power Loss Acknowledge 的异常顺序。 控制 12V/3.3V 上下电时序，观察固件是否正确保护数据。 控制 CLKREQ#、PERST#、RESET 等边带信号，看低功耗状态和唤醒是否可靠。 对 PCIe lane 做 glitch 或关闭某些 TX/RX 信号，观察链路是否进入 Recovery、是否降速、是否掉盘、是否能恢复。 在特定 IO 压力下制造 surprise removal 或 graceful removal，验证数据一致性和异常日志。SanBlaze 文档中还展示了 lane glitch 的能力，例如对 TX0/TX1/TX2/TX3 等 PCIe lane 信号做关闭或 glitch；该能力适用于 iRiser5/5+/6，而不适用于 iRiser6SE。文档中还给出过 PERST# glitch 的序列示例：先上电，释放 PERST#，再对 PERST# 做 100ns 级别的 glitch，然后再释放。并且 iRiser 的动作序列可以用 10ns 精度控制不同信号之间的时间间隔。这类测试对 Gen6 尤其重要。PCIe 6.0 的链路更高速，信号裕量更小，Retimer、Switch、背板、线缆、连接器都会影响稳定性。如果 SSD 固件只在理想条件下测过，一旦进入真实服务器，热插拔、边带时序、供电扰动、lane 异常就可能触发客户现场问题。iRiser-6 的价值，就是在实验室里把这些问题提前制造出来。五、SanBlaze 可以测哪些 NVMe SSD 功能？结合 SanBlaze 公开资料和典型 NVMe SSD 研发流程，可以把它的能力分成几大类。1. NVMe 基础命令和功能验证这是所有 NVMe SSD 测试的基础，包括：Identify Controller / Namespace Get Log Page Set / Get Features Create / Delete IO Queue Create / Delete Namespace Format NVM Firmware Download / Firmware Commit Sanitize Device Self-Test Error Log / SMART Log Asynchronous Event Reset / Subsystem Reset / Function Level Reset Read / Write / Compare / Flush / Write Zeroes这些测试看起来基础，但最容易暴露固件细节问题。比如某个 Identify 字段不符合实际能力，某个 Feature 设置后没有生效，某个 Log Page 在 Reset 后丢失，或者 Namespace 删除/重建后状态没有完全清理。2. 性能、压力和数据一致性测试SanBlaze 也可以做常规性能测试，但它的优势不是替代 FIO，而是把性能压力和协议/电源/异常条件结合起来。例如，在随机读写压力下做 Reset；在写满盘后做 Sanitize；在多 Queue、多 Namespace 下做掉电；在 Dual Port 或 SR-IOV 场景下验证 IO 是否隔离；在热插拔前后比较数据一致性。这类测试更接近真实客户环境。3. Power、Reset、Hot Plug 和 Surprise RemovalSanBlaze DT5CD 页面列出了一系列软件可控硬件特性，包括 power up/down、PERST、hotplug、power measurement、SRIS、surprise removal、graceful removal、VDM、SMBus / in-band MI、firmware download 等。这说明它并不是简单“发 NVMe 命令”，而是能把 NVMe 协议和底层硬件控制结合起来。对于 SSD 工程师来说，这非常重要。因为很多客户现场问题表面是“盘掉了”，本质可能是 PERST#、CLKREQ#、PWRDIS、热插拔时序或掉电恢复没有处理好。4. 低功耗和 L1.1/L1.2 测试OCP 和客户端 SSD 测试里，低功耗状态是常见难点。SanBlaze 公开资料提到，SBExpress/SBCert 可测试 OCP 规范符合性、数据完整性、Power/Reset、Management Interface、低功耗子状态等，并且 Version 10.5 引入了 L1.1/L1.2 测试。L1.1/L1.2 的复杂性在于，它不仅是 NVMe Power State 问题，还涉及 PCIe Link State、CLKREQ#、ASPM、主机侧策略、固件唤醒延迟等多方配合。普通服务器上很难精确控制这些状态，而 SanBlaze 这类平台可以用脚本和硬件控制把测试流程固定下来。5. Management Interface：NVMe-MI、SMBus、MCTP、VDM、In-band MI企业级 SSD 越来越强调可管理性。主机不一定总是通过普通 NVMe IO 命令管理 SSD，还可能通过 SMBus、MCTP、PCIe VDM 或 in-band MI 做状态读取、固件更新、日志访问和管理操作。SanBlaze 的公开资料显示，其平台支持 SMBus 1MHz、MI/MCTP over SMBus、VDM、in-band 等方向。这对 OCP 和数据中心 SSD 非常关键。因为云厂商希望在不影响业务 IO 的情况下，持续监控 SSD 健康状态、温度、功耗、固件版本、错误日志和管理事件。六、重点看白皮书 3.7.1 到 3.7.8：这些 license 功能为什么重要？我们在白皮书《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1》目录里列出的 3.7.1 ~ 3.7.8章节，其实正好对应了现代企业级 NVMe SSD 的几个高阶能力。很多功能不是基础授权就能覆盖，而是需要单独 license 激活。下面我们按工程师容易理解的方式解释。3.7.1 NVMe-MI over PCIe VDM 测试NVMe-MI 是 NVMe Management Interface。简单说，它是用来管理 NVMe 设备的接口，不只关注读写 IO，而是关注设备状态、健康信息、固件、日志、管理命令等。在数据中心里，服务器 BMC 或管理控制器可能不通过普通 NVMe IO 路径，而是通过 SMBus/MCTP、PCIe VDM 或 in-band 方式访问 SSD。SanBlaze 的 NVMe-MI 脚本文档中列出了扩展/短设备自测试、固件下载/提交、Crypto Erase、Secure Erase、OCP Log Page 等测试方向。这类测试能发现什么问题？比如，盘在普通 NVMe 命令下看起来正常，但通过 MI 读取 OCP Log Page 时字段不一致；通过 VDM 做固件下载时状态机不完整；Secure Erase 之后日志状态没有正确更新；设备自测试命令返回状态错误。这些都属于管理通道问题，在云厂商环境里非常敏感。3.7.2 ZNS 测试ZNS 是 Zoned Namespace。传统 SSD 的写入由 FTL 自己管理，主机不太关心内部写入位置；而 ZNS 把存储空间划分成 Zone，让主机按照 Zone 规则写入，以减少写放大、提升可预测性和寿命。ZNS 测试不是简单读写，而是要验证 Zone State Machine。SanBlaze ZNS 文档列出了 Get Log Page、Identify、MAR/MOR、Zone State Transition、Zone Descriptor Extension、Read/Write/Append、Zone Management、Sanitize、ZRWA、Async Event、Copy 等测试项。ZNS 很容易出 bug 的地方包括：Zone Append 返回的 LBA 不正确； Closed Zone、Full Zone、Offline Zone 状态处理错误； 超过最大 Open Zone 或 Active Zone 数量时没有返回正确错误码； Zone Reset 后 Write Pointer 没有回到正确位置； 跨 Zone 写入边界检查不严； Sanitize 或 Format 后 Zone 状态没有正确恢复。这些问题普通 FIO 不一定能系统性测出来，但 ZNS 专用脚本可以逐项覆盖。3.7.3 SRIS Clocking Mode 测试SRIS 是 Separate Refclk Independent SSC。简单说，就是主机和设备不是共享同一个参考时钟，而是各自有独立参考时钟，并可能各自带 SSC。对于某些服务器、扩展卡、Retimer、背板和线缆环境，SRIS/SRNS/Common Clock 支持非常重要。SanBlaze 的 PCIe Clocking Modes 文档列出 Common Clock with SSC、Common Clock without SSC、SRIS、SRNS 等模式，并在不同 de-emphasis、不同 link speed 下测量 link error。这类测试能帮助发现：某块 SSD 在 Common Clock 下稳定，但 SRIS 下错误率上升； Gen4 稳定，Gen5/Gen6 下出现大量 Correctable Error； 打开或关闭 SSC 后链路训练失败； 某些 Retimer/背板环境下链路只能降速。到了 PCIe 5.0/6.0，这类问题会越来越常见。因为高速链路不是协议对了就行，时钟、抖动、参考源、均衡和链路训练都会影响最终稳定性。3.7.4 TCG Opal 测试TCG Opal 是自加密硬盘常见的安全规范。它涉及所有权获取、锁定范围、权限、加密擦除、Revert 等流程。SanBlaze TCG 测试文档中列出了 Level 0 Discovery、Properties、Taking Ownership、Activate Locking SP、Configuring Authorities、Configuring Locking Ranges、Unlocking/Erasing Ranges、MBR Shadowing、Revert 等测试方向。这类测试会暴露安全功能实现中的问题，比如：盘宣称支持 Opal，但 Discovery 信息不完整； Ownership 流程能走通，但 Locking Range 配置异常； 锁定后仍能访问不该访问的数据； Erase 或 Revert 后状态没有恢复； 固件升级后安全状态丢失或不一致。企业级客户对安全功能越来越敏感，尤其是云、金融、政府和服务器供应链场景。3.7.5 SPDM 测试SPDM 是 Security Protocol and Data Model，常用于设备身份认证、能力协商、测量、证明和安全通道相关场景。未来云和服务器平台会越来越重视设备级安全和可证明性。SanBlaze SPDM 文档中列出了一些基础一致性工具，例如 GETCAPABILITIES、GETVERSION、NEGOTIATE_ALGORITHMS 等。这类测试能发现：设备宣称支持某个 SPDM 版本，但版本协商失败； Capability 返回字段和实际支持能力不一致； 算法协商不符合主机预期； 安全会话建立前后状态不一致。对于 AI 数据中心和云厂商来说，SSD 不再只是一个存储介质，而是整个可信计算链路的一部分。3.7.6 FDP 功能测试FDP 是 Flexible Data Placement。它允许主机给 SSD 提供数据放置提示，帮助 SSD 更好地组织内部写入，减少写放大、改善 QoS 和寿命。SanBlaze FDP 文档列出 Basic、Negative、Support Tests，并涉及 FDP Log Page 20h–23h、I/O Management Send/Receive、FDP 相关 Features 1Dh/1Eh、Data Placement Directive 等内容。FDP 是近几年企业级 SSD 里非常热的功能，因为云厂商希望主机和 SSD 更紧密配合，而不是让 SSD 完全黑盒管理数据布局。FDP 测试可能暴露的问题包括：FDP 功能声明和实际可用状态不一致； Log Page 返回错误； I/O Management Send/Receive 状态机异常； Data Placement Directive 没有真正生效； 在关闭 FDP 后，相关命令仍然错误响应； 多 Namespace 或多 workload 下 FDP 行为不一致。这类功能如果只靠普通读写压力测试，很难验证清楚。3.7.7 OCP DSSD 功能验证测试OCP DSSD，也就是面向数据中心的 NVMe SSD 规范测试，是企业级 SSD 进入云厂商生态时必须认真对待的部分。SanBlaze 和 UNH-IOL、Microsoft Azure 之间在 OCP NVMe 测试方面有公开合作信息。SanBlaze 宣称其 OCP 2.6 测试套件与 Microsoft Azure 合作开发，覆盖 OCP NVMe Cloud SSD 和 Datacenter NVMe SSD；UNH-IOL 的 OCP NVMe 测试页面也明确写到 OCP NVMe 2.5 testing 使用 SanBlaze VirtuaLUN NVMe 工具。OCP 测试关注的不只是 NVMe 基础命令，还包括可靠性、热管理、功耗、管理接口、日志、形态规格、低功耗子状态等。SanBlaze 的低功耗/OCP 页面也提到，OCP drive tests 超出强制 NVMe 测试范围，涵盖可靠性、热、耐久、管理、形态等方向。这类测试通常会发现：OCP Log Page 字段缺失或单位错误； Power State 声明与实测功耗不一致； PLN/PLA 行为不符合要求； 低功耗状态进入/退出失败； Reset 后关键日志或 Feature 状态不一致； 温度、寿命、错误统计没有按规范更新。3.7.8 SR-IOV 功能测试SR-IOV 是服务器虚拟化和云环境里的关键功能。它允许一个 PCIe/NVMe 设备暴露多个 Virtual Function，让不同虚拟机或租户更高效地访问设备。SanBlaze SR-IOV 文档中列出 Controller Reset、Get Features、Get Log Page 等测试方向，并针对 child devices 做检查。SR-IOV 测试容易暴露的问题包括：Virtual Function 枚举不稳定； PF Reset 后 VF 状态异常； 不同 VF 之间资源隔离不完整； 某个 VF 下 IO 正常，但 Get Log Page 或 Get Features 返回异常； Reset、Firmware Commit、Namespace 变化后 VF 映射错误； 多租户压力下出现延迟尖峰或数据一致性问题。随着 SSD 越来越多用于云平台和 AI 基础设施，SR-IOV 不再是锦上添花，而是进入高端客户验证时必须认真测试的功能。七、UNH-IOL 与 SanBlaze、SerialTek、Quarch 的关系如果从行业认证角度看 SanBlaze，就绕不开 UNH-IOL。UNH-IOL 是 NVMe、NVMe-oF、OCP NVMe 等测试认证生态里非常重要的实验室。UNH-IOL 的 IOL INTERACT 页面明确提到，IOL INTERACT PC Edition 可用于自动化 NVMe SSD 和 NVMe-oF 测试，并且兼容 SanBlaze SBExpress-RM5 和 DT5；相关测试结果可用于 NVMe / NVMe-oF Integrator’s List 流程。UNH-IOL 在 2025 年新闻中也提到，IOL INTERACT 现在授权用于 SanBlaze SBExpress-DT5/RM5；开发者可以在商业验证系统上做完整系统预验证，而 Integrator’s List 则记录通过 UNH-IOL 严格测试的产品。这说明 SanBlaze 与 UNH-IOL 的关系不是简单“都做 NVMe 测试”，而是 SanBlaze 平台已经进入 UNH-IOL 的商业测试工具生态。对于 SSD 厂商来说，这意味着在内部实验室用 SanBlaze 跑预验证，有助于提前对齐认证实验室的测试方法，减少正式送测时的返工。UNH-IOL 的 OCP NVMe 页面还明确写到，OCP NVMe 2.5 testing 使用 SanBlaze VirtuaLUN NVMe 工具，补充既有 NVMe conformance tooling。除了 SanBlaze，UNH-IOL 的 NVMe 测试工具页面也列出 SerialTek 和 Quarch。SerialTek 的角色更偏 PCIe/NVMe 协议可视化。UNH-IOL 页面介绍了 SerialTek Kodiak Gen5 analyzer，强调其嵌入式数据处理，以及通过 interposer 放在 PCIe slot 和 endpoint 之间监测流量。Quarch 的角色更偏热插拔、电源和故障注入。UNH-IOL 页面列出 Quarch Hot-Swap Solution，可用于自动化 PCIe/NVMe hot plug 和 fault injection；同时列出 Quarch Power Modules，可用于电压 margining、电源中断和功耗测量。这三类工具放在一起，正好构成了企业级 SSD 测试的完整闭环：SanBlaze 负责系统化 NVMe/OCP/功能测试； SerialTek 负责 PCIe/NVMe 协议层抓包分析； Quarch 负责真实环境中的热插拔、电源扰动、故障注入和功耗记录。对于真正做 Gen5/Gen6 SSD 的团队来说，这几类工具不是互相替代，而是互相补位。八、全球哪些公司使用 SanBlaze？国际、国内业内基本有点名气的公司都在使用SanBlaze公司的产品，尤其是NVMe SSD controller和盘的厂商，以及NVMe over Fabric的厂家。第一，SanBlaze 官网说明，其系统部署在全球主要存储硬件和软件厂商的测试/开发实验室中。第二，SanBlaze 的主页页面也公开写到，其产品被 Dell/EMC、NetApp、Intel、Pure Storage、HPE 等主要 SAN 和 Storage 厂商使用。第三，Microsoft Azure 与 SanBlaze 在 OCP 2.6 测试套件方面有公开合作信息。SanBlaze 资料中提到，该测试套件与 Microsoft Azure 合作开发，并引用了 Azure 相关负责人对 OCP 2.6 测试套件的评价。第四，UNH-IOL 在 OCP NVMe 测试和 IOL INTERACT 商业测试工具生态中使用SanBlaze 相关工具。第五，第三方测试实验室 Allion 公开表示提供名为 SanBlaze RM5 的 PCIe Gen5 SSD 测试平台，用于性能验证。SanBlaze 已经被全球主要存储厂商、云生态、认证实验室和第三方测试实验室采用或集成。九、SanBlaze 通常能暴露哪些 NVMe SSD 问题？我们从 SanBlaze 的功能和脚本覆盖范围简单看看，典型能暴露的问题也已经非常明确了，简单举几个例子说明如下。1. Identify / Log Page 字段不一致很多 SSD 在基础读写下完全正常，但 Identify Controller、Identify Namespace、SMART / Health Log、Error Log、OCP Log Page 里的字段存在错误。比如能力位宣称支持某功能，但实际命令不支持；或者功耗、温度、Namespace、固件版本、Feature 位返回不一致。这类问题在客户认证中非常常见，因为认证脚本会逐项检查字段，而不是只看盘能不能读写。2. Reset / Power Cycle 后状态恢复异常NVMe SSD 会经历 Controller Reset、Subsystem Reset、Function Level Reset、Power Cycle、Surprise Removal 等状态。很多固件 bug 出现在“重置之后”。例如，Reset 前后 Feature 状态不一致；Namespace 状态没有恢复；Queue 没有清理干净；Log Page 计数异常；Firmware Commit 后重新枚举失败。这类问题可以通过 SanBlaze 的 Power/Reset、Reset 相关脚本和 iRiser 硬件控制更容易复现。3. ZNS 状态机错误ZNS 测试最容易发现 Zone 状态相关问题。比如 Zone Append 返回位置错误，写入 Closed Zone 没有正确报错，Reset Zone 后 Write Pointer 不对，超出最大 Active/Open Zone 时状态码错误。SanBlaze ZNS 脚本正是围绕这些状态和命令组合展开。4. NVMe-MI / VDM 管理通道异常一块盘通过普通 NVMe 命令看起来正常，但通过 MI over VDM 或 SMBus/MCTP 访问时，可能出现日志读取失败、固件下载状态异常、自测试结果不一致、OCP Log Page 返回不完整等问题。这类问题在云厂商环境中非常敏感，因为 BMC 和管理系统往往依赖这些接口长期监测 SSD。SanBlaze 的 NVMe-MI 脚本覆盖设备自测试、固件下载/提交、安全擦除和 OCP Log Page 等方向。5. SRIS / SRNS 时钟模式下链路稳定性不足有些 SSD 在普通 Common Clock 环境下稳定，但换到 SRIS/SRNS 或带 SSC 的环境就出现错误率上升、链路降速、训练失败或 Recovery 频繁发生。SanBlaze 的 clocking mode 测试会在不同 clock mode、de-emphasis、link speed 下观察 link error。这类问题到了 PCIe 5.0/6.0 会更加明显。6. SR-IOV 多虚拟函数行为不一致SR-IOV 场景下，问题不只是能不能枚举 VF，而是 PF/VF reset、Get Features、Get Log Page、IO 压力、Namespace 映射、资源隔离都要正确。SanBlaze SR-IOV 脚本会针对 child devices 做 reset、feature 和 log page 相关测试。这类问题通常只有进入云平台、多租户压力场景后才会暴露，如果研发阶段不测，后期定位成本会非常高。7. SPDM 安全能力协商失败SPDM 测试可能暴露版本协商、能力返回、算法协商不一致等问题。SanBlaze SPDM 工具覆盖 GETVERSION、GETCAPABILITIES、NEGOTIATE_ALGORITHMS 等基础流程。对于未来云和 AI 数据中心设备，SSD 安全认证能力会越来越重要。8. FDP 功能声明与实际行为不一致FDP 是很容易“宣传支持，但细节没打磨好”的功能。问题可能出现在 Log Page、Feature、I/O Management Send/Receive、Data Placement Directive 等多个位置。SanBlaze FDP 文档覆盖 FDP Basic、Negative 和 Support Tests，并涉及多个 FDP log page 和 feature。如果 SSD 要进入云厂商验证，FDP 这类主机协同能力会越来越受重视。9. iRiser-6 故障注入暴露恢复能力不足用 iRiser-6 做 PERST# glitch、lane glitch、PWRDIS、PLN/PLA、CLKREQ#、电源时序控制时，常见问题包括：盘掉线后不恢复、恢复后 Namespace 丢失、错误日志没有记录、IO 返回错误状态、主机需要重新扫描才能发现盘、甚至数据一致性异常。这些问题在实验室用手工插拔很难稳定复现，而 iRiser-6 可以用纳秒级时序和可重复脚本把它们固定下来。十、为什么 RM6 + iRiser-6 对 PCIe 6.0 SSD 特别重要？PCIe 6.0 SSD 的研发难度比 Gen4/Gen5 又上了一个台阶。一方面，Gen6 引入更高速度和更复杂链路行为，信号完整性、Retimer、背板、线缆、连接器都会影响测试结果。另一方面，面向 AI 数据中心的 Gen6 SSD 不会只比拼带宽，还会被要求支持 OCP、FDP、SR-IOV、SPDM、NVMe-MI、低功耗、功耗上限、热管理和高可靠性。如果研发团队只靠普通服务器、FIO 和自写脚本，很容易出现三个问题：第一，测得不全。很多 corner case 根本没有覆盖。 第二，复现困难。客户现场问题回到实验室复现不了。 第三，报告不规范。内部测试结果很难和认证实验室、云厂商要求对齐。RM6 解决的是平台化和系统化问题：多盘位、Gen1 到 Gen6、SBCert、OCP/NVMe 预封装脚本、自动化 API、报告体系。iRiser-6 解决的是精密控制和故障注入问题：供电、复位、边带信号、lane glitch、功耗监测、纳秒级时序。两者组合起来，才更接近真正的 Gen6 SSD 研发测试闭环。如果再把 SerialTek 协议分析仪和 Quarch 电源/热插拔工具引入，就可以形成更完整的方法：SanBlaze 负责发起测试、运行脚本、生成报告； iRiser-6 负责在 SanBlaze 平台内制造可控硬件异常； SerialTek 负责把 PCIe/NVMe 链路上的真实行为抓出来； Quarch 负责在真实服务器或背板环境里做热插拔、电源扰动和长时间功耗/边带记录。这才是企业级 Gen6 SSD 从研发、验证、debug 到预认证更完整的工具链。十一、给 SSD 工程师的选型建议如果只是做普通客户端 SSD 性能验证，可能桌面型 DT 系列就能满足一部分需求。如果是做 PCIe Gen5 企业级 SSD，RM5/DT5 加上相应 riser、SBCert、OCP/NVMe 脚本会比较合适。如果已经开始规划 PCIe 6.0 企业级 NVMe SSD，尤其是 EDSFF、U.2/U.3、Dual Port、OCP DSSD、FDP、SR-IOV、SPDM、NVMe-MI 等方向，RM6 就应该优先进入评估。如果团队经常遇到热插拔、掉电、复位、低功耗、边带信号、偶发掉盘、链路恢复等问题，iRiser-6 或 iRiser6SE 的价值会非常明显。区别在于，iRiser-6 支持 PCIe lane control / glitching，而 iRiser6SE 不支持这部分能力。如果产品面向云厂商或海外认证市场，还需要重点评估 OCP、UNH-IOL、NVMe Integrator’s List、IOL INTERACT 等流程。UNH-IOL 的公开资料已经说明，IOL INTERACT 与 SanBlaze RM5/DT5 兼容并授权使用，OCP NVMe 测试中也使用 SanBlaze工具。十二、总结：SanBlaze 测的不是“SSD 能不能跑”，而是“SSD 能不能进真实客户环境”今天的 NVMe SSD，特别是企业级 PCIe 5.0/6.0 SSD，已经不是单纯的存储外设。它要面对云平台、AI 服务器、OCP 规范、NVMe 认证、低功耗约束、热管理、虚拟化、多租户、安全认证、固件升级、异常恢复和真实背板环境。所以，测试也必须从“跑一下性能”升级为“系统化验证”。SanBlaze 的核心价值，正是在这里：RM6 提供面向 PCIe 6.0 NVMe SSD 的系统化研发测试平台； SBCert 提供大量预封装测试脚本和报告体系； NVMe-MI、ZNS、SRIS、TCG、SPDM、FDP、OCP DSSD、SR-IOV 等 license 功能覆盖企业级 SSD 的关键新特性； iRiser-6 则把电源、复位、边带信号和 PCIe lane glitch 这些难以手工控制的异常场景变成可重复测试。对第一次接触 SSD 测试的工程师来说，可以把 SanBlaze 理解成一个“可编程的 NVMe SSD 研发实验室”。它不是只告诉你这块盘能跑多快，而是帮你回答更难的问题：这块盘在复杂协议下是否合规？ 在异常电源和复位下是否可靠？ 在 OCP/云厂商规范下是否过关？ 在 Gen6 高速链路里是否稳定？ 在客户现场出问题前，能不能先在实验室把问题逼出来？这才是 Gen6 SSD 测试真正要解决的事情。更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

今天早上，一个潜在用户问了一个很典型、也很“工程现场”的问题：我们想通过一台 server，扩展 16 张 NVIDIA RTX5060 GPU 卡，每张卡是 PCIe Gen5 x8，有没有比较现实、可落地的方案？这个问题乍一听有点夸张。因为普通服务器主板上就算有几个 PCIe x16 插槽，也很难直接插 16 张 GPU。更不用说 16 张卡的物理空间、供电、散热、线缆、链路训练、BIOS 枚举、驱动识别，每一个环节都可能让工程师卡半天。但如果从 PCIe lane 资源的角度重新看这个问题，它反而变得很清楚：RTX5060 这类卡电气链路是 PCIe Gen5 x8。也就是说，一张卡真正需要的是 8 条 PCIe lane，而不是完整 x16。16 张 RTX5060：16 × x8 = 128 lanes如果再给上行连接主机预留一个 Gen5 x16：128 lanes + 16 lanes = 144 lanes这个数字非常巧，刚好等于 Broadcom PEX89144 PCIe 5.0 Switch 芯片的 144 lane 总资源。也就是说，这不是“硬凑出来”的方案，而是 lane 资源刚好对得上的方案。一、先把问题说简单：为什么普通主板做不了？很多初级工程师刚接触 PCIe 扩展时，容易把 PCIe switch、PCIe bifurcation、riser cable、转接卡混在一起。我们先用最直白的话讲清楚。普通服务器主板上的 PCIe slot，本质上是 CPU 或 chipset 给出来的 PCIe 资源。比如一个 PCIe Gen5 x16 slot，就只有 16 条 lane。主板最多可以通过 bifurcation 把它拆成：x8 + x8 或者 x4 + x4 + x4 + x4但它不能凭空变成 16 个 x8。一个 x16 插槽，直接拆，最多只能拆出 2 个 x8。你想挂 16 张 x8 GPU，需要的是 128 条下行 lane。这个时候，就不能靠简单转接线或者被动 riser 解决了，而是需要一个真正的 PCIe switch。PCIe switch 可以理解成 PCIe 世界里的“高速交换机”。它一端连接主机，另一端连接很多 endpoint，比如 GPU、SSD、NIC、DPU、FPGA 加速卡。主机看到的是 switch 后面挂了一串设备；switch 负责在这些设备和主机之间转发 PCIe TLP 数据包，并完成端口管理、链路训练、错误处理和拓扑组织。所以，这个方案的关键不是“把一根线拆成十六根线”，而是通过 PEX89144 这颗 144 lane PCIe Gen5 switch，把一台主机的 PCIe 拓扑扩展成一个高密度、多端口的外部 GPU 测试平台。二、这块 144 Lane Switch 板的资源为什么刚好合适？我们之前介绍过这块基于 Broadcom PEX89144 的 PCIe 5.0 switch 扩展板。它的核心配置可以简单理解为：核心芯片：Broadcom PEX89144 总 lane 数：144 lanes 板上接口：18 个 MCIO x8 接口速率：PCIe Gen5 每两个 MCIO x8 可以组合成一组 x16 18 个 MCIO x8 等价于 9 组 x16这张板有一个很重要的特点：它没有把 PEX89144 的 lane 资源浪费掉，而是通过 18 个 MCIO x8 接口把 144 lanes 尽可能完整地释放出来。这对于测试实验室来说非常有价值。因为在真实的研发验证场景里，我们经常不是只想插一张卡，而是想模拟复杂系统：多 GPU 多 SSD GPU + SSD 混插 GPU + NIC 混插 多 endpoint 同时枚举 某个端口异常时观察其它端口是否受影响 某条链路降速时定位是主机、switch、线缆还是 endpoint 的问题这类问题，在普通 PC 主板上很难做。在高端服务器里做，又经常被机箱结构、主板 BIOS、线缆长度、散热空间限制住。而这块 144 lane switch 板的价值，就是把原本藏在服务器内部的 PCIe fabric，拉到桌面上，变成一个可以搭、可以拆、可以改、可以测的工程平台。三、这次客户需求的拓扑：2 个 MCIO x8 做上行，16 个 MCIO x8 做下行针对这位客户提出的 16 张 RTX5060 GPU 扩展需求，我们建议采用下面的连接方式：Server PCIe Gen5 x16 slot ↓ Uplink Adapter ↓ 2 条 MCIO x8 cable ↓ PEX89144 144 Lane PCIe Gen5 Switch Board ↓ 16 个 MCIO x8 downlink ↓ 16 张 Downlink Adapter，转成 PCIe x16 机械插槽 ↓ 16 张 NVIDIA RTX5060 GPU从 lane 分配上看：用途接口数量Lane 数量说明上行连接 server2 × MCIO x816 lanes组成一个 Gen5 x16 uplink下行连接 GPU16 × MCIO x8128 lanes每张 RTX5060 占用 Gen5 x8总计18 × MCIO x8144 lanesPEX89144 lane 资源全部用满这就是这个方案最漂亮的地方：18 个 MCIO x8，一个不多，一个不少。2 个做 uplink，16 个做 downlink。 上行 x16，下行 16 个 x8。 144 lanes 刚好全部用完。从工程角度看，这种拓扑非常干净，也非常适合向客户解释。四、不要把它理解成“16 张卡都各自拥有直通 CPU 的 x8 带宽”这里需要特别提醒一句，也是很多客户第一次看这种方案时最容易误解的地方。这套方案可以扩展 16 张 Gen5 x8 GPU，但它并不等于服务器 CPU 同时拥有 16 组独立 Gen5 x8 直连链路。原因很简单：下行总资源是 16 × x8 = 128 lanes 但是上行回到主机的是 x16，也就是 16 lanes如果 16 张 GPU 同时向 CPU 大规模搬运数据，那么最终都会经过这条 x16 uplink。这个时候，上行链路就会成为汇聚点。所以我们要把应用场景分清楚。这套方案非常适合：多 GPU 枚举测试 多 GPU 驱动加载测试 多卡稳定性测试 GPU 批量烧机 CUDA / AI 推理环境搭建验证 多 endpoint PCIe 链路训练测试 Switch 端口压力测试 GPU 卡兼容性筛选 外置 PCIe 拓扑调试 GPU 与其它 PCIe 设备混插验证但如果客户的目标是让 16 张 GPU 同时满速和 CPU 内存之间做持续 DMA，并且每张卡都要求接近 Gen5 x8 的主机带宽，那就要明确告诉客户：这不是 16 路 CPU 直连 x8，它是一个通过 x16 uplink 汇聚的 switch 扩展拓扑。这不是缺点，而是 PCIe switch 拓扑设计中必须讲清楚的边界。工程沟通里，最怕的不是方案做不到，而是客户把方案理解错。五、为什么 RTX5060 这种 Gen5 x8 卡反而很适合这个平台？如果客户要扩的是 16 张 RTX5090、RTX6000 Pro 这类更高功耗、更高端的 GPU，事情会复杂很多。不是不能做，而是供电、散热、机械固定、驱动策略、实际 workload 都会变得更重。但 RTX5060 这种 PCIe Gen5 x8 形态，反而很适合拿来做多卡扩展和测试。原因有几个。第一，它每张卡只需要 x8 电气链路。 这使得 144 lane switch 可以挂到 16 张卡，而不是只能挂 8 张 x16 卡。第二，Gen5 x8 的单卡理论链路能力已经很高。 对于很多 AI 推理、轻量训练、视频处理、CUDA 测试、批量应用验证来说，GPU 不是每一秒都在疯狂和 CPU 搬运数据。很多时候，数据加载完成以后，主要计算发生在 GPU 本地显存里。第三，多卡数量本身有测试价值。 很多问题不是单卡能暴露出来的。比如：第 1 张卡能识别，第 16 张卡还能不能识别？ 单卡跑没问题，16 张一起加载驱动有没有问题？ 热启动后设备顺序是否变化？ Linux 下 lspci 拓扑是否稳定？ nvidia-smi 是否能稳定看到所有 GPU？ 某一张卡 link retrain，会不会影响 switch 其它端口？ 某一张卡掉线，系统是冻结、报错，还是只隔离该端口？ 多张卡同时跑压力时，AER 计数是否增加？ 端口是否出现降速、降宽、链路不稳定？这些问题都不是“买一台普通 PC 插一张显卡”能验证出来的。六、这套连接方式的实际落地细节从外观上看，这套系统可能是这样的：主机服务器里插一张 uplink adapter。 这张 uplink adapter 通过 PCIe x16 金手指插入 server 的 PCIe Gen5 x16 slot。 然后从 uplink adapter 引出 2 根 MCIO x8 cable，连接到 PEX89144 switch 板的 2 个 MCIO x8 接口，形成一个 Gen5 x16 uplink。Switch 板剩下 16 个 MCIO x8 接口，分别连接 16 张 downlink adapter。 每张 downlink adapter 把 MCIO x8 转成 PCIe x16 机械插槽。 RTX5060 GPU 插在这些 PCIe 插槽里，虽然物理是 x16 插槽，但实际跑的是 Gen5 x8 链路。这里有几个工程细节一定要提前确认。第一，GPU 供电不能靠 MCIO 线缆想当然解决。 GPU 插槽的 12V 供电、辅助电源、转接板供电，都要单独设计清楚。尤其是 16 张卡同时上电，瞬态电流和电源时序不能随便糊弄。第二，散热必须提前规划。 16 张 GPU 就算不是顶级高功耗卡，也不是随便摊在桌子上就能长期稳定跑。开放式测试架、风道、风扇、温度监控，都要纳入方案。第三，线缆长度和信号完整性要谨慎。 PCIe Gen5 是 32GT/s，不是低速 GPIO。MCIO 线缆、adapter、连接器、走线、retimer 是否需要介入，都要看实际链路裕量。能枚举不代表长期压力下稳定；能跑 Gen5 不代表每次热启动都稳定。第四，server BIOS 必须配合。 建议重点检查：Above 4G Decoding Resizable BAR PCIe speed 固定 Gen5 或 Auto 策略 MMIO 资源分配 IOMMU/VT-d 设置 SR-IOV 或相关虚拟化选项 热插拔相关选项 系统启动时的 PCIe 枚举顺序很多多 GPU 问题，最后不是硬件坏了，而是 BIOS 没给足资源，或者系统在大规模 PCIe BAR 分配时出问题。第五，驱动和操作系统要提前验证。 硬件层面能枚举，只是第一步。后面还要确认：Linux 下 lspci 是否看到全部 GPU 每张卡的 LnkSta 是否是 Speed 32GT/s、Width x8 nvidia-smi 是否稳定识别全部 GPU CUDA sample 是否能遍历全部 device 多卡压力测试是否会触发 Xid error 重启、冷启动、热启动后设备顺序是否稳定 长时间运行后是否有 AER、DPC、Surprise Down 记录这些都是实际客户项目里非常关键的验收项。七、这块板不是“插槽扩展器”，而是一个 PCIe 拓扑实验平台如果只把它理解成“多插槽扩展板”，就低估了它的价值。真正有意思的地方在于，PEX89144 这类 PCIe switch 可以构建复杂的 PCIe 拓扑。对于测试工程师来说，它不是简单地把一个插槽变成很多插槽，而是把整个 PCIe fabric 变成了一个可观察、可控制、可调试的实验环境。比如在这次 16 张 RTX5060 的方案里，我们至少可以做这些测试：1. 多 GPU 枚举与资源分配测试16 张 GPU 同时挂在一个 switch 后面，系统能不能稳定识别？ BIOS 能不能分配足够 MMIO？ 操作系统启动过程中有没有卡住？ GPU 的 bus number、device number 是否稳定？ 不同 server 平台之间表现是否一致？这类测试对客户非常有实际价值。因为很多真实项目的问题，根本不是单张卡性能不够，而是系统级资源分配、枚举、驱动初始化阶段就出问题。2. PCIe Gen5 x8 链路训练测试每张 GPU 都要经过：GPU downlink adapter MCIO cable PEX89144 switch port uplink adapter server root complex链路训练涉及 Tx/Rx equalization、preset、信号完整性、时钟、retimer 或 connector 质量等多个因素。如果 16 张卡里有一张只能跑 Gen4，或者只能跑 x4，或者偶发降速，这时候 switch 平台就能帮助工程师快速定位：是某张 GPU 的问题？ 是某根 MCIO 线缆的问题？ 是某张 downlink adapter 的问题？ 是 switch 某个端口的问题？ 是 server BIOS 或 root port 的问题？ 还是信号裕量本来就不够？这就是测试平台的意义。它不是为了让你“感觉能插上”，而是为了让你知道问题到底出在哪里。3. 多卡压力与稳定性测试16 张 GPU 同时运行压力程序，和一张 GPU 单独运行，是完全不同的系统状态。多卡同时运行时，会出现：更高的瞬态功耗 更高的系统温度 更复杂的 PCIe traffic 更多的中断和 DMA 访问 更复杂的驱动调度 更高概率暴露边缘链路问题这类问题经常不是一分钟出现，而是几个小时甚至几十个小时后才出现。比如：某张卡突然掉线 nvidia-smi 卡住 系统 dmesg 出现 AER 某个 PCIe port Surprise Down GPU driver 出现 Xid error 重启后少识别一张卡 某条链路从 Gen5 退到 Gen4 某个 adapter 摸起来明显过热这些都属于典型的系统级验证问题。如果没有这样一套可重复搭建的 PCIe switch 测试平台，很多问题只能靠猜。4. GPU 与其它 PCIe 设备混插测试今天客户问的是 16 张 RTX5060，但这块 144 lane switch 板并不只能挂 GPU。它也可以挂：Gen5 SSD NVMe JBOF 高性能 NIC DPU FPGA 协议分析仪 故障注入卡 Retimer/Redriver 测试板 客户自己的 endpoint EVB这就很适合做混插场景。比如：8 张 GPU + 8 块 Gen5 SSD 12 张 GPU + 4 张 100G/200G NIC GPU + SSD 做数据流测试 GPU + DPU 做加速与网络转发测试 GPU + 自研 PCIe endpoint 做兼容性验证很多 AI 服务器、存储服务器、加速卡系统，并不是单一设备工作，而是 GPU、NIC、SSD、DPU 在一个复杂拓扑里共同工作。实验室如果想提前模拟这种环境，一块高密度 switch board 就很有价值。八、这个方案最适合什么客户？这套 16 张 RTX5060 扩展方案，不一定适合所有人。如果客户只是玩游戏、做普通图形渲染、想让 16 张消费级显卡像一台高端 AI 训练服务器那样工作，那这个方案可能不是最优解。但如果客户是下面几类团队，就非常值得认真评估：GPU 板卡测试团队 AI 推理平台研发团队 服务器系统集成团队 PCIe endpoint 芯片验证团队 GPU 兼容性测试实验室 多卡驱动与软件栈验证团队 高校或研究机构的异构计算实验室 需要低成本构建多 GPU 原型平台的工程团队 做 PCIe Gen5 链路、拓扑、压力、故障定位的团队尤其是那些“不一定要追求每张 GPU 都有满血 CPU 直连带宽，但非常需要多卡数量、多端口拓扑、多设备稳定性验证”的客户，这套方案就非常有价值。一句话总结：它不是为了替代顶级 GPU 训练服务器，而是为了在实验室里快速搭出一个多 GPU PCIe Gen5 验证环境。九、真正的价值：把复杂 PCIe 系统提前搬到桌面上很多客户的问题，表面上看是“我想多接几张卡”。但深层需求其实是：我想知道我的 server 能不能识别这么多设备。 我想知道我的 GPU 在 Gen5 x8 下是否稳定。 我想知道我的线缆和 adapter 有没有问题。 我想知道 switch 后面挂满设备以后系统会不会乱。 我想知道某个端口异常，会不会把整台机器拖死。 我想知道多卡系统的真实边界在哪里。这些问题，靠纸面规格回答不了，靠普通主板也很难验证。PEX89144 144 lane PCIe 5.0 switch 扩展板的意义，就是让这些问题可以被真实搭建、真实连接、真实运行、真实测出来。这也是为什么我们一直说，这块板不是一个简单的“PCIe 扩展板”，而是一个 PCIe Gen5 拓扑实验平台。它可以把一台服务器的 PCIe x16 uplink，扩展成 16 个 Gen5 x8 downlink；也可以根据 firmware 和端口配置，构建不同的上行、下行、多主机、混合 endpoint 拓扑。对于研发验证工程师来说，这种灵活性非常重要。因为真实项目里，最麻烦的问题往往不是标准答案，而是各种“不知道为什么就是不稳定”的边缘问题。十、回到今天这个客户问题：16 张 RTX5060，怎么接？我们最终给客户的建议可以概括成一句话：使用 PEX89144 144 lane PCIe 5.0 switch 扩展板，采用 2 个 MCIO x8 作为 uplink，通过 uplink adapter 连接 server 的 PCIe Gen5 x16 slot；剩余 16 个 MCIO x8 作为 downlink，每一路通过 downlink adapter 转成 PCIe 插槽，用于连接 16 张 RTX5060 GPU，每张 GPU 以 PCIe Gen5 x8 方式工作。这个方案的 lane 分配非常清晰：2 个 MCIO x8 = 1 个 x16 uplink 16 个 MCIO x8 = 16 个 x8 downlink 合计 18 个 MCIO x8 刚好使用 144 lanes从工程角度看，这就是一个非常漂亮的 PCIe Gen5 多 GPU 扩展案例。它把 PEX89144 的 144 lane 能力真正用满，也把 MCIO x8 接口的灵活性体现得非常充分。更重要的是，它把“PCIe switch 到底能干什么”这件事讲得非常直观：它不是让一台普通服务器凭空变成魔法机器。 它是让工程师可以在可控的平台上，构建真实、复杂、高密度的 PCIe Gen5 拓扑。 然后把多 GPU、多 endpoint、多线缆、多 adapter、多端口异常这些问题，在实验室里提前暴露出来、定位出来、解决掉。对于真正做研发、验证、测试、系统集成的人来说，这就是它最大的价值。因为在高速 PCIe 系统里，最贵的不是一块板卡，也不是一根线缆。最贵的是问题发生以后，你不知道它到底从哪里来。而一块好的 PCIe switch 测试平台，就是为了让这些问题不再靠猜。更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。