目录
master
分支21
标签1
+ 疑修
Web IDE
CyberCheems
项目创新说明格式微调
1个月前134次提交
README.md

项目简介

基于任务—资源配对决策的 Pairwise GNN-PPO，在满足 DAG 依赖与资源约束的前提下，为每个就绪任务选择合适的异构计算节点，并以最小化工作流总完成时间（makespan）为目标。

本项目面向 IoT—边缘—云协同计算环境，将任务依赖、节点算力差异、资源可执行性和跨节点通信开销统一建模，提供从场景配置、模型训练、搜索增强推理到同环境评测和结果可视化的完整闭环。

赛题场景与公平对比原则

项目以 official-stg 为主要实验线，generalization 与 realistic-sim 为可选扩展。三类实验采用独立的数据政策、环境版本、配置、输出目录、checkpoint 和 summary 命名，实验结果分别统计。完整契约见实验主线与产物规范。

实验线 主要用途 数据与配置 结果定位
official-stg 与参考赛题资料保持一致，公平比较 HEFT 与学习策略 仅固定 GrapheonRL/STG rnc50、rnc100 对外性能比较的主要依据
generalization 多任务规模、多节点规模、跨规模训练和泛化调优 自生成或项目原生场景；configs/generalization/ 跨规模、零样本和少样本能力，不替代 STG 结论
realistic-sim 建设拟真云—边—端仿真环境 分层网络、传输延迟、背景负载、多 DAG 类型和任务分布 仿真能力与敏感性分析，不代表真实集群性能

STG 是性能结论的主场景

为保证队伍间比较口径一致，项目以参考赛题提供的 AasishKumarSharma/grapheonrl-benchmark 中的 STG 工作流和异构节点配置作为主要实验来源：

  • rnc50、rnc100 分别固定划分为 120 个训练场景、30 个验证场景和 30 个测试场景；
  • 两个规模独立训练、选择 checkpoint 和评测，不混合数据或复用模型；
  • validation 只用于选模和动作先验校准，test 不参与训练或调参；
  • PPO、HEFT 和搜索增强策略使用完全相同的 DAG、资源节点、执行时间、通信时间与 makespan 计算逻辑；
  • 当前终版说明书与 README 展示 910B 六模型独立 test：验证集用于选模和动作先验校准，测试前封存全部模型与固定推理配置；
  • 历史 CUDA test 结果单独保留，属于不同训练批次和 checkpoint；随机场景结果不用于替代 STG 公平对比结论。

通用 STG 运行入口为 configs/official-stg/rnc50.yaml、 configs/official-stg/rnc100.yaml 和 src/scripts/run_stg_suite.py；复现终版使用下文的910B 六模型正式测试流程。数据划分、实验约束和输出说明见 STG 数据与同环境评测。

generalization 与 realistic-sim 用于扩展实验

除 STG 主实验外，项目提供独立的配置和随机场景生成功能，支持在不修改算法代码的情况下替换实验条件：

可配置内容 配置位置 作用
场景来源与数据划分 configs/scenario.yaml 在 generate、stg、load 三种模式间切换
任务数量、DAG 边密度 scenario.generate.num_tasks、edge_probability 构造不同规模和依赖复杂度的 DAG
任务时长、数据量、核心数、内存和 GPU 比例 scenario.generate.* 生成不同计算与通信特征的任务
IoT、Edge、Cloud、HPC 节点数量和异构能力 configs/resources.yaml 替换核心数、内存、特征、处理速度和网络带宽
PPO、行为克隆与搜索参数 configs/training.yaml、configs/eval.yaml 调整训练预算、模型结构和推理策略
随机种子与输出目录 各主线 canonical 配置 保证场景可复现并隔离实验产物

随机场景可以独立生成训练集和验证集，用于验证“更换任务规模或资源配置后，模型仍能完成训练—保存—加载—评测”的赛题要求。它是工程能力与扩展性补充，不与 STG 主实验的性能数字混为一谈。

HEFT 基线来源与一致性验证

项目中的 HEFT 根据参考赛题资料 grapheonrl-benchmark/stg_to_json_benchmarks/heft_solver.py 编写，对齐任务与节点字段、任务—资源可行性、执行时间、通信时间、upward rank 和 最早完成时间（EFT）选择，并适配为统一的 SchedulerPolicy 逐步动作接口。

