边缘智能科研入门

深色模式

复现组内论文 ​

复现组内论文是进组后的第一个正式任务：代码、数据和作者都在身边，遇到问题容易解决；复现完成后，你手里就有了一套能继续做研究的实验环境。通用的复现方法和实验规范见复现论文与做实验，这一页讲组内论文的三种复现方式、复现到什么程度算完成，以及怎么从复现走向自己的研究。

三种复现方式 ​

方式代表论文主要工作需要的资源
A. 运行官方代码BWCache、PrediT、SCOPE配环境、下载模型权重、跑通、测速度和质量大显存 GPU（论文多用 A800）；模型权重几 GB 到几十 GB
B. 自己写仿真器LDLS、ToN 2024、ROCS、LECU、OCS、ORR按系统模型写仿真器，处理数据，实现对比算法和本文算法CPU 即可；强化学习训练可以用 GPU 加速
C. 搭真实系统LRScheduler、EAT、VELO、HeraSys搭集群或多机多卡环境，部署系统，施加负载并测量多台机器或多张卡，K8s、Docker、Ray 等

复现到什么程度 ​

级别目标参考时间（每周 10 小时）
0. 跑通官方示例能运行，或者仿真器能输出合理的结果1～2 周
1. 复现一个数主实验表格中的一个数字，差距在可以解释的范围内2～4 周
2. 复现一张图主实验中的一整张图（例如随节点数变化的曲线），趋势与论文一致1～2 个月
3. 换条件换模型、换硬件、换数据，得到论文中没有的新结果之后

本科生入门阶段做到第 1～2 级就很好。第 3 级的结果和预期不一样时，往往就是新研究的起点。

A. 运行官方代码 ​

以扩散模型加速的三篇论文为例：

论文代码支持的模型说明
BWCache（ICLR 2026）hsc113/BWCacheOpen-Sora 等基于 VideoSys 实现；README 中 Wan2.1、HunyuanVideo 的支持还在待办列表里
PrediT（ACM MM 2026）hsc113/PrediTFLUX.1-dev、DiT-XL/2、HunyuanVideo有不需要 GPU 的单元测试和配置检查
SCOPE（ACM MM 2026）hsc113/SCOPEMAGI-1、SkyReels-V2有不需要 GPU 的单元测试，提供检查上游代码版本的命令

复现顺序 ​

  1. 先跑不需要 GPU 的检查。PrediT 和 SCOPE 都可以先在任意电脑上运行单元测试，确认安装没问题：

    bash
    git clone https://github.com/hsc113/PrediT.git
cd PrediT
python -m venv .venv && source .venv/bin/activate
pip install -e ".[torch,test]"
pytest                                                     # 单元测试
predit validate-config configs/dit_50.json --smoke         # 检查配置，不加载模型

    README 中的 --smoke 配置会缩小分辨率和步数，只用来检查流程能否跑通，不能用来评测质量。

  2. 再跑原始模型（不加速），记录延迟。这是后面所有对比的基准。

  3. 打开加速，用相同的提示词、随机种子和步数再跑一次，计算加速比。

  4. 对比生成结果：先肉眼看，再以原始模型的输出为参考计算 PSNR、SSIM、LPIPS。

  5. 最后跑完整评测：VBench 等评测非常耗时，先用少量提示词试跑，确认流程正确再跑全部。

注意事项 ​

  • 模型权重：首次运行会从 Hugging Face 下载，国内设置镜像，见国内网络加速。部分模型（如 FLUX.1-dev）要先在模型页面同意许可协议。
  • 锁定版本：PrediT 和 SCOPE 用 provenance.json 记录了依赖的上游代码的具体版本（commit）。上游项目更新后接口可能变化，按记录的版本检出最稳妥。这也是你以后发布代码时值得学习的做法。
  • 计时：排除模型加载时间，先预热，计时前后调用 torch.cuda.synchronize()，见系统实验的特殊要求。
  • 硬件不同：论文在 A800 上测得的加速比，在 4090 上可能不同。复现报告中写清硬件，比较加速比而不是绝对延迟。
  • 在动手之前，可以先做 L5 扩散模型推理与加速，熟悉计时和特征缓存的基本做法。

B. 自己写仿真器 ​

组内调度类期刊论文的实验大多是仿真，代码通常没有公开。复现时照着系统模型自己写，这本身就是很好的训练：写完仿真器，你对论文的理解会比读十遍还深。

从论文到代码 ​

论文中代码中LDLS 的例子
实体类或数据结构节点、任务、镜像层 → Node、Task、层列表
参数类的字段，取值来自参数设置表带宽 60～90 Mbps、CPU 0.8～1.2 GHz、存储 5～15 GB
时间和成本的公式函数式 1～3 → estimate() 返回下载时间、计算时间、完成时间
约束动作掩码，或者在代码中检查存储放不下镜像的节点不能选
优化目标评价指标；在强化学习中对应奖励平均完成时间；奖励为完成时间的相反数
对比算法和本文算法输入相同、输出相同的函数输入环境和当前任务，输出节点编号

L9 层感知容器调度仿真完整走了一遍这个过程，建议先做 L9 再复现其他调度论文。

