Research on running AI at scale, and on the models we train.

Most public work on large models starts after the hardware exists: a cluster is assumed, a scheduler is assumed, and the question is how to train well on it. We start earlier. We do not own data centers. We buy GPU capacity from several clouds, and we buy model tokens from several providers, and we have to make that mixed supply behave like one dependable system. That is a research problem in its own right, and the field has few open answers to it.

Three questions come up on almost every program. How do you measure useful work when jobs of very different shapes share capacity? What does it really cost to move a run, or its data, from one provider to another? And when a service makes thousands of model calls a day, how do you compare the real cost of finishing a task across providers, once retries, checking steps and caching are counted? Vendor figures rarely answer these, because they describe one machine or one price list, not a task from start to finish.

We think these questions deserve plain, reproducible answers, and that customers and other builders are better served when the methods are public. So we write them down as we go, and we release what the customers and partners involved allow us to release.

Systems. This line covers the control plane and the capacity under it: how a training run is scheduled across clouds, how checkpoints move, where very large datasets should sit so that moving the work is cheaper than moving the data, and how to account for goodput, the share of paid time that produces training progress. The aim is a set of definitions and drills that another team could repeat on its own capacity and get comparable numbers.

Models. Here we study the models we train for biology and robotics, and how they are judged. In biology, the central questions are how many lab cycles a model needs before its proposals beat a strong baseline, and how generated sequences are screened for biosecurity risk before anyone sees them. In robotics, the central question is how to measure the gap between simulation and the real world with a fixed set of held-out tasks, so that one checkpoint can be compared with another without argument.

Services. This line covers the enterprise AI services we offer. We look at how to route work across frontier models, how to compare their cost per finished task, and how to test an assistant well enough to decide whether it should leave a pilot. The emphasis is on evaluation that a business owner can read: a test set written with the customer, a report of failures as well as successes, and costs that include everything that was spent.

Reproducible. Code, configuration and evaluation sets are released with the result, wherever licenses and partners allow, so that a reader can run the same test and compare. Where something cannot be released, we say what is withheld and why.

Negative results included. When a method does not beat its baseline, we say so and show the comparison. A field that publishes only wins learns slowly, and customers deserve to know what did not work as much as what did.

Reviewed for risk. Anything that touches sequence design or physical robots is reviewed for misuse before it is released, and we hold back what a review does not clear. This applies to our own work first.

Partner data stays private. We publish methods and aggregate findings, never a partner’s proprietary data without written consent. Customer and partner names appear only with written permission. See Trust for the commitments behind these rules.