Ivan Nikitin，Fortytwo 首席执行官兼联合创始人——系列专访

Ivan Nikitin是 Fortytwo 的首席执行官兼联合创始人，他正在开发群体推理技术，让多个 AI 模型协同推理，并相互评估彼此的成果。他的经历涵盖游戏、对话式 AI、生成式 AI，以及在 Temporal 和 Sensorium 从事交互式系统开发。他于 2011 年与 Vlad Larin 共同创立 Temporal。如今，Vlad Larin 是 Fortytwo 的联合创始人兼首席技术官。在 Temporal 的工作让他积累了构建不断演进的智能体群体及融合专用模型的系统的经验。

Fortytwo构建 AI 基础设施，让模型能够在推理过程中协同工作。其 Fortytwo Engine 借助 Swarm Decoder，在共享的推理过程展开时引导其方向，旨在提高准确性，并减少长任务中不必要的 token 生成。该公司通过 Fortytwo Engine 向开发者提供 API，并通过 Fortytwo Harbor 提供本地部署方案。

在共同创立 Fortytwo 之前，你曾多年在 Sensorium 和 Temporal 开发对话式 AI、生成式 AI 和交互式系统相关产品。这些经历如何塑造了你对单个大型语言模型局限性的看法？它们最终又如何促使你采用 Fortytwo 背后的群体式方法？

我们团队中有相当一部分人，包括我自己，都是通过游戏进入 AI 领域的。游戏一直是个人计算和现代 AI 的摇篮：GPU 的诞生离不开游戏，而游戏也是强化学习的首个重要试验场。游戏世界为我们提供了一个切实可行的环境，用来构建能够学习、适应并参与竞争的智能体。在我于 2011 年与 Vlad Larin 共同创立的 Temporal（Vlad Larin 现为 Fortytwo 的联合创始人兼首席技术官），我们最初探索的是不断演进的智能：在选择压力下相互竞争的智能体群体。我们关注的是，只要有合适的机制来识别并发扬群体中最出色的贡献，群体能否取得超越单个智能体的成果。选择与评估由此成为我们思考智能时的核心。

Transformer 模型问世后，我们拓展到对话式 AI 领域，并构建了一个平台，让 AI 驱动的角色能够凭借记忆和个性，进行开放式、无预设脚本的对话。这比 ChatGPT 问世早了几年，当时我们使用的模型上下文窗口只有 512 至 1,024 个 token。要指望一个早期语言模型可靠地满足这类体验的所有不同要求，根本不现实。我们不得不搭建一条由专用模型组成的定制处理流程，让每个模型各司其职，并设计相应逻辑来整合它们的贡献。对回复进行排序和筛选，是让整个体验顺畅运行的关键。这让我们认识到，将能力有限的模型组合成设计完善的系统，能够释放出多大的潜力。

另一个教训关乎效率。我们发现，针对定义明确的任务训练和部署专用模型，效率更高，让我们能够在算力有限的情况下完成更多工作。但推理规模化仍然是一项挑战：一方面，API 使用量受到上限限制；另一方面，大规模自托管的成本高昂。由于无法获得前沿算力，我们必须仔细考虑如何让现有资源发挥更大作用。Fortytwo 将这些经验汇聚到群体推理这一构想中：多个模型，或同一模型的多个实例，共同参与推理，同时评判同伴的工作。最终，整个群体的准确性高于其中任何一个成员。

Fortytwo Engine 使用多个开放权重模型引导同一个推理过程，并在生成回复时相互检查。这种方法与传统的多智能体系统、模型集成，或简单地运行多个模型后再选出最佳答案，有何不同？

关键区别在于，群体推理是直接集成在我们开发的推理引擎中的。我们称之为 Swarm Decoder：多个模型参与者在生成过程中持续共同塑造一条推理路径。评估和引导都在这一过程中进行，因此模型能够在回复完成之前影响其走向。

其他方法的运作方式各不相同。在答案级集成中，多个模型分别生成答案，然后对这些答案进行排序、筛选或整合。Fortytwo 最初的架构于 2025 年实现，采用对已完成答案进行同伴排序的方式。这大幅提高了答案准确性，但也增加了延迟和计算开销。许多传统多智能体系统会把工作分配给不同智能体，并通过协调器和自然语言消息来管理它们的分工。这种交接可能需要额外的推理调用、重复传递上下文，还要决定在智能体之间传递哪些信息。Swarm Decoder 不存在交接：所有参与者都围绕同一条推理路径协同工作，彼此交换的只有对哪个方向更好的判断。

