论文工作

Maestro · DeepShare · ElastiCo · 多目标性能预测 · SagePilot · 字节 Lumen 实习 · 面试问答

Module Switcher

论文工作

内容模块

ICDCS 2026 Maestro

Q: 请介绍一下 Maestro 这项工作。

我讲的工作是 Maestro，它解决的是：多个 Agent 工作流共享有限 GPU 时，怎样减少长任务对短任务的阻塞，同时让多个模型和请求更有效地使用显存。

先解释一下场景。比如一个旅行规划任务，系统先分析用户需求，再调用工具查航班和酒店，最后生成完整行程。这一个用户任务会触发多次模型调用，我们把一次模型调用叫作一个 stage，也就是一个阶段。不同阶段有依赖，也可能使用不同模型。

这里的特点是，同样是调用模型，有的阶段只生成一小段工具参数，有的阶段要写很长的分析。它们看起来都是一个请求，实际运行时间和显存需求却可能差很多。当这些工作流与后台批处理一起运行时，长任务就可能挡住用户正在等待的短任务。

同时，显存里既要放模型权重，也要放每个请求的 KV Cache。KV Cache 可以理解为模型生成过程中保存的上下文计算结果，输入和输出越长，通常需要的空间就越多。如果按最大长度给每个请求预留，短请求会浪费空间；多个模型又都想留在 GPU 上，就容易互相挤占。模型换出去以后，再使用还需要重新加载。

所以我们希望提前知道：这次调用大概要生成多长、运行多久、需要多少显存，再用这些信息安排请求和模型。Maestro 分成三个部分：预测提供需求，节点运行时管理实际资源，调度器决定谁先执行、放到哪里。

第一个部分是输出长度预测。

我们发现，Agent 当前在做什么，比单看输入长度更有帮助。比如同一个旅行助手，查航班时可能只生成几十个 token 的查询参数，最后整理行程时可能输出上千个 token。这里预测的是模型生成的工具参数，不是工具返回多少内容，也不是查询工具要运行多久。

因此我们用了两阶段方法。先预测这次调用触发工具的概率，再把这个概率和其他信息一起交给长度回归器，预测会生成多少 token。前一步相当于给后一步提供一个线索：这次更像是在调用工具，还是在生成一段回答。

具体实现上，MiniLM 提取输入文本的语义，LightGBM 结合输入长度、工具数量、阶段位置和前一次调用情况做预测。工具调用分类器在不同 Agent 之间共享，长度回归器则按 Agent 区分，因为检索、分析、总结这些角色的输出规律不同。两阶段之间传递的是概率，不是先硬分成两类再分别处理。

拿到预测长度后，再换算成两项资源需求。时间上，用输入处理时间，加上预计生成 token 数乘以每个 token 的生成耗时；显存上，根据模型每个 token 的 KV 大小，估计输入加输出需要多少空间。

第二个部分是节点上的显存管理。预测告诉我们大概要用多少，节点运行时负责检查现在到底能不能放得下。

它同时管理模型权重和 KV Cache。对于模型，近期还会使用的尽量保留在 GPU；暂时不用的可以把权重移到 CPU，并保留一部分运行上下文，降低下次恢复成本；更冷的模型再退到磁盘或远端。这样，调度器看到的不只是“这个节点有没有模型”，还知道“这个模型要等多久才能用”。

对于 KV，我们利用 CUDA 虚拟内存管理，把虚拟地址和实际物理显存分开。可以先留出足够的地址范围，实际生成需要空间时，再映射物理页。这样不必一开始就把所有请求的最大空间都占满，但实际显存容量没有变大。

所以每次接收请求、增加分配时都要检查容量，预测预算外还要留余量。如果空间不够，就先考虑对其他任务影响较小的回收方式，并估计以后恢复这些状态要花多少时间，把这个代价反馈给调度器。预测低估时，也不能绕过容量检查继续分配。

第三个部分是调度。这里有两个不同的问题：一个是哪些工作流先推进，另一个是当前这次调用放在哪个节点。

先说执行顺序。我们采用预计剩余时间较短的工作流优先，也就是 SRTF 的思路。这里看的是整个工作流预计还需要多久，不只是眼前这一小步。当前阶段的时间来自长度预测，后续阶段的时间则根据工作流当前位置和相似历史执行情况估计。

举个假设例子：任务 A 当前这一步只要 1 秒，但后面预计还有 20 秒；任务 B 当前这一步要 3 秒，做完就结束。在其他优先级条件相同的情况下，我们更倾向先推进 B，让一个用户任务尽快完成。单看当前阶段最短，就会优先 A，忽略后面的依赖链。

再说放在哪个节点。我们先排除显存无法安全承载请求的节点，再给剩余节点打分。网络和显存匹配越合适，分数越高；开始执行前要等得越久、为它腾空间造成的恢复代价越大，分数越低。 最后选分数最高的节点。

这里开始前的等待，包括节点排队和模型激活。比如两台机器网络条件差不多，一台模型已经准备好，但还要排队 10 秒；另一台没有排队，模型恢复需要 3 秒。在其他条件相同的情况下，第二台更合适。如果第二台还需要回收别人的状态，造成很大的恢复代价，就要把这部分损失一起算进去。这里数字只是为了说明取舍。

交互任务和后台任务竞争时，我们还支持在阶段边界让出执行机会。也就是后台任务完成当前这次模型调用后，先不让它继续下一次，给交互任务让路。普通调度抢占不会直接打断正在进行的生成，所以遇到特别长的一次调用，交互任务仍可能等待。我们也设置了切换收益门槛、冷却时间和等待时间提升优先级，减少反复切换和后台任务长期得不到执行的问题。

把三个部分连起来看：一个请求到来，预测器先估计长度，再换算成时间和 KV 需求；节点报告模型状态、可用显存，以及腾空间的代价；调度器利用这些信息排序和选节点；执行结束后，再把真实长度和资源使用反馈回来，校准后续预测。

实验方面，论文包括物理集群实验和基于执行记录的模拟。高争用模拟中，相比 EDF，SLO 达成率提高了 23.6 个百分点，也就是更多请求能在规定时间内完成。另一个显存实验中，KV 预留的物理显存开销降低了 67.2%。这两个数字对应不同实验。

我认为这项工作的关键，是把 Agent 的行为差异变成资源调度可以使用的信息。我们先估计调用成本，再让弹性显存管理和工作流调度一起利用这些估计，减少长短任务互相阻塞，也减少多模型服务中的保守预留和反复加载。

展开：Maestro 的调度算法、评分与三个模块的关系

排序和放置使用不同的依据

工作流排序：预计剩余时间 = 当前阶段预计执行时间 + 后续工作流时间估计。后续项来自近期相似状态的执行记录中位数，状态包括角色、阶段模板、调用序号和工具意图等。工作流依赖仍需满足；预测工具参数的长度不能替代工具执行耗时。

节点放置：先检查策略和显存可行性，再计算分数，选择最高分节点：

$$S(N,T)=A(N,T)-\lambda T_{ready}(N,T)-\mu C_{deg}(N,T)$$

N 是候选节点，T 是当前模型调用。
A 是匹配分数，考虑网络距离和显存 best-fit；不是单纯空闲显存越多越好。
T_ready 是开始执行前的预计等待，由节点排队时间与模型激活时间组成。
C_deg 是腾出资源所需回收方案带来的恢复代价；影响活跃执行还会计入额外惩罚。
λ、μ 控制两类代价的权重。论文对指标做稳健归一化，时间项以毫秒报告，默认 λ = μ = 1。

论文公式 (5) 是候选节点评分，公式 (7)–(8) 是工作流剩余时间估计；两者共同服务调度，但不能合并成一个声称全局最优的 cost。Algorithm 3 遍历可行节点并选最高分，节点资源协调的 Algorithm 2 按状态优先级贪心构造回收方案。

三个模块分别交付什么

模块	输出	谁使用
长度与成本预测	输出 token 数、预计阶段耗时、KV 需求	排序使用时间；节点准入使用显存预算。
节点运行时	能否承载请求、模型激活时间、显存余量、回收恢复代价	调度器过滤并评分；运行时执行资源管理动作。
集群调度	工作流推进顺序、节点选择、阶段边界让出执行机会	节点执行后回传真实用量，供后续校准。

普通抢占与内存压力处置要分开

普通交互优先调度在两次模型调用之间切换，避免打断正在 decode 的调用；显存压力下的分级处置还可能涉及活跃 KV 换出或中止执行，这属于更高扰动的资源降级，需要计入恢复和中断代价。不能把阶段边界抢占说成任何情况下都不会中止活跃执行，也不能声称交互请求一定立即运行。

实验数字的口径

23.6 个百分点是高争用模拟中相对 EDF 的 SLO 达成率提升；67.2% 是显存实验中的 KV 预留 HBM 开销下降，不是总显存或每个请求实际 KV 数据量都下降相同比例。预测与后续服务实现的差异以两阶段预测实现章节的核对记录为准。

来源：Maestro 论文 §III-B–D、公式 (2)–(8)、Algorithm 1–3 与 §IV；预测服务细节参考此前核对的 concerto-runtime@8ee8969。

📄 论文原文：ICDCS 2026 — Maestro PDF

问题背景

传统 LLM 推理面对的是独立的一问一答请求。但现在越来越多的应用把多个 agent 组成协作工作流：比如旅行助手里有"需求分析 agent"、"机票搜索 agent"、"酒店推荐 agent"、"行程整合 agent"，它们之间有 DAG 依赖，一个用户请求触发十几次甚至几十次 LLM 推理调用（称为 stage）。

这带来了三个新挑战：

输出长度剧烈波动：工具调用输出几十 token（JSON），用户交互输出几百上千 token。KV 缓存需求差异巨大，固定分配要么浪费要么 OOM。
多模型共存的内存压力：不同 agent 使用不同模型，一块 GPU 需要同时驻留多个模型权重加上所有请求的 KV 缓存。
混合延迟要求：交互式 stage 要低延迟，批处理 stage 要高吞吐。不区分优先级就会造成队头阻塞。

系统设计

核心思路：不把 LLM 请求当黑盒，利用 agent 上下文做前瞻性预测，指导内存管理和调度。

组件一：两阶段输出长度预测

为什么需要预测输出长度？

Agent 工作流中的调用成本差异很大：生成工具参数通常较短，分析和总结可能较长。提前估计输出长度，可以同时为请求排序、模型驻留和 KV 预算提供依据。按需分配负责执行时的空间管理，预测则帮助系统提前安排未来需求。

两阶段流水线

消息、工具描述 → MiniLM → 384 维语义向量
                              ├→ 全局 PCA 32 维
                              │       + 结构化特征
                              │       → 全局 LightGBM 分类器
                              │       → 工具调用概率
                              │                │
                              └→ Agent PCA 32 维
                                      + 结构化特征 + 工具调用概率
                                      → Agent 专属 LightGBM 回归器
                                      → log(1 + 输出长度)
                                      → expm1 → token 数

MiniLM 负责提取语义，LightGBM 负责分类和回归。分类器传递连续概率，让回归器利用工具调用的可能性，而不是先把请求硬切成两个类别。全局分类器共享跨 Agent 的行为规律，专属回归器适配各 Agent 的输出分布。

服务中的输入特征

当前服务配置使用输入 token 数、工具数量、思考模式、是否为首个阶段、阶段序号、同一 Agent 的调用次数、上一阶段输出长度，以及 PCA 语义特征。Agent 名称用于选择模型包；会话 ID 用于获取上下文。语义编码处理系统提示、对话和工具名称与描述，长文本通过重叠滑动窗口聚合。

分类器使用全局 PCA，回归器使用 Agent 专属 PCA；线上共用同一份原始语义向量，再分别投影。这让分类和回归保留各自关注的语义方向，同时减少重复编码。

训练目标与冷启动

当前服务的分类器学习工具调用标签，回归器对真实输出 token 数做 log1p 变换，采用 alpha=0.5 的分位数回归，预测中位数长度；近期样本获得更高权重。模型包保存模型、PCA 参数和特征顺序，推理按同样的顺序组装输入。

论文方法包含 isotonic 概率校准和冷启动时的共享全局模型。后续服务快照直接使用 predict_proba，缺少 Agent 模型或全局分类器时返回默认 150 token。资源安全余量由预算策略处理，不应把当前中位数回归器称为偏向高估的损失函数。

两阶段带来的价值

工具调用概率为长度回归提供显式的行为模式信号，一阶段直接回归则是自然的对照方法。论文报告输出长度 MAE 为 165.43 token、R² 为 0.7774，相比 Magnus 的 MAE 降低 19.2%。消融显示工具意图特征在非 CoT 场景更有帮助；开启 CoT 后，两种模式都可能包含推理文本，因此收益会随工作负载变化。

预测信号如何驱动下游组件

组件	消费方式	作用
KV 预算	每 token KV 字节数 ×（输入长度 + 预测输出长度），再加余量	估计未来需求；执行时结合真实容量按需增长
阶段成本	prefill profile + 每 token decode profile × 预测输出长度	估计当前阶段执行时间
工作流排序	当前阶段成本 + 后续工作流时间估计	决定任务优先级，减少依赖链上的等待
准入与放置	结合预测需求、模型状态和可用容量	选择可承载任务的节点，安排模型驻留与回收

论文根据近期低估误差调整资源安全余量；预测服务本身输出概率与长度，实际容量检查由资源管理层完成。节点运行结束后回传真实用量，异步整理数据和更新模型。

实现依据：concerto-runtime@8ee8969 中的 python-predictor；方法与实验结果依据：Maestro 论文 §III-B、§III-D、§IV。

组件二：节点级弹性内存管理

模型状态管理：五种状态按层级流转——

Running：权重在 GPU，可立即执行推理
Sleeping：权重移到 CPU，但 GPU 上保留 CUDA Graph 和 JIT 内核缓存（约 0.5GB），重新激活省 5-8 秒
CPU-resident：权重完全在 CPU 内存
Disk-resident：权重在本地 NVMe
Remote：权重在远程存储

层级化 LRU 逐级淘汰，最热的模型留 GPU，最冷的逐步退到远端。

KV 缓存管理：CUDA VMM 虚拟内存超配——40GB 物理 GPU 上分配 122GB 虚拟地址池（3 倍超配）。关键在于虚拟地址和物理页分离，按需映射物理页。三层防护：(1) 虚拟 vs 物理分离，不会同时达峰；(2) 准入控制——每个 stage 检查剩余物理页是否够；(3) 映射失败时拒绝 stage 而非崩溃。五级降级策略保证极端情况也不会 OOM。

内存核算：M_kv + M_res ≤ M_total，安全裕度 ρ ∈ [0.1, 0.3]，偏向高估以避免低估导致 OOM。

组件三：工作流感知 SRTF 调度

基于预测的剩余执行时间排队（SRTF），优先执行快要完成的工作流。交互式和批处理 stage 分开排队。Stage 边界抢占——只在两次 LLM 调用之间切换，不打断正在解码的请求。

节点选择：适应度评分 S(N,T) = A(N,T) − λ·T_ready − μ·C_deg，综合模型就绪延迟和降级代价。

核心结果

+23.6pp

SLO 达成率 (vs EDF)

−67.2%

KV 预留内存

−84.8%

交互排队延迟

64×A100

14.4 万 stage

Maestro 高频问答

Q: 低估输出长度和高估，哪个危害更大？

低估远比高估危害大：(1) KV 缓存方面，低估导致预分配不够，解码到一半 OOM，请求被杀；高估只是暂时多占。(2) SRTF 调度方面，低估剩余时间导致长作业排到队首，造成队头阻塞；高估则长作业排后面，影响较小。所以设计安全裕度 ρ 偏向高估。

Q: CUDA VMM 超配 3 倍不怕 OOM 吗？

三层防护：(1) 122GB 是虚拟地址空间，物理页按需映射，不会同时分配满；(2) 每个 stage 进来先做准入控制，检查剩余物理页是否够预测需求；(3) cuMemMap 返回失败时拒绝该 stage 而非崩溃。多 agent 的 KV 使用弹性大，统计上不会同时达峰，类似内存超卖的思路。

Q: 五种模型状态 vs 四层存储的关系？

四层存储：GPU → CPU → Disk → Remote。五种状态多出一个 Sleeping——权重在 CPU，但 GPU 上保留 CUDA Graph 和 JIT 内核缓存（约 0.5GB），重新激活省 5-8 秒。Sleeping 横跨 GPU 和 CPU 两层。设计原因：模型切换频繁时，CUDA Graph 的重建开销可观。

Q: Stage 边界抢占够用吗？为什么不做 token 级？

Token 级抢占需要和解码引擎深度集成，还要做 KV 缓存迁移，工程复杂度极高。Stage 边界抢占只需更新元数据，实测效果已足够：交互排队从 11 秒降到 2 毫秒。超长解码阶段可作为 future work。

Q: 新 agent 角色上线没有历史数据怎么办？

三级回退：(1) per-role 数据不足时回退到全局模型；(2) 结构化特征（工作流位置、工具可用性）本身就有信号；(3) post-execution profiling 增量更新，几轮执行后适应新角色。

Q: 适应度评分 S(N,T) 的权重怎么设？

S(N,T) = A(N,T) − λ·T_ready − μ·C_deg。默认 λ = μ = 1（毫秒量级）。交互式 stage 增大网络延迟权重。用 robust min-max 归一化（5/95 分位数裁剪），防止异常值主导。验证集上选定后跨负载固定。

Q: 什么是"LLM 多智能体工作流"？给一个具体例子。

比如一个旅行助手 Agent：用户说"帮我规划去东京的行程"，系统会依次调用：需求分析 Agent（解析意图）→ 机票搜索 Agent（调工具查航班）→ 酒店推荐 Agent（查酒店）→ 行程整合 Agent（汇总输出）。每个 Agent 背后是一次 LLM 推理调用（称为 stage），一个用户请求可能触发十几次甚至几十次 LLM 调用。这些 stage 之间有 DAG 依赖关系，不同 Agent 可能使用不同模型，输出长度差异巨大——工具调用返回几十 token 的 JSON，用户交互输出几百上千 token。

Q: "解码成本不确定"为什么是个问题？固定按最大长度预留不行吗？

固定按最大长度预留简单但保守，实际输出较短时会浪费空间。只按需分配能减少浪费，却不能提前判断哪些请求会长时间占用资源。我用 Agent 输入与上下文预测输出长度，帮助排序、模型驻留和 KV 预算；运行时再按真实用量增长，并在空间紧张时执行准入或回收策略。

Q: 为什么分类器和回归器都用 LightGBM（GBDT），而不是用深度学习模型做分类/回归？

MiniLM 负责提取文本语义，LightGBM 将语义特征与输入长度、工具数量、阶段上下文结合起来做分类与回归。这样的分工适合结构化特征与文本信息混合的场景，也便于给不同 Agent 训练专属模型。工程上可以预加载树模型、复用编码结果并控制线程数量。性能评估要把文本编码与接口排队一起计入，不能只拿树模型的一次调用时间代表整个预测服务。

Q: 预测特征具体有哪些？语义特征怎么提取的？

落到当前服务实现，结构化特征是输入 token 数、工具数量、思考模式、首阶段标记、阶段序号、同一 Agent 的调用次数和上一阶段输出长度。Agent 名称用于选择专属模型。语义特征由 MiniLM 对系统提示、对话和工具描述编码，长文本采用重叠滑动窗口，聚合为 384 维向量，再分别通过全局 PCA 和 Agent PCA 降到 32 维。分类器与回归器各用对应投影，回归器还接收工具调用概率。

Q: 预测器出错了怎么办？如果预测输出 100 token 实际输出了 1000 token 呢？

预测给出初始需求，实际分配持续接受容量约束。KV 随生成按需增长，每次追加前检查空间；不足时暂停准入，或选择合适的回收与恢复策略，再将低估反馈到后续预算校准。当前回归器输出中位数，保守余量属于资源预算策略。这样预测负责改善利用率，运行时负责处理超出预算的情况。

Q: KV 预留显存降低 67.2%，但这不就是靠 CUDA VMM 超配"骗"出来的吗？实际物理显存并没有减少啊？

这个问题需要分清两个层面：(1) 预留（reservation）≠ 实际使用。传统方案为每个请求预分配最大 KV 物理空间，即使实际输出很短也占着不放——这是真正的物理显存浪费。CUDA VMM 让虚拟地址远大于物理显存，但物理页按需映射，真正减少的是物理 HBM 占用；(2) 67.2% 降低的是预留的 HBM 物理显存，不是虚拟地址空间。通过输出长度预测来决定实际映射多少物理页——短请求只映射少量物理页，长请求映射更多，而不是所有人都按最坏情况分配。统计复用的前提是多 Agent 的 KV 峰值不重叠（某个 agent 在输出长文本时，其他 agent 可能正在工具调用或空闲），如果所有请求同时输出长文本确实还会 OOM，但实际 trace 中这种概率极低，且有准入控制兜底。

Q: EDF 作为 baseline 是不是太弱了？为什么不和更先进的调度方法比？

不只对比了 EDF。Maestro 的实验对比了 EDF、SRTF（无预测版本，纯按已执行时间排序）、FCFS（先到先服务）、Karma（LLM 推理服务最近的调度工作）。关键在于 Maestro 的核心贡献不是调度算法本身（SRTF 是经典算法），而是把预测信号引入 LLM-MAS 场景并设计了弹性显存机制来利用这些预测。实验设计的目的：EDF → 证明传统实时调度在 LLM-MAS 场景下失效（无法区分长短 stage）；SRTF（无预测）→ 证明纯 SRTF 因为不知道剩余时间只能按已执行时间估计，在双峰分布下偏差大；Maestro → 证明预测信号能显著提升 SRTF 的效果。对比不是为了证明"我的排序算法更好"，而是证明"预测信号有价值"。

Q: 为什么不直接用 vLLM/TGI 这些现成的推理框架？它们已经有 PagedAttention、continuous batching 了。

这是不同层面的优化，两者是互补而非替代关系：vLLM/TGI 优化的是单节点内推理引擎的 batching 和 KV 管理（PagedAttention 解决内部碎片、continuous batching 提高单模型 GPU 利用率）。Maestro 解决的是多节点、多模型、多 Agent 工作流层面的调度问题——一个用户请求涉及十几个 Agent stage、用多个不同模型、分布在多块 GPU 上，需要全局视角决定"哪个 stage 放哪块 GPU、哪个模型该常驻、KV 显存怎么跨请求复用"。Maestro 可以和 vLLM 配合使用：节点内用 vLLM 做推理引擎优化（PagedAttention、continuous batching），节点间用 Maestro 做全局调度和显存管理。事实上我们的原型实现就是基于 vLLM 做的，分级权重缓存和 CUDA VMM 超配是在 vLLM 之上的额外优化。

从 Agent 请求到输出长度

Maestro 把 Agent 请求的执行成本提前转成调度信号：先预测这次调用是否涉及工具，再预测会生成多少 token，最后将长度换算成时间和显存需求。工具调用通常生成较短的结构化参数，分析与总结通常生成较长文本；同样的输入长度，执行成本可能相差很大。

python-predictor 将预测封装成 FastAPI 服务。一次请求携带会话 ID、Agent 名称、消息、可用工具和阶段上下文；响应返回工具调用概率、预测输出长度和输入 token 数。

messages + tools ──→ 输入 token 计数
        │
        └─────────→ MiniLM → 384 维语义向量
                                  │
                     ┌────────────┴────────────┐
                     ↓                         ↓
                 全局 PCA                  Agent 专属 PCA
                  32 维                       32 维
                     │                         │
结构化特征 ──────→ 全局 LightGBM 分类器         │
                     │                         │
                  工具调用概率 ──────→ Agent 专属 LightGBM 回归器
                                               ↑
                                          结构化特征
                                               │
                                       log(1 + 输出长度)
                                               ↓
                                      expm1 → 预测 token 数

两阶段之间传递连续概率，不先用阈值把请求硬分成两类。Agent 的差异主要通过选择专属回归器和专属 PCA 来表达。

输入特征怎样获得

信息	实现字段或来源	提供的判断依据
输入长度	`node_input_tokens`；对消息与工具应用配置的 tokenizer 和 chat template	当前上下文规模
工具数量	`len(request.tools)`	可用工具的多少；不等于实际会调用工具
思考模式	`is_thinking_mode`	当前请求是否开启思考模式
阶段位置	`node_index_in_graph`、`is_first_node`	当前处于会话中的哪个阶段
同一 Agent 的调用次数	`model_index_in_agent`；接口根据 Redis 中已回传的节点计数	首次执行还是再次调用
上一阶段输出长度	`prev_node_output_length`；优先使用请求值，缺失时查 Redis	上游刚刚产生的信息规模
输入语义	System prompt、user/assistant 对话、工具名称和描述	请求到底要做什么

agent_name 用于查找模型包，session_id 用于关联会话上下文。当前特征选择配置纳入基础字段、阶段上下文字段、PCA 特征，并为回归器追加 classifier_probability；图的入度、出度、深度和角色 one-hot 不是这份配置中的显式输入。

代码也保留了历史均值、输出／输入比率等统计特征的生成与读取能力。最终哪些字段进入模型，由训练生成的 feature_names 决定；当前配置没有选择这些历史统计列。

文本编码与两套 PCA

语义编码使用 all-MiniLM-L6-v2，通过 ONNX Runtime 执行。默认长文本策略将内容切成最多 510 个 token 的窗口，步长为 255；窗口加上特殊 token 后按 512 长度组织，批量编码。每个窗口做带 mask 的 mean pooling 和归一化，再聚合窗口向量，得到 384 维表示。

全局分类器和各 Agent 回归器分别保存自己的 PCA 参数。两者复用同一个原始语义向量，但投影方向不同：全局 PCA 面向多种 Agent 的工具调用模式，Agent PCA 面向该角色的长度变化。降维后，语义特征与结构化特征一起输入树模型。

PCA 的运行时计算为：

低维向量 = (原始向量 - 训练均值) × 主成分矩阵的转置

这将语义模型负责的“理解输入”与树模型负责的“预测成本”分开，也便于复用编码结果。预测器内部支持传入预计算向量；普通 /predict 接口仍从文本调用编码器。

分类和回归怎样训练

全局分类器以 is_tool_call 为标签，采用 LightGBM 二分类；Agent 回归器以真实生成 token 数 usage_completion_tokens 为目标，先做 log1p 变换。全局分类器的预测概率作为额外特征注入回归器训练，与在线预测保持相同的两阶段结构。

当前服务训练配置如下：

项目	配置
全局分类器	binary objective，500 棵树，学习率 0.05
每个 Agent 的回归器	quantile objective，`alpha=0.5`，300 棵树，学习率 0.05
回归目标	`log1p(usage_completion_tokens)`
推理输出	`max(0, expm1(预测值))`，转成整数
单 Agent 最小训练样本数	50
每次加载的数据窗口	最近 12,000 条记录，再按时间排序
样本权重	按样本新旧顺序指数衰减，近期样本权重更高

medium 对应中位数预测。若要针对 KV 低估采用保守预算，应在资源估计与准入策略中设置余量，而不是把这个 alpha=0.5 的回归器解释成已经偏向高估。

论文方法包含分类概率的 isotonic 校准和冷启动时的共享全局模型；当前服务直接使用分类器的 predict_proba，缺少 Agent 模型或全局分类器时返回默认 150 token。这是论文方法与后续服务版本的具体差异。

长度怎样变成调度与 KV 预算

论文将输出长度转换为模型相关的执行时间和显存估计：

阶段执行时间 ≈ 该模型的 prefill 时间(输入长度)
             + 该模型的平均每 token decode 时间 × 预测输出长度

KV 需求 ≈ 该模型每 token 的 KV 字节数 × (输入长度 + 预测输出长度)

例如，一个 32 层、8 个 KV heads、head_dim 为 128 的 BF16 模型，每 token KV 为 128 KiB。输入 2048 token、预测输出 512 token，则全模型 KV 数据量约 320 MiB；若预算另留 20% 余量，则为 384 MiB。实际分配再考虑 block 对齐、TP/PP 分布和其他显存占用。

预测为调度器提供“这次调用预计要运行多久、需要多少空间”的信号。PagedAttention 负责高效管理已经发生的 KV 分配，两者可以配合：利用预测安排任务和模型驻留，再由运行时根据真实容量决定能否继续分配。

/predict 服务本身返回长度和概率，不执行显存页映射。后续 Concerto 通过 predictor_runtime.py 接入这些字段，并用于请求级投机长度选择；这是同一预测能力在新决策层中的复用。

运行反馈与服务开销

节点完成后通过 /callback/node 回传真实 token 用量和运行信息，暂存到 Redis；工作流完成后由 Celery 汇总、补充上下文与 embedding，再持久化。后台任务根据增量计数触发训练，Agent 模型更新后通知服务重载。

这条链路实现的是“运行反馈—异步训练—模型更新”，训练不放在单次请求的同步路径中。新到达的数据可以用于后续更新，具体更新频率由阈值控制；代码快照中的两个训练触发阈值均为 1,000,000。

服务启动时预加载 Agent 模型，预测线程将树模型限制为单线程；文本编码和模型计算放到受限工作线程中，避免阻塞 FastAPI 的事件循环。耗时分别记录编码、特征准备、Redis、分类、回归，以及接口排队与处理时间，便于判断瓶颈究竟在哪里。

来源：Maestro 论文 §III-B、§III-D；concerto-runtime 提交 8ee8969 中的 moarks-20260125/python-predictor/src/，主要包括 config.py、training/predictor.py、training/trainer.py、training/bert_encoder.py、api/prediction.py、tasks.py；接入逻辑位于 tpds-p0-p1-experiments-20260724/predictor_runtime.py。代码快照日期为 2026-08-29。

设计动机与核心方法

Q1：你的预测器到底解决什么问题？

我做的是面向 Agent 工作流的执行成本预测。一次工作流会多次调用模型，有的阶段只生成工具调用参数，有的阶段要长篇推理或汇总，单看模型大小和输入长度，很难判断这次请求到底会占用多久、需要多少显存。我利用 Agent 的输入语义和阶段上下文，先预测工具调用意图，再预测输出长度，把这个长度转成执行时间和 KV 预算，让调度器能够提前安排，而不是等请求执行起来才发现资源紧张。

Q2：为什么分两阶段，不直接预测输出长度？

因为工具调用和自由文本生成往往对应两种不同的输出模式。比如同一个研究 Agent，有时只是生成检索参数，有时要写一段分析，输出长度差别很大。我先用分类器估计工具调用概率，再把这个概率作为回归器的输入，让长度模型获得一个更明确的行为信号。

这里传递的是连续概率，不是先判成 0 或 1 再硬切换模型。一阶段回归也是合理基线；两阶段的价值在于显式利用行为模式，尤其是工具调用与文本输出长度差别较大的场景。

Q3：为什么用了 MiniLM，还要用 LightGBM？

它们承担不同任务。MiniLM 提取输入的语义，比如当前是在搜索、分析还是总结；LightGBM 把语义向量和输入长度、工具数量、阶段位置等表格特征结合起来，预测工具调用概率与输出长度。这种组合能利用文本信息，也便于按 Agent 单独训练和更新，部署时还可以预加载模型、控制 CPU 线程和复用编码结果。

Q4：具体用了哪些特征？举一个实际例子。

结构化特征包括输入 token 数、工具数量、是否开启思考模式、当前阶段序号、同一个 Agent 已经调用过几次，以及上一阶段输出长度。语义特征来自系统提示、对话内容和工具描述，用 MiniLM 编码后经 PCA 降到 32 维。

比如同一个 Agent 第一次拿到问题，可能需要先调用搜索工具；第二次已经拿到上游信息，就可能进入长文本分析。角色没变，但调用次数、前序输出和当前语义变了，这些信息能帮助模型区分两次调用的成本。

模型训练与工程实现

Q5：为什么每个 Agent 配一个回归器？

不同 Agent 的职责和输出风格相对稳定。检索 Agent、翻译 Agent、总结 Agent 的长度分布不同，使用专属回归器可以减少跨角色混杂。全局分类器共享“是否调用工具”的规律，各 Agent 回归器学习自己的长度模式，因此既有共享信息，也有角色适配。

实现上按完整 Agent 名称保存模型包，包里包含回归器、特征顺序和 PCA 参数。当前服务在 Agent 数据达到 50 条后才训练专属回归器；缺模型时先使用默认长度，待有足够数据后建立专属模型。

Q6：为什么分类器和回归器各有一套 PCA？

分类器要识别所有 Agent 中共同的工具调用模式，回归器要解释某个 Agent 内部的输出长度变化，因此两者关注的语义方向不同。全局 PCA 用全局数据训练，Agent PCA 用该 Agent 的数据训练；线上 MiniLM 只生成一份 384 维向量，再分别投影到两个 32 维空间，既共享编码成本，也保留任务差异。

Q7：长 prompt 怎么处理？直接截断吗？

