每條命令只有不到一微秒
NVMe 規範允許最多 65535 對 SQ/CQ，但一塊盤實際能用滿多少佇列，取決於主控內部有幾條彼此獨立的命令處理流水線。CORE 7 系列的 J750 與 J770 走 PCIe 4.0 x4 鏈路，4KB 隨機讀的規劃目標是 1,500 KIOPS，平均下來每條命令的端到端處理預算不足 0.7 µs。在這個尺度上，任何跨核共享的資源——一把 FTL 映射表的鎖、一段被多核輪詢的完成佇列記憶體——都會直接變成吞吐天花板，而不是可以留到後期調優的細節。
三個真正的開銷點
第一個是 doorbell。主機每提交一批命令都要寫一次 doorbell 暫存器，高 IOPS 下這些 MMIO 寫會佔用上行事務，韌體側必須按批讀取 SQ 條目而不是逐條響應。第二個是映射表訪問的局部性，隨機負載的 LBA 分佈決定映射頁命中率，綁核策略若把相鄰 LBA 分散到不同核，快取局部性就被打散。第三個是完成路徑：中斷聚合能顯著降低主機 CPU 的中斷次數，但每一次聚合都在等待窗口裡累加延遲。
QD1 延遲與高佇列深度吞吐的對立
J750/J770 規劃的 QD1 平均延遲指標是讀 65 µs、寫 10 µs，寫側的數字來自掉電保護支撐下的回寫快取。這組數字只有在聚合窗口接近關閉時才成立。工程上不追求單一配置通吃：後設資料與日誌這類延遲敏感負載用極短窗口，而順序讀 7,400 MB/s、順序寫 5,500 MB/s 的頻寬型負載允許更激進的聚合。韌體把兩種模式做成執行時可切換的 QoS 檔位，而不是編譯期常量。
當前驗證狀態
排程相關測試跑在內部工程平臺 JH-E4U-C 上，兩款產品仍處於產品定義/EVT 階段，上面這些數字都是規劃目標而非實測承諾。當前重點是把佇列數、綁核方式與聚合窗口三者做成正交的可配置項，使不同伺服器平臺上的實測結果能夠直接回灌到預設參數表，而不必每次改動韌體重新編譯。