AI 下半场，不会只剩一个超级模型｜对谈 Kevin Ding：Pyromind 创始人/CEO

摘要

• Kevin Ding 对 AI 下半场的核心 bet：ASI 不会只以一个超级中心化模型的形态到来，而会有“服务化的形态，是 Agent 蜂群的形态”。 理由是需要被 AI 解决的问题和场景“都是无穷无尽的，而且还会不断产生新的场景”，且场景本身不是静态的；“用有限参数的模型去泛化无限的场景……至少在 Transformer 这个架构上实现还是很有挑战的”。他不证伪第一条路，但认为服务化路线“一定成立”——需求一直在那里且在增长。
• PyroMind 的定位从 RL as a Service 进化为 Auto RL 驱动的 RSI（自我改进），因为发现“Service 只解决了一半的问题”。 RSI 热起来正是 Agent 部署多了的结果：“一个人日常带着几十个 Agent 去做一件事，他不可能有精力去维护每一个 Agent 的演进”——Agent 需要自我迭代，训练和奖励两个问题都要纳入闭环。
• 商业上已“初步跑通 PMF”：单体大客户付费在百万到千万人民币区间，两个 FDE 支撑十几个 B 端客户，横向复制的工作量逐步递减。 Koji 将融资介绍为天使轮；Kevin 确认公司成立后完成了一轮融资，投资方包括高瓴、百度风投、蓝驰、Vertical，团队 20 多人。最硬的效果数据：质检场景基于约一万张样本，把误报率从 23% 降到 8%。
• 可 scaling 的关键抽象是“无状态”：不做耦合客户上下文的有状态环境，而做一条无状态的 Auto RL 管道。 “我不能把 A 客户的状态打包进产品，再卖给 B 客户”——与客户之间传递的主要是数据集进、更新好的模型出。竞争格局由此分化：Apply Compute 在头部企业内纵向 scaling、包掉一切；DeepMind 系的 Trajectory 与 PyroMind 理念相近，只把训练做好、横向 scaling。
• 对 Harness 路线的判断：企业深层需求是成本、速度、隐私的“不可能三角”，Harness 能解决速度，但“隐私肯定是解决不了的”；不修改参数的方法“天花板其实是存疑的”。 例证是 PCB EDA 客户：基座模型预训练阶段不可能见过这类样本，“再怎么做 Harness，它都很难达到理想状态”。
• 新工作 Paradigm：4B Worker Model 与任意 Base Model（开源、闭源皆可，不需要梯度）组成协作式推理引擎，benchmark 提升约 10%，lambda 较小时省约 20% 成本。 4B 刚好能在 Mac 端侧跑，推理成本基本为零；三阶段训练是难易分类、路由和 GRPO。下一步是尚未发布的隐私奖励项，对敏感 token 做 masking 后再路由回 Base Model。与 Thinking Machines 的 Tinker 不同：LoRA 绑定基座，Paradigm 与 Base Model 解耦，可以更换。
• 对基模与云厂商均不惧：基模“够用也不够用”——到生产环境“不是把模型 API 接到现场，它自己就能跑起来”；基模越强，Worker Model 压力越小，是站在巨人肩膀上而非竞争。 云厂商目标太多，“最后落下来的形态就不可能像我们这么敏捷、这么专用”。他引用 Hugging Face 报告称，100B 以上本地模型的下载量很小，100B 以下占主流，认为这说明有大量需求需要用分布式形态解决。

精读

1. 开局定调：Auto RL 是 RSI 的具象化实现路径

• Kevin Ding，1994 年生，伦敦国王学院出身，此前在阿里云做 infra——弹性 GPU 实例与训练 GPU 集群。PyroMind 一句话定位：“一个 Auto RL，它跟现在大家一直在讨论的 RSI 方向，相当于是一个比较具象化的实现路径。”公司成立后完成一轮融资，投资方包括高瓴、百度风投、蓝驰、Vertical，现有二十多人。
• 他定义的“初步跑通 PMF”有两条：一是证明 Auto RL 方式实现的 RSI“在生产环境里是有价值的”、商业模型至少成立；二是可扩展性——横向复制场景与客户时，“我们的工作量是在逐步递减的”。

