一、一条链跑通之后，问题才刚开始

1.1 从一个模型到一组模型

业务一旦验证成立，需求就会分散：有的团队要做行业微调，有的要接一个轻量模型做实时问答，有的想在自己积累的语料上继续训练。这些需求落在同一条链路上，就会出现节奏不一致——微调每周都要更新，预训练很久才做一次；推理服务要求随时可发布，训练任务则希望环境长期不动。

1.2 三个需要先说清的名词

① 链路分支：从公共底座上分出的一条独立作业路径，有自己的输入、处理方式与产出。

② 公共底座：多个分支共同依赖的部分，包括数据与样本管理、算力调度、身份权限、记录追溯。

③ 环境隔离：让不同分支的依赖、配置、资源互不影响的一种安排。它不是简单的“分开部署”，而是有选择地隔开。

1.3 为什么不能简单地复制一条链

复制看起来最省事，代价却在后面：评测口径各写一套，两个模型的指标没法比较；同一份数据在不同分支里被处理成不同版本，出了问题无法回溯；算力配额各占一块，忙的忙死、闲的闲死。复制解决的是眼前的隔离问题，留下的是长期的不可比与不可查。

二、三条分支：同一个底座上分出三条路

2.1 分支一：预训练与继续训练

这条分支的特点是周期长、算力需求大、对中断极其敏感。一次训练可能持续很长时间，中途失败意味着大量计算作废，因此对检查点保存、断点续训、异常恢复的要求最高。它也是三条分支中变动最少的，环境一旦稳定就不该频繁调整。

2.1.1 这条分支最怕的是中断

长周期任务一旦因为环境变动或资源被回收而中断，损失的往往不只是时间，还有已经跑出的进度。因此这条分支的优先级不在于跑得多快，而在于跑得完整。

2.2 分支二：微调与对齐

这条分支的特点是频次高、规模中等、迭代快。同一个基座模型可能每周都要出一版微调结果，实验多、对比多。它对环境的灵活性要求高，对算力的需求呈脉冲状，需要能快速起停。

2.3 分支三：直接部署与推理服务

这条分支不改变模型本身，只负责把已有模型变成可调用的服务。它的特点是持续运行、对响应敏感、发布频繁。与前两条分支最大的不同在于：它面向外部使用方，一次不稳定的发布影响的是业务，而不只是内部实验。

2.3.1 它面向的是使用方而不是团队内部

内部实验失败，重跑一次即可；对外服务出现波动，影响的是使用方的信任。这条分支的取舍标准因此不同：宁可发布慢一点，也要稳一点。

2.4 三条分支共用什么、各管什么

一句话概括：数据、评测、权限、记录共用；环境、配额、参数、发布节奏各自管。这条界线是全文的骨架，下面两节分别展开。

三、什么必须共用

3.1 数据与样本的版本

三条分支都要用数据，但用法不同：预训练用大规模语料，微调用高质量标注样本，推理服务则可能需要线上样本回流。共用的是“数据的版本管理方式”——同一份语料只有一个版本号，被哪个分支用过、什么时候用的，都能查到。不共用这部分，跨分支的复现就无从谈起。

3.2 评测口径与样本集

这是最容易被各自为政破坏的一环。每个团队按自己的习惯挑样本、定标准，最后得到的分数互相不可比，大模型训练推理全链路平台的横向比较也就无从谈起。共用一套评测口径，意味着至少有一组固定的样本集与判定标准，所有分支的产出都要在它上面过一遍。这样“新模型比旧模型好多少”才是一个有意义的问题。

3.3 身份、权限与记录

谁有权提交训练任务、谁能发布推理服务、谁能查看数据，这些规则如果每个分支各写一套，安全边界就会出现缺口。统一的身份与权限是底线要求，统一的记录则让事后追溯成为可能。

3.4 共用的代价：一处变更影响所有分支

共用不是没有代价的。评测样本集一改，所有分支的历史分数就失去了可比性；权限模型一调，所有分支的作业流程都可能受影响。因此在共用部分做变更，需要比分支内部更谨慎，三步不能省：

① 先公告：把变更内容与影响范围告知所有分支负责人。

② 再并行：新旧两套同时存在一段时间，让各分支自行切换。

③ 最后切换：确认各分支都已就位，再停用旧的一套。

四、什么必须分开

4.1 环境与依赖

三条分支对框架版本、驱动版本、依赖库的要求常常不同。预训练分支可能锁在某个稳定版本上长期不动，微调分支则要跟着新特性走。合在一起的结果是互相牵制：升级影响稳定分支，不升级又妨碍实验。环境隔离是三条分支能并行运转的前提。

