Dask-Yarn 批量模型推理耗时过长问题咨询

以下是可直接落地的排查和优化方向：

• 替换行级apply为分区级批处理
  现有代码逐行调用推理函数，会产生900万次调度任务，调度开销占比会超过90%。将apply改为map_partitions，一次传入整个分区的数据做批量推理，调度次数直接降低到分区数级别，推理效率可提升10倍以上。
• 优化模型分发逻辑，避免重复序列化
  现有代码用dask.delayed包裹模型后逐任务传递，每次调用推理都会触发一次模型序列化/反序列化，Bert模型体积大，这部分开销极高。可以用client.scatter将模型广播到所有worker节点，保证每个worker只加载一次模型，无需每次推理重复传输。
• 删掉冗余的persist操作
  读取parquet后立刻执行的persist属于冗余操作，会额外产生一次全量数据的内存读写开销，仅需要在repartition完成后执行一次persist即可。
• 避免全量数据compute到本地
  最后一步将900万行全量结果compute到客户端，会产生大量数据传输开销，还容易把客户端内存打爆。直接将结果DDF写入到S3/HDFS等分布式存储即可，完全无需拉取到本地。
• 调整Worker配置降低调度开销
  200个单核心Worker会导致Yarn侧容器调度和Dask侧任务调度的开销大幅上升，建议将单Worker核心数调整为2_{4核，总核心数保持200不变的前提下，Worker数量降到50}100个，可显著降低调度损耗。
• 推理侧本身优化
  Bert推理可开启INT8量化或用ONNX Runtime加速，单条推理速度可提升2~3倍；XGBoost模型可提前用Treelite编译为优化后的推理版本，推理速度也可提升1倍以上。
• 排查指标参考
  打开Dask Dashboard确认几个核心指标：
  1. 任务排队时间如果远大于执行时间，属于调度瓶颈，优先调整为批处理逻辑
  2. Worker CPU利用率长期低于30%，属于任务分发/模型加载瓶颈，优先优化模型分发逻辑
  3. 网络IO长期跑满，属于数据传输瓶颈，优先检查冗余persist和全量compute的问题

内容的提问来源于stack exchange，提问作者Riley Hun