PyTRIO 推出 Training API，让大模型训练像调用推理一样简单
应用层 AI 公司开始自己训练模型
最近，一批应用层 AI 企业不约而同地走上了同一条路：用自己积累的专业知识和业务经验，训练自己的模型。
8 月，法律 AI 公司 Harvey 发布了首个经过后训练的开放权重模型 Tenet。它以 Kimi K3 为底座，在法律智能体基准 LAB 上的全通过率达到 19.7%，明显高于 Fable 5（11.5%）和 GPT-5.6 Sol（2.5%）等闭源模型。单项任务成本为 5.92 美元，也低于上述两款闭源模型。
这一举动让不少网友感叹：“连 OpenAI 投资的公司也开始自己训练模型了？”
Mercor 联合创始人 Brendan Foody 将 Harvey 视为应用层 AI 企业“掌握自主智能”的先驱。他认为，未来企业可能会先针对会计、销售、设计等具体领域对开放模型进行后训练，再为重要客户提供进一步定制。
闭源模型 API 确实降低了使用门槛，但如果核心能力长期依赖外部模型，产品就会受制于服务条款、模型更新、价格波动和供给稳定性。企业既无法决定模型如何迭代，也难以把积累的数据和业务判断沉淀为自身资产。随着 AI 渗透进核心业务，拥有并持续训练自己的模型，正成为保持自主性的关键。
训练门槛高，但解法出现了
问题在于，模型训练正变得越来越难。开放模型从百亿参数迈向千亿参数，所需的算力和工程复杂度同步飙升。
没有专门 Infra 团队的机构，几乎不可能独立搭建和维护大规模训练集群；即使已有团队，持续适配不同模型与算力、维护训练环境、调度资源，仍需大量人力投入。
开放模型降低了获取权重的门槛，却没有同步降低训练门槛。
现在，这道门槛有了一种新解法。
情感机器推出了大模型训练平台 PyTRIO，把训练所需的算力和底层工程封装进 Training API。用户在本地控制数据、Loss、Reward 和训练逻辑，需要 GPU 完成的计算通过 API 发送至云端；环境配置、分布式训练和集群维护等底层工作由平台处理。
由此，训练能力也成为一种可通过 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。
桥水基金与 Thinking Machines Lab 则选取六类金融信息筛选任务，以 Qwen3-235B 为基础展开训练，并让金融专家参与数据标注。结果很直接：模型准确率达 84.7%，高于测试中表现最好的前沿通用模型（78.2%）。错误数量下降 29.8%，单任务推理成本也降低了 13.8 倍。
对 AI 实验室而言，自主训练的价值又有所不同。
随着研究重点从小模型微调扩展到大模型强化学习、蒸馏和 Agentic RL，实验设想越来越依赖大规模训练条件。研究人员可以设计 Loss、Reward 和训练循环，实际推进时却常受困于 CUDA 环境、并行策略与集群调度。不同项目反复适配环境或排队使用算力，会拉长实验周期。
掌握自主训练能力，意味着实验室可以主动决定模型如何学习，并在更大的开放模型上快速验证新方法。研究人员由此获得更充分的实验空间，更多精力也能回到算法设计和结果分析上。
无论是将专业数据沉淀为企业护城河，还是把新方法变成可验证的模型能力，两类需求最终都指向同一个问题：如何更“省心”地实现自主训练？
PyTRIO：让大模型训练成为可调用的能力
PyTRIO 的思路，是将训练过程拆成用户控制的算法层和平台负责的计算层。
用户在本地 Python 环境中安装 PyTRIO SDK，继续编写数据处理、Loss、Reward 和训练循环；每轮训练所需的 batch 通过 API 发送到云端，由 GPU 执行 forward_backward、optim_step 和 sample 等计算。分布式训练、环境配置和算力调度由 PyTRIO 负责，平台同时提供权重保存与断点续训能力。
这意味着，用户保留了对算法与实验过程的控制权，但不必直接操作 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%。用一杯奶茶的预算，完整跑通了一条多轮搜索强化学习链路。
如果说 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 如何承载多阶段蒸馏流程，让研究者在提升专业能力的同时，继续寻找保留通用能力的方法。
图片也可以进入同一套训练流程。Vision GRPO 为模型接入视觉输入，再通过强化学习训练它解答几何题。Qwen3.5-4B 在 GeoQA 固定 100 道测试题上的准确率从 71% 升至 87%，格式正确率则从 75% 升至 91%。
进一步拆解发现，这次提升主要来自回答格式的改善：在格式已正确的样本中，模型的条件准确率仅从 94.7% 提高到 95.6%。研究者由此可继续分析 Reward 具体改变了哪些模型行为，而不只是得到一个最终分数。
从多轮搜索、医疗蒸馏到视觉强化学习，三组实验采用了不同的数据、Reward 和训练流程，却都可以通过同一套 Training API 组织起来。
按需计费：Token 与 GPU 时两种模式
不过，同一套接口之下，不同任务消耗算力的节奏并不相同。
以 Search-R1 为例，一次 Rollout 包含模型生成、调用搜索工具和等待结果的完整过程，其中并非每个环节都在持续占用 GPU 进行密集计算。如果按 GPU 使用时长计费，等待外部环境返回结果的时间也可能产生费用。
针对这类长 Rollout、数据量相对较小的强化学习实验，PyTRIO 的共享集群按 Token 按需计费，团队只需为实际处理的 Token 付费。研究者可用较低成本尝试不同的 Reward 与训练路径，也不必提前租用整块 GPU。
SFT 和数据合成等任务通常具有更连续、稳定的计算负载。对于这类训练，以及有长期使用需求的企业团队，专属 Training API 按 GPU 时计费，并提供相对固定的训练资源。
两种模式分别对应弹性的实验需求与稳定的生产负载。团队可根据任务中生成、等待和密集计算所占的比例选择计费方式，让算力成本更贴合任务实际运行方式。
连接算力、工具链与持续学习
Training API 统一的不仅是训练入口，也包括开发者使用不同底层算力的方式。
一种芯片背后，往往跟着一整套软件生态。例如英伟达与昇腾使用不同的软件栈、算子库和通信方案，迁移训练任务时，环境、算子和分布式方案往往都要重新适配，底层工程几乎需要重做一遍。
PyTRIO 试图让更换芯片这个操作更加“丝滑”。开发者可通过同一套 Training API 组织训练，无论任务运行在英伟达还是昇腾算力上，相应的环境配置和适配工作都由平台完成，上层训练代码也能尽量保持一致。
目前，PyTRIO 已完成对昇腾 950PR、910B 等机型的适配，并能够支撑大规模训练任务。对国产算力而言，这相当于降低了真实训练任务的迁移门槛。算法团队不必先花大量精力熟悉新底层工具，已有实验也更容易转移到国产芯片上。
从整个 AI 研发流程看，PyTRIO 也是情感机器完善工具版图的重要一步。
此前推出的 SwanLab 已覆盖实验观测与管理，帮助研究人员完成训练可视化、实验记录、版本对比和团队协作；PyTRIO 继续进入训练执行环节。二者由此串联起实验发起、执行、观测与复盘等研发工作。
在情感机器设想的持续学习路径中，应用与用户交互产生的数据可重新进入评测和训练流程。哪些回答有效、模型在哪里失败，这些都可能成为下一轮优化的信号。数据经筛选和处理后推动模型更新，更新后的模型再回到应用中接受新反馈。
如果把自动化再向前推进，AI 还可以参与提出研究假设、修改实验配置、启动训练并分析结果，再据此规划下一轮尝试。这类由 AI 参与设计和推进实验的流程，正是 AutoResearch 所指向的方向。
随着训练能力 API 化的实现，这些设想正在逐步演进。从芯片适配到实验管理，再到持续学习与 AutoResearch，PyTRIO 所指向的，是让 Training API 逐步成为连接应用数据、研究逻辑与算力资源的一层基础设施。
从调用智能，到掌控智能
如今，开放权重让越来越多不同规模的团队第一次拥有了塑造模型的机会。然而，从下载模型到真正完成训练，中间仍隔着一段不小的距离。
对企业和实验室而言，这也是从“0”到“1”的距离。再珍贵的行业数据、再有潜力的研究设想，如果无法进入训练流程，最终仍只能停留在原地。
PyTRIO 所做的，正是尽可能缩短这段距离。
对 AI 初创公司，Training API 让产品数据有机会转化为差异化能力；转型期企业可以进一步沉淀行业知识与业务经验；AI 实验室则能减少底层工程对研究效率的牵制。
更长远看，企业要掌握的可能不是某一个万能模型，而是一组面向不同部门、业务场景和客户需求、能够持续更新的专属模型。想让这些模型稳定地训练和迭代，训练能力就不能永远停留在一次性的工程项目上。
如果说推理 API 让更多团队得以调用智能，那么 TaaS（Training as a Service）指向的，正是让塑造智能也成为一种可以调用的能力。PyTRIO 希望通过 Training API，让更多团队离真正掌控自己的模型更近一步。
当模型真正被团队所掌控，智能的边界也将由此开拓。