RD-Agent FT Job Runner多 GPU 机器上并行编排 LLM 微调任务【免费下载链接】RD-AgentResearch and development (RD) is crucial for the enhancement of industrial productivity, especially in the AI era, where the core aspects of RD are mainly focused on data and models. We are committed to automating these high-value generic RD processes through RD-Agent, which lets AI drive>项目地址: https://gitcode.com/GitHub_Trending/rd/RD-AgentFT Job Runner 是 RD-Agent 中 FT-AgentLLM 自动微调场景的批量作业入口它用run_ft_job.sh在单个 job 目录下并行拉起多个 FT-Agent 运行实例每个实例独占若干 GPU、独立日志与独立工作区并统一汇聚到同一个 job 目录供日志和 Streamlit UI 查看。本文基于 job/README.md 的核心内容结合 run_ft_job.sh、loop.py、conf.py 与 UI 源码讲清这套作业编排的配置方式、任务字段语义与底层执行流程。读完本文你可以在多卡机器上一次性下发多个“模型 × 基准评测”的微调任务并知道如何监控进度、定位日志、用 UI 汇总各任务各轮次的基准得分。FT Job Runner 的定位单任务与批量任务的分工FT-Agent 实现了一个基准评测驱动的自动微调闭环检查目标基准与原始数据集、生成数据处理代码和 LLaMA-Factory 训练配置、fail-fast 校验、微调目标模型、再用 OpenCompass 评测并基于反馈迭代。针对单个任务官方推荐使用 rdagent/app/finetune/llm/README.md 中的命令直接运行rdagent llm_finetune或直接python rdagent/app/finetune/llm/loop.py。当机器拥有多张 GPU、需要同时推进多个“模型 × 基准”组合时Job Runner 就是文档中说的“convenience helper for multi-GPU machines”。它与单任务运行共享同一套底层每个 task 最终执行的都是同一个 loop.py 入口只是通过环境变量把基准、GPU、超时等参数注入到各自进程里。快速开始从 RD-Agent 仓库根目录出发完整流程共三步# 1. 先准备好常规 FT-Agent 配置。 # 必填项参见 rdagent/app/finetune/llm/README.md。 cp .env rdagent/app/finetune/llm/job/.env # 2. 准备任务定义。 cp rdagent/app/finetune/llm/job/tasks.json.example rdagent/app/finetune/llm/job/tasks.json # 3. 运行作业。 bash rdagent/app/finetune/llm/job/run_ft_job.sh rdagent/app/finetune/llm/job/tasks.json脚本会为每个任务开一个 tmux 窗口并在log/job_id/下写日志。仓库内置的 tasks.json.example 给出了一个三任务示例同一底座模型Qwen/Qwen2.5-7B-Instruct分别跑aime25GPU 0,1、chemcotbench_mol_editGPU 2,3和tablebench_visualizationGPU 4,5每个任务超时12h第三个任务额外内联了benchmark_description。运行依赖与 conda 环境约定脚本对宿主环境的硬性依赖run_ft_job.sh 启动时逐项检查缺jq或tmux会直接报错退出jq解析tasks.jsontmux承载每个任务的窗口与输出捕获conda每个任务会激活一个 RD-Agent conda 环境默认名为rdagentjob/.env不存在时脚本会提示从仓库根目录复制一份再退出。如果你的 RD-Agent 环境名不是rdagent有两种改法运行前用环境变量覆盖或者把CONDA_ENV_NAME写进job/.envCONDA_ENV_NAMEmy-rdagent-env bash rdagent/app/finetune/llm/job/run_ft_job.sh另一个关键开关是job/.env中的FT_Coder_CoSTEER_env_type它决定训练/评测后端的运行形态也决定脚本的“就绪等待”策略docker模式默认脚本会打印 “Docker mode detected; skipping conda environment readiness checks.”跳过对训练和 OpenCompass 环境的 conda 就绪检查因为容器由训练流程自行准备conda模式第一个任务启动后脚本会循环等待两个 conda 环境可用——先等到conda run -n llm_finetune python -c import requests成功再等到conda run -n opencompass python -c import opencompass成功才继续启动后续任务。任务配置tasks.json 字段详解tasks.json顶层是一个tasks数组数组里每个元素是一个相互独立的运行实例{ tasks: [ { model: Qwen/Qwen2.5-7B-Instruct, benchmark: aime25, gpus: 0,1, timeout: 12h }, { model: Qwen/Qwen2.5-7B-Instruct, benchmark: chemcotbench_mol_edit, gpus: 2,3, benchmark_description: Molecule Editing - perform valid SMILES edits and return JSON: {\output\: \valid SMILES\}. } ] }各字段含义、是否必填与默认值如下与文档表格一致默认值由脚本中jq取值逻辑确认字段必填默认值说明model是-Hugging Face 模型 id。benchmark是-基准评测 key如aime25、chemcotbench_mol_edit。gpus否0作为CUDA_VISIBLE_DEVICES注入该任务。timeout否12h传给 FT-Agent 循环的墙钟预算。port否-可选的本地 API 端口脚本会为该任务写OPENAI_API_BASEhttp://localhost:port。benchmark_description否取自scenarios.json任务与输出格式的说明文本。如果省略benchmark_description脚本会到 scenarios.json 中按benchmarkkey 查找两处都没有时脚本直接报错退出“missing benchmark_description for benchmark ...”。scenarios.json覆盖了当前 FT 场景注册的全部基准按领域分为数学aime24/aime25、专利panorama系列及其 CoT 变体、化学chemcotbench系列、表格 QAtablebench系列、金融FinanceIQ_gen、生物bioprobench系列。每个条目同时携带category领域分类、scenario面向 Agent 的目标描述和benchmark_description含“Expected Output Format”约定这些描述最终会作为FT_BENCHMARK_DESCRIPTION环境变量进入微调循环指导数据生成与评测。脚本执行流程从源码看 run_ft_job.sh 做了什么结合 run_ft_job.sh 的实现整个作业的生命周期可以拆解为以下几步1. 路径与 job 目录。脚本以自身所在目录定位job/.env与scenarios.json并把仓库根目录上溯五级得到RDAGENT_DIR。日志根目录默认$RDAGENT_DIR/log可用环境变量FT_LOG_BASE覆盖工作区根目录默认$RDAGENT_DIR/git_ignore_folder/RD-Agent_workspace可用FT_WORKSPACE_BASE覆盖。JOB_ID取运行时刻date %Y-%m-%d_%H-%M重名时自动追加_1、_2后缀所有任务共享log/JOB_ID/目录。2. 每个任务的环境注入。任务名按benchmark _ 模型 basename生成例如aime25_Qwen2.5-7B-Instruct每个任务拥有独立的 trace 路径log/JOB_ID/task_name与工作区workspace/JOB_ID/task_name。脚本不会把这些值直接拼进命令行而是先写入任务工作区下的.task_env文件内容为CUDA_VISIBLE_DEVICESgpus LOG_TRACE_PATHtrace_path WORKSPACE_PATHtask_workspace FT_TARGET_BENCHMARKbenchmark FT_BENCHMARK_DESCRIPTIONescaped_desc OPENAI_API_BASEhttp://localhost:port # 仅当任务配置了 port CONDA_ENV_NAMEenv # 仅当设置了该变量benchmark_description会先对反斜杠、双引号、反引号、美元符做转义再写入脚本注释明确说明这是为了避免特殊字符造成的命令行转义问题。3. tmux 编排与错峰启动。脚本先杀掉已存在的rdagenttmux session再新建一个main窗口随后用tmux new-window为每个任务开一个以 benchmark 命名的窗口并通过tmux send-keys ... script -q LOG_FILE -c bash RUN_SCRIPT把终端输出重定向到log/JOB_ID/task_name.log。启动节奏上第一个任务启动后脚本会等待FT_FILE_PATH/datasets/dataset_info.json出现即场景初始化完成conda模式下再等待上述两个训练/评测环境就绪其余任务之间以STAGGER_DELAY60秒错峰避免多个实例同时争抢初始化资源。4. 任务实际执行的命令。每个任务的run_task.sh依次source仓库的job/.env和任务级.task_env配合set -a使其全部导出→ 加载 conda 并conda activate $CONDA_ENV_NAME→ 回到仓库根目录 → 执行python rdagent/app/finetune/llm/loop.py --base-model $model --timeout $timeout注意这里只显式传了--base-model和--timeout基准信息走FT_TARGET_BENCHMARK、FT_BENCHMARK_DESCRIPTION等环境变量——这与 conf.py 中LLMFinetunePropSetting的设计一致该类使用env_prefixFT_因此FT_TARGET_BENCHMARK、FT_BENCHMARK_DESCRIPTION、FT_BASE_MODEL、FT_FILE_PATH等环境变量会直接映射到FT_RD_SETTING的同名配置项。每个任务背后的 FT-Agent 主循环loop.py是 CLI 与 Job Runner 的共同入口。rdagent/app/finetune/llm/loop.py 中的main()用fire接收path、checkout、benchmark、benchmark_description、dataset、base_model、upper_data_size_limit、loop_n、timeout等参数将其写回FT_RD_SETTING后断言“必须指定base_model以及target_benchmarkbenchmark_description”随后构造LLMFinetuneRDLoop(FT_RD_SETTING)并以asyncio.run(loop.run(step_n..., loop_n..., all_durationtimeout))启动循环。timeout即任务tasks.json中timeout字段默认12h的最终去向——它是整个 FT-Agent 循环的墙钟预算。同样的入口也注册在 CLI 上cli.py 中app.command(namellm_finetune)命令的参数签名与main()一致因此单任务运行的rdagent llm_finetune --benchmark aime25 --base-model ... --timeout 12h与 job 中每个任务执行的 Python 命令语义等价只是参数注入方式不同CLI 显式传参 vs 环境变量。配置层面conf.py 中的LLMFinetunePropSetting还定义了若干与批量运行相关的旋钮全部支持FT_前缀环境变量覆盖full_timeout完整训练超时默认 100 小时、data_processing_timeout、benchmark_timeout0 表示不限时、benchmark_limit评测样本数限制便于快速调试、api_max_workers数据处理阶段 LLM API 并发数默认 8、upper_data_size_limit默认 2000等。在多任务并行时这些参数写在job/.env里会对 job 内所有任务生效而 GPU 隔离与时间预算则由tasks.json的每任务字段控制。监控与结果查看文档给出的三个监控手段各自对应不同的观察粒度tmux attach -t rdagent tail -f log/job_id/*.log streamlit run rdagent/app/finetune/llm/ui/app.pytmux每个任务一个窗口窗口名即 benchmark 名可用tmux list-windows -t rdagent列出、tmux select-window切换日志所有终端输出经script -q落盘为log/job_id/task_name.logtail -f即可跟踪Streamlit UI在 ui/app.py 的侧边栏选择“Job Summary”视图后把生成的 job 目录如log/2026-09-13_15-30作为日志源。从 UI 源码看Job Summary 模式会扫描目录中每个含__session__子目录的任务ft_summary.py 的is_valid_task判定为每个任务生成一行汇总Baseline 基线分、逐轮L0、L1、…状态与val/test得分、以及 Best 最优分。单元格状态码含义为CCoding 中、RRunning 中、X/红色被 feedback 拒绝或失败、绿色数字被接受的轮次数字颜色由该轮feedback/**/*.pkl中的decision决定得分则取自各 loop 目录下benchmark_result*的 pickle 结果并按split区分 validation/test。切换到“Single Task”视图后可以按 Session Loop Stage 的层级展开单个任务的完整时间线包括场景信息底座模型、数据集、目标基准、基线分、LLM 调用次数与 Docker 成功/失败统计。使用建议GPU 分配不重叠每个任务的gpus直接映射为CUDA_VISIBLE_DEVICES脚本不会检测冲突多任务并行时必须自行保证任务间的 GPU 集合互斥否则会出现显存竞争复用FT_FILE_PATHrdagent/app/finetune/llm/README.md 说明场景启动会在FT_FILE_PATH下准备数据集资源首次运行下载量大、耗时长脚本就绪等待逻辑正是以FT_FILE_PATH/datasets/dataset_info.json生成为标志多个任务共用同一个FT_FILE_PATH可让后续任务复用已下载资产描述文本以scenarios.json为准除非你要针对同一 benchmark 定制输出格式否则让脚本从 scenarios.json 自动填充benchmark_description可避免手写描述与评测期望格式如boxed{}、Final Answer:等约定不一致超时预算按任务粒度给timeout是传给 FT-Agent 循环的整体墙钟预算默认12h包含数据准备、训练与评测全流程批量实验中可按 benchmark 复杂度单独调节。综上FT Job Runner 的本质是“一个 job 目录 每任务一个 tmux 窗口 每任务一份环境注入 错峰启动 共享 UI 汇总”的轻量编排层它把 FT-Agent 的单任务闭环扩展为可并行、可监控、可回溯的批量实验设施同时完全保留了单任务运行所具备的全部配置能力。【免费下载链接】RD-AgentResearch and development (RD) is crucial for the enhancement of industrial productivity, especially in the AI era, where the core aspects of RD are mainly focused on data and models. We are committed to automating these high-value generic RD processes through RD-Agent, which lets AI drive>项目地址: https://gitcode.com/GitHub_Trending/rd/RD-Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考