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

> 十字路口 Crossing 精读

- 发布日期：2026-08-30
- 主持：Koji · Ronghui
- 原节目：https://www.xiaoyuzhoufm.com/episode/6a90fc5e1352af56ff3d48af
- 网页版：https://crossing.qiaomu.ai/ep/6a90fc5e1352af56ff3d48af.html
- 精读字数：约 6605 字（阅读约 15 分钟）

> 本文为 crossing.qiaomu.ai 基于节目转写的 AI 整理精读，不是逐字稿；引用请注明出处并链接网页版。

Kevin Ding 1994 年出生，32 岁，伦敦国王学院毕业，在阿里云做过弹性 GPU 实例和训练 GPU 集群。2025 年他创立 Pyromind，团队 20 多人，天使轮投资方包括高瓴、百度风投、蓝驰、Atypical。公司常被归到 RL as a Service 赛道，Kevin 在十字路口这期节目里说，Service 只解决了一半问题。

这期 Koji 和他聊了 49 分钟。话题从 AI 下半场会不会只剩一个超级模型，到 AutoRL 怎么把训练、奖励、反馈、部署、数据回流串成循环；从工业质检、电镀工艺参数优化，到 GUI Agent、Coding Agent；也聊了 PyroDash，一个 4B worker model 加 base model 的协作架构。节目里有几组具体数字：质检误报率从 23% 降到 8%，用的是一万张样本；PyroDash 在 benchmark 上提升约 10%，lambda 较小时省约 20% 成本；大客户单体付费在百万到千万人民币区间。

下面按对话顺序整理，保留 Kevin 的判断、案例和边界。读者能看到一家 AI ToB 公司怎么选客户、怎么定价、怎么把 FDE 的一次性交付变成可复制的管道，以及他为什么认为需求世界不会收拢到一个超级模型。

## 一个 32 岁的 infra 老兵，押注 Agent 蜂群 0:23

快问快答里，Kevin 给了几个简短答案：INTJ，摩羯座，一句话介绍 Pyromind 是 AutoRL，跟 RSI 这个方向对应，是一个比较具象的实现路径。公司 2025 年成立后做了一轮融资，投资方有高瓴、百度风投、蓝驰、Atypical。团队现在 20 多人。收入和利润的具体数字没有披露，但他认为 PMF 初步跑通了两件事：第一，用 AutoRL 实现 RSI 在生产环境有价值，商业模型至少成立；第二，横向复制到相似场景和客户时，工作量逐步递减。

创业前，Kevin 在阿里云做偏 infra 的事，包括弹性 GPU 实例和训练 GPU 集群。他决定创业，来自对 AI 下半场的一个判断。2025 年下半年，技术圈讨论两条路线：一条继续沿预训练走，ASI 会是一个超级庞大、中心化的模型，能解决绝大多数场景，效果足够好；另一条认为 ASI 会以服务化形态出现，是 Agent 蜂群。Kevin 偏向后者。

他的理由很直接。世界需要 AI 解决的问题和场景已经无穷无尽，时间推移还会不断产生新场景，场景本身也在变。用有限参数的模型去泛化无限场景，在 transformer 架构上挑战很大。**Kevin 押的是服务化、Agent 蜂群这条路线，他认为这条路线必然成立，因为需求一直在那里，而且还在增长。**

一年多后再看，他觉得自己的 bet 更成立了。RSI 在这一年变热，和 Agent 变多有关。一个人日常带几十个 Agent 做事，不可能有精力维护每一个 Agent 的迭代。Agent 嵌入场景后，衡量方式是它在一段时间轴上的表现都要符合预期。实现方法就是 Agent 要能自我迭代，具备自我改进能力。Kevin 把这个需求看成服务化路线的结果，Agent 多了，RSI 才变得重要。

## RL as a Service 只解决了一半问题 5:21

Pyromind 一开始并没有直接想到 AutoRL。Kevin 说，这是过程中浮现出来的。团队本来就在看后训练，RL 为代表的后训练技术是拿环境反馈去更新模型，是一个持续过程。团队研判方向也用了类似方式，先做 RL as a Service，做到扁平的服务形态，以为差不多能满足 Agent 部署要求。后来发现不够。

> Service 只解决了一半的问题。