Swarm Decoder 旨在于生成过程中及时发现薄弱假设，避免在这些假设上投入大量精力继续推演。其目标是减少错误、回溯和不必要的生成；只有在检查所避免的额外工作多于检查本身增加的工作时，才能带来效率提升。这也正是它不会造成延迟损失的原因：执行过程走的是更直接的路径，因此 Engine 完成任务的速度比单独运行同一模型更快，所用 token 总数也更少，且统计时包含所有参与模型。

你曾指出，模型在长时间运行的任务中逐渐偏离目标是个重大问题。造成这种偏离的根本原因是什么？在软件工程、研究或自主 AI 智能体等实际应用中，它又会如何表现？

模型偏离目标，是指模型的上下文逐渐不再围绕任务展开。长时间运行时，上下文会被模型自己的输出、工具结果、文件内容和重试记录填满。模型关注的内容中，最初指令所占的比重越来越小；它先前犯下的错误也会成为后续推理的输入，于是错误不断累积，而不是相互抵消。除此之外，如今的推理模型经过强化学习训练，目的是完成任务；它们也会学到一些看似能完成任务的捷径：跳过工具调用、宣称成功，或用总结代替核查。我们称之为懒惰，前沿模型和开放权重模型都会如此。根本原因在于，单个模型缺少外部核验机制。它只能给自己的工作打分，而模型并不擅长准确地反省自身。

在软件工程中，这种偏离表现为：智能体修复了你描述的漏洞，却破坏了你在第一条消息中提出的约束；写出的测试轻易就能通过；或者因为忘了自己已经了解过哪些内容，把同一个文件读了四遍。在研究中，这表现为长时间运行的任务逐渐偏离你提出的问题，转而回答更容易回答的问题，最后给出一份泛泛的总结。在自主智能体中，这种偏离代价高昂：跑题、反复调用工具、来回折返，耗费的 token 数可能是任务实际所需的好几倍。

我们可以用数字来衡量这一点。我们让 Qwen 3.8 27B 完成了 450 项 DeepSWE 任务。这些任务是需要使用工具、在长上下文中开展的真实软件工程工作。我们分别测试了该模型单独运行和通过 Fortytwo Engine 运行的表现。单独运行时，该模型每次运行平均消耗 1630 万个 token，总计 74 亿个。通过 Engine 运行时，同一模型每次运行平均消耗 1230 万个 token，总计 56 亿个，减少了 24.7%；同时，它解决的任务也更多：47.8%，而单独运行时为 42.2%。模型本身没有任何变化。每次运行中减少的 400 万个 token，消耗在了偏离目标上：反复阅读、重试和来回折返。单个模型之所以不得不这样做，是因为它在走错方向时，没有人及时发现。群体能够及时发现这些错误，因此模型不必为此付出代价。

Fortytwo 先前让模型评估彼此已经完成的答案，而当前的架构则能让它们在推理生成过程中实时影响推理。你们从早期方法中学到了什么？为什么实时引导更有效？

2025 年的架构证明，我们可以通过横向扩展来获得前沿级别的能力——让更多模型参与，而不是一味追求最大的模型。由开放权重模型组成的群体相互评判彼此的完整答案，其表现比群体中最优秀的单个模型高出最多 17 个百分点；而且面对噪声提示、注入指令以及多数答案错误等情况时，它也比单个模型更加稳健。

这种架构无法做到的是及时干预。对完整答案进行排序适用于单个问题，但智能体运行包含数百个步骤，中间还穿插着工具调用，而决定性的错误往往很早就会发生并不断累积。等到最后才评判，意味着每个模型都已承担全部 token 成本，而评判者只能从已经分道扬镳的执行路径中择优。此外，群体的成本也会随着模型数量增加；这对一个棘手的问题尚可接受，但不适用于编程智能体。