默认使用重叠滑动窗口。每个窗口最多取 510 个内容 token，步长 255，加上特殊 token 后送入 ONNX 编码器批量处理。先对窗口内 token 做 mean pooling，再聚合各窗口向量。这样能覆盖长对话中的多个部分，避免只看开头或结尾；相应代价是 prompt 越长，需要处理的窗口越多，所以编码成本也要单独监控。

Q8：输出长度是长尾分布，怎么训练？

当前实现先对真实输出长度做 log1p 变换，再训练 LightGBM 分位数回归器，目标分位数是 0.5。log 变换压缩长短输出之间的尺度差异，中位数目标提供一个典型长度估计。线上再用 expm1 还原成 token 数。训练还对较新的样本赋予更高权重，使模型更关注近期运行模式。

预测长度和资源余量是两层决策：模型给出典型需求，调度器结合低估误差和剩余显存决定预留多少。

Q9：怎么把训练、预测和运行反馈接起来？

执行前调用预测服务，执行后通过 callback 回传真实输出长度和运行数据。节点数据先进入 Redis，工作流结束后交给 Celery 汇总入库；后台根据新增数据量决定是否训练，训练完成后让服务热重载模型。这样请求路径只负责预测，数据整理和训练异步进行，避免训练拖慢用户请求。

Q10：预测本身会不会成为瓶颈？你做了哪些工程处理？

会，尤其是长 prompt 和突发并发，不能只看一次树模型推理。我把成本拆成请求排队、文本编码、特征准备、Redis 访问、分类和回归。实现上使用 ONNX Runtime 编码、启动预加载模型、限制原生线程数量，并把同步计算放到受限工作线程中，让 HTTP 事件循环继续处理其他请求。优化时先看哪一段占主导，再决定是复用向量、调整并发，还是减少重复数据访问。

调度价值与 KV Cache 追问

Q11：vLLM 已经按需分配 KV，为什么还需要预测？

按需分配解决的是“已经需要这些 KV，怎样高效存下来”，预测解决的是“这个请求后面还会占多少资源、持续多久”。在多 Agent、多模型场景下，这个未来需求会影响请求排序、模型驻留和节点选择。例如两个请求当前都只占少量 KV，但一个很快结束，另一个会继续生成很长文本，调度策略就不应完全一样。预测提供前瞻信号，分页管理负责高效执行，两者配合才能把资源安排得更好。

Q12：预测 100 token，实际生成 1000 token，怎么办？

把预测作为初始预算，运行时继续按真实需求增长。每次追加前检查可用容量，不够时暂停新请求准入，或者选择低代价的回收与重算策略。与此同时，把这次低估反馈给后续预算校准。这里最关键的是把“提高利用率的预测”和“约束实际分配的容量检查”配合起来，这样预测不准时仍然有明确的处理路径。

Q13：Cache 命中会改变耗时，你的预测怎样适应？

我会把输出长度预测和运行成本估计分开。输出长度主要由任务语义和生成行为决定；相同输出长度在不同缓存、batch 和资源状态下，耗时可能不同。前缀命中后，时间估计要扣除已复用部分的 prefill 成本，再结合当前排队、decode 速度，以及可能的 KV 传输或重算成本。长度预测器提供需求信号，缓存与负载观测负责把需求换算成当前系统上的成本。

现有长度模型没有把前缀命中率作为显式特征，因此这类在线状态更适合先接到成本估计层。

Q14：当前阶段长度和整个工作流剩余时间有什么关系？

预测器先给当前调用的长度，再用模型的 prefill 和 decode profile 转成当前阶段时间。工作流调度还要考虑后续阶段：根据当前进度和相似历史状态估计后续成本，再与当前阶段合起来。工具调用时间也要单独处理，因为预测工具调用参数的 token 数，并不等于预测外部工具要执行多久。

Q15：怎么证明两阶段预测带来了实际价值？

我分两层看：预测层比较长度误差，并分别分析工具调用、非工具调用和思考模式；系统层看这些预测是否改善排序、显存预算和最终完成时间。论文中输出长度预测 MAE 为 165.43 token、R² 为 0.7774，相比 Magnus 的 MAE 降低 19.2%。消融比较直接回归、加入工具调用概率，以及加入语义特征后的变化。然后固定工作负载和运行资源，比较排队、SLO 达成与显存预留，建立从预测到调度收益的联系。

验证时按时间划分训练和测试，并把同一会话的数据关联起来检查，避免未来信息进入当前请求特征。平均误差之外，还要看长输出和低估尾部。

Q16：你这项工作的技术贡献怎么概括？

我把 Agent 工作流中的行为差异转化成了系统可用的资源信号：通过工具调用意图与输出长度的两阶段预测，提前估计阶段成本，再把这些估计接到工作流调度和多模型显存管理中。工程上补齐了预测服务、上下文获取、异步反馈和模型更新，使预测能够进入真实请求链路。这项工作的价值在于把模型行为、资源需求和调度决策连起来。

来源：Maestro 论文 §III–IV，以及 concerto-runtime@8ee8969 中 python-predictor 的训练、预测与回调实现。实现细节对应后续服务快照；实验数字取自论文。

内容模块

IEEE Cluster 2026 DeepShare

Q: 请介绍一下 DeepShare，包括为什么做、怎么共享，以及怎么抢占。

DeepShare 的背景是实验室里多个课题组共享 GPU 集群，资源有空闲，但任务仍然在排队。这里有两种不同的浪费：一种是团队的需求不同步，某个团队暂时不用自己的配额，其他团队却不能使用；另一种是 GPU 已经分给了任务，但单卡训练并没有用满计算和带宽能力。前者需要允许配额借用，后者需要让合适的任务同卡运行。

把资源共享起来以后，又会出现一个问题：团队自己的需求恢复时，要能优先获得配额内的资源，而且拿到 GPU 后不能因为共享干扰而运行得太慢。所以我们需要同时决定谁先运行、哪些任务可以共享，以及资源不够时回收谁。

首先，我们把任务分为 Guaranteed 和 Best-effort，也就是保障型和机会型。保障型任务使用团队配额内的权益，机会型任务使用剩余容量，并接受回收。配额代表团队可以获得多少保障资源，具体使用哪张物理卡由调度器决定。这样，暂时不用的资源就可以先交给机会型任务运行。

QAD 衡量的是：一个团队当前应该获得的保障，已经兑现了多少。它的分子是已经分配给保障任务的 GPU 数，分母是“团队配额”和“当前保障需求”中的较小值。需求包括正在等待和已经获得分配的有效保障任务；机会型任务的用量单独记账，不进入这个分子。

分母取较小值，是为了区分“没有需求”和“需求没有被满足”。需求低于配额时，平台只需要兑现实际需求；需求超过配额时，保障责任以配额为上限，超额提交不会增加保障权益。因此 QAD 为 1 表示当前应兑现的资源已经给足，低于 1 表示仍有保障缺口；没有保障需求时也取 1。这样才能识别真正等待保障资源的团队。

我们对这个瞬时值做指数平滑，减少任务短暂到达和结束造成的调度抖动。平滑后的 QAD 直接影响队列顺序和共享门槛。任务成功获得保障资源后，分配量增加，后续周期重新计算 QAD，调度优先级也随之调整。

第一，先补保障缺口，再利用短任务优先减少等待。系统先处理保障型任务；同类任务中，优先调度平滑 QAD 较低的团队，QAD 相同时再比较预测剩余时间。运行时间预测用于这个保障顺序之内的优化，避免短任务不断到来时，把欠保障团队的长任务一直压在后面。

第二，共享要同时检查资源能否容纳，以及双方性能能否接受。选中任务后，先尝试空闲 GPU，没有合适的独占位置才考虑通过 MPS 共置。干扰预测器估计两个任务各自的吞吐保持率，也就是共享后的吞吐与独占时吞吐的比值。显存、节点资源满足要求，并且双方保持率都达到门槛，才允许共享；默认考虑两任务共置，至少一方是机会型任务。

这个门槛会随租户保障状态和集群压力变化。任一方的 QAD 较低时，系统提高性能保持率要求，收紧共享，避免欠保障团队继续承受较大的性能损失。因此 QAD 管的是资源权益兑现，保持率管的是实际运行干扰，两者结合才能判断共享是否合适。运行后还会根据 DCGM 指标估计保持率；连续三个窗口不达标时，下一周期回收机会型伙伴，让保障任务继续运行。

第三，保障任务仍然放不下时，选择能释放所需资源、且打断代价较低的机会型任务。系统先尝试回收机会型任务多占的 CPU 和内存并重新放置；如果仍缺 GPU，再考虑清退整张卡上的机会型任务集合。先筛选清退后满足放置条件的 GPU，再根据任务预测剩余时间、累计抢占开销和集合大小比较代价，尽量保护快完成的任务，也减少反复打断同一任务。

这里 QAD 决定哪个团队先获得调度机会，当前保障任务放不下才触发回收；具体回收谁由上述代价决定。执行时先预留目标资源，再删除受害 Pod，等进程退出、资源实际释放后安排保障任务。训练恢复依赖任务自身的 checkpoint，回收动作本身不会保存训练进度。

工程上，配额控制器提供租户配置，Kubernetes 调度扩展维护需求、分配和 QAD，并执行排序、放置和回收决策；节点侧通过 MPS 支持并发执行，通过 DCGM 指标提供运行反馈。两个预测器分别为时间排序、抢占选择和共享准入提供依据。

在十六张 A100 的真实部署实验中，相比 Hard+Colocate，平均作业完成时间降低了 34%，保障租户 QoS 合规率达到 93%。这项工作的核心，是用当前保障兑现情况决定资源优先给谁，再用干扰预测和代价感知回收把这个决定落实到 GPU 上，让空闲容量能被利用，也让团队的保障需求恢复时有明确的处理路径。

Q: 如果只展开抢占，怎么用一分钟讲清楚？

我们的抢占有两个主要入口：一个是保障任务来了，正常放置和安全共享都安排不下，需要回收 Best-effort 占用的资源；另一个是共享后实际干扰持续超标，需要停止同卡上借用资源的 Best-effort 训练任务。

进入回收以后，先找能够满足新任务需求的候选资源，再比较候选任务的剩余运行时间、历史抢占代价，以及需要同时打断多少任务。快结束的任务和已经承担较高累计抢占开销的任务，会尽量保护。如果需要完整 GPU，就必须把该卡上需要退出的 Best-effort 任务一起考虑，不能只停一个就算释放了一张卡。

执行上是通过 Kubernetes 删除选中的 Pod，由节点终止训练进程。删除请求返回成功不等于 GPU 已经空出来，要等实际退出和资源释放，再给新任务分配。训练进度的恢复依赖任务自身的 checkpoint，Pod 删除不会自动保存进度。

Q: 删除 Pod 后，任务怎么恢复？MPS 会帮忙保存状态吗？

MPS 负责多个 GPU 进程并发执行，不负责保存训练进度。删除 Pod 会终止其中的进程，内存和显存里的状态不能因此自动保留。

后续重建或重新提交任务，需要由作业控制器或提交系统负责；恢复训练还需要训练程序支持 checkpoint，保存模型、优化器和训练步数等状态，并在启动时加载。没有这些支持，就可能需要重新训练。因此，介绍 DeepShare 时可以明确说它完成了代价感知的抢占决策和 Pod 层面的执行，不能把它描述成任意训练任务的透明暂停和原地继续。

Q: 抢占代价函数怎么推导？每一项为什么这样写？

论文使用下面的集合代价，分数越小越优先选择：

$$\Phi(J)=\sum_{j\in J}\frac{1+\alpha C_p(j)}{\hat T(j)}+\frac{\beta(|J|-1)}{\bar T(J)}$$

这里，J 是要回收的一张 GPU 上的全部驻留任务，|J| 是任务数量；T̂(j) 是任务 j 的预测剩余时间，T̄(J) 是这些任务的平均剩余时间；C_p(j) 是归一化后的累计抢占开销。默认 α=0.5、β=0.3，分别控制历史打断和多任务打断的惩罚强度。

第一步，保护快完成的任务。先写 1/T̂(j)。其他条件一样，任务越接近完成，倒数越大，抢占它就越不划算。这是一个调度偏好，不是说剩余时间长的任务一定丢失进度更少。

第二步，减少重复抢占。把分子改成 1+αC_p(j)。没有历史开销时也保留基础代价 1；累计开销增加以后，这个任务的分数会升高，下次就更不容易再次成为抢占对象。累计开销不等同于简单的抢占次数。

第三步，计算整张卡的代价。对卡上的任务求和。回收共享 GPU 时，停止一个任务并不代表整张卡释放，所以必须评价完整集合。

第四步，进一步惩罚一次打断多个任务。加入 β(|J|−1)/T̄(J)。只停一个任务时，这项为零；停多个任务时，这项增加；如果它们平均都快结束了，这项还会更大。前面的求和已经累计每个任务的代价，这一项额外表达了对多任务同时中断的惩罚。

最后，先检查可行性，再最小化代价。设 V(d) 是 GPU d 的全部驻留任务，候选集 D_j^P 只包含这些任务全部为 Best-effort、且清退后能满足新任务显存和节点 CPU/内存约束的 GPU：

$$d^*=\arg\min_{d\in\mathcal D_j^P}\Phi(V(d)),\qquad J^*=V(d^*)$$

例如统一用分钟、历史开销均为零：GPU A 上一个任务还剩 10 分钟，代价是 0.1；GPU B 上一个任务还剩 100 分钟，代价是 0.01；GPU C 上两个任务都还剩 100 分钟，代价是 (0.01+0.01+0.3/100=0.023)。如果三张卡释放后都满足需求，就选 B。

这个函数是根据上述目标构造的启发式排序代价，不是“会损失多少秒”的精确模型，也不提供全局最优完成时间的证明。论文将 C_p 定义为归一化累计抢占开销，未在该处进一步规定它的归一化计算式。执行时先预留选定设备，再发起 Pod 删除，释放后绑定；没有可行候选就继续排队。

Q: MPS 已经能共享 GPU，为什么还需要你们这个系统？

MPS 解决的是多个进程能在一张 GPU 上并发执行，但它不知道谁有配额保障，也不会替我们决定哪些任务适合一起跑。我们的工作是在它上面做调度：判断是否允许共享、安排哪个任务先运行、保障任务来了回收谁，以及共享干扰超标后停止哪个借用任务。MPS 提供执行能力，DeepShare 根据租户需求和运行表现作决定。

Q: 一次任务提交后，哪些组件实际参与了执行？

Controller 根据 TenantQuota 整理租户配额和机会型使用上限，任务 annotation 声明保障型或机会型类别。调度器先做租户级准入，累计本轮已放行的申请量，再按类别、平滑 QAD 和预测剩余时间确定任务顺序。

进入放置后，Filter 检查节点与设备约束，共享组合还必须满足双边性能门槛；Score 比较合格位置，Reserve 在最终预留时重新校验设备和额度，避免并发重复使用，之后完成绑定并由节点启动任务。预留之后失败，需要通过 Unreserve 清理尚未提交的预留。

保障任务没有可行位置时，先尝试缩减 BE 的 CPU、内存占用并重试，解除这些资源造成的阻塞；仍然缺少 GPU 才选择完整的 BE 受害集合。GPU 受害者选择放在 PostFilter 分支，清退前预留目标资源，等实际释放后再重新检查和放置，不能在 Filter 检查时直接删除 Pod。

Q: 预测不准，会不会整个调度器就不能用了？

运行时间预测影响任务顺序和抢占代价，但不会改变保障任务优先于借用任务、不能抢占保障任务这些规则。共享干扰预测则先决定是否允许合用，运行后还会用 DCGM 指标估计吞吐保持率；如果连续三个窗口低于阈值，就在下一调度周期停止同卡上的机会型任务。因此预测帮助我们作更好的选择，资源约束和运行反馈仍然持续起作用。

Q: 怎么证明提高利用率没有以拖慢用户任务为代价？

要同时看利用率、排队时间、作业完成时间和保障任务的 QoS。只看利用率不够，因为两个任务相互争用也可能让 GPU 一直忙。我们做了轨迹仿真和真实集群对比；真实集群实验中，相比 Hard+Colocate，平均作业完成时间下降 34%，保障租户 QoS 合规率达到 93%。进一步区分配额借用、预测排序和共享的贡献，要看分别关闭这些机制的消融结果。

Q: QAD 具体存在哪里，什么时候更新，怎么影响调度？

QAD 由调度器维护。按实现设计，用租户 ID 索引状态表，保存配额、有效保障需求、已分配保障量和上轮平滑值。需求包括等待和已分配的有效保障任务，不能只统计 Running Pod；机会型用量单独记账。

每个周期取一致的状态视图，计算已分配保障量除以配额与需求的较小值，没有需求时取 1，再做时间平滑。本周期的队列排序和共享判断使用同一份结果，不在每次节点打分时重新推进平滑值。

它有两个直接使用位置：候选队列先按平滑 QAD 排序，再比较预测剩余时间；共享准入读取双方 QAD，调整吞吐保持率门槛。抢占代价本身不额外加 QAD 权重，而是当前欠保障任务放不下时，触发 BE 回收。

Q: 两个预测器分别怎么做，结果在哪一步使用？

两个模型都是离线训练、在线预测。运行时间预测器采用 Gradient Boosting，按租户学习历史任务规律，新租户用全局模型兜底。输出预测剩余时间，用于 QAD 之后的任务排序，以及 GPU 受害集合的代价比较。

干扰预测器采用 Random Forest，通过独占与共置 profiling 建立训练数据，输入包括 SM activity、显存带宽等硬件特征，预测两个任务各自的吞吐保持率。先检查双方是否都达到共享门槛，再在合格组合中优先选择双方较小保持率更高的组合。

如果追问 Go 与 Python 如何对接，我们准备的工程方案是让 Python 预测服务作为调度 Pod 的常驻辅助容器，通过本机 gRPC 提供批量预测，调度器缓存特征并在同一轮复用结果。这个接口部署属于实现设计，论文没有记录实际通信协议，不能当作已核实的历史实现。预测调用失败时，设计上可保留类别和 QAD 优先级、以到达顺序兜底；干扰预测缺失则不新增共享组合。

Q: MPS、DCGM 和停止任务之间，执行过程怎么连接？

调度器选择合适的共享组合，节点侧 DaemonSet 管理 MPS 环境，让两个任务能够在同一张 GPU 上并发运行。MPS 不提供完整的计算和带宽隔离，所以仍需要干扰准入和运行反馈。

节点采集 DCGM 硬件指标，由在线保持率估计器判断共享后的性能表现。DCGM 计数器本身不等于任务的 samples/s。任意一方的估计保持率连续三个窗口低于门槛，就标记该组合退化，下一周期执行回收。对保障型与机会型的组合，停止机会型任务的 Pod，由 kubelet 和运行时终止进程，保障任务继续运行；训练恢复依赖用户任务的 checkpoint。

如果追问调度选中的 GPU 如何交给容器，工程方案需要配套的设备分配适配层，传递任务与 GPU 的分配计划，并由节点准备设备访问和 MPS 环境。不能认为写一个 GPU UUID annotation，标准 Device Plugin 就会自动完成定向共享；具体适配接口需要结合实现核对。

📄 论文原文：IEEE Cluster 2026 — DeepShare PDF

问题背景

多团队共享 GPU 集群的核心矛盾：

配额闲置：某个团队暂时没有训练任务时 GPU 空转浪费，实测集群平均利用率只有 40%。
配额不够：另一个团队赶 deadline 想多用几块卡，却因超配额被拒。

固定配额简单但浪费严重，完全共享利用率高但无法保障 SLA。问题本质：在保障每个租户配额的前提下，把闲置资源借给需要的人，原主需要时及时收回。

额外问题：即使 GPU 被分配出去了，很多训练任务在 I/O 或 CPU 预处理阶段 GPU 是空闲的。两个任务合用同一块 GPU 可以提升利用率，但会互相干扰——抢占 SM 和显存带宽，搞不好两个任务都变慢。

系统设计

统一控制信号——配额保障度 QAD，同时驱动三个子系统：

$$Q_i(t)=\frac{A_i^G(t)}{\min\!\left(q_i,\,D_i^G(t)\right)}\quad\left(D_i^G(t)>0\right)$$

部分	含义	记忆
分子 `A_i^G(t)`	已经分配给租户的 Guaranteed GPU	已经兑现多少
分母 `min(q_i,D_i^G(t))`	quota 与当前 Guaranteed demand 取小	此刻应该兑现多少
比值 `Q_i(t)`	当前保障兑现率	已给 / 该给

边界：没有 Guaranteed demand 时 Q_i(t)=1；Best-effort 借用不计入分子，所以 QAD 位于 [0,1]，不会因为借卡大于 1。完整数字例子见“QAD 记忆模型”。

子系统一：弹性配额借用（DRA）

空闲 GPU 可被其他租户借走跑低优先级任务。原主提交新任务导致 QAD 下降时，按 QAD 优先级回收——最欠缺的租户最先被满足。和固定配额的区别：闲置资源不浪费，但需要时保证能收回。

子系统二：预测性调度

Per-tenant gradient boosting regressor 预测作业剩余运行时间（MAPE 31.84%，R² = 0.7286）。调度排序采用词典序：

$$\big(\tilde{Q}_i(t)\uparrow,\; \hat{T}(j)\uparrow\big)$$

先按 QAD 升序（优先欠缺的租户），再按预测运行时间升序（短作业优先）。

抢占对象选择：对候选 GPU 上全部 Best-effort 任务计算集合代价，选择最小者。

$$\Phi(J)=\sum_{j\in J}\frac{1+\alpha C_p(j)}{\hat T(j)}+\frac{\beta(|J|-1)}{\bar T(J)}$$

剩余时间越短、累计抢占开销越高，代价越高；第二项额外惩罚同时中断多个任务。候选设备必须在清退全部驻留任务后满足新任务的资源约束。

子系统三：干扰感知 GPU 合用

Random Forest 预测两个任务共享同一块 GPU 时的性能保持率（R² = 0.902）。特征来自硬件计数器（SM activity、memory bandwidth），而非模型架构，保证跨框架泛化。只有预测保持率高于动态容忍阈值时才允许合用。运行时持续监控，实际性能下降超过容忍度时立即驱逐低优先级伙伴。

整个系统实现为 Kubernetes scheduler plugin，覆盖 Filter、Score、Reserve、PostFilter、Permit 五个扩展点（无可行节点时才进入 PostFilter 抢占分支），端到端调度延迟 < 50ms。

核心结果

70.58%

GPU 利用率 (基线 39.64%)

−46%

排队延迟

−34%

作业完成时间

93%

QoS 合规 (QAD≥0.95)

核心定位

DeepShare 的 Kubernetes 实现拆成轻量 Controller 与实时 Scheduler Plugin 两层：

Controller：把 TenantQuota CRD 和作业 class annotation 整理为租户 quota 元数据。
Scheduler Plugin：维护瞬时/平滑 QAD 和队列，执行排序、放置、colocation 准入与抢占。

面试Controller 管静态权益元数据，Scheduler Plugin 管实时 QAD 控制环。

论文不覆盖 Gang Scheduling，因此不引入 PodGroup / minAvailable；但 Permit 仍用于等待 CPU/Memory in-place resize 生效，不要把两种用途混在一起。

5-10 分钟中文论文讲解稿

这版适合面试时完整介绍，目标是让面试官听完后清楚知道：

这篇论文解决什么问题；
为什么这个问题重要；
DeepShare 的核心思想是什么；
QAD 是什么；
DRA、预测调度、colocation 分别做什么；
Kubernetes 实现大概怎么落地；
实验效果说明了什么。

你可以按这个版本背，也可以根据面试时间压缩。

开场：论文定位

我介绍的这篇论文是 DeepShare: Assurance-Driven Resource Management for Multi-Tenant GPU Clusters。它主要研究的是 多租户 GPU 集群中的资源管理问题。

简单来说，这篇论文想解决的问题是：

在多个团队共享一批 GPU 的情况下，如何既保证每个租户的 quota 和 QoS，又尽可能提高 GPU 利用率、降低作业排队时间。

1. 背景和问题

现在很多 AI 平台或者云平台都会有多租户 GPU 集群。比如不同团队、不同项目共用一批 GPU。为了公平，平台通常会给每个租户分配一个 quota，比如 A 团队 32 张 GPU，B 团队 16 张 GPU。

但是实际使用中会有一个矛盾。

如果我们严格按照 quota 静态隔离资源，那么就会出现资源浪费。比如 B 团队当前没有任务，它的 16 张 GPU quota 是空闲的，但 A 团队有很多任务在排队。如果系统不允许 A 使用 B 暂时空闲的 GPU，那么集群整体利用率就会下降。

反过来，如果系统允许 A 临时借用 B 的 GPU，又会出现另一个问题：当 B 后面提交了 Guaranteed 作业，需要拿回自己的 quota 时，资源可能已经被 A 的作业占住了。如果系统不能及时回收资源，就会破坏 B 的 QoS。

所以这里的核心矛盾是：

静态 quota 会降低利用率，过度共享又会破坏 QoS。

论文认为，现有系统的问题不只是某一个调度策略不好，而是 quota 管理、作业调度、抢占回收和 GPU 共享之间缺少一个统一的控制信号。

比如：

调度器可能只看作业优先级；
quota 模块只看租户有没有超过 quota；
抢占模块只看哪个作业优先级低；
colocation 模块只看 GPU 是否空闲或者干扰是否低。

这些模块如果各自决策，就很难同时保证 QoS 和利用率。

2. DeepShare 的核心思想

DeepShare 的核心思想是引入一个统一指标，叫 QAD，Quota Assurance Degree，也就是 配额保障程度。

它用来衡量：

一个租户当前 Guaranteed 资源需求中，有多少已经被满足。

也就是说，QAD 不是简单看一个租户用了多少 GPU，而是看它 应该被保障的资源有没有被保障到。

论文中 QAD 的作用是连接三个关键模块：

Elastic Quota Regulation，也就是弹性 quota 调节 / DRA；
Predictive Scheduling，也就是基于预测的调度；
Interference-Aware Colocation，也就是干扰感知的 GPU 共享。

这三个模块都围绕 QAD 来做决策。

可以简单理解为：

QAD 低，说明租户保障不足，系统应该优先恢复它的 Guaranteed 作业；QAD 高，说明租户保障充分，系统可以更积极地允许资源借用和 GPU 共享。

3. QAD 是什么？

QAD 的直观定义是：

QAD = 已经兑现的 Guaranteed GPU / 当前应该兑现的 Guaranteed GPU

更具体一点，瞬时 QAD 可以理解为：

如果租户当前没有 Guaranteed demand：
    QAD = 1

否则：
    QAD = 当前已分配的 Guaranteed GPU / min(租户 quota, 当前 Guaranteed demand)

这里分母用 min(quota, demand) 很关键。

举个例子，一个租户 quota 是 32 张 GPU。

如果它当前只需要 8 张 GPU，那么系统只需要保障它 8 张。只要它拿到 8 张，QAD 就是 1，而不是 8/32。

如果它当前提交了 100 张 GPU 的需求，但 quota 只有 32，那么系统只承诺保障 32 张，不会因为它提交了 100 张就认为系统欠它 100 张。

所以 QAD 避免了两个问题：

租户不能通过提交超大 demand 来放大资源缺口；
租户当前需求小于 quota 时，也不会因为没用满 quota 而被错误认为保障不足。

论文还对 QAD 做了平滑处理，因为瞬时 QAD 会因为短任务完成、突发任务到来、资源释放等事件频繁波动。

平滑公式是：

Q̃_i(t) = λ Q_i(t) + (1 - λ) Q̃_i(t - 1)

默认 λ = 0.3。

也就是说：

当前平滑 QAD = 30% 当前瞬时 QAD + 70% 上一轮平滑 QAD

这样系统不会因为短期波动频繁重排队列或者抢占 Best-effort 作业，但如果一个租户持续保障不足，平滑 QAD 仍然会逐步下降，从而提高它的恢复优先级。

不要混：Q_i(t) 是瞬时观测，真正进入排序和 colocation 控制的是 EMA 平滑后的 Q̃_i(t)。

4. 模块一：Elastic Quota Regulation / DRA

第一个模块是 DRA，弹性 quota 调节。

它解决的是：

怎么允许租户借用别人暂时不用的资源，同时保证这些资源之后能被回收。

DeepShare 把作业分成两类：

Guaranteed 作业
Best-effort 作业

Guaranteed 作业是 quota 内应该被保障的作业。它们会计入租户的 quota，并且在调度时优先级更高。

Best-effort 作业是机会型作业。它们可以使用集群中暂时空闲的 GPU，或者其他租户当前没有用到的 surplus capacity，但它们是可回收的。

这里的关键是：

Best-effort 可以借资源，但不能破坏 Guaranteed QoS。

当某个租户 Guaranteed 需求回来，导致它的 QAD 降低时，系统会优先回收 Best-effort 作业占用的资源。

所以 DRA 的核心逻辑是：

有空闲资源时，提高利用率；
Guaranteed 保障不足时，回收借出去的资源。

这就是 DeepShare 同时提升利用率和保证 QoS 的基础。

5. 模块二：Predictive Scheduling

第二个模块是 预测调度。

论文正文使用 per-tenant gradient boosting regressor 预测作业剩余运行时间。这个预测信息主要有两个用途。

第一个用途是 队列排序。

DeepShare 的排序不是简单 FIFO，也不是单纯短任务优先，而是：

Guaranteed 优先于 Best-effort；
同一类作业里，平滑 QAD 低的租户优先；
QAD 接近时，预测运行时间短的作业优先。

也就是：

先恢复保障不足的租户，再用短任务优先降低平均排队时间。

这点很重要。预测运行时间只是第二排序键，它不能覆盖 QAD。也就是说，一个已经保障充分的租户，不能仅仅因为它的作业更短，就排到一个保障不足的租户前面。

第二个用途是 抢占代价估计。

如果需要回收 Best-effort 资源，系统不应该随便杀任务，而要考虑：

这个任务已经运行了多久；
剩余运行时间大概多长；
是否有 checkpoint；
重启成本多高；
抢占它能不能真正释放足够 GPU；
抢占后能不能提升低 QAD 租户的保障程度。

所以这里是一个 cost-aware preemption，而不是简单 priority-based preemption。

6. 模块三：Interference-Aware Colocation

第三个模块是 干扰感知的 GPU colocation。

它解决的是：

很多 GPU 作业并不能一直打满一张 GPU，如果让它们完全独占 GPU，会造成利用率浪费；但如果随便共享，又可能互相干扰，破坏 QoS。

GPU 共享的干扰来源很多，比如：

显存容量；
显存带宽；
SM 算力；
L2 cache；
PCIe / NVLink；
CPU dataloader；
网络通信。

所以 DeepShare 不只是看 GPU 有没有空，而是预测两个作业放在一起会不会产生过大 slowdown。

论文中提到使用 random forest 模型预测 colocation 干扰。如果预测干扰低于阈值，才允许 colocation。

而且这个阈值不是固定的，会受到 QAD 影响。

如果某个租户 QAD 很低，说明它的 Guaranteed 资源已经保障不足，那系统会更保守，避免它的作业受到共享干扰。

如果租户 QAD 较高，说明保障比较充分，系统可以更激进地允许 colocation，提高 GPU 利用率。

所以 colocation admission 是：

干扰感知 + QAD 感知

而不是单纯基于利用率。

7. Kubernetes 实现怎么落地？

论文说 DeepShare 是 Kubernetes-native，也就是它不是重新造一个集群系统，而是集成到 Kubernetes 生态里。

论文实现拆成：

Controller + Scheduler Plugin

轻量 Controller 负责配置态：

reconcile TenantQuota CRD；
读取 Guaranteed / Best-effort class annotation；
生成 per-tenant quota metadata。

Scheduler Plugin 负责实时控制环：

在内存中维护瞬时/平滑 QAD 和两级队列排序；
Filter：检查节点 GPU 是否足够、是否允许 colocation；
Score：使用 RF 干扰预测和动态 retention 门槛选择位置；
Reserve：更新下一周期 GPU claim，避免 double booking；
PostFilter：当 Guaranteed 作业调度失败时，选择低代价 Best-effort 作业进行抢占。
Permit：等待 CPU/Memory in-place resize 反映到 Pod 状态。

这里有一个关键点：

Controller 管配置态，Scheduler Plugin 管 QAD 和所有实时放置决策；QAD 可从 informer cache 中的运行 Pod 重建，不需要每轮写回 CRD。

8. 实验结果

论文做了两类实验。

第一类是 trace-driven simulation，基于 23,859 个作业的 trace。

结果显示：

平均 GPU 利用率达到 70.58%；
比 Lucid 高 29.5%；
排队延迟降低 46%；
per-tenant QoS compliance 达到 93%。

第二类是在 16-GPU Kubernetes 集群上的部署实验。

结果显示：

Job Completion Time 降低 34%；
吞吐和资源利用都有明显提升；
说明系统不只是模拟有效，在 Kubernetes 原型上也有实际效果。

论文还做了 ablation study。

比如：

DRA 能降低排队延迟；
predictive scheduling 能进一步优化调度顺序；
interference-aware colocation 对降低排队延迟也有明显贡献；
DRA 和 colocation 结合后效果更好。

