PromptTuner：把提示词调优当成有截止时间的弹性 GPU 作业

1. 问题不是普通训练，也不是普通推理

用户提交基础模型、初始 prompt、下游数据集、目标精度和截止时间，服务端运行若干轮 prompt tuning，最后返回优化后的 prompt。它像训练，因为有迭代、收敛和多 GPU 扩缩；它也像推理，因为每个请求只有秒到分钟级 SLO，实例初始化本身就可能占掉大部分预算。训练调度器 ElasticFlow 倾向在固定集群内频繁重分配 GPU，却不能复用模型运行时；推理系统 INFless 能维持热实例，但通常按一作业一 GPU 的固定形态工作。二者都没有利用“初始 prompt 会显著改变收敛轮数”这一任务语义。

PromptTuner 的目标有两个：减少未在 SLO 内达到终止条件的作业比例，同时压低云 GPU 成本。这里 SLO 不是单纯的响应时间，而是“在给定最大时间内达到目标精度或最大迭代条件”。因此只把作业尽早启动并不够；初始 prompt 太差，启动再快也可能来不及收敛。

2. 两条复用路径

Prompt Bank：先缩短算法路径

系统收集数千个公开高质量 prompt，用某个 LLM 的激活特征表示它们，以余弦距离做 K-medoids 聚类。第一层只保存每簇 medoid，第二层保存簇内候选。新作业只需先评估 K 个代表，再评估命中簇中的 C/K 个 prompt，而不是遍历 C 个候选。理想均匀情况下 K=√C，总评估量从 C 降到 2√C；论文报告查找开销最多降低 40 倍，并可在 10 秒内完成。

score(p) = (1 / |D_eval|) * Σ L(concat(p, d_i^in), d_i^tgt)

候选数：C
两层查找量：K + C/K
最小值：K = sqrt(C) 时约为 2*sqrt(C)

score 越小，prompt 在少量评估样本上的输出越接近目标。实现只用约 16 个评估样本，不先做 tuning。新优化出的 prompt 还会插回最相近的簇；超过容量阈值（例子中为 3000）时，删除与簇代表最相近的冗余项，以维持多样性。三层索引看似更快，但作者在 Vicuna-7B 上遇到聚类不收敛和数十分钟构建成本，因此停在两层。

Workload Scheduler：再缩短系统路径

调度器维护一个共享 cold pool，以及每种 LLM 一个 warm pool。warm GPU 已装好 CUDA/框架运行时和模型权重，同模型的新作业可以立即复用；cold GPU 没有绑定模型，可供数据中心其他服务使用，需要时再转入某个 warm pool。作业完成后 GPU 回到对应 warm pool，闲置超过论文采用的一分钟窗口才退回 cold pool。

3. 一次请求的完整数据流

1. 用户提交模型名、数据路径、初始 prompt、优化器与 batch size、目标精度、最大迭代数和 deadline。
2. Prompt Bank 用初始 prompt 定位代表簇，再在簇内计算 score，得到可迁移的候选 prompt。调度器也会判断 Bank 查询是否会与紧迫作业争抢资源；查询得不偿失时直接执行。
3. 作业进入对应 LLM 的 pending queue。warm-pool 算法按 SLO 从紧到松排序，从 1 张 GPU 起递增，直到预测完成时间 T_warm_i(a) 不超过 T_slo_i；当前 warm pool 不够就暂不分配。
4. cold-pool 算法先看 DelaySchedulable：未来已有作业释放 GPU 后再运行是否仍能按时完成。能则等待，不能才把 cold GPU 初始化成目标模型的 warm GPU，并把初始化成本 T_cold 算入期限。
5. tuning 周期性上报进度，调度器可增减 GPU。达到目标精度或最大迭代数后，返回优化 prompt，并更新 Bank。

对每个按 SLO 升序排列的作业 i：
  A_i = 1
  while T_warm_i(A_i) > T_slo_i and A_i <= R_l:
      A_i += 1
  若能按时完成：从模型 l 的 warm pool 扣除 A_i
  否则：先检查能否等待未来释放；仍不行才扩 warm pool

4. 具体例子：一个紧急 Vicuna 文本转 SQL 作业

