Papers

待读论文 · 自包含完整解释

Titan：基础模型微调不是普通 DLT 的缩小版

微调时长估计、任务合并、资源分配和 pipeline switch

论文：Titan: A Scheduler for Foundation Model Fine-tuning Workloads

本文目录 · 17 节
  1. Titan 利用了哪些微调特征
  2. 问题背景
  3. 调度模型与完整流程
  4. 关键机制
  5. 实验设置与准确数字
  6. 方法贡献
  7. 局限与适用边界
  8. 前置概念：为什么微调负载值得单独设计调度器
  9. 时间估计器：把离线测量变成在线吞吐查询
  10. 资源分配 MILP：目标函数究竟在优化什么
  11. 任务合并：语义可合并不等于调度上应合并
  12. Pipeline Switch：一次参数换入换出的时间线
  13. 端到端例子：三个请求如何经过 Titan
  14. 实验拆解：38% 与 12% 分别说明什么
  15. 反事实分析：每个组件拿掉后会发生什么
  16. 生产控制面：论文之外仍需补齐的系统契约
  17. 复现清单与结论

Titan 利用了哪些微调特征

Foundation model 结构固定，多个下游任务可能共享参数，训练又普遍使用 pipeline parallelism。Titan 据此把运行时间估计、任务合并和 context switch 一起纳入 fine-tuning 调度。

问题背景

普通 DLT 调度器往往假设作业可轻量 checkpoint、可做 data-parallel elasticity，或者要在线 profiling 后才知道扩展效率。Fine-tuning 有另一组特征：模型结构固定，最佳并行 plan 可复用；单次任务相对短，但模型参数大，切换成本相对突出；多个语义相近下游数据集可能合并训练。论文指出，一个有效的并行执行 plan 可把 throughput 提高最多 10 倍，但搜索通常要几分钟；若模型结构、batch size 和输入 shape 相同，就可以缓存结果（PDF 第 1 页）。

调度模型与完整流程

Titan 是事件驱动的非抢占调度器，在作业提交或完成时求解资源分配。它把待运行作业 ji 在分配 a 张 GPU 时的单位时间进度记为 Ti,a，用二元变量 xi,a 表示是否采用该分配，MILP 在 GPU 总量约束下最大化所有作业的单位时间总进度。允许的 GPU 数集合是 {1, 2, 4m}（PDF 第 2 页，式 1-4）。完整流程如下：

  1. 用户提交 fine-tuning dataset。系统根据数据规模确定 batch-size 范围和 epoch 数。
  2. Time Estimator 查询离线 LUT。键包括 GPU 数 a、gradient accumulation steps s、global batch size m、冻结层数 l、是否 mixed precision、是否 gradient checkpoint；值是对应 throughput。未见配置用线性插值估计。系统同时得到运行时预测和该资源量下的较优训练配置（PDF 第 3 页）。
  3. Task Merger 从 dataset card 中提取任务类别、对象类别等关键词，用语义相似度判断哪些数据集可能安全合并。它不是“能合就全合”：系统枚举候选 merged jobs，把单任务和 merged task 一起放入扩展 MILP，并用 (1 + |merged set|) / 2 对合并任务进度加权，避免一个超长 merged job 拉高平均 JCT（PDF 第 3-4 页，式 5-11）。
  4. MILP 为独立作业或 merged job 选择 GPU 数。论文报告 320-job 问题在 1 vCPU 上平均求解 0.005 秒、最大 0.16 秒（PDF 第 2 页）。
  5. 当作业完成、需要切换模型参数时，Pipeline Switch 让旧作业的参数 GPU-to-CPU 保存、新作业 CPU-to-GPU 加载，与不同 pipeline stage 上仍在进行的 forward/backward 计算重叠。新作业按反方向从最后一台机器向第一台机器加载，尽量隐藏切换路径（PDF 第 4 页，图 2）。
  6. 下一次提交或完成事件重新求解；主模型不依赖频繁抢占，因此调度灵活性主要来自资源分配、合并与切换优化，而不是在途作业的 lease 重排。

关键机制

1. 固定结构 LUT。 Titan 不试图拟合一个跨模型通用性能公式，而是承认 fine-tuning service 围绕少量 foundation model 反复出现。用 64 GPU 穷举训练配置建表需要 37 小时，但之后每个请求可直接查询（PDF 第 3 页）。这是把离线成本换成在线速度和可预测性。

