让企业拥有自己的模型！PyTRIO定义TaaS新范式：大模型训练进入API时代

最近，越来越多应用层 AI 企业走上了一条相似的路线：用自己积累的专业知识和业务经验，训练自己的模型。

就在 8 月，法律 AI 公司 Harvey 发布了其首个经过后训练的开放权重模型 Tenet。它以 Kimi K3 为底座，在法律智能体基准 LAB 上的全通过率达到 19.7%，明显高于 Fable 5（11.5%）和 GPT-5.6 Sol（2.5%）等闭源模型。单项任务成本为 5.92 美元，也低于上述两款闭源模型。

在 LAB 留出任务上，Harvey Tenet 以约 5.92 美元的单任务成本取得 19.7% 的全通过率，效果高于 Fable 5 和 GPT-5.6 Sol，成本则明显更低。

这也让一部分网友感叹：「连 OpenAI 投资的公司也开始自己训练模型了？」

Mercor 联合创始人兼 CEO Brendan Foody，将 Harvey 描述为应用层 AI 企业「掌握自主智能」的先驱。

Brendan Foody 认为，企业未来可能先针对会计、销售、设计等具体领域后训练开放模型，再为重要客户提供进一步定制。

闭源模型 API 降低了企业使用 AI 的门槛，但如果核心能力长期依赖外部模型，产品也会受到服务条款、模型更新、价格和供给稳定性的影响。企业既难以决定模型如何迭代，也很难把积累的数据和业务判断真正沉淀为自己的资产。随着 AI 逐渐进入核心业务，拥有并持续训练自己的模型，正在成为企业保持自主性的重要能力。

但与此同时，模型训练正在变得越来越困难。随着开放模型从百亿参数走向千亿参数，训练所需的算力和工程复杂度也在同步上升。

这让企业与 AI 实验室面临相似的压力，没有专门 Infra 团队的机构，很难独立搭建和维护大规模训练集群；即使已经配备 Infra 团队，持续适配不同模型与算力、维护训练环境和调度资源，也需要投入大量人力。

开放模型降低了获取权重的门槛，却没有同步降低训练模型的门槛。

现在，这道门槛有了一种新的解法。

情感机器推出大模型训练平台 ——PyTRIO，把训练所需的算力和底层工程封装进 Training API。用户在本地控制数据、Loss、Reward 和训练逻辑，需要 GPU 完成的计算通过 API 发送至云端；环境配置、分布式训练和集群维护等底层工作由平台处理。

• PyTRIO 官网：https://pytrio.com

• 官方文档：https://docs.pytrio.com

由此，训练能力也成为一种可以通过 API 按需获取的资源。PyTRIO 所呈现的，正是一种 TaaS（Training as a Service）范式：像调用推理 API 一样，调用大模型训练能力。

对企业而言，这意味着模型不再只是从外部租用的通用能力，也可以用自身数据持续塑造模型能力，并将模型真正掌握在自己手中。

从专业数据到专属模型，

自主训练成为新的护城河

一家 AI 公司刚刚起步时，最紧迫的问题通常是验证产品有没有真实需求，也就是找到 PMF（Product-Market Fit，产品市场契合）。

在市场反馈尚不明确的阶段，团队需要尽快做出产品、接触用户并调整方向。此时直接调用前沿模型 API 往往更加高效，不仅省去了自主训练的成本和工程投入，也方便团队根据产品需求随时更换底座模型。

而在 PMF 逐渐清晰之后，产品思路也开始变得不一样。

随着用户增加，产品开始积累真实的数据，团队会逐渐形成一套自己的判断标准。此时，继续调用通用模型，很难让这些积累转化为产品的核心能力。

后训练为这些积累提供了去处。行业知识、业务经验，甚至团队对产品的「品味」，都可以由此进入模型。应用界面和工作流很容易被模仿，而长期积累的高质量数据，以及这些数据塑造出的模型行为，却很难被竞争对手复刻。

