TinyFish 如何在 Databricks AI Runtime 上训练与部署其 web-native 模型
From post-training to production: How TinyFish runs its web-native model on Databricks AI Runtime
TinyFish 将其 web-native 模型的训练、评估与生产部署统一到 Databricks 上,用 AI Runtime 跑 GPU 后训练、MLflow 做评估、Model Serving 做线上服务。
TinyFish 为企业构建基础设施,让智能体能够在实时网络上工作。其 Search、Fetch、Browser 和 Agent API 支持大规模、经过身份验证的 Web 工作流,在这些工作流中,智能体可能需要浏览动态网站、检索信息、与应用程序交互,并跨多个步骤执行任务。
TinyFish 正在为这些智能体任务开发自己的专用 Web 原生模型。随着公司扩展其模型工作,团队还必须构建围绕它的基础设施:用于后训练的 GPU 计算、能够衡量完整智能体行为的评估、生产服务,以及理解系统运行状况所需的数据。
TinyFish 没有在多个独立系统中管理这些部分,而是开始在 Databricks 上构建其模型开发生命周期。 AI Runtime 为训练和微调提供托管 GPU 基础设施,而 MLflow 支持评估,Databricks Model Serving 提供生产服务层。
对我们来说,训练模型只是问题的一部分。我们需要知道某项更改是否真的能让智能体更好地完成真实任务,然后能够迅速将这种改进投入生产。借助 AI Runtime,我们可以在 GPU 上训练、用 MLflow 评估,并服务我们的 Web 原生模型,而无需为每个阶段构建单独的堆栈。——Zach Richardson,TinyFish 人工智能负责人
将智能体行为转化为更好的模型
TinyFish 开始通过监督微调对其 Web 原生模型进行后训练,并正在转向直接偏好优化(DPO)。团队通过 AI Runtime 在 Databricks 托管的 GPU 上运行这些工作负载,使研究人员能够使用 GPU 基础设施,而无需自己运营单独的训练平台。
训练工作与 TinyFish 评估其模型的方式密切相关。由于该模型作为更大的 Web 智能体的一部分运行,评估单个模型响应只能说明部分情况。TinyFish 转而评估完整智能体是否成功完成所请求的任务。
在其内部 go/no-go 基准测试中,TinyFish 的 Web 原生模型成功完成了 2,178 个 Web 智能体任务中的 1,691 个,任务成功率为 77.6%。一个单独的 LLM 评判器会审查原始请求、智能体的操作历史及其最终结果。只有当所请求的操作完成,或返回满足所有要求的正确答案时,任务才算通过;部分完成、错误答案和无效结果都计为失败。
这为 TinyFish 提供了用于模型开发的有用信号。团队可以看到其模型的更改如何影响完整智能体的性能,并利用这些结果指导后续的后训练。
成功的模型迭代随后可以通过 Databricks Model Serving 投入生产。TinyFish 已经在 Databricks 上服务生产模型,包括其搜索重排序器和查询重写器。团队还在该平台上托管并服务其 Web 原生模型。
在最近 15 天内,TinyFish 记录了 294,781 次 agent 运行,涉及其 web-native 模型,覆盖 640 万个工具步骤。该期间的模型服务成本估计为每次运行 $0.088,即每个工具步骤 $0.0040。这些数字仅反映 TinyFish web-native 模型的服务成本,而非完整的 agent 栈,并为团队提供了一种一致的方式,在 Databricks 中结合质量与使用数据来跟踪服务经济性。
这些能力共同为 TinyFish 提供了一条从 agent 行为到后训练、评估和部署的连续路径。评估结果、使用数据和成本报告可以与服务负载一起保留在 Databricks 中,为团队提供一个共同基础,以理解其模型表现并为后续模型开发提供依据。
为 agent 实际执行的工作构建模型
通用基础模型在 TinyFish 的 agent 架构中仍然扮演重要角色,但其 web-native 模型为团队提供了一个可以专门针对 web-agent 任务进行优化的系统。
TinyFish 可以针对其产品实际需要执行的任务来开发和评估模型,而不是在整个 agent 中完全依赖外部基础模型 API。支持这种方法需要的不仅仅是 GPU 容量。开发周期涵盖后训练、评估、生产服务和围绕模型的运营数据。
AI Runtime 为 TinyFish 提供了托管 GPU 基础设施,且位于其用于周边 ML 生命周期的同一 Databricks 环境中。这使团队能够将训练和服务保持在更接近其用于理解模型表现的评估和运营数据的位置,而不是围绕模型构建单独的深度学习栈。
除了自有模型外,TinyFish 正在通过 Unity Gateway 整合对外部基础模型的访问,以实现集中成本跟踪、密钥管理和治理。随着 agent 栈扩展,这为团队提供了一种更一致的方式来管理模型流量。
对于一家成长中的 AI 公司来说,好处很实际:需要运营的独立系统更少,意味着更多工程时间可以专注于让 TinyFish 与众不同的模型和产品行为。
我们在 TinyFish 的优势来自我们能让 agent 变得更好的速度。我们不希望工程师把时间花在管理 GPU 基础设施,或在彼此断开的系统之间移动模型和数据上。Databricks 为我们提供了一个基础,用于构建、改进和运行我们的 web-native 模型,使团队能够专注于产品。—Sudheesh Nair,TinyFish 联合创始人兼 CEO
为下一代模型迭代而构建
TinyFish 持续演进其开发 web-native 模型的方法,从监督微调扩展到 DPO,并随着模型发展探索更大的训练工作负载。
底层工作流的设计目标是在这些技术变化时保持一致。Agent 评估可以显示模型在哪些方面表现良好、哪些方面需要进一步工作。这些信息可以输入后训练,新版本可以针对完整任务进行评估,而准备好投入生产的模型可以从同一环境中提供服务。
通过在 Databricks 上运行该生命周期,TinyFish 可以将 GPU 基础设施视为其 ML 平台的一部分,而不是团队必须组装和维护的独立系统。这为团队提供了一条更直接的路径,从在生产中了解模型到模型的下一轮迭代。
来源:Databricks Blog · databricks.com