H2O GBM增加核心数后训练速度变慢问题咨询

• 首先是小数据集下并行开销超过实际计算收益：你的训练样本只有6840行95列，数据规模极小。GBM属于顺序训练模型，只能在单棵树的节点计算、直方图构建环节做并行，无法跨树并行。小数据集下单个核心处理单树计算的耗时本身就极短，96核并行时产生的线程调度、数据分片、进程间通信、结果合并的额外开销，已经远远超过了多核心带来的计算增益，反而拖慢整体速度。
• 其次是缓存与内存带宽冲突：2核实例运行时，整个训练数据集可以完全放在CPU的L1/L2缓存中运行，缓存命中率接近100%，内存访问延迟极低。而96核的c5.metal实例所有核心共享三级缓存和内存带宽，多核心同时访问数据时会出现大量缓存失效、内存访问排队的情况，反而拉高了平均内存访问耗时。
• 第三是框架并行策略与 workload 不匹配：主流GBM框架（XGBoost、LightGBM、H2O等）的默认并行粒度是针对万级以上样本量的数据集优化的，你的小数据集下每个线程分到的计算任务量级过小，甚至出现大量核心空转等待任务分配的情况，无意义消耗了调度资源。再加上你设置的sample_rate=0.5，每棵树实际仅用3000多行样本训练，单核心处理的速度远高于多核心分片计算再合并的速度。
• 最后是超参数的放大效应：你设置的max_depth=50看起来数值很高，但受限于小数据集和min_rows=10的限制，实际生成的树的节点数非常少，完全喂不饱96核的计算资源，进一步降低了并行效率。

内容的提问来源于stack exchange，提问作者Shaun Lebron