而且，企业未来要掌握的，往往不只一个模型。法务、客服、销售、研发面对的数据、任务目标和评价标准并不相同，企业可能围绕不同部门、场景乃至重要客户，训练一组规模与能力各异的专属模型，并持续用新数据更新它们。

最近有不少案例验证了这条路线的可行性。

Cursor 的做法很有代表性。Composer 2 以 Kimi K2.5 为底座，训练过程中既使用了持续预训练和大规模强化学习，也吸收了 Cursor 在真实产品中积累的反馈。

效果很快体现在模型表现上。根据 Fireworks AI 公布的数据，Composer 2 在多项编程基准上进入第一梯队，推理成本却只有同类前沿编程模型的约 1/6 至 1/10。那些原本散落在产品使用过程中的编程任务、用户反馈和评价标准，也开始直接参与模型能力的塑造。

在 CursorBench 上，Composer 2 保持前沿模型水平的同时，单任务推理成本明显更低。图源：Cursor

另一方面，专业判断的积累也能转化成产品的核心竞争力。

桥水基金与 Thinking Machines Lab 选取六类金融信息筛选任务，以 Qwen3-235B 为基础展开训练，并让金融专家参与数据标注。

结果很直接：模型准确率达到 84.7%，高于测试中表现最好的前沿通用模型（78.2%）。换算成错误数量，降幅为 29.8%；单任务推理成本也降低了 13.8 倍。

经过专家数据训练的 Qwen3-235B，在六类金融信息筛选任务上取得 84.7% 的平均准确率，超过前沿模型，同时推理成本约为后者的 1/13.8。图源：Thinking Machines Lab、Bridgewater AIA Labs

对于 AI 实验室，自主训练的价值又有所不同。

随着研究重点从小模型微调扩展到大模型强化学习、蒸馏和 Agentic RL，实验设想越来越依赖大规模训练条件。研究人员可以设计 Loss、Reward 和训练循环，实际推进时却经常受到 CUDA 环境、并行策略与集群调度等一系列限制，不同项目反复适配环境或者排队使用算力，也会拉长实验周期。

掌握自主训练能力，意味着实验室可以主动决定模型如何学习，并在更大的开放模型上快速验证新方法。研究人员由此获得更充分的实验空间，更多精力也能回到算法设计和结果分析上，让研究设想更快转化为可以验证的模型能力。

无论是将专业数据沉淀为企业的模型护城河，还是把新方法变成可验证的模型能力，两类需求最终都指向同一个问题：如何更「省心」地实现自主训练？

PyTRIO：让大模型训练成为可调用的能力

PyTRIO 给出的思路，是将训练过程拆成用户控制的算法层和平台负责的计算层。

用户在本地 Python 环境中安装 PyTRIO SDK，继续编写数据处理、Loss、Reward 和训练循环；每轮训练所需的 batch 通过 API 发送到云端，由 GPU 执行 forward_backward、optim_step 和 sample 等计算。分布式训练、环境配置和算力调度，则由 PyTRIO 负责，平台同时提供权重保存与断点续训能力。

PyTRIO 通过一组可编程的 Training API 开放训练、采样、评估与权重保存等能力。

这意味着，用户保留了对算法与实验过程的控制权，但不必直接操作承载计算的 GPU 集群。只要具备可联网的 Python 环境，MacBook、轻薄本、CPU 工作站乃至树莓派、机器人都能发起训练任务。设备只负责组织实验，真正繁重的计算都在远端完成。

与直接租用 GPU 相比，PyTRIO 省去了集群环境搭建和 Infra 运维；相较于只能使用固定数据格式、算法和参数的「黑盒微调」平台，数据的组织方式、算法和训练逻辑仍由用户决定。它兼顾了托管平台的便利性和直接租用 GPU 的算法灵活性。

这种可编程、按需获取的训练服务，构成了 PyTRIO 对 TaaS 的一种具体定义。

