Pyromind推大小模型协同架构押注工业AutoRL替代单一巨模

Koji杨远骋

中心化大模型无法通吃多元且动态变化的物理生产环境，企业必须依靠无状态强化学习管道与端侧小模型协同实现闭环迭代。

AI-assisted summary of 【十字路口】AI 下半场，不会只剩一个超级模型｜对谈 Kevin Ding：Pyromind 创始人/CEO【视频播客】 — original source. Check the original for full context.

Source published: 2026-08-30

Key ideas

Pyromind 验证了 AutoRL 商业闭环，在工业质检实战中仅用约 1 万张样本训练即将产线误报率从 23% 降至 8%，工业大客户客单价达到数百万元至千万元人民币区间。 (15:00)
针对企业在成本、效率与隐私间的不可能三角，团队推出 PyroDash 架构，通过 4B 端侧小模型与基座模型协作，在 Benchmark 提升约 10% 的同时节省约 20% 推理成本。 (25:00)
Pyromind 重新定义 FDE 角色边界，仅凭 2 名现场部署工程师即支撑十余家 B 端客户，将交付收敛为无状态（Stateless）AutoRL 自动化管道以规避驻场咨询陷阱。 (34:02)
工业产线由于工件批次与订单切换导致数据天天变化，静态模型极易发生“动态掉点”，使能够闭环吞吐生产数据的持续强化学习成为生产级刚需。 (38:00)

Detailed notes

## Background 该视频由 YouTube 频道「Koji杨远骋」于 2026 年 8 月 30 日发布。节目对谈了强化学习即服务平台 Pyromind 的创始人兼 CEO Kevin Ding，聚焦讨论从 RLaaS 到 AutoRL 的演进、工业制造场景的落地与 ROI 核算，以及大小模型协作架构 PyroDash 如何打破企业 AI 落地的不可能三角。

## TL;DR Kevin 深入阐述了为何 AI 下半场的终局是动态演化的“Agent 蜂群”而非单一中心化超级模型，指出后训练必须将算力与奖励机制闭环为自动化的 AutoRL 管道。Pyromind 重点切入工业质检与工艺参数优化等高价值、强反馈的生产场景，通过无状态管道与模态统一让 FDE 前期投入逐步递减，打破传统咨询定制的重交付陷阱。团队进一步推出 PyroDash 架构，利用 4B 端侧小模型与协作推理引擎联动云端强基座模型，在 GRPO 强化学习驱动下破解了成本、效率与隐私的不可能三角。整场对谈论证了在基座模型日益强大的背景下，海量小模型与专用强化学习管道在实体生产深水区中不可替代的共生价值。

## Atmosphere & style 对谈整体洋溢着深扎工程一线的务实与理性克制，彻底褪去了大模型炒作的浮躁辞藻，通篇贯穿着对 ROI、算力开销和真实场景痛点的冷峻剖析。Kevin 的表达兼具 INTJ 的严谨架构感与创业者的坦率敏锐，既不回避项目制交付与落地掉点的现实挑战，又能清晰复盘底层架构的推演逻辑。主持人的层层追问紧扣商业化内核，两人在技术细节与产业格局间的碰撞平实而富有密度，传递出一种在工业深水区稳步推进技术闭环的笃定感。

## Bulletin - [15:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=900s) Pyromind 验证了 AutoRL 商业闭环，在工业质检实战中仅用约 1 万张样本训练即将产线误报率从 23% 降至 8%，工业大客户客单价达到数百万元至千万元人民币区间。 - [25:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1500s) 针对企业在成本、效率与隐私间的不可能三角，团队推出 PyroDash 架构，通过 4B 端侧小模型与基座模型协作，在 Benchmark 提升约 10% 的同时节省约 20% 推理成本。 - [34:02](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2042s) Pyromind 重新定义 FDE 角色边界，仅凭 2 名现场部署工程师即支撑十余家 B 端客户，将交付收敛为无状态（Stateless）AutoRL 自动化管道以规避驻场咨询陷阱。 - [38:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2280s) 工业产线由于工件批次与订单切换导致数据天天变化，静态模型极易发生“动态掉点”，使能够闭环吞吐生产数据的持续强化学习成为生产级刚需。

## Key takeaways - [00:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=0s) AI 下半场终局并非单一中心化超级大模型，而是服务化 Agent 蜂群，因为有限参数模型无法泛化无限且动态变化的现实场景，Agent 必须依赖强化学习持续演化。 - [05:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=300s) RLaaS（强化学习即服务）仅解决了一半问题，必须将交互轨迹捕获、数据回流、奖励建模与自动部署串接成自循环的 AutoRL，才能真正释放生产力。 - [05:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=300s) 工业制造领域是 AutoRL 的优质沃土，原因在于其数字化底座扎实、生产经济指标带来天然的数据标注闭环，且良率提升能直接折算为明确的 ROI 账目。 - [10:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=600s) 通过打造解耦上下文的无状态（Stateless）AutoRL 管道，将业务有状态信息留存在客户数据集中，使奖励模型与训练能力能够横向跨客户复用且不泄露隐私。 - [15:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=900s) 战略上主动放弃处理发票、报销等 ROI 模糊且难以量化的轻办公 Agent，坚决聚焦在 PCB 电镀工艺参数优化与多模态工业质检等高价值深垂直场景。 - [15:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=900s) 商业计费采用基于场景价值的 Quota（Mindness Credit）模式，底层定价逻辑锚定单轮强化学习迭代的物理算力成本，并叠加自研奖励机制的增值溢价。 - [25:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1500s) PyroDash 架构利用 4B 端侧小模型进行难度分类与本地零算力成本求解，并借助 GRPO 强化学习联合优化正确性与推理成本，摆脱对基座模型梯度的依赖。 - [30:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1800s) 在像 EDA 电路设计这类预训练几乎未曾覆盖的极深垂直领域，外围 Harness 编排方案存在严重天花板，必须端到端修改模型底层参数才能满足业务要求。 - [34:02](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2042s) 构建 T 字形交付组织，前端 FDE 仅负责初次业务理解与奖励结构适配，后端通用产研团队维护自动化管道，使边际人力投入随着场景相似度递减。 - [38:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2280s) 工业流水线环境处于高频动态扰动中，细微的工艺分布偏移会导致模型迅速掉点，静态微调无法一劳永逸，必须依赖持续后训练管道。 - [40:58](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2458s) AI ToB 相比传统 SaaS 更容易算清账，因为其核心不在于售卖固化的流程软件，而是利用后训练教会通用模型解决能直接产生经济回报的具体业务难题。 - [43:26](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2606s) 构建自动化奖励网络的核心前提在于保持模态统一，同一模态（如视觉或代码）内的奖励结构具备高迁移性，跨模态迁移则成本极高。 - [46:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2760s) Hugging Face 本地下载量绝大多数集中在 100B 以下小模型，这一现实趋势强力印证了真实应用需求的高度多元性与端侧专用小模型生态的广阔前景。

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=0s) 创业契机：从阿里云 Infra 到下半场的 Agent 蜂群

Pyromind 创始人兼 CEO Kevin Ding 是一名 1994 年出生的创业者（32 岁，求学于伦敦国王学院 King's College London，MBTI 处于 INTJ 与 ENTJ 之间）。在创立 Pyromind 之前，他在阿里云专注于弹性 GPU 实例及训练 GPU 集群等 AI Infra 基础设施的搭建。Pyromind 成立之初便完成了由高瓴、百度风投、蓝驰创投以及 Atypical Ventures 投资的天使轮融资，目前团队规模在 20 余人。关于商业化进展，Kevin 透露团队已经初步跑通了 PMF（产品市场契合度）：不仅验证了 AutoRL 商业模式本身的成立与价值，更重要的是在横向跨场景、跨客户的复制过程中，团队所需投入的工作量呈现出“逐步递减”的良好趋势。

谈及创业初期的研判，Kevin 回忆在 2025 年下半年，学术界、硅谷和国内技术圈都在探讨 AI 是否进入了“下半场”。当时关于通用人工智能（AGI/ASI）的演进路线分裂为两个核心阵营： 1. **单一超大模型路线**：沿着预训练大模型继续 Scaling，最终依靠一个参数极其庞大的中心化超级模型，去泛化并解决物理世界绝大多数场景的问题。 2. **服务化 Agent 蜂群路线**：现实世界中需要被 AI 解决的场景不仅在当下是无穷无尽的，而且随着时间推移还在持续动态产生。在当前 Transformer 架构下，试图用“有限参数”的模型去泛化“无限且非静态的现实场景”极其困难。因此，未来更实际的形态是高度服务化的 Agent 蜂群（Swarm）。

Kevin 坚定地下注了第二条服务化路线。经过一年多的实践，这一判断愈发得到验证。随着企业内部署的 Agent 数量成倍增加，任何开发者都不可能有人力去逐一维护每个 Agent 在生命周期中的演化。Agent 被嵌入生产业务后，衡量其优劣的核心指标是“能否在长周期的时间轴上持续符合业务预期”。要做到这一点，Agent 必须具备基于真实环境反馈实现自我迭代、自我改进的机制，这正是强化学习（RL）后训练切入的核心战场。

---

[05:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=300s) 从 RLaaS 到 AutoRL：双产品矩阵与工业客户画像

回顾产品的演进，Kevin 坦言 Pyromind 最初也曾以为只要做一个扁平的 RLaaS（RL as a Service）平台、为开发者解决训练基础设施问题就足够了。但实际落地后发现，“Service 仅解决了一半的问题”。在传统的服务形态下，终端依然需要依赖开发者在业务侧不断做需求分析、写奖励、推模型，人力投入并没有减少。一个完整的 RL 生产闭环必须同时解决好训练算力（Train/Infer）与奖励（Reward）两大要素。因此，团队把 scope 扩展到了全自动循环的 AutoRL。

基于此，Pyromind 形成了明确的“双产品矩阵”： - **Pyromind Studio**：面向开发者和模型工程师的 Serverless 训练基础设施平台。它将物理算力抽象为训练依赖的逻辑节点，开发者只需配置训练参数与 DP-Size（Data Parallelism Size），平台便能自动完成从单卡、单机到多机跨节点横向弹性扩展（Scaling），免去底层的 Infra 运维烦恼。 - **EchoMind**：面向全自动 AutoRL 的端到端产品。EchoMind 直接对外透出一个 Proxy URL，客户只需将其挂载到现有 Agent 链路中。EchoMind 会在后端自动捕获 Agent 的交互轨迹（Trajectories），形成规整数据集，送入配套的奖励结构（Reward Agent / Reward Model）生成训练 Pipeline，完成模型更新后再自动部署上线，让客户无需介入底层 RL 细节。