两套 HEFT 已使用相同的 60 个固定 STG test 工作流、相同 8 节点资源和相同单位进行 makespan 对照：59 个场景的绝对偏差不超过 0.0001，最大绝对偏差为 0.137947465， 最大相对偏差为 0.128629%。因此本文表述为“核心口径高度一致”，不宣称逐场景零偏差。 项目中的 ratio 始终以本项目 HEFT 在同一环境中的 makespan 为分母。详细来源、映射和 偏差边界见 HEFT 流程对齐 GrapheonRL 说明。

相较常见调度项目的优势

下表比较的是项目设计与常见“单启发式脚本、扁平强化学习或仅给出模型代码”的实现方式，不代表本项目在所有数据集和所有目标上都普遍最优。

对比维度 常见实现方式 本项目的优势
决策粒度 先选任务再选资源，或只预测单一维度 Pairwise GNN-PPO 直接为合法的“任务—资源”组合评分，显式学习匹配关系
DAG 表征 使用任务列表或固定长度扁平特征 GNN 编码任务依赖结构，并融合资源状态与动作级启发式特征
约束处理 产生动作后再过滤或惩罚非法动作 训练和推理共用 action mask，策略概率只在合法配对上归一化
训练起点 PPO 从随机策略开始探索 使用 Lookahead HEFT 行为克隆 warm start，再由 MaskablePPO 优化 makespan
推理质量 单次策略前向后直接输出计划 以纯 PPO 为保底，结合 PPO-guided Beam 和单调局部修复，按真实 makespan 选择完整计划
评测公平性 不同算法使用不同环境或指标实现 HEFT、PPO、Random 共用同一场景、环境状态转移和指标计算
场景适应性 数据与资源规模固化在代码中 STG、随机生成和自定义 JSON 三种来源可切换，任务与资源参数均由配置驱动
实验可信度 只报告单次或单 seed 最优结果 保留当前 NPU 六模型独立 test、同模型机制对照、旧批次 validation 和 HEFT 偏差验证
工程完整性 仅提供算法或训练脚本 提供配置、训练、评测、CPU/CUDA/NPU 入口、Docker、场景编辑、甘特图和汇总产物

后文实验支持当前组合方法的表现及同模型搜索增强的收益；未完成逐项消融的设计不能据此归因出单项增益。配置化、同环境评测和多 seed 主要提升项目的可复现性、可审查性与扩展能力。

Pairwise 任务—资源联合决策

传统分阶段策略可能先选任务、再选资源；本项目把一个合法的“任务—资源”组合直接定义为一个动作：

候选动作 = (已就绪任务, 可执行资源)
action = task_id × num_resources + resource_id

例如，两个就绪任务和两个资源最多形成四个候选配对。模型综合任务图表示、资源状态、 预计执行时间与通信开销，为每个配对计算分数，再由 PPO 在合法动作集合中决策。 这里的 Pairwise 指任务—资源配对建模，不是成对排序损失。

实测效果

昇腾 910B STG 六模型独立测试

rnc50、rnc100 各采用 120/30/30 个互斥训练/验证/测试工作流，固定 split_seed=42。每规模独立训练 seed 42、43、44，共六个模型，各完成 20,224 个 PPO 步（目标预算 20,000）。验证集用于选模与一轮先验校准，六组验证结果、模型及固定搜索配置封存后才评测 test。每规模有 90 个模型—工作流配对、30 个不同测试工作流；完整调度计时重复三次。

方法 rnc50 平均比值 ± seed SD rnc100 平均比值 ± seed SD
HEFT 1.000000 ± 0.000000 1.000000 ± 0.000000
LookaheadHEFT 0.833179 ± 0.000000 0.862971 ± 0.000000
PairwiseGNN-PPO 原始策略 0.923588 ± 0.022298 1.407504 ± 0.147924
PairwiseGNN-PPO 校准策略 0.894780 ± 0.032491 0.953195 ± 0.030539
PairwiseGNN-PPO 混合推理 0.833001 ± 0.001705 0.866349 ± 0.003032
EFT 搜索对照 0.824920 ± 0.000000 0.874015 ± 0.000000

完整混合框架在 rnc50、rnc100 上的平均比值为 0.833001、0.866349，相对同环境 HEFT 的平均归一化完成时间降低 **16.70%、13.37%**。分别有 83/90、90/90 个配对改善，其余持平。混合推理相对校准策略的逐工作流配对平均改善为 **6.18%、8.93%**，95%置信区间为 [3.21%, 10.90%]、[6.07%, 12.83%]。

