Computational Storage和GPUDirect Storage差在哪？近資料處理與GPU直接I/O

先分清楚三件事：資料在哪裡、運算在哪裡、誰負責搬運

Computational Storage、GPUDirect Storage（GDS）與 GPUDirect RDMA 常被放在同一張架構圖裡，但它們解決的不是同一個瓶頸。Computational Storage 改變的是運算位置：把篩選、掃描、壓縮、解壓、checksum 或其他可下放的工作放到儲存裝置、Storage Processor 或 Storage Array 附近。GDS 改變的是 I/O 路徑：當資料仍然要交給 GPU 時，讓 storage 端的 DMA engine 直接把資料送進 GPU memory，減少 CPU system memory 的 bounce buffer。GPUDirect RDMA 則處理 GPU memory 與遠端 NIC 或其他網路端點之間的資料路徑。

這個區分會直接影響設計決策。若資料集有九成內容在進 GPU 前就能被固定條件排除，近資料 filter 可能降低跨 PCIe、CPU memory 與 GPU memory 的資料量；若幾乎所有資料都必須進 GPU，額外部署 Computational Storage Function 只會增加控制面與維運成本，此時 GDS 可能是較直接的路徑。若資料在另一個節點或另一個 rack，則要把 NIC、RDMA、檔案系統與 GDS 的支援一起評估，不能只看某一個 API 名稱。

SNIA CSx 模型：不要把「靠近儲存」誤寫成「一定是 SSD」

SNIA 的 Computational Storage Architecture 用 CSx 作為較大的統稱，並區分 CSD、CSP 與 CSA。CSD 可以把持久儲存與運算引擎放在同一個裝置內；CSP 提供運算能力但不一定包含持久儲存；CSA 則是在 Storage Array 層提供一個或多個運算引擎。這個分類很重要，因為 API、隔離邊界、更新方式、故障域與資料傳輸介面都可能不同。

對應用程式而言，最值得先定義的是 Computational Storage Function 的契約，而不是先決定硬體名稱。契約應說明輸入資料格式、輸出格式、可接受的版本、最大輸入大小、是否可串流、是否允許重試、是否保證 deterministic、錯誤碼、資源限制與安全身份。若 function 只支援某一個裝置的私有格式，未來更換 CSD、CSP 或 CSA 時，就可能需要重寫整條 pipeline。

可下放的工作通常有三個特徵：輸入量大、輸出量小；規則穩定、可以在裝置端安全執行；資料局部性清楚，不需要頻繁讀取遠端資料。Predicate filtering、固定格式 scan、壓縮與解壓、checksum、加密前後的資料整理比較容易符合這些條件。大型模型推理、複雜跨表 join、需要大量共享狀態的 graph traversal，通常更適合留在 CPU、GPU 或專用計算節點。

CSx 也不應被當成無限擴充的 CPU。裝置端的 compute engine 可能有不同的核心數、記憶體、溫度與韌體限制；同一個 function 在低併發、小資料或高頻更新條件下，初始化與 dispatch overhead 可能比節省的資料搬運更大。因此應保留 host path，讓應用程式可以在不支援某個 function、版本不相容或裝置過載時回到既有流程。

GDS 的實際路徑：控制路徑仍經過 CPU，資料路徑不必經過 CPU memory

NVIDIA GPUDirect Storage Overview Guide 將 GDS 描述成 storage 與 GPU memory 之間的直接 DMA 路徑。這不代表 CPU 完全消失：應用程式仍要由 CPU 發出 cuFile request、準備 file offset、transfer size、GPU virtual address、stream 或 batch；CPU 也要負責 metadata、權限、錯誤處理與 pipeline 控制。被減少的是資料本身經過 CPU system memory 的額外 copy。

在一般 bounce-buffer 路徑中，資料先進入 CPU 可存取的 buffer，再由 CPU 或 GPU 進行第二段 copy。這會消耗 CPU memory bandwidth、增加同步點，也可能讓 CPU 與 GPU 共享的 PCIe root port 成為瓶頸。GDS 會依 filesystem、storage driver、GPU topology 與 cuFile 設定選擇可用路徑；direct path、compatibility path、GPU intermediate buffer 與其他 routing path 的成本並不相同，不能只從程式碼呼叫 cuFileRead 就宣稱一定是 zero-copy。

