我们一般的人认为针对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.0SanBlaze RM6 是最值得重点关注的产品。SanBlaze 在 Gen6 NVMe SSD 测试页面中把 RM6 定位为面向 PCIe Gen6 NVMe SSD 的 Rackmount 测试平台并强调它是 16-bay 企业级 NVMe 测试设备支持 PCIe Gen1 到 Gen6。这个“Gen1 到 Gen6”很关键。企业级 SSD 厂商不会突然只做 Gen6Gen4、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-6Gen6 SSD 测试里最容易被低估的一张卡如果说 RM6 负责“系统化测试”那么 iRiser-6 负责把很多真实环境中的异常变成可控测试。SanBlaze 的 iRiser Family Guide 里列出iRiser6 是 PCIe Gen6 iRiser兼容 RM5 和 RM6支持 PCIe lane control / glitchingiRiser6SE 则是不带 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 InterfaceNVMe-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 功能为什么重要我们在白皮书《PCIe56.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 SSDUNH-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。除了 SanBlazeUNH-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 企业级 SSDRM5/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 测试真正要解决的事情。