2. Task Merger。 多个语义相近任务共享同一套模型参数，可以减少重复模型实例和 GPU 消耗。表 2 的例子很直观：两个各 20 分钟的任务，合并后平均 JCT 为 25 分钟，SRTF 顺序执行为 30 分钟；但 5 分钟与 100 分钟任务合并后是 102 分钟，SRTF 平均仅 55 分钟。因此合并必须进入调度优化，而不是作为固定预处理（PDF 第 3 页，表 2）。

3. Pipeline Switch。 ViT-Large/16 的实测切换开销在 8、4、2 GPU 分配下，naive 分别是 46、29、22 秒，pipeline switch 降为 6、5、7 秒（PDF 第 4 页，图 3）。它利用 pipeline 已经存在的 stage 切分来隐藏参数搬运，而不是另造一套 checkpoint 格式。

4. Merge-aware MILP。 同一原始任务不能既独立运行又出现在 merged job 中，不同 merged set 也不能重叠；资源约束同时覆盖两类候选。该模型把“训练系统能否合并”与“此时合并是否有利于 JCT”分开处理。

实验设置与准确数字

方法贡献

Titan 针对 foundation model 的固定结构、任务适应关系和 pipeline parallelism，分别设计了离线 LUT/plan cache、task merge 和模型切换通道。调度器由此能在计划生成、资源选择与运行时切换中利用 workload structure，而不是沿用通用深度学习作业模型。

局限与适用边界

前置概念：为什么微调负载值得单独设计调度器

基础模型微调与从头训练都使用反向传播和优化器，集群行为却不同。模型结构通常由平台预先选定，用户改变的是数据集、冻结层数、批量大小和训练轮数，因此同一个模型的性能测量可以跨请求复用。微调任务往往只持续几分钟到数小时，加载数 GB 甚至数十 GB 参数、建立分布式进程组和恢复优化器状态仍要几十秒。预训练持续数周时，这点固定开销可以忽略；二十分钟的微调则会把它直接计入作业完成时间。Titan 依赖的是模型集合更稳定、单次作业更短、模型切换更频繁，而不是简单假定微调模型更小。

还要区分数据并行与流水线并行。数据并行让每张 GPU 保存完整模型并处理不同样本，需要在反向传播后同步梯度；流水线并行则把连续网络层拆到不同设备，微批次像流水线产品一样依次经过各个 stage。Titan 的 Pipeline Switch 依赖后者：当旧模型最后几个微批次仍在后部 stage 计算时，前部 stage 已经空闲，可以把旧参数移出并预载下一任务参数。若系统只做数据并行、每张卡都必须同时持有完整模型，这个重叠窗口就小得多。

时间估计器：把离线测量变成在线吞吐查询

对作业 i 和候选 GPU 数 a，调度器真正需要的是吞吐 T(i,a)，进而估计剩余时长 R(i,a)=N_i/T(i,a)，其中 N_i 是尚未处理的训练样本或迭代数。Titan 不只用 GPU 数索引 LUT，还把梯度累积步数、全局批量、冻结层数、混合精度和梯度检查点作为键。原因是同样四张卡，较大的批量能提高矩阵乘利用率，却可能触发显存不足；冻结更多层会减少反向计算与优化器状态；检查点能省显存，但会在反向阶段重新计算激活。忽略这些维度，所谓“四卡吞吐”就不是稳定常量。

一次查询可以理解为两层选择。内层在给定 GPU 数下枚举可行训练配置，过滤显存超限项，并挑出吞吐最高者；外层把各 GPU 数对应的最优吞吐交给 MILP。若某一维没有精确测点，论文采用线性插值。例如 LUT 中全局批量 128 和 256 的吞吐分别为 900 与 1300 样本每秒，查询批量 192 时可估为 1100。这个例子只解释插值方法，不是论文实测值。插值默认性能曲线在邻近点间足够平滑，跨越显存临界点、通信算法切换点或整数微批次边界时可能失真，因此工程实现应同时返回置信度，并在误差持续偏大时补测。

建表成本也必须计入系统经济账。论文的 64 GPU、37 小时相当于 2368 GPU-hours；只有当同一模型服务足够多请求时，摊销才合理。模型权重、CUDA、通信库、GPU 型号、输入分辨率或编译策略变化都会使旧表可能失效。实用版本需要给 LUT 键加入环境版本，记录实测与插值来源，并用在线作业的实际吞吐校准。Titan 论文证明了缓存型估计器的机会，但没有完成这种生命周期管理。

资源分配 MILP：目标函数究竟在优化什么