这套模式已经在多种后训练场景中得到实践。

13.30 元，大约一杯奶茶的价格。你敢相信，这也可以是一次多轮搜索强化学习实验的训练账单吗？

在 PyTRIO 公开的 Search-R1 实验中，开发者使用 Qwen3.5-4B 和知乎搜索后端，让模型通过强化学习掌握多轮搜索能力：模型需要反复提出查询、读取搜索结果，再根据获得的信息完成回答。这类需要与外部工具持续交互的任务，正是 Agentic RL 的典型场景。

整个实验从一台联网的 CPU 设备发起。训练 50 步后，模型在 70 道问题上的 Macro EM（宏平均精确匹配率）由 28.57% 升至 45.71%，格式正确率也从 58.57% 提高到 94.29%。用一杯奶茶的训练预算，也可以完整跑通一条多轮搜索强化学习链路。

在固定 70 道题的评测中，模型训练至第 50 步时，Macro EM 由 28.57% 升至 45.71%，格式正确率由 58.57% 升至 94.29%。

如果说 Search-R1 展示了 Agent 与外部环境交互的训练方式，Medical OPD 关注的则是另一个常见难题：让模型获得专业能力时，怎样尽量避免原有的通用能力退化。

研究者首先对 Qwen3.5-4B 进行普通医疗 SFT。模型的 MedQA-zh 成绩由 72.17% 提高到 79%，非医疗 C-Eval 成绩却从 81.67% 降至 69.33%。医疗知识学进去了，通用能力也出现了明显退化。

随后，研究者采用 SAR-OPD 方案：先让医疗模型指导学生模型学习专业能力，再以原始基础模型作为「锚点」，帮助它恢复通用能力。经过这一过程，模型在 MedQA-zh 和非医疗 C-Eval 上的成绩分别达到 84.33% 和 84.67%，两项指标都超过了最初的 Qwen3.5-4B。

这组实验展示了 Training API 可以如何承载多阶段的蒸馏流程，让研究者在提升专业能力的同时，继续寻找保留通用能力的方法。

普通医疗 SFT 提升了 MedQA-zh 成绩，却导致非医疗 C-Eval 成绩下降；经过 SAR-OPD 训练，两项指标最终分别达到 84.33% 和 84.67%。

图片也可以进入同一套训练流程。Vision GRPO 为模型接入视觉输入，再通过强化学习训练它解答几何题。Qwen3.5-4B 在 GeoQA 固定 100 道测试题上的准确率从 71% 升至 87%，格式正确率则从 75% 升至 91%。

进一步拆解结果会发现，这次提升主要来自回答格式的改善：在格式已经正确的样本中，模型的条件准确率仅从 94.7% 提高到 95.6%。研究者由此可以继续分析 Reward 具体改变了哪些模型行为，而不只是得到一个最终分数。

经过 Vision GRPO 训练，Qwen3.5-4B 在 GeoQA 固定 100 道题上的准确率和格式正确率均提高 16 个百分点。

从多轮搜索、医疗蒸馏到视觉强化学习，三组实验采用了不同的数据、Reward 和训练流程，却都可以通过同一套 Training API 组织起来。

不过，同一套接口之下，不同任务消耗算力的节奏并不相同。

以 Search-R1 为例，一次 Rollout 包含模型生成、调用搜索工具和等待结果的完整过程，其中并非每个环节都在持续占用 GPU 进行密集计算。如果按照 GPU 使用时长计费，等待外部环境返回结果的时间也可能产生费用。

针对这类长 Rollout、数据量相对较小的强化学习实验，PyTRIO 的共享集群按照 Token 按需计费，团队只需为实际处理的 Token 付费。研究者可以用较低成本尝试不同的 Reward 与训练路径，也不必提前租用整块 GPU。

SFT 和数据合成等任务通常具有更连续、稳定的计算负载。对于这类训练，以及有长期使用需求的企业团队，专属 Training API 按照 GPU 时计费，并提供相对固定的训练资源。