步骤 ​

  1. 先写对比算法，再写本文算法。随机、最少负载、贪心这些简单算法几十行就能写完，先用它们检查仿真器：结果不合理时，问题多半出在仿真器上。
  2. 准备数据：
    • 镜像和层：用 Docker Registry 的接口读取镜像清单，L9 给出了脚本。
    • 任务到达和资源需求：阿里巴巴集群 trace 有多个版本，例如 2018 年的混部集群数据和 2020 年的 GPU 集群（PAI）数据；先读对应版本的说明文档，弄清每一列的含义和单位。
    • 用户移动：出租车轨迹等公开数据集。
    • 处理数据的脚本放进 Git，记录抽样方法和随机种子。
  3. 统一单位：带宽 Mbps 与 MB/s 差 8 倍，MB 与 MiB 也不同；时间统一用秒。单位错误是仿真结果离谱最常见的原因。
  4. 多个随机种子：环境的随机性（节点参数、任务序列）和强化学习的随机性（网络初始化、采样）都要用多个种子，报告均值和标准差。训练用的种子和测试用的种子要分开。
  5. 对不上时：先核对参数设置表；论文没写清的细节，自己做一个合理假设并写进报告；还是对不上就去问作者，他们就在组里。

仿真器自查清单 ​

  • 只有一个节点、一个任务时，手算的结果和仿真结果一致吗？
  • 带宽翻倍，下载时间是否减半？
  • 所有任务都请求同一个镜像时，层感知的算法是否明显更好？
  • 随机调度应该最差，简单贪心应该不错。如果不是，先查仿真器，再查算法。

C. 搭真实系统 ​

真实系统的复现最难，难点往往不在算法，而在环境随时间的变化。以 LRScheduler 为例：

  • 官方实现基于 Go 1.18、K8s v1.23.8，要求容器运行时是 Docker，需要私有镜像仓库，测试集群是 1 个控制节点加 4 个工作节点。
  • K8s 从 1.24 起移除了 dockershim，现在的集群一般用 containerd。所以在新版本集群上，原代码中通过 Docker 获取层信息的部分不能直接用。

两种做法：

  1. 还原原始环境：在虚拟机里按 README 搭 K8s 1.23 加 Docker 的集群，先复现论文结果。
  2. 移植到新环境：改为从镜像仓库的接口获取层信息（和 L9 中的脚本思路相同），在新版本 K8s 上运行，再和原结果对比。

第二种做法本身就是一个不错的本科生项目。动手前先做 L6 Kubernetes 与调度，熟悉集群搭建和自定义调度器。

其他论文的系统环境：EAT 在 4 张 RTX 4090 上用 Docker 容器部署生成服务，多卡并行基于 DistriFusion（代码）；VELO 在边缘服务器上用 FastAPI 提供服务、用 Milvus 向量数据库缓存回答；HeraSys 基于 Ray 和 vLLM。

复现报告模板 ​

markdown
# 复现报告：论文名（会议/期刊, 年份）

## 目标
复现论文的哪张表或哪张图，达到哪一级（跑通 / 一个数 / 一张图 / 换条件）

## 环境
硬件（GPU 型号和数量、CPU、内存）、系统、驱动和 CUDA 版本、关键软件版本、代码的 commit

## 步骤
从零开始到得到结果的全部命令，别人照着做能得到同样的结果

## 结果对比
| 设置 | 论文 | 复现 | 差距 |

## 差距分析
硬件不同？版本不同？论文没写清的细节（列出你做的假设）？

## 发现的问题和想法
复现中发现的局限、论文没讨论的情况、可能的改进

从复现到自己的研究 ​

组内的很多论文是一条线发展出来的。看看一个问题是怎么一步步延伸的，能帮你在复现之后找到自己的题目。

1. 改变一个假设，或者换一个场景

层感知的容器调度这条线：

  • LDLS（TMC 2023）：任务调度时考虑节点上已有哪些层；
  • ToN 2024：用户在移动（车联网），容器要跟着迁移，迁移时同样利用层共享；
  • TSC 2024：集群软件升级期间，容器要怎么调度才能少影响正在运行的任务；
  • LECU（TMC 2025）：容器镜像要更新，层可以从其他边缘节点而不只是云端获取；
  • ORR（TSC 2025）：把请求调度、容器放置和资源供给放在一起联合优化。

2. 换一类方法

同样是容器调度，可以用强化学习（LDLS、ROCS），也可以用有理论保证的在线算法（OCS、ORR）。强化学习的策略网络也在演进：从普通的策略梯度，到注意力、LSTM 提取特征，再到基于扩散模型的策略（VELO 期刊版、EAT）。

3. 从仿真走向真实系统

LDLS 是仿真；LRScheduler（MSN 2024）把层感知调度做成了 K8s 调度器插件，获得最佳论文奖；LR²Scheduler（TPCI 2025）在此基础上增加了根据用户需求调整打分的机制。

4. 从一种模型换到另一种模型

BWCache 加速视频 DiT → PrediT 把“复用”变成“预测”，覆盖图像和视频模型 → SCOPE 面向自回归视频生成。

5. 会议版扩展成期刊版

VELO 先发表在 ICWS 2024，期刊版（TSC 2025）把多智能体强化学习的策略网络改成了基于扩散模型的版本（DLRS 算法）。组里还有几组这样的例子：LRScheduler 与 LR²Scheduler；HPCC 2024 和 TSC 2026 上关于多模型推理流水线的两篇论文。期刊版一般要扩展问题模型、改进算法、增加实验，并按期刊要求说明与会议版的区别。

复现之后问自己

复现过程中，哪个假设让你觉得“现实中不是这样”？哪个实验结果让你觉得意外？哪个参数一变，方法的效果就明显变差？把这些写进复现报告的最后一节，拿去和导师讨论。

作者：崔涵帅、姚智、王振胜、唐志清 · 边缘智能系统实验室

内容许可待定