一、先把誤讀拆掉

同一場會議上，NVIDIA 其實宣布了三件互相扣合的事：cuFile 開源、集結超過 40 家儲存與快閃廠商（DDN、KIOXIA、Micron 等）的 Storage-Next 標準化倡議，以及 SCADA（Scaled Accelerated Data Access）——一套讓 GPU 直接掌握儲存控制權的框架。第三件事才是今年真正的新東西，但它幾乎沒有出現在中文報導裡。

比較準確的說法是：AI 系統正在把「儲存」重新納入記憶體階層，而 MoE 模型的稀疏性，又讓這件事在同一個時間點變得特別合理。

這篇文章想做的，是把 HBM、DRAM、UMA、DMA、CXL、NVMe、GDS、Expert Streaming 這一堆看起來零散的名詞，放回同一條脈絡裡。

二、GPU 飢餓：為什麼 GPU 開始需要 Storage

現代 GPU 的算力已經誇張到有點不真實。但 GPU 最常見的限制，往往不是 Tensor Core 不夠多，而是資料餵不進來——業界稱之為 GPU Starvation，GPU 飢餓。一張數萬美元的加速卡停在那裡等資料，是整條 AI 產線上最貴的閒置。

所以 GPU 旁邊必須放 HBM。資料中心等級 GPU 的 HBM 頻寬已經進入數 TB/s 的量級。這不是因為 HBM 便宜，而是因為只有它能在極短的物理距離內提供這種頻寬。

但 HBM 有一個先天限制：容量小、單價高、而且擴不上去。當模型權重、activation、KV cache、optimizer state、checkpoint，加上動輒數 TB 的訓練資料全部加起來遠超過 HBM 時，下一層要放哪裡？

各層記憶體的大致量級（實際數字依世代與配置差異極大，此處僅供比較相對關係）：

層級	頻寬量級	延遲量級	角色
GPU HBM	數 TB/s	奈秒級	運算時直接使用
NVLink-C2C	900 GB/s 等級	—	CPU↔GPU 晶片間互聯
系統 DRAM	數十～數百 GB/s	數十～百奈秒	較大的工作集
NVMe SSD	數～十幾 GB/s	數十～數百微秒	巨大容量、冷資料

越往下：速度越慢、延遲越高，但容量越大、每 GB 成本越低。這是一條連續的斜坡，不是幾個互相取代的選項。

三、第一個要澄清的誤解：DRAM 比 SSD 快很多

討論到這裡，很多人會直覺地問：「那就多插一點 DRAM 不就好了？」這個直覺是對的，而且必須先把一件事講清楚——DRAM 的頻寬與延遲，都遠遠優於 NVMe SSD。

所以千萬不要把這件事理解成「SSD 比 DRAM 快，所以 NVIDIA 才要讓 GPU 直接讀 SSD」。恰恰相反。這根本不是「DRAM vs SSD」的對決，而是 DRAM + SSD。就像我們從來不會說「RAM 很快，所以不需要硬碟」，也不會說「硬碟很大，所以不需要 RAM」。

真正的問題從來不是速度，而是 容量 × 成本 × 功耗。如果一個工作負載需要幾 TB 的資料，全用 DRAM 當然跑得更快；但當資料規模繼續往數十 TB 走，記憶體通道數、插槽數、功耗與價格會同時變成牆。相對地，一台伺服器塞滿 NVMe 很容易，再往上還能用 NVMe-oF、RDMA 把容量延伸到整個儲存網路。

四、第二個誤解：GPU 與 DRAM 之間早就有更好的通道

另一個常見的簡化說法，是把傳統路徑畫成「GPU → CPU → DRAM → CPU → GPU」，然後說 CPU 要親自搬每一筆資料。這也不準確。DMA（Direct Memory Access）本來就是為了避免 CPU 親自搬資料而存在的技術，而且已經存在很多年。

更進一步，NVIDIA 在 Grace Hopper／Grace Blackwell 這類架構上，用 NVLink-C2C 把 CPU 與 GPU 直接連在同一塊基板上，雙向頻寬達到 900 GB/s 等級，讓 GPU 可以非常有效率地存取 CPU 端的大容量記憶體。這其實已經很接近「半統一記憶體」。