在商业落地的客户画像选择上，Pyromind 确立了极高的数据门槛。模型能力提升最快的地方，恰恰是“产生于真实生产场景”且“处于现有基础模型能力范围之外”的高质量真实世界数据（Real-World Data）。基于这一标准，Pyromind 当前的核心主力客群集中在**工业制造领域**（包括英伟达上游的供应链企业）： - **数字化基础扎实**：经历过工业制造 1.0、2.0 改造后，厂区积累了极其庞大且规整的生产沉淀数据。 - **标注天然闭环**：工业场景对经济效益指标有严密定义，回流的数据自带相对明确的好坏标签，天然化解了数据标注的难题。 - **ROI 极其明确**：工业生产中的良率提升与成本节约能直接折算成经济账，商业价值显而易见。

---

[10:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=600s) FDE 的递减逻辑与无状态 AutoRL 管道

在企业端落地 RL 或 AutoRL 时，耗时最长、成本最高的部分必然是 **FDE（Forward Deployed Engineer，前线部署工程师）** 的前期现场介入。Kevin 直言，初次切入客户业务时，FDE 工作不可省略：必须由工程师深入一线，摸透企业的数据制式、评价基准（Ground Truth 与业务指标），并将团队自研的 Reward Agent 或 Reward Model 适配到具体产线上。然而，这一工作的价值在于它是收敛的——奖励建模最终会聚拢到模态层面，在相同或相似的模态场景下，后续的大量工作都可以横向复用，FDE 的人力成本随之逐步递减。

横向对比行业格局，去年涌现的一批做 RL as a Service 的团队如今已经出现战略分化： - **Apply Compute 路线**：选择“做宽做重”，为企业提供一整套包含 Agent Serving 等所有周边生态的基础设施，在单一企业内部进行**纵向 Scaling**。 - **Trajectory 与 Pyromind 路线**（包括 DeepMind 出身团队创办的 Trajectory）：专注将强化学习本身打磨至极致，强调标准化与**横向 Scaling**，并与 Marker、Clay、Harvey 等垂直企业展开生态合作。

为了实现跨客户的横向扩展，Pyromind 重点攻坚了**“无状态（Stateless）AutoRL 管道”**的构建。在 Coding 场景中，编译器（Compiler）是一个天然与生产上下文解耦的“无状态环境”，代码只要跑通测试就能获得明确奖励。但在现实生产中（如复杂的 GUI Agent），如果强行把 Agent 与用户上下文完全剥离，就会丧失业务价值；若深度耦合，则会变成无法通用的“有状态环境”。

```mermaid flowchart LR accTitle: 无状态 AutoRL 管道工作流 accDescr: 展示从生产环境轨迹回流、解耦提取数据、无状态奖励打分，到自动化 RL 迭代与模型部署的全闭环流程。

subgraph ProdEnv["客户端生产环境（有状态）"] Agent["业务 Agent"] -->|"执行交互"| Traj["生成交互轨迹 (Trajectories)"] UserFB["人工判定 / 业务结果"] -.->|"标签注入"| Traj end

subgraph EchoMindPipe["EchoMind 管道（无状态抽象）"] Traj -->|"数据打包回流"| Dataset["解耦数据集"] Dataset --> RM["Reward Model / Reward Agent"] RM -->|"计算 Advantage 优势信号"| RLTrain["RL 后训练流水线"] end

RLTrain -->|"权重自动更新部署"| Agent ```

Pyromind 的破局思路在于进行层级解耦：生产上下文的有状态信息留在用户回流的数据集里，AutoRL 管道和 Reward Model 本身保持完全无状态。系统要么通过生产数据中自带的人工 Judgment 提炼奖励，要么让 Reward Model 对 Rollout 轨迹评估出优势值（Advantage）。如此一来，Pyromind 绝不需要把 A 客户的状态打包卖给 B 客户，而只需输出可横向复用的 AutoRL 训练能力。

---

[15:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=900s) 工业落地案例与 Quota 商业定价逻辑

聚焦工业生产，Pyromind 现阶段主攻两个“甜品地带”： 1. **工艺参数优化**：以电镀（Plating）等典型 PCB 制造工艺为例。以往产线高度依赖“老师傅”凭经验手动配置一系列前后关联的物理参数。后训练的核心目标，就是结合产线历史数据与增量数据，把老师傅的人工经验沉淀并迁移到模型中，不仅降低品控波动，还能在数据累积下实现超越人类的调参表现。 2. **多模态工业质检**：涵盖可见光质检与结构光质检，这是典型的多模态视觉问题。在流水线超长链路中，针对 PQ Phase（Process and Quality，制程与良率控制）输出综合报告，是非常适合 AI 闭环处理的抽象任务。

在商业收费模式上，针对底层 **Studio**，采用标准的云计算资源计费（CPU、GPU 算力与存储）；针对上层的 **EchoMind**，则按**业务场景价值与 Quota 配额**计费。这种 Quota 机制更类似于“Mindness Credit”，而非简单的 API Token 消耗。其定价底层锚定了 Pyromind 自身调动 GPU/CPU 算力跑一轮多模态 RL 轨迹迭代的基础成本 $X$，再叠加上团队自研奖励机制的价值增值比例（$X$ 加上特定百分比）。

大颗粒度的工业企业客户，在 ROI 明确的前提下，单体客户客单价通常在**数百万元至千万元人民币**区间。由于高价值工业产线数据回流极快、精度要求极高，模型训练轮次密集，消耗的 EchoMind Quota 规模也相当可观；而面向轻量级 Pro-C 端或开发者小场景，达标 Baseline 即可，Quota 消耗则较小。

针对传统企业客户，技术团队不需要兜售晦涩的 RL 概念，只需讲清投入产出账。例如在实际质检案例中，Pyromind 仅凭借约 **1 万张工业样本**的后训练，便直接将产线的**误报率从 23% 骤降至 8%**。相比之下，那些 ROI 模糊、效益难以量化的轻办公场景（如处理内部发票、员工差旅报销等 Agent），不仅难以说服客户为效果买单，也偏离了团队当前聚焦多模态工业的主线研发方向，通常会被果断拒绝。

---

[25:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1500s) PyroDash：4B 小模型破解企业 AI“不可能三角”

结合自身在阿里云时期的经验，Kevin 指出，Infra 从来不能闭门造车，必须始终是需求导向。当前企业采纳 AI 存在明显的“两层需求”： - **第一层（好用与效果）**：依靠基础模型厂商的成熟 API，或借助 DeepSeek Harness 等 Harness 提示词/工程框架规范模型输出，再辅以基础的后训练能力。 - **第二层（商业落地深水区）**：企业开始在 ROI 约束下追求**“成本、效率、隐私”的不可能三角**。企业既要求极低的推理成本和极致的推理速度，又绝不愿意将核心私域数据上传到公网云端大模型中。

为了破解这一不可能三角，Pyromind 研发推出了新架构 **PyroDash**。这项工作的初衷源于团队内部为了降低极度高昂的外部 Coding 成本。PyroDash 打造了一个由 4B 小模型、协作式推理引擎（Collaborative Query Engine）与后端强基座模型（Base Model）构成的混合系统：

```mermaid flowchart TD accTitle: PyroDash 大小模型协作架构 accDescr: 展示用户请求进入系统后，4B 端侧小模型如何进行难度分类、本地处理或路由回基座模型，并结合 GRPO 优化的全流程。

UserReq["用户请求 (Query)"] --> SmallModel["端侧 4B 小模型 (Worker Model)"]

subgraph EdgeRouting["端侧协作推理引擎"] SmallModel --> Decision{"问题难度分类判断"} Decision -->|"简单问题 (本地可解)"| LocalSolve["4B 端侧直接求解 (推理成本为 0)"] Decision -->|"复杂难题 (本地难解)"| BaseRoute["路由至 Base Model (开源或闭源大模型)"] end

subgraph Optimization["训练与后训练机制"] Phase1["阶段一：难易问题自适应分类"] Phase2["阶段二：大小模型协作推理闭环"] Phase3["阶段三：GRPO 强化学习<br>(正确性奖励 + 带系数的成本惩罚)"] end

LocalSolve -.-> Optimization BaseRoute -.-> Optimization ```

PyroDash 架构具备以下核心技术与业务特征： - **解耦基座模型**：协作引擎在上下文（Context）层面对齐，完全不依赖基座模型的梯度（Gradient），因此 Base Model 可以是任意开源或商业闭源模型。 - **4B 端侧零成本推理**：选定 4B 尺寸是因为该量级刚好能原生跑在 Mac 等端侧本地硬件上，使得大部分本地命中请求的推理边际算力成本降为 0。 - **三阶段训练机制**： 1. 训练 4B 模型对输入问题进行难易分类； 2. 训练其路由判断，简单问题在本地闭环消化，复杂难题再回传给 Base Model； 3. 引入 GRPO（Group Relative Policy Optimization）后训练，设置由“正确性”与“带惩罚系数的推理成本”构成的奖励函数。 - **实测表现优异**：基准测试（Benchmark）显示，PyroDash 不仅使整体表现相比纯 Base Model **提升了约 10%**，而且在 $\lambda$（成本惩罚系数）较小时，还能**节省约 20% 的推理成本**。

针对企业最敏感的数据安全问题，Kevin 强调，仅靠 Harness 工程手段虽然轻量，却永远解决不了隐私边界。在 PyroDash 架构下，企业问题被自然划分为“公域”与“私域”：公域问题交给具备强 Baseline 的通用基座模型，而涉及企业专属机密的私域问题，则交由经 AutoRL 精调后的端侧 Worker Model 本地闭环，从而在后训练层面同时兑现了成本、效率与隐私保护。

[30:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1800s) 破解数据隐私的不可能三角与深垂直领域的模型微调

对话从企业客户最敏感的“数据隐私”问题切入。Kevin Ding 解释，处理隐私首先需要划分“公域”与“私域”：公域问题基础模型（Base Model）已经解决得很好，但企业内部总有一些核心上下文不希望打到外部的公域基座模型上。

针对这一痛点，Pyromind 在开源架构 PyroDash 中设计了针对性的机制。当前开源版本提供了“正确性奖励”和“成本奖励”，以在兼顾性能的同时压降调用开销；同时还有一个正在研发尚未公开的奖励项——“隐私奖励”。该机制训练 Worker Model 具备敏感 token 的脱敏/遮蔽（Masking）能力：在本地通过小模型先挡一层，把敏感信息过滤或遮盖后再路由到云端的公域 Base Model。

