作者：BUCK SHLEGERIS
日期：2025年10月9日
上周，Thinking Machines 公司发布了一款名为 Tinker 的产品。它是一个用于在开源大语言模型上进行微调和推理的 API，但其工作方式独树一帜。我认为，它将对 AI 安全研究产生立竿见影的实际影响：我预测，它将大幅简化强化学习（RL）实验，未来我们会看到更多关于大型模型强化学习的安全研究论文。
但另一件事更让我感兴趣：这个 API 的设计，让许多类型的机器学习研究不再需要直接访问模型本身。像 Tinker 这样的 API，或许能帮助 AI 公司减少其内部研究员（无论是人类还是 AI）接触敏感模型权重的机会。这对于降低模型权重泄露和其他恶意部署的风险，无疑是一大利好。
Tinker API 的独到之处
在 Tinker 之前，像 OpenAI 的 SFT 和 RL API 那样的 LLM 训练接口，通常允许你提交训练数据，但训练过程用的是服务商自己预设的算法。如果你恰好需要他们提供的算法，那自然再好不过。但缺点是缺乏灵活性。
Tinker API 则另辟蹊径，它提供了一个更底层的 API，赋予你足够的灵活性去实现各式各样的训练算法。不仅如此，他们还提供了一个开源库，在这个 API 的基础上实现了许多主流的训练算法。
具体来说，这个 API 允许你执行以下操作：
初始化 LoRA：在现有的大语言模型之上，初始化一个新的 LoRA 模块。这个 LoRA 模块托管在他们的服务器上。 运行前向与后向传播：你只需提供输入数据，以及一个将模型输出映射为单一损失值的函数。他们的服务器便会在加载了 LoRA 的模型上完成前向传播，并根据你的损失函数计算梯度，然后将梯度累积到 LoRA 模块中。 执行优化器步骤 ( optim_step)：使用累积的梯度来更新你的 LoRA 模块。模型采样：从你微调后的 LoRA 模型生成内容。 下载 LoRA：将训练好的 LoRA 模块下载到本地。
这套接口的表达能力极强，足以让你实现当前绝大多数主流的训练算法，例如监督微调 (SFT)、直接偏好优化 (DPO) 以及各类强化学习算法等等。
这个设计的背后有一个深刻的洞见：由于训练的只是轻量的 LoRA 模块而非整个模型，服务器可以高效地将来自不同用户的请求打包处理，极大地提升了计算效率。当然，这一切的前提是 LoRA 微调能够满足你的需求。这大概也是为什么 Thinking Machines 前几天专门发文论证：在许多常见场景下，LoRA 微调的效果与全模型微调不相上下。
为何这对 AI 安全与控制至关重要
从安全角度看，这个 API 的核心优势在于：它不会让用户直接接触到他们正在使用的模型。
据我专业判断，在前沿 AI 公司里，至少九成的研究工作（其中很大一部分涉及微调）都需要研究员在能直接访问模型权重的机器上编写并执行脚本。这种工作模式带来了巨大的安全风险，而 Tinker 这样的接口恰好可以化解这些风险。
首先，研究员通常能接触到模型架构。如果你希望模型架构保密，那这种情况就相当棘手了。当然，架构本身有多重要还不好说。我的感觉是，自 Transformer 架构问世以来，算法层面的进步主要并非来自架构的革新。
其次，也是更致命的一点，研究员可以直接接触到模型权重。他们运行的 Python 程序能够加载模型权重并执行任意计算，这意味着他们完全可以将权重副本保存在本地，然后随心所欲地转移，进而可能窃取模型权重。
“（对攻击者而言，一个不大不小的麻烦是权重文件通常很大。但在机器学习研究中，生成巨大的文件是家常便饭，研究员完全可以将权重文件分割成小块，分批盗走。）
此外，他们还能进行不受监控的训练和推理。例如，如果研究员可以直接在服务器上调用模型权重进行推理，你就无法保证你最强模型的每一次输出都被记录在案。他们还能随心所欲地微调模型，并运行这些“黑箱”模型。这可能在以下几个方面失控：
他们可能进行灾难性的滥用。 他们可能不断迭代“越狱”方法，用以欺骗作为监控系统的模型，从而在不被察觉的情况下执行危险操作。
以上讨论虽然都以防范人类内鬼为出发点，但同样的逻辑完全适用于防范“行为失控的 AI 代理”所带来的风险。
当然，这种接口并非高枕无忧，依然存在安全隐患：
研究员可能尝试攻击托管 API 的服务器。 但相比于防止他们滥用模型权重，防御几台服务器的难度显然要低得多。 研究员可能尝试隐蔽的恶意微调。也就是说，他们试图滥用 API，在监控系统毫无察觉的情况下，诱导 AI 做出恶意行为。目前我们还不清楚这种行为是否能被有效预防或检测，我非常期待看到这方面的更多研究。
我坚信，强制研究员使用此类 API 而非直接访问模型，将是 AI 安全与控制领域的一大进步。現状是，多数 AI 公司的研究员滥用模型权重相当容易，获取模型架构不费吹灰之力，只要他们下定决心并用点心思，窃取模型权重也并非天方夜谭。而 Tinker 这样的变革，将使所有这些攻击的门槛都大大提高。
我们已经看到，研究员们非常乐于使用集中的推理服务器，而非自己部署服务。这同样有助于提升安全性，尽管限制更多。在过去，训练 API 的灵活性太差，我一度认为但凡有直接训练的机会，没人会愿意用它们。但 Tinker API 的灵活性让我相信，即便拥有直接访问模型的权限，研究员们也可能更愿意使用它。因此，在了解到这个 API 设计后，我对于“保护模型权重与架构免遭恶意内部人员侵害”这件事，的确变得更加乐观了。
大部分机器学习研究，无需直接接触危险模型
我认为，只要有 Tinker 这样的接口，前沿 AI 公司进行的大部分机器学习研究，都可以在研究员不直接接触危险模型权重的情况下完成。这里所谓的“危险模型”，具体可以指那些比当今最强模型能力更强的模型。
在这些受限权限下，可以完成的研究大致可分为几类：
直接使用此接口的项目：绝大多数关于 RL 算法、RL 环境、训练对模型“性格”影响等方面的研究。 这个接口其实也能支持全权重训练，只不过会丧失批量处理带来的效率优势。 需要更细粒度访问，但无需接触危险模型的项目（因为用小型模型或大型模型的早期、能力较弱的检查点即可）： 性能工程（通常用早期检查点就能完成）。 预训练（主要是在小模型上实验；如果未来模型能力主要来自强化学习，那么预训练模型本身可能并不可怕）。 量化研究，或许也在此列。但这方面的研究可能还是需要在最终部署的模型上进行才最有效。 新型优化器的研究。 真正需要对前沿模型进行细粒度权重访问的，主要是模型内部机理与可解释性研究。
总而言之，AI 公司内部绝大多数的机器学习研发工作，很可能都可以在不接触强大模型权重的情况下进行。当然，随着未来研究人员数量的增长，情况会如何演变，我尚不确定。
一个让人不那么乐观的因素是，这种 API 的计算效率可能天生就比直接微调要低。其主要原因是它需要额外的网络通信，且灵活性稍逊。正如我在别处所说，AI 自动化研发的趋势将促使研究员们更加关注计算效率，这可能会放大上述缺点。但反过来看，它也可能更高效，因为可以批量处理不同用户的请求。我倾向于后者，因为我预计未来的 AI 研究员将主要依赖内部推理 API，而非各自为战。
归根结底，在安全与 AI 控制领域，我们的目标并非让内部人员永远不需要危险权限，而是尽可能降低他们需要该权限的频率。这样，我们就能将宝贵的监控资源集中在那些少数的、真正高风险的操作上。所以，哪怕最终仍有 10% 的研究员需要直接访问模型权重，这依然是巨大的进步。
结语
总而言之，在了解了 Tinker API 的设计并看到 Thinking Machines 公司成功将其实现后，我对保护模型权重、防范来自人类与 AI 的内部威胁这件事，确实变得更加乐观了。如果各大 AI 公司能为内部研究搭建类似的服务，将对其整体安全水平大有裨益。我真心希望他们能够采纳。
当然必须澄清，内部威胁的来源远不止于此。除了窃取权重，失控的 AI 代理还可能被用于编写安全关键代码、生成可能被投毒的海量数据、开发可能被植入后门的外部软件（如军用机器人程序）、处理我们不希望泄露的机密信息，或是在关键问题上提供蓄意误导的答案。因此，这次的发现并没有从根本上改变我对 AI 控制研究重要性的整体看法。
但这件事也让我非常清楚地意识到一个事实：对于 AI 安全的未来，有很多重要的事情是许多 AI 公司的内部人员早已知晓，而我却一无所知的。我之前真的不知道，竟然存在如此巧妙的设计，能让研究员在无需直接访问模型的情况下，如此灵活地开展大量研究工作。
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