假设请求使用 Vicuna-7B，用户 prompt 是“把自然语言优雅且正确地转换为 SQL”，目标是在 90 秒内达到指定执行准确率。Bank 有 3000 个候选。系统不会让 3000 个 prompt 各跑一次 tuning，而是先用激活特征构建的代表层找到“结构化查询生成”簇，再用 16 个验证样本计算簇内 score，选出一个曾在近似任务上收敛较快的 prompt。

此时 Vicuna warm pool 只有 2 张空闲 GPU。预测显示 1 张需 115 秒，2 张需 72 秒，因此 warm-pool 算法直接分配 2 张。如果另一个 deadline 为 4 分钟的 Vicuna 作业也在队列中，系统不会马上从 cold pool 再拉 GPU；它用已运行作业的预计释放时刻判断后者能否延迟启动。若 72 秒后接手这 2 张卡仍可在 4 分钟内完成，就等待而非付出模型加载成本。这个例子体现两层优化的分工：Bank 减少要跑多少轮，scheduler 决定每轮何时、用多少卡执行。

5. 实验与证据

主实验在 32 张 NVIDIA A100-80GB 上，以 GPT2-Base、GPT2-Large、Vicuna-7B 同时接收请求，对比 INFless 与 ElasticFlow；还测试 LLaMA-30B、DeepSeek-R1-Distill-Qwen-7B，并在 96 GPU 集群做重载实验。评价指标是 SLO violation 和按 AWS p4de.24xlarge 价格估算的总成本。

综合结果中，论文概括为相对 INFless 将 SLO 违约降低最高 4.0 倍、成本降低最高 1.6 倍；相对 ElasticFlow 分别为 7.9 倍和 4.5 倍。常规负载下违约率相对 INFless 下降 15%–25%，相对 ElasticFlow 下降 48%–51%。消融把 prompt reuse 或 runtime reuse 去掉后，违约率明显上升：前者说明好初始化确实缩短收敛，后者说明热运行时不是可有可无的工程优化。窗口从 20 秒增到 120 秒时，warm GPU 保留更久，违约率从约 14%降到 9%，但成本上升；Bank 从 500 增到 3000 时，违约率从 21%降到 12%，边际收益逐渐变小。

6. 贡献落在哪里，边界又在哪里

Prompt 检索和 autoscaling 单独看都不新。PromptTuner 的贡献在于把“语义初始化会改变收敛迭代数”写进 SLO 调度：算法侧的 Prompt Bank 与系统侧的 warm/cold pool 围绕同一个目标工作，DelaySchedulable 再利用 Bank 省下的时间，避免无依据地扩容。

边界：Bank 的价值依赖候选覆盖和任务相似性；16 个标注样本仍是额外要求。score 只近似实际 tuning 后的收益，不能保证命中全局最优。warm pool 假设热门模型会被多个作业复用，长尾模型多时预热成本会反噬。完成时间上界依赖迭代耗时与剩余迭代预测，流量或收敛曲线剧烈变化会使决策失准。论文的云成本模型还把 cold GPU 视为可被其他服务利用，不等于真实云租户能瞬时免租。

合集关系：它和 SchedMate 都让调度器理解作业语义，但 PromptTuner 针对 LPT 的 prompt 相似性与模型运行时，SchedMate 面向通用训练作业的代码、日志和历史记录；与 DDiT 的逐步弹性类似，它也动态分 GPU，但资源单位是 prompt-tuning job，而不是视频扩散 step。

7. 把两个资源算法再走一遍

温池算法处理“现成资源怎么分”。它先按期限升序排列同一模型的等待作业，每个作业从一张卡起，逐张增加，直到预测上界不超过期限。预测上界采用剩余最大迭代数乘以给定卡数下的最大单轮时间，所以它有意偏保守。若温池里没有足够卡让当前作业按时完成，该作业本轮分配记为零，剩余卡继续用于后续可满足的作业，而不是让一个注定违约的紧急作业占住所有资源。这里的优先级和准入是两回事：期限短者先评估，但只有可满足者才真正扣卡。

冷池算法处理“是否值得扩温池”。它维护每个模型温池中第 k 张卡最早可用的时间表。DelaySchedulable 会枚举未来可获得的卡数，把等待时间、届时执行时间与作业剩余期限相加。只要存在一个未来时点仍能完成，就把这些卡的下一次可用时间更新进去并让作业等待。完全找不到可行未来槽位时，系统才考虑冷启动，而且必须满足“冷启动时间加执行时间仍早于期限”。因此冷池不是无条件容量后备；一个期限短于模型加载时间的请求，即使增加再多 GPU 也不会被算法假装成可满足。