LookaheadHEFT 平均比值为 0.833179、0.862971。完整框架达到接近的平均调度质量，完整计划生成耗时由 3.1799/19.8183 秒降至 2.6224/7.6206 秒，减少 **17.53%、61.55%**；rnc100 展示了以明显更低的计算开销获得高质量方案的效果。

原始策略使用验证选中、校准前的检查点；校准策略使用同次训练的校准后检查点，两者直接决策。混合推理固定深度 4、束宽 8，组合 PPO top-4 与 EFT top-4，使用 HEFT 补全并保留 HEFT 与校准策略完整计划。LookaheadHEFT 固定 k=6。EFT 对照使用相同深度、束宽及补全，改为 EFT top-8，移除策略与外层纯策略候选；其神经概率调用仍保留。

比值为同工作流的 policy makespan / HEFT makespan，SD 是三个种子均值的样本标准差。完整配对统计、逐工作流记录和耗时见实验数字索引及正式测试归档。终版文件为操作系统开源创新大赛项目说明书.pdf。

NPU 实验运行环境

项目 记录值
操作系统与架构 openEuler 24.03 LTS-SP3，Linux aarch64
加速器 Ascend 910B3，64 GiB HBM
Python 3.12.13
PyTorch / torch_npu 2.8.0+cpu / 2.8.0.post4；通过 torch_npu 使用 NPU
CANN / 驱动 9.0.0 / 25.0.rc1.1
Stable-Baselines3 / sb3-contrib 2.9.0 / 2.9.0
Gymnasium / PyTorch Geometric 1.1.1 / 2.8.0.post1

这是本批数据的环境记录，不要求其他复现机器固定为同一型号；更换硬件需单独记录环境， 运行耗时和资源占用分别报告。CPU、CUDA、NPU 使用同一调度接口，按兼容栈安装依赖并选择设备。

方法概览

每一步从所有已就绪任务和可执行资源中选择一个合法配对：

DAG 场景 + 异构资源
        ↓
生成合法动作 mask
        ↓
选择 (ready_task, resource)
        ↓
计算执行时间与通信时间
        ↓
更新资源可用时间和 makespan
        ↓
重复直至全部任务完成

训练与推理链路

DAG 场景与异构资源
        ↓
状态构造与合法动作 mask
        ↓
Pairwise GNN 编码任务、资源与候选动作
        ↓
Lookahead HEFT 行为克隆 warm start
        ↓
MaskablePPO fine-tune
        ↓
validation 选模与动作先验校准
        ↓
纯 PPO 与混合推理对照评测（局部修复为可选扩展）
        ↓
汇总 makespan / ratio / mean_ratio

搜索增强仅发生在推理阶段，不修改 checkpoint；启用纯 PPO 保底候选时，按完整计划的 makespan 选择结果，保证逐场景不劣于该保底计划。当前 910B 正式测试使用固定的 rollout-guided Beam 混合推理（深度 4、宽度 8），同时保留 HEFT 和校准策略完整计划。 旧 NPU validation 的普通 Beam 与历史 CUDA 实验分别保留各自配置与数字。 当前结果见实验数字与证据索引，方法扩展与历史消融见 PPO Beam 推理优化实测。

快速开始

默认验收起点

CPU 功能验收入口是下面的 openEuler 裸机一键命令，安装 CPU wheel 时不依赖 Docker、 CUDA 或 NVIDIA 驱动。当前终版说明书的六模型 NPU 复现使用后面的“910B 实验复现”流程； CPU 功能验收、历史模型复评与 NPU 新模型实验分别记录，不能互相替代。

openEuler 裸机一键运行（CPU 功能验收）

昇腾用户直接按昇腾 910B 运行指南准备环境，不必先执行下面的 CPU 安装。

在项目根目录执行：

TORCH_INDEX_URL=https://download.pytorch.org/whl/cpu TORCH_SPEC='torch==2.9.1' \
  PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple bash src/scripts/run_openeuler.sh

该命令会自动：

  1. 使用 dnf 安装 Python、pip、编译器等系统依赖；
  2. 创建隔离的 .venv 虚拟环境；
  3. 从指定 PyTorch wheel 源安装 Torch，从清华 PyPI 镜像安装其余项目依赖；
  4. 读取 STG DAG 与资源 JSON；
  5. 分别训练、验证和测试 rnc50、rnc100；
  6. 输出 official-stg 带前缀的 validation/test summary 和统一 CSV。