另一條路是 CXL。它建立在 PCIe 實體層之上，但引入更完整的記憶體語意與快取一致性機制，目標是讓 CPU、加速器與記憶體裝置之間形成更有彈性的記憶體資源池。不過這裡也要避免另一個誤解：CXL 不是「插上去就能把所有 DRAM 當 VRAM 用」的魔法。實際能做到什麼，仍然取決於 CPU、GPU、CXL 裝置、韌體、OS、驅動與整個平台拓撲。它比較像是下一代記憶體互聯的基礎設施，不是即插即用的擴充器。

所以結論是：NVIDIA 不是因為 DRAM 太慢才跑去找 SSD，而是因為 DRAM 再快，也有容量與成本的天花板。

五、那 Apple 的 UMA 不是更漂亮嗎

Apple Silicon 的 Unified Memory Architecture 證明了一件事：CPU 與 GPU 共用同一個記憶體池，可以省掉大量資料複製，對本地推理、影像與影片處理都非常有效率。於是問題很自然：既然 UMA 這麼好，為什麼資料中心不全部改成 UMA？

答案不是 UMA 不好，而是兩邊的戰場不同。Apple 可以針對單一 SoC、單一封裝、單一記憶體池做極致最佳化。但資料中心 AI 要同時面對的是：數十張到數千張 GPU、HBM 頻寬、GPU 之間的互聯、CPU 記憶體、網路、儲存、散熱、良率與成本。把超大容量記憶體全部封裝進單一晶片，在良率與可維護性上都是另一種代價。

所以未來比較可能的方向不是「UMA 打敗獨立 VRAM」，而是：不同記憶體層級之間的距離，正在持續縮短。NVLink-C2C 是把 DRAM 拉近 GPU；CXL 是把記憶體變成可調度資源；而 GDS，則是把 SSD 也拉進這條線。

六、GDS 與 cuFile 到底做了什麼

傳統 I/O 路徑的問題，不在於「CPU 要搬每個 byte」，而在於傳統 I/O 堆疊會產生系統記憶體中的 bounce buffer、額外的記憶體拷貝，以及作業系統與檔案系統的軟體開銷。當 GPU 同時發出大量並行請求時，這些開銷會直接變成延遲與 CPU 負載。

GPUDirect Storage（2021 年推出）要做的就是後者，而 cuFile 就是讓應用程式使用這條路徑的 API。程式透過 cuFileRead / cuFileWrite 明確要求資料直接進入 GPU 記憶體，真正的搬運則交給靠近 NVMe 或 NIC 的 DMA engine。

這裡有一個關鍵細節值得記住：GDS 拿掉的是「資料路徑」上的 CPU，但控制路徑仍然掛在 CPU 上。也就是說，過去仍然是 CPU 負責發出儲存請求、管理檔案系統、處理完成通知。

而這正是今年 FMS 上真正的新東西。

七、SCADA：把「控制權」也交給 GPU

SCADA（Scaled Accelerated Data Access）源自 NVIDIA 的 BaM 研究，它做的事情是把儲存控制本身搬到 GPU 上：GPU 自己產生儲存請求、自己處理完成事件，讓數十萬個操作同時在途中，把延遲壓到微秒等級。

為什麼這件事重要？因為傳統 CPU 主導的 I/O 路徑，在「大區塊、循序」的傳輸上其實還算堪用；真正會爆掉的，是每秒數百萬次、512-byte 等級的小型隨機 I/O。而這恰好就是 AI 推理在做 KV cache、context 檢索，以及後面會談到的 expert streaming 時，最常出現的存取型態。

順帶一提，NVIDIA 在會上也秀了 BlueField-4 STX 裡的 Vera CPU，在壓縮與加密這類兩階段任務上，內部測試相較 x86 CPU 有最高 3.21 倍的吞吐量。整條資料路徑上的每一段，現在都在被重新設計。

八、但 SSD 並沒有「變成 VRAM」

這一點必須說得非常清楚。NVMe SSD 與 HBM 的延遲和頻寬差距，是好幾個數量級。HBM 是 GPU 運算時直接使用的高速記憶體，SSD 是儲存裝置。cuFile 目前也更適合應用程式主動發起的、可預期的較大區塊傳輸，而不是把 SSD 當成 GPU 的透明 swap。

所以正確的理解是：GDS 不是「SSD = VRAM」，而是「GPU 可以更有效率地使用 SSD 裡的資料」。SSD 在這裡的身分，是資料階層裡更低、更大、更便宜的一層。

