WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=hacEQHHhu2Q

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/hacEQHHhu2Q.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.800 --> 00:00:13.120
Yeah.

s3
00:00:13.120 --> 00:00:15.280
So, yeah, a bit of a change of speed from the last two talks.

s4
00:00:15.280 --> 00:00:17.359
So, we're looking at kind of higherend robots.

s5
00:00:17.359 --> 00:00:27.840
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.

s6
00:00:27.840 --> 00:00:32.239
And this talk is about what is the state-of-the-art of tiny models at the moment.

s7
00:00:32.239 --> 00:00:33.760
What are the things they're good at?

s8
00:00:33.760 --> 00:00:38.000
Um, and what are the things you can go start building today.

s9
00:00:38.000 --> 00:00:38.480
Okay.

s10
00:00:38.480 --> 00:00:42.719
So, yeah, firstly a bit of background like briefly on me and and the team I work on.

s11
00:00:42.719 --> 00:00:46.320
Then we're going to take a look at small models that you may be kind of more familiar with.

s12
00:00:46.320 --> 00:00:50.960
Just kind of explore what they can do, what they can't do um yet.

s13
00:00:50.960 --> 00:00:55.280
Um, and then kind of see, hey, why do we need even smaller models?

s14
00:00:55.280 --> 00:01:03.120
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 and you can deploy them in production to do useful things.

s15
00:01:03.120 --> 00:01:10.400
And yeah, lastly, we've got a couple of examples uh that we can look at uh from work from our team.

s16
00:01:10.400 --> 00:01:10.799
Okay.

s17
00:01:10.799 --> 00:01:14.560
Um so me I work I've worked in um Edi for a while.

s18
00:01:14.560 --> 00:01:21.040
Um uh um these days I work as a tech lead um on the AI edge team at Google.

s19
00:01:21.040 --> 00:01:30.720
uh within the team the types of things we do um are we develop kind of open source projects called like lighter TLM lighter t mediapipe and these make it easy to deploy

s20
00:01:30.720 --> 00:01:43.520
AI to edge devices 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

s21
00:01:43.520 --> 00:01:54.159
um and then we also work with the Gemma team to ensure their models work well on um and run well on lots of devices and then we have a significant ificant focus on small and tiny models because that's what

s22
00:01:54.159 --> 00:02:12.400
um that's what's useful uh for 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 and generally our kind of playbook is we develop things for first party like for in-house use first and then if we can figure

s23
00:02:12.400 --> 00:02:22.560
out a way to share that via an open source package or make those tools available to the wider world we we do so and that helps kind lots of other people um

s24
00:02:22.560 --> 00:02:26.640
build similar types of things using open source technology.

s25
00:02:28.160 --> 00:02:34.400
Okay, so why do edi this is probably like um uh rel as opposed to just doing everything in the cloud.

s26
00:02:34.400 --> 00:02:37.519
Um you know it's kind of obvious but I'll kind of go through it anyway.

s27
00:02:37.519 --> 00:02:45.840
There's like kind of latency you fast consistent speed privacy data stays on the device offline use it's kind of reliably available.

s28
00:02:45.840 --> 00:02:53.599
So that kind of um that that feature that you rely rely on in your mobile device will still work even when you don't have reception.

s29
00:02:53.599 --> 00:02:54.959
That can be very helpful.

s30
00:02:54.959 --> 00:03:05.360
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.

s31
00:03:05.360 --> 00:03:14.879
Uh particularly if you're kind of shipping an app or like a mobile phone app or something in browser where you know the user interaction is at kind of very very large scale.

s32
00:03:14.879 --> 00:03:22.000
then even though those tokens are relatively cheap, you're multiplying it by a large number and it'll add up quickly.

s33
00:03:22.879 --> 00:03:37.200
So then um the main challenges then of deploying AI on the edge is the leftmost one is kind of new uh which is DAM cost and um it's a really significant constraint

s34
00:03:37.200 --> 00:03:43.200
that um and you'll even see some mobile phone manufacturers are putting less DAM into their devices this year than previously.