PyTRIO 控制台可按模型和 API Key 查看 Token 消耗、请求数、存储与花销。

两种模式分别对应弹性的实验需求与稳定的生产负载。团队可以根据任务中生成、等待和密集计算所占的比例选择计费方式，让算力成本更贴合任务实际的运行方式。

不止于 Training API！

连接算力、工具链与持续学习

Training API 统一的不仅是训练入口，也包括开发者使用不同底层算力的方式。

一种芯片背后，往往跟着一整套软件生态。

例如英伟达与昇腾使用不同的软件栈、算子库和通信方案，迁移训练任务时，环境、算子和分布式方案往往都要重新适配，底层工程几乎需要重做一遍。

PyTRIO 试图让更换芯片这个操作更加「丝滑」。开发者可以通过同一套 Training API 组织训练，无论任务运行在英伟达还是昇腾算力上，相应的环境配置和适配工作都由平台完成，上层训练代码也能尽量保持一致。

目前，PyTRIO 已经完成对昇腾 950PR、910B 等机型的适配，并能够支撑大规模训练任务。

对国产算力而言，这相当于降低了真实训练任务的迁移门槛。算法团队不必先花费大量精力熟悉新的底层工具，已有实验也更容易转移到国产芯片上，迁移工作的重点可以回到模型效果和算力效率本身。

而从整个 AI 研发流程来看，PyTRIO 也是情感机器完善工具版图的重要一步。

此前推出的 SwanLab 已经覆盖实验观测与管理，帮助研究人员完成训练可视化、实验记录、版本对比和团队协作；PyTRIO 继续进入训练执行环节。二者由此串联起实验发起、执行、观测与复盘等研发工作。

SwanLab 通过训练可视化、实验记录与多实验对比，帮助团队持续追踪和分析模型训练过程。

在情感机器设想的持续学习路径中，应用与用户交互产生的数据可以重新进入评测和训练流程。哪些回答有效或者模型在哪里失败，这些都可能成为下一轮优化的信号。数据经过筛选和处理后推动模型更新，更新后的模型再回到应用中接受新的反馈。

如果把自动化再向前推进，AI 还可以参与提出研究假设、修改实验配置、启动训练并分析结果，再据此规划下一轮尝试。这类由 AI 参与设计和推进实验的流程，正是 AutoResearch 所指向的方向。

随着训练能力 API 化的实现，这些设想正在逐步演进。从芯片适配到实验管理，再到持续学习与 AutoResearch，PyTRIO 所指向的，是让 Training API 逐步成为连接应用数据、研究逻辑与算力资源的一层基础设施。

从调用智能，到掌控智能

如今，开放权重让越来越多不同规模的团队第一次拥有了塑造模型的机会。然而，从下载模型到真正完成训练，中间仍隔着一段不小的距离。

对于企业和实验室而言，这也是从「0」到「1」的距离。再珍贵的行业数据、再有潜力的研究设想，如果无法进入训练流程，最终仍只能停留在原地。

PyTRIO 所做的，正是尽可能缩短这段距离。

对 AI 初创公司，Training API 让产品数据有机会转化为差异化能力；转型期企业可以进一步沉淀行业知识与业务经验；AI 实验室则能减少底层工程对研究效率的牵制。

更长远看，企业要掌握的可能不是某一个万能模型，而是一组面向不同部门、业务场景和客户需求、能够持续更新的专属模型。想让这些模型稳定地训练和迭代，训练能力就不能永远停留在一次性的工程项目上。

如果说推理 API 让更多团队得以调用智能，那么 TaaS（Training as a Service）指向的，正是让塑造智能也成为一种可以调用的能力。PyTRIO 希望通过 Training API，让更多团队离真正掌控自己的模型更近一步。

当模型真正被团队所掌控，智能的边界也将由此开拓。

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]