隨著 AI 模型從雲端走向邊緣 (Edge)，儲存裝置的角色正在發生典範轉移。過去我們只要求 SSD 讀寫要快、資料要準；但在 CSD (Computational Storage Device) 架構下，SSD 不再只是資料的倉庫，更變成了運算的「大腦」。
這篇文章將深入探討當 SSD 整合了 NPU 或 AI 加速單元後，驗證工程師該如何面對這場技術變革？我們將從原理、驗證架構到實戰盲點，逐一拆解 CSD 的測試心法。
一、CSD 是什麼？打破馮·諾伊曼瓶頸的關鍵一步
CSD，全名為 Computational Storage Device (運算儲存裝置)。在傳統架構中，資料必須從 SSD 搬移到 DRAM，再由 CPU/GPU 處理，這中間的 PCIe 通道往往成為效能瓶頸（即所謂的 Von Neumann bottleneck）。CSD 的核心概念是**「近數據運算 (Near-Data Processing)」**。它在 SSD 控制器旁整合了 NPU、FPGA 或專用 AI 核心，使其具備邊緣運算能力。這意味著：
• 卸載主機負載 (Offload)： 讓 SSD 就地完成 AI 推論 (Inference)、影像辨識、或即時加解密壓縮。
• 降低延遲 (Latency)： 省去資料在 PCIe 匯流排往返搬運的時間。
• 節能高效： 減少無效的資料搬移功耗。
這類技術目前正大量應用於智慧監控 (Smart Surveillance)、醫療影像初步篩選、以及資料庫的 ETL 預處理場景。
二、驗證重點解析：比傳統 SSD 更棘手的四個維度
驗證 CSD 的難度在於，你同時在測試一個「儲存裝置」和一個「運算裝置」。以下是四大測試挑戰：
1. 推論正確性 (Inference Accuracy)
這不是傳統的 Data Integrity (資料完整性) 檢查，而是「邏輯正確性」檢查。
• 挑戰： CSD 執行的量化模型 (Quantized Model) 結果，必須與主機端軟體執行的結果高度一致。
• 指標： 針對分類問題，需驗證 Top-1 與 Top-5 的吻合度；針對回歸或特徵提取，需計算與黃金標準 (Golden Sample) 的誤差值 (如 MSE)。絕不能發生「圖片存進去是對的，但辨識出來卻是錯的」這種誤判。
2. 資料管線一致性 (Data Pipeline Consistency)
資料從 Flash 讀出後，會經過解壓縮、預處理 (Resize, Normalization) 才進入 Tensor Buffer。
• 挑戰： 中間任何一個環節的資料轉換錯誤（例如 RGB 轉 BGR、Padding 補零錯誤），都會導致進入 AI 核心的數據失真。
• 重點： 驗證必須能針對內部 Tensor Buffer 進行 Dump 與比對，而非只看最終輸出結果。
3. 高併發下的資源爭搶 (High Concurrency & QoS)
這是最考驗 Firmware 架構的地方。當 SSD 正在滿載進行 4K Random Read 時，若同時觸發 AI 推論請求，控制器的 SRAM 和 DRAM 頻寬會被瓜分。
• 挑戰： 觀察是否因硬體資源 (Resource Contention) 導致 IOPS 雪崩式下降，或是 AI 推論延遲 (Inference Latency) 飆升。
• 重點： 需定義清楚的 QoS (Quality of Service) 標準，確保 AI 與 IO 任務能合理共存。
4. 異常處理與強健性 (Error Handling & Robustness)
• 場景模擬：
• 推論執行到一半時發生 Unsafe Shutdown (斷電)。
• 載入損壞或不支援的 AI 模型格式。
• 輸入資料格式錯誤 (如解析度不符)。
• 目標： 系統不應 Crash 或 Hang 住，而應優雅地 (Gracefully) 回報 Vendor Specific Error Code 並恢復待命狀態。
三、驗證架構設計：如何打造 CSD 測試平台？
要測好 CSD，你需要一套能夠「發送 AI 指令」並「比對推論結果」的自動化架構。
1. 測試環境搭建
• Host 端工具： 除了 FIO/Iometer 等傳統工具外，還需要 Python 測試框架 (如 PyTest) 來整合 ONNX Runtime 或 TensorFlow Lite，作為軟體端的「黃金標準」。
• 通訊協定： 支援 Vendor-defined NVMe Command (或遵循 NVMe TP4091 標準)，用於下發推論請求。
• 除錯通道： 必須建立 Side-channel (如 UART 或專屬 Vendor Log Page)，用於回報 NPU 狀態、溫度與中間層 Tensor 數據。
2. 黃金比對流程 (Golden Comparison Flow)
推薦使用 ONNX 作為統一的中介格式，並採用 INT8 量化模型進行測試：
1. Host 端： 將圖片輸入軟體推論引擎 (CPU/GPU)，取得 Result A。
2. Device 端： 將同一張圖片寫入 CSD，發送運算指令，取得 Result B。
3. 驗證： 比對 Result A 與 Result B。注意：由於硬體 NPU 與軟體運算可能存在微小的浮點誤差，需設定合理的容許閥值 (Threshold)。
3. 測試階段劃分
• 功能驗證 (Functional)： 單一指令、單一模型，確認基本動作正確。
• 效能驗證 (Performance)： 測試 AI Throughput (FPS) 與 IOPS 的交互影響。
• 邊界測試 (Corner Case)： 極大/極小圖片輸入、滿碟狀態下的推論、連續切換不同模型。
• 壓力測試 (Stability)： 72小時混合負載 (Mixed Workload)，確保沒有 Memory Leak 導致 NPU 當機。
四、實戰盲點：那些規格書上沒寫的坑
根據過往經驗，新手驗證工程師最容易在以下三個地方「翻車」：
盲點一：只驗「有跑」，沒驗「跑對」
很多測試腳本只檢查 NVMe Command 是否回傳 "Success"，卻忽略了推論內容是否正確。
• 修正： 必須實作「逐幀比對 (Frame-by-Frame Comparison)」。即使 Command 成功，若辨識信心分數 (Confidence Score) 異常低，也代表系統有問題。
盲點二：忽略「前處理 (Pre-processing)」的黑箱
AI 模型對輸入圖片的要求極其嚴格（例如必須是 224x224, Normalized mean=[0.485...]）。CSD 內部的硬體縮放器 (Scaler) 若與 Host 端軟體算法（如 Bilinear vs Bicubic）不一致，會導致驗證永遠失敗。
• 修正： 在驗證初期，應設法截取 CSD 內部「進 NPU 前一刻」的 Tensor Buffer，確認數據是否與 Host 端預處理後的數據完全一致 (Bit-exact)。
盲點三：將 AI 與 IO 隔離測試
單獨測 AI 很快，單獨測 IO 也很穩，但合在一起就崩潰。這才是真實的 Data Center 場景。
• 修正： 你的 Script 必須具備 Multi-threading 能力。一個 Thread 狂打 4K Random Write 塞滿 Queue，另一個 Thread 同時不斷發送 Inference Command。這能有效抓出 Firmware 內部的 Race Condition 與資源鎖死 (Deadlock) 問題。
五、總結：未來驗證工程師的技能樹
CSD 的出現，標誌著儲存驗證工程師的職能正在擴張。你不能只懂 NVMe Spec 和 NAND Flash 特性，你還需要：
1. 理解 AI Pipeline： 知道什麼是 Tensor、Quantization、Pre-processing。
2. 掌握 Python 與資料分析： 能夠撰寫自動化腳本來解析複雜的推論結果與 Log。
3. 系統觀 (System View)： 理解 Host Driver、PCIe 頻寬與 Firmware 排程之間的交互關係。
未來的 CSD 將支援更複雜的功能，如多模型動態切換、與 FPGA/GPU 的異質運算協作。儘早建立一套模組化、可擴充的 AI 驗證架構，將是你進入這個高階領域的最佳入場券。