2. 下半场分岔：超级模型 vs Agent 蜂群

• 2025 年下半年，他观察到社区、硅谷与国内技术圈都在讨论 AI 进入下半场后的两条路线：继续沿预训练走出一个“超级庞大的中心化模型”，或者 ASI 以“服务化的形态，Agent 蜂群的形态”到来。他明确站后者：“这个世界上需要被 AI 解决的问题和场景……都是无穷无尽的，而且还会不断产生新的场景”，且场景本身不是静态的；“用有限参数的模型去泛化无限的场景，至少在 Transformer 这个架构上实现还是很有挑战的。”
• 一年多后的验证信号：他不声称证伪第一条路，但服务化路线“一定成立”。RSI 之所以现在被高频提起，“其实这就是服务化带来的结果”——Agent 部署得多了，“一个人日常带着几十个 Agent 去做一件事，他不可能有精力去维护每一个 Agent 的演进”，衡量标准变成 Agent 在时间轴上持续符合预期，方法是让 Agent 自我迭代、具备自我改进能力。

3. 从 RL Service 到 Auto RL：一个被自己产品教育的转向

• 值得保留的自我修正：“我们一开始创立公司的时候，认为做到 RL as a Service，做成一个扁平的 Service 形态，基本就能满足这些 Agent 的部署要求。但后来我们发现这依然不够”——Service 终归要有开发者驱动 Agent 改进，只解决了一半的问题。真正跑起 RSI，要同时解决训练和奖励，于是奖励也被纳入 scope。
• GUI Agent 客户承载了这段论证：第一期提供 Studio 和固定的通用训练 pipeline，把 infra 全部解决掉，但客户“依然没有摆脱投入大量人力”来更新 Agent。第二期完成 GUI 方向的奖励后发现，只要末端 Agent 能源源不断回流真实用户反馈，“这个 loop 其实可以自动化地跑起来”，于是推出 EchoMind。

4. 两层产品：Studio 管训练 infra，EchoMind 包整个 RSI 闭环

• Studio 是 serverless 的训练 infra service，核心是“逻辑节点”：开发者不用关心物理机实现，只配置训练参数（DP size、TP size 等），从单卡到多台的横向扩展由 PyroMind 完成。
• EchoMind 把整个 RSI 流程包在背后，对用户只透出一个 Proxy，也就是代理 URL。插入某个 Agent 后，它可以持续抓取 Agent 运行轨迹，形成相对整齐的数据集；数据集经过奖励结构处理，生成训练 pipeline，训练后再部署回去，全流程被 EchoMind 封装，客户收到的是更新好的模型。

5. 客户画像：工业是甜点区，因为数据丰富且自带标签

• 选客户的逻辑是找 real-world data 最丰富的地方：数据要产生于生产场景，最好还是模型能力之外的问题。当下重要客户集中在工业领域，例如英伟达的上游企业。这些企业经过制造 1.0、2.0 改造后，内部数字化程度较好，也积累了可观数据；同时，工业企业对精益生产有明确的定义，收集到的数据往往已有相对明确的好坏标签，标注问题天然得到解决。再加上 ROI 可衡量，三条件齐备。
• 偏软件的两个场景是工艺改进与质检，后者是典型多模态问题。工艺的例子是电镀：产线上需要配置一批参数，参数合适才能得到想要的结果，现在仍主要由“老师傅”完成。后训练的目标是把人的经验迁移到模型里，使模型长期运行时改善品控保护和波动，并且随着增量数据增加，“有可能比人做得更好”。具身智能也会看，但硬件部分使它成为相对独立、更复杂的板块。

6. 无状态是横向 scaling 的命门

• 环境问题的拆解：coding 领域的 compiler 环境每生成一段代码就可以运行并得到较强奖励信号，且不与生产环境信息耦合、可以抽离；但 GUI Agent 要满足每个用户的需求，就不能脱离用户上下文，否则会失去生产价值，和用户上下文耦合后便是有状态环境。
• PyroMind 的解法是在长链路里找到可横向 scaling 的无状态部分——不只是一个 environment，而是一条 Auto RL 管道：喂入数据，由 Reward Agent 或 Reward Model 给出 reward signal 和 advantage，以找到更新方向，再迭代一轮；或者利用生产场景回流数据中已有的人工标注作为奖励。这两类信息都被放在回流数据集里，与环境上下文解耦。对不同客户的产品不能打包 A 客户的状态再卖给 B 客户，因此需要这种无状态管道。

