NVIDIA RAPIDS 24.10：GPU 資料科學工作流程的相容性與擴展更新 NEWS DETAIL

RAPIDS 24.10 的重點，是讓既有 Python 資料科學工作流程更容易導入 GPU 加速，並改善大型資料集、套件相容性與 GPU CI 的實務限制。本次更新涵蓋由 cuGraph 加速的 NetworkX 正式推出、Polars GPU 引擎公開測試、可處理超過 GPU 記憶體資料集的 cuML UMAP，以及 cuDF pandas 對 NumPy 與 PyArrow 的相容性調整。這些變化不代表所有工作負載都會得到相同增益；實際結果仍取決於資料規模、演算法、硬體、資料搬移與軟體版本組合。

本次更新改變了什麼

RAPIDS 24.10 將由 cuGraph 加速的 NetworkX 納入正式發行範圍。來源指出，從 NetworkX 3.4 起，可透過設定 NX_CUGRAPH_AUTOCONFIG=True 啟用端到端體驗，包含 GPU 加速的圖形建立與演算法執行。其意義在於，圖形建構若仍留在 CPU、演算法才轉至 GPU，CPU 與 GPU 間的資料轉換可能抵銷部分效能收益；端到端路徑可減少這類切換。

Polars GPU 引擎則仍屬公開測試。使用者可在 Polars Lazy API 的 collect(engine="gpu") 指定 GPU 執行。來源所列 PDS-H 測試中，部分複雜分組與連接查詢相較 CPU 最多達 13 倍加速；該測試使用 NVIDIA H100、Intel Xeon W9-3495X、本機 NVMe 與擴展係數 80，且來源明確指出 PDS-H 衍生自 TPC-H，結果不可與 TPC-H 結果直接比較。

為何對技術決策有影響

對以 Python 為主的分析、圖形運算與特徵探索團隊而言，這些更新降低了部分既有程式導入 GPU 的修改量。NetworkX 使用者可優先評估圖形建立、PageRank、betweenness centrality 等完整流程；Polars 使用者則應檢查 Lazy 計畫中的算子是否適合 GPU 執行，而不是只觀察單一查詢時間。

來源中的 NetworkX 基準測試顯示：在 400 萬節點、1,600 萬邊的美國專利引用圖上，PageRank 相較 CPU NetworkX 快 70 倍；在 500 萬節點、6,900 萬邊的 LiveJournal 圖上，當 k=100 時，betweenness centrality 快 485 倍。測試軟體為 NetworkX 3.4.1、cuGraph/nx-cugraph 24.10，硬體為 NVIDIA A100 80GB 與 Intel Xeon w9-3495X（56 核、250GB）。這些數字可作為評估方向，不能視為其他圖結構、演算法參數或伺服器配置的承諾。

超過 GPU 記憶體時的 UMAP 路徑

cuML UMAP 在 24.10 可透過分批近似最近鄰方法處理大於 GPU 記憶體的資料集。使用者可將 build_algo="nn_descent" 搭配 nnd_n_clusters 設為大於 1，必要時於 fit 或 fit_transform 使用 data_on_host=True，使完整資料保留於 CPU 記憶體，並在 GPU 上分批處理。

此作法的取捨是記憶體壓力與執行時間之間的平衡。來源建議從例如 4 的叢集數開始調整；數值增加可協助控制 GPU 記憶體使用量，但也可能因圖形建構需要多次迭代而增加額外負擔。團隊應以實際資料維度、樣本量、可用 GPU 記憶體及嵌入品質評估合適設定。

相容性與 CI 導入檢查點

cuDF pandas 加速器模式在此版本改善與 NumPy 的互動：來源指出，DataFrame 或欄位轉成陣列後可產生真正的 NumPy 陣列，使 isinstance(arr, np.ndarray) 回傳 True，並支援依賴 NumPy C API 的程式碼。cuDF Python 亦改用 Arrow C 資料介面，以支援自 PyArrow 4 起的 PyArrow 版本。

RAPIDS 24.10 支援 Python 3.10 至 3.12、NumPy 1.x 與 2.x，同時不再支援 Python 3.9 或低於 2.19 的 NCCL。若團隊以 GitHub Actions 執行 GPU 測試，來源提到可使用代管 GPU runner，並以 runs-on 指向 GPU runner；GPU runner 不屬於 GitHub Actions 免費用量，應在組織設定中確認成本與支出上限。導入前也應核對 RAPIDS 版本、CUDA 與驅動程式、NCCL、Python 環境及相依套件鎖定檔。

評估順序與證據邊界

1. 以具代表性的資料集建立 CPU 基準，量測端到端時間、記憶體使用量與結果正確性。
2. 先選擇一項工作流程進行驗證，例如 NetworkX 圖分析、Polars Lazy 查詢或 UMAP 嵌入。
3. 記錄資料載入、CPU/GPU 資料轉移、圖形建立與演算法執行時間，避免只量測局部核心運算。
4. 在目標硬體與完整依賴版本下執行回歸測試，再決定是否擴大至生產 CI。

來源沒有提供完整安裝矩陣、各功能的算子覆蓋範圍、所有硬體的效能資料或生產部署結果。採購與架構決策前，應查核帶日期的官方 RAPIDS 24.10 文件、完整 SKU／BOM 與相依套件要求，並以專案測試確認可行性。

常見問題

NetworkX 啟用 GPU 後，是否所有圖形工作負載都會加速？

不一定。來源提供的是特定資料集、演算法、軟體版本與 A100 80GB 平台上的測試結果。圖形規模、稀疏度、演算法支援情況、CPU/GPU 資料轉移與可用記憶體都會影響結果。應先確認目標 NetworkX API 與演算法路徑，再以實際工作負載測試。

Polars GPU 引擎可直接作為正式環境標準嗎？

來源將 Polars GPU 引擎列為公開測試功能，因此不應僅憑基準測試決定正式導入。應驗證目標查詢、資料型別、分組與連接行為、結果一致性、例外處理及版本相容性，並確認官方文件中的支援範圍。

結論

RAPIDS 24.10 顯示 GPU 資料科學生態正朝向較少程式修改、更完整端到端流程及更寬鬆相依套件相容性發展。對團隊而言，關鍵不是直接套用來源中的加速倍數，而是依工作負載、記憶體限制與 CI 成本，以可重現測試驗證 NetworkX、Polars、UMAP 與 cuDF pandas 的實際價值。

圍繞「NVIDIA RAPIDS 24.10：GPU 資料科學工作流程的相容性與擴展更新」繼續瞭解 NVIDIA 產品與網路方案。