这套设计还能解释为什么 Prompt Bank 与 scheduler 不是两个拼装模块。Bank 让一些作业用更少迭代提前释放温卡，时间表里会出现更早的可用槽位；DelaySchedulable 随即利用这些槽位让后续宽松作业等待，从而少做冷启动。反过来，Bank 查询本身也要占计算资源，调度器会比较查询预计收益和资源竞争：若期限已很紧、查询时间可能吃掉收益，就沿用用户初始 prompt 直接执行。论文的端到端收益来自这种双向联动，而不是简单把检索命中率和 GPU 利用率相加。

8. Prompt Bank 的正确与错误命中

第一层使用代表 prompt 的任务损失选簇，插入时却使用激活特征余弦距离选簇，这两个指标承担不同职责。查询要找到对当前目标数据有效的 prompt，所以必须在验证样本上算损失；插入只需要维护相近表示的局部结构，用特征距离更便宜。若把查询也完全改成 embedding 最近邻，语义措辞相似却输出格式不同的任务可能被误配。若把插入也改成对所有历史任务算验证损失，则每次更新都要取得任务数据，成本和隐私要求都会上升。

最坏情况下，命中的簇不包含全局最佳 prompt，两层搜索会牺牲一部分潜在收敛速度。论文用与 Ideal 的相对迭代到准确率表现检查这点，而不是宣称索引等价于穷举。生产中还应把基础模型版本、tokenizer 和 prompt 模板纳入候选兼容性：同一句 prompt 在 GPT2 与 Vicuna 上的激活及效果并不相同。论文的实现按模型维护运行时温池，但 Prompt Bank 的跨模型迁移边界没有被充分展开，这是部署时需要额外加的保护条件。

9. 前置知识：LPT、ITA、SLO 与弹性加速

论文所说的 LPT 是 LLM Prompt Tuning：基础模型权重不动，系统把一段可调 prompt 接到每个输入前面，对任务数据做前向计算，比较生成输出与目标答案，反向传播“文本梯度”并更新 prompt。一次请求的输入不只是自然语言指令，还包含模型名、训练与评估数据、batch size、优化算法、最大迭代数、目标准确率和 deadline；输出则是达到终止条件后的优化 prompt。论文采用的算法实现来自 TextBox，但系统调度并不依赖某一种 prompt 优化器，Prefix-tuning、P-Tuning、梯度法、零阶法等只要能提供进度和不同 GPU 数下的吞吐画像，都能进入相同调度接口。

ITA 是 Iterations-To-Accuracy，即从某个初始 prompt 出发，达到指定准确率需要多少次迭代；ITA 越小，收敛越快。Prompt Bank 的目标直接是降低 ITA，而不是只找语言表面最像的句子。SLO 则规定作业必须在最大时限内满足终止条件；终止条件同时包含准确率目标和最大迭代数，因此“运行结束”和“在期限内得到合格 prompt”不是同一件事。调度器预测的最坏执行时间是剩余最大迭代数乘以给定 GPU 数下的最大单轮耗时，再加可能的冷启动开销。由于多 GPU 每轮结束后要同步 prompt 梯度，作业具有训练式 barrier；但通信仅占总时间的 0.4%–0.5%，扩卡仍近似线性提速，这使 deadline 驱动的弹性分配有实际意义。

论文先用五种模型上的任务平均分说明 prompt tuning 的价值：GPT-3.5 从 few-shot 的 29.8 提到 70.1，GPT-4 从 37.0 提到 75.8，Vicuna-7B 从 14.9 提到 80.5，LLaMA-30B 从 20.8 提到 84.1，Qwen7B-R1 从 34.1 提到 85.7。这里的重点不是宣称一个统一准确率，而是说明同一服务会收到大量值得执行的调优请求，系统问题不能用“直接 few-shot 即可”回避。

10. 工作负载画像与 baseline 为什么系统性失败

