我观看了Ray Summit上的许多现场演讲，Priunsh Syen和Tyler Titsworth在@LilaSciences的这个关于…的演讲

我观看了 Ray Summit 上的一系列直播演讲，其中 Priunsh Syen 和 Tyler Titsworth 在 @LilaSciences 关于其 AI 研究平台细节的分享令人印象极为深刻。

https://t.co/VVfZpUQUbp

概要： Lila Sciences 构建了一个内部自助式 AI 研究平台，以支持其用于科学发现的“构建-测试-学习”循环，结合使用 Flight、Ray 和 GitOps 来处理多样化的工作负载，同时减少摩擦并维护研究人员的安全性。

引言：科学超智能平台的目标

Lila Sciences 正在打造自动化实验室以处理大规模实验。其核心理念是“构建-测试-学习”循环，他们计划利用大语言模型来优化这个循环。他们将此描述为内循环（设计-构建-测试-学习）和外循环（训练模型以优化流程本身），相信这条路径将通向能够解决人类最大挑战的科学超智能。

这需要大量的深度学习资源（主要是 GPU 算力）和一个管理平台。其平台团队的核心问题是：如何构建一个自助式研究平台？ 该平台必须支持这两个循环，赋能科学家使用 AI 模型，并允许他们反过来为平台做出贡献。

最终目标是减少计算执行时间并优化构思时间，使研究人员能够专注于科学。这必须在云原生环境中实现，采用容器化和其他运维模式，让并非生产代码专家的科学家也能扩展其能力。

从初始状态到未来愿景

在起步阶段，平台专注于特定的初始方向。然而，其长期愿景更为广阔，需要支持：

• 多集群、多云和多区域部署。
• 超越仅限于大语言模型的监督微调，包括强化学习。
• 扩展到蛋白质生成之外的领域，包括物理模拟、训练领域特定模型，以及开发评估套件和基准测试。
• 管理跨区域的 GPU 集群。
• 标准化所有这些工作流程，以减少提交和运行任务的维护负担。

平台架构与核心原则

初始架构解决了一个基本问题：不同的团队在使用不同的 AWS 服务、供应商（如 Weights & Biases）以及基于 Kubernetes 的新型云。该平台需要整合这些，并在所有这些之上提供一个统一的执行层。

平台的中间层——GPU 平面和控制平面——建立在不可妥协的原则之上：

• 公平的 GPU 调度、可观测性和编排： 对于允许多个用户并发训练模型至关重要。
• 多租户和策略执行： 对于安全团队隔离模型服务并执行策略是必要的。 这些原则在做出任何具体的软件决策之前，就定义了平台的需求。

垂直领域与软件决策

团队根据工作负载的性质，将平台划分为三个核心垂直领域：

1. 工作负载执行： 处理任何任务型的工作。
2. 模型服务： 处理非确定性服务，通常是模型推理。
3. 代理： 需要一个安全的沙盒环境。

软件栈：Flight、Ray 和 GitOps

• Flight (v1)： 提供基础。它与 Ray 结合，在多集群、多云环境中进行 DAG 调度。Ray 作为可扩展的子编排器，用于训练工作负载、批量推理和 ETL 管道。
• 模型服务： 使用基于 GitOps 的流水线，结合 Argo CD（权限受限）和 Ray LLM Serve，后者非常适合沙盒环境。
• 代理沙盒： 利用 Jupyter 内核、Python 内核和一个基础 shell。
• 基础组件： 这些垂直领域由 OPA (Open Policy Agent) 和 Kyverno 支持，用于策略执行，并与身份提供商结合以管理组织级别的权限。

核心决策是为每个垂直领域定义清晰的“黄金路径”。例如，模型服务现在通过向 GitHub 提交 PR 来提交 YAML 文件定义，而工作负载执行则有统一的提交 API。

使用 Flight 减少摩擦

Flight 是减少研究人员初始摩擦的关键：

• 自动容器化： Flight 自动生成 Dockerfile、构建/推送命令、Kubernetes 清单并处理部署，所有这些都通过一个 Pythonic 接口完成。研究人员只需指定依赖项和基础镜像。
• 单命令执行： 可以通过单个命令启动整个流程：pyflight run。
• 基于云的容器构建： 为了避免缓慢的本地上传，所有任务构建都使用 Moby 项目的 BuildX 插件 转发到 EKS 集群内强大的远程构建器。
• 声明式资产： 对于模型服务，平台使用像 Argo CD 和 Crossplane 这样的声明式工具，允许在 YAML 中定义整个基础设施和部署流水线。这包括部署 Ray 服务以及所有必要的组件（如入口配置），以便从 Notebook 访问模型。

让研究人员加入：“黄金路径”

一旦部署完成，挑战就在于让研究人员有效使用平台。该过程被抽象为四个阶段：构思、开发、安全边界和自助服务（计算）。一个关键关注点是安全边界，确保进入集群的计算对 Lila 及其客户都是安全的。

平台团队的目标是让标准的“绿色路径”如此无摩擦且有益（提供安全性、GPU 配额、可观测性、可重复性），使其成为显而易见的选择，从而不鼓励“紫色”（定制）或“红色”（离线）路径。

问题与解决方案：扩展 Map 任务

早期的一个挑战涉及具有数万个依赖 GPU 的小型工作项的“Map”任务。

• 初始问题： 直接使用 Flight，每个项都会成为一个 Pod。调度 10,000 个 Pod 在集群的控制平面上造成了自找的 DDoS 攻击，并导致调度失败，因为调度器无法找到尺寸匹配的资源空洞。
• 解决方案： 工作流程被重新设计以使用 Ray。扇出操作发生在 Ray 集群内部。Kubernetes 控制器只看到几个 Ray 节点，而不是数千个 Pod。工作被建模为预热的、类似 Ray Data 抽象内的 Ray Actor，允许在集群内进行高效的分布式处理。这种模式也解决了 SFT 和 RL 作业的类似扩展问题。

问题与解决方案：简化访问与调试

研究人员仅仅运行一个任务就面临巨大摩擦：

• 复杂的认证： 一个长长的凭证清单（AWS 配置、VPN、Kubernetes 上下文、Flight 令牌），缺少一步就会破坏整个链条。
• 不透明的流水线： 由于有许多架构层（AWS、K8s、ECR、Flight），诊断故障很困难。错误可能源自一个层，却在另一个层显现。
• 缺乏统一状态： 很难判断任务是在排队、运行还是失败，尤其是对于等待 GPU 的资源密集型作业。虽然数据存在于 Grafana/Prometheus 中，但并未为研究人员整合。

解决方案：Chariot

为了解决这个问题，团队构建了 Chariot，一个内部命令行工具，作为所有平台工具的一站式商店，简化了身份验证、任务提交和状态检查。

结论

Lila Sciences 通过首先定义清晰的核心原则（公平调度、安全性、可观测性），然后选择并集成工具（Flight、Ray、Argo CD、OPA/Kyverno）到逻辑垂直领域中，构建了他们的 AI 研究平台。他们专注于通过自动容器化、云构建和简化的 CLI（Chariot）来减少研究人员的摩擦，同时通过利用 Ray 处理分布式工作负载来解决关键的扩展问题。该平台是一个持续进行中的工作，不断发展以支持公司打造科学超智能的宏伟目标。

来源：https://www.youtube.com/watch?v=eHb9Z6AxdMk&list=PLZNaJyYZRPdo&index=4