APIDS 機(jī)器學(xué)習(xí)庫 cuML 支持多種類型的輸入數(shù)據(jù)格式，同時(shí)嘗試以最適合用戶工作流的輸出格式返回結(jié)果。 RAPIDS 團(tuán)隊(duì)為 cuML 添加了支持不同類型用戶的功能：

圖 1 ：一個(gè)優(yōu)化的 cuML 工作流示例。

最大化兼容性

使用現(xiàn)有 NumPy 、 Scikit-learn 和傳統(tǒng)的基于 PyData 庫的工作流的用戶： cuML 的默認(rèn)行為，允許盡可能多的格式，以及其基于 Scikit-learn 的 API 設(shè)計(jì)，允許以最小的工作量和無中斷的方式移植這些工作流的一部分。因此，例如，您可以使用 NumPy 數(shù)組作為輸入，然后返回 NumPy 數(shù)組作為輸出，正如您所期望的那樣，只是速度要快得多。

最大化性能

希望通過將所有內(nèi)容都保存在 GPU 內(nèi)存中來獲得最終性能的用戶： cuML 使用的開源標(biāo)準(zhǔn)和行為的可配置性允許用戶以較低的努力實(shí)現(xiàn)最高性能。本文將詳細(xì)介紹用戶如何利用這項(xiàng)工作從 cuML 和 GPU s 中獲得最大的好處。

兼容的輸入格式： CUDA 數(shù)組接口的奇跡

很大程度上要感謝 cuda_array_interface ，即所謂的 CAI ， cuML 接受多種數(shù)據(jù)格式：

cuDF 對象（數(shù)據(jù)幀和序列）

pandas 對象（數(shù)據(jù)幀和序列）

NumPy 陣列

CuPy 和 Numba 設(shè)備陣列

任何與 CAI 兼容的對象，如 PyTorch 和 CuPy 數(shù)組。這組被稱為 CAI 數(shù)組。

這個(gè)列表根據(jù)用戶需求不斷擴(kuò)展。例如， cuML 團(tuán)隊(duì)正在為 dlpack 陣列標(biāo)準(zhǔn)開發(fā) 直接支持 ，與 TensorFlow 的新支持正好吻合。也可以通過 cuDF 還是丘比 或 dlpack 支持來實(shí)現(xiàn)。如果您有當(dāng)前不支持的特定數(shù)據(jù)格式，請?zhí)峤粏栴}或請求 在 GitHub 上 。

默認(rèn)行為： cuML 如何開箱即用？

cuML 的默認(rèn)行為被設(shè)計(jì)成盡可能多地鏡像輸入。因此，例如，如果您在 cuDF 中執(zhí)行 ETL ，這對于 RAPIDS 用戶非常典型，您將看到如下內(nèi)容：

import cuml

import cudf

df = cudf.DataFrame（）

df［1］ = ［1.0， 2.0， 5.0］

df［2］ = ［4.0， 2.0. 1.0］

df［3］ = ［4.0， 2.0. 1.0］

kmeans = cuml.KMeans（n_clusters=2）

kmeans.fit（df）

print（type（kmeans.labels_））

# 《class ‘cudf.core.series.Series’》

鏡像 cuML 行為的默認(rèn)輸入格式類型。

使用 cuDF 數(shù)據(jù)幀時(shí)， cuML 會(huì)返回 cuDF 對象（在本例中是一個(gè)序列）。但是，如前所述， cuML 還允許您在不更改 cuML 調(diào)用的情況下使用 NumPy 數(shù)組：

import cuml

import numpy as np

ary = np.array（［［1.0， 4.0， 4.0］， ［2.0， 2.0， 2.0］， ［5.0， 1.0， 1.0］］）

kmeans = cuml.KMeans（n_clusters=2）

kmeans.fit（ary）

print（type（kmeans.labels_））

# 《class ‘numpy.ndarray’》

原始視圖默認(rèn)輸入格式類型鏡像 cuML 鏡像 NumPy 數(shù)組的行為。

在本例中，現(xiàn)在 cuML 以 NumPy 數(shù)組的形式返回結(jié)果。鏡像輸入數(shù)據(jù)類型格式是 cuML 的默認(rèn)行為，通常情況下，該行為是：

表 1 ：可接受的輸入格式和默認(rèn)輸出行為列表。

