寫比讀快，是因為確認點不同
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 沒有參考價值。