Kevin 的解释是，Service 的使用者终归是开发者，仍要有人驱动 Agent 改进。真正把 RSI 跑起来要解决两个问题：训练和推理，以及奖励。AutoRL 把奖励纳入了 scope，让整个循环可以自动跑。

他举了 GUI Agent 客户的例子。这个客户下游有较多消费级部署量，会收上来很多用户特定需求，也有自己的产品迭代需求。Pyromind 第一期提供 Studio，给客户一个通用 training pipeline，把训练 infra 的问题全部解决掉。客户仍然要投入算法工程师，不断更新 Agent 本身。到了第二期，Pyromind 把 GUI 方向的奖励做进去，发现 loop 可以自动跑起来：末端部署的 Agent 源源不断收真实环境反馈，反馈回来之后，系统可以自主循环变好。于是第二期推了 EchoMind。

两个产品的边界因此清楚起来。Pyromind Studio 是 serverless 的训练 infra 服务，里面实现大量训练依赖的逻辑节点。开发者配节点时不用关心物理机实现，只配训练参数，逻辑节点可以横向 scaling，从单点单卡到多台机器都能扩展。EchoMind 把整个 RSI 流程包在背后，给用户透出一个 proxy URL。这个 URL 插到某个 Agent 里，就能源源不断抓 Agent 轨迹，形成相对整齐的数据集。数据集过奖励结构，生成 training pipeline，训练，拿结果，再部署回去。

**Studio 卖的是训练基础设施，EchoMind 卖的是把 RSI 循环包起来之后的结果。**前者客户自己维护管线和 reward function，后者 Pyromind 介入实际场景，把奖励内化到自己的 reward model 上，由 Pyromind 维护。

## 工业客户、FDE 与无状态管道 8:32

Pyromind 选客户时看真实世界数据，数据要产生于生产场景，最好在模型能力之外。Kevin 问自己，哪里的 real data 最富集？答案之一是工业。他们现在一些重要客户集中在工业领域，包括英伟达的上游企业。这类企业经过制造 1.0、2.0 改造，内部数字化做得不错，多年生产又积累下可观数据。工业场景还有一个好处：企业对自己的精益生产有定义，收上来的数据往往有相对明确的好坏标签，标注问题天然被解掉。第三个条件是 ROI 要能衡量。三个条件满足，产业链上的工业客户就是好画像。

另一类客户和 Agent、具身相关。具身是相对独立的板块，因为还要考虑硬件，问题更复杂。Pyromind 的目标是后训练驱动的 RSI，当下偏软领域会走得更快。

工业里他们偏软主要看两个场景：工艺改进和质检。工艺像电镀，生产线上有一批参数要配，配好了产线后段能拿到想要的东西，配不合适就拿不到。现在这件事由老师傅做，是个人驱动的经验。后训练的目标，是根据历史数据和未来增量生产数据，把人做这件事的经验迁移到模型里。长期看，模型在品控波动上可能做得更稳，增量数据越来越多，也可能比人做得更好。质检更容易理解，Pyromind 说能把误报率从 23% 降到 8%，这是一万张样本上的结果。

这里有一个关键设计：无状态管道。Kevin 用 coding 领域的环境做对比。compiler 是典型环境，每生成一段代码，跑一下 compiler 就能拿到是否通过的强奖励信号，它和生产环境信息不耦合，可以被抽离。实际生产环境里这样的环境有限。GUI Agent 要做用户特定需求，不能脱离用户上下文，脱离了就缺乏生产价值；跟用户上下文耦合，它就是有状态环境。

Pyromind 要在长链路里找到可以横向复制的无状态东西。Kevin 把可横向复制的东西定义成 AutoRL 管道，环境只是其中一部分。管道喂数据，通过 reward agent、reward model 拿到 reward signal，迭代一轮。管道和奖励本身跟生产上下文不耦合。奖励信号可以来自模型在场景里 rollout 一次后 reward model 给出的优势值，也可以来自生产场景回流数据里包含的人工 judgment。两种信息都装在用户回流的数据集里，不装在 Pyromind 的产品里。**不能把 A 客户的状态打包进产品，再卖给 B 客户，这是横向 scaling 的底线。**

FDE 在第一次进入场景时不可省。Kevin 不排斥完全 FDE，初次进入要理解客户场景里的数据格式、评价基准、业务流程，把奖励 agent、奖励模型适配到场景上，这部分最花时间。冷启动之后，scaling 起来工作量递减。奖励最终会收拢到模态上，相似模态有相当一部分工作可以复用。

