Ray对比实录：一次模型推理迁移
ray对比最适合放进真实项目里看。本文还原一个批量图像分类服务从单机脚本迁移到 Ray 的全过程：原系统卡在哪里，如何拆任务和 Actor，怎样核对 CPU、GPU 与数据传输，最后哪些指标真正改善。重点不在“用了框架就变快”，而在于找出并行边界，避免把原有瓶颈原样搬进集群。
第1步：先还原原系统，而不是马上改代码
案例场景是每天处理约 80 万张商品图片，原方案在一台 GPU 服务器上用脚本循环推理。模型本身吞吐尚可，但图片解码、预处理和失败重跑都在同一个进程里，GPU 经常等待 CPU。ray对比的第一步不是看框架宣传，而是拆出三个耗时：读取与解码、预处理、模型推理。
测试结果显示，单张图片推理只占总耗时的一小部分，真正拖慢流程的是小文件读取和异常重试。这个结论决定了后续不能只增加 GPU，也不能把“一张图一个远程任务”直接上线。
第2步：把任务边界改成批次，把模型放进Actor
改造时将图片按批次打包，每个任务处理固定数量的路径，先完成读取和预处理，再把批量张量交给 GPU Actor。Actor 启动时加载一次模型，后续请求复用显存，避免每个任务重复初始化。批次大小通过基准测试确定，而不是凭感觉设置。
任务只返回必要结果：图片标识、类别和置信度，不把原始图片或完整中间张量传回 Driver。失败时按批次重试，并给每个批次设置唯一编号，结果写入时做幂等校验。这样即使节点中途退出，也不会重复落库。
第3步：逐项做Ray对比测试
先测单机多进程，再测 Ray 单节点，最后测多节点。对比指标包括每小时处理量、P95 延迟、GPU 利用率、峰值内存和失败重跑比例。单机多进程在小批量任务上启动更快；Ray 在任务量增加、需要跨节点调度时，吞吐更稳定。若只测一次短任务，很容易得出错误结论。
测试中还发现，批次过大时 GPU 利用率上升，但单批失败的重跑成本也变高；批次过小时，调度和序列化开销明显。最终采用可配置批次，并按图片大小分层，避免少量超大图片拖住普通任务。
第4步：上线前补齐可恢复性
上线前增加任务超时、Actor健康检查、失败批次队列和结果去重。监控不只看节点CPU，还要看对象存储占用、任务排队时间、GPU显存、批次成功率和重试次数。Ray解决的是调度与执行问题，数据源限流、结果校验和业务告警仍需应用层负责。
这次迁移的结论很明确：Ray对比单机脚本的价值不在所有场景都更快，而在于把预处理、推理和失败恢复拆开后，可以稳定扩展。若模型很小、数据量很低，原脚本反而是更合适的答案。
常见问题
迁移到Ray前要准备哪些指标？
至少记录端到端耗时、各阶段耗时、吞吐、P95延迟、峰值内存、GPU利用率、失败率和重试成本。没有基线就无法判断迁移是否有效。
为什么不用每张图片一个Ray任务？
任务太细会放大调度、序列化和文件读取开销。通常应按批次组织任务，再根据实测调整批次大小。
Ray能自动保证结果不重复吗？
不能。任务重试可能重复产生结果，业务侧需要使用唯一任务编号、幂等写入或去重表。