作者在 8 张 A100-80GB 上分析 GPT2-Base、GPT2-Large、Vicuna-7B 与 SAMSUM。一次作业的运行时设置占总延迟 23%–33%，权重加载占 8%–14%，真正执行占 59%–63%；把容器、框架初始化和 GPU runtime 合并计算，GPU allocation 占端到端时间 37%–41%。来自匿名 64-GPU 集群的两小时 Vicuna-7B trace 又显示，每分钟请求峰值达到均值的 5 倍。最后，20 个随机初始 prompt 的 ITA 分布中，中位数和最大值分别可比最小值高 1.7–4.5 倍。三组证据对应 PromptTuner 的三个必要条件：流量需要弹性，启动状态需要复用，收敛路径需要语义复用。

训练调度器 ElasticFlow 预先租下固定 GPU 池，再在作业之间弹性分配。它能做多 GPU 同步，却把突发流量之外的空闲卡也计入成本；论文实测平均集群利用率只有 56%。推理系统 INFless 使用 serverless instance 和按模型预热，避开固定集群，却以单 GPU instance 为扩缩单位，本来不支持 LPT 的同步多 GPU。作者为公平比较给 INFless 补了 Memcached 同步与 Prompt Bank，仍发现多 instance 初始化平均占作业端到端延迟 11%，最坏达 50%。两个 baseline 在不同最大 GPU 上的 SLO violation 均可高到 70%。因此失败不是实现不够精细：ElasticFlow 缺少跨服务可归还的冷池，INFless 缺少同一作业的同时多卡准入，两者都不建模初始 prompt 对迭代数的影响。

这里还要区分“资源充足”与“资源及时可用”。一个作业最终能拿到四张卡，不代表四个独立实例会在同一时刻完成初始化；同步作业会被最晚到位的实例卡住。Warm Allocator 把所需卡作为一组原子地从同模型温池分出，正是为了消除这种尾部等待。Table 8 中去掉它后，违约率从 12.4%升到 27.8%，虽然成本反而从 22.9 美元降到 20.9 美元，说明少花钱的原因是许多作业根本没及时拿到足够资源，而非调度更有效。

11. Prompt Bank 公式逐项拆解与维护规则

对候选 prompt p，论文定义 score(p)=1/|D_eval| · Σ L(concat(p,d_i^in),d_i^tgt)。D_eval 是少量标注评估样本集合，默认取 16 个；d_i^in 是第 i 个输入，d_i^tgt 是对应目标输出；concat 把候选 prompt 放到输入之前；L 是模型输出相对于目标的任务损失。这个 score 在零次 tuning 的条件下计算，越小表示把该 prompt 当初始化更可能快速进入正确区域。它不是 embedding 相似度，也不是完整 ITA：前者只表达激活空间邻近，后者必须真的运行多轮调优，在线成本太大。

若 Bank 有 C 个候选、分为 K 个近似等大的簇，第一层为 K 个 medoid 各算一次 score，找到分数最低的簇；第二层只为该簇约 C/K 个候选算 score。查询次数是 f(K)=K+C/K。把 K 当连续变量，f'(K)=1-C/K²，令导数为零可得 K=√C，最低查询量为 2√C。例如 C=2500 时，穷举需 2500 次评估，K=50 时只需约 50+50=100 次。真实簇不完全均匀，论文实现仍固定 K=50，测得 GPT2-Base、GPT2-Large、Vicuna-7B 的平均选择延迟分别为 5.3、6.1、9.2 秒；K=1 近似穷举时分别约需 2.5、2.9、4.5 小时。

离线构建时，每个模型都要重新抽取候选 prompt 的 activation feature，用 cosine distance 做 K-medoid；Manhattan 和 Euclidean 在作者数据上因不同特征维度数值尺度失衡而不收敛。每个模型的 Bank 存储小于 5GB，两层结构约五分钟可建成。在线插入新优化 prompt 时，只比较它与各 medoid 的 cosine distance，放入最近簇；总量超过 3000 后，从该簇删除离代表最近的一个候选，以去除冗余、保留簇内多样性。三层 K-medoid 在 Vicuna-7B 上出现不收敛且构建可达数十分钟，所以论文明确选择两层，而非把层数越多视为越好。

12. 两个分配算法的变量、伪代码与手算

调度符号中，R_l 是模型 l 的可用温卡数，A_i 是给作业 i 的卡数，T_i^slo 是从当前时刻看作业剩余的期限，T_i^warm(a) 是用 a 张已预热卡时的保守完成时间，T_l^cold 是把冷卡变成模型 l 温卡的开销；E_l 是该模型温池各卡最早可用时间的有序表，B_l 是本轮要从冷池加入的卡数。温池算法每 50 毫秒运行一次，按 T_i^slo 升序处理；每个作业从一张卡开始递增，直到预测可达标。若即使耗尽当前温池也不可达标，则把 A_i 置零，让剩余卡继续服务其他可满足作业，避免 earliest-deadline-first 把全部资源沉没在注定违约的请求上。