这说明 DeepShare 的收益不是来自单个技巧，而是来自：

QAD 统一控制下，资源借用、预测调度和干扰感知共享的协同。

9. 论文贡献总结

我理解这篇论文的核心贡献有三个。

第一，提出了 QAD 这个连续的租户保障指标。它不是简单 quota，也不是简单资源使用率，而是衡量租户当前 Guaranteed 需求被满足的程度。

第二，用 QAD 把多个原本分散的资源管理决策统一起来，包括 quota 借用和回收、队列排序、抢占、colocation admission 和 QoS reporting。

第三，做了一个 Kubernetes-native 的资源管理系统，把 DRA、预测调度和干扰感知 colocation 结合起来，在保证 tenant QoS 的同时提高 GPU 利用率。

DeepShare 的核心机制可以概括为：

DeepShare 不是单纯追求更高 GPU 利用率，也不是单纯做静态 quota 隔离，而是用 QAD 这个统一指标，在多租户 GPU 集群里动态平衡 QoS 保障和资源效率。

10. 面试时的收尾版本

我认为这篇论文最有价值的地方在于，它抓住了多租户 GPU 集群里的核心矛盾：资源空闲时希望共享，提高利用率；资源紧张时又必须恢复租户 quota 保障。DeepShare 用 QAD 把这个矛盾形式化，然后用 DRA 解决资源借用和回收，用预测调度降低排队和抢占成本，用干扰感知 colocation 提高共享效率，同时通过 Kubernetes Scheduler Framework 落地。

所以这篇论文的核心不是某一个单点调度算法，而是一个围绕租户资源保障的统一资源管理框架。

先把完整公式记对

$$ Q_i(t)= \begin{cases} 1, & D_i^G(t)=0,\\ \dfrac{A_i^G(t)}{\min\!\left(q_i, D_i^G(t)\right)}, & D_i^G(t)>0. \end{cases} $$

符号	含义	记忆问题
`i`	第 `i` 个租户	在看谁？
`q_i`	平台承诺给租户的 Guaranteed GPU quota	最多承诺多少？
`D_i^G(t)`	时刻 `t` 租户当前提出的 Guaranteed GPU 需求	现在想要多少？
`A_i^G(t)`	时刻 `t` 已经分配并运行的 Guaranteed GPU	现在实际兑现多少？
`min(q_i, D_i^G(t))`	平台此刻真正应该保障的 GPU 数	现在该兑现多少？

分子 A_i^G(t)：已经给到的 Guaranteed GPU；分母 min(q_i,D_i^G(t))：当前应该给到的 Guaranteed GPU；两者相除就是保障兑现率。

为什么分母一定是 `min(quota, demand)`

分母不是 quota，也不是 demand，而是“当前应保障量”

当 demand < quota：租户只申请了 4 张，即使 quota 是 8，平台此刻也只欠它 4 张；分母取 demand。
当 demand > quota：租户申请了 12 张，但平台只承诺 8 张；分母取 quota。
因此租户既不会因为暂时没用满 quota 被判定为“受损”，也不能靠提交超大需求压低 QAD、抬高恢复优先级。

记忆口令：想要多少 D、承诺多少 q，二者取小才是系统此刻“该给多少”。

用一个数字例子把边界钉死

假设租户 A 的 quota 为 q_A = 8 张 GPU：

场景	`D_A^G`	`A_A^G`	分母	QAD	含义
暂时没有 Guaranteed 作业	0	0	特殊分支	1	没有未兑现的保障，不算欠它
只需要 4 张，目前给了 2 张	4	2	`min(8,4)=4`	0.5	当前保障只兑现了一半
只需要 4 张，目前给满 4 张	4	4	`min(8,4)=4`	1	当前需求已完全保障
需要 12 张，目前给了 4 张	12	4	`min(8,12)=8`	0.5	承诺的 8 张只兑现了一半
Guaranteed 给满 8 张，另有 4 张 Best-effort	12	8	`min(8,12)=8`	1	借来的 4 张不进入分子，QAD 不是 1.5

最容易答错的边界

论文中的 A_i^G(t) 只统计 Guaranteed allocation；Best-effort allocation 不进入分子，因此不会把 QAD “冲高”。在 DeepShare 的定义和准入约束下，Q_i(t) ∈ [0,1]：1 表示应兑现的保障已经满足，低于 1 才表示存在 deficit。

瞬时 QAD 和调度用 QAD 不要混

一个看快照，一个做控制

$$\tilde{Q}_i(t)=\lambda Q_i(t)+(1-\lambda)\tilde{Q}_i(t-1),\qquad \lambda=0.3$$

量	回答的问题	用途
`Q_i(t)`	这一时刻保障兑现了多少？	瞬时观测值
`Q̃_i(t)`	这个租户是否持续处于保障不足？	队列排序、回收优先级、colocation 收紧

EMA 是为了过滤短作业完成和突发到达造成的亚秒级抖动。论文设置 50ms 调度周期和 λ=0.3，持续 deficit 大约 350ms 就能体现 90% 的稳态影响。

QAD 怎么驱动 DeepShare

统计 Guaranteed demand 与 allocation

得到瞬时 Q_i(t)

EMA 平滑

得到控制信号 Q̃_i(t)

租户恢复排序

Q̃ 低的租户先恢复，预测运行时间只做第二排序键

资源回收

Guaranteed 放置失败时，先回收可让渡资源，再做低代价 Best-effort 抢占

共享准入

任一租户 Q̃ 低时提高 retention 门槛，必要时停止新 colocation

Q: 面试官问“QAD 是什么”，怎么一口气讲清楚？

QAD 是租户级的配额保障兑现率。分子 A_i^G(t) 是当前已经分配的 Guaranteed GPU，分母 min(q_i,D_i^G(t)) 是平台此刻真正应该保障的 GPU 数：需求小于 quota 时只保障实际需求，需求超过 quota 时最多保障 quota。如果当前没有 Guaranteed demand，就把 QAD 定义为 1，因为没有未兑现的权益。Best-effort 借用不计入分子，所以 QAD 落在 0 到 1。系统再对瞬时 QAD 做 EMA 平滑，用平滑值优先恢复欠保障租户，并收紧它们的 GPU 共享。

Q: 为什么不能直接用 allocation / quota？

因为租户当前可能只需要 quota 的一小部分。若 quota 是 8、需求只有 4、实际已给 4，用 allocation/quota 会得到 0.5，错误地认为租户受损；DeepShare 用 min(quota, demand) 后得到 1，表示当前需求已完全兑现。

常见误区

错误记法	正确理解
QAD = 总 GPU 使用量 / quota	分子只算 Guaranteed allocation，不算 Best-effort
分母永远是 quota	分母是 `min(quota, 当前 Guaranteed demand)`
没有需求时 QAD = 0	没有未兑现保障，论文显式定义为 1
借到额外资源后 QAD > 1	借用量不进入分子，QAD 保持在 0 到 1
运行时间短的作业永远优先	先按平滑 QAD 恢复欠保障租户，再用预测时间优化局部顺序

总体架构

TenantQuota CRD + Job class annotation

描述 quota、Best-effort 上限和作业类别

Lightweight Quota Controller

reconcile 配置，生成 per-tenant quota metadata

Scheduler Plugin

维护 Q / Q̃、两级队列、colocation 准入和抢占

Informer Cache

从运行 Pod 重建 Guaranteed allocation 与 demand

MPS + DCGM DaemonSet

执行 GPU 共享、采样干扰并上报 degraded pair

Kubernetes API Server

Bind、Pod resize、Pod deletion 与故障幂等恢复

面试记忆：Controller 管“配置态”，Plugin 管“决策态”，DaemonSet 管“节点运行态”。

三类组件分别管什么

组件	核心状态	关键职责	不负责什么
Quota Controller	TenantQuota、作业 class annotation	reconcile 租户 quota 与 Best-effort cap 元数据	不做节点放置，不维护实时 QAD
Scheduler Plugin	队列、瞬时/平滑 QAD、节点视图、预测结果	排序、Filter、Score、Reserve、PostFilter、Permit	不负责 MPS 进程和 DCGM 采样
Node-local DaemonSet	MPS client、DCGM counters、degraded pair	GPU 共享、干扰监控、异常上下文清理	不决定租户优先级

QAD 在哪里维护

QAD 是 Scheduler Plugin 的内存状态

Scheduler Plugin 从 informer cache 里的运行 Pod 推导 A_i^G(t)、D_i^G(t) 和 quota 元数据，计算瞬时 Q_i(t)，再维护 EMA 平滑值 Q̃_i(t)。这样排序、colocation 和抢占看到的是同一份实时状态。

论文没有把每一轮 QAD 写进 TenantQuota.status。发生 leader failover 后，新 leader 可以从运行 Pod 重建瞬时 QAD，并用首轮值 warm-start EMA，避免额外持久化和热路径写放大。

Kubernetes 对象如何表达

TenantQuota CRD：保存权益配置，不保存实时控制环

apiVersion: deepshare.io/v1
kind: TenantQuota
metadata:
  name: team-a
spec:
  gpuQuota: 8
  bestEffortMultiplier: 2

gpuQuota 对应 q_i，即 Guaranteed GPU quota。
bestEffortMultiplier 对应 η，限制机会型作业的借用上限。
作业通过 deepshare.io/class: guaranteed|best-effort annotation 声明服务类别。

metadata:
  annotations:
    deepshare.io/class: guaranteed
spec:
  schedulerName: deepshare-scheduler
  containers:
  - name: train
    resources:
      limits:
        nvidia.com/gpu: 4

Scheduler Framework 五个扩展点

扩展点	DeepShare 中的作用
Filter	筛出有空闲 GPU，或满足 CPU、内存、显存、Best-effort cap 和共享条件的节点
Score	用 RF 干扰预测和双边 retention 门槛排序候选位置
Reserve	把 GPU claim 写入下一调度周期的集群视图，避免 double booking
PostFilter	没有可行 GPU 时运行代价感知的 Best-effort victim 选择
Permit	只有触发 CPU/Memory in-place resize 时等待 Pod 状态反映新资源量；不是用来做 Gang Scheduling

Q: 为什么 QAD 不放在 Controller 里周期性写 CRD？

QAD 是 50ms 调度周期内持续变化的热状态，排序、共享和抢占都要同步消费。若 Controller 计算后再写 CRD，既增加 API Server 写压力，也引入控制环延迟和一致性窗口。放在 Scheduler Plugin 内存里能直接复用 informer cache，并在 leader 切换后重建。

一次调度周期怎么走

读取租户 quota、作业 class 与运行 Pod

Controller 提供配置元数据，informer 提供实时状态

计算瞬时 QAD

A_i^G / min(q_i, D_i^G)，无 Guaranteed demand 时为 1

EMA 平滑

得到调度控制信号 Q̃_i

两级队列排序

Guaranteed 先于 Best-effort，Q̃ 低优先，预测剩余时间短次优先

尝试独占 GPU

无干扰，优先级最高

尝试安全 colocation

RF retention 预测与 QAD 动态门槛同时通过

回收 CPU / Memory

对 Best-effort Pod 发起 in-place resize

选择 GPU victims

PostFilter 比较候选设备完整任务集合的代价，预留最低代价设备并清退

两级队列不要记成两个 Controller

队列符号和职责

队列	含义	做什么
`Q_i^G` / `Q_i^B`	租户 `i` 的 Guaranteed / Best-effort 队列	按 quota 与 cap 做租户级 admission
`Q^G` / `Q^B`	集群级 Guaranteed / Best-effort 队列	按平滑 QAD 和预测剩余时间决定放置顺序

Guaranteed 作业只有在 U_i^G + R_j ≤ q_i 时进入集群 Guaranteed 队列。Best-effort 作业只有在没有剩余 Guaranteed 作业能通过独占或安全合用落点，并且 U_i^B + R_j ≤ ηq_i 时才进入候选集。

集群级排序采用词典序：先区分 Guaranteed / Best-effort，再按 (Q̃_i ↑, T̂(j) ↑) 排序。QAD 是第一键，所以运行时间预测误差不会让保障充分的租户跨过保障不足的租户。

QAD 在调度路径中的输入输出

输入：已兑现与应兑现

$$ Q_i(t)= \begin{cases} 1, & D_i^G(t)=0,\\ \dfrac{A_i^G(t)}{\min\!\left(q_i,D_i^G(t)\right)}, & D_i^G(t)>0. \end{cases} $$</div>

A_i^G(t)：当前已经分配的 Guaranteed GPU，Best-effort 不计入。
min(q_i,D_i^G(t))：当前应兑现的 Guaranteed GPU。
Q_i(t)：瞬时兑现率；Q̃_i(t)：EMA 平滑后的控制信号。

输出：同一个 Q̃ 驱动三类决策

恢复排序：Q̃ 越低，租户越欠保障，越先调度。
共享收紧：任一租户 Q̃ 低时，提高所需 throughput retention 门槛；极端时停止创建新 colocation。
QoS 报告：用连续的保障度观察长期 deficit，而不是只看“是否超 quota”的二值状态。

注意：QAD 不直接无条件触发删除 Pod。GPU 抢占由 Guaranteed 作业 placement failure 触发，PostFilter 再用代价模型选 Best-effort victims。

五个扩展点怎么串起来

Filter 之后存在分支：有可行节点时进入打分、预留与绑定路径；没有可行节点时才进入 PostFilter 尝试抢占。PostFilter 不在 Reserve 之后顺序执行。Permit 在这里用于等待 CPU / Memory resize 状态，不是等待 GPU 抢占释放的通用屏障。

路径	扩展点	关键动作
共同筛选	Filter	检查空闲/单 resident GPU、CPU/内存/显存 headroom 和 Best-effort cap
有可行节点	Score	比较 RF 预测 retention，优先低干扰候选
有可行节点	Reserve	在下一周期视图中预占 GPU，防止并发调度 double booking
无可行节点	PostFilter	无可行节点时执行 cost-aware victim selection
有可行节点	Permit	仅在 CPU/Memory resize 已发起时等待 Pod.Status.Resources 更新

故障恢复与热路径

Plugin 以多副本 Deployment 运行，通过 Lease 选主。
QAD 可从 informer cache 的运行 Pod 推导；新 leader 用首轮瞬时 QAD warm-start EMA。
抢占通过 Pod deletion 发起，由节点的 kubelet 和容器运行时执行终止。API 接受删除请求不等于资源释放；后续分配必须依据实际终止与资源状态。Pod 删除本身不提供训练 checkpoint 或透明恢复。
调度端到端延迟低于 50ms，其中特征提取、队列记账和受限候选打分合计低于 25ms。

Q: 面试官问“两级队列和 QAD 到底怎么连起来”，怎么回答？

每个租户先在自己的 Guaranteed / Best-effort 队列做 quota admission；通过后进入对应的集群级队列。集群级排序先保证 Guaranteed 优先，再用平滑 QAD 让欠保障租户先恢复，只有在保障程度相近时才用预测剩余时间做短作业优化。QAD 因此负责跨租户公平，runtime prediction 只负责局部效率。

DeepShare 高频问答

Q: QAD 和 DRF（Dominant Resource Fairness）的区别？

DRF 用 dominant share 在多资源之间追求 max-min fairness；QAD 则衡量单个租户当前 Guaranteed 权益的兑现率。QAD 的分子只算 Guaranteed allocation，Best-effort 借用单独记账，因此 QAD 位于 0 到 1，不用 QAD>1 表示超额资源。QAD 还能同时驱动租户恢复排序、colocation 准入和 QoS 报告，而 DRF 主要回答公平分配问题。

Q: 为什么 JCT 只改善 6.3% 但排队延迟改善 46%？

JCT = 排队时间 + 执行时间。执行时间由计算量决定，对所有调度策略相同。调度只能影响排队部分。当执行时间占 JCT 主要部分时，排队大幅改善只带来 JCT 小幅改善。这恰好说明调度的优化空间集中在排队环节。

Q: nvidia.com/gpu 不可修改，GPU 共享怎么实现？

K8s Extended Resource admit 后不能修改。GPU 共享通过 NVIDIA MPS 在驱动层做多路复用，设 per-client 内存限制。每块 GPU 部署一个 MPS control daemon（DaemonSet 方式）。CPU 和内存可通过 InPlacePodVerticalScaling 动态调整，但 GPU 分配必须在调度时确定。

Q: 干扰模型为什么选 Random Forest 而不用深度学习？

三个原因：(1) 推理延迟——RF 推理 < 1ms，满足实时调度预算；对比 GAN-based 方法需要 50-200ms。(2) 精度足够——R² = 0.902。(3) 硬件计数器特征跨框架泛化，不需要针对每种模型架构重新训练。

Q: 过载时怎么表现？

大约 8% 高峰时段过载：按 QAD 升序优先最欠缺租户；最坏 QAD = 0.72，过载消退后 3.2 个周期（约 160ms）恢复到 ≥ 0.95。Best-effort 排队延迟增加 2.1 倍，Guaranteed 仅增加 14%，体现服务分级。

实现细节高频问答

Q: QAD 存在哪里？调度路径如何读？

论文实现中，Scheduler Plugin 在内存里维护瞬时 Q_i(t) 和平滑 Q̃_i(t)。原始状态来自 informer cache 中的运行 Pod，因此故障切主后可以重建，并用首轮瞬时 QAD warm-start EMA，不需要把每轮 QAD 写回 CRD。Controller 只把 TenantQuota 和作业 class annotation 整理成 quota 元数据，不承担实时 QAD 控制环。

Q: Controller 和 Scheduler Plugin 到底怎么分工？

Controller 管配置态，Plugin 管决策态。Controller reconcile TenantQuota CRD 和 deepshare.io/class annotation，形成租户 quota、Best-effort cap 和作业类别元数据；Scheduler Plugin 维护实时队列与 QAD，完成排序、Filter、Score、Reserve、PostFilter 抢占和 Permit 等待 resize。这样实时信号和所有放置决策留在同一个调度控制环里。

Q: 为什么不全放 Controller？

Controller 是异步 reconcile 配置态的组件，不拥有单次 scheduling cycle 的节点快照、候选打分和 assumed state。DeepShare 的 QAD、队列排序、干扰准入和抢占必须和 Filter / Score / Reserve / PostFilter 处在同一个实时控制环里，所以由 Scheduler Plugin 完成；Controller 只提供 quota 与 class 元数据。

Q: Best-effort 是怎么借用和归还的？

Scheduler 仅在没有可放置的 Guaranteed 作业、且租户 Best-effort 用量满足 U_i^B + R_j ≤ η·q_i 时考虑 Best-effort。Guaranteed 作业放置失败后，PostFilter 才按低代价策略选择 Best-effort victims；所以 QAD 负责决定谁更急需恢复，真正触发 GPU 抢占的是 placement failure。本质：可借、单独记账、需要时可回收。

Q: 不考虑 Gang Scheduling 后流程能简化什么？

不需要讲 PodGroup、minAvailable、等待全部 worker 到齐或整组回滚。论文的五个扩展点是 Filter / Score / Reserve / PostFilter / Permit；其中 Permit 只在 CPU/Memory in-place resize 发起后等待 Pod 状态更新，不用于 Gang Scheduling。如果以后支持多 worker 训练，才需要给 Permit 增加 PodGroup 级等待语义。

论文原文延伸问答（基于 IEEE Cluster 2026 原稿）

下面这组问题对应面试官真正会按论文细节追问的角度：参数选取、消融、敏感性、对比 baseline、工程边界。回答全部出自论文正文与 §V 实验。

Q: 论文里 EMA 系数 λ=0.3、调度周期 50ms，物理意义是什么？

论文 §III-A 给的解析：在 50ms 调度周期下，持续偏差在大约 350ms 内累积到稳态值的 90%，几何收敛速率为 $(1-\lambda)$。这个区间能 过滤亚秒级抖动（短任务结束、突发请求），同时让真正的"持续 under-service"快速被发现。λ 再调大会被短任务完成的抖动带飞，调小则恢复信号迟滞。

Q: 当租户暂时没有 Guaranteed 需求时 QAD 怎么定？为什么不直接定 0？

论文 Eq.1 显式规定 $Q_i(t)=1$ 当 $D_i^G(t)=0$。这是为了 "暂时不用 quota ≠ 被亏待"：定 0 会让空闲租户被错误识别为最受损者并抢回资源；同时分母用 min(q_i, D_i^G(t)) 又防止租户通过虚报巨大 $D_i^G$ 压低 QAD、抬高恢复优先级。这两条共同实现"既不奖励虚假 demand，也不惩罚临时空闲"。

Q: 干扰预测为什么选 Random Forest？论文给的理由是什么？

这里问的是干扰预测器，不要和运行时间预测混在一起。论文 §III-C 的考虑包括：(1) sub-millisecond 推理，可以放在 Kubernetes scheduler 关键路径上；(2) RFE 选出的主特征是 SM Active (44.5%)、co-run SM Active (20.6%)、mem copy util (12.3%)，与干扰来源相符且可解释；(3) 输入是 DCGM 硬件计数器，跨 framework / model 更容易泛化。它预测共享吞吐保持率，$R^2=0.902$。31.84% MAPE 和 $R^2=0.7286$ 属于另一个 per-tenant gradient boosting 运行时间预测器，不能拿来证明 Random Forest 的准确率。

Q: 抢占代价为什么按一张卡上的完整任务集合计算？

共享卡上只停一个任务，不能保证整张卡可供新任务使用。因此论文 Eq.3–5 先筛选清退后资源足够、且驻留任务全部为 Best-effort 的设备，再计算其完整任务集合的代价：

$$\Phi(J)=\sum_{j\in J}\frac{1+\alpha C_p(j)}{\hat T(j)}+\frac{\beta(|J|-1)}{\bar T(J)}$$

T̂(j) 是预测剩余时间，C_p(j) 是归一化累计抢占开销，T̄(J) 是集合内的平均剩余时间。第一项保护快完成和累计打断开销高的任务；第二项惩罚同时打断多个任务。取 d*=argmin Φ(V(d))，先预留设备，再清退其全部任务，释放后绑定新任务。没有可行设备就继续排队。默认 α=0.5、β=0.3。这是候选设备代价排序，不是按单任务 GPU-时收益逐个累加的背包贪心。

Q: 共享时光靠 RF 准入会不会被打脸？运行时怎么兜底？

会，所以论文叠了一层在线检测：DCGM 周期采样实际 retention $\hat{\rho}=t_{shared}/t_{excl}$，连续 3 个采样窗口 $\hat\rho<\rho_{tol}$ 就把这一对标 degraded，下一周期把 Best-effort 伙伴抢占。固定窗口规则相比 CUSUM 等顺序检测的好处：检测延迟有界 + 每对只维护一组计数器，落到调度器里行为更可预测。一对 GPU 上发生干扰漂移时不会拖到 Guaranteed 任务才被发现。

Q: 动态容忍 $\rho_{tol}$ 里的压力 $P$ 和 $\gamma$ 是怎么调的？

论文公式：

$$P = \left(\frac{G_p}{G_f+\epsilon}\right)^{\gamma},\quad \rho_{tol} = \min\!\big(1,\;[\rho_{min} + P(1-\rho_{min})] \cdot \max(k-\tilde{Q}_i,\, k-\tilde{Q}_{ie})\big)$$

$\gamma=0.5$ 让压力亚线性增长，短促 demand burst 不会立刻把所有 colocation 一刀切关掉；最大值再被任一租户的"欠服务度" k - Q̃ 放大，欠服务越严重门槛越高。Sensitivity 显示 $\rho_{min}=0.7$ 是甜点：0.5 时 GPU 利用 71.2% 但平均放慢 18%，反而 JCT 倒挂；0.9 时干净但只剩 55.3% 利用率。

Q: 31.84% MAPE 是怎么得到的？冷启动用户怎么办？

Venus 23,859 jobs 上采用按租户训练的 gradient boosting regressor。总体 MAPE 为 31.84%，$R^2=0.7286$；历史提交 ≥50 的老租户 MAPE<25，新租户落到集群级 fallback 模型，MAPE<60。冷启动不会阻断调度，只是时间排序不那么准。Figure 4 在随机 2000 jobs 上对照 real vs prediction；即使长尾作业误差较大，也不会覆盖 QAD 主排序，因为 $\hat{T}(j)$ 只是 secondary key。

Q: nvidia.com/gpu 是 K8s Extended Resource，论文怎么绕开"准入后不可修改"？

论文 §IV-B 明确：GPU 数确实改不了，所以 DeepShare 不动 GPU 数；要释放资源时走两条路。
(1) CPU/Memory 走 Pod resize subresource：control plane 必须启用 InPlacePodVerticalScaling，VPA 推荐基础上额外保留 max(10%, 0.5 core) CPU 和 max(10%, 256 MB) memory headroom，避免压缩后 OOM。
(2) GPU 抢占走删 Pod / 重建：通过 PostFilter 选 victim 后由 API server 删除 Pod，新 Pod 重新进入 scheduler。这是为什么论文必须在 §IV 里强调依赖 K8s v1.35 的新 subresource。

Q: 集群过载（$\sum \min(q_i, D_i^G) > G_{tot}$）时 DeepShare 怎么降级？数据多少？

论文 §V-D 给出量化：Venus peak-hour 中约 8% 周期会进入过载。Algorithm 1 按 $\tilde{Q}_i(t)$ 升序排队，近似 max-min fair recovery。可观测后果：
· 单租户最差 $\tilde{Q}_i=0.72$；
· spike 之后 3.2 个 cycle (~160ms) 恢复到 $\tilde{Q}_i\ge 0.95$；
· Best-effort 排队延迟 2.1×，Guaranteed 仅 +14%——这就是"服务差异化"在论文里的实际兑现。

Q: Ablation 里"DRA 单独"和"DRA + colocation"分别贡献多少？

物理 16-GPU testbed（§V-E Figure 11）：
· DRA 单独 vs Hard：makespan −23%、JCT −18.5%、queue −36%；
· DRA + Colocate vs Hard+Colocate：makespan −32%、JCT −34%、queue −66%；
· DRA + Colocate vs DRA-only 再省 31% 排队（Figure 10），整体 throughput 1.48×。
仿真消融（Figure 7）：去掉 runtime prediction 排队 +18.4%，去掉 interference awareness 排队 +30.1%——结论是 colocation 的贡献 > runtime prediction，但两者必须由 QAD 兜住才不会反过来伤害 SLA。

Q: 为什么平均 JCT 只比 Lucid 好 6.3%，但论文还是把 JCT 当卖点？

论文 §V-C 直接解释了：JCT = queueing + execution，execution 部分各策略基本一样，所以平均 JCT 改善被稀释。真正能差异化的是排队侧——论文给出 queueing −46%（1067s vs 1976s）、P95/P99 tail JCT −23%、idle GPU time −71%（vs Lucid）/ −96.8%（vs FIFO）。面试时讲"为什么 JCT 看起来涨幅有限"是高频反向追问，要答：DeepShare 主战场是 排队公平性 + tail-latency，平均 JCT 不是核心指标。

Q: 论文承认哪些局限？（部署前你会注意什么）

§V-G 明文承认四条：
(1) 干扰预测器在 16 个 DL 模型族（CV/NLP/RL/recommender） 上训练，未见架构（如新型 MoE）可能要重训；硬件计数器为输入提供一定泛化。
(2) 物理 testbed 只有 16 GPU，结论稳妥外推到 部门级集群（数十至低三位数 GPU），更大规模需要重新评估。
(3) 异构加速器（如 H100、TPU、国产卡）需要重新 profiling 并重训 RF 干扰模型。
(4) 论文未覆盖 多 node 分布式训练 / Gang Scheduling 场景，generalize 到 LLM 大集群训练需要补 PodGroup + Permit 扩展点（可主动补充作为面试加分）。

Q: 跟 Lucid、Tiresias、Gavel、HiveD 这些 prior art 的本质差异点是什么？

论文 §VI Related Work 总结：
· Tiresias：MLFQ 排序但无 runtime knowledge；DeepShare 加了运行时间预测和 QAD。
· Lucid：最强非侵入式 sharing baseline，但干扰模型简单（DeepShare 干扰 $R^2=0.902$ 显著更准）+ 静态阈值（DeepShare 用 $\rho_{tol}$ 动态调）。
· Gavel：max-min fair throughput 但假设 GPU 独占，没法 colocate。
· HiveD：静态 cell 分区给保证，不弹性，恰好是 DRA 要解的问题。
· Optimus / ElasticFlow：在线 runtime prediction 但无 QAD，会让短任务覆盖租户公平性。
论文卖点是把 quota assurance + interference colocation + runtime prediction 三者用单一 $\tilde{Q}_i(t)$ 信号闭环，前述任何一篇都只解决其中一两块。

先记住这条七步主线

背景冲突 → 现有缺口 → QAD → 弹性借用 → 预测调度 → 干扰感知合用 → 实现与结果

正常语速讲 4～5 分钟；面试官打断后，再进入公式、预测器或 Kubernetes 实现细节。

两个预测模块先彻底分开

维度	运行时间预测	干扰预测
回答的问题	这个作业还要运行多久？	两个作业放在同一张 GPU 上会慢多少？
论文模型	Per-tenant gradient boosting regressor	Random Forest
输入	租户历史作业；新租户使用 cluster-wide fallback	DCGM 硬件遥测，如 SM activity、显存带宽、L2、PCIe、Tensor Core、功耗等
输出	预测剩余运行时间 T̂(j)	预测吞吐保持率 ρ̂ = t_shared / t_excl
调度用途	QAD 之后的第二排序键；估计抢占收益与代价	Filter / Score 阶段判断能否合用以及放到哪张 GPU
安全边界	预测不覆盖 QAD；错了主要影响效率，不改变租户保障顺序	动态阈值准入；运行时连续 3 个窗口异常就驱逐 Best-effort 伙伴
论文结果	MAPE 31.84%，R² = 0.7286	R² = 0.902，推理延迟为亚毫秒级

记忆口诀：运行时间预测解决时间顺序，干扰预测解决空间放置；前者是 Gradient Boosting，后者才是 Random Forest。

论文边界：原文给出了运行时间预测器的按租户训练方式、冷启动 fallback 和准确率，但没有展开它的具体特征向量。面试时不要自行补成“也使用 DCGM 特征”；DCGM 硬件计数器属于干扰预测器。

Q: 请挑一个你最熟悉的工作介绍一下。

1. 背景：固定配额和资源共享存在天然矛盾

我想介绍一下 DeepShare，这是我们面向多租户 GPU 集群设计的、以配额保障为核心的资源管理系统。

它的背景是，企业里的 GPU 集群通常由多个团队共享。平台会给每个租户一个 quota 来保证公平，例如 A 团队 32 张卡、B 团队 16 张卡。但是各团队的需求具有明显的突发性：B 当前没有任务时，如果它的 16 张卡仍被静态保留，A 的作业即使在排队也不能使用，集群利用率会很低；如果允许 A 借用，B 的 Guaranteed 作业回来时，又必须及时拿回自己的资源，否则 quota 只是纸面承诺。

GPU 内部还有第二层浪费。很多训练作业受数据加载、CPU 或通信阶段影响，并不会一直打满 SM 和显存带宽。把两个作业放在同一张 GPU 上可以提升利用率，但盲目合用会产生不可控干扰，反而拖慢 Guaranteed 作业。

因此核心矛盾是：既想通过跨租户借用和卡内合用提升利用率，又必须把租户的配额保障真正兑现出来。

2. 动机：现有方法分别优化局部，却没有统一保障语义

现有工作往往只解决其中一个局部问题：固定 quota 能保证隔离但浪费资源；短作业优先能降低平均等待，却可能让某些租户长期得不到保障；GPU sharing 能提高利用率，却不一定知道当前能否承受干扰。

所以我们的判断是，问题不只是缺少一个更复杂的调度算法，而是 quota 借用、队列排序、抢占回收和 GPU 合用之间，缺少一个统一的反馈信号。系统需要随时回答：哪个租户当前最欠保障？

3. 核心设计：用 QAD 表示配额兑现程度

DeepShare 引入 QAD，也就是 Quota Assurance Degree：

$$Q_i(t)=\frac{A_i^G(t)}{\min\!\left(q_i,D_i^G(t)\right)}$$

分子 A_i^G(t) 是已经分给租户 i 的 Guaranteed GPU 数量；分母 min(q_i, D_i^G(t)) 是系统此刻真正应该保障的 GPU 数量，也就是 quota 和当前 Guaranteed demand 中较小的一个。直观上就是：已经兑现多少 / 此刻应该兑现多少。

如果租户没有 Guaranteed demand，QAD 直接定义为 1，因为“暂时没用 quota”不等于“被系统亏待”。Best-effort 借来的卡不计入分子，所以 QAD 的范围是 0 到 1，不会因为借用资源大于 1。系统还用 EMA 平滑瞬时 QAD，避免短任务完成或突发请求造成频繁抖动。

4. QAD 统一驱动三个机制

第一，弹性配额借用 DRA。租户没有用满 quota 时，闲置 GPU 可以借给其他租户运行 Best-effort 作业；原租户的 Guaranteed demand 回来后，如果资源不足，系统就回收这些可借用资源。这样 quota 从静态分区变成了“可借但必须能还”的保障承诺。

