XGBoost 分布式训练上 Kubernetes基于 Kubeflow Trainer 的多节点训练完整指南【免费下载链接】xgboostScalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library, for Python, R, Java, Scala, C and more. Runs on single machine, Hadoop, Spark, Dask, Flink and DataFlow项目地址: https://gitcode.com/gh_mirrors/xg/xgboost本指南以 XGBoost 官方教程 doc/tutorials/kubernetes.rst 为核心系统讲解如何借助 Kubeflow Trainer 的xgboost-distributed运行时在 Kubernetes 集群上编排多节点分布式 XGBoost 训练任务。读完本文你将掌握分布式训练的架构原理Collective 协议与 Rabit Tracker、TrainJob与ClusterTrainingRuntime两种资源的配置方法、Python SDK 与kubectl两种作业提交方式以及内存优化、早停、断点续训、日志治理等一系列生产级最佳实践。概述XGBoost 如何在多节点上协同训练XGBoost 原生支持通过Collective通信协议历史上称为 Rabit进行分布式训练。在分布式场景下多个 worker 进程各自持有数据集的一个分片shard并通过 AllReduce 同步直方图histogram的统计信息从而在所有 worker 上达成一致的树分裂决策。Kubeflow Trainer 的 XGBoost 运行时runtime将这一过程在 Kubernetes 上自动化具体职责包括将 worker Pod 以JobSet的形式部署自动注入 XGBoost Collective 通信层所需的DMLC_*环境变量向 rank-0 Pod 提供 tracker 地址使你的训练代码能够启动RabitTracker协调各 worker同时支持 CPU 与 GPU 训练负载。从仓库源码可以看到 Collective 通信层的具体实现CommunicatorContext在进入上下文时调用init()、退出时调用finalize()并对外暴露get_rank()、get_world_size()、broadcast()、communicator_print()等分布式原语见 collective.py。RabitTracker类则封装了 tracker 的创建、启动与等待逻辑见 tracker.py本文后面会逐一用到它们。架构四大组件与作业流转Kubernetes 上的分布式 XGBoost 训练架构由以下组件构成TrainJobKubernetes 自定义资源声明训练作业的配置节点数、每节点资源、训练代码。ClusterTrainingRuntime集群级资源定义 XGBoost 运行时模板容器镜像、ML 策略、默认设置。内置运行时名为xgboost-distributed。Trainer Controller将TrainJob与引用的运行时进行解析执行 XGBoost ML 策略注入环境变量并创建底层的JobSet。Worker Pods每个 Pod 运行相同的训练脚本。rank-0 Pod 上的用户训练代码负责启动RabitTracker用于协调。整个作业流转过程可以用下面的图表示┌─────────────────────────────────────────────────────────────────┐ │ User submits TrainJob (SDK or kubectl) │ └──────────────────────────┬──────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Trainer Controller │ │ • Resolves ClusterTrainingRuntime (xgboost-distributed) │ │ • Enforces XGBoost MLPolicy (injects DMLC_* env vars) │ │ • Creates JobSet with worker pods │ └──────────────────────────┬──────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Kubernetes Cluster (Headless Service) │ │ │ │ ┌────────────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Pod: node-0-0 │ │ node-0-1 │ │ node-0-2 │ ... │ │ │ TASK_ID0 │ │ TASK_ID1│ │ TASK_ID2│ │ │ │ (Tracker) │ │ (Worker) │ │ (Worker) │ │ │ └───────┬────────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ └──── Collective Protocol ───────┘ │ └─────────────────────────────────────────────────────────────────┘环境变量运行时自动注入的DMLC_*XGBoost 运行时插件会自动向每个 worker Pod 注入以下环境变量。它们是 XGBoost Collective 协议的原生变量变量说明示例值DMLC_TRACKER_URI运行 tracker 的 rank-0 Pod 的 DNS 地址myjob-node-0-0.myjobDMLC_TRACKER_PORTtracker 通信端口29500DMLC_TASK_IDworker 的 rank由 Pod completion index 推导0、1、2、...DMLC_NUM_WORKER所有节点上的 worker 总数4这些环境变量是保留变量用户不能在TrainJobspec 中手动设置。运行时插件会做校验任何试图覆盖它们的TrainJob都会被拒绝。从源码看xgboost.collective.init()正是通过dmlc_tracker_uri、dmlc_tracker_port、dmlc_task_id等参数初始化通信组见 collective.py 中init的参数说明这与你从环境变量中读到的值一一对应。Worker 数量计算DMLC_NUM_WORKER如何确定worker 总数DMLC_NUM_WORKER的计算公式为DMLC_NUM_WORKER numNodes × workersPerNode其中workersPerNode由训练类型决定CPU 训练每节点 1 个 worker。XGBoost不会为 CPU 训练派生多个 worker 进程而是由单个 worker 进程使用 OpenMP 在节点所有可用 CPU 核上并行构建树直方图构建、分裂评估等。也就是说如果一个 Pod 有 8 个 CPU 核那么 1 个 XGBoost worker 会使用全部 8 核做进程内并行。线程数可以通过 Booster 参数nthread控制# 默认情况下XGBoost 使用所有可用的 CPU 核。 # 设置 nthread 可限制每个 worker 的 OpenMP 线程数。 params { objective: binary:logistic, nthread: 4, # 只使用可用核中的 4 个 tree_method: hist, }DMatrix构造函数中的nthread参数控制数据加载阶段的并行度而 Booster 参数中的nthread控制训练阶段的并行度。若都不设置两者默认取机器上可用的最大线程数。提示在TrainJob中设置resourcesPerNode的 CPU requests 时请将nthread与 CPU requests 对齐以避免超额订阅over-subscription。例如如果你申请了cpu: 4就在训练参数中设置nthread: 4。GPU 训练每 GPU 1 个 worker。GPU 数量从TrainJob或运行时模板的resourcesPerNodelimits 中推导。分布式环境下请使用devicecuda而非cuda:ordinalGPU ordinal 的选择由分布式框架处理指定 ordinal 会报错。常见配置下的 worker 数量对照配置numNodesworkersPerNodeDMLC_NUM_WORKER4 节点纯 CPU4142 节点每节点 4 GPU2481 节点8 GPU188前置条件在 Kubernetes 上运行分布式 XGBoost 作业前请确保满足以下条件Kubernetes 集群一个正在运行的 Kubernetes 集群v1.27。可以使用kind、minikube或托管 Kubernetes 服务GKE、EKS、AKS。kubectlKubernetes CLI 工具并已配置连接你的集群。Kubeflow Trainer在集群上安装 Kubeflow Trainer 及其依赖JobSet。安装控制面包含 JobSetkubectl apply --server-side -k github.com/kubeflow/trainer/manifests/overlays/standaloneKubeflow Python SDK可选用于以编程方式提交作业pip install kubeflowGPU 支持可选用于 GPU 训练确保集群上安装了 NVIDIA GPU Operator 或等效的 device plugin。验证安装安装 Kubeflow Trainer 后验证 XGBoost 运行时是否可用kubectl get clustertrainingruntime你应该能看到xgboost-distributed运行时NAME AGE xgboost-distributed 1mXGBoost ClusterTrainingRuntimexgboost-distributedClusterTrainingRuntime随 Kubeflow Trainer 安装一起部署它定义了默认的 XGBoost 运行时模板apiVersion: trainer.kubeflow.org/v1alpha1 kind: ClusterTrainingRuntime metadata: name: xgboost-distributed labels: trainer.kubeflow.org/framework: xgboost spec: mlPolicy: numNodes: 1 xgboost: {} template: spec: replicatedJobs: - name: node template: metadata: labels: trainer.kubeflow.org/trainjob-ancestor-step: trainer spec: template: spec: containers: - name: node image: ghcr.io/kubeflow/trainer/xgboost-runtime:latest关键点mlPolicy.xgboost: {}激活 XGBoost 运行时插件该插件负责注入DMLC_*环境变量numNodes默认为1可被每个TrainJob覆盖容器镜像ghcr.io/kubeflow/trainer/xgboost-runtime:latest基于nvidia/cuda:12.4.0-runtime-ubuntu22.04包含支持 CUDA 12 的 XGBoost 3.0.2、NumPy 和 scikit-learn。实战示例分布式 XGBoost 训练本节演示两种运行分布式 XGBoost 训练的方式使用 Python SDK推荐用于交互式使用和使用kubectl YAML 清单。方式一Python SDKKubeflow Python SDK 提供了TrainerClient可以编程方式简化作业的提交与管理。第 1 步定义训练函数编写将在每个 worker 节点上被序列化并执行的训练函数。DMLC_*环境变量由运行时自动注入def xgboost_train_classification(): Distributed XGBoost training function using the Collective API. DMLC_* env vars are injected by the Kubeflow Trainer XGBoost plugin: - DMLC_TRACKER_URI: DNS name of the rank-0 pod running the tracker - DMLC_TRACKER_PORT: Port for tracker communication (default: 29500) - DMLC_TASK_ID: Worker rank (0, 1, 2, ...) - DMLC_NUM_WORKER: Total number of workers import os import xgboost as xgb from xgboost import collective as coll from xgboost.tracker import RabitTracker from sklearn.datasets import make_classification from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score # Read injected environment variables. rank int(os.environ[DMLC_TASK_ID]) world_size int(os.environ[DMLC_NUM_WORKER]) tracker_uri os.environ[DMLC_TRACKER_URI] tracker_port int(os.environ[DMLC_TRACKER_PORT]) # Rank 0 starts the Rabit tracker (required for coordination). tracker None if rank 0: tracker RabitTracker( host_ip0.0.0.0, n_workersworld_size, porttracker_port ) tracker.start() # All workers connect to the tracker via the Collective communicator. with coll.CommunicatorContext( dmlc_tracker_uritracker_uri, dmlc_tracker_porttracker_port, dmlc_task_idstr(rank), ): # Generate synthetic classification data. # In practice, each worker would load its own data shard. X, y make_classification( n_samples10000, n_features20, n_informative10, n_classes2, random_state42 rank, ) X_train, X_valid, y_train, y_valid train_test_split( X, y, test_size0.2, random_state42, ) # NOTE: DMatrix construction MUST be inside the communicator context # because it involves cross-worker synchronization for quantization. # # Use QuantileDMatrix instead of DMatrix for the hist tree method # (the default). QuantileDMatrix quantizes data on-the-fly, avoiding # an intermediate dense copy and significantly reducing memory usage. dtrain xgb.QuantileDMatrix(X_train, labely_train) # Validation QuantileDMatrix must reference the training matrix # so that the same quantile bins are reused. dvalid xgb.QuantileDMatrix(X_valid, labely_valid, refdtrain) # Training parameters. params { objective: binary:logistic, max_depth: 6, eta: 0.1, eval_metric: logloss, } # Distributed training - workers synchronize histogram stats via collective ops. # early_stopping_rounds activates early stopping based on the validation metric. # verbose_eval10 prints evaluation results every 10 rounds (rank 0 only). model xgb.train( params, dtrain, num_boost_round100, evals[(dvalid, validation)], early_stopping_rounds10, verbose_eval10, ) # Note: early_stopping_rounds returns the *last* model, not the best. # Use bst.best_iteration to slice the model to the best round. if hasattr(model, best_iteration): model model[: model.best_iteration 1] # Evaluate on validation set. preds model.predict(dvalid) predictions [1 if p 0.5 else 0 for p in preds] accuracy accuracy_score(y_valid, predictions) # Only perform logging and model saving from rank 0 # to avoid duplicate output and file write conflicts. if coll.get_rank() 0: print(fValidation Accuracy: {accuracy:.4f}) model.save_model(/workspace/xgboost_model.json) print(Model saved to /workspace/xgboost_model.json) # Wait for tracker to finish (rank 0 only). if tracker is not None: tracker.wait_for()这里有几个值得注意的源码细节RabitTracker.start()启动 tracker 服务而wait_for()会阻塞等待 tracker 完成全部工作后关闭见 tracker.py因此必须在所有 worker 训练结束后再调用coll.CommunicatorContext进入时调用init()、退出时调用finalize()且get_rank()/get_world_size()只在上下文内有效见 collective.py这就是为何数据矩阵构造、训练与模型保存都必须放在上下文内部的根本原因。第 2 步提交训练作业使用TrainerClient将训练函数作为分布式作业提交from kubeflow.trainer import CustomTrainer, TrainerClient client TrainerClient() # Submit a distributed XGBoost training job on 3 nodes. job_name client.train( trainerCustomTrainer( funcxgboost_train_classification, num_nodes3, resources_per_node{cpu: 3}, ), runtimexgboost-distributed, ) print(fTrainJob {job_name} submitted)GPU 训练时在资源中指定 GPUjob_name client.train( trainerCustomTrainer( funcxgboost_train_classification, num_nodes2, resources_per_node{ cpu: 4, gpu: 4, # 4 GPUs per node → 8 total workers }, ), runtimexgboost-distributed, )注意GPU 训练时请在训练函数的 XGBoostparams字典中加入device: cuda。第 3 步监控训练作业检查作业状态并查看日志# Wait for the job to start running. client.wait_for_job_status(namejob_name, status{Running}) # Check the steps (one per worker node). for step in client.get_job(namejob_name).steps: print(fStep: {step.name}, Status: {step.status}) # Stream logs from each worker node. num_nodes 3 for i in range(num_nodes): logs client.get_job_logs(namejob_name, followTrue, stepfnode-{i}) print(f\n Node {i} ) print(\n.join(logs))第 4 步清理训练结束后删除作业client.delete_job(job_name)方式二kubectl YAML你也可以直接用kubectl创建TrainJob资源。CPU 训练示例下面的 YAML 创建一个 4 个 worker 节点的分布式 XGBoost 训练作业apiVersion: trainer.kubeflow.org/v1alpha1 kind: TrainJob metadata: name: xgboost-cpu-example spec: runtimeRef: name: xgboost-distributed trainer: image: ghcr.io/kubeflow/trainer/xgboost-runtime:latest command: - python - train.py numNodes: 4 resourcesPerNode: requests: cpu: 4 memory: 8Gi应用清单kubectl apply -f xgboost-cpu-trainjob.yamlGPU 训练示例多节点 GPU 训练时通过resourcesPerNode指定 GPU 资源apiVersion: trainer.kubeflow.org/v1alpha1 kind: TrainJob metadata: name: xgboost-gpu-example spec: runtimeRef: name: xgboost-distributed trainer: image: ghcr.io/kubeflow/trainer/xgboost-runtime:latest command: - python - train.py numNodes: 2 resourcesPerNode: limits: nvidia.com/gpu: 4 requests: cpu: 4 memory: 16Gi使用该配置运行时计算出的DMLC_NUM_WORKER 2 节点 × 4 GPU 8。每个 GPU 运行一个 XGBoost worker 进程。使用 kubectl 监控# 查看 TrainJob 状态 kubectl get trainjob xgboost-cpu-example # 查看某个 worker Pod 的日志 kubectl logs xgboost-cpu-example-node-0-0 # 删除 TrainJob kubectl delete trainjob xgboost-cpu-example工作原理运行时插件内部机制XGBoost 运行时插件XGBoost 运行时以 Go 插件的形式实现于 Kubeflow Trainer controller 中见 Trainer 仓库的pkg/runtime/framework/plugins/xgboost/。它实现了两个接口EnforceMLPolicyPlugin注入DMLC_*环境变量见上文「环境变量」小节并暴露容器端口29500CustomValidationPlugin拒绝任何手动设置保留DMLC_*环境变量的TrainJob。Tracker 发现机制worker 通过 Kubernetes headless service 发现 rank-0 上的RabitTracker。DMLC_TRACKER_URI的构造规则为trainjob-name-node-0-0.trainjob-name例如一个名为myjob、含 4 个节点的TrainJob会创建如下 Podmyjob-node-0-0 DMLC_TASK_ID0 (Tracker Worker) myjob-node-0-1 DMLC_TASK_ID1 (Worker) myjob-node-0-2 DMLC_TASK_ID2 (Worker) myjob-node-0-3 DMLC_TASK_ID3 (Worker)注意启动 tracker 是用户的责任。运行时只负责注入环境变量rank-0 上的训练代码必须在其他 worker 连接之前调用RabitTracker(...).start()。最佳实践使用 QuantileDMatrix 降低内存占用默认树方法为histtree_methodauto会解析为hist。使用hist时推荐用xgboost.QuantileDMatrix而非xgboost.DMatrix。QuantileDMatrix直接从输入生成分位数化数据跳过中间稠密表示显著降低内存消耗类定义见 core.py# 标准 DMatrix —— 先加载数据再分位数化峰值内存更高 dtrain xgb.DMatrix(X_train, labely_train) # QuantileDMatrix —— 边加载边分位数化峰值内存更低 dtrain xgb.QuantileDMatrix(X_train, labely_train)构造验证集QuantileDMatrix时务必把训练矩阵作为ref传入让 XGBoost 复用相同的分位数桶。验证数据省略ref可能导致分位数化不一致进而降低模型质量dtrain xgb.QuantileDMatrix(X_train, labely_train) dvalid xgb.QuantileDMatrix(X_valid, labely_valid, refdtrain) # 正确注意QuantileDMatrix自 XGBoost 1.7.0 引入。无需显式指定tree_method—— 默认的auto已经使用hist。早停Early Stopping向xgboost.train传入early_stopping_rounds即可激活早停。它要求evals中至少有一个验证集。当验证指标在连续指定轮数内不再提升时训练停止model xgb.train( params, dtrain, num_boost_round500, evals[(dvalid, validation)], early_stopping_rounds10, )早停在分布式模式下同样正确工作——验证指标已经通过 collective 协议在 worker 之间同步。重要带early_stopping_rounds的xgb.train返回的是最后一个模型而不是最优模型。要拿到最优模型请使用模型切片# 训练后仅保留到最佳迭代轮的轮次 if hasattr(model, best_iteration): model model[: model.best_iteration 1]或者直接使用xgboost.callback.EarlyStopping回调并设置save_bestTrue自动只保留最优模型from xgboost.callback import EarlyStopping model xgb.train( params, dtrain, num_boost_round500, evals[(dvalid, validation)], callbacks[EarlyStopping(rounds10, save_bestTrue)], ) # model 现在只包含到最佳迭代轮的轮次当evals提供了多个评估数据集时使用最后一个条目进行早停当指定了多个eval_metric时使用最后一个指标。分布式模式下的日志分布式训练中print()会在每个 worker 上执行产生重复日志行。若要只从单个 worker 打印用 rank 检查守卫from xgboost import collective as coll with coll.CommunicatorContext(...): # 只从 rank 0 打印 if coll.get_rank() 0: print(fTraining complete, best score: {model.best_score})xgboost.collective.communicator_print是另一个选择它把消息经 tracker 转发而非输出到 stdout。注意它不会按 rank 过滤——任何调用它的 worker 的消息都会被 tracker 打印。它主要用于内部场景例如verbose_eval其自带 rank-0 守卫通过xgboost.callback.EvaluationMonitor实现见 callback.py。生产环境设置 verbose_eval在分布式 Kubernetes 作业中把verbose_eval设为整数而非True以降低日志量model xgb.train( params, dtrain, num_boost_round500, evals[(dvalid, validation)], verbose_eval50, # 每 50 轮打印一次而不是每轮 )断点续训CheckpointingXGBoost 提供了xgboost.callback.TrainingCheckPoint回调见 callback.py在训练过程中周期性地保存模型快照。该回调只会从 rank 0 保存避免多个 worker 写入同一路径from xgboost.callback import TrainingCheckPoint model xgb.train( params, dtrain, num_boost_round500, evals[(dvalid, validation)], callbacks[ TrainingCheckPoint( directory/workspace/checkpoints, namexgb_model, interval50, # 每 50 轮保存一次 ), ], )警告XGBoost 不处理分布式文件系统。directory路径必须能从 rank-0 Pod 写入——例如挂载到 Pod 中的 Kubernetes PersistentVolumeClaim。从检查点恢复训练时通过xgb_model传入已保存的模型文件model xgb.train( params, dtrain, num_boost_round500, xgb_model/workspace/checkpoints/xgb_model_200.ubj, # 从第 200 轮恢复 evals[(dvalid, validation)], )数据划分默认情况下分布式 XGBoost 作业中每个 worker 持有数据行的不同子集水平划分且只支持按行的数据拆分。这种模式下每个 worker 加载自己的数据分片with coll.CommunicatorContext(...): # 每个 worker 根据其 rank 加载不同的数据分片 rank coll.get_rank() X_shard, y_shard load_data_shard(rank) dtrain xgb.QuantileDMatrix(X_shard, labely_shard)按列拆分已经被移除分布式训练使用按行划分。与 rank 相关的逻辑在通信上下文内使用xgboost.collective.get_rank和xgboost.collective.get_world_size执行与 rank 相关的操作with coll.CommunicatorContext(...): if coll.get_rank() 0: model.save_model(/workspace/model.json) # 如需向所有 worker 广播结果 results coll.broadcast(results, root0)xgboost.collective.broadcast可以把任意可 pickle 的 Python 对象从一个 worker 广播到所有其他 worker。这在共享 rank 0 上计算的预处理元数据如标签编码器、特征名列表时非常有用。常见问题与边界情况保留环境变量运行时插件会拒绝任何手动设置保留DMLC_*环境变量DMLC_TRACKER_URI、DMLC_TRACKER_PORT、DMLC_TASK_ID、DMLC_NUM_WORKER的TrainJob。如果你在spec.trainer.env中设置了其中任何一个webhook 会返回Forbidden错误spec.trainer.env[0]: Forbidden: DMLC_TRACKER_URI is reserved for the XGBoost runtime请从TrainJobspec 中移除这些保留变量让运行时自动注入。trainer 为空时不注入环境变量如果TrainJob不包含spec.trainer段XGBoost 插件会完全跳过环境变量注入。DMLC_*变量只有在spec.trainer存在且运行时能在 Pod 模板中找到node容器时才会被注入。请确保TrainJob包含trainer字段。资源优先级TrainJob 覆盖运行时当 GPU 资源同时出现在ClusterTrainingRuntime模板和TrainJob.spec.trainer.resourcesPerNode中时TrainJob的值优先。这会直接影响workersPerNode的计算Runtime template: nvidia.com/gpu: 1 → workersPerNode 1 TrainJob override: nvidia.com/gpu: 3 → workersPerNode 3 (this wins)如果两者都没有指定 GPU 资源workersPerNode默认为1CPU 模式。分布式模式下的 GPU 设备序号分布式训练中不要在 XGBoost 参数中使用devicecuda:0或任何具体的 GPU ordinal。GPU 设备分配由 Kubernetes device plugin 和分布式框架处理。请使用devicecuda# 正确 params {device: cuda, tree_method: hist} # 错误 —— 分布式模式下会报错 params {device: cuda:0, tree_method: hist}数据矩阵必须位于 CommunicatorContext 内在CommunicatorContext外部构造xgb.DMatrix或xgb.QuantileDMatrix对稠密数据可能看起来正常但行为是未定义的。构造函数会执行跨 worker 同步用于数据形状校验和分位数素描tree_methodhist所需。务必在上下文内部构造数据矩阵# 错误 —— 数据矩阵在上下文之外 dtrain xgb.QuantileDMatrix(X_train, labely_train) with coll.CommunicatorContext(...): model xgb.train(params, dtrain, ...) # 未定义行为 # 正确 —— 数据矩阵在上下文之内 with coll.CommunicatorContext(...): dtrain xgb.QuantileDMatrix(X_train, labely_train) model xgb.train(params, dtrain, ...)单节点默认值如果TrainJob未指定numNodes运行时使用ClusterTrainingRuntime中的默认值xgboost-distributed运行时默认为1。单节点作业仍会走完整的运行时流水线——RabitTracker在 rank-0即唯一 Pod上启动DMLC_NUM_WORKER设为1。这在本地扩展前测试训练函数时很有用。CPU 超额订阅默认情况下XGBoost 通过 OpenMP 使用所有可用 CPU 核。在 Kubernetes Pod 中“可用核数”由容器运行时设置的 cgroup 限制决定。如果你的 Pod 只指定了 CPUrequests没有limitscgroup 可能不会限制 CPU 使用XGBoost 可能会尝试使用节点上的所有核导致与其他 Pod 争抢资源。要避免这种情况可以在 XGBoost 参数中设置nthread使其与 CPU request 匹配在resourcesPerNode中设置 CPUlimits而不只是 requests让容器运行时强制 cgroup 上限。# 同时设置 requests 和 limits确保 XGBoost 看到正确的核数 resourcesPerNode: requests: cpu: 4 limits: cpu: 4小结通过 Kubeflow Trainer 的xgboost-distributed运行时XGBoost 的分布式训练能力被完整地映射到了 Kubernetes 生态TrainJob声明作业意图ClusterTrainingRuntime提供运行时模板Trainer Controller 注入DMLC_*环境变量并创建 JobSet而用户代码只需在 rank-0 上启动RabitTracker并在CommunicatorContext内完成数据构造与训练。无论是 4 节点的 CPU 作业还是 2 节点 8 GPU 的 GPU 作业遵循本文的配置规则、worker 数量计算方法和最佳实践你都能在 Kubernetes 上稳定、高效地跑通多节点分布式 XGBoost 训练。【免费下载链接】xgboostScalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library, for Python, R, Java, Scala, C and more. Runs on single machine, Hadoop, Spark, Dask, Flink and DataFlow项目地址: https://gitcode.com/gh_mirrors/xg/xgboost创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考