# AI 下半场，不会只剩一个超级模型｜对谈 Kevin Ding：Pyromind 创始人/CEO 十字路口Crossing · 2026-08-30 · 49 min · https://www.xiaoyuzhoufm.com/episode/6a90fc5e1352af56ff3d48af?utm_source=rss ## 逐字稿 Koji 哎，我是科技。本周十字路口的嘉宾是 PyroMind 的创始人和 CEO Kevin 丁。PyroMind 所在的赛道是非常热门的 RLSS Service，也就是强化学习及服务或者后训练及服务。他们前不久刚完成了天使轮融资，投资机构包括高瓴、百度风投、蓝驰等。你好。 Kevin Ding 你好。 Koji 你好，Kevin，欢迎来到《十字路口》。我们还是从快问快答开始，帮助大家尽快了解你。Kevin，你的年龄？ Kevin Ding 我是 1994 年的，今年 32 岁。 Koji 请问你的求学经历？还有 MBTI 和星座？ Kevin Ding 伦敦国王学院（King’s College London）。MBTI 如果按测试结果来看是 INTG，但我的感觉可能在 I 和 E 之间。星座是摩羯座。 Koji 用一句话介绍一下 PyroMind。 Kevin Ding 最终定位就是一个 Auto RL。它跟现在大家一直在讨论的 RSI 这个方向，其实是一个比较具象化的实现路径。 Koji 那咱们的融资情况呢？ Kevin Ding 我们是去年公司成立之后完成了一轮融资，投资方包括高瓴、百度风投、蓝驰和 Vertical。目前团队规模是 20 多个人。 Koji 收入和利润方面可以讲吗？ Kevin Ding 具体数值就先不讲了。但是现在我觉得比较振奋人心的一点，是我们初步跑通了 PMF。 Koji 什么样的 PMF 跑通了？ Kevin Ding 两个方向。一个方向是证明了我们提供 Auto RL 这种方式实现的 RSI，在生产环境里是有价值的，也就是说它的商业模型至少是成立的。第二点是它的可扩展性：在横向场景和客户复制上，我们的工作量是在逐步递减的。 Koji 在创业之前，你做过些什么？ Kevin Ding 我之前有很多精力放在偏 infra 的事情上，因为我之前在阿里云。那时候在阿里云主要做了弹性 GPU 实例，包括训练 GPU 集群。 Koji 当时你看到了什么样的机会，决定创业做 PyroMind？ ### Agent 蜂群成为方向 Kevin Ding 其实当时我的想法是，模型预训练这件事到现在为止远远没有到终结的时候。但当时看到一个趋势：到 2025 年下半年，无论是社区、硅谷，还是国内的技术圈，大家都在讨论 AI 可能要进入下半场。 这个说法出现了两个方向。一个方向认为我们继续沿着预训练走，ASI 到来的形式会是一个超级庞大的中心化模型，它能够解决绝大多数场景里的问题，而且效果足够好。另一条路线，或者另一个讨论方向，是认为最终 ASI 的形态会是服务化的形态，是 Agent 蜂群的形态。 我个人肯定偏向于后者，因为我觉得这更实际。这个世界上需要被 AI 解决的问题和场景，无论从当下这个时间点看，还是随着时间推移，都是无穷无尽的，而且还会不断产生新的场景。场景本身也不是静态的。 在这种模式下，我们尝试用一个有限参数的模型去泛化无限的场景。目前来看，至少在 Transformer 这个架构上实现，还是很有挑战的。 Koji 到目前为止又过了一年多，你有没有看到一些信号，让你感觉一开始的判断越来越成立了？ ### RSI 开始变得必要 Kevin Ding 是的。首先，我们看到第二条路必然是成立的。我不能说第一条路已经被证伪，但是我能够论证的是，第二条服务化路线一定成立，因为需求一直在那里，而且需求还在不断增长。 这一年我看到的一个变化是，大家为什么现在开始提 RSI。之前 RSI 没有那么高的热度，其实这就是服务化带来的结果。因为 Agent 部署得越来越多，我们可以想象一下，一个人日常带着几十个 Agent 去做一件事，他不可能有精力去维护每一个 Agent 的演进。 RSI 之所以被需要，是因为 Agent 开始多起来了。当一个个 Agent 嵌入到具体场景里的时候，我们最终的衡量方式是：它在一定的时间轴上，表现都要符合预期。实现这一点的方法，就是 Agent 需要自我迭代，需要具备自我改进的能力。 Koji 所以你们一开始做 PyroMind 的时候，就想到了要用 Auto RL 去做 RSI 吗？ ### Auto RL 补上最后一环 Kevin Ding 实话说，这是在过程中慢慢浮现出来的。我们一方面本来就在关注后训练这个场景，另一方面，后训练这件事对我们自己的影响也比较大。 以 RL 为代表的后训练技术，本质上是拿到环境反馈，然后去更新模型，这是一个持续的过程。其实我们自己研判方向也是这样：一开始创立公司的时候，我们认为做到 RL as a Service，做成一个扁平的 Service 形态，基本就能满足这些 Agent 的部署要求。 但后来我们发现这依然不够，因为 Service 面向的对象，终归还是要有一个开发者在那里驱动 Agent 去改进。所以我们在这个阶段才开始想，Service 只解决了一半的问题。真正把 RSI 跑起来，要解决两个问题：一个是训练，另一个是奖励。 于是我们开始规划 Auto RL 要怎么跑起来，奖励也被纳入了我们的 scope。 Koji 可以用一个具体的客户案例讲一下吗？我们只给他单独做 RL as a Service，和现在给他做 Auto RL，具体的服务内容有什么不同？ Kevin Ding 比较好的例子是 GUI Agent 的一位客户，因为他们下游有很多消费级的部署量，会收集到很多用户的特定需求，以及产品迭代过程中的需求。 我们一开始提供的 RL Service，是给了他一个 Studio，把一套通用的训练 pipeline 固定下来。但他依然要不断投入自己的算法工程师，或者其他人员，持续更新 Agent 本身。我们只是把训练这件事情解决好。 一个训练要完整解决、完成一版模型更新，除了要分析需求侧的信息、把需求翻译成奖励、设计算法、进行训练之外，后端的 infra 也需要解决。我们当时把 infra 的问题全部解决掉了，但客户依然没有摆脱投入大量人力来做这件事。 到了第二期，我们把 GUI 方向的奖励做出来之后，发现这个 loop 其实可以自动化地跑起来。只要末端部署的 Agent 能够源源不断地收集用户在真实环境下的反馈，我们就可以让它自主循环起来。所以第二期我们就把 EchoMind 这个产品推给了他。 Koji 咱们现在主要提供两个产品，一个是 PyroMind Studio，另一个叫 EchoMind。可以分别介绍一下它们是什么样的产品吗？ Kevin Ding Studio 是我们提供训练 infra 的一个 serverless service。我们会在 Studio 上实现大量训练所依赖的逻辑节点。 之所以强大，是因为开发者配置这些节点的时候，不需要关心它在物理机上的具体实现，更多只是配置训练参数。逻辑节点本身是可以横向扩展的：你可以做单点、单卡的算力，也可以从单台扩展到多台，这些都可以在一个逻辑节点上完成。扩展工作由我们来做。 对于训练开发者来说，只要把训练参数，以及 DP size、TP size 等配置好就可以了。 EchoMind 这款产品，则是把刚才所说的整个 RSI 流程都包在背后。我们对用户透出的是一个 Proxy，也就是一个代理 URL。这个 URL 只要插入到某个 Agent 里面，就可以源源不断地抓取 Agent 的运行轨迹，形成一个相对整齐的数据集。 这个数据集会经过奖励结构处理，生成训练 pipeline，然后进行训练，拿到结果之后再部署回去。这一套流程全部被 EchoMind 包起来了。 Koji PyroMind 现在典型的客户画像是什么？ ### 工业数据带来杠杆 Kevin Ding 我们选择客户时，需要的是真实世界的数据。第一，这些数据要产生于生产场景；第二，最好是在模型能力之外的问题，因为这对模型效果的提升最明显。 我们会思考，哪里的 real-world data 最丰富。我们现在有一些比较重要的客户集中在工业领域，比如英伟达的上游企业。 这些企业有一个特性：经过过去几年制造 1.0、2.0 的改造，它们在企业内部的数字化做得比较好。同时，经过这么多年的生产，又积累了一批非常可观的数据。 第二个指标是，工业场景除了数据丰富之外，企业自己对精益生产有明确的定义。这样一来，收集上来的数据往往已经有相对明确的好坏标签，标注问题天然就被解决了。 与此同时，毕竟这还是一个商业行为，我们还要衡量 ROI。三个条件都满足的工业客户，可能就是比较好的客户画像。 Koji 工业客户是一类，还有其他比较典型的客户画像吗？ Kevin Ding 还有 Agent，或者和具身智能相关的客户。具身智能我们当然也会看，但现在它是一个相对独立的板块。我们的目标还是做后训练驱动的 RSI，偏软件领域肯定会更快一些，因为具身智能还要考虑硬件部分，这是一个更复杂的问题。 Koji 在给企业做 RL 的过程中，不管是 RL as a Service，还是 Auto RL，最花时间、最花钱的是什么部分？ Kevin Ding 最花时间的，实际上是初次进入一个场景时的 FDE 工作。虽然我们做 RSI，但并不排斥完全做 FDE，因为要让 RSI 渗透到某个场景里，FDE 这个阶段不可省略。 初次进入时，我们需要理解客户场景里的数据、知识和评价基准，同时把我们自己的奖励 Agent 或 Reward Model 适配到这个场景上，这个过程比较花时间。 但好处是，在这类行业里，初次启动确实需要做这些工作，后面扩展起来，工作量是在递减的。因为奖励最终还是会收敛到模态上，在相似模态上，相当一部分工作可以复用。 Koji 所以去年那一大批不管中国还是美国做 RL as a Service 的公司，现在大家也都和你们一样，慢慢开始做 Auto RL，或者叫 RSI 了吗？ Kevin Ding 我觉得大家是有分化的。首先，对于下半场的需求来说，它非常丰富，也非常宽。 比如去年和我们同期关注的一些公司，比较出名的应该是 Apply Compute。它现在已经更往前走了一步，提供一套非常完整的服务基础设施，把 Agent Serving 等事情全部做掉。它面向的可能是几个比较头部的企业，把企业内部所有和 Agent、AI 相关的东西全部做掉。这是一条路线。 另外一条路线，是近期比较出名的 Trajectory。它也是 DeepMind 的人出来做的一家非常优秀的公司。他们做的事情和我们的理念相似度更高一些，单纯做 RL，同时也和 Mercury、Clay、Harvey 等公司有一些合作。 他们的定义和我们相对比较相似。我们更期望做到 Auto，也就是把无状态的 RSI 能力提供出去，把它做成一个可以平台化的东西。 前者，也就是 Apply Compute，做的是把企业内部所有场景全部包掉，是一个更宽、更重的方式。后者的 scaling 方向不一样：Apply Compute 是在一个企业内部纵向 scaling；Trajectory 的思路是只把训练这件事情做好，然后横向 scaling。我们更倾向于用后者的方式来做。 Koji 回到刚才状态的问题。有状态和无状态最典型的例子，是环境。大家做后训练时，环境是一个被高频提到的词。 ### 无状态管道实现扩展 Kevin Ding 我们对环境的理解是，原本在 coding 领域，环境是一个非常典型的东西。比如你把 compiler 提供出来，每生成一个新的代码片段，就用 compiler 跑一下，它都能够拿到一个比较强的奖励信号：代码是否通过。 但它有一个特性，就是和生产环境里的信息不耦合，可以被抽离出来。 对于实际生产环境来说，这样的环境就比较有限。比如刚才说的 GUI Agent，当你想把每个用户自己的需求做好时，就不能脱离用户上下文。如果脱离了，Agent 就缺乏生产价值；如果和用户上下文耦合在一起，它就是一个有状态的环境。 所以我们要做的，是在这么长的一条链路里，找到可以横向 scaling 的无状态部分。这个东西不单纯是一个 environment，而应该是一条 Auto RL 管道。 这条管道就是：你把数据喂给它，它拿到数据后，通过 Reward Agent 或 Reward Model 拿到 reward signal，然后迭代一轮。Auto RL 管道以及奖励本身都是无状态的，和生产上下文不耦合。 Koji 这里我有点困惑。既然是奖励信号，它应该是在真实生产环境里出现的奖励信号，怎么能把它抽离出来呢？ Kevin Ding 对于这个场景，需要做一层解耦。奖励信号本身，是模型在场景里 rollout 一次之后，由对应的 Reward Model 或 Reward Agent 给出一个优势，也就是 advantage。只有给出这个优势，才能找到更新方向。 第二种方式是，生产场景回流的数据里包含了一些人工标注。这本身也是一种奖励。但这两个信息已经和上下文解耦了，它们包含在用户回流的数据集里，而不是包含在我的环境里。 模式上的区别是，对于一个要横向 scaling、卖给不同客户的产品来说，我不能把 A 客户的状态打包进产品，再卖给 B 客户。这样是不行的。 Koji 可以再稍微展开一下刚才提到的第一类典型客户——工业客户吗？在给工业客户提供服务时，你们具体帮他们做了什么？ ### 工业模型学习生产经验 Kevin Ding 工业领域我们现在主要看两个偏软件的场景。一个是和工艺相关的工艺改进，这类模型做 post-training 是比较甜蜜的地带。第二个是质检，质检也是一个典型的多模态问题，同样是比较甜蜜的地带。 工业领域的好处是，无论工艺还是质检，它的数据丰富程度都超出我们的想象，而且非常丰富。同时，它对结果是好还是坏，都有明确的评价基准。 Koji 质检比较好理解，工艺可以举一个更具体的例子吗？ Kevin Ding 工艺其实类似于电镀。我们不需要深入到具体是怎么做的，它本质上是在生产线上配置一批参数。参数配置好之后，产线后段就能拿到想要的东西；如果参数配置不合适，最后拿到的就不是想要的东西。 现在这个事情还是由老师傅来做，因为本质上还是一个人驱动的过程。做后训练的目标，是根据历史数据和未来增量的生产数据，把人完成这件事的经验迁移到模型里。 这样一来，模型长期运行时，无论是在品控保护、品控波动上，还是随着增量数据越来越多之后，都有可能比人做得更好。模型现在已经有能力做到这一点。 Koji 你们怎么收费？ ### 价格锚定场景价值 Kevin Ding 我们现在有两层产品。一层是 RL as a Service 的 Service 层，也就是 Studio。对用户来说，它更多是自助式服务，所以计费方式很简单，就是按资源计费，比如 CPU、存储、GPU 这样的资源，因为这是 Service 层。 Service 的计价方式大家都比较熟悉，毕竟 Cloud Service 已经做了很多年。 对于上层的 Auto RL 产品，我们是按场景价值来计费，计费方式也是 quota。我们会根据场景里的更新频率，对 EchoMind 实例的 quota 进行限制。 Koji 所以本质上，Studio 是按资源收费，EchoMind 是按效果收费？ Kevin Ding 可以这么理解。对于 EchoMind 这样的 Auto RL 产品，我们嵌入了自己提供的奖励价值。除了把训练 Service 做好之外，我们还用自己的奖励结构给出正确的更新方向。所以对客户来说，他什么都不用管，收到的是一个更新好的模型。 Koji 所以第一部分 Service 等于训练模型的一次性收入，后者可能是更长期的收入。 Kevin Ding 其实前者也是长期收入，只是两者的边界在于谁来维护 RSI 管线。 如果是 Studio 用户，管线由客户自己做，包括 Reward Function 也由客户自己写，我们只提供稳定的 infra service。对于 EchoMind，我们介入了客户实际场景中的问题，所以会把这些能力内化到我们的模型上，由我们来维护。 Koji 一个典型用户向你们付费，大概是什么量级？你们能从一个客户那里收到或者赚到多少钱？ Kevin Ding 我们做的 RSI 形态适配的光谱很广。对于大颗粒度的企业来说，在 ROI 很明确的场景下，单体客户付费基本上也是到百万到千万人民币的区间了。 但 RSI 或者 Auto RL 能够改进的场景，有些 ROI 的放大效应非常大，也有一些是开发者做 coding 的小场景。小场景对用户来说颗粒度比较小。 我们一直强调横向，是因为 Auto RL 本来就应该无缝渗透到所有类型的 Agent 里。无论是大颗粒度的 B 端客户，还是小颗粒度、偏 C 端或者 Pro-C 端的客户，付费都取决于 Agent 本身能创造多少效益。 EchoMind 的计价是单一 quota 计价。对于高价值场景，生产 loop 里积累的数据量相应会大很多，要求也很高，需要进行更多轮训练，所以对应的 EchoMind quota 消耗会是一个非常可观的数字。 对于一些 Pro-C 端的小场景，可能要求没有那么高，只要达到某个 baseline 就可以。同时它在一个相对窄的 domain 里积累的数据也没那么多，所以 quota 消耗会比较少。 Koji 你说 quota 消耗，指的是 token 消耗吗？ Kevin Ding 其实是我们定义的一种资源单元。我们会衡量 EchoMind 做一轮 RL、嵌入奖励价值之后对应的资源消耗，可以理解成类似 credit 的东西。 它和 token 不是特别绑定。我们会计算做一轮 Auto RL 的成本：比如一条多模态长链轨迹跑一轮，大概成本是 X；嵌入奖励价值之后，我们会在 X 的基础上加上一个百分比，形成 quota。 Koji 你们的成本主要是 token 成本，还是其他成本？ Kevin Ding 实际上是训练消耗的资源成本，主要还是 GPU、CPU 这样的资源。 Koji 现在企业主要找到你们时，会怎么表达他们的需求？ Kevin Ding 这就涉及需求侧了。客户最直接能 get 到的，是你最终的结果是什么。 为什么我们选择质检和工艺这两个领域？因为结果是显而易见的。对客户来说，他其实只问一个问题：我需要付出什么，付出之后能拿到什么。把这个解释清楚就好了。 这也是为什么我们觉得 RL as a Service 不够。如果面向这样的客户提供一个还需要他自主开发的 Service，肯定是不合理的。 我们提供 EchoMind，可以明确告诉客户：基于你历史上的这些样本，我们训练 X 轮，就能拿到相应的指标。比如在质检领域，我们可以把误报率从目前的 23% 直接降到 8%，这是基于大概 1 万张样本得到的结果。这样成本和收益就非常明确了。 Koji 那客户一般会怎么理解你们的报价？你们创造了一套新的定价体系，客户会对标什么来理解这个价格？ Kevin Ding 客户对价格的理解，更多在于这个事情在他的场景上有多少 ROI，以及付出的代价在 ROI 中占多大比例。他要判断这个东西值不值得做。 对我们来说，消耗主要还是电力和算力资源，所以最终这笔账双方都是算得过来的。我们选场景时，也会选择放大效应比较好的场景。 企业内部并不是所有场景我们现在都要做。比如偏办公、发票、差旅这类 Agent，我们做起来会比较吃力，因为它们的 ROI 不好衡量。这样一来，定价体系要在这些场景里说通，就会有一定难度。 Koji 有没有什么类型的需求总是找你们，但你们觉得现阶段确实不做，会拒绝？ Kevin Ding 一个是 ROI 不明确的需求。我们选择场景有三个依据。 第一个，ROI 必须可衡量。如果不可衡量，就不好定价。第二个，不能偏离我们现在的研发主线。我们现在主要做多模态场景，因为真正落地时，不可能只做单模态。 第三个，场景本身在企业内扩展，以及跨企业扩展，都要有扩展性。 符合这三个条件的偏软件领域，一个是工艺。比如电镀工艺，在所有 PCB 行业里都通用。另一个是质检，包括可见光质检和结构光质检，这些在几乎所有制造业里都通用。 Koji 听起来还是和其他环节解耦的。 Kevin Ding 不能说完全解耦，因为它们本来都是流水线，前后环节息息相关。现在还有一个挺有意思的案例：这些场景的整个生产过程很长，会把这条长流水线里的 PQ 阶段控制汇总成一份报告。PQ 就是 Process and Quality，也就是过程与质量控制。 它会形成一个更抽象的报告。好处是，这个单元可以被 AI 很好地解决。我们是这样看这个问题的。 Koji 之前你在阿里云做 infra，现在开始深入到各个客户业务的一线现场。中间经历了一个什么样的过程？对你来说，创业的体验和经历是什么？ Kevin Ding 我觉得跨度没有那么大。做 infra 本身就是需求导向的，infra 不可能闭门造车，基本上都是以需求驱动的方式来做。 现在做客户也是一样。我们看到场景之后，客户有明确需求，我们去提炼其中的共性，然后找里面可以 scale up 的点。找到之后，就把它做成产品。 这条路径在 infra 时代就是这样的思维模式，完全相通，还是从需求出发。我们之前在阿里云阶段，也做过很多商业客户。 Koji 我自己在想，AI 现在处于落地或者产生价值的阶段，需求其实是分层的，需求的接受度也是分层的。 第一层是这个东西是不是好用，效果是不是好。是不是好用、是不是简单，有很多方式可以实现。比如现在大模型提供的 API 就非常易用。API 之外，比如 DSPy，它做的 GPT-4 Harness，也很好用。 好用解决了之后，效果怎么解决？你可以加大量 Harness 逻辑，让模型行为对齐你的需求；同时也可以做后训练，用训练的方式提升模型能力，达到更好的效果。 下沉到第二层，企业就会考虑第二个问题：做这件事 ROI 是否合理？我得有收益，没收益就不会做。 再往下，企业会追求一个“不可能三角”：成本要低，效率要高，未来还要满足隐私需求。到了这一层，需求就会很多。 所以你们为什么选择做 RL，而不是集中精力做 Harness？我们看到的是，长期来看，Auto RL 形式的 RSI，正好可以承接这两层需求，尤其是深层需求里的“不可能三角”。这其实就是你们近期发布的 Paradigm，对吧？ ### Paradigm 拆分模型职责 Kevin Ding 对。Paradigm 最初源于我们自己的需求。我们主要觉得 Web coding 太贵，所以做了一个协作式推理引擎。 这个引擎会把一个 4B size 的模型和一个 Base Model 连接在一起。因为这种协作式引擎拼接的是上下文的策略，所以它对 Base Model 没有要求。Base Model 可以是任何模型，可以是开源的，也可以是闭源的，因为我们不需要它的梯度。 我们训练的对象是那个 4B 模型。选择这个 size 有一个原因：它刚好可以在端侧，也就是 Mac 上跑起来。这意味着推理成本基本为零。但问题也随之转移了：它的效果还不够好，所以需要对它进行训练。 训练大概分三个阶段。第一个阶段，是对问题的难易程度进行分类。第二个阶段，是做路由系统：请求进来之后，小模型先接；它判断这个问题是不是自己能解决。如果能解决，就直接在端侧解决；如果解决不了，就路由回 Base Model。 第三个阶段，是 GRPO 的过程。我们开放的奖励结构包括正确性和成本，成本奖励会带一个系数。 训练一段时间之后，我们发现了一些有意思的结果。它的 baseline 表现会比纯 Base Model 有一定提升。同时，因为它通过分类把简单问题自己解决掉了，所以成本一定会下降。 有一个数据是，在 benchmark 上表现提升大概 10%；使用 Paradigm 架构，在 lambda 比较小的时候，还可以节省大概 20% 的成本。 当然，我认为这个架构的潜力肯定不只在成本。推广 Paradigm 时，成本是一个很好的突破口，但我们现在真正构建的是隐私问题的解决方案。 隐私更具有 B 端属性。企业内部的问题，归根结底可以分为公域和私域。这里的公域和私域不是 B 端和 C 端，而是指这个问题有没有一个好的 Base Model。 Base Model 不是所有问题都解得很好。公域问题，是指 Base Model 本身的 baseline 还不错；这种情况下，可以用 Paradigm 的方式训练一个 Worker Model。私域问题就比较简单，用一个端到端模型解决就好了。 Koji 所以你的意思是，Harness 再怎么进化，也有它解决不了的地方？ Kevin Ding Harness 是一种很好、很轻的方式。我们思考的是，怎么样在不投入那么多人力的同时，把“不可能三角”解决好。这就是后训练方法要做的事情。 如果你想在成本、速度和隐私这三个维度上都追求最优解，终归还是要挖掘模型本身的能力。纯做 Harness 可能解决速度问题，但隐私肯定解决不了。 Koji 你们具体解决的隐私问题，是怎么定义的？ Kevin Ding 隐私和公域、私域问题要分开看。公域问题是 Base Model 已经解决得很好，但对企业来说，有些问题不希望提交给 Base Model，有些问题则可以。 在公域上，我们会训练 Worker Model。训练 Worker Model 时，可以构造不同的奖励项。现在发布的 Paradigm 开源部分只提供两个奖励项，一个是正确性奖励，一个是成本奖励，先把成本和表现覆盖掉。 同时，还可以构造另一个奖励项，只是我们目前还没有发布，就是隐私奖励项。对于敏感 token，模型需要具备一定的 masking 能力，先挡住这一层，用 Worker Model 把敏感信息挡掉、处理掉，然后再路由回 Base Model。 Koji 你说隐私，意思就是不想把任务丢到公域，不想交给某个 Base Model？ Kevin Ding 对。不是所有信息或者上下文，对于企业来说都可以丢给 Base Model。 Koji 但 Harness 也可以很简单地路由一下。比如我在自己的服务器上部署一个开源模型，把和隐私相关的问题路由到本地部署的模型。你们不也有同样的问题吗？ Kevin Ding 所以还是要训练。这就是我们做模型训练的最终目标：模型本身的参数需要被修改。 如果用一种不修改参数的方法来做这件事，它的天花板其实是存疑的。到了深领域之后，有很多问题如果不通过训练解决，有可能完全做不到。 Koji 可以展开一下吗？在一个具体需求场景里，如果拿到了明确的数据和评价基准，你们是怎么把它变成训练目标的？ Kevin Ding 如果拿到了场景里的数据和评价基准，就可以把它们翻译成一系列奖励信号，教会模型按照目标完成任务。 但模型要真正学会，不可能单纯通过 Harness 来实现。Harness 提供的更多是流程性的东西，比如 workflow、skills 或 memory。本质上，它是在 context 上做一些工作。 如果不修改模型、不训练它，模型能够解决的问题就相对有限。而且这还依赖于你部署的模型在预训练阶段见没见过相关样本。 我们还有一个客户做 PCB EDA，也就是 PCB 板电路图设计的 EDA 软件。这是一个比较独立的深领域，绝大多数 Base Model 在预训练阶段不可能见过这样的样本。 这种情况下，即使拿一个很大规模的 Base Model 部署到本地，让它解决这个问题，再怎么做 Harness，也很难达到理想状态。最终还是要修改模型参数。 我们区分公域和私域问题，最重要的原因是，并不是所有场景都需要完整预训练。如果一个问题已经被 Base Model 解决过，比如 coding 类问题，你想让它在某个具体场景里解决，就没有必要从头预训练。把特定要求训练进 Worker Model 就好了。 而刚才提到的这种很深的领域，肯定需要一个端到端模型来解决。 Koji 所以 Thinking Machines 的 Tinker 和你们有哪些相同、哪些不同？ Kevin Ding 其实不太一样。Tinker 提供的还是 LoRA API。我们现阶段不会花太多精力做 LoRA。 LoRA 的训练当然非常有效，但它有一个要求：必须和 Base Model 绑定。在某个 Base Model 上做的 LoRA，跨 Base Model 迁移时还需要额外工作。 Koji 所以你们 Paradigm 的这个工作是和 Base Model 解耦的，可以随时更换？ Kevin Ding 对。就训练方法来说，Worker Model 和 Base Model 之间是通过上下文建立联系的。所以在训练阶段，它们是完全独立的。 Koji 在服务一个客户的过程中，刚才也提到 FDE。我理解这就是需要人入场，派人过去沟通、服务，帮客户梳理各种问题。你现在怎么理解这件事？你是在追求尽可能弱化 FDE 吗？ ### FDE 重塑交付边界 Kevin Ding 我倒没有说一定要弱化 FDE。我觉得在很长一段时间里，这个角色都会被需要。 我追求的是 FDE 这个角色的宽度。现在主流的 FDE，定义宽度很宽：他要进去理解需求，做相应适配，然后完成交付，而交付形态往往也是 Base Model 加 Harness。 我定义的 FDE，其实只要做前半段就好了，也就是把需求接回来。我们把第一个场景的需求，在 Auto RL 产品上做一次适配。后半段的交付，就更多是交付一条能够让生产数据回流、不断提升模型表现的 RSI 管道。 这样至少从时间角度看，FDE 的工作负载会下降很多。我们现在服务的也有十几个 B 端客户，最终大概由 2 个 FDE 支撑这些需求，还是可以支撑过来的。 Koji 但比如客户需求接回来之后，Auto RL 的部分是不是还要由其他同事承接？ Kevin Ding 需要。因为接回来的需求，在第一次做一个场景时，奖励结构本身还是需要做一次适配。 Koji 那这是不是也可以算某种意义上的 FDE，只是定义得更泛化一些？ Kevin Ding 我觉得不能算。我们自己的角色分配是，接回需求的人更加偏基础和通用产品，负责通用板块。 他们要做的是，在现有奖励结构下，不断把其他场景接入进来，主要解决跨领域的问题。对于 FDE 来说，把一个个需求接回来就好了。它是一个 T 字型结构。 Koji 听起来你们非常追求 Business 能够 scale 起来。 Kevin Ding 一定是这样的。不然就会变成技术咨询服务这种全方位一体的公司。不是说这样的公司没有存在意义，而是如果采用这种模式，客户策略就应该选择最头部、最大的客户，最好一家客户就能 cover 你整个生命周期。 但我的判断是，我们一开始讲 ASI 到来的形态是 Agent 蜂群，它本身就是一个分布式市场，所以不能用中心化思路去做。 如果采用前一种方式，把企业里所有事情都做掉，那就是 Apply Compute 的路线，用中心化方式去做。但这是我们的一个观点。下半场的光谱非常广，我觉得容得下任何一种形态存在。 我们选择的路径，是更多用奖励结构，让多模态场景的问题变得越来越通用。随着收集到的多模态场景越来越多，奖励本来就有一定复用性；有复用性，就意味着可以用泛化能力去解决这个领域里的新问题。这样我认为能够跑出一个飞轮，这是我们内部的视角。 从外部视角来看，我们对外定义产品时，需要划定清楚我们、客户以及双方之间的边界。如果边界划不清楚，这个 Business 就会非常模糊。 我们划定的界限，也解释了为什么选择 RL、选择 Auto RL：我和客户之间传递的无非是数据集，最后回给客户一个更新后的模型。我们的管道是无状态的，客户看到的是用自己的数据拿到了一个提升后的模型。这个结果对双方来说都是可以接受的。 Koji 如果模型训得越来越好，后面需要的训练越来越少，那你们会赚得更多，还是赚得更少？ Kevin Ding 它其实分两层。一层是客户给我数据，我把模型还给他，这属于应用模型。如果客户的场景是静态的，那可能训练一次就够了，把问题都集中解决掉就行。 但绝大多数场景不是这样。比如我们做工艺和 AVI 质检，上游来的需求每天都在变化。持续训练的原因，是需要维持应用模型的能力，不能让它掉点。 Koji 工艺或者 AVI 质检，为什么会每天变化？我理解它们不是相对固定的工作吗？ Kevin Ding 如果只从流水线理解，确实是固定的。但实际上，具体 case 是千变万化的，一直在变化。 这些客户接到的订单，需求肯定不是固定的。同一条生产线上的生产也是混杂的。它不能做粗分类，因为看起来流水线是固定的，但工艺和质检这种更深层次的问题里，一点细微差别都会对结果产生很大影响。 只要场景在变化，就需要通过持续学习，保证应用模型始终维持在一定水平之上。 Koji 你们现在和客户交流时，他们应该也会同时看其他可能帮他们解决问题的提供商，比如模型厂商或云厂商。你们遇到最多的竞争对手是谁？ Kevin Ding 目前来说，我觉得竞争还不是特别多。我们做的深领域，本身具备一定壁垒，不是一个非常开放的领域。 我们在这些领域面临的竞争，可能是一些传统 SaaS 服务商。他们本来就在企业里深耕了很多年。我们进去做的事情，如果和他们的业务没有冲突，大家就各自安好；如果有冲突，可能就要谈合作模式。 纯粹做 RSI 的竞争对手现在比较少，至少在我们选择的领域是这样。当然，其他领域就有很多。 Koji 你指的具体是什么领域？ Kevin Ding 一些 Agent 领域。为什么我要举 Mercury 这个例子？因为我觉得它是一个做得很成功的案例，它和 Harvey 合作，在法律领域其实有很多这样的案例。 如果我们要做类似的事情，就会直接面对它的竞争。 Koji 还是前面那个问题。我不确定刚才是不是已经回答了：SaaS 很难，你们也做 To B，为什么你们就不难？ Kevin Ding 当你把 B 端里面所有事情都做了，它就是一个很难的事情。但你看我们的场景选择，有三条准则。过滤下来之后，场景本身的切面就相对整齐。 再一个，B 端生意最本质的核心还是算账，ROI 是一个很重要的点。 Koji SaaS 为什么算不清楚那笔账？你们为什么能算清楚？或者说，你觉得你们有可能比它们算得更清楚？ Kevin Ding 原因还是因为这里面引入了一个变量。AI 时代做 B 端生意，和软件时代做 B 端生意，变量就在模型本身。 现在的模型还是很伟大的，能解决很多问题，只不过要正确地教会它。我们做的事情，是教会模型把问题解决掉，而不是提供一种软件式的固定服务。 这两者的厚度完全不一样，同时模型又能够创造更大的 ROI 空间，所以成交模式相对来说就容易很多。 Koji 你怎么看云厂商未来潜在的竞争威胁？它们似乎也能做你们做的事情。你们今天卖给客户时，还是需要 GPU、CPU，还是需要找云厂商配合部署。云厂商会不会慢慢把你们吞噬掉？ Kevin Ding 首先，如果这个领域有越来越多的人来做，对我来说是很开心的事情。大家在 RSI 这条路线上都有自己的坚持和探索。 第二，云厂商的业务非常广，目标也非常多。它和模型预训练会变成一样的结果：当你要做一个平台，而这个平台的目标超级多时，最后落下来的形态就不可能像我们这么敏捷、这么专用。 Koji 你觉得今天的基模和多模态基模够用了吗？如果它们继续进化，出现新的 SOTA，对你们来说还会产生显著的价值提升吗？ ### 生产模型需要持续训练 Kevin Ding 我觉得现在的基模状态是够用，也不够用。 说它够用，是因为大家从宏观认知和感性认知上，都觉得基模很强。说它够强但又不够用，是因为一旦放到生产环境里跑，你会发现还要补足很多工作。 不是把模型 API 接到现场，它自己就能跑起来，把问题解决得很好。 Koji 所以这就是你们做的工作？ Kevin Ding 对，我们做的就是其中很多很多的工作。我们也在尝试找到一条相对收敛的路径。 解决这个问题最直接的方法就是堆人，什么地方不够就用人去补。但我觉得这种方向不太可扩展。 所以我们的扩展方法，是在初期用一定人工把奖励网络构建起来。这样在后续扩展时，相对来说会是一个更好的形态。 Koji 构建奖励网络有什么方法论或者窍门吗？ Kevin Ding 首先要在模态上统一，这是最重要的一点。跨模态构建奖励网络有很大的难度和挑战，因为不同模态完全不一样。 但在同一模态下做，总归还是有迁移性的。 Koji 刚刚你也提到了基座模型的演进。为什么你们长期来看要主推 Paradigm？ Kevin Ding 因为现在所有 AI 领域的创业团队，基本都是站在巨人肩膀上往前走。 Paradigm 这个架构本身就是在基模的基础上，增加一个 Worker Model 和 RSI 的 patch。基模演进本身，在 Paradigm 架构下是一件很好的事情。基模越好，说实话，对 Worker Model 来说压力就越小。 Koji 那它和基模之间是不是也存在类似的竞争关系？ Kevin Ding 基模其实不会形成太多竞争。基模总归有它能解决的问题宽度。在基模解决的宽度之内，就沿着 Paradigm 架构走；如果超出基模的宽度，就做一个端到端模型。 它们对后训练的依赖没有变化。我们为什么说自己是面向需求的？因为只有从需求侧，才能拿到有效的场景级奖励。 拿到场景级奖励之后，是训练 Worker Model，还是训练 Base Model，这不是客户来选择的吗？如果未来有客户说，我就是想把公域问题做成一个私有模型来解决，也可以，这是他的选择。 只是从大的范围来看，很少有人会这样做。未来或许会有一家公司，或者某个地域说我要做主权模型，把基础模型重新做一遍，这也可以。我们面向需求，需求才是我们的驱动力。 Koji 最后聊点轻松的。创业到现在，最有成就感的一件事情或者一个时刻，大概是什么？ Kevin Ding 我觉得是近期。最近我和 CTO Frank 讨论 Paradigm 这个架构时，一开始我们的观点也不一样。 我觉得最有成就感的一点，是我们达成共识的那一刻。 Koji 是你说服了他，还是他说服了你？ Kevin Ding 不存在谁说服谁。我们是很开放的，大家一起论证这件事。内部有很多这样的论证，有时候会直接把大家关进小黑屋讨论。 具身智能领域我们也论证过。这样的论证对我很有帮助，大家从不同视角看这件事情，然后达成共识的那一刻，会很有成就感。 Koji 感觉很有成就感。 Kevin Ding 是的。这也是为什么我很喜欢和大家一起聊这些事情。大家带着不同的视角进来，这些视角本身都是自带奖励信号的。 在多目标奖励信号下提炼出来的结果，有可能就离真相很近了。这个时候我会觉得比较有成就感。 Koji 你平时会用哪些 AI 产品？ Kevin Ding 最近 coding 用得多一些。比如 Pi 这样的 coding Agent，它是一个极简的 Agent，感觉很好用。还有 Dify，Dify 还是很强的，已经堪比历史上 stars 增长最快的项目之一了，应该有 14、15 万了。 Koji 我们录这个播客的时候，才三天？ Kevin Ding 对。 Koji 你喜欢用什么模型？此刻有一些偏好吗？ Kevin Ding 我之前主要在 Claude 上用。近期的话，Kimi 还是很强的。前段时间 Gemini 出来的时候，我也会用。另外就是现在的千问系列。 从 Hugging Face 的数据来看，最近 14 号发布的那份报告里，千问在实际运行时的下载量还是很高的，也已经成为使用量比较大的模型。 包括千问 3 的 8B、27B 小模型，我觉得反响也非常好。 Hugging Face 那份报告里还有一个数字挺有意思：本地模型的下载量里，100B 以上的模型下载量很小，基本是 100B 以下的模型占据主流。这说明我们做 Paradigm 这个架构，方向上和社区认知也是相似的。 大家为什么还会下载这些小模型？这说明需求世界是多元的，不是所有需求都要归拢到一个大的 Base Model 上统一解决。Hugging Face 上依然有海量的小模型下载量，就代表有大量需求需要用分布式形态来解决。 所以在这个时间点推出 Paradigm，我觉得也是一个非常正确的时间点。 Koji 最后一个问题。你现在最期待达成的下一个 milestone 是什么？ Kevin Ding 下一个 milestone，最重要的就是希望 Paradigm 能够获得社区最主流的认可。 这个认可的 MLS 衡量基准，可以看它在生产场景里是不是真的解决了一些固定问题，而不只是 benchmark。毕竟这是我们长期关注的方向。 中期和短期的方向，我们现在已经验证得比较好了。 Koji 好，谢谢 Kevin。 Kevin Ding 好的，谢谢。 Koji 我们今天先到这里。再见。 Kevin Ding 再见。