倚天遇到屠龙：LightGBM VS xgboost谁才是最强的梯度提升库？

更多深度文章，请关注云计算频道：https://yq.aliyun.com/cloud

作者介绍：Laurae ，数据科学爱好者

Blog:https://medium.com/@Laurae2

背景知识：

XGBoost是一款经过优化的分布式梯度提升（Gradient Boosting）库，具有高效，灵活和高可移植性的特点。基于梯度提升框架，XGBoost实现了并行方式的决策树提升(Tree Boosting)，从而能够快速准确地解决各种数据科学问题。

LightGBM（Light Gradient Boosting Machine）同样是一款基于决策树算法的分布式梯度提升框架。

这篇博客是关于LightGBM 和xgboost 的对比。实验使用了定制的博世数据集，结果显示，在速度上xgboost 比LightGBM在慢了10倍，而我们还需要做一些其它方面的比较。

总体介绍

首先让我们来看一下这个图表，所有人都应该打起精神!!!

从图上我们可以看到，平均来说，LightGBM 比xgboost 快11到15倍。

我们也注意到，随着线程数的增加，比率变小了。这也很容易解释，因为你不可能让线程的利用率是100%，线程的切入切出以及线程有时要等待，这都需要耗费很多时间。

1–12 个线程

我们来看一下前12个线程。

从表中，我们可以看到，当线程数超过6的时候xgboost的性能得到了很大的提升（当线程数是12的时候，消耗时长从577.9降低到414.3秒，大约提高了28.3%）。

对于LightGBM来说是否也是这样呢？时间从45.1降低到了33.6秒，性能提高大约25.5%。

小结：使用所有逻辑核心进行线程化，这能极大地提高性能。如果你希望你的机器学习训练速度提高25％（显然，根据CPU的不同，情况也不完全一样），你现在知道该做什么：使用逻辑核心，而不是物理核心来创建线程。

13–24 个线程

那么13-24个线程又会怎么样呢？我们增加12个线程作为参照。

我们可以注意到：

对于xgboost来说并没有提升，数值的变化基本可以看成是误差
对于LightGBM来说反而耗时更长，从33.6秒提高到38秒以上

所以我们可以简单的下一个结论：不要过度分配逻辑内核，这不是一个好的做法。保持使用逻辑核心创建一定量的线程，并且不要超过该数。

LightGBM 一瞥

我们再来关注一下LightGBM的曲线。

从图上来看，这似乎是一个线性的改进：从202秒（使用1个核，1个线程），我们下降到33.6秒（6个全部使用的，12个线程），这是几乎100％的多线程的效率。当我们用更多的线程时，多线程的效率急剧下降，使用的时间反而比一千场了。

数据存储器的效率

在创建矩阵后使用gc方法两次来快速查看RAM使用情况，具体情况如下：

初始数据（密集，未使用）：约8,769 MB（27.9％vs原始版本）
原始数据（dgCMatrix）：大约 2,448 MB（100％vs原始版本）
xgboost（xgb.DMatrix）：大约 1,701 MB（69.5％vs原始版本）
LightGBM（lgb.Dataset）：大约2,512 MB（102.6％vs原始版本）

看来LightGBM具有比xgboost更高的内存占用。

训练存储器的效率

我们使用12个线程来检查RAM效率，在50次boosting迭代结束时，在boosting之前使用gc，boosting之后不使用gc，效果如下：

xgboost：约 1684 MB

LightGBM： 1425 MB（xgboost内存使用量的84.6％）

我们可以注意到，LightGBM在训练期间的RAM使用率较低，但是内存中数据的RAM使用量增加。所以R语言的LightGBM包有改进的潜能，以具有更有效的方式来存储数据。

下一个指标

当xgboost的快速直方图方法启动并在R语言中可用时，我们会使用新的指标。虽然它目前正在运行，但在R语言中不可用。这样一来xgboost和LightGBM孰优孰劣到时就会揭晓。

当然，未来我们也会比较xgboost和lightgbm之间的对数损失。

数十款阿里云产品限时折扣中，赶紧点击领劵开始云上实践吧！

以上为译文

本文由北邮@爱可可-爱生活老师推荐，阿里云云栖社区组织翻译。

文章原标题《Benchmarking LightGBM: how fast is LightGBM vs xgboost?》，作者：Laurae，译者：爱小乖

文章为简译，更为详细的内容，请查看原文