设候选作业集合为 J，允许分配集合为 A，二元变量 x(i,a) 表示作业 i 是否以 a 张 GPU 运行。基本约束有两类：每个作业最多选择一种配置，即 sum_a x(i,a) <= 1；所有被选配置消耗的 GPU 不超过集群容量 G，即 sum_i sum_a a*x(i,a) <= G。目标为最大化 sum_i sum_a T(i,a)*x(i,a)，也就是当前时刻整个集群的总训练进度，而不是直接最小化每个作业的完成时间。

这一区别很重要。假设作业甲用一张卡吞吐 100、两张卡 190，作业乙用一张卡吞吐 80、两张卡 100，集群有两张卡。总进度目标会给甲、乙各一张卡，吞吐合计 180；若把两卡都给甲则为 190，实际又会偏向甲，具体结果取决于是否允许未调度作业以及候选集合的权重。若甲剩余工作极少、乙等待已久，纯吞吐仍未显式表达公平或尾部延迟。Titan 借由事件驱动重算和合并权重改善平均 JCT，但它并未提供 deadline 保证、租户公平或 starvation 的形式化边界。

允许的 GPU 数被限制在 {1,2,4m} 一类离散集合，而非从一到集群总卡数逐个枚举，这既符合常见并行拓扑，也显著缩小变量规模。320 作业在单 vCPU 上平均 0.005 秒、最坏 0.16 秒的求解数字说明，这个受限 MILP 可放在提交与完成事件的控制路径上。不过，求解快不等于执行代价为零：分配变化若需要重新建进程组、搬运参数或改变批量，就必须由运行时落实。论文采用非抢占调度，避免了频繁调整在途作业的复杂性，也因此牺牲了对突发高优任务的即时响应。

任务合并：语义可合并不等于调度上应合并

Task Merger 先从 dataset card 提取任务类型和对象类别等关键词，再以语义相似度产生候选集合。这里存在两个独立问题：第一，两个数据集能否在一个训练目标中共同优化，属于机器学习兼容性；第二，此刻把它们合成一个作业能否改善集群指标，属于调度收益。Titan 的贡献是没有把第一步的“可能兼容”误当成第二步的“必然有益”，而是把独立任务与合并候选同时交给优化器。

设合并集合 M 含多个原始任务。约束必须保证每个原始任务最多出现一次：它不能既作为独立作业运行，又被某个合并作业包含，也不能同时属于两个相交的合并集合。合并进度按 (1+|M|)/2 加权，直觉是完成一个合并模型能同时服务多个请求，但权重又小于简单乘以任务数，以免优化器只因“覆盖任务多”就偏爱巨型合并。这个启发式在两个任务时权重为 1.5，在五个任务时为 3；它体现收益折扣，却不是由准确率或 JCT 最优性推导出的理论系数。

表 2 给出了最容易误判的案例。两个单独训练都需 20 分钟的任务，串行 SRTF 完成于第 20 和第 40 分钟，平均 JCT 为 30 分钟；若合并后 25 分钟完成，两个请求都在第 25 分钟拿到结果，平均 JCT 为 25 分钟。反过来，一个 5 分钟和一个 100 分钟任务，SRTF 的完成时刻为 5、105，平均 55 分钟；若合并作业要 102 分钟，短任务被迫等到第 102 分钟，平均也为 102。即使合并节省总 GPU 时间，它仍可能严重伤害短任务，所以调度器必须同时看任务长度与到达状态。

数据语义还带来系统论文未充分量化的风险：标签空间冲突、采样比例失衡、负迁移、隐私边界和不同用户对超参数的要求。论文允许用户关闭合并，并提出若质量不达标再独立恢复训练，但没有测量恢复概率和额外成本。生产实现不能只比较 dataset card 文本，还需要明确的授权策略、合并后逐任务验证集、最低质量阈值以及失败回滚。否则节省的 GPU 时间可能被重新训练抵消。

Pipeline Switch：一次参数换入换出的时间线

朴素切换通常包含三个串行阶段：等待旧任务所有微批次完成，把旧参数或 checkpoint 从 GPU 移到 CPU，再把新任务参数从 CPU 载入每个 stage，最后开始新任务。Titan 观察到流水线排空不是所有设备同时结束。旧任务的最后一个微批次离开 stage 1 后，stage 1 已不再参与旧任务计算，却还要等待它通过 stage 2、stage 3 等后续设备。系统可以立即在 stage 1 上启动旧参数移出；相似地，各 stage 一空闲就开始释放。