s35
00:03:43.200 --> 00:03:53.120
You'll also see that since since launch, the cost of a Raspberry Pi 36 gigabytes has gone up by a factor of like 2.5x.

s36
00:03:53.120 --> 00:03:56.080
Uh so DAM cost is really really significant.

s37
00:03:56.080 --> 00:04:01.599
Um that then has a like casts a shadow over the rest of this talk, right?

s38
00:04:01.599 --> 00:04:11.760
where in order to be able to get AI applications running on the edge, we need to really think a lot about kind of quantization and we also really need to think about what is the smallest possible

s39
00:04:11.760 --> 00:04:14.799
um model we can use for a given task.

s40
00:04:14.799 --> 00:04:26.320
Um other challenges are yeah there's 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

s41
00:04:26.320 --> 00:04:38.639
uh hours that go into LLMs these days are into the much larger models um and techniques and this types of stuff um and the the lower end of the LLM spectrum is a lot less studied

s42
00:04:38.639 --> 00:04:44.800
uh so yeah these are challenges of deploying the edge okay so small models and when I small.

s43
00:04:44.800 --> 00:04:50.560
I would mean kind of typically maybe kind of one to two or one to four billion parameters.

s44
00:04:50.560 --> 00:04:52.400
You may find that these are built into the OS.

s45
00:04:52.400 --> 00:04:58.160
There's a version of a small model that ships um in Android high-end phones today with AI core.

s46
00:04:58.160 --> 00:05:00.800
There's a version that ships with Apple with Apple intelligence.

s47
00:05:00.800 --> 00:05:06.560
Um some some um app vendors will ship a models this size in their app.

s48
00:05:06.560 --> 00:05:09.440
We certainly work with some app vendors that do this.

s49
00:05:09.440 --> 00:05:22.479
Um, 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 has an implied cost on

s50
00:05:22.479 --> 00:05:24.240
the device, right?

s51
00:05:24.240 --> 00:05:36.400
So it then kind of restricts these models to you know things like laptops, mobile phones or kind of higherend electronics and kind of puts it out of reach of maybe a lot of uh lower tier web browsers or

s52
00:05:36.400 --> 00:05:40.639
the wider kind of IoT and consumer robotics market.

s53
00:05:40.639 --> 00:05:49.919
Um yeah and for for smaller models yep developing smaller models and we'll look in a while we do a lot of work to minimize footprints with kind of quantization.

s54
00:05:49.919 --> 00:05:53.039
Um and the playbook here is mostly prompting, right?

s55
00:05:53.039 --> 00:05:58.479
If you want to deliver a particular feature using a smaller model, you can just kind of use zero soft prompting and get pretty good performance.

s56
00:05:58.479 --> 00:06:06.000
Also to use Laura adapters and it's kind of somewhat robust at doing things like kind of function calling and agent skills.

s57
00:06:06.000 --> 00:06:13.919
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.

s58
00:06:13.919 --> 00:06:19.360
Uh so we can see that like the E2B model is um pretty capable in terms of reasoning.

s59
00:06:19.360 --> 00:06:25.199
It's certainly like on par like with a Gemma 3 much larger model from kind of 12 months ago.

s60
00:06:25.199 --> 00:06:35.600
Um and yeah, so we now have like much smaller models with that were pretty capable at reasoning and we get pretty decent answers just with zero shot prompting for a given task.

s61
00:06:35.600 --> 00:06:42.639
We've also done lots and lots of work to optimize the memory footprint of that two billion parameter model as much as we possibly can.

s62
00:06:42.639 --> 00:06:52.720
Um, so it uses a mix of like two bit, four bit and 8 bit quantization getting it down to like I know like 2.9 bits per weight if you look at the actual weights we need to hold in memory.

s63
00:06:52.720 --> 00:06:54.720
We do other tricks like per layer embeddings.