面对主持人的提问——“如果企业在本地部署开源模型，直接用 Harness（外围流程编排）把隐私问题路由到本地模型，不也一样能解决吗？”Kevin 直言这会撞上“不可能三角”。如果不去修改底层参数，模型本身生成的结果很难保证真正满足场景要求。Harness 提供的是流程、Workflow、Skills 或 Memory，做的是 Context 层面的修补；但一旦进入深垂直领域（Deep Domain），天花板就会非常明显。

```mermaid flowchart TD accTitle: 隐私与深垂直领域处理架构 accDescr: 展示了 Worker Model 如何处理本地隐私遮蔽及深入任务的路由逻辑 subgraph Local ["企业本地 / 私域环境"] REQ["企业输入 Context"] --> WM["Worker Model (本地训练/小参数)"] WM -->|"敏感信息"| MASK["隐私脱敏 / 本地直接求解"] WM -->|"深垂类任务 (如 EDA)"| END2END["End-to-End 参数微调模型"] end subgraph Public ["公域环境"] WM -->|"脱敏后无害 Token"| BM["公域 Base Model (强推理)"] end MASK --> OUT["交付结果"] END2END --> OUT BM --> OUT ```

- **EDA 场景的极端案例**：以 PCB 板电路图设计的 EDA 软件为例，这是一个极度垂直孤立的领域，绝大多数基座模型在预训练阶段根本没见过此类数据。此时哪怕在本地部署超大规模的 Base Model 并加装各种 Harness，效果依然不理想，必须端到端（End-to-End）修改模型参数本身。 - **与 Thinking Machine (Tinker) 的区别**：Tinker 依赖 LoRA API 机制，而 LoRA 往往与特定的基座模型强绑定，跨基座迁移成本高。PyroDash 的 Worker Model 与 Base Model 在训练阶段完全解绑，二者仅通过 Context 发生协作关联，底座可以随时抽换。

---

[34:02](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2042s) 重塑 FDE 边界：2 个人如何支撑十余家 B 端客户

在落地 B 端交付时，业内常依赖 FDE（Forward Deployed Engineer，前置部署工程师）入场服务。主持人追问 Pyromind 是否在追求弱化 FDE，Kevin 纠正道：他并非要消灭 FDE，而是重构 FDE 角色的“宽度”。

在主流行业定义中，FDE 的工作宽度极宽——要进场调研业务、适配系统、做定制交付，最后交付的往往只是“Base Model + Harness”。但在 Pyromind，FDE 的职责被收敛到前半段：负责把客户需求和场景数据接回来，并在内部自动化平台（AutoRL）上完成首次场景适配；后半段交付的则是一条能够吞吐生产数据、实现自动化数据回流与持续性能提升的“RLaaS（强化学习即服务）管道”。

```mermaid flowchart LR accTitle: Pyromind 的 T 字形服务结构 accDescr: 展示 FDE 与通用研发团队在交付中的前后端分工 subgraph Front ["前端：FDE (业务接入)"] CUST["B 端客户业务需求"] --> FDE_N["深入理解数据制式 & 评测基准"] end subgraph Back ["后端：通用研发团队 (AutoRL 管道)"] FDE_N --> REWARD["首次场景奖励结构适配"] REWARD --> PIPE["无状态 AutoRL 自动化飞轮"] end PIPE --> MODEL["输出更新后的应用模型"] MODEL --> CUST ```

- **极高的团队杠杆**：目前 Pyromind 服务十余家 B 端客户，前端仅靠 2 名 FDE 即可完全承接。 - **T 字形内部架构**：前端 FDE 专注把各个业务需求横向带回；后端通用产品/技术团队则打磨统一的奖励结构（Reward Structure），解决跨领域的复用性问题。 - **无状态管道交付**：Pyromind 追求 business 的可规模化（Scale）。与客户的界限划定得极其清晰：客户传递数据集，Pyromind 的 AutoRL 管道消化后吐出更新后的模型，管道本身保持“无状态”（Stateless），避免沦为卖人头的驻场技术咨询公司。

---

[38:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2280s) 工业质检与工艺参数的“动态掉点”困局

针对模型是否会“训完一次就不用再训”的商业疑问，Kevin 划分了应用模型的两种场景。如果客户业务是静态的，单次训练确实足够；但 Pyromind 聚焦的工业工艺参数优化以及 AVI（Automated Visual Inspection，自动光学检测/工业质检），上游生产环境处于持续动态波动中。

流水线表面看是固定的，但工件批次、工艺细微变动、上下游混线生产以及订单类型的频繁切换，导致输入数据“天天都在变”。在这类深层工业问题中，极细微的分布偏移都会导致判定结果发生巨大变化。如果不通过持续的强化学习管道让模型不断适应新数据，静态模型就会迅速“掉点”（准确率暴跌）。因此，持续训练是维持模型在产线高水准运行的刚需。

- **竞争格局**：在深垂类领域，Pyromind 面对的往往是深耕多年的传统行业 SaaS 软件商。业务无冲突便各自安好，有冲突则探讨合作集成；纯粹做强化学习管道（RLaaS）的直接竞品在工业垂类极少。 - **Agent 垂类案例**：在通用或专业 Agent 领域（如法律领域的 Harvey 等），竞争则更为激烈，这也反向印证了深扎垂直工业场景的壁垒。

---

[40:58](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2458s) 为什么 AI ToB 能算清账，而传统 SaaS 算不清？

ToB 商业模式最底层的本质是“算账（ROI）”。传统 SaaS 往往卖的是一套死板固定的软件流程，容易陷在沉重的交付泥潭中算不清账；而 AI 时代的变量在于“模型本身”。

Kevin 认为，基座模型本身已经具备极强的通用解决能力，核心问题在于“如何正确地教它”。Pyromind 并不是卖一套笨重的固化软件，而是教会模型解决特定的高价值业务问题，用后训练撬动明显的 ROI 提升，因此客户的买单意愿与成交模式要清晰得多。

- **三条选场景准则**：通过严格设定的 3 条标准过滤场景，保证业务切入点整齐收敛，避免把精力耗散在难以标准化的杂乱需求上。 - **面对云厂商的竞争**：云厂商业务线极度庞大、目标繁杂，如同做大模型预训练一样追求最大公约数。这种大平台机制天然决定了其产品形态无法做到 Pyromind 这样专用、敏捷与收敛。如果更多厂商跟进 RLaaS 赛道，反而能共同做大市场生态。

---

[43:26](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2606s) 模态统一是奖励网络的关键，与基座模型共生而非对抗

在模型能力演进层面，当前基础模型处于“宏观认知上看似够用，一旦拉到严苛生产环境就处处不够用”的断层阶段。许多人尝试靠铺人力去填补差距，但这绝非可扩展的路径。

Pyromind 研发自动化管道的核心方法论，是在初期借助适量人工将“奖励网络（Reward Network）”构建起来。构建奖励网络的重中之重是**保持模态统一**：跨模态构建奖励信号难度极高，但在同一模态（如图像、代码、文本或特定信号）内，奖励结构天然具备极强的可迁移性。

谈及基模越来越强是否会挤压小模型生存空间，Kevin 表示 PyroDash 从第一天起就是站在巨人的肩膀上： - **互补而非替代**：PyroDash 架构本身就是以 Base Model 为基底，外挂 Worker Model 与 RLaaS 补丁。基座模型推理能力越强，Worker Model 承担的协作压力反而越小。 - **公域走协同，私域走单模**：在基模能力覆盖的广度内，直接走 PyroDash 的协作引擎；在基模覆盖不到的深度私域，则走端到端单模型微调。归根结底一切由客户需求决定，需求侧才是唯一的驱动源。

---

[46:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2760s) 创业的共识时刻、个人 AI 工具箱与小模型蜂群的终局

在尾声的轻松对谈中，Kevin 分享了创业以来最有成就感的时刻。那并非某个外部里程碑，而是近期与 CTO 深度探讨 PyroDash 架构方案时，两人从最初观点不一致到最后在“小黑屋闭门论证”中达成共识的瞬间。他笑称，内部经常就具身智能（Embodied AI）等前沿课题展开高强度辩论，“不同视角碰撞就像多目标奖励信号，提炼出来的收敛结果往往离真相最近”。

关于日常工具与技术趋势，Kevin 观察到了一系列值得深思的产品与数据现象： - **日常工具偏好**：写代码高频使用轻量级 Coding Agent（如 Pi/Pi.ai、Claude Code 等）以及开源黑马项目 DeepSeek；日常模型体验兼顾 Claude、Kimi、GLM 以及通义千问（Qwen）系列。 - **Hugging Face 趋势印证**：Hugging Face 发布的报告显示，本地运行（Local）模型的下载量主要由 100B 以下的小参数模型主导（包括 Qwen 3.8B、7B 等型号），100B 以上的超大模型下载量占比极小。

这一数据强力佐证了 Kevin 的核心论断：**真实的需求世界是高度多元的，绝不会所有任务都被收拢到一个中心化大模型里去解决**。海量小模型的下载需求，代表着真实世界中分布式计算与专用任务的庞大体量，而这正是 PyroDash（4B 小模型 + 协作引擎 + 强基座）选择在此时推向社区的底气所在。Pyromind 期待的下一个 Milestone，便是让 PyroDash 架构走出纯基准跑分，在真实工业生产环境中真正解决那些最棘手的卡脖子难题。

## Notable quotes > Service 只解决了一半问题；真正要让 Agent 在生产环境中持续改进，还需要把训练、奖励、反馈、部署和数据回流串成一条可以自动循环的管道 — Kevin Ding

> 需求世界是多元的，不是所有问题都应该被收拢到一个中心化大模型里解决。 — Kevin Ding

> [00:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=0s) 用有限参数的模型去泛化无限且非静态的现实场景极其困难。因此，未来更实际的形态是高度服务化的 Agent 蜂群（Swarm）。 — Kevin Ding

> [10:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=600s) 初次切入客户业务时，FDE 工作不可省略：必须由工程师深入一线，摸透企业的数据制式、评价基准……并将团队自研的 Reward Agent 或 Reward Model 适配到具体产线上。然而，这一工作的价值在于它是收敛的 — Kevin Ding

> [25:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1500s) 企业开始在 ROI 约束下追求‘成本、效率、隐私’的不可能三角。企业既要求极低的推理成本和极致的推理速度，又绝不愿意将核心私域数据上传到公网云端大模型中。 — Kevin Ding

> [30:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=1800s) Harness 提供的是流程、Workflow、Skills 或 Memory，做的是 Context 层面的修补；但一旦进入深垂直领域（Deep Domain），天花板就会非常明显。 — Kevin Ding