收费分两层。Studio 按资源计费，类似云服务的 CPU、存储、GPU 计价，客户自助使用。EchoMind 按场景价值计费，用 quota 限制，根据场景更新频率给客户一个 EchoMind 实例的配额。因为 EchoMind 嵌入了 Pyromind 提供的奖励价值，客户收到的是一个更新好的模型。大颗粒度企业、ROI 明确的场景，单体客户付费能到百万到千万人民币。quota 不是 token，是资源单元，衡量 EchoMind 做一轮 RL 在嵌入奖励价值下的消耗，跟 Pyromind 自己的 GPU、CPU 成本账绑定。

拒绝需求有三条标准：ROI 必须可衡量，不可衡量就不好定价；不要偏离多模态研发主线；场景要在企业内和跨企业有扩展性。偏办公、发票、差旅的 Agent，ROI 不好衡量，Pyromind 做起来会吃力。工艺里的电镀在 PCB 行业通用，质检里的可见光质检、结构光质检几乎在所有制造业通用，这些符合三条标准。

## PyroDash：4B 小模型与基座模型协作 26:29

Kevin 把 AI 进入生产的需求分成两层。第一层是好用和效果。好用有很多方式，模型 API 很方便，DeepSeek 的 harness 也很好用。效果可以加大量 harness 逻辑，让模型行为对齐需求，也可以做后训练，用训练提升模型能力。第二层是 ROI 是否合理，企业要有收益。到了第二层，企业会追求一个不可能三角：成本好、效率好，还要满足隐私需求。

Pyromind 选择 RL 和 AutoRL，没有集中精力做 harness，因为 Kevin 认为长期看 AutoRL 形式的 RSI 能承接这两层需求，尤其是那个不可能三角。对应的工作就是 PyroDash。

PyroDash 最初来自 Pyromind 自己的需求：web coding 太贵。他们做了一个协作式推理引擎，把一个 4B 模型和一个 base model 连在一起。拼接对象是上下文，base model 可以是开源模型，也可以是闭源模型，因为 Pyromind 不需要它的梯度。训练对象是 4B 模型。选这个 size 的一个原因，是它刚好能在端侧、在 Mac 上跑起来，推理成本是零。问题随之变成：效果不够好，所以要训练它。

训练分三个阶段。第一阶段做难易问题分类。第二阶段做冷启动：请求打过来，小模型先接，看这个问题是不是它能解决。能解决就在端侧解决，解决不了就路由回 base model。第三阶段是 GRPO。开放出来的奖励结构有两个，正确性和成本，成本奖励带一个系数。训了一段时间后，结果比较有意思：baseline 比纯 base model 有提升，简单问题被小模型自己解决，成本一定下降。benchmark 上提升大概 10%，用 PyroDash 架构时，lambda 较小可以省掉约 20% 成本。

**PyroDash 的算盘是：简单问题在端侧 4B 模型解决，难题路由给 base model，再用奖励把正确性和成本一起训。**Kevin 认为这个架构的潜力不在成本，成本是推广的突破口。他们现在构建的是隐私能力，这更有 B 端属性。

企业问题可以分公域和私域。公域私域不是 B 端和 C 端，指的是这个问题有没有好的 base model 来解。公域问题，基础模型 baseline 不错，可以用 PyroDash 训一个 worker model，只是训练对象不同。私域问题，端到端模型解掉就好。隐私奖励项还没有发布，思路是对敏感 token 做 masking，让 worker model 挡一层，把敏感信息处理掉，再路由回 base model。企业不是所有信息和上下文都可以丢给基模。

Harness 的局限也在这里。Kevin 说 harness 很好、很轻，能解决速度问题，隐私解决不了。要在成本、速度、隐私三个维度都追求最优，终归要挖掘模型能力。纯 harness 不修改模型参数，天花板存疑，到了深水区，很多问题不训练就完全做不到。他举了 PCB EDA 客户的例子。PCB 板电路图设计是一个独立 domain，绝大多数基座模型预训练时不可能见过这样的样本。哪怕把很大 size 的 base model 部署到本地，再怎么加 harness，也很难达到理想状态，最终还是要改模型参数。