新任务采用与旧任务排空相反的装载方向。若新任务从最后一个 stage 向前预载，那么当旧任务的反向传播逐步离开后部设备时，新参数搬运可占用已经释放的链路和显存；待前部 stage 也完成切换，新任务所需的后部参数早已就位。这里的关键不是单次 PCIe 拷贝变快，而是把通信埋进旧任务仍有用的计算窗口。它与算子融合的区别在于：总搬运字节基本不变，关键路径长度变短。

ViT-Large/16 的数字显示这种重叠对短作业很有价值。8、4、2 GPU 时，朴素切换分别需 46、29、22 秒，Pipeline Switch 降到 6、5、7 秒，约减少 40、24、15 秒。GPU 越多并不保证绝对开销越低，因为参数分片、机器间链路和流水线深度共同决定关键路径。评估也没有覆盖网络拥塞、CPU 内存不足或多个切换同时发生的情况。复现时应分别记录计算、GPU 到 CPU、CPU 到 GPU、进程组重建和空闲气泡，而不能只报一个端到端秒数。

端到端例子：三个请求如何经过 Titan

考虑一个八卡服务，同时到达图像分类任务甲、乙和目标检测任务丙。甲、乙的数据卡显示对象类别相近，系统生成独立甲、独立乙、合并甲乙以及独立丙四类候选。时间估计器查询 LUT，得到每个候选在一、二、四、八码下的可行配置和吞吐；假设合并甲乙在四卡上能共享模型训练，而丙在四卡上的扩展效率较高。MILP 可能选择“合并甲乙四卡 + 丙四卡”，同时加入互斥约束，禁止独立甲乙再占资源。

当合并作业先结束时，甲乙同时获得模型。调度器在完成事件重算等待队列，并选择下一任务丁。若丁使用相同 ViT 结构但不同任务头，运行时按流水线 stage 排空顺序保存旧状态、反向预载丁的参数；LUT 已给出丁在当前卡数上的批量和检查点配置，因此不用现场做几分钟 profiling。若合并后的甲在独立验证集上不达标，系统需要把甲重新提交为恢复任务。这个失败分支说明调度决策的真实完成条件应是“模型达到用户质量阈值”，而不是“训练进程退出”。

再考虑丙突然变慢。Titan 会在下一事件使用预估吞吐继续优化，但论文没有描述运行中预测误差如何反馈，也不抢占丙来调整资源。因此实际部署应监控观测吞吐与 LUT 的偏差；超过阈值时重新估计剩余工作，并把异常配置标为待复测。这个补充并非论文已实现功能，而是从其离线估计假设推导出的必要控制环。

实验拆解：38% 与 12% 分别说明什么

评估用生产 trace 的到达特征驱动模拟器，而不是在真实 Titan 原型上回放。trace 来自 88 节点、704 张 V100、三个月共 18471 个作业；模拟器则缩到 16 节点、64 GPU，只运行 ViT-Large/16 的 320 个合成作业。这样可以控制变量并探索调度策略，但结果同时依赖时间缩放、作业抽样、性能 LUT 和模拟执行模型。论文数字证明设计在该模型下有效，不能直接当作生产集群的无条件加速承诺。

表 3 要分两种指标解释。完整 Titan 的平均 JCT 为 1.04 小时，相比 SRTF 的 1.68 小时下降约 38%，说明多数请求更早完成；makespan 从 33.09 降到 29.01 小时，下降约 12%，说明整个批次的总收尾时间也缩短。二者同时改善，意味着结果不只是把等待从短作业转嫁给最后一个长作业。但去掉 Task Merger 时 JCT 为 1.23、makespan 为 33.11，说明合并主要同时贡献资源效率；去掉 Pipeline Switch 时 JCT 为 1.16、makespan 仍为 29.01，说明切换优化主要影响作业等待，对总工作量的贡献较小。

workload density 实验显示，密度从 0.5 到 2 时，约 18% 至 20% 作业相对 SRTF 至少改善 10%，同时有 6% 至 11% 作业恶化至少 10%。这提醒我们平均值掩盖个体代价：在最密负载下，显著恶化比例达到 11%。论文没有给这些受损作业的租户、长度和合并状态分布，也没有报告 95 或 99 分位 JCT。若服务有交互式用户，尾延迟和最坏减速应与平均 JCT 同列为验收指标。

反事实分析：每个组件拿掉后会发生什么

如果拿掉 LUT，调度器并非完全不能工作，而是只能采用用户声明的 GPU 数、固定经验配置或为每个请求在线 profiling。第一种方式会把低扩展效率作业分到过多 GPU，第二种方式无法适应冻结层和批量差异，第三种方式则让几分钟的搜索成本直接落到短微调任务上。由此可见，LUT 的主要作用不只是提高预测精度，而是把配置搜索从请求关键路径移到服务建设阶段。它适合请求数量大、模型种类少的平台；若每位用户都上传不同架构，复用率太低，在线模型或轻量采样可能更合算。