> [38:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2280s) 极细微的分布偏移都会导致判定结果发生巨大变化。如果不通过持续的强化学习管道让模型不断适应新数据，静态模型就会迅速‘掉点’（准确率暴跌）。 — Kevin Ding

> [40:58](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2458s) Pyromind 并不是卖一套笨重的固化软件，而是教会模型解决特定的高价值业务问题，用后训练撬动明显的 ROI 提升 — Kevin Ding

> [43:26](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2606s) 跨模态构建奖励信号难度极高，但在同一模态（如图像、代码、文本或特定信号）内，奖励结构天然具备极强的可迁移性。 — Kevin Ding

> [46:00](https://www.youtube.com/watch?v=NpMR0lO6Fjc&t=2760s) 海量小模型的下载需求，代表着真实世界中分布式计算与专用任务的庞大体量，而这正是 PyroDash（4B 小模型 + 协作引擎 + 强基座）选择在此时推向社区的底气所在。 — Kevin Ding

## Mentioned Kevin Ding, Koji杨远骋, Pyromind, PyroDash, Pyromind Studio, EchoMind, 高瓴, 百度风投, 蓝驰创投, Atypical Ventures, 阿里云, 英伟达, Trajectory, DeepMind, Apply Compute, Marker, Clay, Harvey, Thinking Machine (Tinker), Hugging Face, DeepSeek, DeepSeek Harness, Claude, Claude Code, Pi (Pi.ai), Kimi, GLM, 通义千问 (Qwen), King's College London, GRPO

## Video description ➤ 本周「十字路口」的嘉宾是 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 的朋友。 01:55 AI 终局为何是 Agent 蜂群？ 05:21 RLaaS 只解决了哪一半？ 08:32 谁最适合 AutoRL？ 22:13 误报率如何从 23% 降到 8%？ 26:29 企业 AI 如何破解不可能三角？ 27:03 4B 模型如何更准更省？ 34:02 2 个 FDE 如何服务十几家企业？ 40:58 AI ToB 为何能算清账？ 42:06 云厂商会吞掉 Pyromind 吗？ 47:47 小模型为何仍有大需求？

[Source](https://www.youtube.com/watch?v=NpMR0lO6Fjc)

中文简报

Pyromind推大小模型协同架构，押注工业AutoRL替代单一巨模中心化大模型无法通吃多元且动态变化的物理生产环境，企业必须依靠无状态强化学习管道与端侧小模型协同实现闭环迭代。 Kevin 深入阐述了为何 AI 下半场的终局是动态演化的“Agent 蜂群”而非单一中心化超级模型，指出后训练必须将算力与奖励机制闭环为自动化的 AutoRL 管道。Pyromind 重点切入工业质检与工艺参数优化等高价值、强反馈的生产场景，通过无状态管道与模态统一让 FDE 前期投入逐步递减，打破传统咨询定制的重交付陷阱。团队进一步推出 PyroDash 架构，利用 4B 端侧小模型与协作推理引擎联动云端强基座模型，在 GRPO 强化学习驱动下破解了成本、效率与隐私的不可能三角。整场对谈论证了在基座模型日益强大的背景下，海量小模型与专用强化学习管道在实体生产深水区中不可替代的共生价值。 Pyromind 验证了 AutoRL 商业闭环，在工业质检实战中仅用约 1 万张样本训练即将产线误报率从 23% 降至 8%，工业大客户客单价达到数百万元至千万元人民币区间。 (15:00) 针对企业在成本、效率与隐私间的不可能三角，团队推出 PyroDash 架构，通过 4B 端侧小模型与基座模型协作，在 Benchmark 提升约 10% 的同时节省约 20% 推理成本。 (25:00) Pyromind 重新定义 FDE 角色边界，仅凭 2 名现场部署工程师即支撑十余家 B 端客户，将交付收敛为无状态（Stateless）AutoRL 自动化管道以规避驻场咨询陷阱。 (34:02) 工业产线由于工件批次与订单切换导致数据天天变化，静态模型极易发生“动态掉点”，使能够闭环吞吐生产数据的持续强化学习成为生产级刚需。 (38:00)

Reading summary

Pyromind 创始人 Kevin Ding 认为，现实业务场景的无限与动态特性决定了 AI 下半场无法仅依赖单一中心化超大模型，而将走向高度服务化的 Agent 蜂群；通过无状态 AutoRL 自动化后训练与端侧小模型协作架构，企业能够在高价值垂直场景中平衡性能、成本与数据隐私。路线分野：从中心化超级模型转向 Agent 蜂群 (0:00) 围绕通用人工智能的演进路径，业内存在“沿预训练持续扩增的单一超级模型”与“服务化 Agent 蜂群”两种判断。Kevin Ding 指出，现实世界中需要被 AI 解决的场景无限且持续动态产生，受限于 Transformer 的有限参数，单一模型极难完全泛化非静态的物理世界。随着企业内部署的 Agent 数量成倍增加，人工维护生命周期已不可持续，核心指标在于 Agent 能否在长周期内契合业务预期，这要求系统必须引入强化学习（RL）后训练以实现基于真实环境反馈的自我迭代。在商业实践中，团队最初尝试的 RLaaS（RL 即服务）模式仅解决了底层训练算力调度，终端仍需大量人力介入需求分析与奖励编写。为此，Pyromind 转向全自动闭环的 AutoRL 模式，构建了包含面向模型工程师的 Serverless 训练基础设施 Pyromind Studio，以及通过挂载 Proxy URL 即可自动捕获交互轨迹并更新模型的端到端产品 EchoMind。工业制造闭环：无状态管道与高 ROI 落地 (5:00) 在客群选择上，Pyromind 将切入点聚焦于工业制造（涵盖英伟达上游供应链企业）。此类场景具备工业 1.0 和 2.0 积累的规整数据，经济效益指标对好坏标签有明确定义，天然化解了标注难题。目前落地的核心场景包括 PCB 电镀工艺参数优化及多模态外观质检（AVI）。据团队披露，在实际质检项目中，模型仅基于约 1 万张工业样本的后训练，就将产线误报率从 23% 降至 8%；工业客户单体客单价通常在数百万元至千万元人民币区间，按调动算力成本叠加自研奖励机制增值的 Quota 配额计费。为了摆脱驻场定制开发的低效模式，团队攻坚了“无状态（Stateless）AutoRL 管道”。与编译器等天然解耦的代码场景不同，工业生产强依赖业务上下文。Pyromind 的做法是将生产环境的有状态信息保留在用户回流的数据集内，使 AutoRL 训练管道与奖励模型本身保持完全无状态，以此实现算法能力在相似模态间的横向规模化复用。组织杠杆与持续训练：化解产线动态掉点 (34:02) 针对企业级交付通常需要耗费大量前置部署工程师（FDE）的痛点，Pyromind 将 FDE 的职责收敛至前期业务调研、数据制式梳理及首次奖励适配，后续的数据吞吐与模型演化则全权交由后端无状态管道自动化承接。依靠这种 T 字形分工，团队目前仅凭 2 名前端 FDE 即可支撑十余家 B 端客户的交付运维。针对模型是否只需单次交付的疑问，Kevin 解释，工业制造面临原材料批次更替、工艺微调、混线生产和订单频繁切换等常态，输入数据处于持续波动之中。在深层工业问题中，极细微的数据分布偏移都会导致静态模型迅速“动态掉点”（准确率暴跌）。因此，保持自动化强化学习管道的持续运行、让模型不断适应产线新数据，是工业客户长期维系良率与稳定性的刚性需求。 PyroDash 架构：协作推理破解不可能三角 (25:00) 企业在商业深水区普遍面临“成本、效率、隐私”的不可能三角。为此，Pyromind 推出了开源混合推理架构 PyroDash，由可在端侧原生运行的 4B 小模型、协作式推理引擎与云端强基座模型构成。两类模型在上下文层面解耦协作，无需依赖基座模型梯度。系统经由难易问题分类、协作路由以及结合正确性与成本惩罚项的 GRPO 强化学习训练，实测基准相比纯基座模型性能提升约 10%，并在特定系数下节省约 20% 推理成本。针对企业私域数据安全与极端垂直场景（如预训练极少见到的 PCB 电路图 EDA 设计），单纯依靠外部工程编排（Harness）存在明显的表现上限。PyroDash 通过 4B 本地 Worker Model 承担敏感信息脱敏屏蔽或端到端特定参数微调，公域问题则交由通用基座处理，从而在技术底层兼顾了私密性与推理经济性。 Kevin Ding 援引 Hugging Face 报告指出，本地模型下载量绝大多数由 100B 以下小参数模型主导，印证了现实世界对分布式与专用小模型的庞大诉求。不过，PyroDash 等协同架构当前核心在于走出跑分基准，未来仍需在更严苛、非静态的工业实体产线中持续验证其落地稳定性与投入产出比。

Source quotes

Kevin Ding: Service 只解决了一半问题；真正要让 Agent 在生产环境中持续改进，还需要把训练、奖励、反馈、部署和数据回流串成一条可以自动循环的管道 Kevin Ding: 需求世界是多元的，不是所有问题都应该被收拢到一个中心化大模型里解决。 [0:00] Kevin Ding: 用有限参数的模型去泛化无限且非静态的现实场景极其困难。因此，未来更实际的形态是高度服务化的 Agent 蜂群（Swarm）。 [10:00] Kevin Ding: 初次切入客户业务时，FDE 工作不可省略：必须由工程师深入一线，摸透企业的数据制式、评价基准……并将团队自研的 Reward Agent 或 Reward Model 适配到具体产线上。然而，这一工作的价值在于它是收敛的 [25:00] Kevin Ding: 企业开始在 ROI 约束下追求‘成本、效率、隐私’的不可能三角。企业既要求极低的推理成本和极致的推理速度，又绝不愿意将核心私域数据上传到公网云端大模型中。 [30:00] Kevin Ding: Harness 提供的是流程、Workflow、Skills 或 Memory，做的是 Context 层面的修补；但一旦进入深垂直领域（Deep Domain），天花板就会非常明显。 [38:00] Kevin Ding: 极细微的分布偏移都会导致判定结果发生巨大变化。如果不通过持续的强化学习管道让模型不断适应新数据，静态模型就会迅速‘掉点’（准确率暴跌）。 [40:58] Kevin Ding: Pyromind 并不是卖一套笨重的固化软件，而是教会模型解决特定的高价值业务问题，用后训练撬动明显的 ROI 提升 [43:26] Kevin Ding: 跨模态构建奖励信号难度极高，但在同一模态（如图像、代码、文本或特定信号）内，奖励结构天然具备极强的可迁移性。 [46:00] Kevin Ding: 海量小模型的下载需求，代表着真实世界中分布式计算与专用任务的庞大体量，而这正是 PyroDash（4B 小模型 + 协作引擎 + 强基座）选择在此时推向社区的底气所在。

Original transcript

[0:00] 嗨,我是Koji本周十字路口的嘉宾是PyroMind的创始人和CEO Kevin DeanPyroMind所在的赛道是非常热门的RL as a Service也就是强化学习及服务或者后训练及服务他们前不久刚完成了天使轮融资投资机构包括高林、百度风投、蓝池等你好凯文欢迎来到十字路口大家好好我们还是从快案快答开始帮助大家尽快了解你请问凯文你的年龄我是94年的32岁请问你的求学经历伦敦国防学院Kens CarlssonMBTI和星座如果是按测试结果来看是INTG但是我的感觉可能IE之间那么一句话介绍一下PyroMine最终定位就是一个AutoRail它跟现在大家一直在讨论的RSI这个方向其实是相对于它是一个比较具象化的一个实现路径我们待会再讲开聊一下对然后咱们的融资情况呢我们是去年公司成立之后就做了一轮高岭百度风投还有蓝驰还有Adebico目前咱们团队的规模是我们现在有20多个人咱们现在收入和利润方面讲吗具体数值就先不是这样的但是现在我们我觉得比较振奋人心的一点我定义就是说他初步的跑通了PMF什么样的PMF跑通了两个方向一个方向就是证明我们提供out-of-rail正方式是有价值的这是第一点它的商业模型至少是成立的第二点就是说它的这种可困难性就是说在横向的这种场景和客户的这种复制上来说我们的工作量是逐步递减的明白咱们在创业之前做过些什么我之前其实有很多经历是放在PN Infra这里的因为我之前也是在阿里云然后在阿里云其实也做了弹性GPU实力包括训练GPU的这些集群当时咱们是看到了什么样的机会决定创业做Paramind其实当时我的想法是这样模型预训练这个事情到现在为止其实远远没有到终结的时候当时看到一个趋势就是到25年下半年也看到无论社区也好还是硅谷也好还是国内的技术权也好大家都在讨论AI可能要进入下半场下半场的说法就出现了两个方向一个方向就是认为我们继续沿着预训练走AI才到来的形式会是一个超级庞大的它能够解决绝大多数的场景里面的问题效果还足够好然后另一条路线或者是另一个讨论的方向就是它最终ASI的形态会是一个服务化的形态是一个agent的风群的形态因为我个人来说肯定偏向于后者我觉得这个更实际一点因为我们这个世界上需要去被AI解决的问题和场景它其实无论是从当下时间点看它就是已经是无穷无尽的了同时随着时间的推移会产生不断的新的这个场景出来而且这个场景本身它也不是静态的那在这个模式下我们尝试去用一种有限参数的这么一个模型去泛化掉无限的场景这个事情目前来看我觉得在至少在这个Transformer这个架构上实现还是蛮有挑战的到目前为止又过了一年多就是你有看到一些信号就是这个让你感觉你一开始的BET是越来越成立了吗是的理论我们看到的是第二条路必然是成立的就是我不能说正伪第一条路但是呢呃我我能论证的就是说第二条这种服务化的路线它是一定成立的因为需求是一直在那里的然后需求一直也在增长的然后这一年我看到的一个变化就是说大家为什么现在去提RSI为什么就是呃在之前RSI其实没有热度没有那么高其实这就是服务化带来的一个结果是因为你去agent步的多了就是我们可以想象一下就是正常一个人日常呃即是个agent再去做一件事他是不可能有精力去维护每一个agent的这种眼镜的对吧而siv需要就是因为其实agent的现在开始多起来了我们这一个个的agent在嵌入到场景里面的时候我们对它最终的衡量方式是它得在一定的时间轴上表现都得符合我的预期这个实现的方法就是agent需要自我去迭代然后你agent的本身需要有自我改进的能力才能做到这件事咱们一开始做Paramind的时候就想到了要用AutoRL去做RSI吗还是这个是在过程中慢慢浮现出来的实话说其实是过程中浮现出来的场景一方面我们自己本来就在看这个方向另一方面就是其实讲一个有意思的故事就是后续的这个事对我们自己影响比较大因为你会发现以RL为代表的这种后训练技术它其实是拿到环境的反馈然后去更新拿到它是一个持续的过程那其实对我们自己去研判方向我们团队也是这样子的 [5:00] 我们其实一开始在创立之初我们认为做到ROA service做到一个扁平的service形态其实就已经差不多能满足这些agent的部署的这些要求了但是我们后来发现它依然是不够的因为service它的面向的对象终归还是要有一个developer在那边去驱动agent去改进的对吧所以我们在这个阶段我们才去想其实service只几了一半的问题因为我们真正把RSI跑起来要解决两个问题Train Infer 一个是奖励的问题所以我们就开始规划说Auto RL要怎么跑起来同样的奖励就纳入了我们的scope可以用一个具体的客户的例子来讲一下我们只给他单独做RLSService和我们现在要给他做Auto RL具体的博物的内容有什么不同吗我觉得比较好的例子就是GUI Agent的一位客户因为他们下游有蛮多的消费的部署量的然后他会收上来很多这种用户这种特定的需求以及他自己的产品迭代一些需求进来我们一开始提供的这个RO Service呢是给了他一个Studio然后去把一个通用的一个Training Pipeline去给他固定下来但是呢他依然是要不断的去投入自己的这个创办公众师也好或者什么样的人也好去不断的去更新这个Agent本身我们只给他去把训练这件事情解决得很好因为就是你想嘛一个训练要去完整的解决完就是完成一版模型更新他其实除了这个需求册的一些分析就翻一张奖励然后训练同时后端的infra也要被解决我们当时把infra的问题全部给它解决掉了但是他依然没有摆脱掉说他依然会去投大量的人力去搞这个东西然后我们后来去就是到了第二期的时候呢我们去把这个GY方向的这种奖励做了做之后呢我们发现其实这个loop其实可以自动化的跑起来的因为就是只要他的这个末端部署的这些agent他能源源不断的收上来用户在真实环境下的一些反馈这个东西说过来之后我们在想那为什么不让它能够自主的循环去跑起来所以我们在第二期就给它把这个EchoMine产品推过去了其实咱们现在提供的这个主要的产品有两个一个就是Paramond Studio然后另外一个叫EchoMine然后可不可以分别介绍一下他们俩是什么样的产品Studio就是我们提供的解决训练Infra的一个Serviless的一个Service我们会在这个Studio上去实现大量的这种训练所依赖的逻辑节点因为开发者在去配这个节点的时候他是不需要去关心他在物理机上实现的他更多的只是配置了一个训练的参数然后逻辑节点它横向着K-Scaling的你可以去做这种单点的单卡的算力然后单台的到多台的这种都是可以在一个逻辑点上去扩展的然后扩展的工作是我们去做掉了然后对于开发者来说他只要去把训练的参数以及像DP-Size去配备好就可以了然后对于Ecomine的这种产品来讲这台所叙述的整个 RSI的流程全部都包在这个ACMINE的背后然后我们给用户透出的是什么呢是一个proxy 就是一个代理的URL然后呢这个URL只要去插入到某一个agent里面其实他就可以去源源不断的去把agent在这种轨迹抓起来它就是一个相对来说比较整齐的一个数据集那这个数据集他去过这个奖励结构然后去生成这样的一个training pipeline 然后去训练拿到结果然后再部署回去好产品去包起来了对OK那Paramad现在典型的客户画像是什么我们去做客户的选择的时候它其实需要的是真实世界的这些数据并且这真实世界的数据一要产生于生产场景第二个它最好是在模型能力之外对吧这个其实对模型的效果提升是最明显的然后我们去选择客户的时候就在思考哪里的real world data最负极对吧我们当下有一些比较重要的客户就是集中在工业领域的就是像英伟大的上游这些企业然后他们有个特性就是经过过往的这么几年的制造1.0 2.0的这些改造他们其实在企业内的数字化做的还是蛮好的同时经过了这么多年的生产又积累下来一批非常可观的数据这是一个指标然后第二个指标就是工业场景还有一个好处它除了数据复迹之外它自己对于自己的经济生产它是有定义的这样的话收上来的数据往往都有了一个相对明确的好坏的标签你标注这个问题也天然的就被他解掉了与此同时我们同样的毕竟还是一个商业行为我们要去衡量一下他的RI然后这三个条件都满足情况下我们在产业链上的工业的客户他可能是一个比较好的画像工业客户是一类还有其他的比较典型的客户画像吗还有像Agent或者是和巨生相关的对巨生相关的其实我们也会看当然当下来看巨生 [10:00] 是一个相对独立的这么一个板块因为我们目标还是去做后训练驱动的这种RSI当下偏软领域肯定会做的会更快一点因为巨身你还要需要去考虑硬件那部分东西这个是一个更复杂的一个问题然后在咱们给企业去做RL不管是RLS Service还是我们做AutoRL的过程当中最花时间最花钱的是什么部分最花时间的实际上是的这个FDE的工作就是你看我们虽然说做RSI但是我们并不排斥就是完全FDE因为就是本身你去让这个把RSI渗透到某一个场景的时候这个FDE这个阶段是不可省的然后我们在初次进入的时候需要去把他们场景里面的这个数据知识还有它评价基准然后同时我们自己做的这套比如说奖励Ager Reward Agent或Reward Model去适配到这个场景上这个是比较花时间的但是好处呢你在这类型的行业其实在初次能几栋是需要做一些工作的但是后面scaling起来它的工作就是递减的对这个是我看到一个比较好的一个现象因为其实做奖励这个事情它最终还是会收拢到模态上就是它在相似模态上的话其实有相当一份工作是可以服用的对所以去年那一大批不管中国还是美国做RL as a service的公司现在大家都和咱们一样慢慢的开始都要去做autoRL塞了吗我觉得大家是有分化的因为首先对于下半场这种需求来说它是非常丰富且非常宽的比如说去年和我们应该说我们同期去看了一些公司他们在做的事情比较出名的应该就是Apply Compute它其实到现在为止已经更往前走了一步它会去提供一个非常完整的这种服务的技术设施它去把agent serving这些东西全部都做了我去把企业内所有和agent和AI相关的东西我全部都做掉了这是一个路线然后还有一个路线呢是应该是近期比较出名的是那个trajectory 也是deemind的人出来去搞的一家非常优秀的一个公司然后他们做的呢就和我们的理念会相似度相相对会高一些他们就是单纯的去做这个二头二摇同时他们跟这个merker啊或者是clay或者是那个hervey啊他们也有一些这个合作然后他们的定义我觉得跟我们就会相对的说比较相似一点我们更期望做到的是Auto这个事情我们去把五状态的RSI的能力提供出去它是一个可以平台化的东西五状态的对因为这两个分支其实你能看到它的属性前者叫他Compute做的就相当于是我把企业里面所有的这场景我全部都爆掉了对吧它是一个更加宽并且更加重的一个方式然后后者呢它是一个scanning的方向不一样Apply Compute它是在一个企业内纵向去scaling然后对于Tradectory这个思想就是它是做只把这个训练这一件事情做好然后横向去scaling我们更倾向用这种方式来做然后回到刚才那个状态的问题啊因为其实有状态无状态它最典型的例子是这个做环境因为其实大家做后训练这个环境是被高频提到的一个词然后我们对环境的理解呢就是呃他原本其实在coding领域环境是一个非常典型的东西因为你去把这个这个compiler去提供出来对吧他其实你每生成一个新的这个代码片段去compiler去跑一下他都能够拿到一个呃比较强的一个奖励信号他是否通过了对吧但是呢就是他的一个特性就是他跟你本身这个生产环境里面的这些信息他是不偶合的他是可以被抽离出来的对吧但是对于实际生产生产环境来说呢这样的环境就比较有限对吧你比如说是刚才举的那个例子就是像这个GValied Agent对吧你想去把他每个用户的一些自己的需求去做好的时候你是不能脱离他的这个用户上下文存在的如果你脱离了对吧他就缺乏了生产价值如果你跟用户上也会偶合在一起那么他就是一个有状态的环境所以我们要去做的事情是在这么长的链路里面找到可以很像去Scanning的无状态的东西这个东西它就不单纯的是一个environment而是说它应该是一个auto rl的这么一个管道这样的一个管道就是你给它去位数据然后它拿到数据之后通过reward agent及reward model去拿到reward signal然后去迭代一轮然后这种其实你本身的这个outRL的管道以及reward本身它其实就是一个无状态的它跟生产上下文其实是不合的这里我有点困惑因为它一旦是奖励信号它应该就是在真实的生产环境里面出现的奖励信号怎么能抽离出来呢?你对于这个场景来讲它需要去做一层捷偶的因为奖励信号本身实际上是当模型去在这个场景里面去rollout [15:00] 一次对吧对应的reward model或者说reward agent他去给出一个这种优势就是advantage对吧就是你给出一个这种优势才能找到更新的方向这是一种方法第二种方法就是他生产场景回流回来的数据他包含了一些人工的这种judgment这样子其实他也是一种奖励但是这两个信息就是他本身跟他的上下文其实已经结偶掉了他是包含在用户去回流过来的数据集里面而不是包含在我的环境里面也就是说这里面的模式的区别是对于我们要去做一个横向可以skilling去卖给不同客户的产品来讲我不能去把A客户的状态打包进我的产品里把它再卖给B客户这样是不行的可以再稍微展开一下刚才咱们提到第一类的典型客户是工业工业的客户咱们在给他提供服务的时候我们具体帮他们做了什么工业其实我们现在偏软的主要看两个场景一个是和工艺相关的就是对于这种工艺改进的这种模型其实它去做post training还是比较甜品的一个地带然后第二个就是做这种质检的质检的其实它也是个典型多么太问题也是一个比较甜品的地带然后工业领域它有个好处是无论是工艺还是质检其实它的数据复及程度是我们无法想象的就是非常非常复及而且是它对这个东西的结果是好还是坏都有明确的评价基准质检比较好理解工艺可以举一个更具体的例子吗工艺其实就类似于像电镀我们其实可以不用深入到它具体是怎么做的它其实就是说在生产线上有一批参数要配然后这批参数配好了之后它的产线后段就能拿到他想要的东西但是参数国配的不合适拿到就不是自己想要的东西然后现在的做法是还是有老师傅在做这个事的对吧因为这个还是其实它就是个人驱动的一个事情然后你去做后训练对模型做后训练的目标是能够有效的去根据它历史的数据和未来增量的生产数据去把人做这个事情的经验去迁移到模型里这样的话其实模型在去做这个事的时候无论就是说它在长期来看的这种品控的保护上就是品控做的水波动上还是说随着它增量数据略越多它可能会比人做得更好这个上面它其实模型现在是有能力去做到的咱们怎么收费呢我们现在就是有两层产品一层产品就是我们定义R-Service的Service层它就是Studio然后这个其实对于用户来讲它更多是资助式服务那这里我去寄费的方式就很简单了那就是白资源的这种寄费方式就是类似CPU存储GPU这样的因为这是在这个Service层的Service的计价其实大家也都比较归拢因为其实Cloud Service做了很多年了然后对于上层的这种AutoRL的产品我们就是白这个场景价值来去寄了然后它寄的方式也是Quota我们会去根据它场景里面的更新的频率来去限制给它一个Ecomine的实力它的QDA的限制在哪里这样的话其实就是白效果因为我们对于Ecomine的AutoL这样的产品我们是嵌入了我们提供的奖励价值的我们相当于除了把训练Service做好之外我们同样的用我们自己的奖励结构去给出了它胜区的一个更新方向所以对于客户来讲他其实什么都不用管他收到的是一个更新好的模型所以第一部分service是等于训模型一次性的收入后者可能是更长期的收入其实前者也是长期的只是他俩的边界就是在于谁来维护RSI的管线如果是studio的用户的话其实他这里面的管线是客户自己在做的包括reward func function也是客户自己去写的我们只提供这个稳定的一个infra service但是对于Ecomite来讲因为我们自己介入了它实际场景里面的这些问题所以说我们会把它内化到我们的这个revolve model上面我们来去维护这个事情那像一个典型的用户他向你们付费大概是什么量级就能从他那收到或者赚到多少钱因为我们做的RSI这个形态它适配的光谱是很广的所以说对于大颗粒的企业来讲其实它付费还是蛮高的在ROI很明确的场景下其实单体客户付费基本上也是到百万到千万人民币的区间了但是因为本来RSI这个事情或者说autoRL这个事情它能够改进的场景可以有这种放大效应非常大的ROI的场景同时它也会有一些比如说developer做coding的一些很小的场景小的场景的话其实对于用户来讲它的颗粒度可能就比较小我们去做这个为什么一直在强调横向就是本来auto-rl这个事情它就是应该无缝的渗透到所有类型的agent里面的至于说我们的这种大颗粒度的B端客户还是小颗粒度的这种PNC端 Pro C端的这种客户的付费它都是取决于这个agent本身能给它创造多少的这个效益出来对 [20:00] 我们的这个ECOMED的这个计价就是一个单一的这种quota的计价我们其实也很容易去区分这个场景就是对于高价值场景来说其实它的这种生产loop里面积累的数据量也是相应的会大很多同时它要求也很高你要去做的这个训练轮次也很多所以说它对应的ECOMED的quota消耗就会是一个非常可观的数字然后对于一些比如说ProC这种很小的场景它可能要求没有那么高它只是说达到某一个base line就可以了同时它在一个相对窄的斗密里面没有那么多它的QOTA消耗就会比较少刚说QOTA消耗的时候说的是Token消耗吗其实是我们定义的这种应该说一个资源单元就是我们去衡量本身Ecomite去做一轮RL在嵌入奖励价值下的一个单元所以它等于就是比如说Mindness的Credit还是类似于Credit对它跟Token其实不是特别的绑定它和什么绑定它就是我们去做一轮这样的一个其实我们自己会有一个成本账对吧你在做这种多莫泰的这种常年轨迹他做一轮我们大概成本是X然后同时我们嵌入了奖励价值之后我们会对Quota去定一个X网上去加一个百分比的这种形式你们的成本主要是Token成本还是是什么成本我们实际上是训练消耗的资源成本主要还是GPU CPU这样的资源对我们自己的内部的成本是这样现在企业主要找到你们他们会怎么表达他们的需求这就是涉及到需求侧了就是客户他能get到或者说最直接的方式就是你的结果是什么为什么我们去做像这种质检领域和公益领域这两个领域的这种结果是显而易见的然后对客户来讲他其实只问一个问题就是我需要付出什么然后我付出了这个之后我能拿到什么这个给他结识清楚就好了就是为什么我们会我们觉得RLS service不够对吧因为我们如果说面向这项客户提供了一个service他去自我自主去开发的这个肯定是不合理的我们提供Ecomine的呢就是我们可以明确的告诉他就是在你历史的这些样本上然后我们去做Excellent的这样的训练就能拿到一个像一个指标然后其实像质检这个领域我们其实比较有效的可以把误报率从当下的23%直接降到18%能给他去这只是在大概1万张的这个样本上去做的然后这样子其实它的成本和收益就非常明确了对那他一般会怎么理解你们的报价因为你其实自己创造了一个定价的体系问到他那他会对标什么来去理解这个价格其实客户对价格的理解更多的是在于这个事情在我的场景上的RI有多少以及我付出这个代价在我RI里面占比他要去判断这个东西值不值得搞其实对我们来讲总归因为我们的消耗其实主要还是店的消耗所以说总归下来这个账是双方都算得过来的因为我们选场景的时候也会去选放大效应比较好的场景就有一些场景其实那不是所有场景我们现在都要做的比如说有一些像偏办公的偏这种发票的或者说差旅的这种agents我们其实做起来就感觉会比较吃力因为它的ROI是不好衡量的在这里去说得通就有一些难度有没有什么类型的需求是总找你们但你们觉得就确实在这个时候就不做拒绝我觉得一个是这种ROI不明确的就是我选场景有三个依据第一个依据就是ROI必须是可衡量的然后如果是不可衡量的我不好定价第二个就是他不要偏离我们现在的研发主线我们现在其实去搞的是这种主要是东摩态的场景因为落地的话其实你不可能做单摩态然后第三个就是这个场景本身它在企业内的这种扩展和跨这种企业的扩展它是有扩展性的的领域就是一个是工艺工艺它本身像比如说电镀这个工艺它在所有的这种PCB的这种行业里面它都是通用的然后质检就像可见光质检包括结构光质检这个其实在几乎所有的制造也都是通用的起来还是蛮和它其他环节节偶的它其实倒不能说节偶了因为它现在其实本来都是流水线它其实前后的都是息息相关的其实现在还有一个挺好玩的一个case就是它这些场景它整个这种生产流水线是很长的这种叫PQ Phase的这种控制整个去出一个报告就是Process and Quality这种控制它会去做一个更丑向的一个报告好处是什么它是可以被AI很好解决的一个单元我们去看是这么看这个问题的其实之前你看你在阿里云是做Infra然后现在开始感觉非常要深入到各个客户的业务的一线的现场就这个中间是一个什么样的过程就对你来说创业的这种体验经历但是我觉得跨路 [25:00] 没有那么大因为做infra本身就是一个需求导向的对吧infra不可能闭门造车的对吧我们基本上都是以需求驱动的方式来去做的现在其实做客户也是一样的我们再去看到这个场景之后然后客户有明确的需求我们去提炼其中的共性然后找里面可以去skew up的点找到之后我们就把它做成一个产品对这个路径其实在infra时代就是思维模式完全是相通的对就还是从需求出发对我们其实之前在阿里零阶段也做了很多这种商业的这种客户我自己在想AI现在在落地的阶段或者说产生价值的阶段它需求其实是分层的需求的这种接受度是分层的第一层就是这个东西是不是好用以及它效果是不是好是不是好用这个事是不是简单这个事其实有很多方式可以实现比如说现在机动模型做的API就非常应用API之外比如说DSH他做这个deep-stick harness对吧这个东西也很好用对吧好用解决了然后效果怎么解决呢效果就是你可以加大量的hardness逻辑让这个模型行为对齐到你的需求上然后呢同时你也可以去做后训练你用训练的方式来提升模型能力来达到效果好用这是这其实是需求的第一层然后下沉到第二层他就会考虑第二个问题就是我做这个事情ROI是不是合理我得有收益我做这些没收益我就不会做了然后再就是说这个本身搞这个东西其实企业里面需求到第二层的时候他就会追求一个不可能三角了就是我既得成本好又得效率好未来还能不能满足我的隐私的需求对吧他到了这一层的时候就会对需求这个就要求就会很多了对所以说我们选择去做RL我们为什么没有去做Harness对吧我们没有去集中精力去做Harness我们选择RL以及把它做成RSI其实我们看到的是长期来看这种autoRL的形式的RSI它是可以正好把这两层需求都完美的承接掉的尤其是刚才提到的深层次需求里面的不可能三角这个东西实际上就是我们近期发的一个工作就是ParaDash对吧给大家讲讲ParaDash到底是什么对因为ParaDash我们做最初是源于我们自己的需求其实我们主要还是外部coding也太贵了我们是做了一个协作式窥离引擎的然后这个引擎呢就是它会把一个4B size的模型和一个base model连在一起当然就是这种协作式引擎因为它在拼接的对象是上下纹的平级所以说它对base model是没有要求的你base model可以是任何一个base model可以是开源可以是B元因为我也不需要它的梯度但是我们训练的对象就是4B的模型我们选Size有一个原因是它刚好在端侧Map上可以跑起来所以说这就代表了你首先有一个推理成本是0的东西只是它问题就迁移到就是说它的效果不够好了对吧所以说要对它进行训练了然后训练大概就三个阶段了第一个阶段是要去给它做难以问题的分类第二阶段去做轮系统也就是说看到的结果是一个请求打过来小模型会先接接了之后他会去看这个问题到底是不是是不是一个他能解决的问题如果小模型能解他就直接端测就解决掉了如果他解不了他就会路由回这个base model然后第三个阶段就是一个grpo的过程这个grpo过程就是我们开放的奖励结构就是一个正确性和一个成本当然成本奖励是带一个系数的这一段时间就发现一些比较有意思的结果它的Baseline表现会比纯的BaseModel会有一些提升同时因为它做了分类之后它把简单问题自己解决掉了所以说成本一定是降的然后我们有一个数据在Benchmark表现提升大概10%然后用PairDash的架构的话其实当Lamda比较小的时候还可以省掉大概20%的成本当然这个架构我认为它潜力肯定不在于成本因为我们在去推广ParaDash的时候它成本是一个非常好的突破口但是我们现在在构建的就是隐私问题隐私问题其实它就更具有这种弊端属性了它的企业里面的问题它总归还是可以分为公寓跟私欲的公寓跟私欲指的不是弊端跟私欲端指的是这个问题有没有好的base model它现在机械模型不是所有问题都解的非常好的对吧就是公寓呢就是指这个问题机动模型本身的Base Line还不错这种情况下其实可以用我们的ParaDash这种方式去训一个这种Worker Model然后它只是训练对象不一样然后思域问题就简单就是你一个端端端的模型解掉就好了所以你觉得Harness再怎么进化它仍然有它解决不了的地方Harness其实是一个很好的很轻的一个方式就是说我们在思考的一个点就是怎么样能够通过一个不要去投入那么大的这个人力的同时去把那个不可能三角能够好好的解决掉这个其实就是一个后训练方法来去做的事情因为你想在这个成本速度和隐私这个三个维度上都去追求一个最优解的话你终归还是要挖掘一下模型的能力的你纯做harness可能能解决速度的问题但是呢隐私肯定是解决不了的对吧所以harness不能够解决隐私的问题然后咱们可以解决这个 [30:00] 具体的隐私问题是怎么定义这个呀隐私这里其实就是公寓和私欲问题这个肯定是要分开看的对吧就公寓问题就是base model解的很好了然后对于企业来讲呢他现在是有一些问题是不希望打到这个base model上有一些问题是可以的那隐私这个方式呢就是我们在公寓上去做这个work model这个work model你在训练他的时候可以去给他构造不同的奖励项我们现在发那个paradish就是开源那部分呢只提供了两个奖励项一个是正确性奖励一个是成本奖励说的成本和表现这个东西先去cover掉了然后同时还有一个讲理像是可以去购造但是我们现在还没有去发出来的一个工作就是隐私讲理一下他对这种敏感的token需要有一定的这种masking能力你需要去挡一层然后用这个work model去把敏感信息挡掉去做一些处理然后再路由回base model所以当你说到隐私的时候就是说不想把任务丢到公寓去就不想丢给基模去对不是所有的这种信息或者说上下文不是所有的信息都可以被丢给一个基模的但是Harness不也可以很简单路由一下如果本地部署一个开源模型到自己的服务器上我就把有隐私相关的问题也就是路由到自己的本地部署的模型所以它就是一个不可能三角你如果是用这种方式的话你怎么确保模型生成的结果是满足你的要求的你们不也有一样的问题吗所以说要训练这就是我们去搞模型训练的一个最终目标就是模型本身参数是需要去被修改的参数的方法来去搞这个事情的话它天花板其实是存疑的因为到了伸斗命之后有很多问题如果你不通过训练解决的话它是有可能是完全做不到的所以这个可以展开一下吗就是我们在一个需求场景上如果拿到了明确的这种就是它的这个场景里面的这些数据也好或者评价基准也好它其实是可以去翻译成一系列的这些奖励信号的我们可以教会模型怎么样去按照目标来完成这个任务但是模型要学会它它是不可能单单纯的通过Harness来学的对吧Harness它给提供的更多的是一些流程性的东西或者 workflow或者skills或者memory对吧它都是在本质上来讲是在context上在做一些工作但是你如果说不去修改这个模型它是不去训练它它可能模型能够解决的这个问题就相对的说比较有限对而且这个还依赖于你本身部署的这个模型在预训练阶段它的样本分布EDA这个方向的就是在PCB版的电路图设计的一个EDA软件它是一个比较独立的这么一个斗命然后绝大多数的基础模型在预讯的阶段是不可能见过这样的样本的那这样的样本其实你哪怕是你拿一个很大size的一个base model去部署到本地去要他解这个问题再怎么做harness他都很难达到就是一个非常非常理想的一个状态最终还是要对于模型参数本身还是要去做修改的我们去区分公寓和私欲问题的最重要的原因是也不是所有的场景都需要完整的预训练因为他当这个问题已经被Base Model解过了比如说Coding类的问题你想在一个具体场景上再让他解的时候就没有必要再去从头预训练了对吧你去把Worker Model去把你特定的这些要求去训练就好了然后对于像刚才提到的这种很深的Domain他肯定需要一个N2N的Model来去做所以Thinking Machine的Tinker和你们有哪些相同的不同其实是不大一样的因为就是Tinker提供的还是这种Laura API对吧就是我们现阶段其实不太会花太多精力去做Laura这个事因为就是怎么说呢就是Laura的训练它固然是非常有效的但是呢它有一个要求是第一它得跟基础模型要绑定起来你去在某一个基础模型上做的Laura其实在去跨基础模型迁移的时候会有一些这个工作所以你们ParaDash这个工作是解绑的完全解绑可以出现换对因为训练方法来讲Worker Model跟Base Model之间就是Context的这种联系所以说他在训练阶段他就是一个完全独立的在服务一个客户的过程当中其实咱们刚才也提到FDE这个词其实我理解他就是需要人入场FDE只是一个比较好听的说法其实也是我们要自己派人过去沟通去服务去给他梳理他的各种东西你现在是怎么理解这个事情在追求尽可能弱化FDE吗我倒没有说一定要弱化FDE因为我觉得在很长一段时间这个角色都是被需要的我追求的东西是FDE这个角色的宽度对吧其实我觉得现行主流的FDE它的定义宽度是很宽的它得进去去理解需求它得去做相应的这种适配然后去把交付做了然后交付的形态往往也是Base Model加Harness对吧这是一个比较典型的这么一个FDE的行为我定义的FD其实我觉得他只要做前面段就好了就是把需求接回来然后我们把第一个场景的 [35:00] 在这个Ottawa的这种产品上去做一次适配这样的话其实后半段交付的东西它更多的是交付的这么一个能够让把生产数据回流回来的能够不断提升模型表现的这么一个RSI的管道这样的话其实至少在我们时间角度来看FDE的工作量负载会相应的下降很多然后实际上我们现在去服务的也有十几个这样的B端的客户最终大概两个FDE去支撑他们的需求来的对但他比如说回来之后像用的AutoRL的这个部分你们要有其他的同事去承接吗我们需要的就是因为接回来的需求我们在第一次做一个场景的时候本身做奖励结构这块还是需要去做一次适配的那他就是也叫某种意义的FDE呢就是犯化一点来定义的话嗯我觉得不能算因为我们我们自己的角色分配是接回来这部分人他们其实是更加做基础和通用产品的这种角色就通用的这种板块的角色然后他们做的事情是在我们现行的这种奖励结构下去不断的去把其他场景去接入进来然后这个东西是一个他们主要做的跨领域的问题然后对于FDE来讲他就是把一个个需求接回来就好了它其实是一个T字形的结构对听起来咱们在非常的追求我们的这个business是要能够scale起来的一定是这样的不然的话你会变成一个就是这种比如说技术咨询服务这种全方位一体的公司然后不是说这样的公司没有存在的意义主要是说如果是用这种模式的话其实你选取客户的策略就应该选取最最最头部最最大的他一家你这一家客户就能够把你整个生命周期的cover住的对吧但是我的判断是说为什么一开始在讲ASI到来的形态它其实本身就是一个分布式的一个市场所以说这个事儿你不能用中心化的思路去做它对吧如果是前者的话我做成这样子的话那就走Apply Compute的路线了嘛我们就用中心化的方式去做了嘛这只是我们的一个观点就是其实在下半场的光谱里面它其实是非常广播的我觉得是容得下任何一个形态存在的对只是说我们选择的路径呢是更多的用这种奖励结构去把东北太这个场景的问题变得越来越通用因为随着你收的这个呃动态场景越来越多其实它奖励本来是有一定复用性的嘛那有复用性会代表的可以用方法能力去解这个领域的一些新的问题那这样的话其实我认为它是能够跑起来一个飞轮的这是我们内部的一个视角从外部视角来看呢对外的我们更多的定义产品的方式是需要去把我们的角色跟客户的角色以及双方的边界得划定清楚如果你划定不清楚的话你这个biziness就是一个非常模糊的一个东西然后我们划定的界限呢就是为什么要选择这种RL的这种方法啊AutoREL这种方法它的界限就很清晰我跟客户之间传递的无非就是数据集然后回到一个更新的模型这样子其实你数据进来模型还给他我们这个管道是无状态的然后客户那里他看到的是我有我的数据拿到了我一个提升好的模型这个其实结果对大家来说都是可以接受的如果这个模型训得越来越好所以他后面需要的训练越来越少我们是会赚的越多还是赚的越少基本上它是分两层一层就是客户给我数据然后模型还给他这属于是应用模型这种模型如果说客户的场景是静态的其实你可能做一次训练就够了它把问题都集结好就完事了但是绝大多数不是这样的绝大多数比如说我们做工艺的和AVI的那种它上游来的这些需求天天都在变然后你要去做实际训练的一个原因是你需要维持应用模型的能力不要掉点如果你给一个静态的他不能去解决很多的这种变化那他就会出现掉点公益或者AVIAVI就是质检对吧对对对对对他们为什么会天天变呢我理解他们不是一个蛮固定的一个工作吗只是从流水线上理解是的但是实际上它的具体的case是千变万化的一直在变的因为我们想这些客户接到的这些订单对吧他接到的订单需求肯定不是固定的对吧这种一条线上的这种生产也是混杂的了解这种其实它一直在变的它不能做粗分类因为你做粗分类看起来它流水线是固定的你涉及到工艺和质检这种很深层的问题它有一点细微差别对它的结果影响都很大所以说这个场景只要是变化的就需要用这种持续的方式来保证应用模型始终维持在一定水平线之上你们现在去和客户交流的过程中他们应该同时也会看其他的一些可能的能帮他们解决问题的提供商不管是机模或者云厂商你们遇到最多的这种竞标的对手是什么 [40:00] 目前来说我觉得竞争还相对不是特别的多因为我们做的Dominion怎么讲它本身具备一定的壁垒它不是一个非常开放的领域所以我们在这些领域面临的竞争可能是一些传统的这种SaaS服务商它本来就在企业已经深耕很多年了我们进去做的事如果跟他们的业务没有冲突其实大家各自安好如果有一些冲突可能就要谈一些这种合作的模式对对然后纯粹去做这种RSI的这种竞争对手现在是比较少的至少我们在我们选的一个领域是这样的嗯对对当然其他领域就有很多了你指的具体是一些agent这种领域比如说为什么要举水来水的意思因为我觉得它是一个做的蛮成功的一个case他去跟Harvey去合作在法律领域其实就有很多这样的case比如说我们去要去做类似的事情肯定就直面他的竞争了还是前面那个问题我们确定是不是已经回答了SaaS很难咱们也突避为什么咱们就不难当你把B段里面所有的事都做了它就是一个很难的事但是你看我选场景我有三条准则我去三条准则去抽象出来的就是过滤下来之后的这个场景本身就相对来说前面比较整齐然后再一个就是弊端的生意的最本质最本质的核心还是算账对吧你ROI那个是一个很重要的点所以SARS为什么算不清楚那个账你们为什么能算清楚就或者你觉得你有可能可以算的比他们更清楚原因就是还是这里面引入了一个变量就是你看AI时代去做弊端生意变量就是在模型本身上因为现在模型还是很伟大的它还是能解决很多问题的只不过你要正确的去教它然后我们做的事情就是在教模型教会模型去把这个问题解掉而不是说我给它提供一个这种软件式的固定的服务因为这个厚度是完全不一样的同时它又能创造具有RI空间的这么一个case它的成交的模式就会相对来说容易很多对你会怎么去看待云厂商未来潜在的竞争威胁呢因为他们其实好像也能做你们做的事对吧或者说你们今天做的事最后就是在卖给客户的时候还是需要GPU CPU还是需要去找一个云厂商来配合你们部署对那会不会慢慢的云厂商就是吞噬掉我觉得首先一点就是如果说这个领域大家做的多了对我来说是我很开心的一个事情就是本来大家在RSI这个路线上都是会有自己的坚持和自己的探索的云厂商其实它的业务是非常广的它的目标也是非常多的它跟模型议训练回程变成一样的结果当你要做一个平台这个平台目标是超级多的时候你最后落起来的形态就不可能像我们这么的敏捷以及这么的专用了你觉得今天的基模和多摩泰的基模他们够用了吗因为他们再继续进化再有新的SATA对咱们来说还能产生显著性的价值提升吗我觉得现在寄模状态是够用也不够就是够用呢就是大家的宏观认知感性认知嘛都觉得寄模很强然后为什么说它够强又不够强呢就是你一旦到一个生产环境里面去跑的时候你会发现其实还要补足很多工作它不是说这个模型API怼到现场然后它自己就跑起来了它能把这个问题解的很好所以就你们做的工作对我们做的工作就是这里面的很多很多的工作我们也尝试就找到这种相对收敛的一个路径因为其实你解决这个问题就是铺人对吧你啥不好人去补但是这个方向我只是觉得它不太可扩展所以说我们去扩展的方法就是在初期用一定的人工去把奖励网络构建起来其实你在去扩展的时候就相对来说它会是一个更好的形态构建奖励网络你们有一些什么样的方法论或者窍门吗其实它就是在模态上要统一这是最重要的一个点你跨模态之间去构建的话是有难度的是有很大的挑战因为完全不一样然后你去在同一模态下去做总归还是有迁移性的还有一个问题刚刚您提到的就是关于机动模型的演进对吧为什么我们长期来看要助推Pairdash 因为本身我觉得现在所有的这种AI领域的创业团队吧我觉得基本上大家都是站在聚业之间网上去往前搞的Pairdash这个架构本身就是在基模的基础之上去做了一个work model及RSI的这种patch给他用这种方式来去做所以说基模眼镜本身在PARADISE这个架构下本来就是一个很好的事情基模其实越好说实话你对Walkmodel来说它压力不也越小还有一个和基模的竞争是不是也类似基模其实不会形成太多的竞争的你基模它总归解决的问题是有宽度的你基模解的宽度内就followPARADISE这个架构走就好了如果解决基模宽度之外你就做一个单上单模型就好了对 [45:00] 对吧其实是一个他俩这种问题他对这种后训练的依赖是没有变的为啥我们说是面向需求的你从需求侧才能拿到这种有效的场景级的奖励然后拿到场景级奖励你要去训一个work model还是训一个base model这不是由客户来选的吗如果说未来出现一个客户说我就想把公寓问题做一个私有模型来解也可以这是他的选择我们只是从大的范围来看很少有人会选择这么搞我或许未来会有一家公司或者一个地域说我要做主权模型我就把扣你问题要重做一遍可以的我们面向需求需求才是我们的驱动员我们最后聊点轻松的创业到现在最有成就感的一件事情或者一个时刻大概是什么我其实觉得近期我跟我的CTO friend我们去讨论这个就是PyroDash这个架构的时候其实一开始我们的观点也是不一样的然后我觉得最有成感一点就是我们打成共识那一刻吧你说服他还是他说服你啊不存在说服吧就是我们很开放的就是大家其实在论证这个事我们其实内部论证有很多嘛就是有的时候就是直接关小黑屋然后去论证论证这个事情包括巨神领域我们也论证过对吧就这种论证我觉得是非常受益的就是大家大家从不同的视角去看这个事情明白打成共识那一刻感觉很有成就对是的这其实就是为什么我很喜欢去跟大家一起去聊这个事情就是本身大家不同的视角进来自来奖励信号的然后你这种多目标的奖励信号下提炼出来这个结果它有可能就离真相很近了对这个时候觉得比较有成就感的你自己平时会用哪些AI产品最近我觉得就是Coning的多点最近比如说PIPi这种ConingAgent就是一个极简的Agent这就是蛮好的包括DSHDSH还是很屌很屌的对吧这个已经是堪比历史上这个STARS增长社会的项目之一了应该14 5万了吧我们陆波克这个是有拆三天谢谢大家你喜欢用什么模型你现在比如此刻有一些偏好吗我之前反正就在Cloud上面去搞搞然后近期的话就是KimiKimi有了就还是很强的然后前段时间就GM出来说也会去搞然后另外就是现在前文系列前文系列其实从我们从Honeyface上那个数据来看他最近14号不是发了一个报告吗就是前文在实际的运行室里面下载量还是蛮高的也成为了一个用量比较大的一个模型了包括千万3.827B这个小模型我觉得它反向也非常好是的Honeybase那个报告其实还有一个数字挺有意思的他看到这种local类的模型下降量基本是100B以上的下降量是很小的基本100B以下占据了下降量的主流这说明什么问题说明就是说我们去搞PairDash这个架构其实方向上我觉得和社区认知识也是相似的还会去下载这些小的模型去做所以说这就说明了需求世界它是多元的它不是所有需求都要归拢到一个大的base model上来统一的这样去解决掉的依然Hanford上依然有海量的小模型下载量就代表有大量的需求是需要用分布式这形态去解决的所以我们在这个时间点去推PairDash我觉得也是一个非常正确的时间点OK好最后一个问题米歇最期待达成的下一个Milestone是什么我觉得下一个Milestone最重要的就是说PairDash能够获得社区最主流的一个认可就是这个形式因为认可的Milestone衡量基准可以去看看它在生产场景里面是不是真的解决了一些困境的问题不光是benchmark因为这毕竟是我们长期看的方向对因为中期和短期看的方向我们现在已经验证的还比较好了对了ok嗯好呀谢谢凯文好的感谢感谢ok好我们今天先到这里拜拜

Pyromind推大小模型协同架构 押注工业AutoRL替代单一巨模