一次近鄰查詢是幾十次序列讀
當向量集合超出記憶體容量，HNSW 這類圖索引的鄰居列表必須放到 SSD 上。一次近鄰查詢沿圖走幾十跳，每跳讀一個鄰居塊，跳與跳之間存在嚴格依賴——上一跳的結果決定下一跳讀哪裡。佇列深度因此天然很淺，常常就是 QD1 到 QD4，塊大小落在 4KB 到 16KB 之間。頻寬在這裡幾乎派不上用場：查詢延遲等於單次讀響應時間乘以跳數，中間沒有任何可以並行掉的部分。
規格表上該看哪一行
同一份規格表上，4KB 隨機讀 1,500 KIOPS 與 QD1 平均讀延遲 65 µs 描述的是兩件事。前者是併發能力，回答的是這塊盤同時能扛住多少條查詢；後者才是單條查詢的延遲基數，序列鏈路只吃後者。更麻煩的是線上服務按 P99 考核，而串聯結構會把尾部放大——三十跳裡任何一跳落在慢路徑上，整條查詢就慢，命中慢路徑的機率隨跳數累積。X9 系列的 J990X、J995X 按 Gen5 超低延遲高耐久定位，配合韌體側的低延遲 QoS 基線，目標正是把讀延遲分佈的右尾收窄，而不是把均值再壓低幾微秒。
構建期把耐久賬一次性花掉
索引構建階段的畫像幾乎完全相反：大批次順序寫與高併發隨機讀混合，持續數小時到數天，累計寫入量可達資料集本身的數倍，耐久消耗集中而劇烈。CORE 7 裡 J750 規劃 1 DWPD（5 年）、J770 規劃 3 DWPD，這個差別在需要頻繁重建索引的場景下會被放大到肉眼可見。按查詢期畫像選盤，構建期就會變成瓶頸或者耐久風險；同一套系統的兩個階段，最優配置本來就不是同一個。上述規格目前是工程規劃值，在內部工程平臺 JH-E4U-C 上按型號推進驗證。
怎麼測才算數
照搬通用基準會得出誤導性結論：把佇列深度壓到 32 去刷峰值 IOPS，測出來的數字與真實查詢路徑沒有關係。有意義的做法是固定 QD1 到 QD4，按 4KB 與 16KB 分別採集完整的延遲分佈，看 P99 與 P99.9 而不是平均值，並在後臺回收活躍、盤接近滿盤的狀態下重複一遍——這兩個條件在生產環境里長期成立，在空盤基準裡卻從不出現。Telemetry 可以把每一輪採集留檔，讓復現與歸因不依賴單次跑分。