默认再次运行会复用 .venv，不重新安装；除非设置 FORCE_SETUP=1，否则 TORCH_SPEC 等安装参数不会生效。 该脚本始终激活项目的 .venv，不是沿用终端当前激活的其他环境。

openEuler 裸机分步运行

如需逐步确认环境创建、依赖安装和训练过程，可在项目根目录依次执行以下精简命令。

# 1. 安装系统依赖
sudo dnf install -y python3 python3-pip python3-devel gcc gcc-c++ make

# 2. 创建并进入虚拟环境
python3 -m venv .venv
source .venv/bin/activate

# 3. 安装 CPU 版 PyTorch 和项目依赖
python -m pip install -U pip setuptools wheel
python -m pip install --index-url https://download.pytorch.org/whl/cpu 'torch==2.9.1'
python -m pip install -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt

# 4. 训练 rnc50/rnc100，并完成 validation/test 评测
python src/scripts/run_stg_suite.py --no-plot

源码现位于 src/。直接运行各入口脚本时会自行设置导入路径；在仓库根目录直接运行 python -m unittest discover -s tests 或 python -m scripts.run_all 时，请先设置 PYTHONPATH=src（PowerShell：$env:PYTHONPATH="src"；bash：export PYTHONPATH=src）。

后续重新进入 CPU 环境时执行 source .venv/bin/activate。

CPU 与昇腾的环境和 Torch 版本

CPU 示例固定安装 Torch 2.9.1；当前昇腾实验记录的是 Torch 2.8.0+cpu 与 torch_npu 2.8.0.post4。这是两种运行平台的安装选择，不是必须依次安装的两个步骤。 +cpu 后缀不代表实际在 CPU 上运行，昇腾通过 torch_npu 使用 NPU。

昇腾可以直接使用平台预装且已经配套的 Python 环境，不要求新建虚拟环境。 只有需要隔离安装、且已取得匹配 wheel 时，才按指南创建 .venv-ascend；名称本身不决定 Torch 版本。如果在同一个 Python 环境中先后安装不同 Torch，后一次可能替换前一次。 已跑通的 NPU 环境无需仅因 CPU 示例版本不同而重装；安装项目依赖时按指南使用 requirements-ascend.txt 与 Torch 版本约束，并记录实际解释器、版本和设备。

训练与评测设备分别由 training.device、eval.ppo_device 控制；当前 auto 按 CUDA → NPU → CPU 的顺序选择可用设备，以运行产物中的实际设备为准。

NVIDIA GPU 可选安装

CPU/CUDA 依赖声明为 torch>=2.8,<3.0，历史 CUDA 实验使用 2.9.1+cu128。 先用 nvidia-smi 查看驱动，再按 PyTorch 官方安装选择器 或 历史版本表 选择 wheel。以下为已具备 兼容驱动时的 CUDA 12.8 示例；FORCE_SETUP=1 会重新安装 .venv 中的依赖，不用于昇腾环境：

FORCE_SETUP=1 TORCH_FIND_LINKS=https://mirrors.aliyun.com/pytorch-wheels/cu128/ \
  TORCH_SPEC='torch==2.9.1+cu128' PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple \
  bash src/scripts/run_openeuler.sh

脚本也支持 TORCH_FIND_LINKS（wheel 目录）和 TORCH_WHEEL（本地 wheel）；详见 src/scripts/setup_openeuler.sh。不支持所选 CUDA wheel 的机器使用上面的 CPU 入口。

Docker 可选运行

若选择容器方式，需要先按照 openEuler Docker 安装配置文档 安装并启动 Docker；GPU 容器还需安装 NVIDIA 驱动和 NVIDIA Container Toolkit。项目不 假设这些宿主机组件已经存在。

宿主机容器环境准备完成后，CPU Docker 一键构建并运行：

docker compose run --build --rm --no-deps scheduler python3 src/scripts/run_stg_suite.py --no-plot

已有项目 CUDA 镜像时，GPU 一键运行：

docker compose --profile gpu run --rm --no-deps scheduler-gpu python3 src/scripts/run_stg_suite.py --no-plot

