Catalyst：自动 LLM 训练基础设施的工程拆解

愿景是一个完全集成的端到端 LLM 训练平台。让用户轻松训练和部署随时间改进的小模型。通过平台路由推理、构建数据集、训练部署模型。之后继续收集推理以做后续改进。

简单的 pitch，但构建比预期难。

数据层：三种摄入路径

客户通过三种方式把数据送入 Catalyst：

通过 proxy 路由推理调用
上传包含别处收集的推理的文件
通过 OTEL-compatible Catalyst Tracing SDK 发送 agent traces

需要归一化这些样本，使其成为 pipeline 的有效输入。处理不同格式问题：Anthropic 把 base64 图像放在 source 对象内、OpenAI 用 image_url、Gemini API 的混乱。所有这些在摄入时处理。

数据预处理 pipeline 负责清洗数据集：丢弃空消息和过长样本、从训练集中移除评估集数据点。最近添加 HALO 处理更大的 agentic 数据集，因为 traces 特别难分析。寻找可能被忽视的语义模式，如模型拒绝或格式错误。某些情况下做 rejection sampling，为训练的模型设定更高门槛。

超参数：意见ated 决策树

训练模型的人知道有一大堆超参数可以调整。这曾是最难做对的事情之一，尤其因为所有配置错误带来的 niche 错误。

点击"train"时，系统启动对数据集的分析步骤。看输入/输出字符统计、语义内容、模态和其他特征。基于这个，复杂的决策树决定启用哪些参数来优化训练运行的速度和准确性。调整 sample packing、parallelisms、学习率、epoch 长度、batch size 和梯度累积、vision towers 和哪些参数冻结等。

之上是 recipe 层——curated 起点。Recipe 给出基础模型、judge 模型、LoRA topology、FSDP 版本、学习率和评估节奏。加上数据集统计，微调 recipe 确保适当设置。

GPU 调度：自有集群 + Serverless 回退

训练 job 需要 GPU，需要决定用哪些、从哪获取。

自有 GPU 集群作为主要训练池，提供可预测性和控制层。需要额外容量时回退到 serverless GPU 提供商，否则客户在高峰负载时会经历长队列。需要平衡：集群每 GPU hour 更便宜更可靠，但不想在使用低谷浪费容量。如果总在 serverless 训练会吸收更高 GPU 成本和更高错误率。

构建了优先级阶梯调度器，检查每个提供商的可用性，容量到位时秒级分配 job。

由于跨多个提供商运行，容器不能绑定到单一目标。容器是 provider-agnostic，接受 job config 作为 CLI 参数和 payload，通过 signed webhook 报告回来。训练容器中没有编排逻辑。

Rollover via Checkpointing

Serverless 提供商施加时间限制，大多数 cap sandbox 运行时长。24 小时常见，而大型模型的 serious fine-tune 需要更久。

解决方案：通过 checkpointing 的 rollover。运行时定期上传完全可恢复的 checkpoint 到持久存储。sandbox 被抢占前约一小时，控制平面从最新 checkpoint 启动新训练 job 并停止旧的。客户视角是一个连续 job。基础设施视角，该 job 可能在其生命周期中存在于很多地方。

这也作为出错时的恢复机制。运行时崩溃、NaN loss、节点故障等，job 从最后一个可恢复 checkpoint 被 pickup 并继续。

运行时栈：从 Megatron 到自定义 PyTorch

几个月后选定训练运行时栈并承诺。当时没意识到，这后来证明是最 consequential 的决策之一。

开始时用 Megatron-Bridge 和 Megatron-Core 生态。纸面上显然：Megatron 有最大模型最成熟的并行故事。Kernels 经过 battle tested，血统包括领域中最雄心勃勃的一些训练运行。很快开始撞硬墙：添加新模型是噩梦，训练速度本身相当慢，尤其 sub-100B 模型上。也无法受益于更大的 kernel 生态，因为大多数 patches 需要大型工程迁移。需要能更快迭代和升级的东西。

迁移到自定义框架，基于 PyTorch 和 Hugging Face Trainer。Patch 自己的并行和 kernel 实现，受益于快速移动的前沿。缺点是并行变得复杂得多，尤其长上下文或大参数模型。创建自己的并行交互网络，使用 Ring/Ulysses Attention、FSDP2 和自定义 NCCL 操作。

这也意味着对添加 kernels 有更细粒度控制。集成 ScatterMoE/SonicMoE 到 MoE 模型。训练速度提升一个数量级，到某些 Megatron Core loop 本身的训练迭代步更快。

评估：不用 Validation Loss

训练 job 运行时，想检查模型是否在学习正确的东西。决定远离单独的 validation losses。它预测模型在 held-out 数据上的 next-token 预测准确率，但不翻译为实际任务表现。

见过很多运行 loss curve 看起来漂亮但模型 broken。原因各异：chat-template mismatch、tokenizer 在特殊 token 上 regression、sample packing bug corrupt position embeddings。Loss curve 不 catch 任何这些，因为 loss 在与产生问题行为完全相同的条件下计算。

方法：在训练中途对实际任务运行评估，对抗实际模型。在设定间隔，用 in-flight weights 启动 vLLM 推理容器，对 held-out 评估数据集生成响应，然后用 rubric 对每个响应运行 LLM judge。此外，从客户数据集样本生成 rubric。这样 judge 知道任务长什么样、好答案是什么。每个样本获得数字分数和书面评估。

这给出实际性能的 curve，轻松看到模型何时开始改进、在哪 plateau、是否开始 overfitting。

这也是进行超参数 sweep 的正确方式。比较两个 config 的 loss curve 告诉你哪个在 next-token 预测上收敛更快。比较 rubric scores 告诉你哪个实际任务做得更好。这些不总是相同答案，当它们不一致时，rubric 是对的。

用相同分数选择部署哪个 checkpoint。关心任务做得最好的那个。也允许跑更长的运行来看何时精确通过学习和 overfitting 之间的线。之后可以一键部署最佳模型。

托管：训练到部署无缝

训练运行完成时，最终 checkpoint 以推理引擎可直接加载的格式存储。没有导出步骤，没有"我在哪托管这个"步骤。Checkpoint 是 Hugging Face 目录，包含运行推理所需的一切。

训练模型自动在账户中注册为可部署 artifact。选择部署时，托管 worker 拉取 checkpoint 并启动推理服务器。几分钟内模型有稳定 endpoint，准备 serve 请求。

回到起点，在新模型上收集推理。准备好 v2 时从输出构建下一个数据集。这个 loop 有效因为拥有整个过程。可以观察推理、构建数据集、训练评估模型、部署它，无需离开 Catalyst。

结果

最初这些是月长 engagement：收集数据、评估、训练、部署。现在有时能够同日迭代和 ship 模型。对客户来说训练也便宜得多。

如果今天在 frontier model 上构建应用，你放弃所有控制。 stuck 于该模型收的任何费用、API 交付的任何延迟。响应质量是该模型碰巧在你的任务上有多好。

用 Catalyst 不需要忍受这个。通过 proxy 路由流量，继续使用今天的模型。收集一些流量后，只需几次点击就获得新模型。构建数据集、配置运行、训练模型、针对任务评估、选择最佳 checkpoint 并部署。结果是一个更小、更快、更便宜的模型，做你的任务和 frontier 模型一样好。通常更好，因为它训练在你实际做什么而不是整个互联网上。