ray.init() 本地调试不带参数，集群必须显式指定 redis://IP:6379 格式地址；ray.tune.run() 需设 resources_per_trial 和 max_concurrent_trials；训练函数必加 @ray.remote；logdir 需共享存储或手动同步。
ray.init() 该连本地还是集群？地址填错直接卡死
调参任务一启动就卡在 ray.init()，或者报 ConnectionError: Unable to connect to Redis，八成是地址没配对。本地单机调试时用 ray.init() 不带参数即可；但一旦进集群，必须显式指定 address，且格式必须是 redis://<head-node-ip>:6379</head-node-ip>（不是 HTTP 地址，也不是 localhost）。如果 head node 在 192.168.1.100，就得写 ray.init(address="redis://192.168.1.100:6379")。
容易踩的坑：
- 误把
ray start --head输出的dashboard地址（如http://192.168.1.100:8265）当成address填进去 - 集群节点间防火墙没开 6379 端口，导致 worker 连不上 head
- 用了
ray.init(address="auto")却没在 head node 上运行ray start --head --port=6379
ray.tune.run() 的资源分配不写清楚，GPU 就被抢光
ray.tune.run() 默认只用 CPU，哪怕你机器上有 8 块 GPU，它也全扔给 CPU 跑——结果就是几十个 trial 同时挤在 CPU 上，每个都慢得像爬。必须显式声明每组 trial 需要多少资源。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
resources_per_trial={"cpu": 2, "gpu": 1}明确指定，别依赖默认值 - 如果用的是
ASHA或BOHB这类早停算法，记得加max_concurrent_trials，否则调度器可能一次性拉起超多 trial，把 GPU 全占满，后续 trial 只能排队等 - 检查
ray.available_resources()输出，确认GPU字段确实有数值，否则说明 Ray 没识别到 GPU 驱动或 CUDA 环境
训练函数里忘了加 @ray.remote，所有 trial 全串行执行
Ray Tune 的核心是并行跑多个 trial，但如果你的训练函数没加 @ray.remote，那 ray.tune.run() 实际上只是在主进程里循环调用它——看着像在调参，其实全是串行，耗时翻倍还察觉不到。
正确写法长这样：
@ray.remote
def train_func(config):
# 你的训练逻辑
pass
<p>tune.run(train_func, ...)注意点：
-
@ray.remote必须加在训练函数上，不是加在tune.run()外层 - 函数内部不能直接调用
torch.cuda.device_count()这类全局查询，因为每个 remote 函数运行在独立进程，需通过config或环境变量传入设备索引 - 如果函数依赖外部模块（比如自定义 dataloader），得确保这些模块已安装在所有 worker 节点，或用
ray.util.multiprocessing打包分发
logdir 写错路径，tensorboard 根本看不到实验曲线
ray.tune.run() 默认把日志写进 ~/ray_results/，但这个路径在集群各节点上是各自独立的。如果你在 head node 上跑 tensorboard --logdir=~/ray_results，看到的只是 head 上那个空目录，worker 节点产生的日志根本不会自动同步过来。
解决方案只有两个：
- 把
local_dir设为共享存储路径，比如 NFS 挂载点：local_dir="/mnt/shared/ray_results" - 或者用
ray rsync-down手动拉取：比如ray rsync-down tune-default.yaml ~/ray_results ./ray_results
别指望 ray.tune.run() 自动帮你聚合日志——它只管调度和记录，路径管理得你自己兜底。
