AI FOR SCIENCE · INTERVIEWS
Lila's platform team says what slows scientists down on GPUs is friction, not compute, so they maintain one supported path: submission, security, quotas and observability are done by the platform and researchers edit only the part they care about.
Engineering detail that neither the July interview nor Beam's keynote at the same summit carries: ten thousand small tasks overloading the cluster and the fix of fanning out inside Ray; one command-line tool and one Hydra config; a platform team of about 15; and scientists building self-expanding agent experiment graphs in a drag-and-drop interface.
It is platform engineering described by the engineers themselves, with no figure for training scale, utilisation or iteration time; the example of scientists using the platform without writing code is a demo screenshot with no usage data.
Titsworth splits Lila's loop in two: the inner loop is design, build, test, learn, and the outer loop is the pipeline that trains a model to optimise it. The question the platform answers is how scientists and researchers can build pipelines and services themselves; he names the barrier as the time it takes ideas to iterate. When he joined, AI coding tools were not yet good, so the needs came from interviews.
Anything job-shaped goes to workload execution, with Flyte orchestrating across clusters and clouds and Ray as sub-orchestrator for training, batch inference and ETL; anything serving a model goes to model serving, with GitOps and Ray LLM serve; anything agentic runs in a safe sandbox on Jupyter kernels. All three share Kueue for quotas and scheduling and Kyverno with OPA for policy, with one queue per team.
Syen's example: Flyte's map task uses a pod as its unit of parallelism, so ten thousand small items are ten thousand pods, each through every admission controller, which amounts to attacking your own cluster, and a granularity mismatch can leave a larger GPU task unschedulable. The fix is to fan out inside Ray so Kubernetes sees only the node count; on top they built a batch layer like Ray Data and model each item as a Ray actor. The same move solved their SFT and RL problems.
Researchers used to authenticate through AWS, a VPN, a Kubernetes context and Flyte credentials, could not tell which layer failed, and a queued job looked like one that had not run. They built an internal CLI, Chariot, for logging in, submitting, checking and jumping to logs and the Ray dashboard. Training configuration splits in three (hyperparameters, compute, run type) and is unified in Hydra, with a Flyte-Hydra launcher in the cluster turning it into a job, a workspace or an end-to-end test.
The app team used the platform's execution system to build a graphical interface that lets people who have never written code string hypothesis, experiment, test and conclusion into a graph; inside a Ray cluster it is not a fixed graph, since the agent adds nodes when it needs to keep testing, until a timeout. The life-sciences team runs a protein-optimisation pipeline: take an existing protein, reverse-fold it into a design, explore the design space with deep learning, check folding and binding, and give ranked candidates to send to a wet lab; each step is its own Ray cluster, handling thousands of sequences and folding hundreds of structures, and ending early if nothing is found.
This site's July Lila interview page records reinforcement-learning MFU of only about 5 to 6% as unsolved and does not describe the software the training runs on.
The platform team describes that layer: Flyte and Ray for orchestration, Kueue and Kyverno for quotas and policy, one Ray cluster per team; but it gives no utilisation or training-scale figure, so the 5 to 6% still has no number answering it.
The July interview page records people staying below the API line and about 30 days to onboard an instrument: the model faces a single API.
This talk covers who can use what sits above that line: scientists building experiment graphs in a drag-and-drop tool and the life-sciences team's protein pipeline run on the same execution system; how many people use it and how many pipelines exist is not said.
This site's record holds nothing on the size of Lila's platform team or how many clouds or regions it uses.
The team is about 15 people in small project groups that rotate; it already runs across several regions and clouds through Flyte, with running one job across GPU clusters in different regions as an aim.
Lila's thesis turns scientific data into model ability through large-scale training; the platform team answers whether a researcher can get an idea running. Layered authentication, errors that do not say which layer failed and queued jobs that look dead all cost time; they sit below Beam's scaling curve but decide how long it can be drawn.
From the command-line tool and the config launcher to the sandboxes and the graphical interface, Lila maintains all of it, with a team of about 15. It means the lab is not only instruments and robots but also internal software, and a comparison with Radical or Periodic should count that.
The platform is Flyte (across clusters and clouds) with Ray (sub-orchestration for training, batch inference and ETL), Ray LLM serve, Kueue, Kyverno, OPA and Argo CD, with one queue and one Ray cluster per team.
Current system
The speakers' description; no outside material to check it against.
A map task of ten thousand small items becomes ten thousand pods and overloads the cluster; fanning out inside Ray let batch work, SFT and RL keep scaling.
Current system
No figure for scale, latency or cluster utilisation is given.
The internal CLI Chariot is the one doorway to log in, submit, check and read logs; training configuration is unified in Hydra, turned by a Flyte-Hydra launcher into a job, workspace or end-to-end test.
Current system
In the Q&A, configuration is validated by a mix of Chariot checks and Hydra verifiers, to be consolidated later, so it is not yet unified.
Scientists chain hypothesis, experiment, test and conclusion in a graphical interface and, inside a Ray cluster, the graph adds nodes by itself until a timeout.
Current automation
A screenshot and an oral description only; how many people use it and how many graphs have run is not said.
The protein pipeline handles thousands of sequences and folds hundreds of structures, filtering at each step and ending early if nothing is found, and gives ranked designs to send to a wet lab.
Current system
How many designs went to a wet lab and the hit rate are not said.
The AI platform team is about 15 people in rotating project groups; Ray Data is not used yet, and data lineage wraps OpenLineage into Weights & Biases, which do not fit perfectly.
Company-reported
Said by the speakers in the Q&A, with no outside material to check it against.
The hope that similar domains will slot into existing pipelines and the platform will optimise itself, and an aim to run one job across GPU clusters in different regions.
Target
Aspirations with no timetable.
A single supported path in which researchers edit only the part they care about works better than letting everyone take their own.
Guest's judgment
The speakers' design view, with no before-and-after numbers.
Whether the platform really shortened the time from idea to compute.
Would show up as Before-and-after figures on one basis from Lila: time from submission to start and runs per researcher per week.The wet-lab hit rate of designs the protein pipeline ranks.
Would show up as Design counts, assay method and hit rate published by Lila or a partner.Training utilisation, the 5 to 6% left open in the July interview.
Would show up as A utilisation figure and training scale from Lila, with its basis stated.Read 2026.10.03 The full transcript of the talk and the live Q&A, read in full. It is a session at Anyscale's own Ray Summit (24 to 26 August 2026), and in his keynote at the same summit Beam thanks Anyscale for a partnership on scaling Lila's training compute, so this is the company describing its own internal platform at a partner's event; for slides and screenshots, only what the speakers said aloud was read. Open the interview ↗
