cuml.accel: 零代码更改加速基准测试

cuML 使用 NVIDIA GPU 为传统 ML 模型提供加速推理和训练。借助 cuml.accel，您可以在现有的 Scikit-Learn、UMAP 和 HDBScan 脚本中获得类似的加速益处，而无需更改任何代码。虽然具体的加速比取决于模型、数据集大小和超参数，但以下基准测试应该能让您大致了解使用 cuml.accel. 时可能获得的益处。

训练

虽然训练和推理都能从 GPU 加速中受益，但 cuML 在训练方面往往比推理带来更显著的收益。对于 cuML 而言，训练时间快 2-80 倍是典型的，尤其是在大型数据集上。cuml.accel 提供了类似的加速，而无需任何 cuML 特定的代码更改。

相对复杂的流形算法，如 HDBSCAN、t-SNE 和 UMAP，往往能从 cuml.accel 中获得最大益处。对于实际工作负载，加速 60 倍到 300 倍是典型的。更简单的算法，如 KMeans 和 Random Forest，也可以看到 15 倍到 80 倍的加速。即使是最简单的 ML 算法，如 Logistic Regression、Lasso、PCA 和 Ridge，通常也会有 2 倍到 10 倍的加速。

在下图中，我们看到在使用和不使用 cuml.accel 运行相同代码所获得的相对加速。这些工作负载的数据集宽度从 8 到 512 个特征不等。正如我们所见，cuml.accel 对 HDBSCAN 提供了最大的益处，实现了 179 倍的加速，即使是 KNeighborsRegressor 也看到了 2 倍的加速。

与直接调用 cuML 相比，开销有多大？

虽然 cuml.accel 试图提供与 cuML 特定脚本相同的加速效果，但与直接调用 cuML 相比，存在一定的开销。因此，人们可能会合理地想知道在什么时候重写代码并直接调用 cuML 以挤出每一分性能是合理的。虽然确切的开销量取决于估计器、参数和数据大小，但对于模型训练而言，开销通常相当低，有些算法的开销比其他算法稍大一些。

这些差异可以归因于一个主要因素：训练通常计算量很大。因此，将数据从 CPU 传输到 GPU 的成本以及 cuML Accelerator 开销的机制并不会显著影响运行时间。但即使在这里，人们也可以立即注意到，对于更简单的任务，例如训练 KNeighbors 模型，开销更为显著。在这种情况下，如果想获得 GPU 的最大性能，直接使用 cuML 会显著更快，尽管需要注意的是，执行时间的差异是秒级计算与毫秒级计算的差异。

同样重要的是要注意数据集形状如何影响这些收益。对于瘦数据集——即特征相对较少但行数较多的数据集——GPU 加速仍然提供了显著的性能提升，尽管对于在 CPU 上已经相当快的简单算法，相对优势可能不那么明显。以下基准测试显示了具有 8 个和 16 个特征的数据集的加速情况。

另一方面，宽数据集真正展示了加速器的优势。高维任务通常需要密集的计算，并且会拖慢基于 CPU 的工作流程。在这种情况下，cuML Accelerator 介入以提供一些最显著的加速，特别是对于降维方法（t-SNE、UMAP）和其他计算密集型操作。以前难以实现的任务，例如在复杂、高维的工作流程中整合 UMAP 和 HDBSCAN，现在 得益于 cuML 和 cuml.accel 的帮助下变得很容易实现。以下基准测试显示了具有 128、256 和 512 个特征的数据集的这些加速情况。

推理

虽然加速器也能加快推理速度，但绝对收益往往较小，因为推理本身通常比训练快得多。尽管如此，2×–7× 的改进（如 KNeighbors 或 RandomForest）对于运行大规模或实时预测至关重要。特别是对于大批量或重复推理场景，GPU 加速可以提供显著价值。

对于较小的数据集，数据传输在总运行时间中所占的比例更大，这意味着特别是对于许多微小批次，开销可能会消耗掉在 GPU 上运行加速算法的大部分（或全部！）收益。在这些情况下，避免不必要的数据传输尤为重要，例如通过显式地将输入和输出保留在 GPU 上，例如以 cupy 数组的形式。这在加速器模式下是不可能的，因此对于这些工作流程，可能更建议使用 GPU 原生数据类型直接调用 cuML，以保留这些加速。

总的来说，这些基准测试强调了 cuML Accelerator 如何大幅缩短各种机器学习任务的训练时间，并且仍然提供显著的推理改进，所有这些都无需更改现有代码，使其成为端到端 ML 管道和工具的引人注目的选择。

由于这是第一个 Beta 版本，性能优化和算法覆盖是一个活跃的领域，将在下一个 RAPIDS 版本中得到改进。