设同模型等待作业甲还剩 100 秒，T甲^warm(1)=150、T甲^warm(2)=82；作业乙还剩 220 秒，单卡需 110 秒；温池有三张空闲卡。算法先处理甲：一张不满足，升到两张后 82≤100，因此扣两张。乙用剩余一张 110≤220，也能启动。若甲两张仍需 115 秒，算法不会把三张卡全部押给甲；只有三张的预测满足时才扣三张，否则甲本轮为零，乙仍可获得一张。这一细节把“deadline 更短”与“可行作业优先”结合起来。

冷池算法先调用 DelaySchedulable。仍以乙为例，假设它尚未启动，甲占用两张卡并预计 82 秒后释放；乙单卡执行 110 秒，则等待甲释放再完成共需 82+110=192 秒，小于 220 秒，函数把相应 GPU 的下一可用时间更新为 192 秒并返回真，不扩温池。若乙只剩 170 秒，等待方案不成立；假设冷启动为 20 秒，单卡执行 110 秒，则 20+110=130≤170，算法从冷池加入一张。若期限只剩 15 秒，连冷启动都超过期限，扩再多卡也不应伪装成可满足。论文 Algorithm 2 的排版条件存在不易读之处，但文字定义清楚：逐卡增加，前提是把冷启动和执行时间共同纳入 SLO 可行性。

13. 端到端例子：从提交到 Bank 回写

考虑一个 Vicuna-7B 对话摘要请求。用户提交 SAMSUM 数据路径、初始指令、batch size、优化器、目标 BLEU 46、最大迭代数和 90 秒 deadline。系统先判断 Prompt Bank 的查询是否落在预算内：预算固定为 SLO 的 20%，这里是 18 秒，而 Vicuna-7B 实测平均查询 9.2 秒，可以执行。Bank 在 50 个代表 prompt 上各用 16 个评估样本算 score，选出最低分簇，再在簇内复算，返回最小 score 候选。若请求期限短到 Bank 预计成本超过 20%预算，就直接使用用户 prompt；这一保护来自论文观察到 Bank 相对 induction 初始化带来 1.2–4.7 倍加速，因此把最多五分之一期限用于检索，至少仍让最低观察收益覆盖查询成本。

作业进入 Vicuna pending queue 后，温池算法用剩余迭代上界和单轮最大耗时评估 1、2、3……张卡。分配到足够温卡后，多个 Knative function instance 通过 LambdaML 建立的 Memcached 通道同步 prompt 梯度，每个 instance 使用 IP 与端口互联，连接额外开销最多 2 秒；因为传输的是很小的 prompt 梯度，通信相对执行可忽略。系统每 50 毫秒重算分配，作业收敛变快时会提前释放卡，未收敛且期限收紧时也可能加卡。

达到 BLEU 46 或最大迭代数后，RPC 返回优化 prompt，GPU 回到 Vicuna 温池，而不是立刻卸载模型。若一分钟内来了新 Vicuna 作业，它可直接复用 PyTorch/CUDA runtime 和权重；超过空闲窗口才退入共享冷池。新 prompt 同时抽取 activation feature 并插入 Bank，超过 3000 上限则触发簇内替换。于是一次请求既消费历史资产，也把结果变成未来请求的资产；但回写不能跨 tokenizer 或模型版本无条件复用，生产实现应把模型版本编码进 Bank key。

14. 实验口径、主要数字与消融证据

主 testbed 每台服务器有 8 张 A100-80GB、200Gbps HDR InfiniBand、64 核 Intel Xeon 8369B、256GB 内存与 PCIe III，最多使用四台服务器。工作负载用 GPT2-Base、GPT2-Large、Vicuna-7B 在 12 个数据集上构造：每个数据集切成十个互斥 partition，因此每个模型有 120 个任务；目标准确率取 20 个随机初始 prompt 所达准确率的平均值。三段 20 分钟真实 trace 分别构成 low、medium、high load：三个模型的请求数为 41/55/42、77/71/65、99/85/76。SLO 定义为原 trace duration 乘紧迫系数 S，再加资源分配开销；S 越小，期限越紧。成本按 AWS p4de.24xlarge 价格与 Elastic Cache 的 GB/hour 估算。

