Ray避坑：分布式任务慢在哪
ray避坑的关键，不是记住几个配置项，而是理解 Ray 如何处理任务、对象和资源。很多项目本地运行正常，放到集群后却出现吞吐下降、内存爆满、GPU闲置和任务重复执行。本文从调度、对象存储、Actor、容错四个底层环节拆开说明，给出可验证的排查顺序，避免把分布式问题误判成模型问题。
先看整体：Ray的性能不是只由CPU决定
Ray应用可以拆成三层：任务负责无状态计算，Actor负责持久状态，对象存储负责在任务之间传递结果。任何一层设计不当，都会让集群看起来“资源很多但跑不满”。例如一个任务只计算 20 毫秒，却要跨进程传输几十 MB 数据，调度和序列化已经占掉主要时间。
ray避坑应先建立基线：记录单任务计算时长、输入输出大小、排队时间、节点间传输量和失败次数。没有这些数据，盲目增加节点往往只会放大浪费。
第一处坑：对象传递造成隐形内存压力
Ray会把任务参数和返回值放入对象存储。大型数组或 DataFrame 被多个任务反复引用时，内存峰值可能快速上升；对象滞留还会触发 spill，把数据落到磁盘，延迟随之抬高。常见误区是把每个分片都设计成一个巨大对象，再让下游任务同时取回。
改法是控制分片大小，避免在 Driver 端集中调用 get；让下游任务直接消费对象引用，并及时释放不再使用的引用。对象大小、存活时间和并发数量要一起看，不能只盯着单个任务的内存。
第二处坑：资源声明和Actor生命周期不匹配
任务默认申请的资源不代表实际消耗。一个推理 Actor 若占用一张 GPU，却只声明 CPU，调度器会把多个实例放到同一节点，最后表现为显存冲突或推理抖动。反过来，资源声明过大又会造成节点碎片，剩余资源无法被其他任务使用。
Actor适合加载一次、重复使用的模型，但不适合把所有逻辑都塞进去。Actor 内部队列无限增长、模型缓存不清理、异常后状态无法恢复，都会让长时间运行的服务越来越慢。应设置并发上限、超时和重启策略。
第三处坑：把重试当成幂等保障
Ray可以在部分失败时重试任务，但重试不等于业务操作天然安全。写数据库、发消息、上传文件这类副作用任务，重复执行可能产生脏数据。需要给任务设计幂等键，或把计算与提交动作拆开：先生成结果，再由单独步骤按唯一标识提交。
总结来看，ray避坑有一条顺序：先测数据传输，再查对象存储；先核对资源声明，再看 Actor 生命周期；最后才调并发和节点数量。把问题定位到具体层，通常比换机器更有效。
常见问题
Ray对象存储爆满怎么办？
减少单个对象大小和并发结果数量，避免Driver集中拉取结果，检查对象引用是否长期保留，并为spill目录预留足够本地磁盘。
Ray任务失败会自动重试吗？
部分任务可以配置重试，但是否安全取决于任务是否幂等。涉及外部写入时，必须额外设计去重或事务机制。
为什么GPU利用率很低？
可能是数据准备、跨节点传输或模型初始化成为瓶颈，也可能是并发数过低。先分别测预处理、传输和推理耗时，不要只看GPU监控。