第二，QAD-first 的预测调度。调度器先按平滑 QAD 升序选择租户，保障不足的租户先调度；只有在 QAD 相同或接近时，才使用预测剩余运行时间让短作业优先。抢占时也会结合可释放的资源、剩余时间和抢占代价选择 victim。因此，预测负责优化效率，QAD 负责守住公平性。

第三，QAD-aware 的干扰感知合用。系统预测两个作业共享 GPU 后的吞吐保持率，并结合当前资源压力和租户 QAD 动态调整准入阈值。租户越欠保障，系统对它受到的干扰越保守；保障充分时，才更积极地合用 GPU。

5. 两个预测模块分别怎么做

运行时间预测模块：我们观察到租户的提交具有重复性，78% 的用户会反复提交特征和时长相近的作业，因此论文正文采用 per-tenant gradient boosting regressor，利用每个租户自己的历史作业学习其工作负载规律，输出预测剩余运行时间 T̂(j)。历史不足的新租户使用 cluster-wide fallback model。它有两个用途：一是在 QAD 之后作为第二排序键，降低平均排队时间；二是在抢占时帮助判断一个 victim 还剩多久、现在打断是否划算。Venus 23,859 个作业上的 MAPE 是 31.84%，R² = 0.7286。历史提交不少于 50 次的租户 MAPE 小于 25%，冷启动 fallback 的 MAPE 小于 60%。原文没有进一步列出该模型的具体特征向量，所以面试时不要自行补成 DCGM 特征。

干扰预测模块：这里使用的是 Random Forest。输入不是模型名字，而是 DCGM 采集的硬件遥测，例如 SM activity、显存带宽、L2、PCIe、Tensor Core、DRAM throughput 和功耗等；输出是两个作业合用时的吞吐保持率 ρ̂。采用硬件计数器有两个好处：一是跨框架、跨模型更容易泛化；二是 Random Forest 可以在 scheduler 关键路径上实现亚毫秒级推理。论文中该模型的 R² = 0.902。

预测本身不是安全保证，所以 DeepShare 还做了运行时闭环。DCGM 会持续监控实际保持率；如果连续 3 个采样窗口低于容忍阈值，就把这对合用标为 degraded，并在下一调度周期驱逐 Best-effort 伙伴，优先保护 Guaranteed 作业。

6. 工程实现和实验结果

工程上，我们把系统实现成 Kubernetes 的轻量 Controller 加 Scheduler Plugin。Controller 负责 TenantQuota 和作业类别等静态元数据；Plugin 维护实时 QAD 和两级队列，并在 Filter、Score、Reserve、PostFilter、Permit 等扩展点完成合用准入、放置、资源预留和抢占。

在 Venus 23,859 个作业的 trace-driven 实验中，DeepShare 把 GPU 利用率从 39.64% 提高到 70.58%，相对 Lucid 提升 29.5%；平均排队时间相对 Lucid 降低 46%。消融实验中，移除运行时间预测后排队时间增加 18.4%，移除干扰感知后增加 30.1%。在 16-GPU 物理集群上，完整方案相对 Hard+Colocate 将 makespan 降低 32%、JCT 降低 34%、排队时间降低 66%，租户周期的 QoS 合规率达到 93%。

7. 收尾：这项工作的核心贡献

所以我认为 DeepShare 最关键的贡献，不是单独提出一个预测器或一个共享策略，而是把配额保障变成一个可观测、可反馈的 QAD 控制信号，再让弹性借用、时间调度和空间合用围绕同一个目标闭环。最终实现的是：资源空闲时敢于共享，租户保障不足时能够及时、可解释地收回来。

面试官打断时，用这四句保住主线

背景：固定 quota 保公平但浪费，动态共享提利用率但可能还不回来，也可能引入干扰。
核心：QAD = 已经兑现的 Guaranteed GPU / 此刻应该兑现的 Guaranteed GPU。
设计：QAD 同时控制资源借用与回收、队列排序与抢占、GPU 合用准入。
预测器：Gradient Boosting 预测剩余时间、优化先后顺序；Random Forest 预测共享干扰、优化放置位置。

Q: 为什么不把两个预测任务合并成一个模型？

因为它们的决策对象、数据和错误后果都不同。运行时间预测面向单个作业和租户历史，回答“还要多久”，主要影响队列顺序和抢占收益；干扰预测面向作业对和硬件遥测，回答“放在一起会慢多少”，直接决定共享准入。拆开后可以独立训练、独立回退，也能分别设置安全边界。

Q: 运行时间预测误差有 31.84%，会不会破坏公平性？

不会直接破坏租户公平性，因为调度是词典序：先比较平滑 QAD，再比较 T̂(j)。预测错误只会让同一保障层级内的短作业排序不够理想，不能让一个高 QAD 租户越过一个低 QAD 租户。也就是说，QAD 是安全主键，运行时间只是效率次键。

Q: 干扰预测错了怎么办？

预测只负责准入，运行时监控负责兜底。系统持续用 DCGM 观察实际吞吐保持率，连续 3 个窗口低于动态阈值就降级这对合用，并抢占 Best-effort 伙伴。这个“离线预测 + 在线纠偏”闭环，比只相信模型输出更适合生产调度系统。

Q: 你认为这项工作里最重要的设计判断是什么？

最重要的判断是把预测放在保障机制之下，而不是让预测结果直接定义公平性。QAD 负责表达租户权益是否兑现，两个预测器只在不越过这条边界的前提下优化时间和空间效率。这样即使模型存在冷启动、分布漂移或预测误差，系统仍然有可解释的保障顺序和在线回退路径。

容易说错的六个口径

不要这样说	正确说法
两个模块都是 Random Forest	运行时间是 per-tenant gradient boosting；干扰预测才是 Random Forest
短作业优先决定全局顺序	QAD 是第一排序键，预测运行时间是第二排序键
预测干扰低就一定安全	还要经过动态阈值，并由连续 3 个窗口的在线监控兜底
借得越多，QAD 可以大于 1	Best-effort 借用不进入 QAD 分子，QAD 位于 0 到 1
QAD 一下降就立即杀掉 Best-effort	先按保障顺序尝试放置；Guaranteed 无法放置时才进入抢占回收
Controller 实时计算和维护 QAD	Controller 管 quota 元数据；Scheduler Plugin 维护实时 QAD 控制环

内容模块

PE 2026 ElastiCo

GPU 作业的资源需求为什么不该是固定值

我介绍的这项工作是 ElastiCo，面向训练和离线推理共同运行的 GPU 集群。离线推理包括批量标注、模型评估等任务，它更关注整体吞吐和完成时间。我们观察到，传统调度通常把一个作业看成固定资源请求：需要几张卡、多少显存，然后寻找能放下的位置。但同一个作业换一种执行配置，资源需求和吞吐都可能变化。

例如训练开启激活重计算，可以少存一些中间结果，代价是反向传播时多做计算；减小 micro-batch 也能降低显存，但可能影响吞吐。推理则可以调整并发 batch、缓存策略和显存预算。如果调度器只接受用户提交时的一种配置，就可能认为作业放不下，而实际上稍微调整配置就能和其他作业共同运行。

但仅仅压缩资源也不够。每个任务都选择占用最少的配置，可能使大家都变慢；直接把能放下的任务堆在一起，又可能因为算力、带宽争用产生严重干扰。ElastiCo 因此联合决定每个作业采用什么配置、占多少资源、与谁合用，以及放在哪里。

先把一个作业变成多种可选配置

第一个模块是资源形态变换。它枚举框架已有的配置开关，例如训练的 micro-batch、激活重计算和混合精度，以及推理的 prefix caching、batch 上限和显存使用比例。对每种可行配置，在预热后采样测量资源占用和吞吐，形成一组资源与性能的候选档案。

这里的形态是多维的，既包括 GPU 显存和计算压力，也包括 CPU、主机内存。同一个训练作业可能有一个吞吐更高但占显存更多的配置，也有一个稍慢、但能腾出空间的配置。系统还保留最低性能要求，不能为了塞进更多作业就无限降低单个作业的吞吐。

用影子价格表达当前什么资源最紧张

有了这些候选，第二个模块用影子价格来选配置。可以把每种资源理解成有一个随供需变化的内部价格。每个作业比较配置的性能损失、占用资源的代价，以及切换配置和干扰的惩罚，选一个综合成本较低的方案。

比如集群显存总需求超过容量，就提高显存价格。此时，高显存配置变贵，一些作业就可能改选启用重计算的配置，用额外计算换取显存。反过来，如果计算资源更紧张，系统就不一定愿意继续增加重计算。这种价格不是给用户计费，而是让各作业在同一套资源稀缺信号下做选择。

每轮选择后，再按总需求与容量的差更新价格，逐步把需求推向可行范围。因为配置是离散的，后面还有放置和干扰约束，所以不能仅凭价格迭代就宣称得到了全局最优解。

把共置干扰反馈回配置选择

第三个模块预测合用后的 slowdown。论文使用一个轻量全连接网络，输入包含硬件利用特征、作业类型与配置，以及两个作业组合后的资源压力。训练数据来自先单独运行、再两两合用的测量，并分别预测两个参与者会慢多少。

假设容量检查允许一个训练作业和一个推理作业共用 GPU，但模型预测其中一个会严重下降，那么系统给这组配置增加干扰惩罚，再重新选择配置和放置，而不是把容量可行直接当成性能可行。合用也不局限于训练和推理这一种组合，还包括训练之间、推理之间；每个参与者都有自己的性能要求。

最后由统一调度循环把它们串起来：为排队作业留出容量，更新价格，选配置，做装箱放置，再检查干扰。必要时反馈惩罚并重复若干轮，之后执行配置切换、放置或迁移。切换本身有成本，重配置可能需要检查点恢复，不能假设所有变化都能毫秒级无损完成。

工程落地与结果

工程上它是 Kubernetes 原生中间件，通过 Pod 参数和框架已有接口下发配置与资源预算，复用框架自己的显存管理。它不是自行实现一个 VMM 显存分配器，也不是简单地不停修改 MPS 环境变量来调算力。

论文在 64 GPU 测试床及更大规模模拟中评估。与 Volcano 对比的实验报告平均 JCT 约为原来的 0.34 倍，吞吐为 2.02 倍，平均 SM 利用率从约 25% 提高到 46%。核心贡献是把作业配置弹性纳入调度：先找出有哪些资源和性能的交换方式，再结合全局稀缺程度与共置干扰选择，让原本固定的资源请求变成可协调的决策空间。

来源：ElastiCo 论文 §3–5，RST、ESP、IAC、PDS 与配置传播机制；JCT 使用基线倍数表达。

配置弹性与资源共享

ElastiCo 面向训练与离线推理混合集群，联合选择作业配置、资源预算与放置。离线推理的目标主要是总吞吐和完成时间，不应把在线服务的 TTFT 门槛直接作为这篇论文的核心目标。

同一作业的资源需求随配置变化。例如激活重计算用额外计算换显存，micro-batch 改变显存与吞吐，推理缓存和并发上限也改变资源需求。调度器必须比较这些选择，再检查合用干扰。原文：[ElastiCo PDF](../../../resources/papers/PE_Journal2026_ElastiCo.pdf)。

四个模块

模块	输入与动作	输出
RST：资源形态变换	枚举作业配置，在预热后测量资源与性能	每作业的一组资源向量、吞吐与最低性能要求
ESP：弹性影子定价	按性能损失、资源价格、切换和干扰惩罚选配置	多资源容量下的候选配置组合
IAC：干扰感知合用	预测每个共置参与者的 slowdown	准入判断及反馈给 ESP 的干扰惩罚
PDS：统一调度循环	队列容量预留、选配置、装箱、干扰检查、反馈迭代	配置切换、放置、迁移和新作业准入

RST 怎样改变资源形态

作业类型	配置开关	资源与性能权衡
训练	激活重计算	降低激活显存，增加重复计算
训练	micro-batch	改变激活规模和吞吐；不能只优化显存而忽略训练语义约束
训练	混合精度	改变精度、显存和执行效率，需满足作业允许的配置范围
离线推理	prefix caching	复用前缀计算，同时保留可复用状态
离线推理	batch 与序列长度上限	改变并发能力和 KV 容量要求
离线推理	显存使用比例	在本作业吞吐与共置余量之间取舍

资源向量包含 GPU SM、GPU 显存、CPU 和主机内存；性能档案记录单独运行的吞吐。配置缺失时，论文采用近邻插值提供临时估计，后续用真实测量替换。这里的“形态变换”指执行配置引起的资源—性能变化，不等于直接切分 SM 或自行映射 VMM 页面。

ESP 怎样选配置

每个作业比较配置的归一化吞吐损失、资源租金与惩罚：

\[ Score_j(c)=1-\frac{T_j(c)}{T_j(c_j^{max})}+\sum_r\lambda_r R_j(c)[r]+\Gamma_j(c) \]

其中价格反映集群中每类资源的稀缺程度，惩罚包括切换配置和过量干扰。选完配置后，再用总需求与容量之差更新价格：

\[ \lambda_r^{t+1}=\max(0,\lambda_r^t+\eta_t(U_r-C_r)) \]

显存需求超过容量时，提高显存价格，推动部分作业选择显存更小的配置；计算资源紧张时，计算密集的替代配置也会变贵。影子价格是内部优化信号，不是实际账单。离散配置与放置仍需要可行性检查，价格迭代不构成全局最优保证。

IAC 怎样预测与反馈

论文使用三层全连接网络，以 36 维特征预测有方向的 slowdown：单独吞吐除以合用吞吐。特征包括每作业硬件利用、作业与配置属性，以及作业对的显存压力和资源互补程度。一对作业产生两个预测，分别描述双方受到的影响。

合用对象覆盖训练—训练、训练—推理、推理—推理。每个参与者都有性能要求，不是固定“训练永远为主、推理永远被驱逐”。超过容忍阈值的组合会给对应配置增加惩罚，重新进入选配置和放置过程。阈值与吞吐约束仍须结合验证，不能把点预测理解成无条件性能保证。

PDS 与 Kubernetes 实现

预留排队作业容量

根据队列需求得到有效容量

ESP 选配置

更新影子价格并考虑切换惩罚

装箱放置

检查多资源容量

IAC 检查

预测双方 slowdown 并反馈违规惩罚

有界迭代

无违规或达到轮数上限后结束本轮搜索

运行时执行

应用可行的配置、放置和迁移，持续更新观测

论文默认调度周期为 5 秒，ESP–IAC 交互有轮数限制。性能合规与容量约束必须在执行前满足，达到搜索上限本身不是安全证明。

观测侧结合 CUDA 调用拦截与 DCGM 硬件指标形成 profiling 数据。预算通过 Pod 启动参数、框架原生配置及可用的 MPS 限制下发；系统复用框架显存分配器，不实现独立 VMM 管理器。对需要重启的配置变化，使用检查点或引擎排空恢复。共享持久存储提供状态访问路径，实际恢复耗时仍取决于 I/O 和状态大小。

实验结果

指标	论文报告值与口径
评估规模	64 GPU 测试床，另有最多 512 GPU 的 trace 驱动模拟
平均 JCT	相对 Volcano 约为 0.34 倍，对应约 2.94 倍加速
集群吞吐	相对 Volcano 为 2.02 倍
平均 SM 利用率	从约 25% 提高到 46%

这些是特定混合负载及基线下的结果。不能直接拿它与 DeepShare 的利用率比较，因为工作负载、保障目标和统计口径不同。

高频追问

Q: 为什么叫资源形态变换，而不是普通资源分配？

普通放置常把资源请求视为固定输入；RST 先用框架配置生成一组资源—性能档案，让调度器能改变作业本身的资源需求。例如重计算改变计算与显存的比例，再决定这个配置适合与谁共置。

Q: 影子价格与 DeepShare 的 QAD 有什么区别？

QAD 衡量租户保障兑现程度，主要约束跨租户服务顺序；影子价格按资源维度表达集群稀缺程度，影响作业配置的选择。前者是保障反馈，后者是多资源优化信号。

Q: 配置切换与 checkpoint 怎样处理？

论文优先考虑配置调整，并计入切换惩罚；需要重配置或迁移时使用框架检查点与恢复，推理可通过引擎排空后重启。训练也可能调整或迁移，不能声称所有变化都只作用于推理，或都有固定的 2–5 秒开销。

Q: 无需修改用户代码是怎么实现的？

论文通过 CUDA 库拦截和硬件计数器进行观测，用 Pod 参数、框架已有配置及恢复接口执行决策。非侵入不代表能任意改动正在运行的程序；具体框架仍需支持所选配置与状态恢复。

Q: MPS 调整需要多长时间，是否逐阶段改变 SM 比例？

不能把这套方法概括为通过修改环境变量实时改变现有进程的 SM 份额。论文的调度对象是配置及其预算，预算通过启动或重启参数下发；调度周期、重配置和迁移时间是不同口径，应分别测量。

依据：ElastiCo 原文 §3 的四模块设计、Algorithm 1，§4 的 profiling 与预算传播，§5 的实验。未核对的实现数值不作为确定事实。

内容模块

异构硬件多目标性能预测

Q: 请完整介绍一下你的异构硬件多目标性能预测项目。

我做的这个项目，是面向异构硬件的深度学习任务多目标性能预测。我们的目标是：给定一个训练或推理任务，以及它的运行配置和目标设备，在不提前试跑这个任务的情况下，预测它的执行时间、内存需求和设备利用情况，为后续的资源调度提供依据。

背景：调度前需要知道任务的性能和资源需求

在异构集群中，调度一个任务之前，我们通常需要知道几个问题：它需要多少显存，放在哪种设备上比较合适，大概需要运行多久。这些信息会直接影响任务能否被接纳，以及资源如何分配。

但是，这些指标很难仅凭模型名称或者参数量判断。同一个模型，batch size 和输入规模改变之后，资源需求就会变化；同一个任务放到不同硬件上，运行性能也可能不同。如果把所有模型、配置和设备的组合都实际运行一遍，评估成本很高，新任务提交时也很难及时获得这些信息。

所以，我们希望学习一个从“模型结构、运行配置和硬件条件”到“实际运行指标”的映射，让预测器能够处理更多没有逐一测量过的任务组合。

方法选择：用计算图保留影响性能的结构关系

首先遇到的挑战，是怎么表示一个任务，才能支持跨模型的预测。一种直接的方法是使用参数量、计算量等整体统计特征，但这些特征会丢失模型内部的结构信息。例如，计算量接近的两个模型，一个主要由较大的矩阵乘组成，另一个包含很多小算子和分支，它们的执行效率和中间数据存储需求也可能不同。

我们因此选择从计算图入手。节点对应算子，边对应算子之间的张量依赖，能够同时描述“执行什么计算”和“这些计算如何关联”。

选择 GNN，是希望预测器既学习单个算子的执行特征，也学习算子之间的结构关系。不同模型虽然整体架构不同，但往往包含相似的算子和局部结构，图模型可以在这些结构之间共享学到的表示，为跨模型预测提供基础。具体实现上，我们使用带边特征的图 Transformer。

数据集建设：自动生成任务，扩大结构和配置覆盖度

确定这个思路之后，项目中很大一部分工作是建设数据集。我们需要的数据比较特殊：每个样本不仅要有模型结构，还要有确定的运行配置、硬件信息，以及任务在目标设备上真实运行得到的多个指标。现成的数据难以直接满足这种完整的配对要求，所以我们自己搭建了任务生成和性能采集流程。

在任务生成方面，我们选择了 ResNet、BERT、ViT 等不同类型的基础模型，覆盖卷积网络和 Transformer 等结构。在这些模型上，进一步改变网络结构和运行配置。

例如，卷积网络可以改变通道规模，Transformer 可以调整层数、隐藏层维度和注意力头数；同时改变 batch size 和输入规模，生成计算量、数据规模和结构特征不同的任务。

这样做的目的是扩大数据覆盖范围。如果只采集几个固定模型，预测器容易依赖这些模型特有的模式；通过系统性地构造变体，我们希望它接触到更丰富的算子组合和资源需求，学习结构、配置与性能之间的关系。

运行时采集：把计算图与真实执行指标对应起来

生成任务之后，还要把它们变成可信的运行时样本。我们让这些任务在不同设备上实际执行，分别记录训练和推理阶段的运行表现。除了运行时间，还采集设备利用率、计算单元活跃情况、设备内存占用等指标，为多目标预测提供标签。

这部分工作涉及不同模型的运行适配、计算图导出、任务执行、监控数据采集，以及计算图与运行记录的对应。性能标签需要关联到具体的任务、设备和执行阶段，避免将任务之外的监控数据混入样本。

我们还对提取后的数据进行有效性检查，处理指标缺失、非数值记录和部分异常采集结果，最终将模型结构、配置、硬件和运行指标整理成统一的样本格式。

因此，数据工作包括模型变体生成、真实运行、指标采集、图数据构建和质量检查的完整流程。计算图、配置和硬件信息作为输入，实测运行指标作为监督标签，预测时不需要先采集待预测任务的运行指标。

特征工程：描述算子、依赖和整体执行条件

接下来，我们把输入分成节点、边和图级三个层次。节点特征描述单个算子的工作，包括算子类别、估算计算量、输入输出张量的形状和数据规模等。保留形状信息，是因为同样的计算量在不同形状下可能有不同的执行效率。

边特征描述算子之间的数据依赖。我们不仅记录哪些算子相连，也记录依赖张量的规模，让预测器区分不同依赖关系涉及的数据量。

图级特征描述任务的整体条件，包括 batch size、执行阶段、模型整体统计信息，以及设备的算力、显存容量和显存带宽等硬件特征。另外，我们根据张量依赖估计激活张量同时存活时的内存规模，为内存预测补充结构信息。

计算图之前使用过 ONNX，当前实现采用 PyTorch FX。两种来源都可以用于特征提取，最终转换为统一的节点、边和图级特征，再送入预测模型。

预测模型：共享图表示，分别预测多个目标

模型先对算子类型和数值特征进行编码，通过带边特征的图注意力层聚合依赖信息，得到计算图表示。随后，将这个表示与硬件、运行配置融合，通过多个独立回归头输出不同指标。

采用多个预测头，一方面是因为这些指标都与模型结构和配置有关，可以共享一部分表示；另一方面，不同指标的影响因素和数值范围不同，需要各自的输出映射。

从调度需求看，多目标也更实用。内存预测可以辅助判断任务能否放到某张卡上，时延预测可以辅助比较不同设备，资源利用情况则可以为后续资源分配提供参考。

异构泛化：结合任务需求和设备能力

计算图告诉预测器，任务需要执行哪些计算、处理多大规模的数据；硬件特征告诉预测器，目标设备具备怎样的计算和存储能力。模型学习两者组合之后的运行表现。

我们希望获得的泛化能力，包括在已有设备上预测新的模型和配置，以及向新硬件扩展的能力。这几种情况需要分别评价，尤其是完全没参与训练的硬件，需要用独立实验判断预测效果。

评价与价值：让预测为资源决策提供依据

评价时，我们既关心预测误差，也关心误差对资源决策的影响。例如，内存低估可能导致任务放置失败，而时延预测会影响设备选择和任务排序。因此，除了总体误差，还需要观察不同任务、设备和指标上的表现，判断哪些条件下可靠、哪些条件下需要补充数据。

整个项目中，我主要围绕数据集构建、图特征设计和多目标预测模型展开工作。最终希望利用任务结构和硬件信息，让调度系统面对新的任务组合时，减少逐一试跑的成本，提前获得资源需求和性能估计。

Q: 如果只有一分钟，怎么介绍这项工作？

我做过一个面向训练和推理任务的异构硬件多目标性能预测项目。它解决的是异构 GPU 集群里新任务选卡的问题：如果每种模型、batch 和 GPU 组合都先完整 profiling，成本很高；只看参数量或 FLOPs，又看不到算子结构和硬件差异。

我们自行构建模型变体和运行配置，在不同设备上执行并采集运行时指标，形成计算图与性能标签配对的数据。计算图之前使用 ONNX，当前采用 FX；节点表示算子，边表示张量依赖，再结合运行配置和硬件特征，用 Graph Transformer 和多个回归头预测时延、内存和设备利用情况。

预测结果可以离线形成资源画像，在线调度先检查显存是否可行，再比较完成时间和资源效率。平均误差之外，我还会关注分布外模型、显存低估尾部以及预测接入调度后是否真的改善作业完成时间。

Q: 为什么需要 Graph Transformer，FLOPs 不够吗？

FLOPs 是有价值的计算量基线，但相同 FLOPs 可能来自不同算子和张量形状，实际执行还受访存、临时工作区、算子依赖和硬件实现影响。计算图能保留这些结构信息，Graph Transformer 再聚合整个图的上下文，因此有机会区分规模相近但执行行为不同的任务。

这不意味着图模型天然优于公式。合理的实验应把参数量、FLOPs、解析估计和传统回归作为基线，同时比较误差、采样成本和最终调度收益。

Q: 多个目标为什么放在一个模型里？会不会互相干扰？

多个目标都由同一份计算图、执行配置和 GPU 条件产生，共享编码器可以复用共同的结构信息；不同输出头再学习时延、容量和利用指标各自的映射。这样还能减少维护多个完全独立模型的成本。

目标之间也可能冲突，例如某个损失量级较大时主导梯度，或者对时延有用的表示不一定最适合显存。需要统一量纲或设置损失权重，并通过单目标与多目标消融、各目标误差和梯度冲突检查判断。没有消融结果时，不能把“共享表示”直接说成准确率提升的原因。

Q: WAPE 低于 5% 能保证调度安全吗？

不能。WAPE 汇总的是整体绝对误差，数值较大的样本权重更高；它不等于每个样本都落在正负 5% 内。少量显存严重低估仍然可能造成 OOM，小的时延误差也可能在两个候选很接近时把排序颠倒。

因此容量指标要额外看低估分位数和覆盖率，调度准入保留安全余量；时延预测则要看排序正确性，以及接入调度后的等待时间和完成时间。运行后继续用真实观测校准，而不是只依赖离线平均指标。

Q: 没见过的模型、算子或 GPU 怎么处理？

新模型如果主要由已见算子重新组合，可以利用算子属性和图结构迁移；真正的新算子如果只有未知类别编码，信息就不足，需要加入计算量、读写量等可解释特征，或者对它做少量 profile。新 GPU 也要提供硬件特征，并用代表性任务校准。

工程上还应做分布外检测或至少设置适用范围。遇到明显超出训练分布的组合，回退到保守估计或 profiling，并限制预测驱动的激进放置。测试集则应按模型家族和 GPU 类型留出，避免随机拆分制造过于乐观的泛化结果。

Q: 这项工作和 SagePilot 的关系是什么？

这项工作聚焦深度学习训练和推理任务的多目标性能预测：输入是模型计算图、执行配置和硬件条件，输出是时延、显存和硬件活动等资源指标。SagePilot 的问题范围更大，它利用资源估计去安排 Agent 工作流中的模型准备、连续调用和跨工作流资源竞争。

两者共享“把模型结构转换成资源代价”的思路，但不能把多目标训练预测的七项指标和 WAPE，直接当成 SagePilot 完整系统的实验结果；也不能把 Agent DAG 当作 Graph Transformer 读取的模型算子图。

实现版本与实验口径

原训练预测项目材料记录七项指标及综合 WAPE 低于 5%；当前代码使用 FX 图，硬件规格表包含 V100/A100，配置支持九个预测目标。ONNX 和 FX 都可作为计算图来源；切换时需统一算子分类、形状及统计口径。不同版本的目标数量、硬件覆盖和实验结果应分别对应原始记录。

当前数据提取入口按样本随机划分，不能单独证明未见模型家族或未见硬件的泛化。缩放脚本的命令行入口读取目录内全部 .pt 文件；拟合时需限定训练集，避免把验证和测试数据用于统计量计算。

Q: 为什么要用预测器做异构设备选择？它究竟能带来什么收益？

我考虑用预测器，是因为调度器需要知道具体作业放到不同设备上，分别要跑多久、占多少资源。只知道哪张卡理论算力高，还不能判断这张卡分给哪个作业最划算。同样换到更强的卡，有的作业能快几倍，有的只快一点；这种差异和模型结构、算子、输入形状、batch，以及实际瓶颈有关。

最直接的办法当然是把每种组合都跑一遍。但模型和配置不断变化时，逐一 profiling 会占用设备，也会推迟作业启动。我们的预测器已经结合了计算图、运行配置和设备条件，可以用来估计候选组合的执行时间与资源需求，减少选择前的试跑。常见组合可以缓存结果，新组合再调用预测服务。

调度时，我会先排除资源放不下的方案，再根据目标比较剩余方案。如果希望作业尽早完成，就比较等待、准备和执行时间之和；如果希望在截止时间前控制成本，就在满足期限的方案中比较费用；多个作业争抢好卡时，就比较谁使用好卡获得的收益更大。预测器提供候选方案的代价，调度策略负责结合配额、公平性和当前资源状态作决定。

我还会主动检查预测有没有帮助调度器选对设备。整体误差低，不一定代表跨设备排序可靠；两个方案很接近时，一点误差就可能颠倒选择。所以我会比较所选方案和实测最佳方案的差距，并进一步看作业完成时间、集群吞吐和 GPU 小时成本。最终收益需要通过调度实验验证。

以下数字均为解释决策的假设算例。运行时间指固定工作量的执行时间；若模型输出的是单步时间，需要结合剩余步数等信息换算。多卡配置还需要对应的性能预测或测量，不能用单卡时间直接除以卡数。

Q: 多个作业同时争抢高性能 GPU，预测器怎么帮忙？

业务矛盾：先拿到好卡的作业，不一定最能从中受益

假设平台有两类 GPU，高性能卡数量有限。如果按照先来先得分配，一个对好卡不敏感的作业可能先把它占住，真正能获得大幅加速的作业只能用普通卡。我希望解决的是：这一批作业和这一批设备，怎么匹配更合理？

以下假设 A、B 都已就绪，各需要一张 GPU，两类设备容量都满足要求，且可以同时启动。

作业	普通卡执行时间	高性能卡执行时间	使用高性能卡节省
A	100 分钟	25 分钟	75 分钟
B	40 分钟	30 分钟	10 分钟

如果好卡给 B、普通卡给 A，最后一个作业到 100 分钟才结束；如果好卡给 A、普通卡给 B，40 分钟就都结束了。平均完成时间也从 65 分钟变成 32.5 分钟。预测帮助系统识别哪个作业更需要稀缺的好卡。

决策依据：生成“作业 × 设备类型”的代价表

我会为待调度作业批量预测各候选设备上的执行时间和资源需求，资源不满足的组合先排除。在一个小的调度窗口内，调度器比较不同匹配方案。以平均完成时间为目标时，可以用预计完成时间构造代价；有不同优先级时，再考虑相应权重。复杂队列里，单纯按节省时间排序不保证全局最优。

执行方式：作业级批量分配，再落实节点放置

调度器取得一批候选作业和可分配设备槽位，计算匹配方案，为选中的作业预留额度，再由控制器创建工作负载。我不会只给每个 Pod 打一个“越快分越高”的分数，因为每个作业都可能偏好同一种好卡；这里要比较的是，好卡给 A 和给 B，对整个队列分别有什么影响。

真实系统还要加入租户配额、优先级和等待时间补偿，避免加速收益小的作业一直拿不到资源。多卡作业要按整组资源分配，结合 gang scheduling；单卡匹配只是这个方案的简化起点。

收益验证：看有效工作完成量，不只看 GPU 忙不忙

这个方案提高的是高性能卡的使用价值，主要看吞吐和作业完成时间。两种方案下所有 GPU 都可能很忙，利用率未必明显变化，但同一段时间完成的有效工作可以更多。

Q: 好卡排队、普通卡空闲，应该等还是立即运行？

业务矛盾：热门设备排长队，其他设备还有空闲

假设训练平台有两类 GPU，用户通常倾向申请高性能卡，导致这类设备排队很长，普通卡还有空闲。但不同作业换卡后的加速收益不一样，有些作业没有必要一直等好卡。我希望在提交时就判断：等待高性能卡和立即使用普通卡，哪个更早完成？

决策依据：比较等待、准备和执行时间之和

作业提交后，控制器拿到模型计算图、batch、精度等配置，调用预测服务，估计各类 GPU 上的执行时间和资源需求；等待时间由队列和资源状态估计，准备时间单独计入。

候选方案	预计等待	准备时间	预测执行时间	从现在起预计完成
等待高性能卡	20 分钟	2 分钟	10 分钟	32 分钟后
立即使用普通卡	0 分钟	2 分钟	18 分钟	20 分钟后

只比较运行速度会选高性能卡，但用户关心什么时候拿到结果。普通卡虽然运行慢了 8 分钟，却省掉 20 分钟排队，最终提前 12 分钟完成。预测器让系统能够量化这个取舍。

执行方式：先在作业队列中选设备池，再创建 Pod

