Azure ML Pipeline REST偶发No temp file found异常咨询

客观问题现象 #

• 已通过实验验证、成功发布的Azure ML管道，通过Jupyter环境端REST端点连续触发调用时，任务偶发失败，无稳定复现规律
• 任务失败时，流程清理阶段抛出典型异常：Exception: No temp file found. The job failed. A job should generate temp files or should fail before this. Please check logs for the cause.
• 系统侧日志异常：logs/sys/warning.txt中可观测到Azure ML遥测接口返回的429 Too Many Requests限流错误、500 Internal Server Error服务端错误
• 临时复现规避表现：等待数分钟后重新触发调用，仅将process_count_per_node参数从6调整为2时，管道无用户代码报错即可顺利跑完

已完成的排查验证过程 #

• 初始测试基于30万行规模的NLP文本评分数据集开展，已将scikit-learn模型的n_jobs硬编码设置为1，搭建的ParallelRunConfig配置如下，仍存在偶发失败问题：

default_ds = ws.get_default_datastore()
# 输出数据集配置
output_dir = OutputFileDatasetConfig(destination=(def_file_store, 'model/results')).register_on_complete(name='model_inferences')
# 评分脚本所在目录
experiment_folder = 'model_pipeline'    
rit = 60*60*24
parallel_run_config = ParallelRunConfig(
    source_directory=experiment_folder,
    entry_script="score.py",
    mini_batch_size="5",
    error_threshold=10,
    output_action="append_row",
    environment=batch_env,
    compute_target=compute_target,
    node_count=5,
    run_invocation_timeout=rit,
    process_count_per_node=1
)

• 缩小测试规模复现：将测试集拆分为单记录独立文件形式，最小测试集为30个单记录文件，即便将error_threshold调整为1，日志显示ParallelRunStep已完成全部6个迷你批次处理、30条输入全部处理成功且0条失败时，仍会在结果拼接阶段触发“No temp file found”异常
• 偶发运行成功的异常表现：存在推理结果记录数缺失问题，例如30条输入仅返回15-25条有效结果
• 针对性优化验证：移除集成模型中1个权重子模型（原结构为15个模型权重融合）、清理输入文本字段中的制表符、换行、逗号等特殊字符后，问题仍未完全解决，表现为偶发运行成功但输出记录不全，偶发直接抛出“No temp file found”异常

问题根因定位 #

• 临时文件清理时序竞态问题
  ParallelRunStep在所有批次任务执行完成后，框架会从计算节点本地临时存储拉取所有批次生成的中间结果文件用于最终拼接。如果在拉取流程完成前，临时存储的后台清理任务触发，会误删未被拉取的中间临时文件，直接触发“No temp file found”异常。
• 计算节点并发配置与资源阈值不匹配导致进程异常退出
  初始设置process_count_per_node=6时，单节点内并行启动的推理进程数远超节点实际可承载的内存/算力阈值，部分进程在运行中被系统OOM Killer强制终止。进程退出后未正常生成本地临时结果文件，既会导致结果记录缺失，也会在后续临时文件校验阶段触发异常。调整参数为2时进程负载回落，任务即可正常完成，与复现表现完全吻合。
• 平台侧内部服务异常的连带影响
  日志中观测到的429限流、500服务端错误，是Azure ML平台内部服务波动的信号。该类异常会导致ParallelRunStep的结果上报通道阻塞，最终节点本地生成的临时结果未被框架正确识别，触发校验异常。

可落地解决措施 #

• 按节点实际承载能力配置并发参数
  不要盲目提高process_count_per_node数值，结合节点单推理进程的内存/算力占用情况，将单节点并发进程数控制在节点总内存可支撑的范围。例如单节点总内存16G、单NLP推理进程占用2G内存的场景，process_count_per_node建议设置为3以内，预留20%的系统内存作为缓冲，避免进程被系统强制终止。
• 规避临时文件竞态风险
  将output_action从append_row调整为append_row_list，同时在评分脚本内主动将推理结果写入指定的持久化输出路径，减少对框架本地临时文件中转流程的依赖；同时适当调小mini_batch_size，降低单批次临时文件的体积，减少临时拉取阶段的耗时，压缩后台清理任务误触发的时间窗口。
• 修复结果记录缺失问题
  在评分脚本的返回逻辑中增加结果条数校验：每处理完一个迷你批次，校验当前批次的输出结果条数是否与输入记录数一致，若存在缺失则触发当前批次重试，避免单条推理静默失败导致的结果不全。
• 抵消平台临时服务波动的影响
  在REST端点触发管道的外层逻辑增加简单重试机制：当收到“No temp file found”、平台侧接口5xx/429类错误时，等待3-5分钟后自动重新触发管道运行，无需人工介入。

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