Figure 7 的逐点结果比最高倍数更容易判断：low/medium/high load 下 PromptTuner 的违约率为 7%/12%/12%，INFless 为 22%/37%/37%，ElasticFlow 为 55%/60%/63%；成本分别为 16/23/27、25/30/39、72/75/78 美元。中等负载、S=0.5/1.0/1.5 时，PromptTuner 违约率为 20%/12%/7%，INFless 为 60%/37%/19%，ElasticFlow 为 85%/60%/46%；成本为 28/23/25、45/30/30、71/75/83 美元。流量从 medium 增到 high 时 PromptTuner 违约没有明显增加，作者解释为更高重复模型密度提供了更多 runtime reuse，而不是系统对负载不敏感。

更重模型和规模实验也给出绝对值：LLaMA-30B 每个 replica 用四张 GPU 做 tensor parallel，PromptTuner/INFless/ElasticFlow 的违约率为 28.4%/38.9%/82.3%，成本为 38.8/46.4/69.4 美元；32,768 最大序列的 Qwen7B-R1 同样四卡 replica，在 32 GPU 集群上为 23.1%/36.2%/74.9%与 30.7/42.8/70.1 美元；96-GPU 扩展实验为 25.4%/57.1%/78.2%与 57.2/65.9/99.1 美元，调度平均/最大开销仅 13/67 毫秒。

组件消融说明收益来源。去 prompt reuse 后，在 S=0.5/1.0/1.5 的违约率升到 45%/28%/21%，去 runtime reuse 后升到 67%/40%/26%；prompt reuse 单独贡献 13%–23%违约下降和 30%–40%成本节省。Table 8 的完整 scheduler 为 12.4%违约、22.9 美元；去 Warm Allocator 为 27.8%、20.9 美元，去 DelaySchedulable 为 15.6%、26.6 美元，去 latency budget 为 16.3%、23.2 美元。温池空闲窗口从 20 秒增到 120 秒时违约从 14%降到 9%，但成本上升，60 秒被选为折中；Bank 从 500 增到 3000 时违约约从 21%降到 12%，在低于 2000 后违约与成本均明显恶化。

15. 部署限制和复现清单

第一类局限来自质量代理。16 个评估样本上的平均 loss 只与真实 ITA 相关，不能证明命中全局最优；论文用 120 个任务验证多数 score candidate 达到 ideal candidate 90%以上的相对 ITA，并相对 induction 在 GPT2-Base、GPT2-Large、Vicuna-7B 上至少加速 1.81、1.38、1.28 倍，但这仍是所选模型和任务的经验结果。候选 Bank 还依赖公开 prompt 的覆盖、多样性与授权；数据漂移、模型升级和 tokenizer 变化后，旧 activation 聚类可能失效。安全部署需要按模型版本隔离 Bank，记录候选来源，定期用新任务重建，并对无可靠评估样本的请求跳过检索。

第二类局限来自系统假设。论文把共享冷池视为不服务 LPT 时可供数据中心其他业务使用，因此不计持续占用成本；普通公有云租户未必能按毫秒取还 GPU，也未必能把空闲租约瞬时变成零成本。完成时间上界依赖最大单轮耗时、剩余迭代数和近线性扩卡，如果不同 batch、跨机网络拥塞或优化器改变使画像失效，DelaySchedulable 可能做错。温池按模型划分也偏向热门模型；长尾模型多、权重大时，预热空间与驱逐策略会成为新的缓存问题。

复现时应依次固定六组事实：一是精确记录模型、数据 partition、目标准确率、最大迭代和初始 prompt；二是分别 profile 每种模型在不同 GPU 数下的最大单轮耗时和冷启动时间；三是按论文用 activation cosine、K-medoid、K=50、16 个评估样本构建每模型 Bank，并记录 5.3/6.1/9.2 秒只是原 testbed 的参考值；四是在 Knative/LambdaML 中验证多 instance 同步、最多 2 秒连接开销与 50 毫秒调度周期；五是同时报告 SLO violation 和计价边界明确的 GPU/缓存成本；六是至少复现去 Bank、去 runtime reuse、去 Warm Allocator、去 DelaySchedulable、去 latency budget，以及 20–120 秒窗口和 500–3000 Bank size 扫描。只有这些消融都保留，才能把算法缩短、启动缩短与额外预热成本分开归因。

