AI Engineer World's Fair 2026
Why Large? Tiny LMs & Agents on Edge/Robotics
Read the talk
Tiny models for devices that cannot afford a large one
Local intelligence depends on more than fitting weights in memory: the task, runtime, hardware and training data determine whether a small device can respond usefully.
From a talk by Cormac Brick
Before you start: Basic familiarity with language models, inference and fine-tuning will help; no robotics background is required.
Intelligence beyond expensive robots
How do you put intelligence into ordinary, inexpensive devices—not just expensive robots? A model that works on a powerful development machine may still be too large to bundle with a mobile app, distribute through a browser or run alongside the rest of a device’s software. The starting question is therefore how little model a useful feature needs.
Cormac Brick introduces himself as a tech lead on Google’s AI Edge team, which builds deployment tools including LiteRT-LM, LiteRT and MediaPipe. The team also supplies technology to Google products and works with the Gemma team on compatibility and performance across devices. The software stack connects applications to execution on CPUs, GPUs and NPUs.
Mobile and browser distribution make model footprint a product constraint. The team’s usual path is to develop a capability for an internal application, then release the tools through open source where feasible. That experience provides two distinct deployment paths: use a small general-purpose model directly, or specialize a much smaller model for a bounded task.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Local inference trades cloud costs for a memory budget
Running inference locally offers several benefits that matter independently:
- Latency: responses can be fast and consistent without a network round trip.
- Privacy: input data stays on the device.
- Offline availability: a feature continues working without reception.
- Operating cost: repeated interactions do not each require a paid cloud inference call.
The last benefit becomes substantial at mobile-app or browser scale. Even inexpensive tokens add up when multiplied by a large population and frequent interactions.
The corresponding constraint is hardware cost, especially DRAM. Brick reports phone manufacturers reducing installed memory and cites a roughly 2.5× Raspberry Pi price increase since launch, though the precise board comparison is unclear. The engineering consequence is straightforward: quantization and task-appropriate model sizing affect the device’s bill of materials, not just an inference benchmark.
Deployment also has to accommodate a heterogeneous collection of devices. Meanwhile, much of the research effort goes toward larger language models and mixture-of-experts architectures, leaving the lowest end of the model-size range less studied. Finding the smallest model that satisfies a task is therefore a development problem in its own right.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Small models are often ready to prompt
Here, a small model means roughly 1–4 billion parameters, with 1–2 billion a common starting range. Models in this tier can arrive through the operating system—Android AICore on high-end phones or Apple Intelligence—or be bundled by an application vendor.
For IoT and robotics, Brick gives a device-memory rule of thumb of 4–8 GB DRAM for this model tier. That pushes deployment toward laptops, phones and higher-end electronics, while excluding many lower-cost devices and browser environments.
The attraction is a comparatively simple development workflow. Quantize to reduce footprint, then try zero-shot prompting for the feature. LoRA adapters offer another route to adaptation, and models in this range can already be reasonably capable at function calling and agent skills. If the hardware budget fits, a custom training pipeline may be unnecessary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Compressed weights are only part of the footprint
The concrete example is Gemma 4 E2B. Brick describes its reasoning as comparable to a much larger Gemma 3 model from roughly a year earlier, with useful answers obtainable through zero-shot prompting. That capability comes with substantial work to reduce the memory occupied by the model.
The E2B example mixes 2-bit, 4-bit and 8-bit quantization, which Brick reports as about 2.9 bits per resident weight. Per-layer embeddings provide another optimization. The slide distinguishes the model’s file size from its multimodal and text-only in-memory footprints; Brick gives 841 MB for the text-only weights. Those are different accounting boundaries, so a download size and a resident-weight size should not be treated as interchangeable.
Weights are only the first part of the working memory budget. Brick estimates roughly 2 GB of active RAM after adding the runtime and KV cache, then at least 4 GB of device RAM once the operating system and other workloads are included. A model can fit its weights comfortably and still leave too little memory for a healthy application.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The same model produces different interaction budgets
The next question is how quickly that model runs. Brick reports the following throughput for the roughly 2-billion-parameter example using the team’s runtime and toolchain:
| Hardware | Prefill | Decode |
|---|---|---|
| Raspberry Pi, without MTP | — | About 7.6 tokens/s |
| Jetson Orin Nano | — | About 24 tokens/s |
| Qualcomm IoT board, NPU | Almost 4,000 tokens/s | About 31 tokens/s |
On Raspberry Pi, Brick says enabling multi-token prediction, or MTP, may roughly double speed depending on the task. He also notes that NVIDIA’s own toolchain may run faster than the team’s Jetson implementation. The Qualcomm board is not identified in the spoken explanation.
Prefill processes the input; decode produces the response. That distinction matters for visual interaction. Brick gives Gemma 4 image budgets of about 500 tokens for a medium-resolution image and 1,120 for a high-resolution image. From the Qualcomm prefill capacity, he estimates roughly three high-resolution frames per second while retaining useful decoding speed. This is a capacity estimate from image-token processing, rather than a measured end-to-end camera application rate.
These speeds make small models attractive for near-real-time applications when the product can afford the processor and DRAM. The runtime also supports similarly sized community models, giving developers alternatives with different strengths within the same hardware tier.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Test the interaction, not just whether the model runs
AI Edge Gallery provides a direct way to try small models on iOS and Android and see their speed on a phone. The application is fully open source, so the same experiment also exposes how an app integrates the open-source runtime. It is both a test surface and an implementation to inspect.
The robotics example is Open Duck Mini v2, an open-source hobby project Brick attributes to DeepMind engineer Xavier. He recommends its video without playing it during the talk. He describes two robots, one using a Jetson Nano and the other a Raspberry Pi, that accept voice and image input, read signs, react and nod their heads.
Brick describes good real-time interaction on the Jetson version, while the Raspberry Pi version works but responds much more slowly. That difference exposes a product-level requirement: successfully completing inference does not mean the robot responds quickly enough for the intended interaction.
If a ready-to-prompt small model meets the product’s hardware and interaction constraints, there is no need to go smaller. But older laptops and lower-cost consumer devices may remain out of reach. Sometimes the AI feature is only a small part of an application and must run while everything else continues working. In that setting, lower memory use and faster responses protect overall system health.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tiny models narrow the task to widen device reach
Tiny models occupy roughly the 50–500-million-parameter range in this discussion. Brick reports deploying models as small as 50 million parameters. These models are easier to bundle natively with an application and can target devices with less than 2 GB RAM, potentially considerably less. They can also run very quickly, but development becomes more specialized: find an off-the-shelf model that already performs the task, or fine-tune one for the required outcome.
Several fixed-task capabilities are already useful starting points:
- Speech recognition: an ASR model converts audio into text.
- Vision: a compact visual model supplies basic awareness of a scene.
- Embeddings: a text embedding model supports processing and matching text.
For vision, Brick demonstrates Apple FastVLM, a 0.5-billion-parameter model, running on Android with hardware acceleration. The example shows a way to add visual awareness without starting from a larger general-purpose model. ASR and embedding models offer similarly focused building blocks.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From a spoken request to a device function
For custom tasks, the starting points include Gemma 3 at 270 million parameters and FunctionGemma, which receives additional pretraining for function-calling patterns. Brick reports about 45 decode tokens/s on Raspberry Pi for this tiny-model example, attributing the improvement to reading less memory at each decoding step.
The specialized Mobile Actions model takes text in and produces function calls. Brick reports above 86% reliability for a model covering about ten output functions, including calendar scheduling and Wi-Fi toggling. The published FunctionGemma model card separately reports 85% after specialization, versus 58% before, for identifying and formatting Mobile Actions system calls; it does not establish that its evaluation is identical to the talk’s result. Neither figure should be read as end-to-end speech-command reliability.
The useful interface boundary is a structured request that application code can interpret. For a Wi-Fi request, that boundary can be illustrated with this JSON contract:
json
{
"input": "Turn off Wi-Fi",
"proposed_call": {
"name": "set_wifi_enabled",
"arguments": {
"enabled": false
}
}
}
The function name here defines an application interface; producing the call does not itself change the device setting. In the demo, a separate ASR model sits in front of the function caller, making the sequence audio → text → function call.
Voice-to-function calling is particularly useful on small devices whose settings menus are awkward to navigate. A person can ask for an outcome instead of locating the right control. The selected calendar frame shows a populated Tennis practice event form, including date and time fields and a Save button. It is an intermediate state: the form has been populated, but the event is not yet saved.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Spend the training effort on one task
The fine-tuning workflow begins with the device constraints, before the training investment:
- Choose a base model. Check that its performance and memory footprint fit the target device.
- Build synthetic task data. Generate examples of the inputs and outputs the feature needs.
- Fine-tune for the outcome. Teach the compact model the bounded behavior rather than expecting broad zero-shot capability.
The open-source Mobile Actions dataset provides a starting point for recreating the function-calling example by fine-tuning FunctionGemma.
Across the team’s work, Brick reports using roughly 10,000–10 million synthetic examples to obtain high task reliability through fine-tuning. This broad range reflects different models and tasks, rather than a prescribed dataset size for every feature.
Summarization and proofreading illustrate the trade. A 2–4-billion-parameter model can perform these tasks reasonably reliably with less specialization work. Brick reports that investing in synthetic data and single-task fine-tuning can produce the same or better quality with a much smaller model. The payoff is a smaller footprint, more responsive interaction and access to a wider set of devices—the properties that make deployment at large scale practical.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Offline dictation combines two specialized models
A production dictation application turns that specialization workflow into a complete feature. Brick describes subscription-free voice dictation that runs entirely on the device. It also removes fillers such as ums and uhs and supports personalization toward words and names relevant to the user.
The architecture separates an ASR engine from a text-polish engine. Both are fine-tuned Tiny Gemma models, described as being in the low hundreds of millions of parameters rather than given exact sizes. The recognition stage produces text; the polish stage cleans it up. Brick describes very good quality from this fully offline application, available to try on iOS, for a feature that would previously have required a server-backed subscription.
The same deployment logic extends to browser features. Brick points to Chrome summarization and proofreading APIs, describing them at the time as developer-preview features. His point is that tiny models can make such capabilities available to a wider hardware population; the preview framing is not a claim of current availability across all Chrome installations.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make specialization easier, and perception faster
For consumer devices and entry-level robotics, the deployment choice turns on what the product can afford. Small LLMs are easy to use and can run especially quickly on NPUs. Tiny models reach more devices, but robust voice-to-function calling requires investment in an appropriate synthetic dataset and fine-tuning. The model’s size and the development effort have to be considered together.
Asked about broader ambitions for tiny models, Brick identifies easier, more general voice-to-function calling as a key goal. One possibility is to have an agent generate the synthetic training data, reducing the work required to specialize a model and making the process accessible to more developers. He presents this as a direction for improvement, not an already completed training system.
Visual input is the other frontier: it still takes time to process. Faster visual models, with broader capabilities such as segmentation, could support additional device behaviors. The next gains therefore depend on both lowering the effort needed to build a specialized model and reducing the time it takes that model to perceive and respond.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Open-source app for trying local models on Android and iOS, inspecting examples and benchmarking device performance.
Google's runtime framework for deploying language models across phones, desktops and edge devices.
Model documentation covering function-calling evaluations, specialization and measured mobile resource usage.
Google's conversational training and evaluation data for mapping natural-language requests to Android system functions.
Official implementation and checkpoints for efficient vision-language models, including the 0.5B variant.
Developer-trial documentation for built-in proofreading, including availability checks and hardware requirements.
Further reading
Official tutorial for specializing FunctionGemma 270M and deploying the resulting model into AI Edge Gallery.
- Gemma 4 on Google AI EdgeArticle
Launch article explaining memory optimizations, device support and Raspberry Pi and Qualcomm inference measurements.
Read the complete timestamped transcript
- 0:00
[upbeat music] Yeah. So yeah, a bit of a change of speed from the last two talks that we're looking at kind of higher-end robots.
- 0:17
If we want, uh, for intelligence to get into lots and lots and lots of devices, and not just really expensive robots, we are going to need tiny models. And this talk is about what is the state-of-the-art of tiny models at the moment, what are the things they're good at, um, and what are the things you can go
- 0:35
start building today. Okay. So yeah, firstly, a bit of background, like, briefly on me and, and the team I work on. Then we're gonna take a look at small models that you may be kind of more familiar with, just kind of explore what they can do, what they can't do, um, yet.
- 0:51
Um, and then kind of see, "Hey, why do we need even smaller models?" Uh, and then just looking at the state-of-the-art of, uh, tiny models today, and what you need to do to get them into a form where you can deploy them in production to do useful things.
- 1:03
And yeah, lastly, we've got a couple of examples, uh, that we can look at, uh, from work from our team.
- 1:10
Okay, um, so me, our work-- I've worked in, um, edge AI for a while. Um, uh, um, these days, I work as a tech lead, um, on the AI Edge team at Google.
- 1:21
Uh, within the team, the types of things we do, um, are we develop kind of open source projects called, like, LiteRT-LM, LiteRT MediaPipe, and these make it easy to deploy AI to edge devices.
- 1:33
Um, we also do a lot of work delivering kind of edge AI core technology to Google's own products, um, some of which would be via tiny models. Um, and then we, we also work with the Gemma team to ensure their models work well on, um, and run well on lots of devices.
- 1:50
And then we've a significant focus on small and tiny models, because that's what, um, that's what's useful, uh, for, uh, a lot of kind of mobile phone applications, or if we want to be able to ship a model in-browser, uh, that also has to be really, really small.
- 2:05
And generally, our kind of playbook is we develop things for f-first party u- like, for in-house use first, and then if we can figure out a way to share that via an open source package or make those tools available to the wider world, we, we do so.
- 2:19
And that helps kind of lots of other people, um, uh, build similar types of things using open source technology.
- 2:28
Okay. So why do edge AI? This is probably, like, um, uh, rela- as opposed to just doing everything in the cloud. Um, you know, it's kind of obvious, but I'll kind of go through it anyway.
- 2:37
There's, like, kind of latency. You have fast, consistent speed. Privacy, data stays on the device. Offline use, it's kind of reliably available, so that kind of, um, that, that feature that you rely o- rely on on your mobile device will still work even when you don't have reception.
- 2:53
That can be very helpful. And then savings, um, especially these days if the alternative is to call a, um, even a faster model on the cloud, that will come at a cost, uh, particularly if you're kind of shipping a, an app or, like, a mobile phone app or something in-browser where, you know, the user interaction is at
- 3:13
kind of a very, very large scale. Then even though those tokens are relatively cheap, you're multiplying it by a large number, and it'll add up quickly.
- 3:22
So then, um, the main challenges then of deploying AI on the edge is the leftmost one is kind of new, uh, which is DRAM cost. And, um, it's, uh, a really significant constraint that, um...
- 3:38
And you'll even see some mobile phone manufacturers are putting less DRAM into their devices this year than previously. You'll also see that since, since launch, the cost of a Raspberry Pi 3 sixteen gigabytes has gone up by a factor of, like, two point five X.
- 3:53
Uh, so DRAM cost is really, really significant. Um, that then has a, like, casts a, a shadow over the rest of this talk, right? Where in order to be able to get AI applications running at the edge, we need to really think a lot about kind of quantization, and we also really need to think about what is
- 4:10
the smallest possible, um, model we can use for a given task. Um, other challenges are, yeah, there's a, a wider pool of target devices. And yet another challenge is, um, yeah, it's kind of fair to say that a lot of the research, uh, hours that go into LLMs these days are into the much larger models, um, and
- 4:31
MoE techniques and these types of stuff. Um, and the, the lower end of the LLM spectrum is a lot less studied. Uh, so yeah, these are challenges of deploying on the edge.
- 4:42
Okay. So small models, and when I say small, I would mean kind of typically maybe kind of one to, like, two or one to four billion parameters. You may find that these are built into the OS.
- 4:52
There's a version of a small model that ships, um, in Android high-end phones today with AICore. There's a version that ships with Apple, with Apple Intelligence. Um,
- 5:02
some, some, um, app vendors will ship models this size in their app. We certainly work with some app vendors that do this. Um,
- 5:11
and for, like, IoT and robotics, you would typically require, like, four, maybe four to eight gigs of DRAM in order to be able to ship this grade of model, which then is an implied cost on the device, right?
- 5:24
So it then kind of restricts these models to, you know, things like laptops, mobile phones, or kind of higher-end, uh, electronics, and kind of puts it out of reach of maybe a lot of, uh, lower-tier web browsers or the wider kind of IoT and consumer robotics market.
- 5:40
Um, yeah. And for, for smaller models, yeah, uh, developing smaller models, and we'll look in a while. We do a lot of work to minimize footprint with kind of quantization.
- 5:50
Um, and the playbook here is mostly prompting, right? If you want to deliver a particular feature using a smaller model, you can just kind of use zero-shot prompting and get pretty good performance.
- 5:58
Also, you could use, uh, LoRA adapters. And it's kind of somewhat robust at doing things like kind of function calling and agent skills.
- 6:06
Okay. So really quick example is like our, you know, um, working with the Gemma team, our favorite go-to example is always Gemma for these kind of things. Uh, so we can see that like the E2B model is, um, pretty capable in terms of reasoning.
- 6:19
It's certainly like on par, like with a Gemma 3 much larger model from kind of 12 months ago. Um, and yeah, so we now have like much smaller models with...
- 6:29
That are pretty capable at reasoning, and we get pretty decent answers just with zero-shot prompting for a given task. We've also done lots and lots of work to optimize the memory footprint of that 2 billion parameter model as much as we possibly can.
- 6:42
Um, so it uses a mix of like 2-bit, 4-bit, and 8-bit quantization, getting it down to like, what is it, like 2.9 bits per weight if you look at the actual weights we need to hold in memory.
- 6:52
We do other tricks like per-layer embeddings. I won't go into l- like all of the detail here, but end result is we can, you know, you need maybe one, like here it's 841 megabytes for a text-only model in memory just for the weights.
- 7:05
And then, you know, maybe by the time you add in the runtime, a, a KV cache, um, uh, footprint, you, you might be up to requiring like 2 gigs of active RAM to be able to run this model.
- 7:16
Then you account for an OS and the fact that there's other things going on, that's where we get the kind of four, 4 gig plus rule of thumb, uh, for deploying this on a device.
- 7:27
Um, then in terms of speed, this is using our runtime. This is just a list of devices that we run on. Uh, for the purpose of this talk, we're gonna look more closely at the last three rows of the table, which is if we take that 2 billion parameter model and run it on a Raspberry Pi, um,
- 7:44
that is... will give about 7.6 tokens per second decode. This is without MTP. If you turn on MTP, that'll get maybe 2X faster depending on the task. Um, if you go to a higher, a more capable device like a Jetson or a Nano, we can get up to maybe 24, um, tokens per second decode, or maybe even
- 8:04
faster if you used NVIDIA's own toolchain. This is with our toolchain. Um, we also have done work to port this to a Qualcomm IoT board, which is pretty popular among kind of higher-end, uh, robotics and IoT applications.
- 8:16
And there, yeah, you can see you can get about like almost 4,000 tokens per second, uh, prefill, uh, 31 tokens per second decode. And that's useful for lots of like almost real-time, um, uh, applications, uh, on an NPU because s- um, with, with these, uh, with Gemma 4 models, like one medium resolution image is like kind of
- 8:40
500 tokens. A high resolution image is 1120 tokens. So you could get like, you know, 3 frames per second of high resolu- high resolution tokens, um, uh, going through this model, and have pretty decent decode speed as well.
- 8:52
So there's lots of, lots of compelling applications you can build with this type of... with a small model. If you're kind of, if you're kind of market or if you're kind of willing to have more expensive hardware and have a more expensive, um, uh, uh, DRAM kind of, uh, line on your kind of bill of materials for
- 9:13
the device you're building. Uh, yeah, just like our toolchain, we also s- work with other models in the community that are of similar size, and they each have their strengths as well, right?
- 9:28
Um, so these are some of the other models that we support here. Um, really briefly, I won't go into this in too much detail, but we also... If I can get this to play.
- 9:39
Um, we also have a- an app that you can use on both iOS and Android. So if you wanna take one of these small models to see how fast it works on a phone, you can, uh, just go straight ahead and do that.
- 9:51
Um, so it's available on AI Edge Gallery. Also, all of the...
- 9:57
Why am I getting that buzzing? Uh, all-- the app is also fully open source, so if you wanna see how to build something similar using one of these models or to see how this is using the open source runtime that runs the models, you can see all of that.
- 10:10
So this is a great way of just getting started and trying small models if this is what you want to do.
- 10:17
Okay. This is another example, uh, which I'm not gonna play this video, but you should definitely check it out. This is an example showing a, um, an open source, the OpenDoc Mini v2 robot.
- 10:28
This is one, um, Xavier, one of the, um, engineers in DeepMind built this as a kind of hobby project. Really, really fun. Um, so go check out this YouTube video.
- 10:37
What you'll, what you'll see is these two robots. One is, uh, one uses the Jetson Nano, one uses the Raspberry Pi. And, um, you'll see that the robot is able to, um, it's, it's able to kind of like read signs like, um, and react to things and kind of nod its head.
- 10:55
It's also kind of able to take both voice and image input. Um, yeah, and what you'll see is the Jetson Nano one performs, uh, uh, has really good real-time interaction.
- 11:04
The one based on Raspberry Pi, it works, but it's kind of a lot slower, right? So for some examples, um, for some types of interaction, um, even the kind of best models we have today are, are maybe not meeting a kind of user interaction requirements.
- 11:21
Uh, but yeah, this is a really fun video, so definitely check it out. So yes, um, so then small models, while, uh, they're great, right? If your product can afford, uh, to use one of these, they're, uh, they're really easy to use because you just need to zero-shot prompt in order to get it to work.
- 11:38
Um, the Gemma team has done great work in having, you know, low footprint, high capable, um, uh, models that are ready to use, and they're optimized running on all of those devices, uh, you saw earlier.
- 11:50
And you know, if, um, yeah, so if, if all of your constraint-- if you can live within those constraints, uh, then great, right? Your journey would stop here, and you would build a feature you would want, right?
- 12:02
For lots and lots of other things that, that we do in our work and other people that we talk to, you know, we're still at a point where small models are too big because they can't reach like older laptops or kind of more consumer edge devices.
- 12:17
Um, the user interaction needs to be more responsive. Um, we also kind of have the reality, and we do have this a lot of times, where the, the model you want to run isn't the main feature in the application.
- 12:29
It's like one tiny thing in a corner that needs to run while everything else in the system is running. Um, so we also need a, a smaller model for system health as a common, uh, common pattern.
- 12:39
So then enter kind of tiny models, right? So these are typically in the as small as kind of 50 billion parameters. We've deployed models that small, uh, to maybe 500 million parameters.
- 12:50
Uh, they're easier to ship nati- natively with applications. They would run on the types of things you see on the right-hand side, um, uh, and would require, you know, maybe less than two gigs of RAM or, or even less than that.
- 13:03
And they can also be made to run really, really fast. But the playbook to deploying here, it's a little more complicated. Um, so, you know, sometimes there's off-the-shelf models that'll do what you want, and we'll look at those in the next slide.
- 13:15
Um, or else if that doesn't work, you're gonna be left in a world of kind of fine-tuning a model to achieve a given outcome, but which works very, very well.
- 13:24
So fixed task models, um, there's a bunch of things around ASR, vision, and embedding models. And if you have a... If you have something, uh... Yeah, so like ASR and vision and embeddings, these are all kind of stock features, and they work really, really well.
- 13:38
This is an example of Apple FastVLM, uh, which is 0.5 billion parameter model running on a, uh, Android device using hardware acceleration, and you can see it runs really, really fast.
- 13:50
So if you needed to kind of add a little bit of visual intelligence to a, um, like an edge device or an IoT device, you know, this class of model is an excellent, uh, is an excellent option to get that kind of first level of visual awareness.
- 14:04
Or for ASR, um, yeah, there's some kind of strong models listed here as well.
- 14:09
And, and then lastly, embedding models are great at, um, uh... Yeah, like this is just a text embedding model, which is, yeah, really good at kind of, uh, processing and ma- matching text, which is can be relevant in some cases.
- 14:24
Okay. Um, but then next scenario is you want to kind of fine-tune a model. Um, so here you can start with, uh, the models I'm citing here are kind of Google developed models.
- 14:36
Uh, so there's some starting at like 270 million parameters, and Gemma 3 and FunctionGemma. Uh, Gemma 3 is a general purpose model. FunctionGemma is one that has extra pre-training, uh, for function calling patterns.
- 14:51
So here the performance, if you remember earlier on the Raspberry Pi, our performance was at, uh, mid-single digits tokens per second decode. So here that kind of jumps up to 45 tokens per second because we need to read less, uh, from memory each time.
- 15:05
And we can fine-tune this to do pretty compelling things. So on the right-hand side, um, this is running a, uh, what we call a mobile actions model. Uh, so this is text in and function calling out.
- 15:19
Um, this model knows about 10 different output functions and can call them at over 86%, uh, reliability from a given arbitrary text input. And this is for doing common things on a mobile device like, uh, schedule a, uh, calendar or turn on and off Wi-Fi or things like this.
- 15:39
And it can take like arbitrary free text input and, uh, convert that to appropriate function calling. And for this demo, we've taken another ASR model and put it in front of that, um, which gives kind of voice to function calling as a feature.
- 15:53
And voice to function calling is pretty key for lots of IoT and edge devices because,
- 15:58
um, yeah, like smaller devices tend to have, you know, require settings menus, and that user interface can be really, really challenging for lots of people. Uh, so yeah, being able to just talk to something to ask for a given outcome, this is a pretty key capability, and, uh, we can do that reasonably reliably using a fine-tuned small
- 16:17
model. So the playbook is generally then you pick a base model, you check the performance if the performance and memory footprint are within the range that you want. And then, um, the kind of the harder part is you...
- 16:30
uh, the playbook we've found works really, really well is we synthetically generate data to fine-tune that model. Um, depending on the model, like, um, there's a dataset we've open sourced here called Mobile Actions, it's available on Hugging Face, that corresponds to this if you want to kind of recreate that same demo yourself and fine-tune FunctionGemma from scratch.
- 16:50
Um, but we- we've generally found that in the range of 10,000 to 10 million samples of synthetically generated, um, data will be sufficient to fine-tune a smaller model to a really, really high degree of reliability.
- 17:07
And so for other tasks we've done like things like summarization or proofreading, so something which you could do with a 2 or 4 billion parameter model reasonably reliably. If you're willing to put the time and energy into creating a synthetic dataset and fine-tuning a model, you can achieve a similar, like the same or greater quality with a
- 17:27
model that is much, much smaller, will work on a much wider set of devices, and will be much, much more responsive. Um, so yeah, and that's the, that's the type of outcome we're seeing now with just fine-tuning a model for a single task.
- 17:40
And it's a really like... Yeah, we found this is a really good playbook, uh, for deploying at like very wide scale.
- 17:47
So here's another example in... This is one example in production where we have... This is an app that we've developed for voice dictation without subscription. Um, all of the voice dictation happens locally on device.
- 18:02
Um, and as well as just doing dictation, it also does, uh, uh, it also does, um... Well, it kind of cleans up ums and uhs, right? If you see on the right-hand side, it's able to clean up text.
- 18:13
It's also able to do biasing towards kind of words and names that, um, uh, are kind of relevant to you personally, so kind of personalization. The left-hand side kind of shows how we built that application.
- 18:25
So there's an ASR engine and a text policy engine, and both of these are fine-tuned versions of Tiny Gemma models. And this allows us to take something that would've been a kind of like server-only feature of, you know, where you require a subscription to do highly accurate, uh, voice dictation, and have an app that's just able to
- 18:42
do that completely offline with very, very good quality. Uh, so this is something you can try on iOS if, if you wanna give this a go today. But, um, uh, yeah, and it just, uh, the backbone of this app is kind of two fine-tuned, uh, small Gemma-based models in the low single digits, hundreds of parameter- million parameters.
- 19:01
Yeah. We... Also worth, uh, noting is there's also, uh, kind of features in developer preview in Chrome, for example, that kind of summarization and proofread APIs are a feature as built-in APIs in Chrome.
- 19:14
And delivering those features via tiny models allows, um, the Chrome team to ship them to a much wider set of, uh, Chrome users than would otherwise be possible. Um, yep.
- 19:24
So that's, uh... We've probably gonna have like one minute for questions. Um, some kind of key takeaways is on the last slide, if I can get there.
- 19:33
Yeah, so takeaways from consumer devices and entry-level robotics is small LLMs are easy to use, uh, and, and especially on NPUs, uh, they're very, very fast. Uh, tiny models will alla- will enable reach a much, much larger pool of devices.
- 19:46
And voice-to-function calling, um, can now be built to, to be robust using tiny models. Uh, it just requires kind of investing in an appropriate synthetic data set with enough samples, and then you can fine-tune a model to get really good outcomes.
- 19:58
Cool. So happy to take one or two questions or, um, if anybody has one. Yeah?
- 20:09
Sorry, I'm going to plug this out. Yeah, sorry. Sorry. Say again?
- 20:27
Like broader ambitions of where tiny models can go? Wow. Um,
- 20:32
I think kind of generalizing voice-to-function calling, um, is a, is a, is one key goal, like making that very easy for lots of people because I think that's a key use case.
- 20:43
That if we can figure, like, if we can figure out how to make, you know, have, like, an agent generate the synthetic data [laughs] for you, right? Um, if we...
- 20:51
Like, it's certainly possible to make that journey much easier than it is today and make it available to a lot more people. Um,
- 20:59
yeah. And, and certainly the, the visual input as well, um, that takes a little bit of time at the moment. There's certainly scope to have faster models there, uh, that can do a wider set of things like kind of segmentation and other things that would enable other use cases.
- 21:12
Yeah.
- 21:12
Awesome. Yeah, due to the time, we probably don't have a, a Q&A session for today.
- 21:16
Um-
- 21:16
Yeah. But Cormac will stay after the session maybe, and you can ask for more question about the-
- 21:22
I'll stay after the session, or you can come grab me downstairs at the DeepMind booth at 4:00. I'll, I'll be there 4:00 to 5:00. Okay. [outro music]