The example that justifies this entire session is a farming application in rural Maharashtra, translating English agricultural insights and weather warnings into Marathi — and specifically into the Varhadi dialect, with local farming vocabulary and regional slang, running offline because rural connectivity cannot be assumed (12:43).
That example is doing more work than it appears to. It is not a latency argument.
On-device as reach, not speed
The usual case for local inference is response time, privacy, or cost. This example makes a different one: the user is unreachable by a hosted model, twice over.
Connectivity fails first — no network means no service, regardless of how good the hosted model is. And coverage fails second, because a regional dialect with agricultural vocabulary is precisely the kind of language a general-purpose system handles adequately and not well, and adequately is not sufficient when the content is a weather warning.
Local inference plus fine-tuning addresses both. The interesting part is that neither problem is solved by a better hosted model. A more capable system in a data centre does not reach a farm without a network, and its dialect performance improves only if someone decides that dialect is worth the training investment. Putting the tuning in the developer's hands moves that decision to whoever cares about those users.
The number that makes multilingual feasible
The most concrete engineering claim concerns speech. A conventional approach requires downloading a separate model of roughly 100 to 200 megabytes for each language the user needs, while the on-device approach needs one small adapter to cover all supported languages (6:24).
That difference decides what is shippable. Three languages at the conventional size is an install cost most applications will not accept, which is why multilingual on-device speech has largely not existed outside applications where it is the entire product. A shared base with per-language adapters turns a linear cost into a nearly fixed one.
It also changes the default. When each language carries a large fixed cost, developers ship the languages with the most users and the rest get nothing. When the marginal cost collapses, including a language stops being a business case and becomes a checkbox — which is how coverage actually broadens.
The advice buried in the middle
The guidance for anyone building this is deliberately unfashionable: always use the smallest model that reliably solves your use case (12:15).
Two words carry it. Smallest, because on a phone every megabyte competes with the application itself and every parameter costs battery. And reliably, which is the constraint that stops smallest from being a race to the bottom — the smallest model that works, not the smallest model that sometimes works.
This is the opposite instinct to server-side development, where the sensible default is to use the most capable model available and optimise later if cost becomes a problem. On a device there is no later. The size is fixed at ship time and the failure mode is a user uninstalling the application.
The productionisation details that matter
Two additions are more consequential than they sound.
Prefix caching stores and reuses intermediate state so that repeated inference does not recompute shared context (8:00). On constrained hardware this is not a minor optimisation — it is the difference between an interaction that feels immediate and one that does not, in a setting where there is no larger machine to fall back on.
Structured output lets an application define the object classes it expects back, rather than writing a long English prompt describing which fields to extract (9:35). That converts a probabilistic text-parsing problem into a typed interface, which is the single change most likely to make one of these features survive contact with production code.
The prompt-optimisation tooling is the interesting inversion: server-side models propose improved prompts, measured against a developer's own evaluation set, to find the best prompt for a local model (11:12). The large model is not serving users. It is tuning the small one that will.
What is being asked of developers
The platform argument is that a system service handles hardware-specific optimisation, model updates and request isolation on the developer's behalf (3:13).
That is a genuine convenience and a real dependency. Model deployment becoming someone else's problem also means model behaviour becoming someone else's decision, on a schedule the application does not control. For the fine-tuned dialect case that opened the session, this is exactly why the custom path exists alongside the managed one — and choosing between them is the actual architectural decision this session is asking developers to make.
关键数据
- 100-200 MB per language
- conventional on-device speech model size, versus one small adapter covering all supported languages 6:24
演讲章节
关键要点
- 01
The anchoring example is offline dialect translation for rural farmers, where a hosted model fails on connectivity and on language coverage simultaneously. 12:43
- 02
Conventional on-device speech needs 100 to 200 megabytes per language while the newer approach needs one small adapter for all of them. 6:24
- 03
The guidance is to use the smallest model that reliably solves the use case, because on a device there is no optimising later. 12:15
- 04
Structured output lets an application declare the object classes it expects instead of describing extraction rules in a long prompt. 9:35
- 05
Server-side models are used to optimise prompts for the local model against the developer's own evaluation set. 11:12
提及的实体
相关演讲

