AI 下半场，不会只剩一个超级模型｜对谈 Kevin Ding：Pyromind 创始人/CEO
👦🏻 播客采访：Koji
🥷 整理编辑：十字路口
🧑🎨 排版: Zeoooo
🚗 本周「十字路口」的嘉宾是 Pyromind 创始人 / CEO Kevin Ding。Pyromind 所在的赛道，常被称作 RL as a Service，也就是强化学习即服务、或后训练即服务。公司前不久完成天使轮融资，投资方包括高瓴、百度风投、蓝驰、Atypical 等机构。
但在 Kevin 看来，RL as a Service 只是起点，不是终点。他在节目里说，Service 只解决了一半问题；真正要让 Agent 在生产环境中持续改进，还需要把训练、奖励、反馈、部署和数据回流串成一条可以自动循环的管道——也就是 Pyromind 正在押注的 AutoRL。
我们也聊到了 Pyromind 的真实落地场景：工业质检、工艺参数优化、GUI Agent、Coding Agent，以及企业里那些 ROI 明确、数据足够富集、好坏标准相对清楚的生产问题。
同时，这期也会讨论一个非常现实的问题：企业 AI 到底怎样才能不是项目制咨询？
Kevin 坦诚，第一次进入客户场景时，FDE 的工作不可省：要理解数据制式、评价基准、业务流程和奖励信号。但 Pyromind 追求的是让这部分工作在相似模态和相似场景中逐渐递减，把一次性交付沉淀成可以横向复制的 AutoRL 管道。
Kevin 重点分享了他们的新工作 PyroDash：一个由 4B 小模型、强基座模型和协作引擎组成的大小模型协作架构。Kevin 认为，这背后对应的是一个更大的判断：需求世界是多元的，不是所有问题都应该被收拢到一个中心化大模型里解决。
这期适合所有关心 AI Agent、后训练、企业智能、工业 AI 和 AI infra 的朋友。
微信收听播客：
小宇宙收听播客：
🎬 视频播客已同步上线于 @Koji杨远骋 的视频号、小红书、哔哩哔哩、Youtube 等平台
快问快答
👦🏻 Koji
请问 Kevin 你的年龄？
👨🏻💻 Kevin
我是 94 年的，32 岁。
👦🏻 Koji
请问你的求学经历？
👨🏻💻 Kevin
伦敦国王学院 King's College London。
👦🏻 Koji
MBTI 和星座是？
👨🏻💻 Kevin
如果是按测试结果来看是 INTJ，但是我的感觉可能在 I 和 E 之间。星座是摩羯。
👦🏻 Koji
一句话介绍一下 Pyromind。
👨🏻💻 Kevin
最终定位就是一个 AutoRL，它跟现在大家一直在讨论的 RSI 这个方向，其实相当于是一个比较具象化的实现路径。
👦🏻 Koji
融资情况呢？
👨🏻💻 Kevin
我们是去年公司成立之后就做了一轮，投资机构包括高瓴、百度风投、蓝驰，还有 Atypical。
👦🏻 Koji
目前团队的规模是？
👨🏻💻 Kevin
我们现在有 20 多个人。
👦🏻 Koji
现在收入和利润方便讲吗？
👨🏻💻 Kevin
具体数值就先不 share 了，但是现在我觉得比较振奋人心的一点是，我们初步跑通了 PMF。
👦🏻 Koji
什么样的 PMF 跑通了？
👨🏻💻 Kevin
两个方向。
一个方向就是证明我们提供 AutoRL 这种方式实现的 RSI 在生产环境是有价值的，它的商业模型至少是成立的。
第二点就是它的可扩展性。在横向的场景和客户的复制上，我们的工作量是逐步递减的。
👦🏻 Koji
明白，咱们在创业之前做过些什么呀？
👨🏻💻 Kevin
我之前其实有很多精力是放在偏 Infra 这里的。我之前在阿里云，也做了弹性 GPU 实例，包括训练 GPU 的这些集群。
AI 终局为何是 Agent 蜂群？
👦🏻 Koji
当时是看到了什么样的机会，决定创业做 Pyromind？
👨🏻💻 Kevin
当时我的想法是，模型预训练这个事情，到现在为止其实远远没有到终结的时候。
当时看到一个趋势，就是到 2025 年下半年，看到无论社区、硅谷还是国内的技术圈，大家都在讨论 AI 可能要进入下半场。下半场的说法就出现了两个方向。
一个方向是认为我们继续沿着预训练走，ASI 到来的形式会是一个超级庞大的、中心化的模型，它能够解决绝大多数场景里面的问题，效果还足够好。
另一个方向是，它最终 ASI 的形态会是一个服务化的形态，是一个 Agent 蜂群的形态。
我个人更偏向于后者，因为我觉得这个更实际。
我们这个世界上需要被 AI 解决的问题和场景，无论是从当下时间点看，它就已经是无穷无尽的了。 同时，随着时间的推移，它还会不断产生新的场景，而且场景本身也不是静态的。
在这样的模式下，我们尝试用一种有限参数的模型去泛化掉无限的场景，至少在 Transformer 架构上实现还是蛮有挑战的。
👦🏻 Koji
到目前为止又过去了一年多，你有看到一些信号，让你感觉一开始的 bet 越来越成立了吗？
👨🏻💻 Kevin
首先从理论上，我们看到第二条路必然成立。我不能证伪第一条路，但我能论证的是，第二条服务化的路线是一定成立的，因为需求一直都在那里，并且一直在增长。
这一年我看到的一个变化是，大家为什么现在去提 RSI，而在之前热度没有那么高。这其实就是服务化带来的一个结果。因为部署的 Agent 变多了，我们可以想象一下，正常一个人日常带了几十个 Agent 去做一件事，是不可能有精力去维护每一个 Agent 的演进的。
RSI 被需要，是因为 Agent 现在开始多起来了。当我们把一个个 Agent 嵌入到场景里面的时候，对它最终的衡量方式是它得在一定的时间轴上表现都符合预期。
实现的方法就是 Agent 需要自我迭代，Agent 本身需要有自我改进的能力才能做到这件事。
RLaaS 只解决了哪一半？
👦🏻 Koji
所以一开始做 Pyromind 的时候，就想到了要用 AutoRL 去做 RSI 吗？还是在过程中慢慢浮现出来的？
👨🏻💻 Kevin
实话说，其实是过程中浮现出来的。
我们去关注后训练这个场景，一方面是我们自己本来就在看这个方向，另一方面，后训练这个事情对我们自己影响也比较大。你会发现，以 RL 为代表的后训练技术，其实是拿到环境的反馈然后去更新，它是一个持续的过程。
对我们自己研判方向，我们团队也是这样子的。我们在创立之初，认为做到 RL as a Service，做到一个扁平的 service 形态，其实就已经差不多能满足这些 Agent 部署的要求了。但我们后来发现这依然是不够的。因为 service 面向的对象终归还是要有一个 Developer 在那边去驱动 Agent 去改进的。
在这个阶段我们才去想，其实 service 只解决了一半的问题。我们真正把 RSI 跑起来要解决两个问题，一个是 Training Infra，一个是奖励。
所以我们就开始规划 AutoRL 要怎么跑起来，同样的，奖励就纳入了我们的 scope。
👦🏻 Koji
能用一个具体的客户例子讲讲，只单独做 RL as a Service，和做 AutoRL，具体的服务内容有什么不同吗？
👨🏻💻 Kevin
比较好的例子是我们在 GUI Agent 领域的一个客户。他们下游有很大的消费级部署量，会不断收集到很多用户特定的需求，以及他们自己的产品迭代需求。
我们一开始提供的 RL service 是给他们提供了一个 Studio，把一个通用的 training pipeline 固定下来。但他们依然需要不断投入自己的算法工程师去更新 Agent 本身，我们只帮他们把训练这件事情解决得很好。
因为一个训练要完整解决、完成一版模型更新，除了需求侧的分析、算法设计和训练，后端的 Infra 也要被解决。当时我们把 Infra 的问题全部帮他们解决掉了，但他们依然没有摆脱要投入大量人力去搞这件事情。
到了第二期，我们将 GUI 方向的奖励做好后，发现这个 loop 其实是可以自动化跑起来的。只要他们末端部署的 Agent 能源源不断地收上来用户在真实环境下的反馈，我们就在想，为什么不让它自主地循环跑起来。所以我们在第二期给他们推了 EchoMind 这套产品。
👦🏻 Koji
现在提供的主要产品有两个：一个是 Pyromind Studio，另一个是 EchoMind。可以分别介绍一下它们是什么样的产品吗？
👨🏻💻 Kevin
Studio 是我们提供的解决训练 Infra 的 Serverless 服务。我们会在 Studio 上实现大量训练所依赖的逻辑节点。
之所以强调是逻辑节点，因为开发者在配置节点时不需要关心物理机上的实现，他们更多只是配置训练的参数。逻辑节点横向是支持 scaling 的，单卡算力、单台到多台，都可以在一个逻辑上扩展，扩展工作是由我们完成的。对于训练开发者来说，只需要把训练参数以及像 DP size、TP size 配备好就可以了。
对于 EchoMind 这套产品，我们把刚才叙述的整个 RSI 流程都包在了背后。我们给用户透出的是一个 proxy（一个代理的 URL），这个 URL 只要插入到某一个 Agent 里面，就可以源源不断地把 Agent 在真实环境下的轨迹抓取下来，形成一个相对整齐的数据集。
这个数据集通过奖励结构，生成 training pipeline 进行训练，拿到结果后再部署回去。这一套流程全部被 EchoMind 包起来了。
谁最适合 AutoRL？
👦🏻 Koji
Pyromind 现在典型的客户画像是什么？
👨🏻💻 Kevin
我们筛选客户时，**核心是看他们是否需要真实世界的数据。**并且，这些真实世界的数据首先要产生于生产场景，其次最好是在现有模型的能力之外。这对于模型效果的提升最明显。
我们当时在想，哪里的 Real-World Data 最富集？我们当下有一些比较重要的客户集中在工业领域，比如英伟达上游的这些企业。
他们有个特性，经过过去几年的制造 1.0、2.0 改造，企业内的数字化做得很不错，长期的生产也积累了非常可观的数据。这是一个指标。
第二个指标是，工业场景对于自己的精益生产是有定义的。收上来的数据天然带有相对明确的好坏标签，标注的问题在生产环节就被天然解掉了。
与此同时，毕竟这也是商业行为，我们也要衡量 ROI。在这三个条件都满足的情况下，产业链上的工业客户是一个比较好的画像。
👦🏻 Koji
工业客户是一类。还有其他典型的客户画像吗？
👨🏻💻 Kevin
还有像 Agent 或者是和具身相关的。
具身相关的我们也会看，但当下来看，具身是一个相对独立的板块。我们的目标还是去做后训练驱动的 RSI，当下在偏软的领域肯定会做得更快。因为具身还需要去考虑硬件部分，这是一个更复杂的问题。
👦🏻 Koji
在给企业做 RL，不管是 RL as a Service 还是做 AutoRL 的过程中，最花时间、最花钱的是什么部分？
👨🏻💻 Kevin
最花时间的实际上是初次进入一个场景时的 FDE 工作。虽然我们做 RSI，但我们并不排斥完全的 FDE，因为要让 RSI 渗透到某一个场景，初次进入时的冷启动阶段是不可省的。
我们需要把他们场景里面的数据制式、评价基准，与我们自己的 Reward Agent 或 Reward Model 适配到场景上，这比较花时间。
但好处是，在这类行业中，初次冷启动虽然需要做一些工作，但后面 scaling 起来，工作量是递减的。这是我看到的一个比较好的现象。因为做奖励这个事情，最终还是会收拢到模态上，在相似模态上，其实有相当一部分工作是可以复用的。
👦🏻 Koji
去年大批做 RL as a Service 的公司，现在大家都和你们一样，慢慢开始做 AutoRL 或者叫自己的 RSI 了吗？
👨🏻💻 Kevin
我觉得大家是有分化的。因为对于下半场的需求来说，它非常丰富且宽广。
比如我们同期去看的一些公司，比较出名的像 Applied Compute，到现在已经更往前走了一步。他们会提供一个非常完整的服务基础设施，把 Agent Serving 这些东西全部都做了。它面向的可能是几个头部的企业，把企业内所有和 Agent、AI 相关的东西全部包揽。这是一个路线。
另一个路线是近期比较出名的 Trajectory，它是 DeepMind 的人出来搞的一家非常优秀的公司。他们做的东西和我们的理念相似度相对会高一些，他们就是单纯地去做 RL。同时跟 Mercor、Clay、Harvey 也有一些合作。
他们的定义跟我们会相对相似，我们更期望做到的是 Auto 这件事情。我们去把无状态的 RSI 能力提供出去，做成可以平台化的东西。
👦🏻 Koji
无状态的？
👨🏻💻 Kevin
对。这两个分支的属性不同：前者 Applied Compute 相当于把企业里面所有的场景全部包掉了，是一个更宽并且更重的方式，它是在一个企业内纵向去 scaling；而后者 Trajectory 的方向是只把训练这一件事情做好，横向去 scaling。我们更倾向于用后者。
我们对环境的理解是，它原本在 coding 领域是一个非常典型的东西。你提供一个 compiler，每生成一个新的代码片段去 compiler 跑一下，都能够拿到一个比较强的奖励信号，判断它是否通过。它的特性是，跟你本身生产环境里面的这些信息是不耦合的，是可以被抽离出来的。
但对于实际的生产环境，这样的环境非常有限。比如刚才提到的 GUI 类的 Agent，想把每个用户的特定需求做好，是不能脱离它的用户上下文存在的。如果脱离了，就缺乏生产价值；如果跟用户上下文耦合在一起，它就是一个有状态的环境。
所以我们要去做的事情，是在这么长的链路里，找到可以横向 scaling 的无状态的东西。这个东西不单纯是一个 environment，而是一个 AutoRL 的管道。
你给它喂数据，它拿到数据后通过 Reward Agent 及 Reward Model 拿到 Reward Signal，去迭代一轮。这个 AutoRL 管道以及 reward 本身是无状态的，跟生产上下文不耦合。
👦🏻 Koji
这里我有点困惑。它一旦是奖励信号，应该是在真实的生产环境里出现的，怎么能抽离出来呢？
👨🏻💻 Kevin
在具体场景中，它需要做一层解耦。
奖励信号本身，实际上是当模型在场景里面 rollout 一次，对应的 Reward Model 或者 Reward Agent 去给出一个优势，以此找到更新的方向。这是一项方法。
第二种方法是，生产场景回流回来的数据，它包含了一些人工的 judgment，这其实也是一种奖励。
这两个信息本身跟它的上下文已经解耦掉了，它是包含在用户回流过来的数据集里面的，而不是包含在环境里面的。
这里的模式区别是，对于我们要去做一个横向可以 scaling、能卖给不同客户的产品，我不能去把 A 客户的状态打包进我的产品里再卖给 B 客户，这样是不行的。
👦🏻 Koji
工业领域，你们具体帮他们做了什么？
👨🏻💻 Kevin
工业上我们现在偏软的主要看两个场景：一个是和工艺相关的工艺改进，第二个是做质检，这两个都是典型的多模态问题，也是做 post-training 的甜点区(Sweet Point)。
工业领域有个好处是，无论是工艺还是质检，数据的富集程度是无法想象的，而且它对结果好坏都有明确的评价基准。
👦🏻 Koji
质检比较好理解，工艺可以举一个更具体的例子吗？
👨🏻💻 Kevin
工艺类似于电镀。简单来说，在生产线上有一批参数需要配置，配置好了，产线后段就能拿到想要的产品；参数配置得不合适，拿到的就不是自己想要的东西。
目前的做法依然是靠老师傅，这是一个个人经验驱动的事情。我们去做后训练的目标，就是能够有效地根据它历史的数据和未来增量的生产数据，把人做这个事情的经验迁移到模型里。
这样模型在长期品控稳定的保障上，或者是随着增量数据变多后超越人类的表现上，模型现在是有能力做到的。
👦🏻 Koji
你们怎么收费呢？
👨🏻💻 Kevin
我们现在有两层产品。
一层产品是我们定义为 RL as a Service 的 Service 层，也就是 Studio。对于用户来讲，它更多是自助式服务，计费方式很简单，就是 by 资源（类似于 CPU、存储、GPU 这样的资源消耗）。
对于上层的 AutoRL 产品，我们就是 by 场景价值来计费，计费方式是 quota。我们会根据场景里更新的频率来限制实例的 quota 额度。因为对于 EchoMind 这样的 AutoRL 产品，我们是嵌入了我们提供的奖励价值的。我们相当于除了把训练 service 做好之外，同样用我们自己的奖励结构给出了正确的更新方向。
所以对于客户来讲，他们什么都不用管，最后收到的是一个更新好的模型。
👦🏻 Koji
所以第一部分 service 相当于训练模型一次性的收入，后者是更长期的收入？
👨🏻💻 Kevin
其实前者也是长期的，只是两者的边界在于谁来维护 RSI 的管线。
如果是 Studio 的用户，管线是客户自己在做的，包括 Reward Function 也是客户自己写的，我们只提供稳定的 Infra Service。
但对于 EchoMind 来讲，因为我们自己介入了实际场景中的问题，我们会把它内化到我们的 Reward Model 上面，由我们来维护这个事情。
👦🏻 Koji
一个典型的用户，向你们付费大概是什么量级？
👨🏻💻 Kevin
因为我们做的 RSI 形态适配的光谱很广。对于大颗粒度的企业，在 ROI 很明确的场景下，单体客户付费基本上也是到百万到千万人民币的区间。
AutoRL 能改进的场景，可以有这种放大效应非常大的高 ROI 场景，也有一些偏 Developer 做 coding 的很小场景。对于小场景，付费的颗粒度就比较小。
我们之所以一直强调横向，是因为 AutoRL 应该无缝地渗透到所有类型的 Agent 里面。无论是大颗粒度的 B 端客户，还是偏 C 端、 Pro-C 端的客户付费，都是取决于 Agent 本身能创造多少效益。
我们的 EchoMind 计价是单一的 quota 计价。我们很容易去区分场景：对于高价值场景，生产 loop 积累的数据量大、要求高、训练轮次多，对应的 EchoMind quota 消耗就会是一个非常可观的数字；而对于一些 Pro-C 端的窄 domain 场景，只要达到 baseline 就可以，积累的数据没有那么多，quota 消耗就比较少。
👦🏻 Koji
当说 quota 消耗的时候，说的是 Token 消耗吗？
👨🏻💻 Kevin
其实是我们定义的一个资源单元，用来衡量 EchoMind 做一轮 RL 在嵌入奖励价值下的单元。
👦🏻 Koji
它和什么绑定呢？
👨🏻💻 Kevin
它跟我们自己内部的成本账挂钩。比如做多模态的长链轨迹，做一轮的成本是 X，我们在嵌入奖励价值后，会对 quota 进行定价，通常是在 X 的基础上往上加一个百分比。
👦🏻 Koji
你们的成本主要是 Token 成本，还是什么成本？
👨🏻💻 Kevin
我们实际上是训练消耗的资源成本，主要还是 GPU、CPU 这样的资源。
误报率如何从 23% 降到 8%？
👦🏻 Koji
现在企业主要找到你们，他们会怎么表达他们的需求？
👨🏻💻 Kevin
这涉及需求侧。客户不关心也不理解实现的细节，最直接的方式就是结果。
为什么我们去做像质检和工艺这两个领域？因为这两个领域结果是显而易见的。对客户来讲，他们只问一个问题：我需要付出什么，付出之后能拿到什么。把这个解释清楚就好了。
这也是为什么我们觉得 RL as a Service 不够。如果我们面向这样的客户只提供一个 service，还需要他们自主去开发，这显然不合理。我们提供 EchoMind，可以明确地告诉他们，在历史样本上经过 X 轮训练，能拿到什么样的指标。
在质检领域，我们可以把误报率从 23% 直接降到 8%，这只是在大概 1 万张的样本上去做的。这样客户的成本和收益就非常明确了。
👦🏻 Koji
那他们一般怎么理解你们的报价？毕竟你创造了一个新的定价体系，到他们那，会对标什么去理解价格？
👨🏻💻 Kevin
客户对价格的理解，更多是在于这件事情在场景上的 ROI 有多少，以及付出的代价在 ROI 里的占比，以此来判断值不值得搞。对我们来说，主要的消耗其实主要还是算力和电的消耗，总归下来这个账是双方都算得过来的。
我们选场景时也会去挑那些放大效应比较好的。 企业内不是所有场景我们现在都做，比如一些偏办公、偏发票、偏差旅的 Agent，我们做起来就会比较吃力，因为它的 ROI 不好衡量，定价体系在这些场景上很难说得通。
👦🏻 Koji
有没有什么类型的需求是总找你们，但你们觉得确实在这个时候就不做、拒绝的？
👨🏻💻 Kevin
一个是 ROI 不明确的。
我选择场景有三个依据：
第一是 ROI 必须是可衡量的，否则不好定价；
第二是不要偏离我们现在的研发主线，我们目前主要搞多模态场景；
第三是场景本身在企业内以及跨企业的扩展性。
符合这三个条件的，在偏软的领域目前就是工艺和质检。比如电镀工艺在所有的 PCB 行业都是通用的，而可见光和结构光质检在几乎所有的制造业也是通用的。
👦🏻 Koji
听起来还是蛮和它其他环节解耦的？
👨🏻💻 Kevin
倒也不能说完全解耦，因为流水线前后的环节都是息息相关的。
现在有一个挺好玩的 case。生产流水线很长，我们会把流水线中 PQ Phase（Process and Quality）的控制整个去出一个更抽象的报告，这就是我们 Process and Quality 这种控制。
好处是，它是可以被 AI 很好解决的一个单元。我们去看是这么看这个问题的。
企业 AI 如何破解不可能三角？
👦🏻 Koji
你之前在阿里云做 Infra，现在要深入到各个客户的业务一线现场，这中间是一个什么样的过程？
👨🏻💻 Kevin
其实我觉得跨度没有那么大。做 Infra 本身就是需求导向的，不可能闭门造车。
现在做客户也是一样，看到场景、了解需求后，提炼出共性，寻找可以 scale up 的点，然后把它做成产品。这个思维模式在 Infra 时代完全是相通的。
👦🏻 Koji
就还是从需求出发？
👨🏻💻 Kevin
对，我们其实之前在阿里云阶段也做了很多商业的客户。
AI 在落地的阶段，需求的接受度是分层的。
第一层是这个东西是不是好用，以及效果是不是好。 是不是好用、简单，有很多方式可以实现，比如易用的 API，或者像 DSH（DeepSeek Harness）这种工具。效果可以通过加大量的 harness 逻辑去对齐需求，也可以通过后训练提升模型能力。
下沉到第二层，客户就会考虑第二个问题：我做这个事情，ROI 是不是合理？我得有收益，做这事没收益我就不会做了。
再就是，在企业里面，需求到第二层时，就会追求一个不可能三角了：既要成本好，又要效率好，未来还能不能满足我的隐私需求。
所以我们选择去做 RL 并在长期将其做成 RSI，而不是去集中精力做 harness，是因为我们看到，长期来看，基于 AutoRL 形式的 RSI 可以完美承接这两层需求，尤其是解决不可能三角。这就是我们近期发布的工作 —— PyroDash。
4B 模型如何更准更省？
👦🏻 Koji
要不要给大家讲讲 PyroDash 到底是什么？
👨🏻💻 Kevin
PyroDash 最初源于我们自己的需求，因为 Vibe Coding 实在是太贵了。
我们做了一个协作式推理引擎，它把一个 4B size 的模型和一个 Base Model 连在一起。因为这种协作式引擎拼接的是上下文，所以对 Base Model 没有要求，开源、闭源都可以，我们也不需要它的梯度。
我们训练的对象是 4B 的模型。选择这个 size 是因为它刚好可以在端侧（比如 Mac 上）跑起来，这意味着推理成本为 0。但问题是它本身的效果不够好，所以需要对它进行训练。
训练大概分为三个阶段：
第一阶段做难易问题的分类；
第二阶段做冷启动。 当一个请求打过来，小模型会先承接，并判断这个问题自己能不能解决。如果能解，直接在端侧解掉；如果解不了，他就会路由回 Base Model。
第三阶段是一个 GRPO 的过程，我们开放的奖励结构是一个正确性和一个带系数的成本奖励。
训了一段时间后，它的 baseline 表现比纯的 Base Model 会有一些提升。同时，因为小模型过滤并解决掉了简单问题，成本一定是降的。在 Benchmark 表现上，它提升了大概 10%，当 Lambda 比较小时，还可以省掉大概 20% 的成本。
这个架构的潜力不仅仅在于降低成本，我们目前在构建的是它的 B 端属性更强的隐私保护能力。
企业里的问题总归可以分为公域和私域。公域是指基座模型本身 baseline 表现不错的问题。在这种情况下，可以用 PyroDash 这种方式去训一个 Worker Model。私域问题就更简单，一个端到端的模型解掉就好了。
👦🏻 Koji
所以你觉得 harness 再怎么进化，它仍然有它解决不了的地方？
👨🏻💻 Kevin
Harness 是一个很轻、很好的方式，但如果想在成本、速度和隐私三个维度上追求最优解，终归还是要挖掘和修改模型的能力。
纯做 harness 能够解决速度，但隐私是解决不了的。
👦🏻 Koji
所以 harness 不能够解决隐私问题，咱们怎么解决具体的隐私问题，怎么定义这个？
👨🏻💻 Kevin
隐私问题需要公域和私域分开看。
在公域问题上，我们训练 Worker Model 时，可以构造不同的奖励项。目前开源的 PyroDash 提供了正确性奖励和成本奖励。
我们还没发出来的另一个工作是隐私奖励项，它能让 Worker Model 对敏感 Token 具备 Masking 能力，挡一层敏感信息，处理后再路由回 Base Model。因为对企业来说，不是所有的上下文都可以毫无保留地丢给基座模型的。
👦🏻 Koji
但是 harness 不也可以简单路由一下，如果本地部署一个开源模型到自己的服务器上，把隐私相关的问题，路由到本地部署的模型？
👨🏻💻 Kevin
所以它就是个不可能三角。如果用这种方式，你怎么确保这个模型生成的结果能满足你的深度场景要求？
👦🏻 Koji
你们不也有一样的问题吗？
👨🏻💻 Kevin
所以说要训练。这就是我们去搞模型训练的最终目标，模型本身的参数需要被修改。
如果用一个不修改参数的方法来搞这个事情，它的天花板其实是存疑的。因为到了深 domain 之后，有很多问题如果不通过训练解决，是有可能完全做不到的。
👦🏻 Koji
这个可以展开一下吗？
👨🏻💻 Kevin
我们在一个需求场景上，如果拿到了明确的它的场景里面的数据或者评价基准，它是可以去翻译成一系列的奖励信号的。我们可以教会模型怎么样去按照目标来完成任务，但模型要学会它，是不可能单纯通过 harness 来学的。
Harness 更多提供的是一些流程性的东西、workflow 或者是 skills 或者是 memory，在本质上都是在 context 上做工作。如果不去训练模型，它能解决的问题非常有限，而且还依赖于你本身部署的基座模型在预训练阶段的样本分布。
比如我们有一个做 PCB EDA 方向的客户，这是一个非常独立的 domain。绝大多数基座模型在预训练阶段是不可能见过这样的样本的。哪怕你拿一个很大 size 的 Base Model 部署到本地，你让它解这个问题，再怎么做 harness，都很难达到一个非常理想的状态，最终还是要对模型参数本身去做修改的。
👦🏻 Koji
Thinking Machine 的 Tinker 和你们相比，有什么相同和不同？
👨🏻💻 Kevin
其实不太一样。Tinker 提供的还是 LoRA API。我们现阶段不会花太多精力在 LoRA 训练上，因为 LoRA 必须和特定的基座模型绑定，跨基座模型迁移时会有一些工作。
👦🏻 Koji
所以你们 PyroDash 这个工作是解绑的，完全解耦，模型可以随时换？
👨🏻💻 Kevin
对，因为训练方法来讲，Worker Model 跟 Base Model 之间是上下文的联系，所以说它在训练阶段是一个完全独立的。
2 个 FDE 如何服务十几家企业？
👦🏻 Koji
在服务客户的过程中，需要人入场去沟通、服务、梳理的 FDE 角色，你现在是怎么理解的？你在追求尽可能弱化 FDE 吗？
👨🏻💻 Kevin
我倒没有说一定要弱化 FDE，在很长一段时间里，这个角色都是被需要的。我追求的是 FDE 角色的宽度。
目前主流的 FDE 定义非常宽，需要理解需求、做适配、做交付，交付形态往往也是 Base Model 加 harness。
而我定义的 FDE，只需要做前半段 —— 把需求接回来，在我们的 AutoRL 产品上做一次适配。后半段的交付，更多是交付一个能让生产数据回流、能持续提升模型表现的 RSI 管道。这样 FDE 的工作量负载会下降很多。
目前我们服务了十几个 B 端客户，最终两个 FDE 就能支撑得过来。
👦🏻 Koji
但需求接回来后，用到 AutoRL 的部分，需要其他的同事去承接吗？
👨🏻💻 Kevin
我们在第一次做一个场景的时候，本身做奖励结构这一块，还是需要去做一次适配的。
👦🏻 Koji
那它是不是也是某种意义上的 FDE 呢？
👨🏻💻 Kevin
我觉得不能算。我们自己的角色分配是，接回来需求的那部分人，做的是基础和通用产品的角色。
他们主要做的是跨领域的问题。而 FDE 只需要单纯地把需求接回来。这是一个 T 字型的结构。
👦🏻 Koji
听起来咱们在非常追求我们的 business 是要能够 scale 起来的？
👨🏻💻 Kevin
一定是这样的，不然你会变成一家技术咨询服务公司。那种模式需要去服务最头部的单一客户，靠一家客户养活整个生命周期。
但我的判断是，ASI 的最终形态是 Agent 蜂群，它本身是一个分布式的市场，不能用中心化的思路去做它。
我们选择的路径是，用奖励结构把多模态场景的问题变得通用。随着多模态场景变多，奖励本身会有一定的复用性，就可以用泛化能力去解决新领域的场景问题，从而跑通飞轮。
对外，我们必须把我们的角色、客户的角色以及边界划定清楚。
我们选择 AutoRL，就是因为它的界限很清晰：我跟客户之间传递的无非是数据集，最后还给他们一个更新好的模型。这个管道是无状态的，结果大家都能接受。
👦🏻 Koji
如果模型训得越来越好，后面需要的训练越来越少，我们是赚得越多还是越少？
👨🏻💻 Kevin
这分为两层。如果是静态场景，客户给数据，训练一次，模型还给他们就结束了。但绝大多数场景不是静态的。
比如我们做工艺和质检（AVI），上游的需求和 case 天天都在变。一点细微的差别对结果影响都很大。
👦🏻 Koji
工艺或 AVI，也就是质检，为什么天天变？我理解这不是一个蛮固定的工作吗？
👨🏻💻 Kevin
只是从流水线上理解是的，但实际上具体的 case 是千变万化的，一直在变。
这些客户接到的订单需求肯定不是固定的，一条线上的生产也是混杂的。它不能做粗分类，因为涉及到工艺和质检这种深层次问题，一点细微差别对结果影响都很大。
所以场景只要是变化的，就需要用持续学习的方式保证应用模型始终维持在一定水平线之上。
👦🏻 Koji
你们在去和客户交流的过程中，遇到最多的竞标对手是谁？
👨🏻💻 Kevin
目前在我们的 domain 里，面临的竞争相对不是特别多。因为这个领域具备一定的壁垒，不是一个非常开放的领域。
我们面临的可能更多是一些传统的 SaaS 服务商。如果和他们的业务没有冲突，大家各自安好；有冲突的话也可以谈合作。
而纯粹做 RSI 竞标的竞争对手在我们的选定领域里还比较少。当然其他领域就有很多了，比如一些 Agent 领域。像 Trajectory 就是一个蛮成功的 case，在法律领域合作。如果我们要去做类似的事情，那肯定就直面竞争了。
AI ToB 为何能算清账？
👦🏻 Koji
SaaS 很难，咱们也 To B，为什么咱们就不难？
👨🏻💻 Kevin
当你把 B 端的所有事情都包揽时，它确实很难。但我们过滤下来的场景切面非常整齐。
而且 B 端生意的核心还是算账，ROI 是最重要的一点。
👦🏻 Koji
SaaS 为什么算不清楚那个账，你们为什么能算清楚？或者你觉得你有可能可以算得比他们更清楚。
👨🏻💻 Kevin
原因在于这里面引入了一个变量，就是模型本身。
因为现在的模型还是很强大的，它能解决很多问题，关键在于我们要正确地教它。我们做的是在教模型，教会模型把这个问题解掉，而不是提供一个固定的软件式服务。这能创造出更具 ROI 空间的 case，成交自然会容易很多。
云厂商会吞掉 Pyromind 吗？
👦🏻 Koji
你会怎么看待云厂商未来潜在的竞争威胁？
👨🏻💻 Kevin
首先，如果这个领域大家做得多了，我是很开心的，这说明大家在 RSI 路线上面都有自己的探索。
其次，云厂商的业务太广、目标太多。就跟预训练模型一样，当一个平台的目标超级多时，最后落下来的形态就不可能像我们这样敏捷和专用。
👦🏻 Koji
你觉得今天的基模和多模态基模，它们够用了吗？新的 SOTA 还能产生显著的价值提升吗？
👨🏻💻 Kevin
我觉得现在基模状态是"够用，也不够"。
够用是大家的宏观和感性认知；不够用是因为一旦到了生产环境，还要补足非常多的工作，不是把 API 怼到现场它就能跑得很好。
👦🏻 Koji
所以这就是你们做的工作？
👨🏻💻 Kevin
对，我们做的工作就是这里面的很多很多工作。我们也尝试去找到这种相对收敛的一个路径，因为其实你解决这个问题最直接的方法就是铺人。
但这不可扩展。我们的方法是在初期用一定的人工去把奖励网络构建起来。
👦🏻 Koji
构建这个奖励网络，你们有一些什么样的方法论或者窍门吗？
👨🏻💻 Kevin
其实就是在模态上要统一，这是最重要的一个点。跨模态去构建是有很大挑战的。在统一模态下做，总归是有迁移性的。
关于基座模型的演进，为什么我们长期来看要主推 PyroDash？因为现在所有的 AI 领域创业团队，基本上大家都是站在巨人肩膀上去往前搞的。
PyroDash 架构本身就是在基模的基础之上去做一个 Worker Model 及 RSI 的 patch。所以基模演进本身在 PyroDash 架构下，本来就是一个很好的事情。
基模其实越好，对 Worker Model 来说压力就越小。
👦🏻 Koji
还有一个和基模的竞争，是不是也类似呀？
👨🏻💻 Kevin
基模其实不会形成太多的竞争，它总归解决的问题是有宽度的。
在基模解决的宽度内，就 follow PyroDash 架构走就好了。如果解决基模宽度之外，就做一个端到端模型就好了。
我们是面向需求的，从需求侧才能拿到有效的场景级奖励。
👦🏻 Koji
明白。
👨🏻💻 Kevin
拿到场景级奖励后，要去训一个 Worker Model 还是训一个 Base Model，这不是由客户来选的吗？
如果未来出现一个客户说，想把公域问题做一个私有模型来解，也可以，这是他的选择。我们只是从大范围来看，很少有人会选择这么搞。
或许未来会有一家公司或者一个地域说我要做主权模型，要把 coding 问题重做一遍，也是可以的。需求才是我们的驱动源。
👦🏻 Koji
我们最后聊点轻松的，就是创业到现在最有成就感的一件事情，或者一个时刻大概是什么？
👨🏻💻 Kevin
其实就是近期吧。我跟我的 CTO friend 讨论 PyroDash 这个架构的时候，其实一开始我们的观点也是不一样的，我觉得最有成就感的一点就是我们达成共识那一刻。
👦🏻 Koji
你说服他，还是他说服你啊？
👨🏻💻 Kevin
不存在说服，我们是很开放的。大家其实在论证这个事，我们内部论证有很多，有的时候就是直接关小黑屋去论证，包括具身领域我们也论证过。
这种论证非常受益，大家从不同的视角去看这个事情。
👦🏻 Koji
明白，达成共识那一刻感觉很有成就。
👨🏻💻 Kevin
是的。这其实就是为什么我很喜欢去跟大家聊，本身大家不同的视角进来，都是自带奖励信号的。在多目标的奖励信号下，提炼出来的结果，有可能就离真相很近了。这是我觉得比较有成就感的。
👦🏻 Koji
你自己平时会用哪些 AI 产品最近？
👨🏻💻 Kevin
我觉得就是 coding 用的多一点。最近比如说 PI 这 Coding Agent，它就是一个极简的 Agent，我觉得就蛮好的。
包括 DSH，DSH 还是很厉害的，这个已经是堪比历史上 Stars 增长最快的项目之一了。
👦🏻 Koji
是，应该是三天就有十四五万了吧？
👨🏻💻 Kevin
是的。
小模型为何仍有大需求？
👦🏻 Koji
你喜欢用什么模型呢？有一些偏好吗？
👨🏻💻 Kevin
我之前会在 Claude 上面去用，近期的话就是 Kimi 。然后前段时间 GLM 出来的时候也会用。
另外就是现在千问系列，千问在实际的运行时里面下载量还是蛮高的，它也成为了一个用量比较大的模型。
Hugging Face 的报告其实还有一个数字挺有意思，就是 local 类的模型下载量基本 100B 以下占据了下载量的主流。
👦🏻 Koji
这说明什么问题？
👨🏻💻 Kevin
说明我们去搞 PyroDash 这个架构，方向上和社区认知也是相似的。这说明需求世界是多元的，它不是所有需求都要归拢到一个大的 Base Model 上来统一解决。
HuggingFace 上依然有海量的小模型下载量，就代表有大量的需求是需要用分布式这个形态去解决的。所以我们在这个时间点去推 PyroDash，也是一个非常正确的时间点。
👦🏻 Koji
最后一个问题，你现在最期待达成的下一个 milestone 是什么？
👨🏻💻 Kevin
我觉得下一个 milestone 就是 PyroDash 能够获得社区最主流的认可。
因为这个认可的衡量基准，可以去看看它在生产场景里面是不是真的解决了一些特定的问题，而不单纯是 Benchmark 上的分数。
因为这毕竟是我们长期看的方向。而中期和短期看的方向，我们现在已经验证得比较好了。
👦🏻 Koji
好呀，谢谢 Kevin。
👨🏻💻 Kevin
好的，感谢感谢。
