EC2 Graviton Windows 11 ARM inbox StorNVMe 驱动 IO 性能验证
Graviton 上 DD 安装的 Windows 11 ARM 用的是微软 inbox StorNVMe.sys，而不是 AWS 官方 AWSNVMe.sys。这个 inbox 驱动会不会成为 IO 瓶颈？本文用 diskspd 做了完整的 IOPS 和吞吐测试，把瓶颈锁定在实例侧。
测试环境
| 项目 | 配置 |
|---|---|
| 实例类型 | t4g.large（2 vCPU / 8 GB，Graviton2） |
| 系统 | Windows 11 Pro 25H2 ARM64（Build 26200） |
| NVMe 驱动 | Microsoft stornvme.inf（inbox，10.0.26100.8521） |
| 系统盘 | 50 GB gp3（3,000 IOPS / 125 MB/s） |
| 测试盘 | 100 GB gp3（16,000 IOPS / 1,000 MB/s） |
| 测试工具 | diskspd 2.1（ARM64 原生版） |
t4g.large 实例级 EBS 突发上限：带宽 2,780 Mbps（≈347 MB/s），IOPS 11,800。测试盘配置远超实例上限，确保瓶颈在实例侧而非 EBS 卷侧。
驱动确认
DeviceName : Standard NVM Express Controller
DriverVersion : 10.0.26100.8521
InfName : stornvme.inf两个 NVMe 控制器（系统盘 + 测试盘）均由 inbox StorNVMe 驱动，无 AWS 官方驱动参与。
测试结果
IOPS
| 场景 | 总 IOPS | 平均延迟 | P99 延迟 | CPU% |
|---|---|---|---|---|
| 随机 4K 纯读 | 15,696 | 8.15 ms | 12.86 ms | 51% |
| 随机 4K 纯写 | 15,699 | 8.15 ms | 9.03 ms | 48% |
| 随机 4K 混合(7:3) | 15,697（读 11,000 + 写 4,697） | 8.15 ms | 10.10 ms | 46% |
吞吐
| 场景 | 吞吐(MB/s) | 平均延迟 | P99 延迟 | CPU% |
|---|---|---|---|---|
| 顺序 128K 读（QD=4） | 331.19 | 6.04 ms | 7.67 ms | 12% |
| 顺序 128K 写（QD=4） | 154.85 | 12.91 ms | 20.46 ms | 16% |
| 顺序 1M 读（QD=4） | 331.38 | 48.28 ms | 70.14 ms | 6% |
| 顺序 128K 写（QD=16） | 331.37 | 24.14 ms | 33.20 ms | 14% |
测试期间 CloudWatch 监控：EBSIOBalance% 最低 94%，EBSByteBalance% 最低 93%，burst credit 充足，测试反映的是稳态性能。
分析
IOPS 超过文档标称的 11,800？
实测达到 ~15,700 而非被限制在 11,800，原因是 t4g.large 的 EBS 性能规格是 "up to 11,800 IOPS"（突发上限）。在 burst credit 充足时实例可以短时间超出标称值。关键是 StorNVMe 驱动没有成为额外限制——如果驱动有性能问题，即使不限流也跑不到这个数。
写吞吐：QD=4 时 155 MB/s，QD=16 时 331 MB/s
顺序写在低队列深度下只跑到 155 MB/s，而读在同样 QD=4 下就能跑到 331 MB/s。原因是 EBS 写延迟（13ms）比读延迟（6ms）高一倍，单个 IO 完成时间更长，相同队列深度下能维持的并发 IO 数更少。
增大队列深度到 16 后，写吞吐也达到 331 MB/s，与读持平，打满实例带宽上限。这是 EBS 写路径的延迟特性，和驱动无关。
CPU 开销
IOPS 测试时 CPU 占用 46-51%（2 vCPU），主要消耗在内核态 IO 处理（Kernel 占 40-50%）。吞吐测试时 CPU 占用仅 6-16%。StorNVMe 驱动在高 IOPS 负载下的 CPU 消耗合理，没有异常高的软件模拟开销。
测试命令
# 随机 4K 纯读 - 测 IOPS 上限
diskspd.exe -b4K -r -o32 -t4 -w0 -d60 -Sh -L -c10G D:\testfile.dat
# 随机 4K 纯写 - 测 IOPS 上限
diskspd.exe -b4K -r -o32 -t4 -w100 -d60 -Sh -L -c10G D:\testfile.dat
# 顺序 128K 读 - 测吞吐上限
diskspd.exe -b128K -si -o4 -t4 -w0 -d60 -Sh -L -c10G D:\testfile.dat
# 顺序 128K 写 - 高队列深度
diskspd.exe -b128K -si -o16 -t4 -w100 -d60 -Sh -L -c10G D:\testfile.dat参数说明：-b 块大小、-r 随机 / -si 顺序交错、-o 队列深度、-t4 4 线程、-w 写比例、-d60 60 秒、-Sh 禁用缓存、-L 记录延迟、-c10G 创建 10 GB 测试文件。
结论
inbox StorNVMe 驱动在 EC2 Graviton2 + Windows 11 ARM 上不构成 IO 性能瓶颈：
- IOPS 达到 ~15,700，超过实例文档标称的突发上限
- 吞吐达到 331 MB/s（实例上限 347 MB/s 的 95.4%）
- 读写均能打满实例带宽（写需要更高队列深度补偿延迟）
- CPU 开销正常，无驱动层额外损耗
- 无需安装 AWS 官方 NVMe 驱动（实测安装反而导致启动失败）