Dockerfile 的普通 Python 包默认使用清华 PyPI 镜像；新建 GPU 镜像时同样传入 wheel 参数：

TORCH_FIND_LINKS=https://mirrors.aliyun.com/pytorch-wheels/cu128/ TORCH_SPEC='torch==2.9.1+cu128' \
  docker compose --profile gpu run --build --rm --no-deps scheduler-gpu \
  python3 src/scripts/run_stg_suite.py --no-plot

以上 gpu profile 面向 NVIDIA；昇腾容器入口见昇腾运行指南。

已有模型快速复评

仓库提供的历史 seed=42 STG 模型位于（不是本次 910B 三 seed 新训练的模型）：

artifacts/official_stg/checkpoints/ppo_tuned_rnc50.zip
artifacts/official_stg/checkpoints/ppo_tuned_rnc100.zip

纯 PPO 复评

--skip-train 会读取下面两个 official-stg 位置的带前缀 checkpoint：

runs/official-stg/rnc50/checkpoints/
runs/official-stg/rnc100/checkpoints/

全新克隆仓库后，先将内置模型放到默认位置：

mkdir -p runs/official-stg/rnc{50,100}/checkpoints
cp artifacts/official_stg/checkpoints/ppo_tuned_rnc50.zip runs/official-stg/rnc50/checkpoints/official_stg_rnc50_ppo_tuned.zip
cp artifacts/official_stg/checkpoints/ppo_tuned_rnc100.zip runs/official-stg/rnc100/checkpoints/official_stg_rnc100_ppo_tuned.zip

裸机运行：

bash src/scripts/run_openeuler.sh --skip-train

Docker GPU 运行：

docker compose --profile gpu run --rm --no-deps scheduler-gpu python3 src/scripts/run_stg_suite.py --skip-train --no-plot

该入口执行 HEFT 与确定性纯 PPO 的 validation/test 评测；ppo_tuned 表示动作先验经过 校准，不代表启用了 Beam。默认 ppo_planning_rollouts=0，不会执行搜索增强。

PPO+Beam 增强推理

下面的循环复评历史 seed=42 checkpoint，分别评测 rnc50 和 rnc100，启用该批实验采用的 depth=4、width=8 PPO+Beam；它只增强推理，不修改模型权重：

source .venv/bin/activate
for scale in 50 100; do
  python src/scripts/inference_probe.py \
    --config configs/official-stg/rnc${scale}.yaml \
    --checkpoint artifacts/official_stg/checkpoints/ppo_tuned_rnc${scale}.zip \
    --output runs/official-stg/rnc${scale}/official_stg_rnc${scale}_test_beam_summary.json \
    --split test --deterministic-candidate \
    --rollout-beam-depth 4 --rollout-beam-width 8 \
    --rollout-beam-policy-top-k 4 --rollout-beam-eft-top-k 4 \
    --no-rollout-beam-ppo-tail
done

910B 实验复现（STG50/100 正式测试）

在包含 src、configs、data 的项目根目录执行。环境准备见昇腾 910B 指南。以下逐行脚本对应终版 PDF 附录 A；文档整理后，复现工具的源路径由 docs/ 调整为 src/docs/，使用下面的复制命令。–reproduce 不锁定分支或提交，仍保留场景、配置和冻结模型检查。两个工作目录须为新目录；重复运行请更换编号。

# 先激活已安装配套 PyTorch/torch_npu 的环境；平台预装环境直接使用
# source .venv-ascend/bin/activate
set +e
export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MPLBACKEND=Agg
unset PERFORMANCE_SOURCE_PROVENANCE PERFORMANCE_SOURCE_PROVENANCE_SCOPE
mkdir -p runs/paper_tools
cp src/docs/optimization_910B_*.py runs/paper_tools/
TRAIN=runs/paper_tools/optimization_910B_paper_experiments.py
CONFIRM=runs/paper_tools/optimization_910B_framework_confirm.py
TRAIN_WORK=runs/official-stg/paper-reproduction-01
CONFIRM_WORK=runs/official-stg/framework-reproduction-01
TRAIN_ARGS=(--work "$TRAIN_WORK" --reproduce)
CONFIRM_ARGS=(--source-work "$TRAIN_WORK" --work "$CONFIRM_WORK" --reproduce)
python -u "$TRAIN" init "${TRAIN_ARGS[@]}"
python -u "$TRAIN" smoke "${TRAIN_ARGS[@]}"
python -u "$TRAIN" train "${TRAIN_ARGS[@]}" --variants full
python -u "$CONFIRM" init "${CONFIRM_ARGS[@]}"
python -u "$CONFIRM" val "${CONFIRM_ARGS[@]}"
python -u "$CONFIRM" summarize "${CONFIRM_ARGS[@]}" --phase val
python -u "$CONFIRM" freeze "${CONFIRM_ARGS[@]}"
python -u "$CONFIRM" test "${CONFIRM_ARGS[@]}"
python -u "$CONFIRM" summarize "${CONFIRM_ARGS[@]}" --phase test
cat "$CONFIRM_WORK/reports/test/summary.csv"
cat "$CONFIRM_WORK/reports/test/paired_comparisons.csv"

