写比读快，是因为确认点不同
J750/J770 的规划指标里，QD1 平均 4KB 随机写为 10 µs，随机读为 65 µs。在同一颗 3D 企业级 TLC 上，编程时间远长于读取时间，写却反而更快，唯一的原因是两者的完成时刻定义不同：读必须等数据真正从阵列取出、解码完成才能投递完成项；写只需要把数据放进受掉电保护的写缓冲、把对应的映射变更登记下来，就可以立即返回。NAND 的实际编程发生在这之后，它决定的是稳态带宽和后台压力，并不出现在这条延迟路径上。这两个数字目前是产品定义/EVT 阶段的设计目标，在内部工程平台 JH-E4U-C 上作为回归基线逐版比对。
确认过的数据是一笔必须兑现的债
提前确认的前提，是断电之后仍然兑现得了。写缓冲中已确认但尚未编程的数据，连同尚未落盘的映射变更，都必须由板载储能支撑着完成写入。这条约束的方向是单向的：可用能量决定能兑现多少，能兑现多少才决定缓冲能开多大。缓冲越大，突发写表现越好，但断电瞬间需要刷写的数据量与元数据量同步上升。J750/J770 规划的 18 W 典型、22 W 最大、6 W 空闲，是这套机制连同前台性能一起必须落进去的整体边界。
Flush 与 FUA 会把确认点推回介质侧
10 µs 只在主机允许易失写缓存生效时成立。当应用下发 Flush，或对单条命令置上 FUA 位，NVMe 的语义要求数据在完成之前抵达非易失介质，此时的延迟量级由编程时间决定，与 10 µs 不在同一个数量级。数据库日志、文件系统日志以及虚拟化层的写屏障都会大量使用这两种语义。所以评估写延迟必须先说明负载是否带 Flush/FUA，否则两份报告之间没有可比性。固件侧能做的是让一次 Flush 只等待真正需要持久化的那部分，而不是无差别地清空整个缓冲。
同样的 10 µs，不同的稳态
J750 与 J770 的 QD1 写延迟目标相同，分化出现在深队列和稳态：4KB 随机写规划值 J750 为 300 KIOPS、J770 为 600 KIOPS，五年 DWPD 分别是 1 与 3。队列一深，命令在确认点之前就开始排队，垃圾回收与主机写争用同一批通道，延迟分布的尾部随之被拉长。更高的耐久预算允许更激进的前台优先调度，代价是写放大上升；耐久预算更紧的型号只能把调度做得保守。这也是写延迟必须在近满盘、叠加持续写流量的条件下取值的原因——空盘上测出来的 10 µs 没有参考价值。