s64
00:06:54.720 --> 00:07:10.160
I won't go into 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 texton model in memory just for the weights and then you know maybe by the time you add in the runtime a KV cache

s65
00:07:10.160 --> 00:07:20.880
um footprint you you might be up to requiring like two gigs of active RAM to be able to run this model 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

s66
00:07:20.880 --> 00:07:27.039
four gig plus rule of thumb uh for deploying this on a device.

s67
00:07:27.360 --> 00:07:31.680
Um then in terms of speed, this is using our runtime.

s68
00:07:31.680 --> 00:07:34.240
This is just a list of devices that we run on.

s69
00:07:34.240 --> 00:07:43.039
Uh for the purpose of this talk, we're going to look more closely at the last three rows of the table, which is if we take that two billion parameter model and run it on a Raspberry Pi.

s70
00:07:43.039 --> 00:07:48.639
Um that is will give about 7.6 tokens per second decode.

s71
00:07:48.639 --> 00:07:49.759
This is without MTP.

s72
00:07:49.759 --> 00:07:54.639
If you turn on MTP, that'll get maybe 2x faster depending on the task.

s73
00:07:54.639 --> 00:08:05.919
Um, if you go to a higher a more capable device like a Jetson RN Nano, we can get up to maybe 24 um tokens per second decode or maybe even faster if you use Nvidia's own tool chain.

s74
00:08:05.919 --> 00:08:07.840
This is with our tool chain.

s75
00:08:07.840 --> 00:08:21.280
Um we also have done work to port this to a Qualcomm IoT board which is pretty popular among kind of higherend uh robotics and IoT applications and there yeah you can see you can get about like almost 4,000 tokens per second

s76
00:08:21.280 --> 00:08:39.599
uh preill 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 um with with these uh with Gemma 4 models like One medium resolution image is

s77
00:08:39.599 --> 00:08:40.880
like kind of 500 tokens.

s78
00:08:40.880 --> 00:08:43.279
A high resolution image is 1120 tokens.

s79
00:08:43.279 --> 00:08:52.880
So you could get like you know three frames per second of high resol high resolution tokens um going through this model and have pretty decent decode speed as well.

s80
00:08:52.880 --> 00:09:05.440
So there's lots and 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

s81
00:09:05.440 --> 00:09:15.760
more expensive um uh uh DRAM kind of uh line on your kind of bill of materials for the device you're building.

s82
00:09:17.440 --> 00:09:28.560
Uh yeah, just like our tool chain, we also work with other models in the community that are of similar size and they each have their strengths as well, right?

s83
00:09:28.560 --> 00:09:32.320
Um so these are some of the other models that we support here.

s84
00:09:32.320 --> 00:09:45.360
Um really briefly, I won't go into this in too much detail, but we also, if I can get this to play, um we also have a an app that you can use on both iOS and Android.

s85
00:09:45.360 --> 00:09:51.760
So if you want to take one of these small models, see how fast it works in a phone, you can uh just go straight ahead and do that.

s86
00:09:51.760 --> 00:09:54.480
Um so it's available on AI edge gallery.

s87
00:09:54.480 --> 00:09:58.560
Also, all of the Oh, I'm getting that buzzing.

s88
00:09:58.560 --> 00:10:00.959
Uh all the app is also fully open source.

s89
00:10:00.959 --> 00:10:10.240
So if you want to 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.

s90
00:10:10.240 --> 00:10:16.959
So this is a great way of just getting started and trying small models if this is what you want to do.

s91
00:10:17.519 --> 00:10:23.120
Okay, this is another example uh which I'm not going to play this video but you should definitely check it out.

s92
00:10:23.120 --> 00:10:28.160
This is an example showing a um an open- source the open doc mini v2 robot.

s93
00:10:28.160 --> 00:10:33.440
This is one um Zavier, one of the um engineers in deep mind built this as a kind of hobby project.

s94
00:10:33.440 --> 00:10:34.720
Really really fun.

s95
00:10:34.720 --> 00:10:37.200
Um so go check out this YouTube video.