九、開源的戰略意義

為什麼 NVIDIA 願意把 cuFile 交給一個由 Google、Intel、Meta 共同維護的中立組織？因為 GPU 效能已經不是單純的 GPU 問題。今天的 AI 工廠是一整條鏈：GPU、HBM、CPU、DRAM、NVMe、檔案系統、NIC、RDMA、網路、儲存陣列——任何一環卡住，價值數萬美元的 GPU 就在那裡閒著。

NVIDIA 靠自己一家把這條鏈上的每個檔案系統、每張 SSD、每個 Linux 核心版本都調到最佳，是不可能的任務。開源之後，儲存廠商、檔案系統開發者、Linux 社群與 AI 框架作者可以一起最佳化這條路徑。代價是放掉介面的獨佔，換到的是整條資料鏈都朝著 GPU 的需求演化。

這是一個很典型的策略：當你在生態系裡已經是重心，開放介面通常會擴大你的重力範圍，而不是削弱它。

十、另一條路：讓模型主動住進 SSD

到目前為止談的都是 NVIDIA 的思路——讓資料搬得更快。但同一時間，還有另一條完全不同的路線正在成形，而它剛好搭上近年模型架構最大的變化之一：Mixture of Experts（MoE）。

傳統 Dense Model 有個很硬的限制：模型有多少參數，大致就代表要有多少參數常駐在高速記憶體。MoE 不一樣。以 DeepSeek V4 Flash 為例，總參數 284B，但每個 token 實際啟用的只有約 13B——大約 4.6%。

換句話說：模型非常大，但工作集（working set）可能沒有那麼大。這就產生一個很直接的問題：既然某些 expert 現在根本沒被用到，為什麼一定要讓它們佔著 VRAM 或 DRAM？

於是就有了 Expert Streaming：

Colibri：把 VRAM / RAM / SSD 當成單一階層

Colibrì 是一個純 C、零相依的推理引擎（Apache-2.0），它明確地把儲存、RAM 與 VRAM 視為同一個多層推理階層。以 GLM-5.2（744B MoE）為例：只把 dense 部分（attention、shared expert、embedding，int4 約 9.9 GB）常駐在 RAM，其餘 21,504 個 routed experts（磁碟上約 370 GB）依需求從 SSD 串流進來，用 per-layer LRU cache 管理，並且會自動 pin 住熱門 expert——用得越久，快取越準。目前已支援 GLM-5.2（744B）、Inkling（975B）、Kimi K3（2.8T）、DeepSeek V4 Flash（284B）與 OLMoE（7B）。

這代表什麼？代表 expert streaming 目前是用時間換可行性：它讓原本需要八張 A100 才能載入的模型，可以在你手邊的機器上「跑得起來」，但還遠遠稱不上「跑得順」。這是一條正在成形的路，不是已經鋪好的路。

ds4（DwarfStar）：專用化到底

antirez 的 ds4 走的是另一種極端：不做通用 GGUF runner，而是針對 DeepSeek V4 Flash／PRO 與 GLM 5.2 做深度專用化，模型載入、prompt 渲染、tool call、KV state、HTTP server 全部一起設計與驗證，支援 Metal、CUDA 與 ROCm。

它的 SSD streaming 是明確的降級路徑：記憶體夠就整個常駐，記憶體不夠就 --ssd-streaming，用可設定的 expert cache 預算從本地快閃分頁載入權重，用延遲換取「這台機器跑得動」。這個案例證明了一件事：當模型結構可以預測，針對它把資料放置與 I/O 調到極致，收益是很實在的。

FlashMoE：讓快取策略自己學

這件事也不只是開源社群在玩。2026 年 1 月的 FlashMoE 研究直接把 inactive experts offload 到 SSD，並用一個輕量的、以機器學習為基礎的快取替換策略，同時結合 recency 與 frequency 訊號來決定哪些 expert 值得留在高速記憶體。結果：在實機平台上，快取命中率相較 LRU／LFU 等傳統策略最高提升 51%，相較既有 MoE 推理系統最高有 2.6 倍的加速。

這已經不只是「SSD 可以存模型」，而是：AI 系統開始學習預測「下一步會用到哪個 expert」。一旦可以預測，就可以提前把它從 SSD 搬到 RAM，甚至搬進 VRAM，形成 Prediction → Prefetch → Cache → Compute 的完整流水線。