7. 同赛道分化：Apply Compute 纵向做重，Trajectory 横向做轻

• 去年同期关注 RL as a Service 的公司如今“是有分化的”。Apply Compute 更往前走了一步：提供完整服务基础设施，连 Agent Serving 等事情都做，面向几个头部企业“把企业内部所有和 Agent、AI 相关的东西全部做掉”——在一个企业内纵向 scaling，更宽、更重。
• 近期出名的 Trajectory 是 DeepMind 的人出来做的公司，与 PyroMind 理念相似度更高：单纯做 RL，同时与 Mercury、Clay、Harvey 等公司有一些合作，方向是横向 scaling。PyroMind 更希望做到 Auto，把无状态的 RSI 能力平台化。Kevin 认为下半场光谱很广，容得下不同形态；PyroMind 选择的是更适合 Agent 蜂群这一分布式市场的路径。

8. 定价与账本：Studio 按资源，EchoMind 按场景价值收 quota

• Studio 是自助式服务，按 GPU、CPU、存储等资源计费。EchoMind 则按场景价值计费，以 quota 作为资源单元，并根据场景更新频率限制 EchoMind 实例的 quota。它与 token 不特别绑定：一条多模态长链轨迹做一轮 Auto RL 的成本为 X，嵌入奖励价值后在 X 的基础上增加一定百分比形成 quota；成本主要是训练消耗的 GPU、CPU 等资源，Kevin 也概括为电力和算力资源。高价值场景数据量大、训练轮次多，quota 消耗自然可观；Pro-C 小场景达到 baseline 即可，消耗较少。
• ROI 明确的大颗粒度客户，单体客户付费基本在百万到千万人民币区间。客户理解价格的方式是看这件事在其场景上的 ROI，以及付出的代价在 ROI 中占多大比例。质检案例基于约一万张样本，把误报率从 23% 降到 8%，成本和收益因此较为明确。
• 选场景三准则、也是拒单标准：ROI 必须可衡量；不能偏离多模态研发主线；场景在企业内和跨企业都要有扩展性。办公、发票、差旅类 Agent 目前做起来会比较吃力。电镀工艺在 PCB 行业通用，可见光和结构光质检几乎通用于制造业，正是过滤后的答案。

9. 为什么 Harness 不够：不可能三角与“参数必须被修改”

• Koji 先将落地需求分层：先是是否好用、效果是否好，再是企业是否能算清 ROI，进一步追求成本、效率和隐私的“不可能三角”。Kevin 认可的结论是，Harness 是一种轻量方式，但“可能解决速度的问题，隐私肯定是解决不了的”。
• Kevin 更根本的论断是：“如果用一个不修改参数的方法来做这个事情，它的天花板其实是存疑的。”Harness 提供的是 workflow、skills、memory 等流程性能力，本质是在 context 上工作。PCB EDA 客户的电路图设计属于独立深领域，绝大多数基座模型预训练时不可能见过这类样本，本地部署再大的 Base Model 加 Harness 也很难达到理想状态，最终仍需修改模型参数。
• 公域和私域要分开：公域问题是 Base Model 已经解决得较好的问题，可以训练 Worker Model，把特定要求训练进去，不必从头预训练；很深的领域则需要端到端模型。对“把隐私问题路由到本地开源模型”的追问，他仍强调模型需要训练，模型本身的参数需要被修改。

10. Paradigm：4B 端侧模型 + 任意基模的协作推理，成本是入口、隐私是目标