s96
00:10:37.200 --> 00:10:39.920
What you what you'll see is he has two robots.

s97
00:10:39.920 --> 00:10:44.640
One is uh one uses the Jets and Nano, one uses the Raspberry Pi.

s98
00:10:44.640 --> 00:10:55.120
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.

s99
00:10:55.120 --> 00:10:58.240
It's also kind of able to take both voice and image input.

s100
00:10:58.240 --> 00:11:04.240
Um yeah, and what you'll see is the Jets Nano one performs uh has really good real-time interaction.

s101
00:11:04.240 --> 00:11:19.360
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

s102
00:11:21.440 --> 00:11:31.839
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

s103
00:11:31.839 --> 00:11:38.160
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.

s104
00:11:38.160 --> 00:11:48.640
Um Genet 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

s105
00:11:48.640 --> 00:11:50.160
uh you saw earlier.

s106
00:11:50.160 --> 00:12:02.880
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

s107
00:12:02.880 --> 00:12:08.880
for lots and lots of other things that that we do in our work and other people that we talk to.

s108
00:12:08.880 --> 00:12:17.920
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.

s109
00:12:17.920 --> 00:12:21.120
um the user interaction needs to be more responsive.

s110
00:12:21.120 --> 00:12:29.279
Um we also could have the reality and we do of this a lot of times where the the model you want to run isn't the main feature in the application.

s111
00:12:29.279 --> 00:12:33.920
It's like one tiny thing in a corner that needs to run while everything else in the system is running.

s112
00:12:33.920 --> 00:12:36.720
Um so we also need a smaller model for system health.

s113
00:12:36.720 --> 00:12:39.680
It's a common uh common pattern.

s114
00:12:39.680 --> 00:12:41.920
So then enter kind of tiny models, right?

s115
00:12:41.920 --> 00:12:46.240
So these are typically in the as small as kind of 50 billion parameters.

s116
00:12:46.240 --> 00:12:50.480
We've deployed models that small uh to maybe 500 million parameters.

s117
00:12:50.480 --> 00:12:53.279
Uh they're easier to ship natively with applications.

s118
00:12:53.279 --> 00:12:56.480
They would run on the types of things you see on the right hand side.

s119
00:12:56.480 --> 00:13:02.959
Um uh and would require you know maybe less than 2 gigs of RAM or or even less than that.

s120
00:13:02.959 --> 00:13:05.920
And they can also be made to run really really fast.

s121
00:13:05.920 --> 00:13:09.680
But the playbook to deploying here it's a little more complicated.

s122
00:13:09.680 --> 00:13:15.600
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.

s123
00:13:15.600 --> 00:13:24.399
um or else if that doesn't work, you're going to be left in a world of kind of fine-tuning a model to achieve a given outcome, but which works very very well.

s124
00:13:24.399 --> 00:13:34.399
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

s125
00:13:34.399 --> 00:13:38.160
and vision and embeddings these are all kind of stock features and they work really really well.

s126
00:13:38.160 --> 00:13:50.240
This is an example of Apple fast VLM uh which is 0.5 billion parameter model running on a Android device using hardware acceleration and you can see it runs really really fast.

s127
00:13:50.240 --> 00:14:00.000
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

s128
00:14:00.000 --> 00:14:05.199
uh is an excellent option to get that kind of first level of visual awareness or for ASR.

s129
00:14:05.199 --> 00:14:09.680
Um yeah, there's some kind of strong models listed here as well.

s130
00:14:09.760 --> 00:14:23.360
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 processing and match matching text which is can be relevant in some cases.

s131
00:14:24.240 --> 00:14:25.440
Okay.

s132
00:14:25.440 --> 00:14:31.199
Um but then next scenario is you want to kind of fine-tune a model.

s133
00:14:31.199 --> 00:14:36.880
Um so here you can start with uh the models I'm citing here are kind of Google developed models.

s134
00:14:36.880 --> 00:14:43.199
Uh so there's some starting at like 270 million parameters and Gemma 3 and function Gemma.