主流工具的方向不太一樣但問題相同：llama.cpp 大量依賴 mmap 與 OS page cache，並提供 --cpu-moe / --n-cpu-moe 把 expert 丟到系統 RAM，社群也已在討論 VRAM／pinned RAM／mmap 的三層 expert cache；AirLLM 走逐層載入；FlexGen 與 DeepSpeed ZeRO-Infinity 則是更完整的訓練／推理分層 offload。答案不同，但問的是同一個問題：模型大到超過高速記憶體時怎麼辦？

十一、SSD 會不會很快被寫壞

這是實務上最常被問到的問題，也最容易被誇張。先講原理：NAND 的壽命主要消耗在寫入與抹除（P/E cycle），讀取本身不是主要敵人。所以要分成兩種完全不同的情境。

情境	存取型態	壽命影響
A. 一次寫入、大量讀取 Expert streaming、GDS 模型載入	權重寫入一次 → 反覆讀取	相對輕微
B. 高頻 swap VRAM 不足時的資料抽換	寫回 → 讀進 → 再寫回，不斷循環	消耗極快

情境 B 才是真正的殺手。持續寫入會被寫入放大（Write Amplification）進一步放大，加上垃圾回收與耗損平均的額外動作，消耗會非常快。所以要看的指標是 TBW、DWPD、WAF，以及控制器與 NAND 的等級。企業級常見做法是：原始資料放在安全陣列，另外劃出專門的、可耗損的 NVMe 當快取盤，壞了就熱插拔換掉，當成消耗品編列。

還有一個容易被忽略的實務問題：溫度。持續高負載的隨機讀取會讓 M.2 SSD 快速升溫並觸發降速，對長時間的 expert streaming 來說，散熱片與氣流的影響有時比標稱頻寬還大。

十二、兩條路線正在會合

把整件事攤開來看，會發現有兩條問題意識完全不同的路線：

路線	核心問題	代表技術
Data Path Optimization	資料怎麼搬得更快？	GDS／cuFile、SCADA、NVLink-C2C、CXL、RDMA
Data Placement Optimization	哪些資料根本不必放在高速記憶體？	Colibri、ds4、FlashMoE、llama.cpp offload

這兩條路不但不衝突，而且天生互補。可以想像未來的組合是：

這已經不太像傳統的「載入模型」，而比較像是：GPU 在一個巨大、分層、動態的記憶體空間裡工作。

十三、從「模型多大」到「工作集多大」

過去我們挑硬體時問的是「這張卡有幾 GB VRAM？」未來可能要改成兩個問題：這個模型的有效工作集有多大？這台機器能有效使用幾層記憶體？

一個 2.8T 的 MoE 模型，如果每個 token 只用到其中很小一部分，那 2.8T 並不代表你必須擁有 2.8T 的高速記憶體。真正要解決的是：需要的那一小塊，能不能及時到位。

對照 CPU 的世界，這個結構一點都不陌生。L1 → L2 → L3 → DRAM → SSD 這條階層存在幾十年了；AI 系統現在正在長出幾乎一模一樣的形狀：HBM → NVLink/C2C → DRAM → CXL → NVMe → NVMe-oF。差別只在於，管的東西從「CPU 的 cache line」變成了「模型的 expert」。

而真正的問題也從「這是不是記憶體？」變成了：這份資料現在，值不值得佔用高速記憶體？

十四、對中小企業與本地部署的實際意義

回到我們比較關心的現場。這一連串變化，對想在自己機房或工作站跑大模型的人，實際上意味著五件事：

最後：下一場競賽比的是「資料距離」

如果要把整件事濃縮成一句話：HBM 負責最快的資料，DRAM 負責更大的工作集，NVMe SSD 負責巨大的冷資料，GDS／SCADA 負責縮短 Storage 到 GPU 的距離，MoE 負責讓模型不必所有參數同時工作，Expert Streaming 負責把真正需要的那一塊送到正確的層級。

所以這次 FMS 上真正值得記住的，不是「SSD 終於可以當顯存了」，而是：GPU 正在從一個「只看 HBM」的運算裝置，變成一個直接面對整個資料階層的運算裝置。

AI 硬體的競爭，正在從單純的算力競賽，進入另一個階段——誰能讓 GPU 花最少的時間等資料。當模型規模從數百 B 走向 T 級，這個問題只會越來越重要。