16. 十二类任务如何覆盖 Prompt Bank 的有效性

论文没有只用一种摘要任务验证候选复用，而是把任务分成对话、问答、文本生成、摘要和故事生成。对话数据集 DA 的目标是 BLEU 54；问答包含 PC 的 BLEU 19、COQAQG 的 BLEU 51、QUORA 的 BLEU 21；文本生成包含 WIKIBIO 的 ROUGE 70、WIKIP 的 ROUGE 22；摘要包含 CNNDM 的 BLEU 34、SAMSUM 的 BLEU 46、XSUM 的 BLEU 40；故事生成包含 CMV 的 ROUGE 26、WP 的 ROUGE 20、ROC 的 ROUGE 25。每个数据集再切成十个互不重叠的子集，三个主要模型各形成一百二十个任务。这样的设置迫使 Bank 同时处理输出格式、语义目标和数据分布差异，而不只是记住一个固定指令。

目标准确率不是作者随意挑一个容易达到的点，而是对每项任务随机取二十个 Bank prompt，测得平均准确率并把它设为终止目标。这样既保证用于敏感性分析的不同初始化大多有机会达到目标，也让 ITA 差异体现“到同一质量门槛需多少轮”。Ideal baseline 也不是对全部三千候选真的穷举完整 ITA：作者先用 score 缩到二十个，再在其中以实际 ITA 选最佳，因此它是计算可承受的近似上界。Induction baseline 则让模型根据示例自己生成初始 prompt，强模型和简单任务更占优势；Bank 对 GPT2-Base 的相对收益最大，恰好说明历史高质量 prompt 能补弱模型自行归纳指令的不足。

Figure 9 的正确读法是先看 score 对 Ideal：大多数候选的相对 ITA 超过九成，说明只用十六条验证样本的零调优 loss 可以作为实际收敛速度的近似；再看 score 对 Induction：三个模型最低加速依次为一点八一、一点三八、一点二八倍，说明检索不是仅仅缩短查找，而是找到更好的起点。Figure 10 再把质量与开销分开：增加簇数没有造成显著 ITA 损失，却把小时级穷举降到秒级。三条证据共同支撑 Bank，缺少任一条都只能说明“检索快”，不能说明“快且选得对”。

17. 运行时状态机与最容易实现错的边界

每个作业至少经历提交、候选选择、等待、运行、完成五种状态。提交后首先检查 Bank 时间预算；只有通过后才在同一批已分配 GPU 上顺序执行 Bank 与 LPT，避免另起一套运行时。进入等待队列后，温池分配与冷池扩容都按剩余期限而非原始期限重算。运行中调度器每五十毫秒接收最新吞吐和分配开销画像，更新完成时间上界；完成后先释放卡回同模型温池，再更新 Bank，温卡空闲满六十秒才退冷。若把 Bank 当成与 LPT 并行的独立作业、把 GPU 完成时间表按原始 deadline 静态计算，或完成后立即卸载权重，都会破坏论文设计中的复用链条。

同时分配也不能被实现成逐卡异步启动。LPT 每轮末尾有同步梯度交换，三张卡中两张先到而第三张仍在初始化时，前两张只能闲等。Warm Allocator 应先判断整组卡是否可行，再一次性把同一作业的实例标为占用；不满足则本轮分配零。DelaySchedulable 的 GPU 时间表同样不是简单记录“现在空闲几张”，而要记录未来第 k 张卡何时可用，并在接受一个延迟方案后把所用卡的下一次可用时刻整体向后推进，否则多个等待作业会重复预订同一批未来资源。

成本核算还需把温池卡、正在运行卡、缓存存储与连接通道分开。论文允许冷池 GPU 被数据中心其他服务占用，所以只把 LPT 实际使用与温池保留计入成本；若复现环境是固定租下整台服务器，就必须同时给出论文口径和实际租约口径，不能把闲置冷卡当免费后再宣称同等成本优势。相同地，六十秒窗口是在论文 trace 上的折中，不是常数真理。热门模型复用间隔短时可延长窗口，长尾模型多时应缩短；无论怎样调，都要同时画违约率与成本曲线，而不能只优化其中一个指标。