s135
00:14:43.199 --> 00:14:45.199
Uh Gemma 3 is a general purpose model.

s136
00:14:45.199 --> 00:14:51.120
Function Gemma is one that has extra pre-training uh for function calling patterns.

s137
00:14:51.120 --> 00:14:59.279
So here the performance if you remember earlier on the Raspberry Pi our performance was at uh mids singledigit tokens per second decode.

s138
00:14:59.279 --> 00:15:05.760
So here that kind of jumps up to 45 tokens per second because we need to read less uh from memory each time.

s139
00:15:05.760 --> 00:15:08.079
And we can fine-tune this to do pretty compelling things.

s140
00:15:08.079 --> 00:15:15.839
So on the right hand side um this is running a uh what we call a mobile actions model.

s141
00:15:15.839 --> 00:15:19.040
Uh so this does text in and function calling out.

s142
00:15:19.040 --> 00:15:30.720
Um this model knows about 10 different output functions and can call them at over 86% uh reliability from a given arbitrary text input.

s143
00:15:30.720 --> 00:15:39.279
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.

s144
00:15:39.279 --> 00:15:44.800
And it can take like arbitrary free text input and convert that to appropriate function calling.

s145
00:15:44.800 --> 00:15:49.040
And for this demo, we've taken another ASR model and put it in front of that.

s146
00:15:49.040 --> 00:15:53.120
Um which gives kind of voice to function calling as a feature.

s147
00:15:53.120 --> 00:16:07.759
And voice to function calling is pretty key for lots of IoT and edge devices because 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.

s148
00:16:07.759 --> 00:16:11.279
Uh so yeah being able to just talk to something to ask for a given outcome.

s149
00:16:11.279 --> 00:16:18.560
This is a pretty key capability and uh we can do that reasonably reliably using a fine-tuned small model.

s150
00:16:18.560 --> 00:16:30.399
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

s151
00:16:30.399 --> 00:16:48.880
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 data set 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

s152
00:16:48.880 --> 00:16:50.639
function gemma from scratch.

s153
00:16:50.639 --> 00:17:07.039
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.

s154
00:17:07.039 --> 00:17:12.400
And so for other tasks we've done like things like summarization or proof reading.

s155
00:17:12.400 --> 00:17:27.039
So something which you could do with a two or four billion parameter model reasonably reliably if you're willing to put the time and energy into creating a synthetic data set and fine-tuning a model you can achieve a similar like the same or greater quality

s156
00:17:27.039 --> 00:17:33.679
with a model that is much much smaller will work on a much wider set of devices and will be much much more responsive.

s157
00:17:33.679 --> 00:17:47.360
Um so yeah and that's that's the type of outcome we're seeing now with just fine-tuning a model for a single task and it's a really like yeah we found this is a really good playbook uh for deploying at like very wide scale.

s158
00:17:47.760 --> 00:17:58.400
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.

s159
00:17:58.400 --> 00:18:02.080
Um all of the voice dictation happens locally on device.

s160
00:18:02.080 --> 00:18:10.720
Um, and as well as just doing dictation, it also does uh it also does um wow, it kind of cleans up ums and a's, right?

s161
00:18:10.720 --> 00:18:13.280
If you see on the right hand side, it's able to clean up text.

s162
00:18:13.280 --> 00:18:21.120
It's also able to do biasing towards kind of words and names that um uh are kind of relevant to you personally.

s163
00:18:21.120 --> 00:18:22.640
So kind of personalization.

s164
00:18:22.640 --> 00:18:25.520
The left hand side kind of shows how we built that application.

s165
00:18:25.520 --> 00:18:28.160
So there's an ASR engine and a text policing engine.

s166
00:18:28.160 --> 00:18:31.919
And both of these are fine-tuned versions of tiny Gemma models.

s167
00:18:31.919 --> 00:18:40.480
And this allows us to take something that would have been a kind of like server only feature of, you know, where you require a subscription to do highly accurate