我会把选择放在作业队列这一层。作业尚未创建执行 Pod 时，先生成候选预测；队列调度器结合正在运行作业的剩余时间、排队规则和容量，比较预计完成时间。选好普通 GPU 池后，控制器创建带设备类型约束的 Pod，由 Kubernetes 完成具体节点放置。

落地时仍要检查实际空闲资源，如果资源已经被占用，就重新评估。等待时间也有误差，两个方案差距很小时不频繁切换；只有收益超过一定余量时才改变安排。作业启动后再换设备，还要考虑检查点和恢复成本，不能照搬提交时的选择规则。

收益验证：减少提交到完成的时间

主要观察作业完成时间和各设备池的使用情况，检查是否减少热门设备排队、让闲置设备承担适合它的工作。单次运行加速比不足以衡量这个场景的收益。

Q: 如果业务目标是按时完成，同时尽量省钱呢？

那我会先把截止时间作为约束，再比较成本。比如作业要在 60 分钟内完成，好卡跑 20 分钟，每小时 12 个计费单位；普通卡跑 40 分钟，每小时 4 个单位。假设立即运行、按实际时长计费，两边都满足期限，但好卡成本是 4，普通卡约为 2.67，就可以选普通卡。

如果期限缩短到 30 分钟，普通卡就不满足要求，需要选好卡。因此同一组预测，在不同业务目标下可以支持不同选择。实际决策还要计入排队、准备和预测误差余量。自有集群可以用 GPU 小时或设备机会成本代替云上价格。

Q: 为什么还要一起预测显存、CPU 和主机内存？

业务矛盾：用户靠经验选卡、配 batch，可能既贵又慢

用户为了避免失败，可能直接申请大显存卡，再配一个偏小的 batch。这样能运行，但可能占用了昂贵设备，也没有获得理想吞吐。我希望平台回答：在用户允许调整的范围内，哪组设备和执行配置满足容量要求，同时有更好的吞吐或成本？

决策依据：先检查容量，再比较合法配置的性能

平台生成有限的合法候选，例如固定模型和精度，比较设备类型和允许的 micro-batch。以下吞吐只演示各候选单步处理样本数与时间的关系。

候选配置	预测单步时间	预测显存需求	样本吞吐
普通卡，batch 32	100 ms	18 GB	320 样本/秒
普通卡，batch 64	160 ms	28 GB	400 样本/秒
大显存卡，batch 64	100 ms	28 GB	640 样本/秒

假设普通卡可用显存只有 24 GB，第二个方案就不能选。剩下两个方案中，追求吞吐可以选第三个；如果大显存卡单位时间价格高出很多，第一个可能更省钱。时延预测帮助比较性能，显存预测判断可行性，CPU 和主机内存预测补齐资源需求。主机内存若预测的是相对启动基线的增量，还要加上基线再评估容量。

执行方式：先推荐配置，再逐步开放自动选择

我会先做提交阶段的配置推荐，展示预计吞吐和资源需求，用户确认后运行；对于明确允许平台自动优化的作业，再自动选择。预测容量还需要根据误差校准保留余量。

如果调整训练 micro-batch，就要保持用户要求的全局 batch 等条件。例如通过梯度累积维持全局 batch 时，时间比较也要按完整的有效训练步计算。CPU 占用预测可以帮助识别过大的 requests，但降低 CPU limit 还需要验证性能影响，不能把实际占用直接当成安全限额。

收益验证：减少试错，提高合法配置下的吞吐或性价比

我会观察配置试跑次数、资源不足失败、吞吐和完成固定工作量的成本，在推荐模式下积累真实反馈后再逐步自动执行。吞吐提升不直接等于训练收敛更快，比较需要保持训练语义一致。

Q: 具体怎么接到调度系统里？

三个场景可以复用同一套集成方式，主要区别在决策目标。预测服务回答候选方案大概如何运行，作业级调度器选择方案，节点调度器落实放置。这是我会优先设计的集成方案。

用户提交作业
    ↓
控制器生成合法候选：设备类型、batch 等
    ↓
预测服务批量返回：执行时间、资源需求
    ↓
作业级调度器结合：队列、容量、配额、价格
    ↓
选择设备与配置，并进行资源预留
    ↓
控制器创建工作负载 → 节点调度器完成放置
    ↓
采集实际运行结果，检查预测偏差与决策收益

预测调用：排队期间准备，常见组合查缓存

我会把预测器封装成独立服务，计算图提取和候选预测尽量在作业排队期间完成。缓存键包括模型或计算图指纹、执行配置、设备类型、影响性能的软件环境以及预测模型版本，避免复用失效结果。同类设备复用预测，避免遍历每个节点时重复运行 GNN。预测超时或遇到陌生组合时，可以回退到历史测量、保守规则或少量 profiling。

资源交付：预测结果不能替代实际记账

作业级调度器选择设备池和配置后，由控制器通过设备类型约束和资源 requests 表达需求。落地前重新检查容量，并把作业层的预留与实际调度结果对账：创建或调度失败时释放相应预留、重新选择或排队，避免重复占用和遗留预留。多卡训练再结合 gang scheduling，保证整组启动条件。

运行反馈：区分模型偏差和决策偏差

运行后保存预测版本、选定配置、实际执行时间和资源使用。某类 GPU 上持续低估运行时间，可能需要校准模型；执行时间预测准确、最终却更晚完成，也可能是等待时间估计失准。分别检查这些环节，才能解释系统收益为什么出现或消失。

Q: 怎么证明预测器真的有调度收益，而不只是预测误差低？

我会先看跨设备排序，再看选错的代价，最后看整个系统。比如真实时间分别是 10 和 10.2 分钟，即使选反了，损失也很小；但真实是 10 和 30 分钟，选错就严重得多。因此只看选对比例也不够，还要看所选方案相对实测最佳方案，多花了多少时间或成本。

系统实验中，我会固定作业到达序列、设备规模、优先级和配额，比较三类方案：现有规则或历史查表策略、使用预测的策略，以及在相同决策框架中使用真实执行时间的理想参考。理想参考只用于离线评估，不把未来信息提供给实际策略。这样能区分策略本身的收益与预测误差造成的损失。

主要观察平均和尾部作业完成时间、吞吐、GPU 小时成本，以及资源不足失败和长作业等待情况，同时把特征提取与预测开销计入。还要按未见模型、配置和设备分别检验，避免总体平均误差掩盖某一类设备上的系统性偏差。

Q: 固定规则、历史查表不行吗？一定需要 GNN 吗？

如果模型和配置很固定，历史查表可能已经足够，命中缓存时就直接复用实测结果。预测器更适合新模型、新配置较多，完整试跑成本较高的场景。GNN 的价值需要通过与查表、简单特征回归等方法比较来证明，包括新组合的预测质量、决策收益和推理开销。

对于明显超出训练分布的新设备或新算子，我会先补代表性测量或校准。引入预测器的理由，是用可接受的成本获得可靠的决策依据。

内容模块

SagePilot

Q: 请介绍一下 SagePilot，包括工作背景、核心思路和执行过程。

SagePilot 面向私有部署中，多个大模型 Agent 工作流共享有限异构 GPU 的场景。例如代码修复需要依次分析问题、生成修改和运行测试，不同阶段可能调用不同模型。设备容量不足以让所有模型长期驻留，因此用户除了等待模型生成和工具执行，还会遇到模型加载和实例排队。

我们关注的是，这些等待中有一部分来自工作流信息没有被资源调度充分利用。后续阶段虽然还没拿到输入，但它需要哪个模型可能已经确定；如果等输入就绪才开始准备，就会增加串行等待。另外，在逐阶段申请资源的执行方式下，连续使用相同模型的调用也可能中间重新排队，甚至遇到实例被回收。

因此，我们希望利用工作流已经暴露的依赖和模型需求，重新组织资源申请与模型准备，减少这些阶段之间的等待。

具体来说，逻辑工作流描述各个调用及其数据依赖。我们先从中识别可以连续执行的兼容调用，以及能够合并的模型准备需求；调度器再结合预计执行代价、模型驻留和设备占用，把它们落实到具体实例和 GPU 上。这就是从逻辑工作流到物理执行安排的转换。

这里有两种复用。第一种是工作流内部的复用：例如 A 用 M1 生成初稿，B 继续用 M1 修改。两者满足一对一依赖、部署和执行配置兼容时，可以合成一个外层调度单元，申请一次资源后逐阶段执行，保持实例可用，减少中间重新排队。第二种是跨工作流的复用：多个工作流需要相同且兼容、允许共享的模型部署时，可以合并准备需求，让一次加载形成的实例服务多个工作流。各次调用的输入、上下文和结果仍然独立，底层引擎也仍然负责请求调度。

如果后继 C 要用 M2 检查结果，C 的生成必须等待 B 完成，但 M2 的加载可以在资源允许时提前进行。物理安排因此还包含“准备 M2”这个动作：它可以和 B 的执行重叠，并成为 C 开始执行前必须满足的条件。

预测为这些选择提供代价依据。我们根据模型、请求配置和 GPU 属性估计执行时间与显存需求，加载时间估计再结合加载记录校准；然后用工作流依赖和前驱进展推算后继的就绪时机。已确定的后续模型来自工作流本身，未知的输出长度和执行耗时需要估计，尚未确定的分支不会直接作为必然需求。

调度器再把这些复用机会落实到当前资源上，优先推进已经就绪的任务。已有实例能接纳就复用；排队较长时，比较继续等待与加载新副本后的预计完成时间，收益足够且资源允许才增加副本。选择 GPU 时先检查部署兼容性和容量，再结合设备显存与预测执行时间选择位置。

资源不足时，再决定回收谁；当前需求处理后，才考虑预加载。回收先排除正在使用和受保护的实例，优先考虑冗余副本，再比较下次使用时间与重新加载的代价。预加载只利用允许的剩余容量，避免为了后续任务反而阻塞当前请求。同一张逻辑工作流图，会根据模型驻留和设备占用情况，形成不同的物理执行安排。

工程上，资源预测、工作流分析和在线调度分别由 SageRadar、SageGraph、SageWeaver 承担。核心资源状态通过命令队列串行更新，加载和执行异步进行：发出加载命令前先登记设备占用，加载完成后再把实例标记为可用。新请求、工具返回和模型执行完成都会触发重新决策，真正开始生成仍然要求输入齐备、模型就绪和容量检查通过。

评估覆盖代码修复、数学求解和会议总结，关注整批会话完成时间、单个会话的 p95 延迟和 GPU 占用时间，并通过消融区分连续调用成组、预加载和跨工作流需求协调的作用。SagePilot 的核心，是利用工作流依赖，把独立的模型调用组织成能够复用资源的执行单元，合并跨工作流的模型准备需求，再结合异构 GPU 状态决定加载、放置和回收，减少整个任务的等待时间。

展开：三个模块如何接力，以及调度的一轮决策

同一个例子，三种不同的输出

假设 A 已结束，B 正在 GPU 0 的 M1 实例上运行，C 要用 M2。GPU 1 是可放下 M2 的空卡，M2 尚未加载。以下时间均为解释机制的假设值，不是实验数据。

模块	在这个例子里提供什么	交给调度器的信息
SageRadar	估计 B 还需 20 秒、M2 加载需 20 秒、C 生成需 10 秒，以及显存需求。	各动作的预计耗时与资源代价。
SageGraph	保留 B → C，增加“准备 M2 → C”；准备 M2 不依赖 B 的输出。兼容的其他工作流也可依赖这次准备。	可以选择的执行单元、准备动作和必须满足的依赖。
SageWeaver	检查 GPU 1 是否仍空闲、是否有 ready 工作需要它、预取是否到时，再决定是否发出加载。	具体命令，例如“现在在 GPU 1 加载 M2”；C 此时仍不开始。

预测给代价，图转换给候选和依赖，调度结合实时资源状态选择动作。这是职责划分；实现时可以交织构造和选择，不要求先枚举完所有物理图。

调度为什么不只是给请求排序

如果只把 C 排到队首，M2 还没有准备好，C 依然跑不了。调度器必须同时决定模型是否准备、在哪里准备，以及哪些实例继续保留。执行顺序只有结合这些资源动作才有意义。

看当前能推进谁：先按优先级和等待情况处理 ready 任务。C 的输入还没齐，此时只能参与模型准备，不能参与生成。
检查已有资源：模型已驻留且实例可接纳，就复用；否则考虑加载。模型驻留不等于实例有空余容量。
处理资源不足：寻找合适空卡，或回收合法的空闲实例；活跃租约保护下的 M1 不能卸载。没有合法动作就等待事件。
考虑后续需求：这轮没有 ready 准入或模型准备动作可推进时，检查 C 的预取时间、可用设备和资源约束，决定是否加载 M2。
登记并发出动作：加载前先登记设备占用，防止其他动作重复分配；完成事件返回后，再把实例标为可用。

提前准备具体省在哪里

如果等 B 完成才加载 M2，从现在到 C 完成需要：B 剩余 20 秒 + 加载 20 秒 + C 生成 10 秒，共 50 秒。若符合预取条件并立即加载，B 和模型加载可以重叠，两者都结束后 C 再生成，合计约 30 秒。省下的是关键路径上的模型等待，不是 C 的生成计算。

若加载实际用了 25 秒，C 就到第 25 秒才能开始；若 B 实际用了 30 秒，C 就到第 30 秒才能开始。预测时间到了，不代表数据或模型已经就绪。

同样的 C，资源状态不同，动作就不同

M2 已驻留：检查容量后复用，不必再次加载。
空卡可用且没有 ready 动作可推进：满足预取时机和容量条件时，可以提前加载 M2。
另一 ready 任务需要这张空卡：优先推进它，C 的预取推后。
只有 B 正在用的 M1 能腾出位置：不能回收，等待合法资源机会。
M2 已有实例但队列很长：比较等待与另开副本的预计完成时间，收益和资源条件都满足才扩容。

“联合优化”描述要一起考虑的决策范围；当前在线算法按上述优先顺序逐步作决定，不是穷举所有方案再找全局最优。此前核对的实现选卡仍采用可行性过滤和固定排序，不能把这个例子讲成每次都会选预计完成最早的 GPU。

展开：目标公式、约束、Algorithm 1 与决策算例

优化对象：当前可推进的任务与已确定的后继

输入状态：已就绪执行单元、紧邻且路径已确定的后继、模型副本与设备占用，以及 SageRadar 给出的运行时间、加载时间和显存估计。
决策变量：复用、加载、扩副本或回收哪些实例；执行单元绑定哪个副本和 GPU；哪些资源冲突动作必须先后执行。
规划范围：当前就绪单元与紧邻的 near-ready 后继。尚未解析的分支不作为确定需求，后续随真实事件更新。

目标函数：按优先顺序比较方案

$$\min_{G,\pi}\;\Phi(G,\pi)=(-A_1,\ldots,-A_K,\hat C_F,-P_N,H_{life})$$

这里采用字典序：前一项相同，才比较后一项。G 表示物理执行图，π 表示绑定和资源执行顺序。

尽量接纳就绪任务：Aₖ 是第 k 个优先级与等待时间类别中接纳的单元数，高优先级类别先比较。
缩短当前任务的完成时间：Ĉ_F 是本轮已接纳就绪单元中最晚的预计完成时间。
增加及时预取：P_N 表示能及时完成的后续模型预取数量。
减少模型管理代价：H_life 计入面向就绪工作的加载延迟和回收引起的重加载代价。

因此，论文中的时间目标针对当前规划窗口，通过滚动决策改善端到端表现；它不是直接精确求解整批工作流的全局最短完成时间。

代价模型：把依赖等待和资源等待放在同一条时间线上

$$\hat s_u=\max\left(\hat r_u,\max_{v\in pred_G(u)}\hat c_v,\max_{v\in rpred_\pi(u)}\hat c_v\right),\qquad \hat c_u=\hat s_u+\hat T_{u,a(u)}$$

数据就绪：r̂_u 表示任务何时具备输入。
图上依赖：pred_G 包括原有依赖和新增的模型准备依赖。
资源冲突：rpred_π 表示占用同一资源、必须先完成的操作。

例如输入在第 100 秒就绪，模型在第 90 秒加载完成，但不可并发的同卡操作到第 120 秒才结束，那么任务最早第 120 秒开始；运行需要 20 秒，就在第 140 秒完成。只比较模型运行时间，会漏掉前面的等待。数字均为说明机制的算例。

可行性约束：不仅检查模型权重是否放得下

语义与依赖：输入输出依赖保留，数据和模型都实际就绪才能生成；加入资源顺序后不能出现环。
部署与准入：满足设备兼容性、上下文长度和副本并发上限；共享准备动作必须符合所有消费者的设备条件。
显存：论文在每个预计状态变化时刻检查“驻留及过渡态模型显存 + 活跃请求增量显存 ≤ 设备容量”，共享权重不按请求重复计算。
回收：排除正在使用和受保护的实例，不能为了新任务直接卸载正在执行的模型。

Algorithm 1：按事件逐步构造可行方案

RankReady：按优先级和 aging 排列就绪单元，等待较久的任务提高优先级。
BestFeasibleBinding：过滤不可行设备，每个单元至多返回一个绑定；已有实例可接纳时形成准入动作。
PlanReady：对其余就绪任务安排加载、扩副本或安全回收，逐步更新方案。
PlanPrefetch：仅当本轮没有产生推进就绪任务的准入或模型准备动作时，才考虑 near-ready 模型预取。
Propagate 与 Prefix：传播预计完成时间、安排资源冲突并检查容量，只提交当前可执行的动作；新请求、加载完成和任务完成事件触发下一轮。

实现中的具体选择：加载谁、是否扩容、回收谁

决策	实际使用的判断	说明算例
先加载谁	按同一部署的（ready 数 + near-ready 数）÷ 预计加载时间排序；等待过久的请求优先处理。	M1：6 ÷ 30 = 0.20；M2：2 ÷ 40 = 0.05。其他条件相同时优先 M1。这是加载优先级，不是生成吞吐。
是否扩副本	比较原实例预计完成时间与“当前时间 + 新实例加载 + 执行”的差，检查收益门槛、副本上限和可行设备。	原队列还需 70 秒，新实例需 30 + 20 = 50 秒，预计收益 20 秒；不能因此跳过资源检查。
回收谁	合法候选中先考虑冗余副本，再比较“距下次使用的时间 − 重加载时间”；缺少可计算信息时回退到冗余优先与 LRU。	100 − 20 = 80 秒，比 30 − 25 = 5 秒留下更多重新准备的余量，其他条件相同时更适合回收。

跨工作流的作用就在这些决策里：W1 和 W2 如果需要相同部署，需求可以共同进入加载排序；复用一个实例节省加载，但排队变长时又需要评估扩副本。模型准备、请求等待和设备占用因此被放在同一个决策过程中。

论文建模与当前实现的区别

上面的优化目标和累计资源约束来自论文 §3.5、公式 (7)–(12)；Algorithm 1 是遵循目标优先顺序的在线启发式，不是求解所有图与排程组合的精确优化器。

已核对的实现主要采用单卡单副本与副本内 batch 显存准入。选卡先做可行性过滤，再按设备总显存较小、预测运行时间较短、设备 ID 排序；扩副本路径才显式比较新旧方案的预计完成时间。因此不能声称每次选卡都最小化总完成时间，也不能把论文一般形式的时间线显存规划说成已经完整实现。

Q: 和普通的模型缓存、换入换出有什么区别？

普通缓存主要根据已经到来的请求决定保留谁、换入谁。我们额外利用工作流依赖：前一步还在运行时，就能看到后续可能需要什么模型，从而评估能不能提前准备；连续兼容的调用可以一次安排，减少阶段间重新调度。落到动作上仍然是加载、调用和回收模型，区别在于决定这些动作时，多了后续需求、就绪时间和整个工作流完成时间这些依据。

Q: 从一个会话到达开始，系统到底怎么跑？

假设 A 调用模型 M1，接着 B 调用工具，再由 C 调用 M2。会话到达后，运行时知道这三个步骤的依赖，A 可以开始，B 和 C 要等待。调度器查 A 的执行代价，检查 M1 是否已有可用实例，决定复用还是加载；实例就绪后 A 开始生成。

A 完成后，运行时把结果交给 B，B 执行工具调用。此时 GPU 不需要继续替这个工具计算，调度器可服务其他请求；结合后续 C 的需求和工具完成时间估计，也可以判断是否提前加载 M2。工具结果真正返回后，C 才能成为可执行任务，拿到 M2 实例并开始生成。C 完成后会话结束，实例上的任务记录更新；没有任务使用的模型可以保留给其他会话，或者在显存紧张时回收。

这里 A 和 C 使用不同模型，中间还有工具调用，因此不作为同模型连续链融合。每一步由真实完成事件推进，预测只辅助提前准备。

Q: 提前加载为什么可能让 p95 更差？你会怎么处理？

比如预测后续很快会用到 M2，提前加载却挤掉了当前请求马上要用的 M1，M1 就要重新加载，等待时间反而增加。还有一种情况是分支最终没走到 M2，这次加载既占了显存，又消耗了加载带宽。

设计上我会先满足已就绪请求，再把预加载限制在可用容量和并发加载预算内；对预测收益接近成本的候选更保守，并持续比较预加载命中率、重加载次数和 p95。如果误差变大，就降低预加载的积极程度。这里的关键是把提前准备当作有成本的优化，具体限额和回退策略还需要结合实现与实验验证。

Q: 两个请求同时申请显存，如何防止超额分配？

当前调度器通过命令队列串行处理核心状态更新。检查容量、登记资源占用和记录实例正在加载，属于同一段受控的状态更新；真正加载可以异步执行，但预留必须先完成。因此后来的请求看到的已经是扣除预留后的容量，不能重复使用它。加载完成后再更新可用状态，失败路径则要撤销对应预留，不能只依赖实时查询显存来避免竞争。

Q: 为什么不只报预测准确率？

因为我们最终优化的是会话完成时间。预测更准，如果没有改变放置或加载决定，未必产生收益；平均误差较小，也可能有少数显存低估导致 OOM。所以我会同时看预测误差、显存低估、加载等待、重加载次数、平均完成时间和 p95，再通过分别关闭融合、预加载等机制，判断收益来自哪里。

Q: SageGraph 连续执行，是不是意味着这条链独占 GPU、不再排队？

连续链只向资源调度器申请一次，中间不再重复准入，并保持实例可用。它不等于独占 GPU，也不消除推理引擎内部的调度；同一实例可以在容量允许时接收其他请求。收益是减少阶段间重新争取资源的开销，代价是这组调用在更长时间内保持资源使用，因此还要观察其他请求的等待和整链显存预算。

Q: 当前实现是不是始终选择预计完成最早的 GPU？

当前选卡先检查上下文、预测桶和显存可行性，再按总显存较小、预测运行时间较短的顺序选择候选。扩副本会比较现有队列和新副本的预计完成时间，但这不等于所有选卡动作都在全局最小化完成时间。A100 与 V100 的时间算例可以用来解释加载与计算重叠的价值，不能当作当前选卡函数必然执行的规则。

Q: LangGraph 调用常驻 vLLM，本来就能复用模型，你们增加了什么？

常见的 LangGraph 加常驻 vLLM 部署里，A 请求结束不会自动卸载模型，B 可以继续调用同一个服务。因此不能把“不重复加载模型”本身作为我们相对常驻服务的贡献。

我们面向多个模型竞争有限 GPU、实例需要动态准备和回收的环境。工作流提供的不只是当前请求，还包括连续兼容的调用和已确定的后续模型需求。系统利用这些信息，把调用成组、模型准备、跨工作流复用和设备分配组织成实际执行方案。收益需要通过阶段等待、重加载次数和端到端延迟验证；如果模型始终驻留、资源又充足，成组执行的收益可能很小。

这里“一次安排”指的是 SagePilot 外层对实例的安排。底层仍逐阶段调用模型，也仍然存在引擎内部的调度。LangGraph 运行机制；vLLM 请求与缓存管理。

Q: 物理方案一定能按预测时间执行吗？

不能。比如 B 实际比预计慢，M2 可能提前准备好，却仍需等 B 的真实输出；如果模型加载更慢，C 就还要等加载。系统只执行当前满足条件的动作，在完成事件到来后调整尚未发出的安排。预测误差会影响准备时机和收益，但不能放宽数据依赖或资源容量约束。

论文描述了更一般的时间线资源约束；此前核对的实现主要采用单卡单副本和副本内 batch 容量检查。不能把这直接描述成已经实现了任意多模型同卡共置，或任意未来时间线的全局最优规划。

Q: 什么时候增加副本，什么时候回收已有模型？

扩副本时，比较继续在已有实例等待的预计完成时间，与加载新实例再执行的预计完成时间。假设前者还需 70 秒，后者加载 30 秒、执行 20 秒，预计能节省 20 秒；只有收益超过配置门槛、设备和副本上限允许，而且不会占掉其他需求最后一个可行位置，才考虑扩容。

回收先排除正在使用和受保护的实例，再优先考虑冗余副本，以及下一次使用较远、重新加载代价较小的实例。假设一个模型 100 秒后才需要、加载需 20 秒，另一个 30 秒后需要、加载需 25 秒，其他条件相同更倾向回收前者。数字用于解释判断，实际动作仍需经过回收条件检查并确认卸载完成。

Q: 两个动机实验的数字分别说明什么？

图 1 的 77.3%～85.5%，分母是请求等待时间，统计等模型加载和模型加载尚不能开始的时间，不是全部端到端延迟。28.1%～33.0% 的分母是总 GPU 时间，描述模型空闲驻留。图中可以提前开始的加载占总 GPU 时间的 10.5%～11.5%，表示优化机会，不能直接当作端到端加速比。

图 2 使用 QMSum 的两条并行 Qwen3-4B 三节点链及后续三个 Qwen3-8B 聚合节点，九次调用中六次有同模型后继；并发的四模型 MBPP 修复工作流制造资源竞争。设备是一张 A100-40GB 和两张 V100-32GB，重复三次，每个基线共 30 个 QMSum 会话。

阶段间重新等待在中位会话里为 2.7～3.8 秒，占 2%～3%；在 p95 对应会话中为 97.1～155.1 秒，占 39%～42%。这些数值来自固定执行轨迹的时间拆分；改变执行单元后，资源竞争也会变化，净收益需要通过消融实验测量。依据：论文初稿 §2.2–2.3、图 1–2。

Q: 调度优化的变量、目标和约束具体是什么？

变量包括物理方案中采用哪些模型准备动作、执行单元绑定哪个副本和设备，以及资源冲突操作的先后顺序。论文公式 (12) 使用字典序目标：Φ = (−A₁, …, −Aₖ, Ĉ_F, −P_N, H_life)，按这个顺序最小化。

Aₖ 是对应优先级与等待时间类别中接纳的已就绪单元数，负号表示越多越好；Ĉ_F 是当前窗口中已接纳就绪单元的最晚预计完成时间，越小越好；P_N 是及时完成的预取数量，越多越好；H_life 则计入面向就绪工作的加载延迟和回收造成的重加载代价。字典序意味着前面的目标相同时才比较后面的目标，不是把所有指标任意加权求和。

硬约束包括依赖和资源顺序无环、上下文长度、部署与设备兼容性、模型可用性、显存容量以及副本并发上限。每个预计状态变化时刻都要考虑驻留与过渡态模型显存，加上活跃请求的增量显存；共享模型权重不能按请求重复计算。共享准备动作还要满足所有消费者共同的设备条件。

需要区分研究目标、窗口目标和求解方法：研究上希望降低端到端完成时间；公式里的完成时间项针对当前已接纳的就绪单元；Algorithm 1 用启发式逐步构造可行方案，并非精确求解全局最优排程。依据：论文初稿 §3.5、公式 (7)–(12)、Algorithm 1。

Q: 初稿报告了哪些端到端结果，比较口径是什么？

按当前论文初稿的报告值，在突发到达设置下，相比两条参照策略，makespan 降低约 36%，整体 p95 降低约 25%。这组比较在相同 serving 底座上采用参照系统的请求排序规则。关闭链融合后，初稿报告不同到达设置下 p95 增加约 8.5%～44.9%；把生命周期需求限制为按单工作流统计，也会增加整批完成时间。这些结果分别对应减少阶段间重新等待、以及协调跨工作流模型需求的作用。

这组数字目前按初稿报告口径介绍，实验规模和资源表来源仍需要与原始运行记录统一。评估时还需要注意：整批任务更早结束，不代表所有负载下每个会话的尾延迟都最低，因此我们会同时比较完成效率、尾延迟和资源成本。

现有实验核对记录还指出，一份运行配置读取既有 predictions.yaml，尚不能据此把端到端改善归因于 GNN；十二卡材料属于反事实模拟，也不能当作十二卡真实部署结果。正式引用具体提升前，需要将设备规模、资源表来源、参照策略与对应运行记录逐项匹配。

工作流依赖如何影响 GPU 执行

SagePilot 研究多个 Agent 工作流共享异构 GPU 时，模型准备、请求准入与设备放置如何共同影响完成时间。一个工作流包含模型调用和工具调用；下游调用尚未 ready 时，其模型身份可能已经确定，因此存在提前加载的机会。连续同部署调用若每次都重新申请后端，也会增加排队，并留下模型被回收的空隙。

模块	输入	具体产物
SageRadar	模型算子图、请求配置、GPU 属性、测量数据	运行时间、显存上界和加载时间构成的资源代价表
SageGraph	Agent 工作流依赖与部署身份	最大合法同部署调用链；论文还用物理图表达生命周期动作
SageWeaver	ready/near-ready 需求、资源表、副本与设备状态	执行 grant、加载、扩副本、回收和预取动作

模型算子图与设备属性

预测并校准，生成资源代价表

Agent 工作流

编译合法的同部署调用链

请求进入调度器

结合资源表、队列与副本状态判断准入

发放 grant 或准备模型

预留资源后异步加载、执行

完成或失败事件

更新状态，再进行下一轮决策

QMSum 连续聚合例子

融合前：聚合 A(Q8) → 聚合 B(Q8) → 聚合 C(Q8)
        acquire/complete  acquire/complete  acquire/complete

融合后：Fused[A, B, C]
        一次 acquire → 三次顺序生成 → 一次 complete

融合保留每一阶段的提示词、输出上限与结果传递，只把三次准入变为一次，让整条链持有同一模型副本的租约。已有活跃租约的副本不会在两个阶段之间被正常回收。收益来自减少重新准入、排队与可能的重加载；生成次数和 token 计算并未因此消失。

再加入另一个同样需要 Q8 的工作流，就会产生共享副本、合并需求、保留模型与扩副本的取舍：当前请求可能因增加副本更快完成，但新副本也可能占用其他模型唯一能放下的设备。

项目追问

Q: 为什么已经有 vLLM batching，还需要 SagePilot？

实例内 batching 负责组织已进入该实例的请求。SagePilot 还要处理调用之间的依赖、哪个模型何时加载、连续调用是否共享一次租约，以及请求放在哪类设备。两者处在不同层次，上层决定资源与准入，下层执行生成。

Q: 与 Maestro 的预测有什么区别？

Maestro 的相关预测侧重请求输出长度及由此带来的 KV 需求。SageRadar 用模型算子图、请求形状和设备属性估计配置级资源代价，再服务于模型生命周期和工作流调度。SagePilot 的时间估计也会利用近期输出长度，不能把它简化成只预测固定的模型权重大小。

Q: 这项系统工作的难点是什么？

各项动作会改变后续可行性。预取可以隐藏加载，却提前占卡；链融合减少准入，却延长租约；增加副本可以缩短队列，却挤压其他模型。解释效果需要把请求的 ready、等待、加载、生成与完成时间对齐，并用消融区分各机制的贡献。

设计与实现的区别

问题	论文的表达	当前核对到的实现
图优化	用物理图统一表达执行和生命周期选择	确定性链融合；生命周期动作由副本状态和策略实现
放置	联合考虑资源与完成时间	先过滤可行配置，再按卡容量、预测运行时间、设备 ID 排序
显存	更一般的时间线累计资源约束	单卡归属一个副本，副本内 batch 显存准入及账本检查
性能预测	GNN 提供资源信号	调度器查表；表既可来自预测，也可来自实测，需核对实验配置

论文依据为用户提供的《SagePilot: Latency-Aware Orchestration for Multi-Agent LLM Workflows on Heterogeneous GPUs》初稿（PPoPP2027_sagepilot.pdf，第 1、4–7 页）；实现细节依据 2026-09-06 的本地代码核对。初稿 §3.5 也明确采用事件驱动启发式，不能把形式化约束误解为精确全局优化器。个人分工和最终实验结果必须以真实记录为准。

逻辑图与物理图

SagePilot 初稿的完整题名是 SagePilot: Latency-Aware Orchestration for Multi-Agent LLM Workflows on Heterogeneous GPUs。逻辑图规定调用依赖、输入输出与可见结果；物理图决定哪些调用共享准入、模型何时加载或回收、调用绑定哪个副本，以及争用资源时谁先执行。初稿 §3.2–3.5 将这些动作放进同一计划，但明确将 SageWeaver 定义为事件驱动的启发式，没有给出全局最优保证。