如果保留 LUT 而拿掉 Task Merger，系统仍能给每个作业选择较好的并行配置，也能通过 Pipeline Switch 缩短相邻作业空档，但同一基础模型针对相近数据的重复反向传播不会消失。表 3 中无合并版本的 makespan 甚至略高于 SRTF，说明仅优化瞬时吞吐未必减少全部工作量。合并之所以能降低 makespan，是因为它改变了要执行的训练集合，不只是改变执行顺序；与此同时，它也把模型质量、数据授权和短任务等待引入调度器，这是收益最大的机制也是风险最高的机制。

如果保留合并而拿掉 Pipeline Switch，总工作量已被减少，所以 makespan 与完整 Titan 同为 29.01 小时；但平均 JCT 从 1.04 上升到 1.16 小时。这个对照说明切换优化更像每次交接时的固定税：它不改变需要训练多少样本，却会在大量短作业间反复累积。若工作负载全是十小时以上长任务，几十秒切换的相对影响会很小；若超过一半作业短于三十分钟，论文 trace 所呈现的场景就会放大收益。因此组件是否必要应由作业时长分布决定，而不能根据一次总吞吐测试决定。

生产控制面：论文之外仍需补齐的系统契约

一个可部署的 Titan 至少需要提交层、估计层、优化层和执行层四个边界。提交层验证数据集元信息、质量目标、租户权限以及是否允许合并；估计层只返回带版本和置信区间的候选配置，不直接占用资源；优化层根据当前队列构造互斥集合并求解，输出不可变的调度计划；执行层负责创建分布式作业、实施参数切换并上报真实进度。把边界写清楚可以避免 MILP 同时承担策略、预测和运行时故障处理，便于在估计错误时单独回退。

故障恢复也是论文留白。Pipeline Switch 中若旧状态只保存了一半而节点失败，系统必须知道哪个 checkpoint 是完整可恢复版本；若合并作业训练完成但只有一个子任务通过验证，另一个子任务应生成恢复请求，已通过者不能被重复计费；若求解器超时，控制面应退回上一次可行计划或简单 SRTF，而不是阻塞全部提交。由于论文报告的求解最坏值只有 0.16 秒，容易忽视这些低概率路径，但生产可用性往往由异常状态而非平均求解时间决定。

多租户计费同样需要明确。合并甲乙后，GPU 时间应按样本量、训练收益还是均分结算？某租户若拒绝合并，是否会被系统降低优先级？论文提到用优先级激励合并，但没有定义公平边界。合理做法是把合并视为用户可审计的服务选项：提前展示可能的等待和费用收益，保证不合并仍获得基础服务等级，并记录候选生成、授权、训练配置和逐任务质量结果。只有当技术收益与治理契约一起成立，Task Merger 才是可持续的资源优化，而非把成本转移给用户。

复现清单与结论

  1. 先固定一个模型、GPU 型号、输入尺寸和软件版本，枚举 GPU 数、批量、梯度累积、冻结层、混合精度和检查点配置；记录吞吐、显存峰值和测量方差，生成带版本的 LUT。
  2. 实现只含独立作业的基本 MILP，用小规模穷举验证约束与目标值一致，再测 320 作业时的求解延迟。不要先加入合并，以免无法定位收益来源。
  3. 加入 dataset card 候选生成和互斥约束，构造“20+20”和“5+100”两个手算案例，确认优化器不会把所有语义相近任务无条件合并。
  4. 在真实流水线引擎中分别测朴素切换与重叠切换，采集每个 stage 的计算和传输时间线，验证减少的是关键路径而非漏计保存工作。
  5. 用同一到达 trace 比较 SRTF、Tiresias、无合并、无切换和完整 Titan，报告平均、分位数、makespan、GPU 利用率、质量失败率与重训成本。

Titan 最值得保留的结论是：调度器应利用服务负载中稳定而可验证的结构。固定模型让性能表可复用，相关下游任务让训练有合并机会，流水线排空让参数搬运可隐藏。它的 38% 平均 JCT 改善来自这些假设共同成立，而不是一个通用 MILP 自动带来的结果。落地前应逐项验证模型复用率、合并质量和切换时间线；任一条件不成立，对应机制就应关闭或重新设计。调度收益只有和逐任务质量一起成立，任务合并才值得启用。