让企业拥有自己的模型！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，让更多团队离真正掌控自己的模型更近一步。

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