对象	初稿定义	约束
activation	某模型节点的一次调用；重复修复产生新的 activation	不能把同角色的多次执行视作同一次
ready	所有前驱已完成	可以参与生成准入
near-ready	路径、角色、模型、不可变输入前缀和可用设备已确定；前驱已完成或在运行，至少一个仍在运行	可以准备模型，生成和外部副作用仍等待原依赖
deployment	模型及版本与 serving 配置组成的身份	跨工作流复用还必须满足隔离授权
grant / lease	调用单元准入某副本，并在执行期间持有租约	有活跃租约的副本不能回收
planning window	ready 单元及其紧邻的 near-ready 后继	不把未解析分支当成确定未来

SageGraph 的两步变换

初稿 §3.4 先做工作流内最大合法链融合，再构造模型生命周期动作。ready 单元可以选择 Load 或 Reclaim → Load；near-ready 单元可以选择 Prefetch 或 Reclaim → Prefetch。不需要加载动作时，可以复用已有副本，或延后该单元。

Fig. 4 的两个工作流 W1、W2 都需要当前的 Q8 和随后才 ready 的 Q14，且两个模型都不驻留。兼容的需求可共享一次 Q8 加载和一次 Q14 预取；两个工作流各自的请求状态、工具结果、KV 与完成事件仍然分开。若需增加独立副本，则对应独立的生命周期动作。

W1: Q8 调用 ── 工具 ── Q14 调用
       ↑                   ↑
    共享 Load Q8       共享 Prefetch Q14
       ↓                   ↓
W2: Q8 调用 ── 工具 ── Q14 调用

共享动作的可用设备必须满足所有消费者的设备约束，不能只因模型名相同就合并。物理候选是用于启发式构造的隐式空间，不意味着在线遍历所有图。

融合链的上下文包络

初稿公式 (4) 明确考虑后续阶段消费哪些先前输出。令 P_i 为第 i 阶段固定输入的 token 上界，A_i 为其消费的前序阶段集合，O_j 为阶段 j 的输出上限：

\[ I_i=P_i+\sum_{j\in A_i}O_j,\qquad I_c^{adm}=\max_i I_i,\qquad O_c^{adm}=\max_i O_i \]

以下为教学算例：A 的固定输入为 1000 tokens、输出上限 200；B 的固定输入为 300，消费 A 的输出、输出上限 400；C 的固定输入为 500，并消费 A、B 的输出。三个输入包络分别为 1000、300+200=500、500+200+400=1100，整链输入上界取 1100。链的运行时间则是各阶段时间预测之和。

这是初稿的通用定义。此前核对的 worker 使用“首段实际输入 + 前序最大输出上限”的近似；存在更长固定 prompt 或多段累计输出时，两者不等价，需要按具体模板验证。

同一时间线上的依赖与争用

初稿公式 (7) 同时考虑逻辑前驱和资源顺序前驱。某操作即使数据就绪，也可能因为模型准备或同卡前一个操作尚未完成而不能开始：

\[ \hat s_u=\max\left(\hat r_u,\max_{v\in pred_G(u)}\hat c_v, \max_{v\in rpred_\pi(u)}\hat c_v\right),\qquad \hat c_u=\hat s_u+\hat T_{u,a(u)} \]

例如数据第 100 秒就绪，模型第 90 秒加载完，但设备上有不可并发操作到第 120 秒才结束，则最早第 120 秒开始。如果本次执行需 20 秒，预计第 140 秒完成。这里的数字是演示值。

初稿公式 (11) 在每个预计状态变化时刻检查“驻留与过渡态模型内存 + 活跃请求的增量内存”是否超过设备容量。请求项是增量内存，不能给每个请求重复累加同一份权重。副本的 batch 上限也必须满足。此前代码核对的是单卡单副本与副本内 batch 准入，尚不能据此确认一般时间线约束已完整实现。

Algorithm 1 与字典序目标

步骤	具体含义
RankReady	按优先级和 aging 排 ready 单元
BestFeasibleBinding	过滤设备，每个单元至多返回一个绑定；能复用副本则形成 grant
PlanReady	为其余 ready 工作考虑加载、扩副本或安全回收
PlanPrefetch	仅当没有 ready grant 或生命周期动作推进时考虑预取
Propagate	传播完成时间、排列资源冲突并检查可行性
Prefix	只提交当前可执行前缀，后续事件到达后重算未发出的部分

公式 (12) 的排序键为：

\[ \Phi=(-A_1,\ldots,-A_K,\hat C_F,-P_N,H_{life}) \]

按字典序最小化：先尽量服务高优先级 ready 单元，再比较这些单元的最晚完成时间，然后增加及时预取，最后降低加载和回收导致的生命周期代价。它不使用一个任意加权总分来交换这些优先顺序。Algorithm 1 按这个意图逐步构造计划，并非求解所有图与排程组合的精确优化器。

来源：用户提供的 PPoPP2027_sagepilot.pdf 初稿，第 4–7 页，Fig. 3–4、公式 (1)–(12)、Algorithm 1。文件采用 PPoPP ’27 模板，不据此推断已投稿或录用。

预测怎样帮助调度

Q: SageRadar 的预测具体怎么做，为什么调度需要它？

调度器知道下一步要调用哪个模型，但还需要知道：放到不同 GPU 上分别要跑多久、需要多少显存，如果模型没加载，还要准备多久。只有这些数值，才能比较一个请求放在哪里更早完成，以及能不能放得下。

所以我们的预测对象是“一次模型调用在某种执行配置下的资源开销”。比如同样调用 Qwen3-8B，输入 2048 tokens、输出预算 512 tokens、batch 为 2，在 V100 和 A100 上就分别对应一组时间和显存估计。输入长度、输出长度和 batch 改了，估计也要跟着变。

具体做法是，把模型在这个配置下的计算过程转成算子图。图上的节点是矩阵乘、Attention 这些算子，边表示张量怎样从一个算子传到下一个算子。每个节点带上计算量、张量形状等特征，边带上数据量，再把 GPU 算力、带宽以及请求配置一起交给图模型。

图模型沿着依赖关系聚合信息，最后汇总出整个计算图的表示，用不同的回归头预测运行时间和峰值显存等指标。训练标签来自实际测量：在对应配置下执行，记录耗时和资源峰值，让模型学习图结构、配置和资源代价之间的关系。

这些预测会提前整理成资源表。在线调度时，根据模型、GPU、batch 和长度配置查表，再结合当前队列、模型是否已经驻留、前驱任务什么时候完成，比较候选位置。模型加载时间也进入这套查询接口，并通过加载实测记录进行校准。

时间和显存的使用方式不同：时间估计帮助选择更快完成的位置，显存估计用来判断能不能接这个请求。显存低估可能直接导致 OOM，所以我们会给预测值做校正、加入余量，而且按配置允许的输出上限检查容量，不因为最近回答比较短就把显存预算一起缩小。

用一个请求串起输入与输出

以 Qwen3-8B / decode / batch=2 / 输入2048 / 输出预算512 为例。这里 512 是需要评估的输出长度配置，不代表已经知道下一次真实生成长度。

确定执行配置

模型、prefill 或 decode、batch、输入长度、输出长度配置

生成模型算子图

节点表示算子，边表示张量依赖

加入目标 GPU 属性

同一请求分别评估 V100、A100 等候选设备

用实测样本训练回归模型

学习执行时间、峰值显存等资源指标

生成并校准资源表

时间供候选比较，显存校正并增加准入余量

在线调度查询

结合就绪时间、驻留状态和排队情况选择位置

这里有两张不同的图。 SageRadar 的算子图展开一次模型调用内部的计算；SageGraph 的工作流图描述多个 Agent 调用和工具调用之间的先后关系。前者回答“一次调用要花多少资源”，后者告诉调度器“下一次调用什么时候才有机会开始”。

输入层次	例子	为什么需要
算子节点	算子类型、MACs、参数量、张量形状、内存量	判断这个算子有多少计算和访存工作；MACs 表示乘加操作数量
依赖边	张量字节数、元素数、维度、连接关系	区分算子怎样衔接、需要传递多少数据
请求配置	prefill/decode、batch、长度与整图统计	同一个模型在不同请求规模下开销不同；部分长度信息也体现在张量形状中
设备属性	GPU 算力、显存容量、带宽	相同计算图在不同设备上的执行表现不同

图模型怎样训练出来

一个训练样本由“算子图和配置”以及“对应的实测资源标签”组成。 网络共享图编码部分，再分别回归多个指标；不同目标的数值尺度经过缩放，输出时恢复对应单位。

编码节点、边和全局特征

算子类型先做 embedding，再与数值特征合并

沿依赖边聚合信息

TransformerConv 图层更新表示

汇总整个图

mean / sum / max pooling 保留平均、总量和极值信息

分别回归各个目标

独立预测头输出耗时、显存等指标

与实测标签比较并更新参数

加权 Smooth L1 损失，AdamW 优化

Q: Decode 生成 512 个 token，要把 512 步都展开成图吗？

当前采图实现没有把所有生成步骤展开。它先构造长度为“输入长度 + 输出长度 − 1”的 KV 上下文，再捕获一步 decode，同时把输出长度作为全局特征。输入 2048、输出 512 时，构造的是长度 2559 的已有上下文，再捕获接下来这一步。

这样既能让图反映长上下文下的算子形状，又控制了图的规模。训练时用对应配置的实测耗时作为标签，让模型学习配置到运行时间的关系。不能把这里的一步采图理解为只预测一个 token，也不能直接说实现就是“最后一步耗时乘 512”。

Q: 网络结构和训练目标具体是什么？

核对的训练配置采用 128 维隐藏表示、2 层图网络、8 个 attention heads，读出方式是 mean/sum/max，使用加权 Smooth L1 和 AdamW。共有九个预测目标，其中调度重点使用运行时间、峰值显存和部署时间，标签分别是 run_duration_sec_avg、gpu_mem_used_mb_max 和 deployment_duration_sec_avg；其余目标包括 CPU、主机内存、GPU 活跃度和功率等。

初稿 §3.3 介绍的是运行时间、峰值显存和部署加载时间三类资源输出，上面的网络参数来自关联实现。

预测怎样变成一次放置决策

在忽略额外资源争用、且排队等待可以用一个可执行时刻表示的简化例子中：

\[ t_{finish}(d)=\max\{t_{ready},\ t_{model}(d),\ t_{queue}(d)\}+\hat T_{run}(d) \]

$t_{ready}$：前驱结束、输入齐备的时刻，由工作流进展估计。
$t_{model}(d)$：设备 d 上模型准备好的时刻，由驻留状态和加载耗时决定。
$t_{queue}(d)$：设备上的执行队列允许这个请求开始的时刻。
$\hat T_{run}(d)$：资源表提供的本次调用执行时间估计。

取最大值是因为三个条件都满足才能开始，再加上实际执行所需的时间。GNN 提供执行代价，当前排队和驻留状态由调度器掌握，整个工作流的就绪时间也不是 GNN 单独输出的。

例如从现在计时，请求预计第 5 秒就绪，两张卡都空闲：A100 没有模型，从现在加载需要 8 秒，执行需要 4 秒；V100 已驻留模型，执行需要 9 秒。

候选	能开始执行的时刻	预计完成时刻
A100，允许现在开始加载	max(5, 8, 0) = 8 秒	8 + 4 = 12 秒
V100，模型已经驻留	max(5, 0, 0) = 5 秒	5 + 9 = 14 秒

在这个例子的资源条件下，A100 更早完成。如果必须等请求就绪后才加载，A100 则要到第 17 秒完成。预测的价值，是把加载能否提前、不同 GPU 的执行速度以及请求就绪时间放到同一次比较里。这是解释决策的算例，真实准入还要检查显存和其他请求的资源占用。

输出长度未知，时间和显存分别怎么估计

资源表按模型、GPU、batch、输入长度和输出长度配置索引。运行时间可以用同一节点近期输出 token 数的 p90 选择覆盖桶；没有历史时使用配置的输出上限。p90 就是近期样本中约 90% 不超过的长度。

例如输出上限为 1024，近期 p90 为 300，如果资源表有 256、512、1024 三个桶，时间估计选择能覆盖 300 的 512 桶；显存仍查询覆盖 1024 上限的配置。时间侧利用近期请求通常较短这个信息，容量侧继续为允许生成的最大长度留空间。

Q: 在线每来一个请求，都跑一次 GNN 吗？实测表和预测表是什么关系？

当前调度接口在线查资源表，离线可以用 GNN 预测或实测 profiling 填充同一套字段，所以图推理不用放在每次调度的关键路径上。GNN 的作用是学习不同配置的资源代价；实际测量则提供训练标签、校准依据，也可以直接形成资源表。

讲实验时，要区分这一轮使用的是预测表还是实测表。当前等预算评估使用已标定的运行时间缓存，具体某次运行是否使用 GNN 表，应以该次配置为准。

显存：点估计、校正值与准入上界

显存低估可能导致 OOM，所以点预测不能直接等同准入预算。当前后处理先拟合线性去偏项，其中 I、B、O 分别是输入长度、batch 和输出长度：

\[ M_{corr}=\max\{1, w^\top[\hat M,\log_2 I,\log_2 B,\log_2 O,1]\} \]

这里的 1 是代码使用的最小正值，单位沿用资源表的 MB。再根据校准集的正向残差分位数加入余量，并至少保留 10%：

\[ M_{upper}=\max(M_{corr}+q_{0.95},\ 1.1M_{corr}) \]

最终准入条件还包括固定余量与该配置的 OOM 惩罚：

\[ M_{upper}+\epsilon_{mem}+penalty_{OOM}\le M_{GPU} \]

显存按配置的输出上限检查，不因近期输出较短而缩小准入容量。 例如时间按 300 tokens 的覆盖桶估计，显存仍按 1024 上限的覆盖桶检查。两者分别服务于完成时间估计与容量安全。

Q: 95% 分位数加 10% 余量，能保证零 OOM 吗？

这是经验上界。运行分布变化、后端额外开销和未建模状态都可能使实际占用超出校准范围。分位数必须用独立数据验证覆盖率，并监测低估尾部与 OOM；它不能作为绝对安全证明。

Q: 为什么不用参数量、FLOPs 或 GBDT？

图特征能表达算子类型、形状和依赖的差异，但有图结构不等于必须用 GNN。应比较解析公式、表格模型和 GNN 的误差、数据成本与下游调度收益，尤其检查显存低估尾部。简单公式在某些目标上可能更有效。

Q: 换成 H100 的设备属性就能保证泛化吗？

设备属性提供条件输入，不构成泛化保证。新架构、kernel、精度与后端版本都可能改变映射。需要留出 GPU 或模型族的测试，并根据目标设备实测做校准。采图与训练本身也有成本，不能把系统表述为完全零 profiling。

Q: 算子图会遗漏哪些运行信息？

模型级图不自动等同真实 serving 的 kernel 执行图，后端融合、kernel 选择、动态 batching 和资源争用都可能造成偏差。要用匹配后端与负载的标签和独立验证检查误差；新增运行特征或 trace 校准属于需要验证的补偿方法。

核对依据：关联实现的 src/gnn_model/data/causal_lm_graph.py、data/constants.py、models/predictor.py、训练配置 scaled_training_v2_20260607.yaml，以及 src/experiment/workflow/cache_postprocess.py。

用过去的重新加载耗时估计下一次

加载时间的 serving 校准来自真实日志：同一个模型过去在同类 GPU 上重新加载用了多久，就用这些记录估计下一次的成本。日志读取 model_load_finished.payload.duration_sec。这项统计可直接替换 GNN 资源表里的原始部署时间预测。

首次加载 Q8 → 使用 → 回收 Q8 的 GPU 副本 → 再次加载 Q8 → 使用
                                        ↑ warm reload 统计对象

每轮运行内，按 (model_key, GPU 类型) 识别首次加载并排除，后续记录进入 warm 统计。这是按事件顺序划分的操作口径；它不直接检查操作系统缓存，不能仅凭“第几次”证明缓存一定热。缓存仍在主机侧时可能更快，但存储拥堵和并发加载也会改变耗时。

初稿 §3.3 只定义部署级加载代价与缓存接口，未展开 warm reload 的两层中位数。这套统计和门槛来自代码后处理路径，不能将其当成初稿公式，也不能仅凭初稿确认 Table 1 的加载误差统计覆盖了该校准。

两层中位数算例

下面全部是演示数字，不是论文实验结果。

运行轮次	首次加载，排除	后续 reload 耗时	该轮中位数
第 1 轮	90 秒	28、30、32 秒	30 秒
第 2 轮	85 秒	29、31、33 秒	31 秒
第 3 轮	100 秒	27、29、35 秒	29 秒

每轮先排序取中间值，然后对 30、31、29 再取中位数，得到 30 秒。下一次同模型在同类 GPU 上重新加载时，资源表提供的经验估计就是 30 秒。

\[ \hat T_{load}=\operatorname{median}_{run}\left(\operatorname{median}(T_{warm\ reload\ in\ run})\right) \]

先按轮汇总，使每个有 warm 记录的运行贡献一个代表值，避免某轮因重复加载特别多而主导总体统计。排除首次加载按部署身份进行，直接替换原值的最终统计范围是“模型名 × GPU 类型”。

数据不足如何回退

条件	采用的估计
模型 × GPU 至少有 3 轮 warm 记录、合计至少 5 条 warm 样本	使用两层中位数替换原值
该组样本不足，但同类 GPU 有满足门槛的模型	使用 GPU 级经验比例乘原估计
连 GPU 级比例也无法取得	保留原资源表的加载时间

GPU 比例由合格模型的 warm 实测代表值 / 原估计值 取中位数。例如其他合格模型的代表比例为 0.5，样本不足模型原来估计 80 秒，回退值为 40 秒。这仍是跨模型的粗略校准。

调度怎样使用 30 秒

假设任务预计第 100 秒 ready，加载估计 30 秒，预取余量 5 秒，则预取资格从第 100 - 30 - 5 = 65 秒开始。若资源允许并及时发起，加载可与前驱执行重叠。实际策略仍先推进 ready 工作，所以到第 65 秒不意味着一定加载。

同一加载成本也参与回收决策：预计 100 秒后再用且重加载只需 20 秒的模型，比 30 秒后再用且重加载需 25 秒的模型更适合暂时回收，前提是其他保护条件相同。

Q: 没有神经网络参与，为什么也叫预测？

预测是给尚未发生的事件提供估计。历史中位数本身就是统计预测器：把可比较的过去测量汇总，作为下一次的预计耗时。GNN 可以给原始值，历史数据足够时再用 serving 的真实重加载统计替换。

Q: 这 30 秒能用来估计首次冷启动吗？

不能直接等同。统计特意排除了每轮首次加载，目标是后续重加载成本。首次冷启动的文件读取、缓存与引擎初始化状态可能不同，需要单独的观测口径或估计。

核对依据：src/experiment/workflow/cache_postprocess.py 中 _robust_medians、_gpu_scale 与 _calibrated_load；门槛分别是 MIN_CALIBRATION_RUNS=3 和 MIN_WARM_SAMPLES=5。

同部署链如何找到

给定工作流 P → A(Q8) → B(Q8) → C(Q8) → D(Q14)，编译器沿拓扑顺序检查相邻边，满足下列条件才合并：

前后节点都是可融合的 Agent 节点。
前节点只有该后继，后节点只有该前驱，链内部没有分叉或汇合。
两者部署的 model_key 相同，涵盖模型路径、dtype 与 serving 配置等身份。
其余执行配置相同，允许每阶段 max_new_tokens 不同。

链首仍可以接收多个外部前驱，链尾仍可以连向多个外部后继。约束针对链内相邻边，不能误解成整条链两端也必须一对一。

输入：P → A(Q8) → B(Q8) → C(Q8) → D(Q14)
输出：P → Fused[A, B, C] → D(Q14)

编译器延长至最大的合法链，生成 FusedAgentNode，重接外部边、移除链内部边，并保留各阶段的 prompt、system prompt 和输出上限。这里是确定性的合法性扫描，不是枚举所有物理图并搜索全局最优。

执行时究竟省了什么

以下是概念伪代码，用于说明准入边界：

grant = acquire(chain_resource_budget)
try:
    for stage in stages:
        prompt = render(stage.prompt, context)
        result = backend.invoke(prompt, stage.max_new_tokens)
        context = update(context, result)
finally:
    complete(grant)

同一后端依次执行原有的三次生成，整链只申请和释放一次资源。租约覆盖中间阶段，因此正常回收策略不能在阶段切换处移走该活跃副本。伪代码的异常收尾不代表已验证所有失败情形；生产实现还必须区分成功、失败和取消。

对象	融合后的变化
acquire / complete	多次变成一次
后端副本租约	覆盖整条链
生成调用	仍按原有阶段顺序执行
提示词与结果传递	保留各阶段语义
token 计算量	不因链融合自动减少
kernel / KV 共享	不能仅由调用链融合推导出自动共享

时间和显存预算

没有历史时，链运行时间按各阶段估计求和。显存容量需要覆盖后续阶段可能增长的上下文。

当前 worker 使用的输入长度近似为“首段实际输入长度 + 前序阶段最大的输出上限”。如果后续固定提示词更长，或模板累计保留多段输出，这个近似需要扩展。它不能无条件覆盖任意提示词模板。整链预留还可能比逐阶段准入更保守，长租约会影响其他请求的等待。

跨工作流共享

两个工作流需要相同部署时，可以共用该部署的副本组。开启跨工作流生命周期机制后，需求按 model_key 合并；关闭时按 (workflow, model_key) 分别统计。合并后的需求会进入加载收益排序，也影响保留模型、预取与回收判断。

Q: SageGraph 是把多个 prompt 拼成一个大 prompt 吗？

不是。当前链融合仍逐阶段渲染提示词、调用模型、传递结果。合并的是资源准入与副本租约边界，不是把多次推理替换为一次推理。

Q: Agent 分支还没确定，怎么提前知道该加载什么？

利用已确定路径和部署身份的 near-ready 节点。未解析的动态分支不能当成确定需求。提前准备依赖工作流可见性，而不是凭对话内容任意猜测未来工具。

核对依据：src/workflow/fusion.py 的 find_fusable_chains、_same_deployment、_build_fused_node，以及 src/workflow/worker.py 的融合执行路径。

调度状态与动作顺序

SageWeaver 当前实现由事件推动，结合 pending 请求、会话依赖、预测表、模型副本和设备归属做决策。核心状态更新通过命令队列串行处理；加载和执行异步进行，完成事件回来后再更新账本。

清理异常副本

先处理需要清理的可疑状态

ready 请求准入

优先尝试已有副本，检查合并 batch 显存

加载或扩副本

有空卡时评估 ready 需求与扩容收益

回收与 drain

为受阻 ready 请求准备资源

near-ready 预取

没有可推进的 ready 动作时才尝试

完成事件

更新状态并再次决策

ready 排序与可行性过滤

cache 策略偏向模型已驻留的 ready 请求，同类按请求顺序，等待过久的请求通过 aging 提升优先级。它降低长期等待风险，但不能据此宣称持续过载下有有限等待上界。

设备选择先检查三个条件：

实际输入长度 + 配置输出上限 ≤ 模型上下文上限
资源表存在覆盖输入、输出和 batch 的桶
显存上界 + 固定余量 + OOM 惩罚 ≤ 设备容量

可行候选按“卡总显存更小 → 预测运行时间更短 → 设备 ID”排序。例如请求在两类卡上都可行时，先倾向显存较小的卡。这一步不是对所有设备全局最小化排队、加载和执行的总时间。

加入已有副本仍要重新检查总 batch。例如已有两个请求，新请求加入后按 batch=3、所有请求中最大的输入桶与最大的输出桶查显存上界，不能只验证新增请求单独能否放下。

多个模型都要加载，先加载谁

当多个模型都有需求、需要决定加载顺序时，优先考虑：花同样的加载时间，哪一个模型能为更多请求准备好服务。

$$ score(m)=\frac{N_{ready}(m)+N_{near-ready}(m)}{\hat T_{load}(m)} $$</div>

m：一个待加载的模型部署配置。
N_ready：输入已经齐备、正在等待资源的请求数。
N_near-ready：前驱已完成或正在执行、接下来可能就绪的任务数；不把整个工作流里所有未来节点都算进来。
T̂_load：把这个模型加载到候选设备上预计需要多少秒。
score：需求数量除以加载耗时，越大越优先。它是加载优先级分数，不是模型每秒能完成多少请求。

先看一个不用算公式的例子

假设现在只有一张合适的空卡，M1 和 M2 都没有加载，而且加载都要 10 秒。当前及即将就绪的请求中，6 个需要 M1，2 个需要 M2。

先加载 M1：花 10 秒，为 6 个请求准备好了模型；先加载 M2：同样花 10 秒，只为 2 个请求准备好了模型。 在其他条件相同、没有请求等待过久时，我们优先 M1。

这不意味着 6 个请求会在 10 秒内全部完成。10 秒只是模型准备时间，之后仍需进行容量检查、排队和生成。

加载时间不同，就比较需求与耗时的比值

以下是演示数字，Q8 和 Q14 分别代表两个模型部署：

候选模型	有多少请求需要它	加载需要多久	优先级分数
Q8	6 个	30 秒	6 ÷ 30 = 0.20
Q14	2 个	40 秒	2 ÷ 40 = 0.05

Q8 需要的加载时间更短，而且需要它的请求更多，所以优先加载 Q8。 这里 0.20 和 0.05 只用来排序，不能解释为 Q8 的生成吞吐是 Q14 的四倍。

跨工作流为什么要一起统计

假设 W1 有 2 个请求要用 Q8，W2 有 4 个请求也要用相同部署配置的 Q8，分子就合计为 6。一次加载得到的实例可以供多个工作流复用，因此加载决策需要看到这些共同需求，而不是只数 W1 的两个请求。

这个分数用于候选加载动作的排序。资源是否可行、副本是否达到上限等条件还要检查；等待超过阈值的请求会优先于普通分数排序，避免低需求模型一直被推后。

Q: 面试时怎么解释这个加载优先级？

如果几个模型都需要加载，我们会把不同工作流对同一个模型的当前和即将到来的需求加起来，再除以加载时间。这样，同样花一段时间加载模型，我们更倾向于先准备需求更多、加载更快的那个。比如两个模型都要加载 10 秒，一个有 6 个请求需要，另一个只有 2 个，就先准备前者。已经等太久的请求会提高优先级，不能一直让热门模型先走。

何时增加副本

扩容比较原副本排队的预计完成时刻，与新副本加载后完成的预计时刻：

\[ gain=\widehat F_{existing}-(now+\hat T_{load}+\hat T_{run}) \]

例如留在原队列还需 70 秒，新副本需加载 30 秒、执行 20 秒，预计收益为 20 秒。若配置扩容门槛是 10 秒，就通过收益判断；这并不意味着一定扩容，还要检查副本上限、可用设备和其他需求的可行性。

核对的实验配置对每个“部署 × GPU 类型”副本组最多允许两个副本，扩容每 tick 至多发起一次。扩容不得拿走其他有需求模型最后一个可行位置；如果要回收别的模型，还需要覆盖相应扰动。具体阈值属于配置，不能写成普遍常数。

回收谁

先排除活跃租约和受保护副本，检查可回收状态与最短驻留时间。具有可计算复用距离和重加载成本的候选中，优先冗余副本，再比较：

\[ eviction\ score=\text{距下次使用的时间}-\text{重加载成本} \]

差值越大，通常越适合回收。模型 A 为 100 - 20 = 80 秒，模型 B 为 30 - 25 = 5 秒，其他条件相同时优先 A。没有候选具备可计算的距离和加载成本时，回退到冗余优先及 LRU 顺序。不能把这个分值直接用于所有副本而忽略合法性过滤。

何时预取

near-ready 节点的所有前驱均已完成或正在运行，且至少一个仍在运行。未完成前驱的最晚预计完成时刻决定其 ETA：

\[ ETA(u)=\max_{v\in pred(u),\ v\ not\ completed}\widehat{finish}(v) \]

\[ t_{prefetch}=ETA(u)-\hat T_{load}-\epsilon \]

预计第 100 秒 ready，加载 30 秒，余量 5 秒，从第 65 秒起具备预取资格。策略仍优先 ready 工作：已有准入、加载或回收动作推进时，不立即开展推测性预取。这种顺序保护当前需求，也可能错过更激进的重叠机会。

资源账本的实际边界

加载动作发出前，设备归属先交给 LOADING 副本，防止另一动作重复取得同一张卡；加载完成后更新副本状态。执行中的租约、batch 准入与账本校验进一步约束资源使用。

当前模型主要是“一张卡归属一个副本 + 副本内 batch 显存检查”。论文中沿时间线累计多个模型、请求与加载占用的更一般规划，不能直接当成已完整实现的功能。

核对依据：src/workflow/policy.py 的 select_placement、select_eviction_victim，以及 src/workflow/scheduler.py 的 tick_once、_order_by_load_yield、_collect_near_ready_tasks 与扩副本路径。

实验设置与数据范围

以下数值是用户提供的 PPoPP2027_sagepilot.pdf 初稿 §4 的报告值，尚未完成与原始运行记录的一一对应。初稿与此前代码仓库的图表来源说明存在差异，所以“论文报告”与“已核实实测”不能互换。

项目	初稿 §4.1–4.2 的描述
设备	三个节点，共 8 张 V100-32GB 与 4 张 A100-40GB
后端	CUDA 12、vLLM 0.10.2、PyTorch 2.8.0、Transformers 4.55.2
模型	Qwen3 0.6B、1.7B、4B、8B、14B；每副本占一张 GPU
会话	GSM8K、MBPP、QMSum 各 60，共 180
到达过程	burst；每场景 0.150 或 0.075 sessions/s 的 Poisson
重复	同一到达 trace 使用 seed 42；各配置执行五次，取运行级指标均值
预测测试集	2,798 个实测 Qwen3 部署配置

GSM8K 使用多求解器并行、投票和精炼；MBPP 包含生成、测试、诊断与修复；QMSum 包含两条并行滚动总结链及聚合链。三者分别带来 fork–join、工具交错和连续同模型调用等结构。

端到端时间

到达设置	SagePilot makespan	对 Parrot / Kairos 的报告降幅	尾延迟说明
Burst	634.2 秒	35.8% / 36.8%	overall p95 为 587.0 秒，降低 25.4–25.9%
Poisson 0.150	965.1 秒	12.4–13.1%	部分 p95 或模型子集指标可能由其他策略更优
Poisson 0.075	1386.4 秒	1.6–6.6%	更早排空全部负载不等于每个会话的尾延迟都最低

makespan 是从首个到达直到最后会话完成的总区间；p95 来自每个会话的完成延迟，包含依赖、排队、加载和执行，不是单次模型推理时间。初稿的 Oracle 使用已知 trace 时长做离线参考，明确不是可在线实现的策略，也不是严格下界。来源：第 8–9 页，Fig. 5、§4.2。

GPU 时间与占用

场景	SagePilot GPU-s / 完成会话	相对两条参照线的报告降幅
GSM8K	46.26	46.9–47.4%
MBPP	15.33	53.8–56.7%
QMSum	65.25	14.5–16.5%

跨 180 个会话平均最多节省 24.63 GPU-s / 会话。初稿将 GPU 时间拆为生成、空闲驻留、加载和其他活动，并按各场景在同模型上的生成时间份额分摊共享生命周期成本。idle residency 是权重仍占 GPU 但没有生成的时段；GPU-s 不是能耗焦耳，也不能仅凭占用时间推导电费。来源：第 9 页，Fig. 6、§4.3。

预测精度与决策精度

预测器	加载 WAPE ↓	运行 WAPE ↓	显存 WAPE ↓	排序准确率 ↑	窗口可完成判断 ↑
SageRadar	8.05%	7.25%	14.08%	97.94%	97.82%
Formula	27.21%	15.29%	11.98%	96.37%	96.82%
GBDT	24.35%	11.05%	15.70%	96.53%	97.18%

WAPE 是绝对误差总和除以实测值总和，不是逐样本百分比误差的平均。排序准确率检查预测与实测是否认同两个配置谁更快；窗口指标检查能否在 48.85 秒内完成，这个阈值是留出配置实测运行时间的中位数。两项都不能直接解释为 OOM 避免率。

Formula 的显存 WAPE 最低。 SageRadar 的优势在本表中是运行与加载误差、排序和窗口决策准确率，不能讲成三个资源目标全部最优。来源：第 9 页，Table 1、§4.4。

消融结果的含义

替换或关闭的机制	初稿报告的变化
用 GBDT 替换预测器	完整 SagePilot 的 makespan 比它低 1.0–3.0%
用 Formula 替换预测器	完整 SagePilot 的 makespan 比它低 6.6–36.3%
生命周期决策限制到单工作流	makespan 比完整系统增加 7.1–16.4%
关闭节点融合	p95 增加 8.5–44.9%，makespan 增加 3.0–8.1%
关闭预取	三种到达设置下 makespan 均增加

