瓶颈在谁能用上 GPU，而不只在 GPU 够不够
Lila 的论点是科学数据要靠大规模训练变成模型能力；平台团队回答的是研究员能不能把想法跑起来。认证分好几层、报错不知在哪层、任务排队看着像没跑，都是时间损失，和 Beam 的 scaling 曲线不在同一层，但决定曲线能画多长。
AI FOR SCIENCE · 访谈
Lila 的 AI 平台：把受支持的那条路修得让人不想走别的
核心信号
Lila 的平台团队说，科学家上 GPU 的最大阻力是摩擦而不是算力，所以他们只修一条“受支持的路”：提交、安全、配额、观测都由平台包办，研究员只改自己关心的那部分。
这次新增
七月的访谈和 Beam 在同一大会上的主题演讲都没有的工程细节：一万个小任务压垮集群、改成在 Ray 里展开的做法；一个统一的命令行工具和一份 Hydra 配置；平台团队约 15 人；以及科学家用拖拽界面搭出能自己扩张的智能体实验图。
当前边界
这是平台工程的自述，没有给出训练规模、利用率或迭代时间的数字；“科学家不写代码也能上平台”的例子只有演示截图，没有使用数据。
访谈里说了什么
目标是缩短“想法到算力”的时间
Titsworth 把 Lila 的循环分成内外两层：内循环是设计、构建、测试、学习，外循环是训练模型去优化这个循环的流水线。平台要回答的问题是怎么让科学家和研究员自己搭流水线和服务；他把障碍定为想法迭代的时间。他刚加入时 AI 编码工具还不好用，所以是先靠访谈弄清需求。
三类负载，一个底座
凡是像“作业”的都进工作负载执行，用 Flyte 做跨集群、跨云的编排，Ray 做训练、批量推理和 ETL 的子编排；凡是在服务模型的都进模型服务，用 GitOps 和 Ray LLM serve；凡是智能体的都要在安全沙箱里跑，底下是 Jupyter 内核。三者共用 Kueue 管配额和调度、Kyverno 与 OPA 管策略，每个团队有自己的队列。
一万个小任务压垮了集群
Syen 讲的例子：Flyte 的 map task 以 pod 为并行单位，一万件小活就是一万个 pod，每个都要过全部准入控制器，等于自己攻击自己的集群，还会因为“粒度不匹配”让更大的 GPU 任务排不上。办法是把展开放进 Ray，Kubernetes 只看到节点数；他们在上面做了一层和 Ray Data 类似的批处理，并把每件活做成 Ray actor。同一个办法也解了 SFT 和 RL 的问题。
一个命令行和一份配置
研究员原来要过 AWS、VPN、Kubernetes 上下文、Flyte 凭证好几层认证，出错也看不出在哪一层，任务排队时看着像没跑。他们做了内部命令行 Chariot：登录、提交、查看、跳到日志和 Ray 仪表盘都从这里走。训练配置分成三类（超参数、算力、运行类型），统一用 Hydra，由集群里的 Flyte-Hydra 启动器把它变成作业、工作区或端到端测试。
不是平台团队做的，也跑在平台上
应用团队用平台的执行系统给科学家做了图形界面，让没写过代码的人把假设、实验、测试、结论串成图；在 Ray 集群里它不是固定的有向图，智能体需要继续试就自己加节点，直到超时。生命科学团队有一条蛋白优化流水线：取已有蛋白、反向折叠回设计、用深度学习探索设计空间、再检查折叠和结合，给出排序的候选送去湿实验；每一步是各自的 Ray 集群，能处理数千条序列、折叠数百个结构，没有结果就提前结束。
改变了什么
- 此前的公开记录→
本站七月的 Lila 访谈页把强化学习的 MFU 只有约 5–6% 记为没解决的问题，没有描述训练跑在什么软件上。
这次访谈新增平台团队描述了这一层：Flyte 加 Ray 做编排，Kueue 和 Kyverno 管配额与策略，每个团队有自己的 Ray 集群；但没有给出利用率或训练规模的数字，所以 5–6% 的问题仍没有数字回应。
- 此前的公开记录→
七月访谈页记录了“人留在 API 线之下、仪器接入约 30 天”：模型面对的是一个统一的 API。
这次访谈新增这场分享讲的是 API 线之上谁能用：用图形界面搭实验图的科学家、做蛋白流水线的生命科学团队，都在同一个执行系统上；使用人数、流水线数量没有说。
- 此前的公开记录→
本站记录里没有 Lila 的平台团队规模，也没有它用了几个云或区域。
这次访谈新增团队约 15 人，按小项目动态分组；已在多个区域和云上用 Flyte 跨集群运行，目标是跨区域的 GPU 集群联合跑。
为什么重要
一家实验室公司自己写了多少软件
从命令行、配置启动器到沙箱和图形界面，这些都是 Lila 自己维护的，团队约 15 人。这说明它的“实验室”不只是仪器和机器人，也是一套内部软件；要和 Radical 或 Periodic 比较，要把这部分也算进去。
主张与边界
主张谁的口径目前状态
平台由 Flyte（跨集群、跨云）加 Ray（训练、批量推理、ETL 的子编排）、Ray LLM serve、Kueue、Kyverno、OPA 和 Argo CD 组成，每个团队有自己的队列和 Ray 集群。
当前系统
嘉宾的描述；没有外部材料可对。
map task 一万件小活变成一万个 pod 会压垮集群；改在 Ray 里展开后，这类批量任务以及 SFT 和 RL 都能继续放大。
当前系统
没有给出规模、延迟或集群利用率的数字。
内部命令行 Chariot 是登录、提交、查看和看日志的唯一入口；训练配置统一用 Hydra，由 Flyte-Hydra 启动器转成作业、工作区或端到端测试。
当前系统
现场问答里说明配置校验靠 Chariot 加 Hydra 的校验器，以后会合并，目前并不统一。
科学家用图形界面把假设、实验、测试、结论串成图，在 Ray 集群里图会自己加节点，直到超时。
当前自动化
只有界面截图和口头描述；没有说有多少人在用、跑过多少个图。
蛋白流水线能处理数千条序列、折叠数百个结构，层层过滤、无结果就提前结束，最后给出可送湿实验的排序设计。
当前系统
没有说有多少设计被送去湿实验，也没有命中率。
AI 平台团队约 15 人，按小项目动态分组；Ray 数据还没用上，数据血缘靠 OpenLineage 包进 Weights & Biases，两者配合得并不好。
公司自述
嘉宾在现场问答里说的，没有外部材料可对。
以后希望相似的领域直接套进已有的流水线，平台能自己优化；也想跨区域的 GPU 集群联合跑一个任务。
目标
都是愿景，没有时间表。
把平台修成“研究员只改自己关心的那部分”的一条路，比让每个人各走各的更有效。
受访者判断
嘉宾的设计看法；没有采用前后的对比数字。
接下来看什么
平台有没有让从想法到算力的时间真的变短。
会表现为 Lila 按同一口径公布的前后数字：提交到开跑的时间、每个研究员每周的运行次数。蛋白流水线排出的设计在湿实验里的命中率。
会表现为 Lila 或合作方公布的设计数量、实验方法和命中率。训练的利用率，也就是七月访谈里没解决的 5–6%。
会表现为 Lila 公布的利用率数字和训练规模，写明口径。
读于 2026.10.03 整场分享和现场问答的完整文字稿，通读。这是 Anyscale 自己的 Ray Summit（2026 年 8 月 24–26 日）上的一场；Beam 在同一大会的主题演讲里感谢 Anyscale 在扩大 Lila 训练算力上的合作，所以这是公司在合作方的大会上讲自己的内部平台；幻灯片和截图只读到嘉宾口头讲的部分。 打开原访谈 ↗