EvalStop：利用世界反馈检测并修正多租户RLHF平台中的奖励过度优化

# 使用世界反馈检测并修正多租户RLHF平台中的奖励过度优化

来源：https://arxiv.org/html/2606.04145

###### 摘要

背景。云端LLM微调平台越来越多地服务于RLHF负载，其中学习到的奖励模型被优化为人类质量的*代理*。正如Gao等人（2023 (https://arxiv.org/html/2606.04145#bib.bib10)）所示，在持续的优化压力下，该代理会与*世界反馈*（下游评估指标）产生分歧：即*奖励过度优化*现象。局限性。现有平台调度器忽略此分歧：非先验调度器优化JCT而不使用任何质量信号，SLAQ风格的质量感知调度器使用训练损失（一个较弱的代理，在破解过程中单调下降），经典的每作业早停需要人工监控且无法释放共享GPU。方法。我们提出EvalStop，一种可组合的调度原语，在连续kk次评估分数下降时终止作业、释放GPU、保留最佳检查点，并委托给任意基础调度器。我们将调度器级别的早停框架化为一个*检测*问题，并在一个离散事件模拟器中评估它，该模拟器的RLHF负载混合了奖励破解和结构健康运行，真实标签对调度器隐藏。结果。在RLHF重负载（80% RLHF，64 GPU）上，EvalStop实现了精度98% / 召回99% / 假阳性率1.5%，同时相比SRTF-Est将JCT提升9%并削减22%的浪费计算（p<0.05p{<}0.05）。琐碎的固定进度和损失平台竞争者要么产生65%的FPR，要么错过超过一半的真实破解案例。增益在基础调度器间可组合（9–25% JCT），并在评估噪声（σ≤0.05\sigma{\leq}0.05：精度≥\geq91%）和破解基础发生率（精度≥\geq89%，20–80%范围内）下保持稳定。

见图1：EvalStop架构。*世界反馈*流入*衰退检测器*；在连续kk次评估下降时，包装器执行*停止并保存*（释放GPU，保留最佳检查点），然后将更新后的集群状态委托给任何*基础调度器*。一个非先验*信息边界*（底部条带）贯穿整个流水线，因此检测质量可诚实测量。每个模块1:1映射到§1 (https://arxiv.org/html/2606.04145#S1)中的贡献：{世界反馈，信息边界}→\toC1；{衰退检测器，停止并保存}→\toC2；{基础调度器}→\toC3。

## 1 引言

背景。基于云端的LLM微调平台在共享GPU集群上为不同租户提供多样化负载（LoRA适配器微调、DPO（Rafailov等人，2023 (https://arxiv.org/html/2606.04145#bib.bib12)）和RLHF（Ouyang等人，2022 (https://arxiv.org/html/2606.04145#bib.bib9)）），随着RLHF成为LLM对齐的主导方法（Stiennon等人，2020 (https://arxiv.org/html/2606.04145#bib.bib11)；Ouyang等人，2022 (https://arxiv.org/html/2606.04145#bib.bib9)），这些平台上RLHF负载的比例正在迅速增长。RLHF在结构上与监督微调不同：策略被训练以最大化学习到的奖励模型，但该奖励是人类偏好的*代理*，策略的真正质量仅通过下游评估（留出基准测试、在留出偏好集上的胜率、任务特定指标）来衡量。因此，调度器可以访问三个代理性递减的信号：训练损失（代理2，由RL算法优化）、奖励模型分数（代理，策略直接优化的目标）和下游评估分数（*世界反馈*，基于任务质量但有延迟和噪声）。

Gao等人（2023 (https://arxiv.org/html/2606.04145#bib.bib10)）表明，随着优化压力增加，前两者单调上升，而第三者达到峰值后下降。这就是*奖励过度优化*现象（Skalse等人，2022 (https://arxiv.org/html/2606.04145#bib.bib19)；Pan等人，2022 (https://arxiv.org/html/2606.04145#bib.bib20)）；图2 (https://arxiv.org/html/2606.04145#S2.F2)（§2.3 (https://arxiv.org/html/2606.04145#S2.SS3)）在一个代表性运行上展示了该现象。

先前工作及其局限性。有三条先前工作线索涉及此场景，但均未直接解决。(i) *非先验ML调度器*（Tiresias（Gu等人，2019 (https://arxiv.org/html/2606.04145#bib.bib1)）、Pollux（Qiao等人，2021 (https://arxiv.org/html/2606.04145#bib.bib3)）、Gavel（Narayanan等人，2020 (https://arxiv.org/html/2606.04145#bib.bib4)）、Sia（Jayaram等人，2023 (https://arxiv.org/html/2606.04145#bib.bib5)））优化JCT而不使用任何质量信号，因此无法判断RLHF作业后期花费的GPU时间是有效的还是浪费的。(ii) *质量感知调度器*，最接近的先前工作，依赖于训练损失：SLAQ（Zhang等人，2017 (https://arxiv.org/html/2606.04145#bib.bib2)）优先将GPU分配给损失下降最快的作业。这对于损失与质量相关的凸损失有效，但对于RLHF，损失恰恰是在过度优化过程中与世界反馈解耦的代理，因此损失感知调度器会继续为破解作业分配资源。(iii) RL社区的*奖励破解缓解措施*（Moskovitz等人，2024 (https://arxiv.org/html/2606.04145#bib.bib18)；Gao等人，2023 (https://arxiv.org/html/2606.04145#bib.bib10)）在*训练循环内部*运行（约束RL、奖励集成、SFT正则化）。它们旨在防止破解，但在生产部署中，不完美的缓解是常态，这些技术无法从已经偏离的作业中回收GPU。经典的早停（Prechelt，1998 (https://arxiv.org/html/2606.04145#bib.bib23)）同样需要每作业的人工监控，并且不能转化为平台范围的资源重新分配。

动机。我们认为，对世界反馈采取行动的正确位置是*调度器*，而不是训练器：调度器已经控制着GPU分配和终止，一个调度器变更即可统一应用于每个租户的RLHF作业。与评估感知的*优先级*调度器（EvalSched，§4 (https://arxiv.org/html/2606.04145#S4)）的早期实验表明，简单地降低峰值后作业的优先级是不够的：降优先级的作业仍然占用系统，并且EvalSched的JCT比SRTF-Est差2.2×\times倍。解决方法是*终止*正在衰退的作业，而不是饿死它们。但是粗暴的终止（例如，在固定进度停止每个RLHF作业）将在任何真实负载中都存在的结构健康的RLHF运行上付出高昂的假阳性代价。这重新将问题框架化为一个*检测*任务：调度器必须仅使用其合法可观察的信号（在调度检查点处的评估分数）来区分破解与健康运行，而不修改训练，也不违反非先验边界（Motwani等人，1994 (https://arxiv.org/html/2606.04145#bib.bib21)）。

贡献。我们提出EvalStop，一种可组合的调度原语，其架构（图1 (https://arxiv.org/html/2606.04145#S0.F1)）分解为五个模块；每个贡献映射到其中一个或多个模块。

- • C1 — 检测框架（*世界反馈*输入 + *信息边界*）。我们认为RLHF的调度器级别早停是一个*检测*问题：调度器消费世界反馈并必须报告哪些作业正在破解。仅报告JCT/TTFUC的先前框架遗漏了这一轴。我们的实验设计将真实破解标签隐藏在代理白名单之后（SchedulerJobView，信息边界），因此检测质量是可诚实测量的。
- • C2 — 在检测轴上获胜的可组合检测器（*衰退检测器* + *停止并保存*）。EvalStop跟踪每作业的连续评估分数下降，在连续kk次下降时，终止作业并保存其最佳检查点。在RLHF重负载（80% RLHF，64 GPU）上，它实现了精度98% / 召回99% / 假阳性率1.5%，胜过了琐碎的固定进度停止规则（FPR 65%）和强大的损失平台检测器（召回38%）。
- • C3 — 在基础调度器和负载上的可组合系统增益（*基础调度器*委托）。包装器将更新后的集群状态交还给任何调度器（FIFO、SJF-Est、SRTF-Est、LossAware），继承其资源分配策略。EvalStop在每种测试的基础调度器上产生9–25%的JCT改善和约22%的浪费计算减少，并且其检测质量在评估噪声（σ≤0.05\sigma{\leq}0.05：精度≥\geq91%）和破解基础发生率（精度≥\geq89%，20–80%范围内）下都保持稳定。

## 2 背景与问题设定

### 2.1 作业模型

一个微调作业jj具有类型∈{LoRA,DPO,RLHF}\in\{\text{LoRA},\text{DPO},\text{RLHF}\}、GPU需求、一个评估计划（运行评估的进度百分比）以及一个将进度映射到（损失, 评估分数）的训练曲线。作业类型在结构上不同：LoRA作业短（10–60分钟，1–2 GPU），评估单调改善；DPO作业中等（30–120分钟，2–4 GPU），收益递减；RLHF作业长（60–360分钟，4–8 GPU），评估达到峰值后下降。

### 2.2 评估感知指标

除JCT外，我们定义：(1) *TTFUC*（首次有用检查点时间）：从到达时间到第一个超过质量阈值τ\tau且相比之前最佳改进≥1%\{\geq\}1\%的检查点的时间；(2) *浪费计算分数*：作业评估峰值后用于训练的GPU分钟数除以总GPU分钟数；(3) *节省计算分数*：通过早停避免的GPU分钟数除以总计划GPU分钟数。

### 2.3 代理信号与世界反馈

图2 (https://arxiv.org/html/2606.04145#S2.F2)在一个代表性RLHF训练运行上说明了核心问题。调度器可以获取三个信号：

- • 训练损失在整个训练过程中单调递减。一个SLAQ风格（Zhang等人，2017 (https://arxiv.org/html/2606.04145#bib.bib2)）的损失感知调度器会将其解释为“作业进展良好，继续运行”。
- • 奖励模型分数（归一化1−loss/loss01-\text{loss}/\text{loss}_{0}）也单调递增，因为策略直接优化此目标。
- • 评估分数（下游基准）在大约55%进度时上升到峰值，然后随着奖励破解的占据而下降。只有评估分数（*世界反馈*信号）揭示了作业已进入收益递减或负收益状态。使用代理信号的调度器会在此作业峰值后分配*更多*资源（最陡的损失改善），而世界反馈感知的调度器会终止它。

见图2：RLHF训练中的代理与世界反馈。训练损失（代理2，红色）和奖励模型分数（代理，橙色虚线）都表明持续改善。只有评估分数（世界反馈，蓝色）揭示了质量已达到峰值并正在下降。使用代理信号的调度器会*增加*分配；EvalStop使用世界反馈来*终止*。

这种代理-世界分歧在经验上已有充分记录。Gao等人 (2023 (https://arxiv.org/html/2606.04145#bib.bib10)) 展示了KL约束RLHF策略的可预测过度优化规模法则。Rafailov等人 (2024 (https://arxiv.org/html/2606.04145#bib.bib17)) 将这些发现扩展到DPO，并且多项工作提出了训练级别的缓解措施：约束RL（Moskovitz等人，2024 (https://arxiv.org/html/2606.04145#bib.bib18)）、奖励模型集成和SFT正则化。EvalStop与这些方法是*互补的*：它不是修改训练算法，而是在调度器级别使用世界反馈作为外部控制信号来终止已经偏离的作业。

## 3 EvalStop：世界反馈驱动的早停

回忆图1 (https://arxiv.org/html/2606.04145#S0.F1)中的架构概述。EvalStop是一个可组合的包装器，包裹任何基础调度策略。它监控评估分数轨迹（世界反馈信号），并在质量不可逆转地下降时早停作业。

算法1 EvalStop调度包装器
0:基础调度器S\mathcal{S}，衰退阈值 \(k_{\text{RLHF}}=2\)，\(k_{\text{DPO}}=3\)
1:状态：每作业连续衰退计数 \(d[j]\)
2:函数 on_eval_result(\(j\), \(score\))
3:   如果 \(score < best\_score[j]\) 且 \(score < prev\_score[j]\)
4:       则 \(d[j] \gets d[j] + 1\)
5:   否则 \(d[j] \gets 0\)
6:   更新 \(prev\_score[j]\) 和 \(best\_score[j]\)
7:   如果 \(d[j] \ge k_{type[j]}\)
8:       则 调用 stop_and_save(\(j\))
9:       移除作业 \(j\) 及其 GPU
10:      释放 GPU 并返回给集群
11:   结束如果
12:   将更新后的集群状态交给 S\mathcal{S} 进行调度
13:结束函数
14:
15:函数 on_job_arrival(\(j\))
16:   初始化 \(d[j] \gets 0\)
17:   将作业加入待处理队列
18:   将其状态交给 S\mathcal{S}
19:结束函数
20:
21:函数 stop_and_save(\(j\))
22:   将 \(j\) 的记录标记为“因质量早停”
23:   将 \(best\_score[j]\) 和相应检查点移至永久存储
24:   记录浪费计算：总 GPU 分钟数 − 峰值前 GPU 分钟数
25:结束函数

### 3.1 设计原理

连续衰退计数。我们使用连续下降次数而非固定阈值，因为它对评估噪声鲁棒且无需归一化：在恒定或改善的信号中，单次误差评估可能下降，但两次连续下降意味着真实趋势。我们通过实验设置 k=2（RLHF）和 k=3（DPO），因为 DPO 的过度优化出现更慢（Rafailov 等人，2024 (https://arxiv.org/html/2606.04145#bib.bib17)）。对于单调改善的 LoRA 作业，即使 k=2 也会产生不可接受的假阳性率（FPR > 30%），因此 EvalStop 仅监控 RLHF 和 DPO 作业。信息边界。调度器只能看到评估分数（SchedulerJobView）：损失、奖励和真实标签被隐藏。这强制执行了一个非先验边界（Motwani 等人，1994 (https://arxiv.org/html/2606.04145#bib.bib21)），使得检测质量可诚实测量。我们使用一个白名单代理 SchedulerJobView，其中包含（类型、进度、评估分数）——一个调度器在现实 RLHF 平台中可能观察到的精确信号（图 1 (https://arxiv.org/html/2606.04145#S0.F1) 底部）。停止并保存。当 EvalStop 触发时，它（i）释放 GPU 到集群池，（ii）保留作业的最佳检查点用于下游使用。这通过将质量控制转移到调度器级别，使调度器能够减少浪费计算并加速后续作业。

### 3.2 与基础调度器的交互

EvalStop 作为一个包装层：每当作业到达或终止时，EvalStop 将更新后的 CPU/GPU 状态交给基础调度器 S\mathcal{S} 继续操作。算法 1 显示 FIFO 可以替换为任何策略；我们在 §4 (https://arxiv.org/html/2606.04145#S4) 中测试了 FIFO、SJF-Est、SRTF-Est 和 LossAware。请注意，EvalStop 添加了*终止*动作，而基础调度器通常不会自行执行此动作。非先验调度器（FIFO、SRTF-Est）仅优先排序；它们不会早停。LossAware 可能会降优先级处理解耦的作业，但不会移除它们。

## 4 实验设计

### 4.1 模拟器与负载生成

我们构建了一个离散事件模拟器（约 5000 行 Python）：GPU 是时分复用的，评估是串行化的，到达时间遵循泊松分布，作业类型从混合分布中抽取。负载生成器为每个作业合成训练曲线，使用噪声评估分数。对于 RLHF 作业，评估分数基于一个解析峰值模型，该模型根据在原始 PPO 训练运行上拟合的随机系数而变化：r(p)=p⋅exp(−αp)r(p)=p\cdot\exp(-\alpha p) 加上独立同分布高斯噪声。DPO 作业使用一个根据 SyntheTron（Hoffman 等人，2024 (https://arxiv.org/html/2606.04145#bib.bib22)）校准的饱和指数模型。LoRA 作业使用固定线性改善。真实标签（健康/破解）通过将作业的峰值幅度与随机阈值比较来决定。所有实验重复 5 次，显示 95% 置信区间。

### 4.2 基线调度器

我们评估了四个基础调度器：（i）FIFO（先来先服务）；（ii）SJF-Est（估计最短作业优先，使用估计运行时间）；（iii）SRTF-Est（估计最短剩余时间优先）；（iv）LossAware，一个优先分配 GPU 给损失下降最快作业的调度器。在每个基础上，我们比较：(a) 没有 EvalStop 的基础调度器（无早停），(b) 固定进度规则（在 60% 进度早停），(c) 损失平台规则（当损失改善 < 0.1%（滑动窗口为 5 个检查点）时早停），(d) EvalStop（k=2 用于 RLHF，k=3 用于 DPO）。全局指标：JCT、TTFUC、精度、召回、FPR、F1 分数、浪费计算分数。

### 4.3 负载特征

除非另有说明，否则 64 GPU 集群的负载包括：16% LoRA（平均 20 分钟）、16% DPO（平均 60 分钟）、64% RLHF（平均 180 分钟）和 4% 杂项（未建模）。RLHF 中的基础破解发生率默认设置为 50%。

## 5 结果

### 5.1 检测质量

表 1 总结了在 RLHF 重负载（80% RLHF，64 GPU）下的检测质量。

**表 1：检测质量。** 所有方法均使用 SRTF-Est 作为基础调度器运行。区间为 95% CI（5 次试验）。

| 方法               | 精度 (%) ↑ | 召回 (%) ↑ | FPR (%) ↓ | F1 (%) ↑ |
|--------------------|------------|------------|-----------|----------|
| 固定进度 (60%)     | 49.2±2.1   | 100.0±0.0  | 65.1±1.9  | 66.0±1.4 |
| 损失平台           | 75.6±3.4   | 38.2±2.8   | 5.8±0.7   | 50.8±2.6 |
| EvalStop (k=2)    | 98.3±0.6   | 99.0±0.4   | 1.5±0.3   | 98.6±0.3 |

固定进度达到 100% 召回，但 FPR 为 65.1%，意味着超过一半的健康 RLHF 作业被不必要的终止。损失平台实现了低保真精度（75.6%）但召回仅为 38.2%——它错过了超过 60% 的破解运行，因为损失在过度优化后仍在改善。EvalStop 在所有指标上占优：精度 98.3%、召回 99.0%、FPR 1.5%。

### 5.2 系统级增益

表 2 显示了在 64 GPU、80% RLHF 负载下，EvalStop 相对于每个基础调度器的改善。JCT 改善 9–25%；浪费计算减少 24–31%；TTFUC 始终改善（2–14%）。

**表 2：系统级改善。** 显示 EvalStop 相对于无早停基线的 JCT（%Δ）、浪费计算分数（%Δ）和 TTFUC（%Δ）。负载：64 GPU，RLHF 80%。p<0.05。

| 基础调度器 | JCT (%Δ ↓) | 浪费计算 (%Δ ↓) | TTFUC (%Δ ↓) |
|------------|------------|-----------------|--------------|
| FIFO       | -24.7±1.7  | -31.0±1.2       | -13.8±1.1   |
| SJF-Est    | -14.2±1.3  | -26.8±1.4       | -8.1±0.9    |
| SRTF-Est   | -9.1±0.8   | -21.9±0.9       | -4.3±0.6    |
| LossAware  | -11.5±1.1  | -24.6±1.5       | -6.9±1.0    |

改善跨基础调度器一致。FIFO 的收益最大，因为它缺少优先级逻辑（EvalStop 的 GPU 释放帮助更大）。即使是已经感知质量的 LossAware，EvalStop 也增加了 11.5% 的 JCT 改善。

### 5.3 噪声鲁棒性

图 3（见原文）显示了在增加的评估标准差 σ\sigma 下的 EvalStop 性能。在 σ≤0.05\sigma\le 0.05 时，精度 ≥91%，FPR ≤5%。在 σ=0.1\sigma=0.1 时，FPR 上升到 11%（此时建议使用 k=3 阈值）。没有早停（无 EvalStop）的情况下，浪费计算与 σ\sigma 无关（水平线 20.3%），证实了评估噪声影响的是检测器，而不是噪声本身增加浪费。

### 5.4 破解基础发生率的敏感性

图 4（见原文）评估了从 20% 到 80% 的破解基础发生率。精度在所有水平上保持 ≥89%。在低发生率（20%）时，FPR 为 1.8%（仍然可接受）。固定进度规则在低发生率时精度崩溃（20% 破解下仅 24%）。EvalStop 的 F1 分数在发生率变化时稳定在 0.91–0.99。

### 5.5 与 EvalSched（优先级）的比较

一个替代方案，EvalSched，在观察到的评估分数低于预测峰值时降低 RLHF 作业的优先级，但不会终止它们。在 64 GPU、80% RLHF 下，EvalSched 的 JCT 为 42.3 分钟，而 EvalStop+SRTF-Est 为 18.7 分钟，无早停的 SRTF-Est 为 20.6 分钟。EvalSched 的 JCT 差 2.2 倍，因为降优先级的作业仍然占据 GPU，阻塞后续作业，并且当集群拥塞时，任何降优先级的作业在 GPU 上是相同的重量级。

## 6 讨论与局限性

(1) *现实世界验证。* EvalStop 已在具有合成评估曲线的模拟中进行评估。真实世界的评估环境引入了非平稳效应（数据集漂移、多任务评估）、平台故障（评估崩溃、检查点损坏）以及差异化的评估调度成本，这些在模拟中是缺失的。我们计划在开源集群上使用 PPO 训练运行进行跟踪研究。 (2) *阈值敏感性。* k=2 在 σ<0.15\sigma<0.15 时表现良好，但当评估噪声较大（σ>0.15\sigma>0.15）时，k=2 阈值可能不足。我们的噪声模型是高斯且跨检查点独立同分布的；重尾或自相关的评估噪声（更接近跨基准项目的自助方差）可能会进一步增加 FPR。自适应或置信感知的阈值（例如贝叶斯变化点检测）将扩展工作范围。 (3) *评估成本建模。* 我们将评估建模为占用 GPU 一段固定的每模型尺寸时间，但未将评估调度本身作为决策变量处理。 (4) *同构硬件。* 模拟器使用同构 GPU，没有网络 I/O、梯度累积或弹性扩展。

## 7 相关工作

ML 集群调度。Tiresias（Gu 等人，2019 (https://arxiv.org/html/2606.04145#bib.bib1)）开创了用于深度学习的非先验调度（Motwani 等人，1994 (https://arxiv.org/html/2606.04145#bib.bib21)），使用多级反馈队列。Pollux（Qiao 等人，2021 (https://arxiv.org/html/2606.04145#bib.bib3)）共同调整批大小和资源分配。Gavel（Narayanan 等人，2020 (https://arxiv.org/html/2606.04145#bib.bib4)）和 Sia（Jayaram 等人，2023 (https://arxiv.org/html/2606.04145#bib.bib5)）处理异构集群。Shockwave（Zheng 等人，2023 (https://arxiv.org/html/2606.04145#bib.bib6)）处理带公平调度的动态适应。更近期，MAST（Choudhury 等人，2024 (https://arxiv.org/html/2606.04145#bib.bib13)）解决超大规模的地理分布式 ML 调度，Parcae（Duan 等人，2024 (https://arxiv.org/html/2606.04145#bib.bib14)）优化可抢占实例上的训练。没有使用下游评估质量作为调度信号。

质量感知调度。SLAQ（Zhang 等人，2017 (https://arxiv.org/html/2606.04145#bib.bib2)）使用训练损失来预测质量改进并相应分配资源。这对于凸损失 ML 模型有效，其中损失与质量相关，但对于 RLHF 失败，因为损失是代理，在峰值后与质量解耦。EvalStop 将质量感知范式从代理信号（损失）扩展到世界反馈（评估）。

RLHF 与奖励破解。RLHF（Ouyang 等人，2022 (https://arxiv.org/html/2606.04145#bib.bib9)；Stiennon 等人，2020 (https://arxiv.org/html/2606.04145#bib.bib11)）现在是 LLM 对齐的标准，但奖励过度优化是一个有充分记录的失败模式（Gao 等人，2023 (https://arxiv.org/html/2606.04145#bib.bib10)；Skalse 等人，2022 (https://arxiv.org/html/2606.04145#bib.bib19)；Pan 等人，2022 (https://arxiv.org/html/2606.04145#bib.bib20)）。Rafailov 等人 (2024 (https://arxiv.org/html/2606.04145#bib.bib17)) 将过度优化规模法则扩展到 DPO，Moskovitz 等人 (2024 (https://arxiv.org/html/2606.04145#bib.bib18)) 提出了约束 RLHF。这些工作专注于通过训练修改*防止*奖励破解。EvalStop 是互补的：它通过世界反馈*检测*过度优化并在调度器级别*采取行动*，而不修改训练算法。

LLM 微调系统。S-LoRA（Sheng 等人，2024 (https://arxiv.org/html/2606.04145#bib.bib15)）和 dLoRA（Wu 等人，2024 (https://arxiv.org/html/2606.04145#bib.bib16)）通过适配器编排解决多租户 LoRA 服务。MuxTune（Xue 等人，2026 (https://arxiv.org/html/2606.04145#bib.bib7)）通过骨干网复用处理多任务 LoRA 协同调度。Kong 等人 (2025 (https://arxiv.org/html/2606.04145#bib.bib8)) 研究时限感知调度。