“增加 x%”与反向“降低 x%”使用不同分母，不能直接互换。初稿的 per-workflow lifecycle 仍允许复用已加载副本，只把复用估计、等待排序和加载收益按工作流分别计算，不等于全面禁止跨工作流模型共享。来源：第 9–10 页，§4.5、Fig. 7。

尚需统一的证据

初稿写“12 GPU、五轮均值”，此前核对的 evaluation_12gpu_counterfactual/manifest.json 却标记相关图表为反事实模拟并采用选定来源。初稿把预测器替换视为隔离变量，而 run_serve_0728.sh 的 SagePilot 分支使用 profile_v2 实测标定表。实验说明还限定 Parrot / Kairos 仅借用请求排序规则。要确认上述数值的最终口径，需要把每张图对应到运行 manifest、输入 trace、资源表版本和汇总方法；单凭新 PDF 不能消除这些差异。

来源文档为论文初稿，不据其版式推断投稿或录用状态，也不把摘要提升归因于 GNN 的单独贡献。

预测收益如何验证

预测误差和调度收益回答不同问题。运行时间平均误差降低，不一定改变队列顺序；显存平均误差很小，也可能在少数请求上严重低估。完整验证要同时报告预测精度、显存覆盖率、加载偏差、端到端延迟和系统资源成本。

追问	可验证的回答
GNN 比解析模型强在哪里？	在相同数据与预算下比较目标误差、低估尾部和实际决策收益
融合带来多少收益？	固定其余配置，只关闭融合，观察准入次数、重加载和完成时间
预取是否有效？	固定其余配置，统计加载与前驱执行的重叠，以及额外驻留成本
跨工作流共享有何作用？	改变需求合并范围，检查加载排序、复用和资源争用
是否真在端到端用到 GNN？	核对运行命令、资源表来源和运行记录，而不是只看方法名称

当前实验材料的口径

2026-09-06 核对到的材料有以下限制，不能把它们混成一组实测结论：

data/evaluation_12gpu_counterfactual/manifest.json 明确标记为 12 GPU 反事实模拟，且未建模跨 GPU 网络、存储、PCIe 与并发加载干扰。这不是 12 卡端到端实测。
run_serve_0728.sh 的 sagepilot 分支读取 cache/profile_v2/predictions.yaml。该运行配置不能直接支持“收益由 GNN 带来”的归因；需要独立确认使用 GNN 表的实验。
serve_0728_reference.md 说明 Parrot / Kairos 参照仅借用了请求排序规则，没有完整实现各系统的其他机制，因此不能表述为完整系统复现。
旧资料中的数据集规模、跨 H100 泛化和“零 profiling”等说法，缺少本次核对所需的完整证据，不作为已验证成果列出。

工程追问

Q: 两个请求同时看到空闲显存怎么办？

把检查、预留、发 grant 放在同一个资源所有者的原子状态转换中。当前调度器核心通过命令队列串行更新状态，并在异步加载前登记 LOADING 归属。解释并发正确性必须指出状态所有者和原子边界，仅说“异步执行”不足以证明不会超卖。

Q: 取消和完成消息同时到达，如何避免重复释放？

作为工程扩展，应按 request / attempt 标识实现幂等状态转换，让资源只释放一次，并用 generation / epoch 隔离旧尝试。超时不等于 worker 已停止，重新分配前需要取消确认、核对或隔离。这些是需要通过故障测试验证的设计要求，不代表当前系统已经具备完整高可用保证。

Q: GPU 利用率低，怎么找到瓶颈？

先拆请求时间：arrival、ready、acquire、加载起止、生成起止、工具起止与 completion，再关联 session、node、replica、device。分清排队、加载、生成还是工具占主导，再深入对应时间线。显存占用、GPU 忙碌比例和有效生成吞吐不是同一指标，不能仅凭一个利用率百分比下结论。

Q: 从十几张卡扩到万卡，如何设计？

当前材料没有验证万卡。扩展可采用全局路由与局部准入：全局维护容量、模型位置摘要，资源域内部做精确预留。摘要过期时，局部仍拒绝不安全准入；还需处理热模型复制、跨域代价和故障隔离。验证应覆盖控制面事件吞吐、p99 决策延迟、数据面吞吐与恢复时间。

Q: 提高吞吐却让 p95 延迟变差怎么办？

明确负载和目标，例如在满足延迟 SLO 条件下最大化可接受吞吐。长链租约、驻留优先与更大 batch 都可能改变等待分布，需要同时测尾延迟、SLO 违反比例和公平性。当前启发式不能被描述为严格 SLO 保证。

Q: 哪种负载下收益可能变小？

所有模型都能常驻、加载已经完全被隐藏、工作流缺少可融合链，或大部分时间花在生成和工具执行时，生命周期优化的空间可能缩小。相反，频繁换模也不保证一定受益：若预取和重加载争抢 I/O，可能引入新瓶颈，需要受控对照验证。

Q: 简历里的个人贡献该如何具体表达？

把真实负责的组件、一个可复现的问题、做出的代码或策略改变，以及有运行记录支撑的结果连起来。团队成果、当前实现和未来扩展分别陈述。未确认的个人职责、投稿状态与实验提升不填成既成事实。

内容模块

字节 Lumen 实习

Lumen 内部统一 GPU 资源池

Lumen 内部各团队的 GPU 需求存在忙闲差异。没有内部协调时，暂时空闲的资源会被 Merlin 回收，难以充分服务 Lumen 内部其他有需求的任务。 平台将各团队暂时未使用的配额汇入统一公共池，让 C 优先级的 Spot 任务使用；团队配额内需求恢复时，再回收 Spot 占用。

Q: 请完整介绍这段实习经历。

我在字节国际电商 Lumen 团队实习期间，参与建设了内部统一 GPU 资源池，主要工作包括公共池资源分配、Spot 任务回收、任务状态管理，以及和 Merlin 平台的对接。

这个项目的背景是，GPU 配额按内部团队分配，但各团队的需求不同步。有些团队暂时用不满，其他团队又有额外任务需要运行。如果没有内部协调，空闲资源会被底层 Merlin 回收，不能充分服务 Lumen 内部的任务。

我们的做法是把各团队暂时未使用的配额汇入统一公共池，供 C 优先级，也就是 Spot 任务使用。团队仍保留自己的配额权益，等它有新的配额内需求时，再回收 Spot 占用。这让空闲资源能够先在 Lumen 内部发挥价值。

团队内所有任务都经过我们的平台，配额也由我们管理，所以我们能统一控制哪些任务可以提交、哪些 Spot 需要回收。底层通过 Merlin OpenAPI 提交、查询和停止任务，具体节点和 GPU 放置由 Merlin 负责，我们这一层不直接接触 Kubernetes。

回收时，先检查目标任务的配额资格，优先使用已有空闲资源，只对不足的部分发起回收。同时为目标任务保留额度，收紧新的 Spot 准入，避免刚回收的额度又被新申请占用。选择回收对象时，策略有三个先后顺序。

第一，先确定可以中断的范围。只从使用公共池、符合回收规则的 C 类 Spot 任务中选择，已经进入回收流程的任务不重复选择。

第二，在能够补足缺口的组合里，优先考虑估计中断代价较低的组合。结合任务类型、卡数、已运行时长和 SM Active 判断，不能只看到某个任务利用率低就直接停止。我们要求用户任务自身具备 checkpoint 保存能力，平台负责中断，checkpoint 由任务保存；实际重算损失取决于最近一次有效保存，运行时长只能作为间接参考。

第三，代价接近时，尽量少中断任务、少超额回收。选定后通过 Merlin 停止任务，等确认任务退出、占用释放，再更新资源账本并提交等待任务。

工程上的主要难点，是我们的资源账本和 Merlin 的执行状态是异步变化的。我参与的状态管理，需要把资源承诺、实际占用和释放区分开。MySQL 保存持久状态，Redis 加速高频读取，可靠性主要体现在三个环节。

首先是并发准入。多个任务可能同时看到公共池有空闲额度，因此额度检查和预留需要原子完成。任务一旦获批，即使还没在 Merlin 上运行，也要计入已承诺资源；最终分配不能只依据缓存里的剩余量。

其次是区分操作请求和执行结果。提交前先记录任务及额度承诺，再调用 Merlin 并关联外部任务标识。接口超时，任务可能已经创建，不能直接释放额度或重新提交，要先核查。停止任务也是一样，发出停止请求之后仍保留占用，确认释放才能推进后续任务。

最后是状态核对和异常恢复。根据 Merlin 的状态反馈推进本地记录，持续核对未完成的提交和回收操作。重复收到完成结果只能释放一次额度；服务重启后，也要根据持久记录继续核查未完成操作，避免重复提交、重复释放，或者任务结束后额度一直不归还。

这段经历让我把团队的资源使用规则落实成了公共池准入和回收流程，也积累了通过外部平台执行调度决策、处理异步状态一致性的经验。项目的价值是提高 Lumen 内部空闲资源的使用效益，同时在团队配额内需求恢复时有序回收 Spot 资源。

平台职责与个人工作

环节	Lumen 内部平台	Merlin
任务入口	接收团队内任务，识别归属和优先级	接受平台提交的任务
资源权益	管理团队配额、公共池使用与任务准入	提供底层资源执行能力
Spot 回收	计算缺口，选择允许中断的任务	执行任务停止并提供状态
状态管理	核对资源承诺、占用和释放	提供实际任务执行状态
物理放置	根据 OpenAPI 可见信息作上层决策	选择具体节点和 GPU

所有任务经过统一入口是控制准入的前提。平台可以停止向公共池批准新的 Spot 使用，并为配额内等待任务保留额度；任务何时获得合适设备，还取决于 Merlin 的物理资源与放置条件。

Q: 你的工作与 Merlin 的边界在哪里？

我做的是 Lumen 内部的资源统筹，包括团队配额、公共池分配、Spot 回收和任务准入。Merlin 负责底层任务执行和设备放置。我们通过 OpenAPI 下发操作，再根据任务状态反馈更新账本。我这一层不直接接触 Kubernetes，也不直接操作节点或 GPU UUID。

统一公共池的使用规则

团队配额保留其使用权益，未使用部分进入公共池。C 优先级明确对应 Spot 任务，这类任务使用公共池并接受回收。公共池统一分配，不要求维护“A 团队把几张卡一对一借给 B 团队”的关系。

团队配额内占用与 Spot 占用需要分别统计。同一个团队可以同时有配额内任务和使用公共池的任务，任务所属团队与资源使用类别是不同维度。A/B 任务的完整定义、同级排序和具体抢占矩阵尚未补充，不能仅根据字母推导业务含义；“A 团队”也不等于“A 优先级任务”。

回收策略与工程重点

回收选择依次遵循：先过滤允许中断的公共池 Spot 任务，再比较满足缺口的组合代价，代价接近时减少中断任务数和超额释放量。结合任务类型、卡数、SM Active 和已运行时长估计代价。SM Active 反映计算活动，已运行时长反映时间投入，两者都不能独立代表有效训练进度或剩余运行时间。

平台具备中断能力，并要求用户任务自行保存 checkpoint。平台不代替用户生成 checkpoint，也不能在没有接口信息的情况下假定能够确认最新保存点或在停止前触发保存。实际重算损失取决于用户侧有效 checkpoint。

上层发出停止请求以后，旧任务可能还在退出。任务状态、配额账本和实际占用必须持续核对，才能避免把尚未释放的资源再次分配。并发准入、调用超时、事件重复和进程重启，都是状态管理需要覆盖的情况。

效果与经历表达

Q: 这项工作的价值和你的收获是什么？

这项工作让 Lumen 内部暂时不用的资源能够优先被内部 Spot 任务利用，并在团队需求恢复时协调回收。评价效果需要同时看公共池使用情况、配额内任务的等待时间、回收耗时和中断损失。我积累的是把资源使用规则落实成任务准入与回收策略，并通过外部训练平台执行、核对状态的经验。

已有材料没有核实利用率提升百分比、成本节省或严格回收时限，量化效果以实际统计为准。具体锁、事务、字段和重试流程可以作为设计题展开，不能仅凭合理性认定为历史代码实现。

公共池与 Spot 的资源关系

各团队保留配额权益，暂时未使用的配额汇入 Lumen 内部公共池。C 优先级的 Spot 任务从公共池申请资源；团队新增配额内需求时，公共池可供 Spot 使用的空间缩小，必要时触发回收。

对象	管理含义
团队配额	团队能够使用的资源权益
配额内占用	团队任务已经使用的资源
公共池	各团队暂时未使用额度形成的统一可用空间
C / Spot 任务	使用公共池、允许被回收的任务
额度预留	已承诺给任务、尚未完全转为实际占用的部分
Merlin 放置	将已提交任务落实到具体节点与设备

配额准入与实际设备就绪分别确认。以下流程是在统一入口、统一配额管理和 Merlin OpenAPI 条件下的具体设计；字段名、事务和选择算法是设计展开，不等同于历史代码逐行还原。

任务提交与公共池准入

接收任务

识别所属团队、资源请求和任务优先级

核对权益

配额内任务检查团队额度，C/Spot 检查公共池

承诺额度

在并发控制范围内检查并登记尚未执行的资源承诺

调用 Merlin

使用 OpenAPI 提交任务，记录外部任务标识

同步执行

查询或处理状态反馈，推进占用与失败释放

公共池可继续分配的量需要扣除 Spot 已占用量和已批准的 Spot 申请，并考虑已经承诺给配额内任务的需求。回收中的 Spot 在确认退出前仍计入实际占用，不能因其进入回收状态就提前算为空闲。不同卡型或独立资源域分别核算，额度还需结合 Merlin 的可执行条件。

触发回收与选择对象

确定目标需求。 选出具备配额内准入资格的等待任务，先使用现有可用资源，再计算仍需回收的缺口。没有实际需求时，不因 Spot 正在使用公共池就主动清退。
收紧公共池准入。 为目标任务保留额度承诺，减少新 Spot 可获批的空间。保留的是提交资格，等待实际释放后才执行新的资源分配。
过滤候选。 选择占用公共池、按业务规则允许回收、尚未被其他回收计划选中的 Spot 任务。若定义了保护期或退出时限，也在此检查。
比较组合。 在释放量能够覆盖缺口的组合中，比较估计中断代价。结合任务类型、卡数、SM Active 和已运行时长估计代价；代价接近时，优先减少被中断任务数，再减少超额释放量。用户任务自行保存 checkpoint，只有平台实际可见保存进度时，才能进一步估计重算量。
通过 API 执行。 调用 Merlin 停止所选任务，跟踪结果，确认占用已释放后推进目标任务。结果不明时先核查，不能直接撤销或重复扣减。

Q: 你们具体怎样回收 Spot 任务？

团队有新的配额内任务时，我们先核对它的额度和需求，算出当前资源缺口。确定需要回收后，先减少公共池继续接收 Spot 的额度，为目标任务保留提交资格，避免一边回收一边又批准新的占用。

选择对象有三个先后顺序：第一，只保留公共池里符合回收规则、尚未进入其他回收计划的 Spot 任务；第二，在能补足缺口的组合中，优先选估计中断代价低的，结合任务类型、卡数、运行时长和 SM Active 判断；第三，代价接近时，尽量少中断任务、少超额回收。选好后调用 Merlin 的停止接口，继续跟踪任务状态。

停止请求发出后，资源仍按占用核算。确认任务真正退出、占用释放以后，再更新账本并提交目标任务。如果回收失败，就核对状态后重试或更换对象；如果目标任务取消，就撤销对应额度承诺。

Q: Spot 被中断时，checkpoint 由谁负责？

平台可以通过 Merlin 中断任务，用户任务需要自行具备 checkpoint 保存能力。平台负责决定回收对象、执行停止和确认释放；保存训练状态由用户任务完成，重新运行时的恢复逻辑也需要由任务实现。不能仅凭“任务支持 checkpoint”就保证停止前一定完成了一次最新保存，实际损失取决于有效保存点。

16 卡示例：公共池使用与归还

以下为机制示例，假定卡型相同且 Merlin 能满足目标任务的放置条件。

阶段	甲团队配额内占用	乙团队配额内占用	Spot 占用	说明
初始	4	4	8	两团队各有 8 卡配额，未使用的 8 卡进入公共池并被 Spot 使用
甲新增 4 卡需求	4	4	8	为甲保留额度，计算需回收 4 卡；此时设备尚未释放
Spot 退出	4	4	4	实际释放 4 卡，交接期间仍为甲保留额度
甲的新任务运行	8	4	4	甲兑现配额内需求，剩余公共池仍供 Spot 使用

若可回收任务只能以 8 卡为单位整体停止，可能释放超过缺口的资源；超额释放部分在核对账本后重新参与公共池分配。不能默认任意抽走一个多卡任务中的几张卡。

低代价选择与可见信息

Q: 为什么不总是抢一个大任务，或者抢 SM Active 最低的任务？

任务数少不一定损失小。一个大任务可能已经运行很久，几个刚启动的小任务反而中断代价更低。SM Active 低也可能是通信或数据准备阶段，不能直接判断任务没有价值。我会先筛出允许回收的对象，再结合运行信息比较满足释放量的组合。

候选少时，可枚举组合并剪枝；候选多时，可按估计代价与释放量生成初始可行组合，再在搜索预算内改进。具体搜索方法属于设计选择，不能声称未经验证的最优性或历史实现。若只有已运行时长和设备指标，损失模型应视为估计；用户任务需要自行保存 checkpoint；只有平台能获得有效保存点和进度信息时，才进一步估计需要重做的进度和恢复代价，不能把全部已运行时长当成损失。

平台只使用 Merlin OpenAPI 暴露的信息。 如果接口没有节点与设备拓扑，就不能在这一层保证单机多卡放置。节点级预留、GPU UUID 选择和 Kubernetes 调度插件不属于已确认的 Lumen 平台能力。

Q: 回收后的资源为什么不会被其他排队任务抢走？

我们统一管理团队内所有任务的入口和配额。回收开始前，先将对应额度留给目标任务，其他尚未提交的 Spot 就不能再获批使用它。已经提交到 Merlin 的任务必须计入已承诺占用；如果要撤销它们，仍需通过 API 确认。这样能够保证上层额度交付，具体设备何时到位由 Merlin 决定。

上层账本与 Merlin 执行状态

平台统一管理任务入口、团队配额和公共池，通过 Merlin OpenAPI 提交、查询和停止任务。MySQL 持久化任务与配额状态，Redis 缓存高频调度数据；状态变化后持续核对记录与实际占用。对外以用户确认的 OpenAPI 描述接入边界，不据此推定具体传输协议或底层 Kubernetes 实现。

下面的字段、原子提交和恢复路径是可靠性设计，用于解释机制；不是对历史数据库和代码的逐项还原。

配额与公共池怎样记账

状态	核算用途
团队配额	判断配额内任务的使用资格
配额内占用与未完成承诺	防止运行中和待启动任务重复使用权益
公共池 Spot 占用与承诺	计算还能批准多少 Spot 使用
回收计划	关联目标需求、受害任务、预期释放量和执行状态
外部任务标识	对照 Merlin 中的实际任务，核查不确定结果

公共池统一管理 Spot 使用，不要求维护团队之间一对一的借入/借出关系。已提交到 Merlin 但尚未运行的任务也属于承诺占用，不能只统计 Running。

目标任务的额度承诺和尚未释放的 Spot 实际占用需要分别表达。回收期间两者可以同时存在：前者禁止新的竞争申请，后者反映设备仍被占用。只有确认 Spot 退出，才允许把释放容量用于目标任务，不能将“额度预留”误算成一份已经可用的设备。

并发准入如何避免重复分配

两个任务同时读到剩余四卡，不能各自获批四卡。可用短数据库事务结合行锁，或带版本的条件更新，将“检查可用额度”和“登记资源承诺”放在同一个并发控制范围内。

校验

读取本资源域的配额、占用、承诺与回收状态

登记意图

原子记录目标任务的额度承诺和待执行操作

请求执行

事务提交后调用 Merlin OpenAPI

确认结果

成功则关联外部任务，结果未知则进入核查

释放承诺

仅在确认失败、取消或完成后按状态处理

MySQL 事务不能把外部 API 调用一起原子提交。调用前需要保留可恢复的操作意图，调用后依据查询结果推进；Redis 中的缓存读不能代替最终分配时的并发校验。

停止与资源释放的状态链

以下为概念状态名：

Running → StopRequested → Stopping → Released

观察到的状态	平台动作
请求已发出或接口接受	保留实际占用，继续查询
任务仍在停止	保留回收计划，不重复选择同一受害者
已确认任务退出及占用释放	幂等扣减 Spot 占用，推进目标任务
请求失败且任务仍运行	保留占用，按规则重试或补选对象
目标任务取消	撤销目标额度承诺，核对已停止/尚在运行的 Spot

平台能够中断 Spot，用户任务负责 checkpoint 保存。资源释放确认与训练进度保存是两个不同条件；没有相应接口时，平台不能把停止成功当成 checkpoint 已保存。

Merlin 若将任务退出与资源释放分别暴露，应等待接口定义的可用状态；不能仅凭本地停止标记推断设备已经空闲。

API 超时、重复事件与重启

Q: Merlin 提交接口超时，能不能直接再提交一次？

超时只说明没有收到确定结果，任务可能已经创建。我们先保留额度承诺，利用外部任务标识、查询能力或接口支持的幂等键核查。如果确认已经创建，就补齐本地关联；确认未创建后才重试。如果接口无法消除歧义，就保持待核查状态，不能盲目重新创建任务。

Q: 回收接口超时怎么办？

我会先查目标 Spot 是否还在运行。已经退出就同步释放结果，仍在退出就继续等待，确认未执行才按接口语义重试。同一任务的释放只能记账一次，不能因为重复响应多次增加公共池可用量。

事件处理应按任务标识和可用的版本信息去重；迟到的 Running 事件不能将终态任务重新记为占用。服务重启后，扫描未完成的提交与回收计划，查询 Merlin 并恢复状态。不能把 API 的幂等性当成上层账本天然一致。

如何判断公共池是否有效

目标	需要观察的证据
提高 Lumen 内部使用效益	内部公共池使用量、Spot 有效完成量、空闲资源被外层回收的情况
满足团队配额内需求	等待时间、资源兑现情况、回收耗时
控制中断损失	Spot 中断次数、重算与恢复开销（可测时）
保持状态正确	账本与 Merlin 不一致数量、重复提交、核对恢复耗时

这些是效果评估方法，尚无已核实的提升百分比。GPU 占用率反映分配情况，SM Active 反映计算活动，最终仍要结合任务完成量和等待情况解释效益。

Q: 这段实习最大的工程难点是什么？

主要难点是资源账本和 Merlin 执行异步变化，一次接口调用不能同时保证两边状态一致。MySQL 保存任务、配额和未完成操作，Redis 加速高频读取，关键是把资源承诺、实际占用和释放分别管理。

第一是并发准入。多个任务可能同时读到同一份剩余额度，因此检查额度和记录预留需要原子完成。获批但尚未运行的任务也要计入承诺，最终分配时仍需并发校验，不能直接相信缓存读到的可用量。

第二是操作请求与执行结果分开。调用前先持久化任务和额度承诺，再提交给 Merlin。提交超时可能已经创建成功，要先查询核实，不能立即重提或释放额度。停止请求被接受，也不代表资源已释放，必须跟踪到接口确认的释放状态后再推进等待任务。

第三是核对和恢复。持续检查未完成的提交与回收操作，重复结果只能引起一次有效状态迁移和记账。服务重启后根据持久记录查询 Merlin，继续处理未完成操作；这样才能避免重复创建任务、重复归还额度以及占用长期残留。

内容模块

面试叙事

互补关系

Maestro 解决推理侧的多 agent 调度，DeepShare 解决训练侧的多租户管理。一个完整的 GPU 集群需要同时支持训练和推理。

共通设计理念

理念	Maestro	DeepShare
预测驱动调度	预测输出长度 → 内存管理 + 排队	预测运行时间 → 排序 + 抢占
代价感知抢占	量化降级代价 C_deg 选最小影响路径	量化抢占效率 E_j 考虑进度损失
弹性资源管理	CUDA VMM 3× 超配	DRA 弹性配额借用
分层架构	全局调度器 + 节点运行时	全局调度器 + 节点 DaemonSet

自我介绍中的论文定位

我的研究聚焦于 GPU 集群的资源调度与性能预测，在训练和推理两个互补场景下展开：

DeepShare（IEEE Cluster 2026）解决多租户 GPU 集群中训练作业的调度。核心创新是配额保障度 QAD，统一驱动弹性配额管理、预测性调度和干扰感知合用，在 219 GPU 的 K8s 集群上实现 70.58% GPU 利用率和 93% QoS 合规率。

Maestro（ICDCS 2026）面向 LLM 多智能体系统的推理调度。核心挑战是输出长度不确定性和多模型内存压力。设计了两阶段预测器加 CUDA VMM 超配加 SRTF 调度，在 64 块 A100 上将 SLO 达成率提升 23.6 个百分点。

贯穿核心能力：用轻量预测模型为调度器提供前瞻性信号，再设计弹性资源管理和抢占策略来利用这些信号。

与工业界系统的区别

对比对象	区别
vLLM / SGLang	它们是单节点推理引擎，Maestro 在其之上做多模型管理和跨节点调度
Volcano	面向 Gang scheduling，DeepShare 在配额弹性、干扰感知、运行时间预测方面做了增强
Orca / FastServe	它们关注单模型的迭代级调度，Maestro 关注多模型多 agent 的工作流级调度

简历论文提问的一般规律

面试官看简历上的论文/项目描述时，通常按以下路径追问：

"这个东西解决什么问题？"——先确认你理解问题本身，不是只记了术语。
"为什么现有方法不行？"——考察你是否理解 gap 和 motivation。
"你的核心想法是什么？"——明确说清楚 insight。
"具体怎么实现的？"——深入技术细节，考察你是否真做了。
"XX 技术为什么选这个不选那个？"——设计决策题，考察 trade-off 思维。
"效果怎么样？怎么评估的？"——数字背后的实验设计和结论可信度。
"有什么局限性？如果重做会怎么改进？"——考察反思能力。

Maestro（ICDCS 2026）简历追问

简历原文："面向 LLM 多智能体系统的工作负载感知调度系统 Maestro。针对 LLM 多智能体（LLM-MAS）工作流中解码成本不确定、长尾多模型显存竞争与过度预留等系统挑战，设计在严格 GPU 预算下的工作负载感知调度系统。预测层：利用 Agent 角色与工具调用语义构建两阶段输出长度与显存预测器；调度层：工作流感知优先级排序与阶段边界抢占，SLO 达成率较 EDF 提升 23.6pp；节点层：分级权重缓存与弹性显存供给，KV 预留显存降低 67.2%。"

Q: 什么是"LLM 多智能体工作流"？给一个具体例子。

比如一个旅行助手 Agent：用户说"帮我规划去东京的行程"，系统会依次调用：需求分析 Agent（解析意图）→ 机票搜索 Agent（调工具查航班）→ 酒店推荐 Agent（查酒店）→ 行程整合 Agent（汇总输出）。每个 Agent 背后是一个 LLM 推理调用（称为 stage），一个用户请求可能触发十几次甚至几十次 LLM 调用。这些 Agent 之间有 DAG 依赖关系，不同 Agent 可能用不同模型。

Q: "解码成本不确定"为什么是个问题？固定预留不行吗？

LLM 推理的输出长度变化极大：工具调用输出几十 token（JSON 格式），用户交互输出几百上千 token。输出长度直接决定 KV Cache 大小和 decode 时长。固定按最大长度预留会导致严重的显存浪费（利用率低），按平均长度预留则会 OOM。关键挑战是在请求开始前就要预测输出长度来分配资源，但这个预测不准就会出问题。

Q: "两阶段预测器"具体是哪两个阶段？为什么要分两阶段？

第一阶段是工具调用分类器（LightGBM），判断当前 stage 是否会触发工具调用（AUC 0.96）。第二阶段是输出长度回归器，在分类结果的基础上预测具体 token 数（MAE 165 tokens，R² 0.78）。分两阶段是因为输出长度呈双峰分布——工具调用短（几十 token），用户交互长（几百上千 token），单一回归器在双峰上表现差。分类器先识别模式，回归器在各自模式下预测更精准。消融实验去掉分类器后 MAE 从 134 升到 142。

Q: "分级权重缓存"是什么？和普通的 LRU 有什么区别？

多 Agent 场景下一块 GPU 需要同时驻留多个模型权重。设计了五层状态：Running（GPU 上可立即执行）→ Sleeping（权重在 CPU，但 GPU 保留 CUDA Graph/JIT 缓存约 0.5GB，恢复省 5-8 秒）→ CPU-resident → Disk-resident → Remote。Sleeping 状态是关键创新——保留 GPU 侧的 kernel 缓存避免重建开销。层级化 LRU 逐级淘汰，最热模型留 GPU，最冷退到远端。

Q: "弹性显存供给"怎么做的？CUDA VMM 超配 3 倍不怕 OOM 吗？

用 CUDA Virtual Memory Management 实现地址和物理页分离。在 40GB A100 上分配 122GB 虚拟地址池（3 倍超配），物理页按需映射。三层防护防 OOM：(1) 虚拟地址不等于物理内存，多 Agent 的 KV 使用不会同时达峰（统计复用）；(2) 每个 stage 进入前做准入控制，检查剩余物理页是否满足预测需求；(3) cuMemMap 失败时拒绝该 stage 而非崩溃。偏向高估（安全裕度 ρ），低估导致 OOM 的代价远大于高估浪费。

Q: "阶段边界抢占"是什么意思？为什么不做 token 级抢占？

Stage 边界抢占是指只在两个 LLM 推理调用之间切换（一个 stage 完成后、下一个 stage 开始前），不打断正在 decode 的请求。Token 级抢占需要和推理引擎深度集成、做 KV Cache 迁移，工程复杂度极高。Stage 边界抢占只需更新元数据，实测效果已足够——交互排队延迟从 11 秒降到 2 毫秒。

Q: SLO 达成率提升 23.6pp 的 baseline 是什么？怎么算 SLO 达成？

Baseline 是 EDF（Earliest Deadline First），实时系统经典调度策略。SLO 定义为"交互式 stage 的 TTFT（首 token 时间）< 阈值"。在高负载下 EDF 因为没有预测信息，无法区分长短 stage，导致长 stage 阻塞短交互 stage（队头阻塞）。Maestro 用预测的剩余时间做 SRTF，加上工作流感知的优先级（交互式 > 批处理），SLO 达成率从约 60% 提升到 83.6%。

Q: 46,769 条真实 trace 从哪来的？怎么保证实验可信？

Trace 来自内部部署的多 Agent 应用平台，记录了每个 agent stage 的输入/输出 token 数、模型类型、时间戳。实验分为两部分：16 台 V100 做原型实测（端到端延迟、SLO 达成率），46,769 条 trace 做大规模仿真（64 卡级别）验证调度策略的扩展性。仿真器基于真实 trace 回放，关键参数（KV 内存增长、推理延迟）从原型实测校准。

DeepShare（IEEE Cluster 2026）简历追问

简历原文："以连续的「配额保障度（QAD）」为统一运行时控制信号、协调弹性配额借用、预测调度和干扰感知共置四类决策的 Kubernetes 原生调度框架。QAD = 分配量/min(配额, 保障需求)，经 EMA 平滑。空闲配额以 best-effort 借出（DRA），按 QAD+运行时预测做字典序排序，代价感知抢占。干扰感知共置用 RF 预测吞吐损失，MPS 共置无需改代码。23,859 条 Venus trace 仿真 GPU 利用率 70.6%（vs Lucid +29.5%），排队延迟降 46%；16 节点 64 卡 K8S 实测 JCT 降 34%，QoS 达成 93%。"

Q: 什么是"配额保障度 QAD"？为什么不直接用"用了多少 GPU / 配额"？

QAD = 已分配的 Guaranteed GPU / min(配额, 当前 Guaranteed 需求)。分母用 min(quota, demand) 很关键：如果租户 quota 32 但只需要 8 张，保障 8 张就是满足（QAD=1），不需要给满 32 张；如果租户提交 100 张需求但 quota 只有 32，保障 32 张就够（QAD=1），不会因为超额提交就认为系统欠它的。而"使用率"（usage/quota）不区分 Guaranteed 和 Best-effort，也无法区分"需求少"和"被欠服务"。EMA 平滑（λ=0.3）避免瞬时波动频繁触发抢占。

Q: "四类决策"是哪四类？QAD 怎么统一协调它们？

四类决策：(1) 弹性配额借用/回收（DRA）——QAD < 1 时回收 Best-effort 资源恢复保障；(2) 调度排序——Guaranteed 优先，QAD 低的租户优先，QAD 接近时短作业优先；(3) 抢占 victim 选择——抢占效率 Ej = (释放资源 × 剩余时间) / (1 + α × 抢占代价)，选代价最小的 Best-effort 作业；(4) GPU 共置准入——QAD 高时允许更激进的 colocation（利用率优先），QAD 低时收紧（保障优先）。QAD 作为统一信号，让四个模块的决策方向一致——保障不足时偏向 QoS，保障充分时偏向利用率。