full 是执行器中的完整训练配置代号，对应终版的 PairwiseGNN-PPO 训练链路。train 完成六组训练与先验校准，确认执行器随后比较六种固定方法；freeze 在测试之前封存验证结果和模型。校准不访问 test，测试结束后不据其结果重新选模或调参。

只核对已发布数字，无需 NPU、PyTorch 或训练：

python scripts/verify_paper_test.py

较早的固定源码 validation/普通 Beam 复现见历史归档，全量历史核验见归档与复现。历史 CUDA 性能资源清单的 CRLF/LF 差异可能触发 resource input mismatch，与新正式测试归档分别核验。

输出文件

CPU/CUDA 的 run_stg_suite.py 训练或历史模型复评完成后检查以下文件； 终版六方法测试输出位于 $CONFIRM_WORK/reports/test；下列布局属于通用 run_stg_suite.py：

runs/official-stg/rnc50/
  checkpoints/official_stg_rnc50_ppo_tuned.zip
  official_stg_rnc50_val_summary.json
  official_stg_rnc50_test_summary.json
runs/official-stg/rnc100/
  checkpoints/official_stg_rnc100_ppo_tuned.zip
  official_stg_rnc100_val_summary.json
  official_stg_rnc100_test_summary.json
runs/official-stg/
  official_stg_suite_summary.json
  official_stg_suite_summary.csv

各规模的 summary JSON 保留 PPO/HEFT 评测；suite CSV 汇总 PPO 的 makespan、 相对 HEFT 的 ratio 统计与胜率，不单独导出 HEFT 的完整统计表。

配置说明

configs/generalization/default.yaml 是 generalization 默认入口；历史 configs/default.yaml 仍保留兼容。official-stg 和 realistic-sim 分别使用各自目录下的 canonical 配置。

以下为 configs/generalization/default.yaml 的部分配置；includes 相对该 YAML 所在目录解析：

seed: 42
output_dir: runs/generalization/default

includes:
  - ../scenario.yaml
  - ../resources.yaml
  - ../training.yaml
  - ../eval.yaml
文件（相对仓库根目录） 作用
configs/scenario.yaml 场景来源、训练/验证数量、任务规模和 DAG 生成参数
configs/resources.yaml 异构节点的层级、算力、核心数、内存、特性与带宽
configs/training.yaml GNN-PPO、行为克隆、奖励塑形、选模和先验校准参数
configs/eval.yaml 评测策略、模型设备和搜索增强推理参数

场景支持三种来源：

  • generate：按配置生成可复现的随机 DAG；
  • stg：读取 GrapheonRL/STG 工作流数据；
  • load：读取项目原生 Scenario JSON 文件。

official-stg 使用 configs/grapheon/heterogeneous_nodes_scc_mb.json 的 8 个节点与固定 split_seed=42；数据划分与字段映射见 STG 数据与同环境评测。

实验结果与证据索引

当前 NPU 独立测试

历史 NPU validation 与普通 Beam

以下为 6fc8327 训练批次，与本轮 8ec171a 六模型训练及深度 4/束宽 8 混合推理分别记录：

规模 历史校准纯 PPO mean_ratio 历史普通 Beam 宽度 8 mean_ratio
rnc50 0.886860 0.855650
rnc100 0.943348 0.909714

旧结果使用参与选模和校准的 validation，见历史数字索引、历史预算曲线与旧 NPU 归档，不混入当前 test。

历史 CUDA test（独立训练批次）

以下历史 seed=42 模型分别在 30 个 test DAG 上评测，与当前 NPU 模型不混合统计：

