Ray 实战:节点级 Actor Pool、模型预热与节点调度
一、问题背景
在上一篇《Ray 应用场景一例》中,我介绍了如何使用 Ray 内置的 node:IP 资源,把任务绑定到指定节点。那篇文章要解决的核心问题是:当任务依赖节点本地文件或节点本地环境时,如何确保后续步骤落到正确的机器上执行。
但在当前项目里,这还不够。
这个项目的执行链路大致如下:
- 先把音频或视频下载到某个节点的本地磁盘
- 再使用该节点上的 GPU 模型做说话人分离、ASR 和视频分析
- 最后生成报告并回调业务系统
如果继续沿用第一篇文章里的思路,节点绑定本身依然是成立的,但会进一步暴露出两个新问题:
- 每次 GPU 任务启动时都要重新加载模型,初始化成本高
- 调用方需要自己处理节点绑定、Actor 选择和空闲资源调度,工程上比较粗糙
所以,本文并不是要推翻上一篇文章里的方案,而是在那个思路之上继续往前走一步:在“节点绑定”已经成立的前提下,引入节点级 Actor Pool 做模型预热,并通过 NodeAffinitySchedulingStrategy 实现更稳定的节点级资源调度。
需要先说明一点:本文中的 Pipeline 设计来自一个具体项目实现,不是 Ray 的固定范式。文中提到的某些约束,例如 step_d 固定在 Head 节点执行、step_c 不做节点绑定,都是当前项目的工程选择,而不是 Actor Pool 方案本身的必然要求。
可以把两篇文章的关系简单理解为:
| 方案 | 主要解决的问题 | 模型预热 | 调度灵活性 | 实现复杂度 |
|---|---|---|---|---|
| node:IP 资源绑定 | 任务如何落到正确节点 | ⚠️ 可做但通常会退回任务级初始化 | ⭐⭐ | 简单 |
| 节点级 Actor Pool + NodeAffinity | 节点绑定基础上的模型复用与节点内调度 | ✅ 预加载复用 | ⭐⭐⭐⭐ | 中等 |
