Hydra Ray Launcher 插件完全指南用 Ray 在本地集群与 AWS EC2 上并行调度多任务【免费下载链接】hydraHydra is a framework for elegantly configuring complex applications项目地址: https://gitcode.com/GitHub_Trending/hyd/hydra本指南以 Hydra 官方文档 ray_launcher.md 为主体结合仓库内 hydra_ray_launcher 插件源码 展开。Hydra Ray Launcher 插件为 Hydra 提供两个 Launcherray_aws基于 Ray Autoscaler SDK 在 AWS EC2 上远程调度与ray在本机或已有 Ray 集群上调度二者配合 Hydra 的--multirun机制即可将一组参数组合以并行任务的形式分布式执行。读完本文你将掌握插件的安装、启用、完整配置结构、集群生命周期管理、代码/产物同步以及ray.init()/ray.remote()的自定义方法。插件概览两个 Launcher 的分工插件位于仓库 plugins/hydra_ray_launcher对应 PyPI 包hydra-ray-launcher。它通过 Hydra 的 ConfigStore 机制向hydra/launcher配置组注册了两个 Launcher见 _config.pyray_aws在 AWS EC2 上远程启动任务构建于 Ray Autoscaler SDK 之上适合需要大规模、临时云集群的算力场景ray在本机或连接已有 Ray 集群启动任务适合本地开发验证与复用既有集群。官方对两者支持力度不同详见 ray_launcher.md本地rayLauncher 作为常规 Hydra 插件受完整支持ray_aws则属于 best-effort 维护路径因为它依赖 Ray Autoscaler 行为与真实 AWS 基础设施这类外部不稳定面且端到端测试有真实云成本负担。用户若能在 AWS 上验证修复社区欢迎为ray_aws提交 PR长期来看若它完全失效且无人维护该能力可能被整体移除。安装与启用安装插件$ pip install hydra-ray-launcher --upgrade启用方式有两种在命令行追加hydra/launcherray_aws或hydra/launcherray或在配置文件的defaults列表中覆盖defaults: - override hydra/launcher: ray_awsHydra 官方提供了多种配置插件的标准做法可参考 configuring_plugins.md。方式一ray_awsLauncher远程 AWS前置条件ray_aws基于 Ray 的 Autoscaler SDK使用前需要配置 AWS 凭证aws configure或环境变量凭证需具备EC2与IAM的相关权限Ray Autoscaler SDK 依赖这些权限创建、查询、销毁实例。Autoscaler SDK 需要一份描述 EC2 集群的配置。Hydra 将这份配置全部结构化、模式化schematized在 _config.py 中这意味着所有字段都有默认值、类型与注释可在 IDE 中获得补全提示并可通过--cfg hydra完整查看。完整默认配置速览运行--cfg hydra即可导出hydra.launcher的完整默认配置默认值即来自上面提到的结构化配置类$ python my_app.py hydra/launcherray_aws --cfg hydra -p hydra.launcher # package hydra.launcher _target_: hydra_plugins.hydra_ray_launcher.ray_aws_launcher.RayAWSLauncher env_setup: pip_packages: omegaconf: ${ray_pkg_version:omegaconf} hydra_core: ${ray_pkg_version:hydra} ray: ${ray_pkg_version:ray} cloudpickle: ${ray_pkg_version:cloudpickle} pickle5: 0.0.11 hydra_ray_launcher: 1.2.0.dev1 commands: - conda create -n hydra_${python_version:micro} python${python_version:micro} -y - echo export PATH$HOME/anaconda3/envs/hydra_${python_version:micro}/bin:$PATH ~/.bashrc ray: init: address: null remote: {} cluster: cluster_name: default min_workers: 0 upscaling_speed: 1.0 max_workers: 1 initial_workers: 0 autoscaling_mode: default target_utilization_fraction: 0.8 idle_timeout_minutes: 5 docker: image: container_name: pull_before_run: true run_options: [] provider: type: aws region: us-west-2 availability_zone: us-west-2a,us-west-2b cache_stopped_nodes: false key_pair: key_name: hydra-${oc.env:USER,user} auth: ssh_user: ubuntu available_node_types: ray.head.default: resources: {} node_config: InstanceType: m5.large ImageId: ami-0a2363a9cff180a64 ray.worker.default: min_workers: 0 max_workers: 2 resources: {} node_config: InstanceType: m5.large ImageId: ami-0a2363a9cff180a64 InstanceMarketOptions: MarketType: spot head_node_type: ray.head.default file_mounts: {} initialization_commands: [] cluster_synced_files: [] setup_commands: [] head_setup_commands: [] worker_setup_commands: [] head_start_ray_commands: - ray stop - ulimit -n 65536;ray start --head --port6379 --object-manager-port8076 --autoscaling-config~/ray_bootstrap_config.yaml worker_start_ray_commands: - ray stop - ulimit -n 65536; ray start --address$RAY_HEAD_IP:6379 --object-manager-port8076 run_env: auto stop_cluster: true sync_up: source_dir: null target_dir: null include: [] exclude: [] sync_down: source_dir: null target_dir: null include: [] exclude: [] logging: log_style: auto color_mode: auto verbosity: 0 create_update_cluster: no_restart: false restart_only: false no_config_cache: false teardown_cluster: workers_only: false keep_min_workers: false配置结构逐项解读ray_aws的配置由 RayAWSLauncherConf 描述自上而下分为几大块env_setup远程环境准备。pip_packages会在远程按包名版本形式执行pip install。其中omegaconf、hydra_core、ray、cloudpickle通过插件注册的ray_pkg_versionOmegaConf resolver_pkg_version动态取本地对应包的版本号从而保证远程环境与本地一致pickle5仅在 Python 3.8 时才会加入源码中按sys.version_info条件添加见 _config.py。commands为自定义 shell 命令默认创建一个独立的 conda 环境hydra_${python_version:micro}并把其 bin 目录写入~/.bashrc。ray.clusterEC2 集群定义。对应 RayClusterConf与 Ray Autoscaler 的集群配置文件一一对应常用字段含义字段默认值含义cluster_namedefault集群唯一标识min_workers0除 head 外最少 worker 数 0max_workers1最大 worker 数优先于min_workersinitial_workers0首次ray up时启动的 worker 数upscaling_speed1.0扩缩容速度越大扩容越快 0autoscaling_modedefault取default/aggressivetarget_utilization_fraction0.8目标资源利用率小于 1.0 才会触发扩容idle_timeout_minutes5节点空闲超过该分钟数将被移除docker空在容器内执行全部命令image为空表示禁用providertype: aws等云厂商与区域key_pair.key_name默认hydra-${oc.env:USER,user}authssh_user: ubuntuSSH 登录用户available_node_typeshead worker 两类节点类型与实例规格worker 默认使用m5.largespot 实例head_node_typeray.head.defaulthead 节点类型file_mounts/cluster_synced_files空文件挂载 / 从 head 同步到 worker 的路径initialization_commands/setup_commands等空列表初始化与安装命令head_start_ray_commands/worker_start_ray_commands默认命令各节点启动 Ray 的命令stop_cluster默认true任务结束后销毁集群false则保留集群可用ray up cluster.yaml再次拉起。sync_up/sync_downrsync 同步分别对应 RsyncConf 的source_dir、target_dir、include、exclude。sync_up在任务启动前执行本地→远端用于上传多模块代码sync_down在任务结束后执行远端→本地用于回传输出。其语义等价于rsync {source} {target} --include{include} --exclude{exclude}。logging、create_update_cluster、teardown_cluster分别对应 Ray SDK 的configure_logging、create_or_update_cluster、teardown_cluster三个 API 的参数将在下文展开。运行示例官方在 examples 目录 提供了两个可直接运行的示例。简单应用simple应用代码见 my_app.py其 config.yaml 中直接override hydra/launcher: ray_aws。用--multirun提交 3 个任务$ python my_app.py --multirun task1,2,3 [HYDRA] Ray Launcher is launching 3 jobs, [HYDRA] #0 : task1 [HYDRA] #1 : task2 [HYDRA] #2 : task3 [HYDRA] Pickle for jobs: /var/folders/n_/9qzct77j68j6n9lh0lw3vjqcn96zxl/T/tmpqqg4v4i7/job_spec.pkl Cluster: default ... INFO services.py:1172 -- View the Ray dashboard at http://localhost:8265 (pid3374) [__main__][INFO] - Executing task 1 (pid3374) [__main__][INFO] - Executing task 2 (pid3374) [__main__][INFO] - Executing task 3 ... [HYDRA] Stopping cluster now. (stop_clustertrue) [HYDRA] Deleted the cluster (provider.cache_stopped_nodesfalse) Destroying cluster. Confirm [y/N]: y [automatic, due to --yes] ... No nodes remaining.日志中的关键信息插件先把全部任务打成 picklejob_spec.pkl随后在远端创建集群并逐个执行任务默认stop_clustertrue且cache_stopped_nodesfalse任务一结束集群就被完全销毁。多模块代码上传与结果回传upload_download当应用依赖多个模块时可配置sync_up把依赖模块上传到远端集群需要回传输出时再配置sync_down。示例见 upload_download其入口 train.py 依赖model.my_model.MyModel模块并落盘 checkpoint。自定义的 custom_ray_aws.yaml 给出了推荐用法defaults: - ray_aws sync_up: # source_dir 相对路径以运行目录为基准也支持绝对路径 source_dir: . # target_dir 留空文件会被同步到远端临时目录 # 任务结束后该临时目录会被清理。 # 建议同步代码/产物时保持 target_dir 为 null # 这样无需在远端额外配置 $PYTHONPATH。 include: [model, *.py] # 无需上传配置文件 exclude: [*] sync_down: include: [*.pt, */] exclude: [*]运行输出示例$ python train.py --multirun random_seed1,2,3 [HYDRA] Ray Launcher is launching 3 jobs, [HYDRA] #0 : random_seed1 [HYDRA] #1 : random_seed2 [HYDRA] #2 : random_seed3 [HYDRA] Pickle for jobs: /var/folders/n_/9qzct77j68j6n9lh0lw3vjqcn96zxl/T/tmptdkye9of/job_spec.pkl Cluster: default ... INFO services.py:1172 -- View the Ray dashboard at http://localhost:8265 (pid1772) [__main__][INFO] - Start training... (pid1772) [INFO] - Init my model (pid1772) [INFO] - Created dir for checkpoints. dircheckpoint ... [HYDRA] Output: receiving file list ... done 16-32-25/ 16-32-25/0/ 16-32-25/0/checkpoint/ 16-32-25/0/checkpoint/checkpoint_1.pt 16-32-25/1/ 16-32-25/1/checkpoint/ 16-32-25/1/checkpoint/checkpoint_2.pt 16-32-25/2/ 16-32-25/2/checkpoint/ 16-32-25/2/checkpoint/checkpoint_3.pt ... [HYDRA] Stopping cluster now. (stop_clustertrue) [HYDRA] Deleted the cluster (provider.cache_stopped_nodesfalse) Destroying cluster. Confirm [y/N]: y [automatic, due to --yes] ... No nodes remaining.在源码层面sync_down会在任务结束后、集群销毁前执行当sync_up/sync_down的目录为空时远端源目录与本地目标目录都会回退到 sweep 输出目录见 _core_aws.py。同步实际由 _launcher_util.py 中的rsync()完成它拼装rsync --rsh ssh -i pem -o StrictHostKeyCheckingno -avz命令逐个追加--include/--exclude并自动带上--prune-empty-dirsSSH 私钥则按auth.ssh_private_key→provider.key_pair.key_name→ray-autoscaler_region的顺序推断。集群生命周期管理通过stop_cluster、ray.cluster.provider.cache_stopped_nodes与teardown_cluster.*三个开关组合可以精确控制任务结束后的集群去向默认行为命令行无需任何额外参数任务结束即删除集群hydra.launcher.stop_clustertrue hydra.launcher.ray.cluster.provider.cache_stopped_nodesfalse hydra.launcher.teardown_cluster.workers_onlyfalse hydra.launcher.teardown_cluster.keep_min_workersfalse任务结束后保留集群继续运行hydra.launcher.stop_clusterfalse通过cache_stopped_nodes与workers_only组合控制 EC2 实例停机与节点终止方式cache_stopped_nodesworkers_only行为falsefalse所有节点被终止falsetrue保留 head 节点运行仅终止 worker 节点truefalse保留 head 与 worker 节点并将两者都停机truetrue保留 head 与 worker 节点仅停机 worker 节点保留hydra.launcher.ray.cluster.min_workers个 worker 节点删除其余 workerhydra.launcher.teardown_cluster.keep_min_workerstrue源码中对应逻辑位于 _core_aws.pystop_clustertrue时调用sdk.teardown_cluster并把teardown_cluster整块参数透传false时则只打印提示不停止集群可能产生额外费用。创建/更新集群的行为控制create_update_cluster三组布尔开关对应 Ray SDKcreate_or_update_cluster的参数默认配置运行 setup 命令、重启 Ray、有条件时使用配置缓存hydra.launcher.create_update_cluster.no_restartfalse hydra.launcher.create_update_cluster.restart_onlyfalse hydra.launcher.create_update_cluster.no_config_cachefalse更新集群配置时跳过 Ray 服务重启可动态调整 Autoscaler 配置而不打断运行中的任务hydra.launcher.create_update_cluster.no_restarttrue跳过 setup 命令、只重启 Ray不可与no_restart同时使用hydra.launcher.create_update_cluster.restart_onlytrue禁用配置缓存、完全重新向云厂商解析环境设置hydra.launcher.create_update_cluster.no_config_cachetrue以上字段的定义与注释见 RayCreateOrUpdateClusterConf。配置 Ray 日志logging对应 Ray SDK 的configure_logging参数默认配置最低 verbosity自动检测是否使用 pretty-print 与彩色输出hydra.launcher.logging.log_styleauto hydra.launcher.logging.color_modeauto hydra.launcher.logging.verbosity0禁用 pretty-print改用 record 风格hydra.launcher.logging.log_stylerecord禁用彩色输出hydra.launcher.logging.color_modefalse提高 Ray 日志详细程度hydra.launcher.logging.verbosity3这些枚举与取值的语义定义在 _config.pylog_style取值auto/pretty/recordauto在 stdin 不是 TTY 时自动关闭 pretty 格式color_mode取值true/false/autoverbosity为 0~3 的 IntEnumminimal/verbose/very_verbose/very_very_verbose。运行期会通过sdk.configure_logging(**logging_config)真正生效见 _core_aws.py。方式二rayLauncher本地机器或已有集群rayLauncher 让你在本机或已有 Ray 集群上启动应用。在本仓库中ray的默认配置同样由结构化配置类 RayLauncherConf 定义_target_指向 ray_launcher.py 中的RayLauncher类并通过 ConfigStore 注册在hydra/launcherray配置组下核心只有ray.init默认{address: null}与ray.remote默认空字典两个小节。启动一个新 Ray 集群官方 simple 示例 同样适用于本地rayLauncher$ python my_app.py --multirun hydra/launcherray [HYDRA] Ray Launcher is launching 1 jobs, sweep output dir: multirun/2020-11-10/15-16-28 [HYDRA] Initializing ray with config: {} INFO services.py:1164 -- View the Ray dashboard at http://127.0.0.1:8266 [HYDRA] #0 : (pid97801) [__main__][INFO] - Executing task 1注意--multirun hydra/launcherray中 Launcher 直接由命令行指定与ray_aws示例通过配置文件override的方式互为补充。address为空时ray.init()不带参数调用默认启动一个新的本地 Ray 集群注意本地启动的 dashboard 端口为 8266与 AWS 场景不同。连接已有 Ray 集群通过覆盖hydra.launcher.ray.init.address即可连接到已有的 Ray 集群$ python my_app.py --multirun hydra/launcherray hydra.launcher.ray.init.addresslocalhost:6379 [HYDRA] Ray Launcher is launching 1 jobs, sweep output dir: multirun/2020-11-10/15-13-32 [HYDRA] Initializing ray with config: {num_cpus: None, num_gpus: None, address: localhost:6379} INFO worker.py:633 -- Connecting to existing Ray cluster at address: 10.30.99.17:6379 [HYDRA] #0 : (pid93358) [__main__][INFO] - Executing task 1ray.init是一个自由字典ray.init()支持的任何参数address、num_cpus、num_gpus、object_store_memory等都可以直接通过它传入。测试用例中也验证了这一点例如 _test_ray_launcher.py 通过hydra.launcher.ray.init.object_store_memory78643200覆盖 object store 内存。配置ray.init()与ray.remote()rayLauncher 构建于 Ray 的ray.init()与ray.remote()之上只需覆盖hydra.launcher.ray.init与hydra.launcher.ray.remote即可定制执行方式参考 simple 示例的 config.yaml。在源码中_core.pyray.init会先被解析成纯容器再交给start_ray()而ray.remote字典则被透传给ray.remote(**...)_launcher_util.py因此你可以像使用原生 Ray 一样配置num_cpus、num_gpus、max_calls等资源约束。源码级的执行链路与实现细节两条 Launcher 路径的底层执行链路可从源码中清晰还原ray路径RayLauncher.launch()→ _core.py 的launch()创建 sweep 输出目录 →start_ray(ray_init)已初始化则复用→ 逐个覆盖项调用load_sweep_config生成 sweep 配置 →launch_job_on_ray把任务函数包装成ray.remote任务提交 → 最后统一ray.get收集JobReturn。每个任务在远端执行 _run_job会重建全局状态setup_globals、Singleton.set_state、HydraConfig.instance().set_config再以hydra.sweep.dir/hydra.sweep.subdir为工作目录调用run_job——这与 Hydra 其他 Launcher 的作业执行约定完全一致。ray_aws路径RayAWSLauncher.launch()→ _core_aws.py 的launch()先合并env_setup.commands与pip install 包版本命令到集群setup_commands→sdk.configure_logging→ 将全部 sweep 配置、hydra_context、任务函数与 Singleton 状态用cloudpickle打成job_spec.pkl_pickle_jobs→sdk.create_or_update_cluster创建/更新集群 → 通过ray_tmp_dir在远端建立临时目录并执行任务 → 按需rsync上传/回传 →sdk.teardown_cluster收尾。这种本地打包、远端执行的设计使多任务在远端以并行进程日志中的pid...运行全部任务输出与生命周期日志都会回显到本地终端。测试与维护现状插件自带测试见 tests/test_ray_launcher.pytest_discovery验证插件能被 Hydra 插件系统发现RayLauncher出现在Launcher插件列表中TestRayLauncher复用 Hydra 官方的LauncherTestSuite/IntegrationTestSuite跑通用 Launcher 测试。由于 Ray 不支持 Windows测试在 Windows 平台整体跳过。AWS 端到端测试被默认禁用见 ray_aws_launcher_tests_disabled.py这与官方best-effort 维护的定位一致仓库另提供 integration_test_tools 帮助构建用于集成测试的 AMI。插件的演进历史可参考 NEWS.md1.1.0 起从 Autoscaler CLI 迁移到 SDK1.2.1 升级到 Ray v2。小结Hydra Ray Launcher 插件把参数组合 → 分布式执行这件事封装成了两个开箱即用的 Launcherray适合本地开发与复用既有集群ray_aws适合按需在 AWS EC2 上弹起临时集群。结合 Hydra 的--multirun、结构化配置的完整默认值、sync_up/sync_down的 rsync 同步、以及stop_cluster/teardown_cluster/create_update_cluster对集群全生命周期的精细控制你可以在不改动业务代码的前提下把单机脚本平滑迁移到分布式环境。动手实践时建议从 simple 示例 的本地rayLauncher 入手再按 upload_download 示例 扩展出多模块上传与产物回传的完整工作流。【免费下载链接】hydraHydra is a framework for elegantly configuring complex applications项目地址: https://gitcode.com/GitHub_Trending/hyd/hydra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考