STG 规模 纯 PPO mean_ratio PPO + rollout-beam d4/w8 mean_ratio mean_ratio 相对下降
rnc50 0.910418 0.831101 8.71%
rnc100 0.949353 0.862175 9.18%

完整 validation/test 表、多 seed 汇总和逐场景证据见 STG 数据与同环境评测、 历史 STG 归档 与 PPO Beam 推理优化实测。 test 结论仅支持同分布、同任务规模的未见 DAG 泛化，不表示单模型跨规模泛化； 本轮 NPU test 与这批 CUDA 模型使用各自的检查点和结果。

直接用归档的四份结果绘图，无需重新运行模型：

python src/scripts/viz_inference_improvement.py \
  --case rnc50=artifacts/official_stg/seed42/rnc50_test_summary.json,artifacts/official_stg/inference/rnc50_beam_test.json \
  --case rnc100=artifacts/official_stg/seed42/rnc100_test_summary.json,artifacts/official_stg/inference/rnc100_beam_test.json

输出为 runs/search_probes/inference_optimization_comparison.png 与同名 .json， 包含总体 mean_ratio、相对 HEFT 胜率与逐场景配对统计。

随机生成场景（补充）

configs/generalization/default.yaml 合并 scenario.yaml、resources.yaml、training.yaml 和 eval.yaml。其中 scenario.mode=generate，任务规模、边密度、训练/验证数量和随机种子均从配置读取。该线用于跨规模训练和泛化评测。

本地或 openEuler CPU 容器可运行：

python3 src/scripts/run_all.py --config configs/generalization/default.yaml --no-plot

docker compose run --rm --no-deps scheduler \
  python3 src/scripts/run_all.py --config configs/generalization/default.yaml --no-plot

默认输出位于 runs/generalization/default/。历史随机 DAG 消融见 PPO Beam 推理优化实测；原模型与原始结果未纳入当前 STG 归档，复现需补齐产物或重新测量，不作为 STG 公平对比证据。

50/100/200/300 任务的单 checkpoint 混合训练使用 configs/generalization/multiscale-50-100-200-300.yaml。该入口的训练统一在 Docker 中运行， 数据比例、隔离规则、正式命令和四规模 smoke 见 Issue #12 多规模训练说明。

Issue #13 在该场景池上增加按场景/按环境步采样与分阶段课程训练，入口为 configs/generalization/balanced-curriculum.yaml。等预算三 seed 对照、实际采样占比和 结果适用范围见 Issue #13 均衡采样与课程训练。

可视化

场景编辑器

python src/scripts/config_editor.py

编辑器支持：

  • 创建、移动和删除任务节点；
  • 绘制任务依赖边并设置数据传输量；
  • 管理异构资源节点；
  • 读取或保存 configs/resources.yaml；
  • 将场景导出到 runs/custom/scenarios/。

调度结果对比

先完成 official-stg 训练或历史模型复评，生成 scenarios/val.json 与对应 checkpoint， 再显式指定配置和模型，避免脚本按旧默认名 checkpoints/ppo.zip 查找而跳过 PPO：

# 对比已有 rnc100 验证场景；可追加 --id 指定场景
python demo/viz_demo.py \
  --config configs/official-stg/rnc100.yaml \
  --checkpoint runs/official-stg/rnc100/checkpoints/official_stg_rnc100_ppo_tuned.zip

# 可视化编辑器导出的自定义场景
python demo/viz_demo.py --custom my_dag

已成功加载模型时输出 HEFT/PPO/Random 的 makespan 对比和甘特图，不展示 DAG 依赖图。 未加载兼容 checkpoint 时只比较 HEFT/Random；留意终端的 Skipping PPO 提示。

实现边界

  • 本项目是调度算法的仿真、训练与评测框架，输出任务—资源映射和调度时间线。
  • 当前优化目标是最小化 makespan；能耗、费用、可靠性和在线节点故障尚未纳入正式目标函数。
  • 同一资源上的任务按时间顺序执行，cores 和 memory 用于任务—资源可行性检查，不表示节点内部多任务并行容量（参考赛题的参考资料进行搭建）。
  • baseline 模式按数据量与两端瓶颈带宽计算跨节点通信时间；realistic-sim 额外计入网络分区延迟，并在计算时间中考虑静态背景负载；storage 为兼容资源配置保留字段，当前不参与环境和 HEFT 计算。
  • 本次 910B STG50/100 已完成六模型独立 test 与六方法比较；每规模分别训练三个模型，验证同规模未见工作流的调度效果。
  • STG300 的容量探针、泛化推理与正式训练是不同验收项；不能以能够完成 300 任务推理替代尚未完成的正式训练与资源审计。

