1. Worker 常驻及 UDF/模型缓存

1.1 优化点名称

Ray UDF Worker 常驻及 UDF/模型缓存。

1.2 背景与收益原理

原始 Daft Ray UDF 路径会为每个 Actor UDF 节点创建 actor 池，节点执行结束后调用 ray.kill 销毁 actor。包含多个 UDF 或模型算子的 pipeline 会反复承担：

• Ray worker/actor 创建和就绪等待；
• Python 模块导入；
• UDF class 初始化；
• SentenceTransformer、fastText、KenLM、OpenCV 等模型或运行时状态加载；
• actor 注册、销毁和 GCS 状态更新。

常驻 actor 池按资源规格复用 Worker 进程，并在每个 actor 内按 UDF 表达式缓存初始化后的 UDF/模型。连续 UDF 阶段可复用进程；同一 UDF 再次出现时还可直接复用模型实例。

1.3 实现方式、分支与提交

分支：codex/ai-de-worker-udf-cache

提交：

• b4f967e1a：cache UDF models in resident Ray workers

主要实现位于 daft/execution/ray_actor_pool_udf.py：

• 将 UDFActor 从只保存一个 projection 改为维护 _projection_cache。
• 使用序列化表达式的 SHA256 作为 projection cache key。
• driver/coordinator 侧按 actor 数量和 Ray resource options 缓存常驻 actor 池；pool key 不包含具体 UDF，使不同 UDF 阶段也能复用同一批 Worker。
• 首次使用某个 UDF 时调用 prepare_projection 初始化并缓存 UDF/模型。
• 后续批次只传 projection key 和输入数据，不重复传输完整表达式。
• teardown 不再立即 ray.kill，由 Ray 在 driver 退出时统一回收进程。

结构性 smoke 测试中，两个串联 Actor UDF 只保留 1 个存活的 UDF actor，计算结果正确。

该优化测试完成后已从当前 xarch 环境回退；实验分支仍保留。

1.4 测试结果

结论：新 base 上只有 FineWeb 提升 0.39%，其余 4 条回退，五条汇总回退 1.03%。特别是向量化由旧 base 的正收益变为回退 1.65%，表明新 base 已降低部分 Worker/模型初始化成本，或 smoke 规模不足以摊薄常驻池管理开销。当前实现不建议合入。