為什麼 AI 工作負載會重新定義儲存問題
AI 基礎設施的瓶頸並不固定在 GPU、CPU 或 SSD 的某一個部件上，而常常出現在資料抵達計算資源之前的整條路徑：資料集讀取、解壓與預處理、快取命中、網路傳輸、檔案系統排程，以及最終的訓練檢查點寫入。因而，採購清單中的“最高順序讀取速度”只能說明單一條件下的能力，不能直接等同於真實訓練吞吐或推理響應時間。
NVMe 是為非易失性儲存而設計的協議，支援多佇列和並行命令處理；NVM Express 也將較低延遲、更高 IOPS 與資料中心擴展能力列為其主要價值。 這意味著在需要大量併發小 I/O 的場景，佇列深度、軟體棧與服務質量往往和峰值頻寬一樣重要。
先把資料路徑拆成四類，而不是用一個規格覆蓋所有工作負載
| 資料路徑 | 典型特徵 | 選型關注點 |
|---|---|---|
| 資料集準備與預處理 | 大檔案與小檔案並存，讀取模式會隨框架改變 | 併發讀取、檔案系統、CPU 解壓能力、快取策略 |
| 訓練檢查點 | 週期性大量寫入，恢復時有讀取高峰 | 持續寫入效能、DWPD、寫放大、掉電保護與恢復流程 |
| 推理與檢索 | 更重視響應尾部而非平均值 | 延遲分位數、QoS、容量規劃、熱資料命中率 |
| 日誌與運維資料 | 寫入持續、保留策略明確 | 耐久度、隔離、監控告警、分層與歸檔策略 |
把這四類路徑分別量化後，企業才能判斷應使用本地 NVMe、共享儲存、快取層還是物件儲存；也能避免由某一種“全能型”規格承擔互相沖突的讀寫需求。
企業級評估應關注哪些指標
第一，明確測試資料集和 I/O 模式。隨機與順序、讀寫比例、塊大小和佇列深度都會改變結果；脫離這些條件比較 IOPS，結論沒有可遷移性。第二，要求觀察穩定階段而非僅看空盤峰值。第三，把容量利用率、預留空間、散熱邊界和韌體版本記錄在驗證報告中。最後，為檢查點和生產推理預留故障恢復演練，包括單盤失效、節點重啟和異常掉電後的恢復時間。
從“單盤效能”轉向“單位工作負載的可預測性”
對大多數團隊而言，更實用的目標不是追求某項單點跑分，而是在既定資料集、併發使用者數和恢復目標下得到可復現的吞吐與延遲。建議在小規模試點階段收集 I/O 追蹤資料，再用接近生產的伺服器、作業系統、驅動與檔案系統進行驗證。這樣得到的結論，才可以用於容量、耐久度和預算之間的取捨。