這個(gè)列表在不斷增長，所以希望很快能在該表中看到類似 dlpack 兼容庫的內(nèi)容。

可配置性：如何讓 cuML 按自己的方式工作？

cuML 允許用戶全局配置輸出類型。例如，如果您的 ETL 和機(jī)器學(xué)習(xí)工作流基于 GPU ，但依賴于基于 NumPy 的可視化框架，請嘗試以下操作：

import cupy as cp

import numpy as np

import cuml

cuml.set_global_output_type（‘numpy’）

ary = cp.array（［［1.0， 4.0， 4.0］， ［2.0， 2.0， 2.0］， ［5.0， 1.0， 1.0］］）

kmeans = cuml.KMeans（n_clusters=2）

kmeans.fit（ary）

print（type（kmeans.labels_））

# 《class ‘numpy.ndarray’》

使用 cuML 的“ set \ u global \ u output \ u type ”`

使用 set_global_output_type 指令會(huì)影響對 cuML 的所有后續(xù)調(diào)用。如果用戶需要更細(xì)粒度的控制（例如，您的模型由 GPU 庫處理，但只有一個(gè)模型需要是 NumPy 數(shù)組才能進(jìn)行專門的可視化），則可以使用以下機(jī)制：

cuML 的上下文管理器 using_output_type ：

import cuml

import cupy as cp

ary = ［［1.0， 4.0， 4.0］， ［2.0， 2.0， 2.0］， ［5.0， 1.0， 1.0］］

ary = cp.asarray（ary）

with cuml.using_output_type（‘cudf’）：

dbscan = cuml.DBSCAN（eps=1.0， min_samples=1）

dbscan.fit（ary）

print（type（dbscan_float.labels_））

# 《class ‘cudf.core.Series’》

kmeans = cuml.KMeans（n_clusters=2）

kmeans.fit（ary）

print（type（kmeans.labels_））

# 《class ‘cupy.core.core.ndarray’》

使用 cuML 的上下文管理器` using \ u output \ u type `

設(shè)置單個(gè)模型的輸出類型：

import cupy as cp

import cuml

ary = cp.array（［［1.0， 4.0， 4.0］， ［2.0， 2.0， 2.0］， ［5.0， 1.0， 1.0］］）

kmeams = cuml.KMeans（n_clusters=2， output_type=‘numpy’）

kmeans.fit（ary）

print（type（kmeans.labels_））

# 《class ‘numpy.ndarray’》

這種新功能可以自動(dòng)將數(shù)據(jù)轉(zhuǎn)換為方便的格式，而無需手動(dòng)從多種類型轉(zhuǎn)換數(shù)據(jù)。以下是模型為了解返回內(nèi)容而遵循的規(guī)則：

如果在構(gòu)建模型時(shí)指定了輸出類型，例如 cuml.KMeans（n_clusters=2， output_type=’numpy’） ，那么它將給出該類型的結(jié)果。

如果模型是使用 cuml.using_output_type 在上下文管理器 with 中構(gòu)建的，那么模型將使用該上下文的輸出類型。

如果 output_type 是使用 set_global_output_type 設(shè)置的，那么它將返回該類型的結(jié)果。

如果沒有指定上述任何一項(xiàng)，則模型將鏡像用于輸入的對象的類型，如“默認(rèn)行為”部分中所述。

效率：我應(yīng)該使用什么格式？

既然您知道了如何使用 cuML 的輸入和輸出可配置性，那么問題是，最好使用什么格式？這將取決于你的需要和優(yōu)先級(jí)，因?yàn)樗械母袷蕉加袡?quán)衡。讓我們考慮一個(gè)簡單的工作流程：

圖 2 ：使用 ML 的簡單數(shù)據(jù)科學(xué)工作流。

使用基于 NumPy 的對象

在下面的圖 3 中，傳輸（粉色框）限制了 cuML 可以給您的加速量，因?yàn)?a href="http://www.brongaenegriffin.com/v/tag/1301/" target="_blank">通信使用較慢的系統(tǒng)內(nèi)存，您必須通過 PCI-Express 總線。每次使用 NumPy 數(shù)組作為模型的輸入或要求模型返回 NumPy 數(shù)組時(shí)，主系統(tǒng)內(nèi)存和 GPU 之間至少有一次內(nèi)存?zhèn)鬏敗?/p>

乍一看，有人認(rèn)為這影響不大。然而，將盡可能多的數(shù)據(jù)保存在 GPU 中，即使不是最大的原因，也是 RAPIDS 實(shí)現(xiàn)閃電般速度的原因之一。

圖 3 ：說明使用 NumPy 數(shù)組進(jìn)行輸入或輸出時(shí)發(fā)生什么的工作流。

使用 cuDF 對象

使用 GPU 對象而不是 NumPy 數(shù)組具有重要意義。例如，使用 cuDF 對象如下圖 4 所示。橙色框表示完全在 fast GPU 內(nèi)存上發(fā)生的轉(zhuǎn)換。不幸的是，這意味著在 cuML 算法處理過程中會(huì)有一個(gè)額外的數(shù)據(jù)副本，這會(huì)限制在特定 GPU 中可以處理的數(shù)據(jù)集的大小。

圖 4 ：說明 GPU 內(nèi)存中發(fā)生的轉(zhuǎn)換的工作流。

DataFrames （和 Series ）是非常強(qiáng)大的對象，允許用戶以平易近人和熟悉的方式進(jìn)行 ETL 。但要提供這一點(diǎn)，它們是具有大量復(fù)雜性的復(fù)雜結(jié)構(gòu)，以實(shí)現(xiàn)此功能。

其中有幾個(gè)例子：

除了數(shù)據(jù)之外，每一列都可以有一個(gè)位掩碼數(shù)組（基本上是一個(gè)由 0 和 1 組成的附加數(shù)組），允許用戶在數(shù)據(jù)中有丟失的條目。

由于數(shù)據(jù)幀在添加/刪除行和列時(shí)需要提供靈活性，因此每一列 MIG 在內(nèi)存中應(yīng)該彼此遠(yuǎn)離。

當(dāng)然，還有一些附加的結(jié)構(gòu)，比如索引和列名。

但是，這些限制為某些分析工作流帶來了一些困難：

首先，許多算法在所有數(shù)據(jù)都是連續(xù)的情況下工作得更好，例如，所有字節(jié)都分組在同一個(gè)內(nèi)存區(qū)域中，因?yàn)楦咝У卦L問內(nèi)存是快速處理數(shù)據(jù)的一個(gè)重要組成部分（特別是對于 GPU s ！）。

內(nèi)存是一種有限的資源（一般來說，但對于 GPU 和加速器來說更是如此），因此額外的開銷會(huì)產(chǎn)生非常顯著的影響。

使用設(shè)備陣列

下面的圖 5 說明了用于輸入或輸出的 CAI 數(shù)組如何在 cuML 中處理數(shù)據(jù)時(shí)具有最低的開銷。通過使用 CAI ，不會(huì)發(fā)生內(nèi)存?zhèn)鬏敾蜣D(zhuǎn)換。 cuML 直接使用 CAI 的屬性訪問數(shù)據(jù)，然后返回 CAI 數(shù)組。這些格式幾乎沒有開銷。設(shè)備陣列，例如來自 CuPy 或 Numba 的設(shè)備陣列，比數(shù)據(jù)幀/系列等效物的結(jié)構(gòu)要簡單得多。與 NumPy 類似，它們被設(shè)計(jì)成由元數(shù)據(jù)描述的連續(xù)內(nèi)存塊。這個(gè)設(shè)計(jì)決定就是為什么 NumPy 對于最初的 Python 生態(tài)系統(tǒng)是革命性的。考慮到所有這些，設(shè)備陣列是使用 cuML 最有效的方法也就不足為奇了！

如前所述，從 cuML 的角度來看，所有 CAI 數(shù)組本質(zhì)上是相同的，因此您的工作流可以組合 Numba 、 CuPy 、 cuML 等功能，而無需執(zhí)行昂貴的內(nèi)存復(fù)制操作。

圖 5 ：說明用于輸入或輸出的 CAI 數(shù)組如何在 cuML 中處理數(shù)據(jù)時(shí)具有最低開銷的工作流。

選擇數(shù)據(jù)類型的提示

那么您應(yīng)該使用什么數(shù)據(jù)類型呢？如前所述，這取決于場景，但這里有一些建議：

如果您有一個(gè)現(xiàn)有的 PyData 工作流，那么可以利用 cuML 的 NumPy 功能逐個(gè)嘗試不同的模型。從加速工作流程中最慢的部分開始。 DBSCAN 和 UMAP 是 cuML 中 modInels 的很好例子，即使它們自己使用，沒有完全的 RAPIDS 加速，也能提供巨大的加速和改進(jìn)。

潛在陷阱：這可能會(huì)在主系統(tǒng)內(nèi)存和 GPU 內(nèi)存之間造成通信瓶頸。

如果您的工作流程非常依賴 ETL ，需要大量的 cuDF 工作，而大部分處理和開發(fā)時(shí)間都在數(shù)據(jù)加載或轉(zhuǎn)換中，請將其作為 cuDF 對象，并讓 cuML 管理轉(zhuǎn)換。

潛在的陷阱：這個(gè) MIG ht 限制了 GPU 中單個(gè)模型可以容納的數(shù)據(jù)量。

如果訓(xùn)練或推理的最終速度是關(guān)鍵，那么調(diào)整您的工作流以盡可能多地使用 CUDA rray 接口庫。

使用所有這些技巧，您可以配置 cuML 來優(yōu)化您的需求，并更好地估計(jì)工作流的影響和瓶頸。您的新工作流現(xiàn)在可能如下所示：

圖 6 ：用戶在 cuML 中優(yōu)化的工作流。

下一步是什么？

以下是我們很高興在接下來的帖子中分享的一些活躍領(lǐng)域：

多節(jié)點(diǎn)多 – GPU （ MNMG ） cuML ：還有很多額外的工作要做。 RAPIDS cuML 團(tuán)隊(duì)中的許多工程師目前正在構(gòu)建領(lǐng)先算法的多節(jié)點(diǎn)多 – GPU （ MNMG ）實(shí)現(xiàn)，以實(shí)現(xiàn)大規(guī)模的分布式機(jī)器學(xué)習(xí)。分布式數(shù)據(jù)本身就是一個(gè)完整的主題，很快就會(huì)有更多的帖子發(fā)布。但是從版本 0 。 13 開始， mnmgcuml 接受 Dask-cuDF 對象（使用 Dask 的 cuDF 的分布式等價(jià)物）和 CuPy 支持的 Dask 陣列 。 cuML 在 MNMG 算法中生成反映您使用的輸入的結(jié)果，類似于 cuML 對單個(gè) GPU 的默認(rèn)行為。我們正在努力為 MNMG-cuML 算法添加更多的可配置性。我們將討論您的數(shù)據(jù)是如何分布的，以及您使用的格式對 cuML 的影響。

有關(guān)數(shù)據(jù)及其含義的較低級(jí)別詳細(xì)信息： 許多細(xì)節(jié)，如數(shù)據(jù)類型或內(nèi)存中數(shù)據(jù)的順序，都會(huì)影響 cuML 。我們將討論這些細(xì)節(jié)如何影響 cuML ，以及它與傳統(tǒng) PyData 庫的比較和區(qū)別。

抽象與設(shè)計(jì) ：最近在 RAPIDS 軟件堆棧中引入的抽象和機(jī)制，如 CumlArray ，允許 cuML 提供此功能，同時(shí)降低代碼復(fù)雜性和保證結(jié)果所需的測試數(shù)量。我們將討論這個(gè)，連同 CAI ，如何讓用戶能夠使用多個(gè)庫，比如 CuPy ， cuDF ， cuML ，而不費(fèi)吹灰之力。

Conclusion

這篇文章討論了 cuML 的輸入和輸出可配置能力，支持的不同數(shù)據(jù)格式，以及 cuML 中每種格式的優(yōu)缺點(diǎn)。這篇文章展示了在現(xiàn)有工作流中采用 cuML 是多么容易。 cuML 的 sciketlearnapi 和格式輸出鏡像允許您使用它作為現(xiàn)有庫的替代品。為了獲得最大的性能，用戶應(yīng)該盡量使用 GPU 特定的格式，以及 CuPy 或 Numba 等 CAI 數(shù)組。 RAPIDS 團(tuán)隊(duì)正在努力改進(jìn) cuML 的功能和支持的數(shù)據(jù)格式。

關(guān)于作者

Dante Gama Dessavre 是 NVIDIA 的 RAPIDS 團(tuán)隊(duì)的高級(jí)數(shù)據(jù)科學(xué)家和工具開發(fā)人員。

審核編輯：郭婷