三段负载的形状完全不同
训练流水线上至少存在三种截然不同的访问模式。样本加载是海量小对象的随机读，每个 epoch 重新打乱顺序，几乎没有局部性；检查点写入是周期性的顺序大块写，写完立刻沉寂；推理侧的 KV Cache 换入换出则是延迟敏感的小粒度读写，对尾延迟的容忍度远低于前两者。用一种规格覆盖全部，必然在某一段上付出不必要的成本。下文引用的规格均为产品定义/EVT 阶段的规划目标值，型号名已固定，容量与配置通过 SKU 管理。
样本加载：IOPS 与延迟决定 GPU 空转比例
DataLoader 的工作线程拿不到下一批样本，GPU 就在空转。这一段的瓶颈通常不是带宽而是 IOPS 与响应时间——图像或音频样本往往只有几十到几百 KB，顺序带宽再高也帮不上忙。CORE 7 的 J750、J770 规划 4KB 随机读 1,500 KIOPS、QD1 平均读延迟 65 µs，对应的正是这类负载。整条产品线规划的最高顺序读 14,500 MB/s 是另一回事，它服务的是大文件流式读取与数据集预热。
检查点：单位比特成本优先
大模型检查点单次落盘量可达数百 GB，写完之后长期只读、极少访问。把这类数据放在高耐久 TLC 盘上是浪费。Q9 系列的 J960Q、J960QD 以 Gen5 QLC 面向 AI 检查点与超大容量阵列，写入以顺序大块为主，恰好避开了 QLC 最不擅长的随机小写。产品线整体的单盘容量上限规划到 122.88TB，容量密度换回的正是单位比特成本的下降。
KV Cache：尾延迟与耐久优先
推理服务把注意力键值缓存下沉到 SSD 之后，一次慢速读会直接体现为 token 输出的卡顿，而缓存条目的频繁覆写又对耐久提出要求。X9 系列的 J990X、J995X 按 Gen5 超低延迟高耐久定位，服务的正是 KV Cache 与实时数据库场景。产品线整体的写入耐久上限规划到 120 DWPD，这是产品线的边界值；具体型号落在哪一档由该型号的规格与 SKU 定义，选型时必须按型号核对，不能拿产品线边界值去推断。
选型的实际含义
同一个训练集群里，这三段理想情况下由三类盘分别承担：随机读密集层放高性能 TLC 盘，冷检查点层放大容量 QLC 盘，缓存层放低延迟高耐久盘。真正的判据是每一段最先撞上的那堵墙——空转的 GPU、每 TB 的成本，还是 P99 的读延迟。