s168
00:18:40.480 --> 00:18:45.840
uh voice dictation and have an app that's just able to do that completely offline with very very good quality.

s169
00:18:45.840 --> 00:18:49.520
Uh so this is something you can try on iOS if if you want to give this a go today.

s170
00:18:49.520 --> 00:19:02.720
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 singledigit hundreds of parameter million parameters.

s171
00:19:02.880 --> 00:19:17.360
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 proofre APIs or feature as built-in APIs in Chrome and delivering those features via tiny models allows

s172
00:19:17.360 --> 00:19:23.840
um the Chrome team to ship them to a much wider set of uh Chrome users than would otherwise be possible.

s173
00:19:23.840 --> 00:19:27.840
Um yeah, so that's uh we've probably g have like one minute for questions.

s174
00:19:27.840 --> 00:19:29.760
Um some kind of key takeaways.

s175
00:19:29.760 --> 00:19:33.360
It's on the last slide if I can get there.

s176
00:19:33.360 --> 00:19:33.600
Yeah.

s177
00:19:33.600 --> 00:19:38.160
So takeaways from consumer devices and entry- level robotics is small LLMs are easy to use.

s178
00:19:38.160 --> 00:19:41.360
Uh and especially on NPUs, uh they're very very fast.

s179
00:19:41.360 --> 00:19:51.840
Uh tiny models will will enable reach to a much much larger pool of devices and voiceto function calling um can now be built to to be robust using tiny models.

s180
00:19:51.840 --> 00:19:58.960
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.

s181
00:19:58.960 --> 00:19:59.440
Cool.

s182
00:19:59.440 --> 00:20:04.720
So happy to take one or two questions or um if anybody has one.

s183
00:20:04.720 --> 00:20:06.720
Yeah.

s184
00:20:09.840 --> 00:20:10.160
Sorry.

s185
00:20:10.160 --> 00:20:12.240
I'm going to plug this out.

s186
00:20:12.240 --> 00:20:12.559
Yeah.

s187
00:20:12.559 --> 00:20:14.320
Sorry.

s188
00:20:14.320 --> 00:20:14.799
Sorry.

s189
00:20:14.799 --> 00:20:16.799
Second.

s190
00:20:26.960 --> 00:20:30.240
like broader ambitions of where tiny models can go.

s191
00:20:30.240 --> 00:20:30.720
Wow.

s192
00:20:30.720 --> 00:20:47.360
Um, 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 that if we can figure like if we can figure out how to make, you know, have

s193
00:20:47.360 --> 00:20:50.559
like an agent generate the synthetic data for you, right?

s194
00:20:50.559 --> 00:20:57.919
Um, if we like it's certainly possible to make that journey much easier than it is today and make it available to a lot more people.

s195
00:20:57.919 --> 00:21:00.000
Um, yeah.

s196
00:21:00.000 --> 00:21:02.240
and and certainly the the visual input as well.

s197
00:21:02.240 --> 00:21:04.320
Um that takes a little bit of time at the moment.

s198
00:21:04.320 --> 00:21:12.720
There's certainly scope to have faster models there that can do a wider set of things like kind of segmentation and other things that would enable other use cases.

s199
00:21:12.720 --> 00:21:13.120
Awesome.

s200
00:21:13.120 --> 00:21:13.360
Yeah.

s201
00:21:13.360 --> 00:21:14.159
Do you see the time?

s202
00:21:14.159 --> 00:21:16.880
We probably don't have uh Q&A session for today.

s203
00:21:16.880 --> 00:21:17.440
Yeah.

s204
00:21:17.440 --> 00:21:22.159
But Corman will stay after the session maybe and you can ask for more question about

s205
00:21:22.159 --> 00:21:26.080
I'll stay after this session or you can come grab me downstairs at the Jeep mind booth at 4:00.

s206
00:21:26.080 --> 00:21:29.440
I'll I'll be there 4 to 5. Okay.

s207
00:21:42.154 --> 00:21:44.154
[music]