实时引导解决了这两个问题。持续排序会在整个运行过程中施加选择压力，因此一旦出现错误方向，就能在它扩散之前及时纠正。群体不会满足于懒散的尝试，因为在排序中，更懒散的尝试会输给更谨慎的尝试。因此，同一机制如今既能提高准确率，也能减少 token 消耗。

在对 Qwen 3.8 27B 的测试中，Fortytwo 报告称，完成 450 次 DeepSWE 运行时，token 使用量减少了 24.7%，同时在六项基准测试中的表现都有提升。群体内部发生了什么，使它既能提升性能，又能减少 token 消耗？

群体进行核查的成本较小且固定；而它所避免的补救成本会随着任务长度增加，因为每一次未被纠正的错误转向，都会让其后续建立的一切付诸东流。因此，任务越长，可节省的成本就越多。DeepSWE 属于任务长度范围的较高端，这也是节省量接近所有 token 总数四分之一的原因。

准确率方面的提升，关乎智能表现的不均衡性。模型的进步通常并不均衡：它们在某个领域具备博士级推理能力，在另一个领域却会胡言乱语。这是因为微调、强化学习和其他后训练方法会让模型在其训练数据所涵盖的内容上有所提升；而实际任务与这些数据越不相似，提升幅度就越小。Swarm Decoder 不会改动模型，而是持续改进推理过程本身。因此，六项基准测试并非我们专门优化的六个领域，而是用来衡量同一种能力的六个场景。总体而言，模型变得更聪明，也更专注；有同伴检查每一步时，它给人的感觉是对你的任务投入了更多精力。这也正是我们能够按照基础模型的每 token 价格为 Engine 定价的原因：客户付费买的不是更大的预算，而是更短的正确答案路径。

随着推理模型生成越来越长的 token 链，AI 开发者日益关注推理成本。你认为，提高推理过程本身的效率，最终是否可能与让单个模型更小、更快或更便宜同样重要？

是的，我认为这已经是更大的杠杆。让模型更小、更快、成本更低，可以降低每个 token 的价格。但没人买 token，大家买的是完成的任务。在智能体时代，每项任务所需的 token 数量激增：推理模型处理实际编码任务时会消耗数百万个 token，其中很大一部分都花在了反复回溯上。每项任务的 token 数减少 25%，其价值恰好等同于价格降低 25%；不同的是，这种节省还能与硬件、量化和内核方面的每一项改进叠加，而且我们可以将这种方法应用于市面上任何开放权重模型。

这个行业有三个杠杆。更好的模型依赖训练，而训练成本高昂。更便宜的 token 取决于硬件和服务，而这方面的差距正在缩小，因为大家用的都是同样的 GPU。还有每项任务使用更少的 token，这取决于推理的运行方式，而这一方向几乎尚未得到探索。迄今为止，规模扩展意味着模型更大、思维链更长，而这两种做法都要求一个模型在单条轨迹中包办一切。我们认为，下一个扩展方向是集体协作：多个模型共同推理、分担判断，从而让推理轨迹本身更短、更可靠。这是一种不同于增加参数或测试时计算量的扩展方式，也是我们押注的方向。我们将其概括为：重同伴协作，而非参数规模。

Fortytwo Engine 在运行开放权重模型的同时兼容 OpenAI API。与现有 AI 开发技术栈兼容有多重要？开发者要将应用从传统的单模型 API 迁移到群体架构，过程有多简单？

兼容性至关重要。智能体生态系统——包括编码智能体、运行框架、开发框架和评测工具——都是基于 OpenAI API 的接口形式构建的。因此，对于使用 Fortytwo Engine 的开发者来说，迁移就像从一家推理服务提供商切换到另一家：对于兼容的应用、智能体、运行框架或服务，通常只需更改一项配置：端点、API 密钥和模型选择。

改变的是运行行为，而不是集成方式。差异会体现在较长时间运行的智能体任务中：在这类任务里，token 消耗量和首次执行的准确率决定了成本。同一个模型通过 Engine 运行时，完成任务更快、消耗的 token 更少，而且答对的任务更多。我的建议是像更换任何模型一样处理：在你的智能体上运行现有评测，比较每项任务的 token 数量和成功率，然后保留表现更好的方案。

感谢这次精彩的访谈。希望进一步了解群体推理以及同伴评估如何提高推理效率的读者，请访问 Fortytwo。