25. 某製造業團隊建立瑕疵偵測模型時，使用單張約 20MB 的高解析度工業影像作為訓練資料，並將所有影像儲存於 NAS(Network Attached Storage)中。訓練時透過 PyTorch 搭配 CNN 模型於 GPU 上進行，工程師觀察到 GPU 使用率僅約 20%至 30%，整體訓練時間 耗費數日。根據上述情境，造成 GPU 利用率偏低的最可能原因為何？
(A) 模型架構過於複雜，導致反向傳播時間過長
(B) 訓練資料品質不穩定，造成模型難以收斂
(C) 高解析影像從 NAS 載入產生 I/O(Input/Output)瓶頸，導致 GPU 等待
(D) 批次大小(Batch Size)設定不當，導致 GPU 長時間閒置

這題的正確答案是：

(C) 高解析影像從 NAS 載入產生 I/O (Input/Output) 瓶頸，導致 GPU 等待

專業解析

作為 AI 規劃師，在建置基礎設施（Infrastructure）時，**「計算（Compute）與資料傳輸（Data Transfer）的平衡」**是調校效能的關鍵。

1. 為什麼是 (C)？ 這是一個典型的 「I/O Bound（I/O 受限）」 場景，而非「Compute Bound（計算受限）」。

• 數據量巨大： 單張 20MB 的影像非常大（通常訓練用的 ImageNet 圖片經壓縮後僅數百 KB）。假設 Batch Size 設為 32，一次迭代就需要讀取並解碼 640MB 的數據。

• 傳輸瓶頸： NAS 是透過網路（Network）傳輸資料，其頻寬與延遲遠不如本機的 NVMe SSD。

• GPU 的飢餓現象 (Starvation)： GPU 的運算速度極快，瞬間就處理完了目前的數據，但 CPU 還在努力從 NAS 下載並解碼下一批圖片。這導致 GPU 大部分時間都在「空轉等待數據」，因此使用率只有 20%~30%。

2. 為什麼其他選項不是主要原因？

• ❌ (A) 模型架構過於複雜：

  • 如果模型架構複雜，GPU 需要進行大量的矩陣運算，使用率反而會飆升至 90%-100%，這代表 GPU 很忙，是我們樂見的情況（Compute Bound）。

• ❌ (B) 訓練資料品質不穩定：

  • 資料品質差會導致 Loss 不下降或準確率低，但 GPU 不會因為「這張圖拍得不好」就拒絕運算或降低效能。

• ❌ (D) 批次大小 (Batch Size) 設定不當：

  • 雖然 Batch Size 過小確實會導致 GPU 使用率偏低（因為與 CPU 通訊的 overhead 變高），但在 20MB 大圖的情境下，記憶體通常很快就滿了，Batch Size 很難設得非常小。且相較於 NAS 的物理傳輸限制，Batch Size 造成的影響通常是次要的。

規劃師的實戰建議 (Troubleshooting)

遇到這種情況，我通常會建議 IT 團隊採取以下三階段優化：

1. 資料預處理 (Pre-processing)：

   • 20MB 的圖對於 CNN 來說太大了。應在訓練前先將圖片 Resize 到模型輸入的大小（如 512x512 或 1024x1024），並存成較小的格式（如 JPG 或 TFRecord/WebDataset）。這能將 I/O 需求降低 10 倍以上。

2. 硬體架構調整：

   • 快取 (Caching)： 不要直接從 NAS 讀取。訓練開始前，先將資料複製到訓練機的 本機 NVMe SSD 上。

   • Dataloader 優化： 在 PyTorch 中增加 num_workers 的數量，利用多核心 CPU 平行讀取與解碼圖片。

3. 監控工具：

   • 使用 nvidia-smi 監控 GPU，同時使用 top 或 iostat 監控 CPU 與磁碟 I/O。如果 GPU 低載但 CPU 滿載（在解碼圖片）或 I/O 滿載（在讀圖），就能證實是 I/O 瓶頸。

1. 核心考點：I/O 瓶頸 (I/O Bottleneck)

在深度學習訓練中，GPU 負責運算（模型的前向與反向傳播），而 CPU 負責從磁碟或網路讀取數據、解碼影像並傳送到 GPU。如果「數據供應的速度」趕不上「GPU 運算的速度」，GPU 就會因為沒有資料可算而進入閒置狀態。

2. 逐項解析

• ✅ (C) 高解析影像從 NAS 載入產生 I/O(Input/Output) 瓶頸，導致 GPU 等待：

  • 原因：每張影像達 20MB 非常大，且儲存在 NAS（網路附加儲存）。這意味著數據必須透過區域網路傳輸，速度遠慢於本地 SSD。當 GPU 快速算完一個批次（Batch）後，新的資料還在網路傳輸中，導致 GPU 使用率僅能維持在 20%~30% 的低點。

• ❌ (A) 模型架構過於複雜，導致反向傳播時間過長：

  • 原因：如果模型架構複雜，GPU 會花更多時間在運算梯度。這通常會導致 GPU 使用率衝高（接近 100%），但訓練進度變慢，而非利用率偏低。

• ❌ (B) 訓練資料品質不穩定，造成模型難以收斂：

  • 原因：收斂（Convergence）與否是關於模型「學不學得會」的問題。即便模型不收斂（Loss 不降），只要運算在跑，GPU 利用率依然會維持在一定水準。

• ❌ (D) 批次大小 (Batch Size) 設定不當，導致 GPU 長時間閒置：

  • 原因：Batch Size 過小會導致 GPU 運算效率不佳（無法發揮平行運算優勢），但在此情境下，20MB 的影像只要幾個就能塞滿顯存，最大的殺手顯然是從 NAS 讀取資料的過程。

? 重點整理：如何解決 I/O 瓶頸？

這類題目在 iPAS 或業界實務中常見，解決方案通常包括：

1. 資料遷移：將資料從 NAS 搬移到工作站本地的 NVMe SSD。

2. 數據預處理：預先縮放影像大小，或將大量小檔案封裝成大型二進位格式（如 TFRecord、WebDataset）。

3. 多線程加載：在 PyTorch 的 DataLoader 中增加 num_workers 參數，利用多核 CPU 預先讀取資料。