并非所有场景都需要完整预训练。coding 这类问题 base model 已经解过，具体场景里就没必要从头预训练，把特定要求训进 worker model 就好。很深的 domain 才需要端到端模型。和 Thinking Machines 的 Tinker 相比，Tinker 提供 LoRA API，Pyromind 现阶段不太会花太多精力做 LoRA。LoRA 训练有效，但要求跟基座模型绑定，在一个基座模型上做的 LoRA，跨基座迁移会有工作。PyroDash 在训练阶段把 worker model 和 base model 解绑，base model 可以随便换。

## 两个 FDE 支撑十几个客户，靠什么 34:02

Kevin 没有把弱化 FDE 当成目标。他认为很长一段时间里，这个角色都会被需要。他追求的是 FDE 角色的宽度变窄。现行主流 FDE 定义很宽：进去理解需求，做适配，把交付做完，交付形态往往是 base model 加 harness。Kevin 定义的 FDE 只做前半段：把需求接回来，把第一个场景的需求在 AutoRL 产品上做一次适配。后半段交付的是一个能让生产数据回流、不断提升模型表现的 RSI 管道。

这样 FDE 的工作量负载会下降。Pyromind 现在服务十几个 B 端客户，大概两个 FDE 支撑他们的需求。接回来的需求由另一组同事承接，这组人更偏基础和通用产品，在现行奖励结构下不断把其他场景接入进来，主要做跨领域问题。FDE 横向接需求，通用产品团队纵向做跨领域接入，形成一个 T 字形结构。

这套安排背后是 business 要能 scale。Kevin 说，不然公司会变成技术咨询服务这种全方位一体的公司。这类公司有存在意义，只是选客户策略会变成押最头部、最大的一家，一家客户 cover 整个生命周期。他的判断是，ASI 到来时形态是 Agent 蜂群，本身就是一个分布式市场，不能用中心化思路做。Applied Compute 选择在企业内纵向做重，把 Agent serving 等完整基础设施都包掉，面向几个头部企业。Pyromind 选择横向，把奖励结构和 AutoRL 管道做成可复用的产品。

**Pyromind 选择把奖励结构和 AutoRL 管道做成可复用的横向产品，没有把每个客户的所有 AI 需求都包掉。**下半场的光谱很广，Kevin 认为容得下任何形态。Pyromind 的路径是用奖励结构把多模态场景的问题变得越来越通用。收的动态场景越多，奖励越有复用性，复用性又能用泛化能力解新领域的问题，飞轮就可能跑起来。

对外，Kevin 很在意划清角色和边界。边界不清楚，business 就会模糊。选 RL 方法的好处是界限清晰：客户和 Pyromind 之间传递的是数据集，回来的是一个更新好的模型。管道无状态，客户看到的是用自己的数据拿到了提升后的模型。

## 模型越训越好，Pyromind 赚更多还是更少 38:20

模型训得越来越好，后续训练需求会不会越来越少？Kevin 把生意分两层看。一层是应用模型，客户给数据，模型还给他。如果客户场景静态，做一次训练就够了，问题集结好就完事。绝大多数场景不静态。工艺和质检上游来的需求天天在变，持续训练的原因是要维持应用模型的能力，不要掉点。静态模型解决不了变化，就会掉点。

工艺和质检为什么天天变？流水线看起来固定，具体 case 千变万化。客户接到的订单需求不固定，一条线上的生产也是混杂的。不能做粗分类，工艺和质检这种深层次问题，细微差别对结果影响都很大。场景只要在变，就需要持续学习，保证应用模型维持在一定水平线之上。

竞争上，Kevin 觉得目前 RSI 领域竞争相对不多，因为做的 domain 本身有壁垒，不是一个非常开放的领域。他们面临的竞争更多来自传统 SaaS 服务商，这些服务商在企业里深耕多年。Pyromind 进去做，如果跟对方业务没有冲突，大家各自安好；有冲突就谈合作。纯粹做 RSI 的竞争对手比较少。Agent 领域竞争多，法律领域已经有 Agent 公司和 Harvey 合作的成功案例，类似事情会直面竞争。

中国 SaaS 难做，Pyromind 也做 ToB，为什么能算清账？Kevin 说，把 B 端所有事都做了，就会很难。他选场景有三条准则，过滤下来场景切面比较整齐。B 端生意最本质的核心还是算账，ROI 很重要。AI 时代做 B 端生意