RAPIDS 24.12 將 cuDF 包引入 PyPI，加快了 groupby 聚合和從 AWS S3 讀取文件的速度，在 Polars GPU 引擎中支持大于 GPU 內存的查詢，并加快了真實圖形的圖形神經網絡 (GNN) 訓練速度。
cuDF 和 RMM CUDA 12 軟件包現在可在 PyPI 上獲得
從 24.12 版本的 RAPIDS 開始，rmm、cudf、dask-cudf 的 CUDA 12 版本及其所有依賴項現在均可 在 PyPI 上使用 。因此，安裝這些庫不再需要使用 –extra-index-url 和 pip 的其他配置。試用：
pip install \????'cudf-cu12==24.12.*' \????'dask-cudf-cu12==24.12.*'\????'rmm-cu12==24.12.*' |
這也意味著 Polars 用戶無需再在安裝期間指定額外的索引即可獲得 GPU 支持：pip install polars[gpu] 即可正常工作。
這是通過 pypi.org 提供 RAPIDS 庫的持續努力的第一步。敬請關注，了解更多信息。
Polars GPU 引擎：擴展對大數據規模的支持
我們與 Polars 一起在 Open Beta 中推出了基于 cuDF 構建的 Polars GPU 引擎，將加速計算引入到適合 GPU 內存的 Polars 工作負載中。但是，隨著數據大小的增加，使用 Polars GPU 引擎處理數據集可能會導致 GPU 內存不足 (OOM) 錯誤。
24.12 版本引入了兩項功能來消除 OOM，同時在大型數據集大小下保持出色性能：分塊 IO 和 CUDA 統一內存。
分塊 IO?
首先，cudf-polars 現在以塊 (默認為每個塊 8 GiB) 處理 parquet 文件，同時保持高解壓縮和解碼吞吐量。
壓縮文件需要在內存中進行擴展，這可能會導致一些工作負載在 IO 期間顯存不足，而如果數據位于內存中，這些工作負載就會成功。這對于 ZSTD 壓縮尤其重要，因為實際內存占用通常是文件大小的 3 倍。
分塊 IO 可減少此峰值內存壓力，助力更多工作負載取得成功。
CUDA 統一顯存?
其次，此版本在 cudf-polars 中默認啟用預取的托管內存池，這與之前在 cudf.pandas 中完成的工作類似。有關更多詳細信息，請參閱使用 RAPIDS cuDF 在 pandas 中擴展至十億行數據。
統一內存使 DataFrames 能夠在 GPU 和主機內存之間進行擴展，高效處理通過 GPU 互連 (PCIe 或 C2C) 進行的數據遷移，實現無縫處理。
借助 Unified Memory 和 prefetching，Polars GPU 引擎現在可以處理更大的數據集，而不會出現顯存不足的情況。
PDS-H 基準測試?
在上一版本中，隨著 Scale Factor（數據集大小）超過 80 GB 或 100 GB，許多使用 Polars GPU 引擎運行的 PDS-H 基準查詢將在 NVIDIA H100 GPU 上顯存不足。
借助這些增強功能，Polars GPU 引擎現在可以高效處理適合 GPU 和 CPU 組合顯存但之前會導致 GPU OOM 錯誤的工作負載。
圖 1 比較了使用 RAPIDS 24.10 和 24.12 在 PDS-H 基準測試中進行的 22 次查詢中 Polars GPU 與 Polars CPU 引擎的加速比。根據對 Scale Factors 的掃描，先前因 OOM 而失敗的查詢現已成功。與僅使用 CPU 的基礎設施相比，更新后的引擎現在可以大幅加速，甚至可提升至 Scale Factor 250 (250 GB)。
GPU：NVIDIA H100|CPU：雙路英特爾 Xeon 8480CL (Sapphire Rapids)|存儲：本地 NVMe。注意：PDS-H 源自 TPC-H，但這些結果無法與 TPC-H 結果進行比較。
cuDF 性能改進?
RAPIDS 24.12 還包括兩項性能優化，旨在改善大規模數據處理工作流程。
cuDF 中更快的低基數 groupby?
此版本包括針對 cuDF 中基于哈希的 groupby 聚合的新優化。以前，處理低基數 (少量組) 的 groupby 聚合會導致吞吐量相對較低。
吞吐量較低的原因是當組數量低于 100 時發生原子爭用。現在，通過使用 GPU 共享內存來追蹤部分聚合，可以避免此瓶頸。
以下代碼示例展示了此效果的實際應用：
import cudf, cupy, rmmimport timermm.mr.set_current_device_resource(rmm.mr.CudaAsyncMemoryResource())?
df = cudf.DataFrame({????'key': cupy.ones(100_000_000),????'payload': cupy.random.rand(100_000_000),})?
for _ in range(3):????t0 = time.time()????g = df.groupby('key').agg({'payload': 'sum'}).reset_index()????t1 = time.time()?
print(f'cudf {cudf.__version__}: {t1-t0:0.3f} seconds')?
cudf 24.10.01: 0.177 secondscudf 24.12.01: 0.012 secondspandas 2.2.3:? 1.463 seconds |
在配備 NVIDIA H100 GPU 和 Intel Xeon Platinum 8480CL CPU 的系統上執行，可在此用例中將 cuDF 24.10 至 24.12 的速度提高 15 倍。
此優化對于 Spark 和 Dask 用戶特別有用，因為在這些用戶中，大型工作負載可能需要對少量類別得出聚合結果。
AWS S3 提供更快的 IO (遠程存儲)
cuDF 24.12 為 cuDF 和 Dask-cuDF 引入了新的可選擇功能，用于多線程 S3 對象讀取。
新功能基于 KvikIO 中用于管理 S3 對象讀取的 libcurl 用法，可顯著提高 Dask cuDF 中 S3 讀取的整體性能和可擴展性。可以使用 CUDF_KVIKIO_REMOTE_IO 環境變量啟用，并使用 KVIKIO_NTHREADS 進行控制。
在圖 2 中，KvikIO (通過 CUDF_KVIKIO_REMOTE_IO=ON) 用于將 Red-Pajama v2 數據集的子集從 S3 存儲桶讀取到具有不同線程數的 4-GPU g5.12xlarge EC2 實例。
在這種情況下，KVIKIO_NTHREADS=128 的總吞吐量為 963 MiB/s，而不使用 KvikIO 的總吞吐量為 450 MiB/s。
由于每個工作負載都不同，因此線程數量是可配置的。我們目前正在研究一系列數據集和系統中的適當默認配置，因此此功能目前可供用戶選擇，但可廣泛使用。
在 WholeGraph 中通過基于層次結構的集合加快 GNN 訓練速度
此版本還通過專為 power-law 圖形設計的新通信優化，顯著提升了 WholeGraph 的性能。
定律圖的度數分布與圖 3 所示相似。大多數頂點的度數很小 (許多頂點只有一個近鄰)，而一些頂點的度數非常高且高度連接。大多數真實圖形都屬于這一類。
對冪律圖進行采樣時，最高度頂點可以在批量中多次出現。對于 ogbn-papers100M 數據集，使用 8 個 GPU 進行訓練時，重復頂點的百分比最高可達 70%。
通過僅讀取重復頂點的特征張量一次，我們可以在特征獲取階段節省大量時間。這稱為基于層次結構的收集操作，而不是默認的分布式收集操作。
在這些場景中，使用基于層次結構的收集操作可獲得比分布式收集操作高 2 倍的速度。更快的采集步驟可為批量大小為 1,024 的三層 GraphSAGE 模型提供約 30-40% 的端到端加速。
系統：NVIDIA DGX H100
結束語?
RAPIDS 24.12 版本為 DataFrame 分析和 GNN 訓練帶來了顯著的用戶體驗改進和性能優化。Polars GPU 引擎處于 Open Beta 階段，多線程 AWS S3 文件讀取處于實驗階段。歡迎您向 GitHub 提供反饋。您還可以加入 RAPIDS Slack 社區 的 3,500+ 名成員，討論 GPU 加速的數據處理。
如果您不熟悉 RAPIDS，請查看這些 資源以開始使用 。
?
