三段負載的形狀完全不同
訓練流水線上至少存在三種截然不同的訪問模式。樣本載入是海量小物件的隨機讀，每個 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 的讀延遲。