• Paradigm 起点是自身需求——“Web coding 太贵了”。它是协作式推理引擎：把一个 4B 模型和 Base Model 连接起来，拼接的是上下文策略，对 Base Model 没有要求，可以是开源或闭源模型，因为不需要 Base Model 的梯度。选择 4B 是因为它刚好能在 Mac 端侧运行，推理成本基本为零；代价是效果还不够好，需要对其训练。
• 训练三阶段是：第一，对问题难易程度分类；第二，做路由系统，小模型先接，能解决就留在端侧，不能解决就路由回 Base Model；第三，进行 GRPO。奖励结构包括正确性和成本，成本奖励带一个系数。结果是 benchmark 表现提升约 10%，lambda 较小时还能节省约 20% 成本。
• Kevin 明确表示，这个架构的潜力不只在成本：成本是推广 Paradigm 的突破口，真正正在构建的是隐私解决方案。尚未发布的隐私奖励项会让 Worker Model 对敏感 token 具备 masking 能力，先挡住、处理敏感信息，再路由回 Base Model。
• 与 Thinking Machines 的 Tinker 不同：Tinker 提供 LoRA API，LoRA 需要与 Base Model 绑定，跨 Base Model 迁移还需额外工作；Paradigm 的 Worker Model 与 Base Model 通过上下文建立联系，训练阶段彼此独立，因此可以更换 Base Model。

11. FDE、持续训练与“SaaS 很难，你们为何不难”

• 最花时间的是初次进入场景的 FDE：“这个阶段是不可省的”——理解客户场景的数据、知识和评价基准，并把 Reward Agent 或 Reward Model 适配到该场景；但奖励最终会收敛到模态上，同模态间有一部分工作可以复用，因此 scaling 后工作量递减。Kevin 不追求消灭 FDE，而是缩小其宽度：FDE 主要负责前半段接回需求，交付的是能让生产数据回流、持续提升模型表现的 RSI 管道，形成 T 字型结构。目前约两个 FDE 支撑十几个 B 端客户。
• 持续训练的必要性来自具体 case 的变化：从流水线看工艺和质检似乎固定，但订单需求不固定，同一条生产线也可能混杂生产；在这些深层问题里，一点细微差别都可能显著影响结果，因此需要持续学习，让应用模型维持在一定水平之上。
• 面对“SaaS 都很难做 To B，你们凭什么”的追问，他的答案是变量在模型：“我们做的事情是在教模型把问题解决掉，而不是提供一种软件式的固定服务”，模型能够创造更大的 ROI 空间。当下纯 RSI 的竞争对手较少，但可能遇到深耕多年的传统 SaaS 服务商：不冲突则各自安好，有冲突则谈合作；Agent 领域则会直接面对 Mercury 与 Harvey 等合作案例带来的竞争。

12. 基模、云厂商与社区信号：分布式需求为 Paradigm 背书

• 对基模的判断是“够用也不够用”：宏观上大家都觉得基模很强，但“到生产环境里跑，你会发现还要补足很多工作”，不是把模型 API 接到现场它自己就能跑起来。基模越强，对 Paradigm 的 Worker Model 压力越小；基模能力宽度之外的问题则做端到端模型。训练 Worker Model 还是 Base Model，可以由客户根据需求选择；未来如果某家公司或某个地域要做主权模型、重新做基础模型，也可以，需求才是驱动力。云厂商的威胁被类比为预训练平台：目标太多的平台最终不可能像 PyroMind 这样敏捷、专用。
• 社区侧证据是 Kevin 引用的 Hugging Face 报告：本地模型下载量中，100B 以上模型很少，100B 以下模型占主流。他据此认为有大量需求需要用分布式形态解决，因此在这个时间点推出 Paradigm 是合适的。个人使用的产品包括 Pi 这样的极简 coding Agent、Dify，以及 Claude、Kimi、Gemini 和千问系列；他特别提到千问 3 的 8B、27B 小模型反响很好，并称 Dify 应该已有约 14 万至 15 万 stars。
• 最有成就感的时刻是与 CTO Frank 讨论 Paradigm 架构时从分歧走向共识：“不存在谁说服谁”，而是不同视角共同论证；这些视角“自带奖励信号”，在多目标奖励信号下提炼出的结果“有可能就离真相很近了”。下一个 milestone 是 Paradigm 获得社区主流认可，衡量标准是在生产场景中真正解决固定问题，而不只是 benchmark。