Four of Google's model, product and search leads on what changes once agents run for hours rather than seconds, and the most quotable argument comes from Dean: the constraint is moving out of the model and into the tools around it. By Amdahl's law, an agent spending half its time in tools built for human-speed interaction cannot gain more than a doubling however fast the model becomes — which reframes a great deal of current infrastructure work as latency debt. Their internal response is concrete: rewriting Python tooling into Go, framed as a fully specified translation task rather than an open prompt, produced order-of-magnitude speedups overnight. Reid supplies the counterweight from Search, where acceptable latency turns out to scale with how much work is being taken off the user rather than being a fixed budget. Woodward's detail is the quietest and perhaps the most telling: teams that have stopped writing product documents for humans and now write context files for models to act on directly.

The clearest statement at I/O of how an agent API differs from a chat API, and the reasoning behind each departure is stated rather than assumed. Three changes matter. Conversation state moves to the server: a call returns an identifier, and passing it back continues the thread, retiring the client-side history array. The data model abandons alternating user and model turns for discrete steps, on the argument that a trace containing reasoning, tool calls, environment responses and compaction was never really a conversation and modelling it as one distorted it. And agents receive their own persistent remote environment rather than acting on the caller's machine — addressable by identifier, and shareable, so a research agent's output files become an application builder's input without passing through the context window. Schmid is explicit that scaffolded environment files are deliberately not model input, which is what keeps large artefacts out of the context budget. Schaeff's first half covers the real-time voice path, where the notable property is speech-to-speech across ninety languages with transcription of both directions.

The anecdote that opens the panel does the work: a robot asked to pick up the extinct animal selected a dinosaur toy, with nothing in its training data connecting the phrase to the object. That transfer from language models into machines with hands is the premise of the current wave. What the practitioners then describe is where it stops. Physical intelligence is about exerting force and using a body to do it, which is knowledge about consequences — the one thing a corpus of internet images contains almost nothing about. The humanoid question gets an honest treatment: not that human shape is optimal, but that the world is already built for it, plus a development-loop argument about collecting data and deploying on the same hardware. The most useful passage is scepticism about the field's favourite shortcut: generated video looks realistic and does not hold up for dexterous manipulation, because looking right and being physically consistent are different properties.

The observation that organises this session is not about capability but about attention. Engineers increasingly file a ticket rather than opening an editor, and the code comes back — which changes what the surrounding tools are for. If the agent works while you do something else, the conversation between you is no longer a workspace; it is the mechanism by which the agent surfaces a question it cannot resolve alone. Interfaces built for continuous conversation optimise for flow, and interfaces built for interruption should optimise for the opposite. A runtime constraint follows immediately: an agent that starts a long-running job cannot block until it finishes, which turns out to be a workflow-engine problem rather than a model one. The panel's closing formulation — that deciding what to build is the hard skill and always was — reads as reassurance and functions as a warning, since that judgement is downstream of exactly the work now being delegated.

The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.

Pichai's framing of Google as the buffer between people and the raw internet is offered as continuity — search did it, browsers did it, agents do it more — and it is also the most contested claim in the industry, because a buffer decides what passes through. He reaches immediately for the counterweight, the connection people feel to creators they follow, which is precisely the tension the company is currently managing without resolving. Two answers are sharper than the format usually produces. On competition he describes participants running on different pre-training and release cadences rather than at different speeds in one race, which is a more honest account than the leaderboard framing and comes from someone with an interest in leaderboards. On security he acknowledges models improving at cyber work, which is the one domain where better capability does not obviously net out positive, since an attacker needs one vulnerability and a defender needs all of them.