cuFile API Reference 所描述的流程通常包含 driver initialization、file handle registration、GPU buffer registration、read／write、deregister 與 driver close。非同步、batch 與 CUDA stream API 可以把 I/O 和 kernel 排進同一個控制流程，但仍要測量 queue depth、stream ordering、資料生命週期與 completion event。若上游或下游仍在 CPU 解析資料，GDS 可能只改善其中一段，端到端結果未必顯著。

open file and validate mount / permission
cuFileDriverOpen()
cuFileHandleRegister(file)
cuFileBufRegister(gpu_buffer, bytes)
cuFileRead(handle, gpu_buffer, bytes, file_offset, buffer_offset)
wait for completion and validate checksum
cuFileBufDeregister(gpu_buffer)
cuFileHandleDeregister(handle)
cuFileDriverClose()

O_DIRECT、相容模式與「看起來成功」的陷阱

GDS O_DIRECT Requirements Guide 說明 direct path 與檔案開啟模式、filesystem、storage driver 及 buffer 條件的關係。應用程式即使拿到成功的 API 回傳，也要確認實際走的是 direct path 還是 compatibility mode。compatibility mode 可能透過 CPU system memory 完成 I/O，功能上可用但不代表已取得 GDS 的預期效益。

部署檢查至少要包含 filesystem mount、O_DIRECT 行為、GPU allocation 類型、buffer registration、file offset、transfer size、driver、CUDA／GDS 版本與 cuFile configuration。非對齊資料、過小的 I/O、細碎 random access、mmap 造成的隱式 fault，可能讓 direct path 的收益下降。測試報告應寫清楚每一個條件，而不是只有一個「GDS enabled」布林值。

Computational Storage 加 GDS：何時真的值得組合

兩者組合的理想流程是「在 storage 附近先縮小資料，再把結果直接送進 GPU」。例如原始 log 先由 CS function 依時間、租戶或欄位條件篩選，再由 GDS 將較小的 columnar batch 送進 GPU；或先在裝置端完成解壓與格式整理，再讓 GPU 做 embedding、訓練或推論。這條路徑只有在 function 的 dispatch、執行與結果驗證成本小於節省的資料搬運成本時才有意義。

要做出可比較的 break-even，至少記錄五段時間：CS function dispatch、storage-side compute、縮減後資料傳輸、GPU kernel、以及 fallback 或 recovery。除了 bytes reduction，也要看 selectivity 是否穩定；若某些資料分區幾乎沒有可排除內容，系統可能在不同 partition 上有完全不同的最佳路徑。控制面應根據資料特徵選擇 host path、CSx path、GDS path 或兩者組合，而不是把所有流量固定送到最複雜的路徑。

raw object / block data
  -> CSx function: validate + filter + decompress
  -> versioned reduced batch
  -> cuFile direct transfer when supported
  -> GPU kernel / inference
  -> checksum + offset + generation acknowledgement

資料一致性也要在兩層之間明確定義。CS function 回傳的 batch 要帶 schema version、source offset、input checksum、output checksum、function version 與 generation；GDS consumer 只有在 metadata 與 buffer 大小吻合後才可啟動 kernel。若 function 重試造成重複結果，consumer 必須使用 idempotency key 或 generation 去重。若 direct path 不可用，Host Copy 的結果要使用相同的 schema 與 checksum，讓上層不必依賴路徑判斷資料是否可信。

拓樸不是附註：PCIe switch、NIC、NVMe 與 GPU 的距離會改變答案

GDS 的實際路徑受 PCIe root complex、switch、NVMe、NIC、GPU BAR1、NVLink 與跨 socket 路徑影響。同一套 cuFile 程式在兩台機器上可能有不同結果；即使都沒有 CPU bounce buffer，資料也可能需要跨 root port 或先進入另一個 GPU 的 intermediate buffer。NVIDIA 文件也提到 dynamic routing 會依 storage NIC 與 GPU 的 PCI distance 選擇候選路徑，這正是為什麼 topology 應列入部署與 benchmark 的主欄位。

在多 GPU 系統，先繪製 storage device、NIC、GPU、CPU socket、PCIe switch 與 NVLink 的關係，再決定 buffer 放在哪一張 GPU。對分散式 filesystem，還要記錄 mount、RDMA device、IP、filesystem driver 與 dynamic routing 設定。對 local NVMe，則要測試 drive 數量、RAID、queue depth 與共享 PCIe link。結果若只報「單張 GPU 的讀取速度」，無法推論多 GPU、多 NIC 或多 tenant 的端到端能力。