4.2 算力配额

预训练要成规模的大块资源并长时间占用，微调要能快速起停的中等规模，推理服务要的是持续在线的稳定份额。三者的资源形态不同，放在一个配额里争夺，结果一定是一方长期饥饿。按分支划分配额，是让每类需求都有基本保障的简单办法。

4.2.1 三种资源形态的差别

大块长占、中块快起快停、小块长期在线，是三种完全不同的使用方式。前者看重连续，中者看重周转，后者看重稳定。把它们放进同一个池子里排队，必然有一方长期等不到。

4.3 配置与参数

训练的超参数、推理的服务配置、微调的数据配比，彼此没有关系。混在一起管理，改一处容易误动另一处。分开存放不只是整洁问题，更是避免误操作的必要安排。

4.4 发布节奏

推理服务的发布有明确的时间窗与回退要求，训练分支的产出则是随时可更新。把两者绑在同一次发布里，等于让业务发布去等待一个不确定的实验结果。分开之后，各自的节奏都能保持。

五、分支之间的三种相互干扰与隔离办法

5.1 依赖干扰：一个升级，全线波动

微调分支为用上新特性升级了依赖，而预训练分支正在长跑，升级后环境变了，任务中途出错。解法是把环境固化到镜像里，每个分支绑定自己的镜像版本，升级只在新镜像上做，长跑任务继续用旧镜像跑完。

5.2 数据干扰：样本回流污染了训练集

线上样本回流是好事，但如果回流的数据直接并入训练集，就可能把一时的偏差带进下一版模型。解法是分层存放：原始语料、清洗后语料、标注样本、回流样本各自独立，合并要有明确的规则和审查环节。

5.2.1 回流样本要单独放一放

回流样本先进入独立的缓冲池，经过一轮人工抽检与清洗之后再考虑并入，比直接混入训练集稳妥。这一步多花的时间，换来的是模型效果的稳定。

5.3 配额干扰：一条分支占满，全平台等

预训练任务一次性占满大部分资源，微调实验排队到第二天才有结果。解法可以分两层：

① 设上限：按分支核定配额，任何一条分支都不能把池子吃满。

② 排位置：可中断的实验任务放在可被抢占的位置，配合断点续训，被中断后能接着跑。

六、分支变多之后的三条管理规矩

当大模型训练推理全链路平台上的分支到五条以上时，靠记忆已经管不住，需要几条简单的规矩：

① 每个分支有一个明确负责人：负责该分支的环境维护、效果把关与发布决定，避免出现“大家都能改、出了问题没人管”。

② 共用部分的变更要公告：数据版本、评测口径、权限模型的调整，提前告知所有分支的负责人，并留出过渡期。

③ 定期回收废弃分支：实验做完的分支如果一直留着，会持续占用配额与环境维护的精力，也容易让后来者误用旧配置。回收时保留记录与产物，删掉环境。

七、天翼云在分支组织上的支撑

7.1 一站式训推与公共底座

大模型训练推理全链路平台把数据处理、训练、微调、部署与推理串在同一套体系内，多个分支可以共用底层的算力调度、身份权限与记录能力，不必各自重建一套。这是“共用”能够落地的前提。

7.2 环境镜像与版本管理

支持以镜像方式固化环境，不同分支绑定各自版本，升级不影响正在运行的任务。对应第五节所说的依赖干扰问题，这是最直接的解法。

7.3 算力调度与配额分层

依托资源池与任务级调度，按分支设定配额，并对可中断任务安排抢占与续跑。三条分支的资源形态不同，这一层决定了它们能否同时跑得动。

7.4 中途保存与异常恢复

长周期训练支持中途保存与恢复，减少长时间运行任务因环境或资源变动而作废的风险。对预训练分支而言，这一项比任何优化都重要。

7.5 安全合规与官方口径

在数据分级、权限隔离与合规方面有相应机制。关于产品的具体能力、适用场景、实践案例与所获认可，均以天翼云官网和官方渠道发布的信息为准，本文不作超出官方口径的描述，建议在方案评估阶段按需核对。

八、科普小结

全链路平台的价值，在只有一个模型时体现为流程顺畅，在有一组模型时体现为结构清楚。界线其实很朴素：数据、评测、权限、记录这几样一旦分开就失去意义，必须共用；环境、配额、参数、发布节奏这几样一旦合并就相互牵制，必须分开。把这八个词想清楚，分支再多也不会乱，平台的规模才算真正立住。