Q: "MPS 共置"具体怎么实现？K8s 不是以整卡为单位调度吗？

K8s 的 nvidia.com/gpu 是 Extended Resource，分配后不可修改。GPU 共享通过节点侧 MPS DaemonSet实现——每块 GPU 运行 MPS control daemon，允多个 CUDA context 共享 GPU，通过 per-client SM 限制（CUDA_MPS_ACTIVE_THREAD_PERCENTAGE）做算力隔离。Scheduler Plugin 在 Filter 阶段检查节点是否有足够空闲 SM 和显存来接纳新 Pod（基于干扰预测），允许后 Pod 调度到该节点，Node Agent 配置 MPS 限制。不需要扩展 K8s 资源模型，也不需要改用户代码。

Q: 干扰模型用什么特征？为什么选 Random Forest 不用深度学习？

特征来自 DCGM 硬件计数器：SM activity、memory bandwidth utilization、L2 cache hit rate、PCIe throughput 等——这些是框架无关的，不管你跑 PyTorch 还是 TensorFlow 都能采集。选 RF 三个原因：(1) 推理延迟 < 1ms，满足实时调度（DL 模型要 50-200ms）；(2) R² = 0.902，精度足够；(3) 硬件计数器特征跨模型泛化，不需要每种架构重训。运行时持续监控实际 slowdown，超过动态阈值时驱逐低优任务。

Q: Venus trace 是什么？为什么不直接在大集群上跑？

Venus 是公司内部集群的作业 trace，包含 23,859 个深度学习作业的提交时间、GPU 需求、运行时长等信息。Trace-driven simulation 可以在可控环境下对比多种策略（对比 Lucid、Gandiva 等 baseline），控制变量。同时我们在 16 节点 64 卡的 K8s 原型上做了实测验证，证明仿真结论在真实环境中成立。大规模集群实测成本高且影响生产，仿真是学术研究的标准做法。

Q: 为什么 JCT 只降 34% 而 GPU 利用率提升到 70.6%？

JCT = 排队时间 + 执行时间。调度优化主要影响排队时间，执行时间由计算量决定。当集群负载高时排队时间占比大，JCT 改善明显；负载低时改善小。34% 是平均 JCT 降低，排队延迟降了 46%，执行时间基本不变。GPU 利用率从 39.64% 提升到 70.6%（+29.5% vs Lucid），说明资源确实被更充分利用了——主要来自 DRA 借用空闲配额和干扰感知共置两块收益。

ElastiCo（Performance Evaluation 2026）简历追问

简历原文："训推弹性混部（ElastiCo）：面向训练与离线 LLM 推理在同一 GPU 上的安全共置，提出资源形态变换、弹性影子定价与干扰感知共置三项机制，以原生 Kubernetes 中间件形式实现、无需改动用户代码。64 卡实测与最高 512 卡仿真下，平均完成时间最高降低 2.94×、集群吞吐提升 2.02×、GPU 利用率由约 25% 提升至 46%。"

Q: 为什么要把训练和推理放同一块 GPU？分别放不行吗？

训练集群平均 GPU 利用率只有 25% 左右——训练任务在数据加载、梯度同步通信、checkpoint 保存时 GPU 是空闲的，这些空窗期加起来占了大部分时间。同时离线推理（如批量 embedding、离线评估）有明确 SLO 但不需要独占 GPU。把它们共置可以填补这些空窗，把利用率从 25% 提到 46%。为什么不分开跑？分开跑需要额外 GPU，而 GPU 是最贵的资源——共置用同样的硬件跑更多任务，直接降成本。

Q: "资源形态变换"是什么意思？训练和推理的资源使用有什么互补性？

"形态"指 SM 算力和显存的分配比例随负载动态变化。互补性体现在：(1) 训练在 forward/backward 阶段 SM 利用率高（80-90%），在 dataloader/communication 阶段 SM 空闲；(2) 推理在 prefill 阶段突发 SM 需求，decode 阶段 SM 利用率低但占显存（KV Cache）。通过 MPS 动态调整 SM 比例+ VMM 弹性显存，可以在训练空闲时把 SM 让给推理 prefill，训练繁忙时收回 SM。这和 MIG 静态切分（固定 50/50）的区别是：MIG 切完就不变，ElastiCo 毫秒级动态调整。

Q: "弹性影子定价"是什么？怎么定的价？

给 GPU 上的 SM 和显存定一个动态价格，反映当前稀缺程度。价格由训练任务的实时 GPU 利用率和显存占用决定——训练越忙价格越高，训练空闲价格越低。推理任务有一个"价值"（SLO 优先级 × 剩余工作量），价值大于当前价格才允许共置。本质上是一个基于市场机制的准入控制：价格自动调节供需，比固定阈值灵活——高优推理在资源紧张时仍可进入（付高价），低优推理只在空闲时进入（付低价）。

Q: 和 DeepShare 的区别是什么？你们为什么做了两个系统？

DeepShare 解决的是多租户之间的配额管理（A 团队和 B 团队之间怎么借 GPU），合用对象是训练+训练；ElastiCo 解决的是同一 GPU 上训推的共置问题，两者在不同层级。而且训推共置有特殊挑战：训练是长作业、不能被杀（重启代价大），离线推理是短作业、可以被暂停/驱逐——这种主客不对称性是 DeepShare 没有的。两者可以组合：DeepShare 做集群级租户治理，ElastiCo 做节点级训推填充。

Q: "无需改动用户代码"具体怎么做到的？

三层透明注入：(1) Admission Webhook 自动给 Pod 注入 MPS 环境变量和 VMM 配置；(2) Node Agent（DaemonSet）通过 CUDA Driver API 动态管理显存映射和 SM 限制，不经过用户代码；(3) Scheduler Plugin 在调度时做放置决策，用户只需给 Pod 打上 elastico.sh/class: training 或 inference 标签。底层用 LD_PRELOAD hook 部分 CUDA 内存分配 API 实现显存记账，对训练/推理框架完全透明。

Q: GPU 利用率 46% 也不算高啊？为什么不是更高？

25% → 46% 已经是将近翻倍的提升。为什么不是 70%+？(1) 我们有严格的 SLO 约束——训练 slowdown 不能超过阈值（约 10%），推理 SLO 必须达标；(2) 训练的空窗期不是完全可预测的，有时推理刚加载进来训练就开始计算了，需要保护训练；(3) 显存容量是硬约束——训练占了大部分显存（权重+梯度+优化器状态），推理的 KV Cache 和权重可用空间有限；(4) 46% 是安全共置下的利用率，牺牲部分利用率换 SLO 保证是合理的 trade-off。

SagePilot（撰写中）简历追问

简历原文："结构感知的深度学习负载资源预测与 Agentic 工作流编排（SagePilot）。计算图表征：ONNX 计算图→图样本，融合算子类型、张量形状与拓扑结构。GNN 多目标预测：一次前向预测时延、显存峰值、GPU 利用率，免反复试跑。Benchmark：运行时程序分析自动采集，10W+ 条，覆盖 CNN/Transformer/推荐。工作流编排：冷启动预部署、OOM 风险选卡、显存复用与驱逐。"

Q: 为什么需要"不运行就预测"？直接 profile 不行吗？

Profiling 成本非常高：一个 7B 模型在 A100 上跑一次推理 profiling 需要几分钟到十几分钟，如果要测多个 batch size、序列长度、GPU 型号组合，可能需要几小时、占用多张 GPU。对于大模型（70B），profiling 本身就需要多卡，成本更高。而且在 Agentic 场景下，模型组合是动态的（用户请求决定用哪个模型），无法提前 profile 所有组合。SagePilot 通过 ONNX 图 + GNN 一次前向推理（毫秒级）就能给出多指标预测，零试跑成本。

Q: 为什么用 GNN？计算图和 GNN 的图是什么关系？

ONNX 计算图天然就是 DAG——节点是算子（matmul、conv、layernorm），边是张量（带 shape 和 dtype）。GNN 的消息传递机制恰好模拟了张量在算子间的流动：每个算子节点聚合其输入张量的信息，类似实际执行时算子读入输入计算输出的过程。MLP/CNN 无法处理变长拓扑（不同模型节点数从几百到几万不等），GNN 天然支持。

Q: 多目标预测具体怎么做的？显存预测 OOM 怎么办？

共享 GIN backbone，三个独立 MLP 输出头分别预测时延、显存、利用率。训练时用 uncertainty weighting 自动平衡三个 loss。显存预测使用非对称 loss——低估的惩罚是高估的 3 倍，因为低估导致 OOM（请求直接失败），高估只是浪费显存（可接受）。预测结果加安全裕度 ρ ∈ [0.1, 0.3]。

Q: ONNX 图丢了 kernel fusion 等运行时信息，预测准吗？

这是个好问题。ONNX 静态图确实看不到推理引擎的 kernel fusion 策略，但我们做了补偿：(1) 训练标签来自真实执行的 profiling 数据，fusion 带来的加速已经隐含在标签里，GNN 会学习到哪些算子模式容易被融合；(2) 加入常见 fusion pattern 的特征（如 matmul+bias+gelu 的组合模式）；(3) 对于特定引擎（TensorRT）可以加一个校准步骤，用少量 profiling 数据 fine-tune。当前 R² 在 0.8 左右，对资源调度场景足够。

跨论文追问（面试官可能串联提问）

Q: 你做了这么多调度系统，核心方法论是什么？

贯穿几篇工作的核心理念是用轻量预测为调度器提供前瞻性信号，再设计弹性资源管理和代价感知抢占来利用这些信号。DeepShare 预测作业运行时间来做排序和抢占，Maestro 预测输出长度来做显存分配和 SRTF 调度，ElastiCo 用影子定价（本质也是基于利用率的预测）做共置准入，SagePilot 直接预测模型资源画像。共同模式是：(1) 识别可预测的信号；(2) 选择轻量、低延迟、可泛化的预测模型（LightGBM/RF/GNN，不用大模型）；(3) 设计弹性机制利用预测信号获益，同时有安全兜底应对预测错误。

Q: 这些系统都是在 Kubernetes 上做的，为什么不自己做一个调度器？

Kubernetes 已经是 GPU 集群管理的事实标准，生态成熟（device plugin、CSI、CNI、Prometheus 监控）。基于 K8s Scheduler Framework 做插件可以复用大部分基础设施（节点管理、Pod 生命周期、资源账本），只需要扩展调度逻辑，用户迁移成本低。DeepShare 和 ElastiCo 都是 Scheduler Plugin + Controller + DaemonSet 的架构，不侵入 kube-scheduler 核心代码，升级 K8s 版本时维护成本低。Crater 开源平台也是基于 K8s + Volcano，验证了这个路线的可行性。

Q: 你在这些论文中具体负责什么？哪些是你做的？

四篇一作论文中我都是第一作者，负责问题定义、系统设计、核心算法实现、实验验证和论文写作。具体来说：DeepShare 中我设计了 QAD 指标和三个子系统的协同机制，实现了 K8s Scheduler Plugin 和 Controller 的核心代码，跑了 64 卡实测和 trace 仿真；Maestro 中我设计了两阶段预测器和 CUDA VMM 弹性显存管理，实现了节点级运行时和全局调度器；ElastiCo 中我提出了资源形态变换和影子定价机制，实现了训推共置的 K8s 中间件；SagePilot 中我设计了计算图表征方案和 GNN 多任务架构，搭建了自动化数据采集 pipeline。导师给方向指导，合作者协助部分实验对比。

Q: 你的工作有什么局限性？如果再做一遍会改进什么？

几个明确的局限：(1) 预测模型都需要训练数据，新场景/新硬件冷启动需要少量 profiling 数据做校准，未来方向是用 transfer learning 减少冷启动成本；(2) ElastiCo 目前只支持离线推理和训练共置，在线推理有严格 TTFT 要求，共置风险更大；(3) DeepShare 的 colocation 用 MPS 做 SM 隔离，但 MPS 不支持显存硬隔离（只是建议值），极端情况下一个任务可能撑爆显存影响另一个；(4) SagePilot 的 GNN 在超大规模计算图（>10万节点）上推理延迟可能成为瓶颈，需要子图采样或层次化预测。

Q: 你在字节实习做的跨团队二级调度框架，和你论文中的调度思想有什么联系？

共同关注的是资源共享、权益保障和中断代价。Lumen 实习建设的是内部统一资源池：各团队暂时不用的配额汇入公共池，由 C 优先级的 Spot 任务使用，避免空闲资源被 Merlin 回收后无法充分服务 Lumen 内部需求；团队需求恢复时再协调回收。平台统一管理任务入口和配额，通过 Merlin OpenAPI 提交、查询和停止任务，具体节点和 GPU 放置由 Merlin 执行。DeepShare 则研究配额保障、运行时间与干扰预测如何共同影响调度，并采用 Kubernetes 调度框架扩展。两者共享问题意识，但实现层次和具体机制分别说明。

面试官"挑刺"与陷阱题

面试官可能用挑战性问题试探你对自己工作的理解深度——不是真的否定你，而是看你是否思考过弱点。这些问题如果没准备过很容易卡壳。

Q: Maestro 说 KV 预留显存降低 67.2%，但这不是靠 CUDA VMM 超配"骗"出来的吗？实际物理显存并没有减少啊？

这个问题很尖锐。需要分清两个层面：(1) 预留（reservation）≠ 实际使用。传统方案为每个请求预分配最大 KV 空间（物理显存），即使实际输出很短也占着不放——这是真正的浪费。CUDA VMM 让虚拟地址远大于物理显存，但物理页按需映射，真正减少的是物理显存占用。(2) 67.2% 降低的是预留的 HBM 物理显存，不是虚拟地址。我们通过输出长度预测来决定实际映射多少物理页，短请求只映射少量物理页，其余虚拟地址不占物理内存。统计复用的前提是多 Agent 的 KV 峰值不重叠。如果所有请求同时输出长文本还是会 OOM，但实际 trace 中这种概率极低，且有准入控制兜底。

Q: 预测器出错了怎么办？如果预测输出 100 token 实际输出了 1000 token 呢？

这是所有预测驱动系统都要面对的问题。我们做了三层防护：(1) 偏向高估——训练 loss 对低估加惩罚（类似 SagePilot 的非对称 loss），预测值偏高而不是偏低，宁可浪费不能 OOM；(2) 动态扩容——KV 内存在 decode 过程中按页增长（paged attention 类似 vLLM 的思路），不是一次分配完，如果实际输出超过预测，运行时可以追加映射物理页；(3) 优雅降级——如果物理内存真的耗尽，选择抢占/暂停优先级最低的 stage 释放空间，而不是让整个服务崩溃。预测准确率 R²=0.78 看起来不高，但配合安全裕度和动态扩容，实际 OOM 率 < 0.1%。

Q: DeepShare 的干扰预测 R²=0.902 就敢用来做共置决策？万一预测错了把高优任务拖慢了怎么办？

R²=0.902 是在离线测试集上的指标，真正运行时我们不依赖单点预测做决策，而是：(1) 保守准入——预测 slowdown < 5% 才允许共置，留出足够安全边界；(2) 运行时闭环——共置后持续监控实际 slowdown（通过 DCGM 实时采集 SM 利用率），一旦实测 slowdown 超过阈值（如 10%）立即驱逐 Best-effort 任务，反应时间在秒级；(3) 只对 Best-effort 任务冒险——Guaranteed 任务的资源绝不用于共置，只有空闲配额借出的 Best-effort 任务才参与共置，预测错误最坏情况是杀掉 Best-effort 任务，不影响 Guaranteed QoS。

Q: 你们所有论文都用 trace 仿真+小集群实测，怎么证明在大规模生产环境有效？

这是学术研究的通用方法论局限。我们做了几件事增强可信度：(1) Trace 来自真实生产集群（Venus 23,859 条作业、Maestro 46,769 条 stage），不是合成数据；(2) 仿真器参数从 16 节点原型实测校准，保证仿真结果和真实环境趋势一致；(3) 64 卡 K8s 实测验证了关键结论（端到端 JCT、SLO 达成率），仿真主要用于验证大规模扩展性；(4) ElastiCo 做了 512 卡仿真看 scaling 趋势；(5) 字节实习中验证了核心算法思想在生产环境的可行性——弹性配额借用和代价感知抢占在工业界确实能落地。当然，真正部署到几千卡集群还需要更多工程鲁棒性工作，这也是未来方向。

Q: 为什么不直接用 vLLM/TGI 这些现成的推理框架？它们已经有 PagedAttention、continuous batching 了。

这是不同层面的优化：vLLM/TGI 优化的是单节点内推理引擎的 batching 和 KV 管理（PagedAttention 解决内部碎片、continuous batching 提高 GPU 利用率），Maestro 解决的是多节点、多模型、多 Agent 工作流的调度问题——一个用户请求涉及十几个 Agent stage、用多个不同模型、分布在多块 GPU 上。Maestro 可以和 vLLM 配合使用：节点内用 vLLM 做推理引擎优化，节点间用 Maestro 做工作流感知调度和显存管理。事实上我们的原型就是基于 vLLM 做的，分级权重缓存和 CUDA VMM 超配是在 vLLM 之上的额外优化。

Q: EDF 作为 baseline 是不是太弱了？为什么不和更先进的方法比？

EDF 是实时调度的经典 baseline，但我们的对比不只是 EDF。Maestro 对比了 EDF、SRTF（无预测）、FCFS、Karma（LLM 服务最近的调度工作）；DeepShare 对比了 Lucid（GPU 共享最强无侵入基线）、Gandiva（协同调度）、Tiresias（GPU 调度经典工作）、K8s 默认调度器。关键是 Maestro 的核心贡献不是调度算法本身（SRTF 是经典算法），而是把预测信号引入 LLM-MAS 场景并设计弹性显存机制来利用这些预测。和纯算法 baseline 比是为了证明预测信号的价值，而不是发明新的排序算法。

Q: MPS 有已知的问题啊——一个 CUDA context 段错误会影响 MPS server 下所有进程，你们怎么处理的？

确实，MPS 的一个已知风险是故障隔离差。我们的应对：(1) 只在受控环境下使用 MPS 共置——Best-effort 任务和 Guaranteed 任务共置时，Best-effort 任务是经过准入检查的（短作业、已知模型类型），减少未知风险；(2) 每个 GPU 节点上跑 MPS health monitor，检测到 MPS server 异常立即重启并隔离该节点上的新任务调度；(3) ElastiCo 场景下训练任务直接跑在 GPU 上（不经 MPS），推理任务通过 MPS 共享 SM，训练故障不依赖 MPS；(4) 对于生产环境，长期方案是用 MIG 或时间片（MPS 属于进程级共享，MIG 是硬件级隔离），但 MIG 不支持动态 SM 划分，ElastiCo 的动态资源形态变换目前只能通过 MPS 实现。

Crater 开源平台追问

简历原文："主导基于 Kubernetes 的 GPU 集群管理平台 Crater...已在实验室稳定运行 1.5 年，纳管 250+ 张 GPU、日均调度 200+ 任务，Apache-2.0 开源。"这是工程能力的重要证明。

Q: Crater 和 Volcano/Kubeflow 有什么区别？为什么不直接用现成的？

Volcano 提供了队列、优先级、gang scheduling 等基础能力，但它是通用的批调度器，缺少科研场景需要的功能：(1) 配额管理是硬划分，没有 DeepShare/ElastiCo 那种弹性借用；(2) 没有用户管理、审批流程、账户计费——科研集群需要导师审批学生的 GPU 使用；(3) 没有一键 LLM 训练/推理的作业模板，用户要写完整 YAML；(4) 没有集成 Jupyter/WebIDE/终端开发环境，科研用户需要交互式开发。Kubeflow 更偏 ML pipeline，不是集群管理平台。Crater 在 Volcano 基础上做了面向科研场景的封装和增强，整合了 DeepShare 和 ElastiCo 的调度能力，提供 Web 控制台降低使用门槛。

Q: 250 张 GPU 的集群，你作为项目负责人最头疼的技术问题是什么？

最头疼的是多用户场景下的 GPU 资源争用和占卡不释放问题。实验室场景下学生经常启动 Jupyter 后忘记关，GPU 被占着但利用率为 0。我们做了：(1) 占卡检测——Agent 监控 GPU 利用率，连续 N 分钟低于阈值就通知用户，超时自动回收；(2) 交互式任务有最长运行时间限制（默认 12 小时，可以续期）；(3) 训练任务必须在容器内跑，容器退出自动释放资源；(4) 空闲 GPU 标记和自动推荐。另外一个挑战是多型号 GPU（A100/A800/3090/4090/V100 混合），不同作业对 GPU 型号有不同要求，调度器需要感知拓扑和型号约束。

Q: Crater 的技术栈是 Go/React/Helm，你在其中写了多少代码？哪部分最复杂？

我是项目负责人，核心后端（Go）大约 70% 是我写的，包括自定义 Controller、Scheduler Plugin、API Server、配额管理逻辑；前端（React/TypeScript）主要是两个师弟做的，我做了架构设计和 Code Review；Helm Chart 和部署脚本是我写的。最复杂的部分是调度器和 K8s controller 的设计——队列状态机、配额超分/回收逻辑、和 Volcano 的协同、多维度抢占顺序的正确性保证。调试调度器问题非常痛苦，因为状态分布在 etcd、scheduler cache、node agent 多处，需要全链路 tracing。

论文间深层关系与体系化思考

面试官喜欢问"你的几篇论文之间是什么关系"——这考察你是否有体系化的研究视角，而不是零散地做了几个项目。

Q: 你的几篇工作（DeepShare/Maestro/ElastiCo/SagePilot）是一开始就规划好的 research line，还是逐步演进的？

是从实践中逐步演进出来的，不是一开始就规划好的。最早做 Crater 平台（2023）时发现真实 GPU 集群利用率只有 25-40%，于是做了 DeepShare 解决多租户配额借用问题（集群级）；在 DeepShare 实测中发现训推混部是更大的利用率提升空间，而且有独特的主客不对称挑战，于是做了 ElastiCo（节点级训推）；同时在 LLM Agent 场景下发现输出长度不确定是全新的调度挑战，做了 Maestro（请求级 LLM 推理）；在所有这些工作中反复遇到一个痛点——资源画像预测不准，需要 profiling，于是做 SagePilot（预测底座）。回头看形成了从集群→节点→请求→预测的逐层深入，但当时是跟着实际问题走的。

Q: 如果让你把这四个系统合并成一个超级系统，架构会是什么样？

这是个好问题。分层架构：(1) 预测层（SagePilot）——所有上层决策的基础，提供作业/模型/请求级别的资源画像预测，不需要运行就能给出时延、显存、利用率估计；(2) 集群调度层（DeepShare）——基于 QAD 做多租户配额管理、弹性借用、全局排序和抢占决策，决定作业放到哪个节点；(3) 节点运行时层（ElastiCo + Maestro）——在节点内做精细资源管理：训推共置用 ElastiCo 的资源形态变换和影子定价，LLM 推理用 Maestro 的分级权重缓存和 CUDA VMM 弹性显存，stage 边界抢占。Crater 是产品形态，把这些能力封装成用户友好的平台。共同的设计原则：预测驱动、弹性资源、代价感知、安全兜底。

Q: 你的工作和业界主流方案（K8s + Volcano/YARN/Kubernetes Scheduler）比，最大的 gap 在哪里？为什么工业界没有这样做？

几个原因：(1) 工业界优先稳定性——预测驱动调度如果预测出错会产生线上事故，工业界倾向用简单确定性策略（优先级队列+固定配额），学术界更愿意用预测换效率；(2) 工作负载差异——我们的场景是科研集群+LLM Agent，负载波动大、任务类型多样，弹性收益明显；而大厂在线服务集群负载规律，弹性空间小；(3) 工程复杂度——MPS 共置、CUDA VMM 超配、干扰预测都需要精细的工程实现和监控，大厂有更成熟的隔离方案（如 MIG、物理分区）；(4) 但趋势是工业界也在往这个方向走——字节内部的跨团队 Spot 调度、云厂商的 GPU 共享（如阿里云 cGPU、腾讯 qGPU）本质上都是弹性配额和精细隔离。我们的工作提供了算法和机制上的验证。

Q: ESCAPE（IEEE JCC Best Paper）和你后面的工作有什么关系？

ESCAPE 是我硕士阶段做的微服务资源估算工作，用 GNN + Profiling Engine 预测微服务的资源需求。这是我第一次接触"用 ML 做资源预测"这个方向，GNN 的使用经验直接启发了 SagePilot 的计算图表征思路——微服务调用图和 DNN 计算图在结构上都是 DAG，都可以用 GNN 建模；Profile Engine 的经验让我意识到 profiling 成本问题，才有了 SagePilot "零试跑预测"的动机。可以说 ESCAPE 是 research line 的起点，后面的 DeepShare/Maestro/ElastiCo 都需要预测信号，SagePilot 是回到预测这个基础问题上做深度工作。

压力面与行为题（结合论文经历）

面试官可能在技术讨论中穿插行为面试问题，用你的论文经历来考察软素质。这些问题需要用 STAR 法则回答。

Q: 做论文过程中遇到最大的困难是什么？怎么解决的？

（STAR 示例）S: DeepShare 做 64 卡实测时，干扰预测模型在实验环境精度很高（R²=0.9），但部署到真实集群后预测完全不准，共置任务频繁 slowdown 超阈值。T: 需要在不重写系统的前提下找出原因并修复。A: 我花了两周时间排查：(1) 先加详细日志记录每次共置的特征和实际 slowdown；(2) 发现实验环境用的是同一类型 GPU（A100），但真实集群有多种型号 GPU 混用，DCGM 指标在不同型号上的分布差异很大；(3) 训练数据只覆盖了 A100，没有做跨 GPU 泛化。解决方案是为每个 GPU 型号训练独立的 RF 模型，并加入 GPU 型号作为特征，同时引入 online fine-tuning——新的共置数据持续更新模型。R: 修复后跨型号预测 R² 恢复到 0.85 以上，共置 QoS 达标率从 60% 回升到 93%。这个教训让我在后续 ElastiCo 和 SagePilot 中都提前考虑了跨硬件泛化问题。

Q: 如果导师给你的方向你觉得不对，你会怎么办？（结合 ElastiCo/DeepShare 的选题经历）

我会先做小实验验证而不是直接反驳。例如最初导师建议在 DeepShare 中用强化学习做调度决策，我做了 literature review 后发现 RL 在调度场景的 sample efficiency 很低，真实集群无法承受在线探索的代价。但我没有直接否定，而是用一周时间做了个小 prototype：用 DQN 在仿真环境训练，对比 RF + 启发式规则的方案，结果 RL 收敛慢、调参困难、泛化差。带着数据和导师讨论，最终改用 RF 干扰预测 + 启发式排序的方案。我觉得导师给方向是大方向指引，具体技术选型需要自己用实验验证，用数据说话比争论更有效。

Q: 你同时推进 DeepShare、Maestro、ElastiCo、SagePilot 四个项目，怎么管理时间和优先级？

这确实是博士期间的挑战。我的方法：(1) 串行深入、并行维持——一个时间段主攻一个项目（做核心实验和写作），其他项目只做基础推进（每周开一次会、review 合作者进度）；(2) 复用基础设施——四个项目共享 Crater 平台、trace 采集 pipeline、K8s 部署脚本，避免重复造轮子；(3) 借助合作者——ElastiCo 有师弟帮忙做部分实验对比，SagePilot 的 ONNX 解析和图特征工程有一个本科生协助，我专注核心算法设计和论文写作；(4) 按截止日期排列优先级——会议截稿日期前 2 个月集中全部精力在那篇论文上。关键是识别项目之间的依赖关系（比如 SagePilot 的预测能力反过来可以增强 Maestro），让它们互相促进而不是互相竞争。

Q: 你的一作论文有四篇，最满意哪一篇？为什么？

最满意 DeepShare。原因：(1) 从问题到落地完整闭环——它是从 Crater 平台真实问题出发，经过 QAD 指标设计、系统实现、64 卡实测、开源验证完整走通的，不只是算法创新，而是真正在 250 卡集群上跑了一年多的系统；(2) 工程和研究的平衡最好——QAD 指标虽然简单，但统一协调四个子系统的设计很优雅，工程实现也足够扎实（Scheduler Plugin + Controller + DaemonSet 架构）；(3) 反馈最好——在实验室落地后确实解决了 GPU 争抢问题，同学们的作业等待时间明显缩短，这种"真的有人在用"的感觉比论文中稿更有成就感。Maestro 的 LLM 场景更新颖，但 DeepShare 是我从系统思维到工程能力成长最多的一篇。

Q: 你在寒武纪实习做 TF 算子适配，这段经历对你后面做 GPU 调度有什么帮助？

帮助很大，让我从底层理解了 AI 芯片的执行模型：(1) 做算子适配时需要理解 chip 的内存层次（SRAM/DRAM/片上缓存）、并行方式（多核/向量/张量核）、算子切分和 fusion 策略，这让我后来在做 GPU 调度时能从硬件特性出发思考问题——比如为什么 SM 和显存是两种不同资源、为什么 kernel fusion 会影响 SM 利用率、为什么 MPS 的 SM 比例调整不能太频繁；(2) C++ 底层调试经验让我在做 CUDA VMM、MPS 配置、LD_PRELOAD hook 时不怕碰底层；(3) 国产芯片的适配经历让我对硬件异构性有直观感受，后来 SagePilot 做跨 GPU 泛化时我就知道不同硬件的 performance counter 含义和分布差异很大。

场景题：如果面试官问"你来我们团队会怎么做"

Q: 如果加入我们团队做 AI Infra，你觉得你的研究经验能怎么转化为业务价值？

几个直接相关点：(1) GPU 利用率优化——我在 DeepShare/ElastiCo 中做的弹性配额、干扰感知共置、训推混部可以直接应用于提高集群利用率，字节实习中已经验证了类似思路在生产环境可行（400 张空闲卡问题）；(2) LLM 推理系统——Maestro 的输出长度预测、分级权重缓存、CUDA VMM 弹性显存思路可以优化 LLM 推理服务的显存利用率和 TTFT；(3) K8s 调度器开发经验——我有从零写 Scheduler Plugin、Controller、DaemonSet 的实战经验，不需要 Ramp-up 就能上手 K8s 相关开发；(4) 性能预测能力——SagePilot 的 GNN 预测思路可以用于作业调度前的资源预估、容量规划、自动扩缩容决策；(5) 工程能力——Crater 250 卡开源平台的经验证明我能把研究原型推进到生产级可用系统。

论文工作

ICDCS 2026 Maestro

排序和放置使用不同的依据

三个模块分别交付什么

普通抢占与内存压力处置要分开

实验数字的口径

问题背景

系统设计

为什么需要预测输出长度？

两阶段流水线

服务中的输入特征

训练目标与冷启动

两阶段带来的价值

预测信号如何驱动下游组件

核心结果

Maestro 高频问答

从 Agent 请求到输出长度

输入特征怎样获得

文本编码与两套 PCA

分类和回归怎样训练

长度怎样变成调度与 KV 预算

运行反馈与服务开销

设计动机与核心方法

模型训练与工程实现

调度价值与 KV Cache 追问

IEEE Cluster 2026 DeepShare

问题背景

系统设计

核心结果

核心定位

5-10 分钟中文论文讲解稿

开场：论文定位

1. 背景和问题

2. DeepShare 的核心思想

3. QAD 是什么？

4. 模块一：Elastic Quota Regulation / DRA

5. 模块二：Predictive Scheduling

6. 模块三：Interference-Aware Colocation

7. Kubernetes 实现怎么落地？

8. 实验结果

9. 论文贡献总结

10. 面试时的收尾版本

先把完整公式记对

为什么分母一定是 min(quota, demand)

分母不是 quota，也不是 demand，而是“当前应保障量”

用一个数字例子把边界钉死

最容易答错的边界

瞬时 QAD 和调度用 QAD 不要混

一个看快照，一个做控制

QAD 怎么驱动 DeepShare

常见误区

总体架构

三类组件分别管什么

QAD 在哪里维护

QAD 是 Scheduler Plugin 的内存状态

Kubernetes 对象如何表达

TenantQuota CRD：保存权益配置，不保存实时控制环

Scheduler Framework 五个扩展点

一次调度周期怎么走

两级队列不要记成两个 Controller

队列符号和职责

QAD 在调度路径中的输入输出

输入：已兑现与应兑现

输出：同一个 Q̃ 驱动三类决策

五个扩展点怎么串起来

故障恢复与热路径

DeepShare 高频问答

实现细节高频问答

论文原文延伸问答（基于 IEEE Cluster 2026 原稿）

先记住这条七步主线

两个预测模块先彻底分开

1. 背景：固定配额和资源共享存在天然矛盾

2. 动机：现有方法分别优化局部，却没有统一保障语义

3. 核心设计：用 QAD 表示配额兑现程度

4. QAD 统一驱动三个机制

5. 两个预测模块分别怎么做

6. 工程实现和实验结果

7. 收尾：这项工作的核心贡献

面试官打断时，用这四句保住主线

容易说错的六个口径

为什么分母一定是 `min(quota, demand)`