Modal 发布开源训练服务器 Spindle，兼容 Tinker API 并按 GPU 计费
Introducing our Training API
Modal 发布开源、Tinker 兼容的训练服务器 Spindle，可在 Modal 工作区内部署，按 GPU 时间而非 token 计费，支持全参数训练和多 LoRA。
官方给出与 Tinker 的对比成本数据和多客户端共享 GPU 的利用率分析，读者可据此评估自托管训练 API 的性价比。
Thinking Machines 的 Tinker 改变了人们进行后训练的方式。你在笔记本电脑上用普通 Python 编写训练循环，Tinker 则在其 GPU 上执行前向和反向传播。我们是它的忠实粉丝，与我们合作的许多团队也是如此。
然而，随着这些团队扩大规模，他们不断提出同样的两个问题：
- 当你运行数十个实验时，按 token 计费会变得很昂贵。
- 你只能使用服务商决定支持的模型和功能。
我们认为，一个好的 API 值得拥有不止一种实现。今天我们发布 Spindle，这是一个开源、兼容 Tinker 的训练服务器，可运行在你的 Modal 工作区中。因为服务器归你所有，你可以自定义其中的任何内容，并且你按 GPU 时间付费，而不是按 token 付费。我们的默认配置经过调优，开箱即可最大化 GPU 利用率，我们还计划持续推出优化，进一步推高性能价格比。
只需一条命令即可部署服务器：
然后，针对该服务器运行你的训练脚本。
你的团队何时应该使用 Spindle？
Modal 现在覆盖了整个后训练技术栈，从按需集群到为你运行训练循环的库。你该从何处开始？
如果你不想编写训练循环，可以使用我们昨天发布的训练库 Modal Dojo。只需带上模型和数据集，Dojo 会处理其余一切。如果你想掌控从集群开始的一切，Modal 提供原始原语：按需多节点集群 和 用于 RL rollout 的沙箱。
Spindle 介于两者之间。你使用自己的损失函数、奖励和环境编写训练循环，Spindle 负责其下的分布式训练。它支持全参数训练和在众多开源模型上进行多 LoRA 训练。对于运行大量实验的团队，Spindle 支持数百个并发训练运行，性能相近，且与闭源 API 相比成本显著降低。
深入底层
Spindle 兼容 Tinker 的 API 由一个分布式控制平面支撑，该平面处理请求和会话管理，并基于 Modal Functions 实现容器自动扩缩容。
Spindle 的后端包含一组解耦的训练器引擎和推理池。请注意，它们不必运行在相同的加速器或精度上！我们已撰文介绍如何在这些情况下保持 RL 稳定，并利用固有的成本节省和更高的 GPU 可用性。
我们的整个系统构建在 Modal 原语之上：Modal Clusters 使大型模型的传入请求能够在动态可用的 RDMA 连接节点上调度，而无需预留集群；Modal Volumes 提供快速、持久的检查点保存；Modal Servers 提供快速推理层。在构建多 LoRA 训练的过程中，我们还向 Miles 和 SGLang 上游贡献了多项改进，并将继续投资于开源生态系统。
设计一个高性能的多租户训练系统需要克服各种挑战，我们必须仔细思考。这带来了许多令人兴奋的工作，如今支撑着 Spindle 的核心组件，包括多客户端批调度、异步检查点、增量权重同步，以及用于多 LoRA 和 KV 感知请求路由的自定义推理路由器。你可以在这里阅读更多关于我们设计的内容。
Spindle 实战
在过去几个月里，我们在数学推理、智能体编程和搜索智能体方面运行了大量 RL 工作负载。以下是几个例子。
多轮搜索智能体的后训练
我们复现了 Jasper Lu 的用 GRPO 训练搜索智能体，该工作训练 gpt-oss-20b 在 SEC 文件语料上执行多轮智能体搜索，使用关键词匹配、grep 和读取工具。任务是整理出一组能够回答查询的文档。
我们拉取了他的开源代码，只把 BASE_URL 和 API_KEY 改为指向我们的 Spindle 部署，然后运行 uv run。就这样。
对比两个 Spindle 种子、我们在 Tinker 上对同一代码的重新运行，以及作者发布的训练结果，我们看到 Spindle 在所有更新步上与两者的奖励差异都在 0.01 以内。
随后我们在相同的 32 条留出查询上对第 16、20 和 24 次更新的检查点进行评分，观察到了类似的一致性：
将 Spindle 扩展到适合你的工作负载
如果你通过闭源 API 进行训练，你就只能受限于提供商决定支持的模型和功能。当你需要他们没有的东西时，除了等待或寻找变通方案，你几乎无能为力。
由于 Spindle 是开源的，并在你的 Modal 工作区中运行，你可以按需进行修改，而我们的配置层让这件事变得极其简单。例如，当我们想在长时程软件任务上训练 Qwen3.5-9B 时，当时我们只有默认的 16k 上下文配置。通过两处简单的修改，我们在配置中将其提升到 256k：
这次运行在可抢占 GPU 上训练了大约 3 天，每当机器被回收时都会自动从检查点恢复。它还让 8 个客户端通过 multi-LoRA 共享同一批 GPU，这意味着你可以用一次运行的成本和时间完成 8 次长上下文消融实验。更多内容见下文。
复合成本节省
智能体 RL 大部分时间都花在生成 rollout 上，这既需要较长的解码时间，也需要执行延迟。当一个客户端等待长时间的多轮 rollout 时，其训练器 GPU 大多处于闲置状态。根据工作负载的不同，我们观察到，为单个客户端提供服务的训练器（即使运行异步 RL）忙碌时间也不到一半。
在完全异步 RL 中，应对训练器利用率不足的标准做法是扩展推理计算，并允许略微偏离策略的 rollout 始终供给训练器。Multi-LoRA 与这种方法完美契合：在固定的训练器规模下，你可以为单次运行扩展推理，在固定的推理预算下增加运行数量，或者两者兼做！
Spindle 的 multi-LoRA 后端让许多客户端共享同一个训练器，从而利用训练器的空闲时间。当一个客户端等待 rollout 时，训练器会运行另一个客户端的训练步骤。当多个客户端共享同一批 GPU 时，每次运行的成本只是使用专用计算时的一小部分。
为了量化这一点，考虑同一个简单的 GRPO 作业（在 DAPO-math 上训练 27B 模型），让一到八个客户端共享同一个训练器和推理 GPU（训练使用 4×H200，推理使用 12×B200）。
观察训练器的利用率，我们可以看到成本收益来自哪里：
只有一个客户端时，训练器有很长的空闲时间。当四个客户端交错执行训练步骤时，它保持约 88% 的忙碌状态。增加客户端会降低每次运行的成本，代价是每次运行完成得稍慢一些。请注意，这里存在一个限制：超过四个客户端后，我们观察到训练器发生抖动，这会显著降低每个客户端的吞吐量。
同样的效果也能扩展到智能体工作负载上。以下是我们用 Spindle 运行的一些工作负载，从单轮数学到长时程智能体，每一项都与在 Tinker 上运行相同脚本的情况进行了对比：
| 工作负载 | 配置 | 客户端 | $/100 万输出 token | 相比 Tinker 的价格降幅 |
|---|---|---|---|---|
| DAPO-math，单轮（Qwen3.8-27B） | Tinker | 1 | $9.77 | — |
| Spindle：4×H200 训练，12×B200 推理 | 2 | $3.57 | −63% | |
| Spindle：8×H200 训练，8×H200 推理 | 8 | $1.99 | −80% | |
| 搜索智能体，最多 40 轮（gpt-oss-20b） | Tinker | 1 | $5.06 | — |
| Spindle：8×H200 训练，16×H200 推理 | 4 | $4.06 | −20% | |
| Spindle：8×H200 训练，16×H200 推理 | 8 | $3.80 | −25% | |
| SWE-Gym，256K 上下文（Qwen3.8-27B） | Tinker | — | $10.79（预估） | — |
| Spindle：8×B200 训练，8×B200 推理 | 4 | $6.17 | −43% | |
| Spindle：8×B200 训练，12×B200 推理 | 8 | $5.82 | −46% |
为 GPU 付费而非按 token 付费，意味着你从它们身上榨取的每一点额外吞吐量都会降低你的每 token 价格。这些实验得出的更广泛结论是，如果你让 GPU 保持忙碌，例如同时运行多个实验，Spindle 提供的性价比远优于闭源 API。
立即试用
要开始使用，请按照设置说明在你的 Modal 工作区中部署 Spindle。
Spindle 是开源的，我们希望与使用它的人一起构建它。如果你遇到 bug，或需要我们还尚不支持的模型或功能，请提交 issue。对于新模型配置或现有模型的性能调优，你可以直接提交 PR。如果要做更大的上游贡献，请到我们的 Slack 与我们聊聊，这样我们可以讨论你的想法！
我们仍处于 beta 阶段，正在加紧开发性能优化、改进的自动扩缩容、新功能和训练配方等更多内容。敬请期待，祝你 Spindling 愉快！🍽️
来源：Modal 官方工程博客 · modal.com