一次近邻查询是几十次串行读
当向量集合超出内存容量，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 可以把每一轮采集留档，让复现与归因不依赖单次跑分。