Why training tool-using AIs is so hard on Google's chips

Google's most expensive AI chips now spend a large share of their training day doing nothing, not because the math is done, but because the model is waiting on a web search, a database query, or a line of code to run. The slowest part of training a tool-using AI is the moment it talks to the outside world, and the chips just sit there. A new open-source library called Tunix is Google's attempt to make them sit there less.

For most of the last decade, training a large language model meant running text in, getting text out, and updating weights. The accelerator, Google's Tensor Processing Unit (TPU) chips, did the heavy compute in a tight loop. That loop is now breaking apart. Frontier labs are training models that pause mid-sentence to call a search engine, query a database, or run a snippet of code, then keep going. Every tool call is a network round trip, and the chip waits for the answer.

The bottleneck has a name in the post on the Google Developers Blog: the rollout phase, the part of training that generates a model's trajectory, or step-by-step path, through a task. In a chatbot, the rollout is one or two model calls. In an agent that calls tools, the rollout can stretch into dozens of sequential steps, each one waiting on something outside the model. Synchronous rollouts, where the trainer waits for every trajectory to finish before the next batch starts, leave chunks of accelerator time empty. The team calls those gaps "execution bubbles," and they say they get worse as the agent spends more time waiting on environment I/O.

Tunix's answer is two engineering moves that decouple the chip from the wait. First, Asynchronous Rollouts let many trajectories run in parallel on host machines, so a slow tool call on one trajectory no longer blocks the others. Second, Barrier-Free Pipelining streams completed trajectories to the trainer as soon as they are ready, instead of batching them into a synchronized wall. Together, the two moves keep the TPU fed with new work even when the environment is the slowest part of the loop.

Tunix also ships with a lightweight instrumentation layer that watches RL-specific metrics, such as rollout length, reward rate, and step time, alongside TPU utilization. The post frames this as a contrast with XProf, which captures detailed operator-level traces but carries enough overhead that it is only used for short, sporadic captures. The Tunix version is built to run continuously and to let an engineer correlate a stalled rollout with the exact TPU timeline underneath it.

What is and is not proven matters here. The throughput wins Google describes come from the company's own benchmarks on its own hardware. There is no independent third-party test in the Tunix documentation or the open-source release, and the wider RL community has not yet published replication results. The novelty of the asynchronous-rollout and barrier-free-pipelining patterns, and how they compare to similar work in other open frameworks, is also not addressed in the post. The library is real, the code is on GitHub, and the problem it names, environment latency as a structural cost, is the same one every lab training tool-using models is now hitting.

A related Google project, GRL, already uses Tunix on TPUs to train agents on verifiable games, a December 2025 open-source release that previews the same decoupling problem. Tunix's broader bet is that the rollout phase, not the next architecture, is where the next round of training-cost wins will come from.