更完整的限制列表请参阅 技术报告 第 11 节“实现边界与已知限制”；正式实验的证据等级、资源监测和泛化口径请参阅 完整运行资源报告。

项目结构

CloudEdgeDAG-RL-Scheduler/
├── src/
│   ├── cloud_edge_scheduler/ # 环境、策略、训练、工具与可视化
│   ├── scripts/              # 训练、评测、调优及环境验证入口
│   └── docs/                 # 算法、运行与实验文档；history/ 保存历史记录
├── scripts/                  # 归档审计与旧版 official STG 冻结校验脚本
├── configs/                  # 当前默认/STG配置和资源定义
├── experiments/legacy/       # 历史Pairwise、Beam和消融实验配置
├── docs/                     # 比赛项目说明书与匿名成员分工说明
├── tests/                    # 奖励、策略和局部修复测试
├── demo/                     # 可视化演示脚本
├── presentation/             # 现有 PPT 与演示视频
├── runs/                     # checkpoint、场景和评测结果
├── Dockerfile
├── docker-compose.yml
└── requirements.txt

scripts/verify_official_stg.py 属于已冻结的 official STG 证据清单，目录迁移时保留原文件及路径；可运行 python scripts/verify_official_stg.py 核验历史证据。

扩展策略

新增调度方法可继承统一策略接口：

from cloud_edge_scheduler.policies.base import SchedulerPolicy


class MyPolicy(SchedulerPolicy):
    name = "my_policy"

    def select_action(self, obs, mask, deterministic=True):
        """返回一个合法动作索引。"""
        ...

将策略注册到 src/scripts/eval.py 的 build_policies() 后，即可与现有策略在相同场景和指标下比较。

相关材料与文档

材料 用途
终版项目说明书 已确定的比赛终版，含项目实现、正式测试与复现命令
成员分工及主要贡献说明 A（组长）、B、C 的匿名分工、实际贡献与对应项目材料
正式测试数字与证据索引 当前 910B 六模型 test、配对统计和核验入口
昇腾 910B 运行指南 平台环境复用、依赖配套、NPU 验证、训练与性能探针
推理增强预算曲线 同模型 NPU Beam 预算对照、分批证据核对与作图命令
技术报告 问题建模、系统设计、算法原理与实验结论
项目整体流程说明 从配置加载到训练、推理和评测的完整调用链
模块文档 源码模块、脚本入口、配置项和扩展方法
GNN-PPO 当前实现方案与数学原理 状态、动作、奖励、网络结构与数学定义
GNN-PPO 训练流程详解 行为克隆、PPO 微调、验证选模和先验校准
HEFT 算法、字段映射与 GrapheonRL 对齐 算法原理、任务与资源字段、实现差异和偏差测试
完整运行资源报告 正式环境、训练预算、耗时及泛化证据边界
性能基线使用说明 当前计时/资源运行入口、历史交付范围与限制
历史实验与交付记录 Issue #9/#12/#15 的设计、诊断和失败结果；不替代当前主实验
测试目录 环境、动作映射、策略、训练与评测产物的回归检查

参考资料

  • Aasish Kumar Sharma, GrapheonRL Benchmark：参考赛题提供的工作流、系统配置与 HEFT 实现参考。
  • Topcuoglu, H., Hariri, S., & Wu, M. Y. (2002). Performance-effective and low-complexity task scheduling for heterogeneous computing. IEEE TPDS, 13(3), 260–274.
  • Schulman, J., et al. (2017). Proximal Policy Optimization Algorithms. arXiv:1707.06347.
  • GrapheonRL: A Graph Neural Network and Reinforcement Learning Framework for Constraint and Data-Aware Workflow Mapping and Scheduling in Heterogeneous HPC Systems.
关于
README.md
228.1 MB
邀请码
    Gitlink（确实开源）
  • 加入我们
  • 官网邮箱：gitlink@ccf.org.cn
    • QQ群
  • QQ群
    • 公众号
  • 公众号

版权所有：中国计算机学会技术支持：开源发展技术委员会
京ICP备13000930号-9 京公网安备 11010802047560号