人工智能深度学习大模型微调LoRAAutoML【免费下载链接】ludwigLow-code framework for building custom LLMs, neural networks, and other AI models项目地址https://gitcode.com/gh_mirrors/lu/ludwig点击查看免费下载本篇技术指南围绕 Ludwig 官方示例 examples/ray/job_submission 展开讲解如何用 Ray Job Submission 取代 Ray Client 模式把 Ludwig 训练任务提交到远程 Ray 集群KubeRay、Anyscale 或任意 Ray 集群上执行。读完本文你将掌握submit_job.py提交脚本与train_on_cluster.py集群训练脚本的完整工作原理、命令行用法、数据访问规范与自定义扩展方式并能直接基于本仓库示例搭建一套可运行的远程分布式训练流程。一、为什么放弃 Ray Client 改用 Ray Job Submission在 Ludwig 的分布式训练场景中传统做法是在本地机器上通过ray.init(ray://head:10001)以 Ray Client 模式连接远程集群。这种模式在实际使用中有一个已知痛点与ray.data相关的算子存在兼容性问题在分布式训练过程中容易触发OwnerDiedError之类的异常导致任务中断。Ray Job Submission 正是为了解决这一问题而生的替代方案训练脚本不再在本地连接集群而是整体上传到集群的 head 节点上直接运行。由于ray.init()在集群内部完成本地连接ray.data的算子得以在集群环境中正常工作从根源上绕开了 Ray Client 模式的缺陷。从仓库源码看Ludwig 的 Ray 后端本身就为集群内执行做了专门设计。ludwig/backend/ray.py 中定义了RayBackend(RemoteTrainingMixin, Backend)其BACKEND_TYPE ray具备distributedTrue、hyperoptTrue、cache_preprocessingTrue等能力initialize()方法会调用initialize_ray()完成 Ray 运行时初始化。这意味着只要训练脚本运行在集群内Ludwig 就能自动识别 Ray 环境并把预处理、训练、超参搜索等环节分布到各 worker 上。二、工作机制与整体架构整个流程可以用下图概括沿用原文档的架构示意Your machine Ray Cluster ------------------ ------------------ | submit_job.py | --- uploads --- | train_on_cluster.py | config.yaml | config | (runs on head node) | | script | ray.init() is local | | -- streams --- | ludwig.train() | | logs back | saves to S3/NFS ------------------ ------------------完整执行链路共五步submit_job.py在本地机器笔记本、CI 服务器等上运行通过 Ray Job Submission API 把配置文件和训练脚本上传到集群train_on_cluster.py作为 Ray Job 的入口在集群 head 节点上执行训练脚本内的ray.init()在集群内部完成本地连接不再使用 Client 模式Ludwig 通过其 Ray 后端在集群各 worker 之间正常分发训练任务训练完成的模型保存到共享存储S3/GCS/NFS本地机器可随时取回。examples/README.md的目录说明中也将该示例定位为通过 Ray Job Submission 向远程 Ray 集群提交 Ludwig 训练规避 Ray Client 与 ray.data 的问题适用于 KubeRay、Anyscale 或任意 Ray 集群。三、三个核心文件详解示例目录 examples/ray/job_submission 下共三个文件分别承担提交、执行与配置三个职责。1. submit_job.py本地提交端submit_job.py 运行在本地机器上核心逻辑集中在submit()函数中submit_job.py建立客户端并构造运行时环境脚本使用ray.job_submission模块的JobSubmissionClient连接 Ray Dashboard 地址默认端口 8265见 submit_job.py。随后构造runtime_envworking_dir指向脚本所在目录Ray 会把该目录下的本地文件配置文件 训练脚本整体上传到集群env_vars通过环境变量把CONFIG_PATH、DATASET_PATH、OUTPUT_DIR三个参数传递给集群内的训练脚本pip可选当指定--pip参数时Ray 会在 Job 启动时先在集群上安装这些 Python 包见 submit_job.py。配置文件同步脚本会把本地 config 复制到脚本目录确保它随working_dir一起上传见 submit_job.py。提交 Job 并流式回传日志入口命令固定为python train_on_cluster.py可选entrypoint_num_gpus为 head 节点上的驱动脚本预留 GPU见 submit_job.py。提交后脚本进入日志轮询循环每隔 2 秒查询一次 Job 状态增量打印新产生的日志直到 Job 进入SUCCEEDED、FAILED或STOPPED终态失败时还会尝试读取error_type与错误信息见 submit_job.py。2. train_on_cluster.py集群训练端train_on_cluster.py 是 Ray Job 的入口脚本运行在 head 节点上。它通过环境变量接收参数见 train_on_cluster.pyCONFIG_PATHLudwig 配置路径默认config.yamlDATASET_PATH数据集路径必须设置为集群可访问的 S3/GCS/NFS/HDFS 路径缺失时脚本直接报错退出OUTPUT_DIR模型输出目录默认/tmp/ludwig_results。脚本读取 YAML 配置后用LudwigModel(configconfig)构造模型再调用model.train(datasetdataset_path, output_directoryoutput_dir)启动训练见 train_on_cluster.py。关键点在于远程 URIs3://、gs://等由 Ludwig 通过 fsspec 透明读取无需本地下载训练完成后脚本从train_stats.validation中提取每个输出特征的验证指标把最优值loss 取最小、其余取最大打印到 Job 日志中方便直接查看训练效果见 train_on_cluster.py。3. config.yaml示例训练配置config.yaml 是一个可直接运行的 Ludwig 配置示例模拟了经典收入预测二分类任务input_features: - name: age type: number - name: workclass type: category - name: education type: category - name: occupation type: category - name: hours-per-week type: number - name: capital-gain type: number output_features: - name: income type: binary combiner: type: ft_transformer hidden_size: 128 num_heads: 8 num_layers: 2 trainer: epochs: 50 batch_size: 256 early_stop: 10 learning_rate: 0.0001 optimizer: type: adamw该配置包含 4 个类别特征与 3 个数值特征输出为二分类目标组合器采用 FT Transformer隐藏维度 128、8 头注意力、2 层训练器设置 50 轮、batch size 256、早停耐心 10 轮、学习率 1e-4优化器选用 AdamW。配置中特别注明无需手动指定backend: {type: ray}。当脚本运行在 Ray 集群上时Ludwig 会自动检测 Ray 环境并使用分布式后端这一点与 ludwig/backend/ray.py 中get_trainer_kwargs()的实现吻合——它会根据ray.cluster_resources()自动探测集群 GPU 数量有 GPU 时按 GPU 数量分配 worker 并设置resources_per_worker为{CPU: 0, GPU: 1}无 GPU 时按节点数分配 CPU worker。这也是替换成你自己的配置即可能直接生效的底层原因。四、环境准备前提条件本地机器执行提交脚本只需安装 Ray 默认套件pip install ray[default]Ray 集群需要安装 Ludwig 的分布式扩展pip install ludwig[distributed]如果集群上尚未预装也可以在提交 Job 时用--pip ludwig[distributed]让 Ray 在 Job 启动阶段现场安装——代价是每次提交都会增加约 2~5 分钟冷启动时间。原文档建议生产环境尽量在集群镜像中预装 Ludwig。若使用容器方式部署集群本仓库提供了现成镜像构建入口例如 docker/ludwig-ray/Dockerfile 与 docker/ludwig-ray-gpu/Dockerfile对应镜像即上文 KubeRay 集群 YAML 中所引用的ludwigai/ludwig-ray:master与ludwigai/ludwig-ray-gpu:master。五、完整使用流程与命令详解基础用法python submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/--ray-addressRay Dashboard 地址HTTP 协议端口 8265--config本地 Ludwig 配置路径会被上传到集群--dataset集群侧可访问的数据集路径--output-dir模型输出目录默认/tmp/ludwig_results。提交到 KubeRay 集群KubeRay 集群的 head 服务名一般为ray-head命名空间为ray因此地址写作python submit_job.py \ --ray-address http://ray-head.ray.svc:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/在 Job 启动时现场安装 Ludwigpython submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir /shared/nfs/results/ \ --pip ludwig[distributed]提交后不等待、直接返回python submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/ \ --no-follow使用--no-follow时脚本打印 Job ID 后立即退出并提示后续可用ray job status job_id --address ray-address查询状态、用ray job logs job_id --address ray-address --follow跟进日志见 submit_job.py。对于长时间训练任务这种提交即走的方式更为稳妥。CLI 参数速查表参数必填默认值说明--ray-address是无Ray Dashboard 地址如http://ray-head:8265--config是无本地 Ludwig YAML 配置路径随 Job 上传--dataset是无集群可访问的数据集路径s3://、gs://、/nfs/...--output-dir否/tmp/ludwig_results集群上的结果输出目录--pip否无Job 启动时在集群安装的 pip 包可传多个--num-gpus否无为 head 节点驱动脚本预留的 GPU 数量浮点数--no-follow否False不流式跟进日志打印 Job ID 后退出六、数据访问与共享存储使用本方案最关键的一条约束是数据集必须从集群侧可访问而不是从本地机器访问。原因在于训练脚本在集群 head 节点上运行model.train()读取的dataset路径最终由集群内的 worker 通过 fsspec 或本地文件系统解析。存储类型示例路径说明S3s3://bucket/data.csv集群需要配置 AWS 凭据GCSgs://bucket/data.csv集群需要配置 GCP 凭据NFS/shared/data/train.csv需挂载到集群所有节点HDFShdfs://namenode/data.csv需运行 Hadoop 集群如果数据目前在本地需要先上传到集群可访问的存储例如aws s3 cp my_data.csv s3://my-bucket/data/my_data.csv然后在提交命令中把--dataset指向s3://my-bucket/data/my_data.csv。模型输出同理--output-dir指向 S3/GCS/NFS 等共享存储后训练产物对本地提交方自动可见。KubeRay 集群若需访问 S3 等远程文件系统可在集群镜像中补充s3fs、adlfs、gcsfs等库并通过环境变量注入凭据详见 examples/ray/kubernetes/README.md。七、自定义与进阶配置使用自己的配置原文档明确指出config.yaml只是一个示例任何合法的 Ludwig 配置都可以直接替换使用。替换后保持--config指向你的配置文件即可其余流程完全不变。得益于 Ludwig 对 Ray 环境的自动检测见上文get_trainer_kwargs()的 GPU 探测逻辑你无需在配置里显式声明分布式后端。为驱动脚本请求 GPU部分训练脚本需要在 head 节点上使用 GPU例如加载模型做推理预热。此时用--num-gpus 1为入口脚本预留 GPUpython submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/ \ --num-gpus 1该参数对应 Ray Job 提交时的entrypoint_num_gpus只作用于 head 节点的驱动脚本实际训练 worker 的 GPU 由 Ludwig 的 Ray 后端配置自行按需申请见 submit_job.py。自定义运行时环境如需更复杂的运行环境Conda 环境、容器镜像、额外环境变量等直接编辑 submit_job.py 中的runtime_env字典按 Ray 的runtime_env规范增加conda、container、env_vars等选项即可。当前实现已经通过env_vars传递了三个关键参数你可以在此基础上扩展。八、与 Kubernetes / KubeRay 结合本仓库在 examples/ray/kubernetes 目录下提供了完整的 KubeRay 集群管理脚本。快速上手路径通过kubectl get nodes确认已连接 Kubernetes 集群在 examples/ray/kubernetes/clusters 下选择集群模板例如导出CLUSTER_NAMEludwig-ray-gpu-cluster运行./utils/ray_up.sh $CLUSTER_NAME启动集群运行./utils/dashboard.sh $CLUSTER_NAME后访问http://localhost:8267打开 Ray Dashboard训练结束后用./utils/ray_down.sh $CLUSTER_NAME关闭集群。以 ludwig-ray-gpu-cluster.yaml 为例集群 head 与 worker 均使用ludwigai/ludwig-ray-gpu:master镜像head 节点暴露了 8265dashboard即 Job Submission 的--ray-address端口、10001client、6379redis等端口GPU 通过nvidia.com/gpu资源声明。该 YAML 中的 head 服务地址正是前面 KubeRay 提交示例中http://ray-head.ray.svc:8265的来源。需要特别说明的是KubeRay 场景下更常见的做法是直接用ray job submit命令或./utils/submit.sh提交任务而本示例的价值在于把提交与训练拆分为两个独立的 Python 脚本并在submit_job.py中内置了配置上传、环境变量传递与日志流式回传使 Job Submission 流程可以嵌入到任意 CI/调度系统中复用。结语Ray Job Submission 为 Ludwig 的远程分布式训练提供了一条稳定、可工程化的路径本地只负责提交与观测训练完全在集群内闭环执行从而绕开 Ray Client 模式下ray.data的已知问题。结合 submit_job.py、train_on_cluster.py 与 config.yaml 三个文件以及 Ludwig Ray 后端 ludwig/backend/ray.py 的自动资源探测能力你可以快速搭建起一套本地提交、集群训练、共享存储落盘的分布式训练流水线并平滑适配 KubeRay、Anyscale 等任意 Ray 集群环境。赞分享人工智能深度学习大模型微调LoRAAutoML【免费下载链接】ludwigLow-code framework for building custom LLMs, neural networks, and other AI models项目地址https://gitcode.com/gh_mirrors/lu/ludwig点击查看免费下载相关推荐Horovod on Ray 实战指南用 RayExecutor 在 Ray 集群上运行分布式训练Horovod on Ray 实战指南用 RayExecutor 在 Ray 集群上运行分布式训练 导读 本文基于 Horovod 官方文档中 Horovo深度学习机器学习分布式训练Ray Train 分布式 JAX 训练实战指南使用 JaxTrainer 在 GPU 与 TPU 上运行 SPMD 训练Ray Train 分布式 JAX 训练实战指南使用 JaxTrainer 在 GPU 与 TPU 上运行 SPMD 训练 Ray Train 提供的 Jax人工智能分布式训练强化学习任务调度模型推理服务后端使用 Ray Train 的 TorchTrainer 在分布式集群上运行 DeepSpeed 训练ZeRO 优化实战指南使用 Ray Train 的 TorchTrainer 在分布式集群上运行 DeepSpeed 训练ZeRO 优化实战指南 导读 DeepSpeed 是微软人工智能分布式训练强化学习任务调度模型推理服务后端上一篇探索高效Vue 2开发新境界vitejs/plugin-vue2深度揭秘下一篇Tinycast 自签名与自更新发布全流程macOS 启动器的自签名身份 GitHub Actions Homebrew Tap 实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Ludwig 分布式训练实战：使用 Ray Job Submission 在远程 Ray 集群上运行训练任务
人工智能深度学习大模型微调LoRAAutoML【免费下载链接】ludwigLow-code framework for building custom LLMs, neural networks, and other AI models项目地址https://gitcode.com/gh_mirrors/lu/ludwig点击查看免费下载本篇技术指南围绕 Ludwig 官方示例 examples/ray/job_submission 展开讲解如何用 Ray Job Submission 取代 Ray Client 模式把 Ludwig 训练任务提交到远程 Ray 集群KubeRay、Anyscale 或任意 Ray 集群上执行。读完本文你将掌握submit_job.py提交脚本与train_on_cluster.py集群训练脚本的完整工作原理、命令行用法、数据访问规范与自定义扩展方式并能直接基于本仓库示例搭建一套可运行的远程分布式训练流程。一、为什么放弃 Ray Client 改用 Ray Job Submission在 Ludwig 的分布式训练场景中传统做法是在本地机器上通过ray.init(ray://head:10001)以 Ray Client 模式连接远程集群。这种模式在实际使用中有一个已知痛点与ray.data相关的算子存在兼容性问题在分布式训练过程中容易触发OwnerDiedError之类的异常导致任务中断。Ray Job Submission 正是为了解决这一问题而生的替代方案训练脚本不再在本地连接集群而是整体上传到集群的 head 节点上直接运行。由于ray.init()在集群内部完成本地连接ray.data的算子得以在集群环境中正常工作从根源上绕开了 Ray Client 模式的缺陷。从仓库源码看Ludwig 的 Ray 后端本身就为集群内执行做了专门设计。ludwig/backend/ray.py 中定义了RayBackend(RemoteTrainingMixin, Backend)其BACKEND_TYPE ray具备distributedTrue、hyperoptTrue、cache_preprocessingTrue等能力initialize()方法会调用initialize_ray()完成 Ray 运行时初始化。这意味着只要训练脚本运行在集群内Ludwig 就能自动识别 Ray 环境并把预处理、训练、超参搜索等环节分布到各 worker 上。二、工作机制与整体架构整个流程可以用下图概括沿用原文档的架构示意Your machine Ray Cluster ------------------ ------------------ | submit_job.py | --- uploads --- | train_on_cluster.py | config.yaml | config | (runs on head node) | | script | ray.init() is local | | -- streams --- | ludwig.train() | | logs back | saves to S3/NFS ------------------ ------------------完整执行链路共五步submit_job.py在本地机器笔记本、CI 服务器等上运行通过 Ray Job Submission API 把配置文件和训练脚本上传到集群train_on_cluster.py作为 Ray Job 的入口在集群 head 节点上执行训练脚本内的ray.init()在集群内部完成本地连接不再使用 Client 模式Ludwig 通过其 Ray 后端在集群各 worker 之间正常分发训练任务训练完成的模型保存到共享存储S3/GCS/NFS本地机器可随时取回。examples/README.md的目录说明中也将该示例定位为通过 Ray Job Submission 向远程 Ray 集群提交 Ludwig 训练规避 Ray Client 与 ray.data 的问题适用于 KubeRay、Anyscale 或任意 Ray 集群。三、三个核心文件详解示例目录 examples/ray/job_submission 下共三个文件分别承担提交、执行与配置三个职责。1. submit_job.py本地提交端submit_job.py 运行在本地机器上核心逻辑集中在submit()函数中submit_job.py建立客户端并构造运行时环境脚本使用ray.job_submission模块的JobSubmissionClient连接 Ray Dashboard 地址默认端口 8265见 submit_job.py。随后构造runtime_envworking_dir指向脚本所在目录Ray 会把该目录下的本地文件配置文件 训练脚本整体上传到集群env_vars通过环境变量把CONFIG_PATH、DATASET_PATH、OUTPUT_DIR三个参数传递给集群内的训练脚本pip可选当指定--pip参数时Ray 会在 Job 启动时先在集群上安装这些 Python 包见 submit_job.py。配置文件同步脚本会把本地 config 复制到脚本目录确保它随working_dir一起上传见 submit_job.py。提交 Job 并流式回传日志入口命令固定为python train_on_cluster.py可选entrypoint_num_gpus为 head 节点上的驱动脚本预留 GPU见 submit_job.py。提交后脚本进入日志轮询循环每隔 2 秒查询一次 Job 状态增量打印新产生的日志直到 Job 进入SUCCEEDED、FAILED或STOPPED终态失败时还会尝试读取error_type与错误信息见 submit_job.py。2. train_on_cluster.py集群训练端train_on_cluster.py 是 Ray Job 的入口脚本运行在 head 节点上。它通过环境变量接收参数见 train_on_cluster.pyCONFIG_PATHLudwig 配置路径默认config.yamlDATASET_PATH数据集路径必须设置为集群可访问的 S3/GCS/NFS/HDFS 路径缺失时脚本直接报错退出OUTPUT_DIR模型输出目录默认/tmp/ludwig_results。脚本读取 YAML 配置后用LudwigModel(configconfig)构造模型再调用model.train(datasetdataset_path, output_directoryoutput_dir)启动训练见 train_on_cluster.py。关键点在于远程 URIs3://、gs://等由 Ludwig 通过 fsspec 透明读取无需本地下载训练完成后脚本从train_stats.validation中提取每个输出特征的验证指标把最优值loss 取最小、其余取最大打印到 Job 日志中方便直接查看训练效果见 train_on_cluster.py。3. config.yaml示例训练配置config.yaml 是一个可直接运行的 Ludwig 配置示例模拟了经典收入预测二分类任务input_features: - name: age type: number - name: workclass type: category - name: education type: category - name: occupation type: category - name: hours-per-week type: number - name: capital-gain type: number output_features: - name: income type: binary combiner: type: ft_transformer hidden_size: 128 num_heads: 8 num_layers: 2 trainer: epochs: 50 batch_size: 256 early_stop: 10 learning_rate: 0.0001 optimizer: type: adamw该配置包含 4 个类别特征与 3 个数值特征输出为二分类目标组合器采用 FT Transformer隐藏维度 128、8 头注意力、2 层训练器设置 50 轮、batch size 256、早停耐心 10 轮、学习率 1e-4优化器选用 AdamW。配置中特别注明无需手动指定backend: {type: ray}。当脚本运行在 Ray 集群上时Ludwig 会自动检测 Ray 环境并使用分布式后端这一点与 ludwig/backend/ray.py 中get_trainer_kwargs()的实现吻合——它会根据ray.cluster_resources()自动探测集群 GPU 数量有 GPU 时按 GPU 数量分配 worker 并设置resources_per_worker为{CPU: 0, GPU: 1}无 GPU 时按节点数分配 CPU worker。这也是替换成你自己的配置即可能直接生效的底层原因。四、环境准备前提条件本地机器执行提交脚本只需安装 Ray 默认套件pip install ray[default]Ray 集群需要安装 Ludwig 的分布式扩展pip install ludwig[distributed]如果集群上尚未预装也可以在提交 Job 时用--pip ludwig[distributed]让 Ray 在 Job 启动阶段现场安装——代价是每次提交都会增加约 2~5 分钟冷启动时间。原文档建议生产环境尽量在集群镜像中预装 Ludwig。若使用容器方式部署集群本仓库提供了现成镜像构建入口例如 docker/ludwig-ray/Dockerfile 与 docker/ludwig-ray-gpu/Dockerfile对应镜像即上文 KubeRay 集群 YAML 中所引用的ludwigai/ludwig-ray:master与ludwigai/ludwig-ray-gpu:master。五、完整使用流程与命令详解基础用法python submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/--ray-addressRay Dashboard 地址HTTP 协议端口 8265--config本地 Ludwig 配置路径会被上传到集群--dataset集群侧可访问的数据集路径--output-dir模型输出目录默认/tmp/ludwig_results。提交到 KubeRay 集群KubeRay 集群的 head 服务名一般为ray-head命名空间为ray因此地址写作python submit_job.py \ --ray-address http://ray-head.ray.svc:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/在 Job 启动时现场安装 Ludwigpython submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir /shared/nfs/results/ \ --pip ludwig[distributed]提交后不等待、直接返回python submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/ \ --no-follow使用--no-follow时脚本打印 Job ID 后立即退出并提示后续可用ray job status job_id --address ray-address查询状态、用ray job logs job_id --address ray-address --follow跟进日志见 submit_job.py。对于长时间训练任务这种提交即走的方式更为稳妥。CLI 参数速查表参数必填默认值说明--ray-address是无Ray Dashboard 地址如http://ray-head:8265--config是无本地 Ludwig YAML 配置路径随 Job 上传--dataset是无集群可访问的数据集路径s3://、gs://、/nfs/...--output-dir否/tmp/ludwig_results集群上的结果输出目录--pip否无Job 启动时在集群安装的 pip 包可传多个--num-gpus否无为 head 节点驱动脚本预留的 GPU 数量浮点数--no-follow否False不流式跟进日志打印 Job ID 后退出六、数据访问与共享存储使用本方案最关键的一条约束是数据集必须从集群侧可访问而不是从本地机器访问。原因在于训练脚本在集群 head 节点上运行model.train()读取的dataset路径最终由集群内的 worker 通过 fsspec 或本地文件系统解析。存储类型示例路径说明S3s3://bucket/data.csv集群需要配置 AWS 凭据GCSgs://bucket/data.csv集群需要配置 GCP 凭据NFS/shared/data/train.csv需挂载到集群所有节点HDFShdfs://namenode/data.csv需运行 Hadoop 集群如果数据目前在本地需要先上传到集群可访问的存储例如aws s3 cp my_data.csv s3://my-bucket/data/my_data.csv然后在提交命令中把--dataset指向s3://my-bucket/data/my_data.csv。模型输出同理--output-dir指向 S3/GCS/NFS 等共享存储后训练产物对本地提交方自动可见。KubeRay 集群若需访问 S3 等远程文件系统可在集群镜像中补充s3fs、adlfs、gcsfs等库并通过环境变量注入凭据详见 examples/ray/kubernetes/README.md。七、自定义与进阶配置使用自己的配置原文档明确指出config.yaml只是一个示例任何合法的 Ludwig 配置都可以直接替换使用。替换后保持--config指向你的配置文件即可其余流程完全不变。得益于 Ludwig 对 Ray 环境的自动检测见上文get_trainer_kwargs()的 GPU 探测逻辑你无需在配置里显式声明分布式后端。为驱动脚本请求 GPU部分训练脚本需要在 head 节点上使用 GPU例如加载模型做推理预热。此时用--num-gpus 1为入口脚本预留 GPUpython submit_job.py \ --ray-address http://ray-head:8265 \ --config config.yaml \ --dataset s3://my-bucket/data/train.csv \ --output-dir s3://my-bucket/results/ \ --num-gpus 1该参数对应 Ray Job 提交时的entrypoint_num_gpus只作用于 head 节点的驱动脚本实际训练 worker 的 GPU 由 Ludwig 的 Ray 后端配置自行按需申请见 submit_job.py。自定义运行时环境如需更复杂的运行环境Conda 环境、容器镜像、额外环境变量等直接编辑 submit_job.py 中的runtime_env字典按 Ray 的runtime_env规范增加conda、container、env_vars等选项即可。当前实现已经通过env_vars传递了三个关键参数你可以在此基础上扩展。八、与 Kubernetes / KubeRay 结合本仓库在 examples/ray/kubernetes 目录下提供了完整的 KubeRay 集群管理脚本。快速上手路径通过kubectl get nodes确认已连接 Kubernetes 集群在 examples/ray/kubernetes/clusters 下选择集群模板例如导出CLUSTER_NAMEludwig-ray-gpu-cluster运行./utils/ray_up.sh $CLUSTER_NAME启动集群运行./utils/dashboard.sh $CLUSTER_NAME后访问http://localhost:8267打开 Ray Dashboard训练结束后用./utils/ray_down.sh $CLUSTER_NAME关闭集群。以 ludwig-ray-gpu-cluster.yaml 为例集群 head 与 worker 均使用ludwigai/ludwig-ray-gpu:master镜像head 节点暴露了 8265dashboard即 Job Submission 的--ray-address端口、10001client、6379redis等端口GPU 通过nvidia.com/gpu资源声明。该 YAML 中的 head 服务地址正是前面 KubeRay 提交示例中http://ray-head.ray.svc:8265的来源。需要特别说明的是KubeRay 场景下更常见的做法是直接用ray job submit命令或./utils/submit.sh提交任务而本示例的价值在于把提交与训练拆分为两个独立的 Python 脚本并在submit_job.py中内置了配置上传、环境变量传递与日志流式回传使 Job Submission 流程可以嵌入到任意 CI/调度系统中复用。结语Ray Job Submission 为 Ludwig 的远程分布式训练提供了一条稳定、可工程化的路径本地只负责提交与观测训练完全在集群内闭环执行从而绕开 Ray Client 模式下ray.data的已知问题。结合 submit_job.py、train_on_cluster.py 与 config.yaml 三个文件以及 Ludwig Ray 后端 ludwig/backend/ray.py 的自动资源探测能力你可以快速搭建起一套本地提交、集群训练、共享存储落盘的分布式训练流水线并平滑适配 KubeRay、Anyscale 等任意 Ray 集群环境。赞分享人工智能深度学习大模型微调LoRAAutoML【免费下载链接】ludwigLow-code framework for building custom LLMs, neural networks, and other AI models项目地址https://gitcode.com/gh_mirrors/lu/ludwig点击查看免费下载相关推荐Horovod on Ray 实战指南用 RayExecutor 在 Ray 集群上运行分布式训练Horovod on Ray 实战指南用 RayExecutor 在 Ray 集群上运行分布式训练 导读 本文基于 Horovod 官方文档中 Horovo深度学习机器学习分布式训练Ray Train 分布式 JAX 训练实战指南使用 JaxTrainer 在 GPU 与 TPU 上运行 SPMD 训练Ray Train 分布式 JAX 训练实战指南使用 JaxTrainer 在 GPU 与 TPU 上运行 SPMD 训练 Ray Train 提供的 Jax人工智能分布式训练强化学习任务调度模型推理服务后端使用 Ray Train 的 TorchTrainer 在分布式集群上运行 DeepSpeed 训练ZeRO 优化实战指南使用 Ray Train 的 TorchTrainer 在分布式集群上运行 DeepSpeed 训练ZeRO 优化实战指南 导读 DeepSpeed 是微软人工智能分布式训练强化学习任务调度模型推理服务后端上一篇探索高效Vue 2开发新境界vitejs/plugin-vue2深度揭秘下一篇Tinycast 自签名与自更新发布全流程macOS 启动器的自签名身份 GitHub Actions Homebrew Tap 实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考