LightGBM比XGBoost快的核心在于GOSS和EFB：GOSS按梯度绝对值排序，保留top_rate（默认0.2）高梯度样本并随机采样other_rate（默认0.1）小梯度样本加权计算，每轮仅处理约30%样本；EFB将互斥稀疏特征通过位移+加法编码捆绑压缩，降低特征维度，两者协同显著减少冗余计算。
LightGBM 在 Python 中比 XGBoost 快，核心不是“参数调得巧”，而是 GOSS 和 EFB 这两个底层工程机制在训练循环里直接砍掉了大量冗余计算。 它们不依赖用户手动特征工程或调参，只要数据规模稍大（比如行数 >10 万、特征数 >50），默认开启就能生效。但很多人误以为开了 verbose=-1 就算“用对了”，其实 GOSS 和 EFB 的触发条件、影响范围、甚至是否真被启用，都藏在几个关键参数里。
GOSS 是怎么跳过“梯度小”的样本的？
GOSS（Gradient-based One-Side Sampling）不是随机丢样本，而是按当前迭代中每个样本的梯度绝对值排序，保留 top top_rate 的高梯度样本（即残差大、拟合难的样本），再从剩下样本里随机采 other_rate 做补充。这样既保留信息量大的样本，又避免全量扫描。
-
top_rate默认 0.2，other_rate默认 0.1 —— 意味着每轮只处理约 30% 的样本，但精度损失极小（论文称误差增幅 - 它只在
boosting_type='gbdt'下生效；如果用了'rf'（随机森林式提升），GOSS 自动关闭 - 梯度小 ≠ 样本不重要：当
learning_rate设得过大（如 >0.3），低梯度样本可能被错误过滤，导致收敛震荡 - 验证集不受 GOSS 影响 —— 所有验证样本始终参与评估，所以
early_stopping_rounds依然可靠
EFB 如何把互斥特征“捆”成一个桶？
EFB（Exclusive Feature Bundling）针对的是高维稀疏特征（比如 one-hot 后的类别列、文本 n-gram），它检测哪些特征几乎不会同时为非零值（即互斥），然后把它们压缩进同一个整型特征里 —— 不是简单相加，而是位移+加法编码（如 feature_a=1, feature_b=2 → bundled=1 | (2
- 自动启用：只要数据含稀疏模式（如大量 0 值 + 少量离散非零），LightGBM 在构建直方图前就会运行 EFB 预处理
- 不改变特征语义：解包逻辑内置在分裂计算中，
feature_importances_返回的是原始特征名，不是捆绑后的新 ID - 和
categorical_feature冲突：如果某列已声明为类别型，EFB 会跳过它 —— 因为类别特征本身已用最优分割处理，无需再捆 - 内存收益明显：1000 维稀疏特征经 EFB 可压到 200 维以内，直方图内存占用同步下降
为什么有时候开了 GOSS/EFB 也没变快？
这两个技术不是“一开就灵”，它们的加速效果高度依赖数据分布和硬件缓存行为。常见失效场景包括：
立即学习“Python免费学习笔记（深入）”；
- 数据太小（
n_samples ）：GOSS 的采样开销反而超过全量扫描收益；EFB 找不到足够互斥特征对 - 特征全是稠密浮点（如图像 embedding）：EFB 几乎无用，GOSS 效果也弱（梯度分布太均匀）
-
num_threads=1且未设device='cpu'：某些旧版 LightGBM 在 GPU 模式下会静默禁用 GOSS - 用了
histogram_pool_size限制直方图内存，但设得太小（如MB）：导致频繁刷盘，掩盖了 GOSS/EFB 的计算优势
真正要注意的，是 GOSS 的 top_rate 和 other_rate 并非越大越好 —— 它们和 learning_rate 构成隐式耦合：学习率越小，梯度越平缓，top_rate 就得适当调高，否则容易漏掉关键样本。这个平衡点没法靠文档查到，得看训练日志里每轮的 used_sample_rate 输出值是否稳定在 0.25–0.4 之间。