同樣的原則適用於 Computational Storage。CSD、CSP 或 CSA 的位置可能靠近資料，但不一定與 GPU 位於同一個 PCIe tree；若先縮減的資料仍要經過昂貴的跨節點傳輸，function 的收益可能被網路 latency 吃掉。應把資料縮減率、function 所在位置、storage 到 GPU 的 hop 數、NIC bandwidth、GPU idle 與 queue wait 放在同一張表比較。

安全、租戶隔離與韌體生命週期

Storage-side function 具有讀取資料和消耗裝置資源的能力，不能只當成一個普通 query。function 應有簽章、版本、allowlist、資源上限與撤銷機制；資料來源、租戶、object、partition 與輸出 destination 也要在控制面做身份驗證。多租戶環境不應讓一個租戶透過 function 讀取另一個租戶的 metadata、快取或未授權的 storage range。

GDS 的 GPU buffer registration、file handle、configuration 與 device node 同樣需要最小權限。log 可以記錄 function version、allocation id、bytes、offset、錯誤碼與 trace id，但不應保存可重播的秘密、未遮罩的租戶內容或不必要的 handle。韌體、driver、CUDA、GDS library、filesystem module 與 CS function 更新應各自有 compatibility matrix，並且保留 host fallback。升級後先跑小型 pattern、錯誤注入與 recovery，再逐步增加資料量。

Benchmark 要測端到端，不只測峰值 GB/s

一個可用的 benchmark matrix 至少要比較 Host Copy、GDS direct path、GDS compatibility path、Computational Storage、Computational Storage 加 GDS，以及必要時的 RDMA path。資料內容要包含高 selectivity、低 selectivity、壓縮資料、不可下放的資料與不同 partition 大小。每一個結果都要固定 CUDA／driver／GDS 版本、GPU 型號、storage、filesystem、PCIe topology、buffer size、queue depth、stream 數、batch 大小與 tenant 數。

正確性驗收不能只看 checksum 的最後一個結果。要確認 offset、record count、schema version、順序、重試去重與部分失敗的處理；對訓練資料，要確認 sample 不會遺失或重複；對 checkpoint，要確認寫入完成與 rename／commit 的順序；對 KV 或 embedding，要確認版本和來源 partition 一致。效能提升只有在資料正確、可觀測、可回退且維運成本可接受時才算有效。

選型決策表

如果資料必須完整進 GPU，且瓶頸是 CPU copy、CPU memory 或 PCIe root path，優先測 GDS。若資料可以用穩定規則大幅縮減，且 CSx function 的部署與安全邊界可控，才把 Computational Storage 放進主路徑。若資料在遠端節點或物件儲存，先確認 NIC、RDMA、filesystem、cuFile 或 cuObject 的支援，避免把 local NVMe 的結果套到遠端環境。若資料量小、延遲要求不高或故障恢復最重要，Host Copy 仍可能是最合理的 baseline。

• 要降低資料量：先驗證 filter／compress／scan 的 selectivity 與 function 成本。
• 要降低 CPU copy：先驗證 GDS 的 direct path、buffer registration 與 filesystem 支援。
• 要跨節點傳輸：先驗證 NIC topology、RDMA、排序、重試與租戶隔離。
• 要簡化維運：保留 Host Copy，讓 unsupported、timeout、driver reset 都有清楚 fallback。
• 要宣稱效能改善：提供端到端矩陣與環境快照，不用單一 microbenchmark 代替整條 pipeline。

官方資料與圖片來源

本文依據 SNIA Computational Storage Architecture、NVIDIA GPUDirect Storage Design Guide、NVIDIA GPUDirect Storage Overview Guide、NVIDIA GDS cuFile API Reference與 NVIDIA O_DIRECT Requirements Guide整理。CSx 的實際能力、GDS direct／compatibility path、filesystem、driver、CUDA 版本與 PCIe topology 都需要在目標環境重新驗證；本文不把官方文件的架構描述當成特定硬體的效能保證。圖片使用 NVIDIA GPUDirect Storage Design Guide 官方圖，保留來源頁與原始圖片 URL，不主張超出 NVIDIA 文件的授權範圍。

__COMPUTATIONAL_STORAGE_26512_SOURCE_IMAGE_RECONCILE_20260816__