Owning the AI Pareto Frontier with Jeff Dean

Source material

Transcript

Hello, we're here in the studio with Jefty and Chief ASN is a Google Welcome.

Thank you for having me.

It's a bit surreal to have you in the studio.

I've watched so many of your talks and obviously your career has been super legendary.

I mean congrats.

I think the first thing must be said congrats on owning the period of frontier.

Thank you.

Thank you.

Prado frontiers are good.

It's good to be out there.

Yeah, I think it's a combination of both, you have to own the period of frontier.

You have to have frontier capability but also efficiency and then offer that range of models that people like to use.

And you know, some part of this was started because of your hardware work, some part of that is your model work.

And I'm sure there's lots of secret sauce that you guys have worked on accumulatively.

But it's really impressive to see it all come together in like this slidily advancing frontier.

Yeah, I mean, I think as you say, it's not just one thing.

It's like a whole bunch of things up and down the stacks.

And you know, all of those really combined to help me, you know, us able to make have a capable large models as well as, you know, software techniques to get those large model capabilities into much smaller lighter weight models that are, you know, much more cost effective and lower latency.

But still, you know, quite capable for their size.

How much pressure do you have on like having the lower bound of the private frontier, too?

I think like the new labs are always trying to push the top performance frontier because we need to raise more money and all of that.

And you guys have billions of users and I think initially when you work on the TPU you were thinking about, you know, if everybody they use Google we use the voice model for like three minutes a day that will like you need to double your CPU number like, what's that discussion today at Google?

Like how do you prioritize frontier versus like we actually need to deploy it if we build it?

Yeah, I mean, I think we always want to have models that are at the frontier pushing the frontier because I think that's where you see what capabilities now exist that didn't exist at the sort of slightly less capable last year's version last six months ago version.

But at the same time, you know, we know those are going to be really useful for a bunch of use cases, but they're going to be a bit slower and a bit more expensive than people might like for a bunch of other broader use cases.

So I think what we want to do is always have kind of a highly capable sort of affordable model that enables a whole bunch of, you know, lower latency use cases people can use them for a gentle coding much more readily.

And then have the high end, you know, a frontier model that is really useful for, you know, deep reasoning, you know, solving really complicated math problems, those kinds of things.

And it's not that one or the other is useful, they're both useful.

So I think we'd like to do both, and also, you know, through distillation, which is a key technique for making the smaller models more capable, you know, you have to have the frontier model in order to then distill it into your smaller model.

So it's not like an either or choice, you sort of need that in order to actually get a highly capable, more modest size model.

Yeah, and I mean, you and Jeffrey and then came up with this solution in 2014.

Yeah, we're real vignals.

Yeah, long time ago, like, I'm curious how you think about the cycle of these ideas, even like, you know, sparse models and, you know, how do you re-evaluate them?

How do you think about, in the next generation of model, what is what revisiting, like a, yeah, they're just kind of like, you know, you work on so many ideas that, and they've been influential, but like, in the moment that might not feel that way necessarily.

Yeah, I mean, I think distillation was originally motivated because we were seeing that we had a very large image data set at the time.

You know, 300 million images that we could train on with, you know, I forget like 20,000 categories or something.

So much bigger than image net.

And we were seeing that if you create specialists for different subsets of the image categories, you know, this one's going to be really good at sort of mammals.

And this one's going to be really good at sort of indoor rinsions or whatever.

And you can cluster those categories and train on an enriched stream of data after you do pre-training on on a much broader set of images.

You get much better performance if you then treat that whole set of maybe 50 models we've trained as a large ensemble.

But that's not a very practical thing to serve, right?

So distillation really came about from the idea of, okay, what if we want to actually serve that and train all these independent sort of expert models.

And then squish it into something that actually fits in a form factor that you can actually serve.

And that's, you know, not that different from what we're doing today, you know, often today we're instead of having an ensemble of 50 models we're having a much larger scale model that we then distill into a much smaller scale model.

Yeah, a part of me also wonders if distillation also has a story with the RL revolution.

So let me, let me maybe try to articulate what I mean by that, which is you can, RL basically spikes models in a certain part of the distribution.

And then you have to sort of, well, you can spike models, but usually sometimes you might be lossy in other areas and it's kind of like an uneven technique, but you can probably distill it back.

And you can, I think that the sort of general dream is to be able to advance capabilities without regressing on anything else.

And I think that that whole capability merging without loss.

I feel like it's, you know, some part of that should be a distillation process, but I can't quite articulate it, I haven't seen much papers about it.

Yeah, I mean, I tend to think of one of the key advantages of distillation is that you can have a much smaller model and you can have a very large, you know, training data set and you can get utility out of making many passes over that data set.

Because you're now getting the budgets from a much larger model in order to sort of, sort of coax the right behavior out of the smaller model that you don't wouldn't otherwise get with just the hard labels.

And so, you know, I think that's what we've observed is you can get, you know, close, very close to your largest model performance with distillation approaches.

And that that seems to be, you know, a nice sweet spot for a lot of people because it enables us to kind of, for multiple Gemini generations now we've been able to make the sort of flash version of the next generation.

But as good or even substantially better than the previous generations pro, and I think we're going to keep trying to do that, because that seems like a good trend to follow.

There I ask, so the original map was flash pro and ultra is, are you just sitting on ultra and distilling from that?

Is that like the, what the load.

We have a lot of different kinds of models, some are internal ones that are not necessarily meant to be released or served.

Some are, you know, our pro scale model and we can distill from that as well into our flash scale model.

So I think, you know, it's an important set of capabilities to have and also inference time scaling can also be a useful thing to improve the capabilities of a model.

Yeah, of course, I think the economy of flash is what it's led to total dominance.

I think the latest numbers like 50 trillion tokens.

I don't know.

I mean, obviously it's changing every day.

Yeah, but, you know, by market share, hopefully up.

No, I mean, there's no, I mean, just the economics wise, like because flash is so economical, like you can use it for everything, like it's in Gmail now, it's in YouTube, like it's in everything.

We're using it more in our search products of very, yeah, I'm over views.

Oh my god, flash positive.

I'm on my god.

Yeah, that's yeah, I didn't even think about that.

I mean, I think one of the things that is quite nice about the flash model is not only is it more affordable.

It's also a lower latency.

And I think latency is actually a pretty important characteristic for these models because we're going to want models to do much more complicated things that are going to involve, you know, generating many more tokens from when you ask the model to do something until it actually finishes what you ask it to do because you're going to ask now not just write me a for loop, but like write me a whole software package to do X or Y or Z.

And so having low latency systems that can do that seem really important and flash is one direction, one one way of doing that, you know, obviously our hardware platforms enable a bunch of interesting aspects of our, you know, serving stack as well like TPUs, the interconnect between chips on the TPUs is actually quite quite high performance and quite amenable to, for example, long context kind of attention operations, you know, having sparse models with lots of experts.

These kinds of things really really matter a lot.

And in terms of how do you make them serveable at scale.

Yeah, doesn't feel like there's some breaking point for like the protoflash distillation kind of like one generation delayed.

I almost think about almost like the capability asymptote and certain tasks like the pro model today is saturated some sort of task.

So next generation that same task will be saturated at the flash price point.

And I think for most of the things that people use models for at some point the flash model and two generation will be able to do basically everything.

And how do you make a economical thought I keep pushing the pro frontier when a lot of the population will be okay with the flash model.

I'm curious how you think about that.

I mean, I think that's true if your distribution of what people are asking people over the models to do is stationary, right?

But I think what often happens is as the models become more capable people ask them to do more, right?

So I mean, I think this happens in my own usage like I used to try our models a year ago for some sort of coding task.

And it was okay at some simpler things, but wouldn't do work very well for more complicated things.

And since then we've improved dramatically on the more complicated coding tasks.

And now I'll ask it to do much more complicated things.

And I think that's true, not just a coding, but of, you know, now, you know, can you analyze all the, you know, renewable energy deployments in the world and give me a report on solar kind of deployment or whatever.

That's a very complicated, you know, more complicated task than people would have asked a year ago.

And so you are going to want or capable models to push the frontier and sub-zense of what people ask the models to do.

And that also then gives this insight into, okay, where does the word of things break down?

How can we improve the model in these particular areas in order to sort of make the next generation even better?

Are there any benchmarks or like test sets they use internally?

Because it's almost like the same benchmark to get a report every time.

And as I, all right, like 99 set of 97, like, how do you have to keep pushing the team internally to it or like this is what we're building towards?

Yeah, I mean, I think benchmarks, particularly external ones that are publicly available have their utility, but they often kind of have a lifespan of utility where they're introduced and maybe they're quite hard for current models.

You know, I like to think of the best kinds of benchmarks or ones where the initial scores are like 10 to 20 or 30% maybe, but not higher.

And then you can sort of work on improving that capability for whatever it is the benchmark that's trying to assess and get it up to like 80, 90% whatever.

I think once it hits kind of 95% or something, you get very diminishing returns from really focusing on that benchmark because it's sort of.

It's either the case that you've now achieved that capability or there's also the issue of leakage in public data or very related kind of data being being in your training data.

So we have a bunch of held out internal benchmarks that we really look at where we know that wasn't represented in the training data at all.

There are capabilities that we want the model to have that it doesn't have now and then we can work on, you know, assessing, you know, how do we make the model better at these kinds of things?

Is it we need different kind of data to train on that's more specialized for this particular kind of task do we need, you know, a bunch of, you know, architectural improvements or some sort of model capability improvements, you know, what would help make that better.

Is there, is there such an example that you've a benchmark inspired in architectural improvement?

Like, I'm just kind of jumping on that because you just.

I mean, I think some of the long context capability of the of the Gemini models that came, I guess, first in 1.5 really were about looking at, okay, we want to have, you know, everyone jumped to like completely green charts of everyone had, I was like, how did everyone correct this at the same time?

Right, yeah, I mean, I think.

And once you're sat, I mean, as you say, that new single needle in a haystack benchmark is really saturated for at least context links up to 128K or something.

I think most people don't actually have, you know, much larger than 128K these days or 256 or something.

You know, we're trying to push the frontier of 1 million or 2 million context links.

I think Google's still the leader to be in.

Yeah, which is good because I think there are a lot of use cases where, you know, putting a thousand pages of text or putting, you know, multiple, you know, our long videos and the context.

And then actually being able to make use of that as useful.

But the single needle in a haystack benchmark is sort of saturated.

So you really want more complicated sort of multi needle or more realistic.

Take all this content and produce this kind of answer from a long context that sort of better assesses what it is.

People really want to do with long context, which is not just, you know, can you tell me the product number for this particular thing?

Yeah, it's retrieval.

Yeah, it's retrieval within machine learning.

Yeah, it's interesting because, like, I think that the more meta lesson level of trying to operate out here is you have a benchmark, you're like, okay, I see the architectural thing I need to do in order to fix that.

But like, should you do it?

Because sometimes, you know, that's an inductive bias basically that you're in.

And it's a what Jason way, who used to work at Google would say, like, exactly kind of thing like, yeah, you're going to win short term longer term.

I don't know if that's going to scale.

You might have to undo that.

I mean, I like to sort of not focus on exactly what solution wouldn't should drive, but what capability would you want?

And I think we're very convinced that, you know, long context is useful, but it's way too short today, right?

Yeah, like, I think what you would really want is, can I attend to the internet?

Well, I answer my question.

But that's not going to be solved by purely scaling the existing solutions, which are quadratic.

So a million tokens kind of pushes what you can do.

You're not going to do that to a trillion tokens.

Little, you know, a billion tokens, let alone a trillion.

But I think if you could give the illusion that you can attend to trillions of tokens, that would be amazing.

You would have to find all kinds of use if that you would have attend to the internet.

You could attend to the pixels of YouTube and the sort of deeper representations that we can form for a single video, but across many videos, you know, on a personal Gemini level, you could attend to all of your personal state with your permission.

So, like, your emails, your photos, your docs, your plane tickets, you have.

I think that would be really, really useful.

And the question is, how do you get algorithmic improvements and system level improvements that get you to something where you actually can attend to trillions of tokens in some meaningful way?

Yeah.

But, by the way, I think I did some math.

And if, like, if you spoke all day, every day for eight hours a day, you only generate a maximum of like 100K tokens, which, like, very comfortably fits.

Right.

By the few, then, say, okay, I want to be able to...

I'm just playing everything in terms of putting on media access.

Well, also, I think that the classic example is, you start going beyond language into, like, proteins and whatever else is extremely information dense.

Yeah.

I mean, I think one of the things about Gemini's multimodal aspects is we've always wanted it to be multimodal from the start.

And so, you know, that sometimes, to people means text and images and videos, sort of human-like, and audio, human-like modalities.

But I think it's also really useful to have Gemini know about non-human modalities.

Yeah.

Lied our sensor data from, yes.

Yeah.

Wemmo vehicles or, like, robots, or, you know, various kinds of health modalities.

So, we've got to look for ways in MRIs and imaging and genomic separation.

And I think there's probably hundreds of modalities of data where you'd like the model to be able to, at least be exposed to the fact that this is an interesting modality and has certain meaning in the world, where even if you haven't trained on all the lighter data or MRI data, you could have, because maybe that's not, you know, it doesn't make sense in terms of trade-offs of, you know, what you include in your main pre-training data, because it makes it, at least, including a little bit if it is actually quite useful.

Yeah.

Because it sort of, uh, tempts the model that this is a thing.

Yeah.

Do you, do you believe, I mean, sensor on this topic, and something like, I just get to ask you all the questions.

I always wanted to ask you, it's fantastic.

Like, there are, there are, there are some King modalities, like, modalities that supersede all the other modalities.

So, the, as simple as I suppose, vision, um, can, on a pixel level and code text.

And deep sea can, that, that this, deep sea, because you are a paper that that, uh, vision has also been shown to maybe incorporate audio, because you can do audio spectral grants.

And that's, that's like a vision, uh, a keyboard thing.

Yeah.

So, so maybe vision is just the King modality and, like, yeah.

Yeah.

I mean, vision and motion are quite important things, right?

Motion.

Uh, well, like, the audio, as opposed to static images.

Yeah.

Because, I mean, there's a reason evolution has evolved eyes, like, 23 independent ways, because it's such a useful capability for sensing the world around you, which is really what we want these models to be able to do, is interpret the things we're seeing, or the things we're, we're paying attention to, and then help us in, uh, using that impression to do things.

Yeah.

I, I think motion, uh, you know, I still want to shout out, I think Gemini, uh, still the only native video understanding model there.

Uh, so I use it for YouTube all the time.

Uh-huh.

Nice.

Yeah.

I mean, it's actually, I think people kind of do, are not necessarily aware of what, the Gemini models can actually do with video.

Like, uh, I have an example I've used in one of my talks.

It had, like, uh, it was like a YouTube highlight video of 18 memorable sports moments across the last 20 years or something.

So it has, like, Michael Jordan hitting some jump shot at the end of the finals, and, you know, some soccer, uh, goals and things have got.

And you can literally just give it the video and say, can you please make me a table of what all these different events are, what, what the date is when they happen and a short description of the event.

And so you get, like, now on 18 row table of that information extracted from the video, which is, you know, not something most people think of as, like, a turn video into sequel like a table.

Hmm.

Has there been any discussion inside of Google of, like, you mentioned tending to the whole internet, right?

Google, it's almost built because the, a human cannot tend to the whole internet, and you need some sort of ranking to find what you need.

Yep.

That ranking is, like, much different for an LLM.

Because you, you can expect the person to look at maybe the first five, six links in a Google search, versus for an LLM, should you expect to have 20 links that are highly relevant?

Like, how, how do you, internally, figure out, you know, how do we build the AI mode that is, like, maybe, like, much broader, search and span versus, like, the more human.

Yeah, I mean, I think even pre-language model based works, you know, are ranking systems would be built to start with a giant number of web pages in our index, many of them are not relevant.

So you identify a subset of them that are relevant with very lightweight kinds of methods.

You know, you know, into, like, 30,000 documents or something.

And then you gradually refine that to apply more and more sophisticated algorithms, and more and more sophisticated sort of signals of various kinds, in order to get down to ultimately what you show, which is, you know, the final 10 results or, you know, 10 results plus other kinds of information.

And I think, in LLM based system is not going to be that dissimilar, right?

You're going to attend to trillions of tokens, but you're going to want to identify, you know, water the 30,000ish documents that, with the, you know, maybe 30 million interesting tokens.

And then how do you go from that into water the 117 documents?

I really should be paying attention to, in order to carry out the task that the user has asked me to do.

And I think, you know, you can imagine systems where you have, you know, a lot of highly parallel processing to identify those initial 30,000 candidates, maybe with very lightweight kinds of models.

Then you have some system that sort of helps you narrow it down from 30,000 to the 117, with maybe a little bit more sophisticated model or set of models.

And then maybe the final model is the thing that looks at 117 things that might be your most capable model.

So I think it has, it's going to be some system like that that is really, enables you to give the illusion of attending to trillions of tokens.

Sort of a way, Google search gives you, you know, not the illusion, but you are searching me or not, but you're finding, you know, a very small subset of things that are relevant.

Yeah, I often tell a lot of people that are not steeped in like Google search history that, well, you know, like Bert was like using basically immediately inside of Google search.

And that improves results a lot, right?

Yeah, I don't have any numbers on top of my head, but like, I'm sure you guys, that's obviously the most important numbers to Google.

Yeah, I mean, I think going to an LLM based representation of text and words and so on, enables you to get out of the explicit hard notion of particular words having to be on the page, but really getting at the notion of this topic of this page where this paragraph is highly relevant to this query.

Yeah, I don't think people understand how much elements have taken over all these very high traffic.

Yeah, like, it's Google.

It's YouTube.

YouTube has these like semantics ID thing, where it's just like every token, every item in the full cab is a YouTube video or something.

Right, it predicts the video using a code book, which is absurd to me for YouTube's size.

And then most recently, Grok also for XAI, which is like, yeah.

I mean, I'll call out even before LLMs were used extensively in search.

We put a lot of emphasis on softening the notion of what the user actually entered into the query.

So, if I do have like a history of LLMs.

Oh, yeah, I mean, I actually gave a talk in a web search and data mining conference in 2009, where we never actually published any papers about the origins of Google search, sort of, we went through sort of four, five or six generations.

Four or five or six generations of redesigning of the search and retrieval system from about 1999 through 2004 or five.

And that talk is really about that evolution.

And one of the things that really happened in 2001 was we were sort of working to scale the system in multiple dimensions.

And so one is we wanted to make our index bigger, so we could retrieve from a larger index, which always helps your quality in general.

Because if you don't have the page in your index, you're going to not do well.

And then we also needed to scale our capacity because we were, our traffic was growing quite extensively.

And so we had, you know, a started system where you have more and more shards as the index grows.

Like 30 shards, and then if you want to double the index size, you make 60 shards.

So that you can bound the latency by which you can respond for any particular user query.

And then as traffic grows, you add more and more replicas of each of those.

And so we eventually did the math that realized that in a data center where we had say 60 shards, and, you know, 20 copies of each shard, we now had 1200 machines with disks.

And we did the math and we were like, hey, one copy of that index would actually fit in memory across 1200 machines.

So in 2001, we introduced, we put our entire index in memory.

And what that enabled from a quality perspective was amazing, because before you had to be really careful about, you know, how many different terms you looked at for a query, because every one of them would involve a disc seek on every one of the 60 shards.

And so as you make your index bigger, that becomes even more inefficient.

But once you have the whole index in memory, it's totally fine to have 50 terms you throw into the query from the user's original three or four word query, because now you can add synonyms like restaurant and restaurants and cafe and bistro and all these things.

And you can suddenly start sort of really getting at the meaning of the word, as opposed to the exact semantic form, the user type 10.

And that was, you know, 2001, very much pre-LLM, but really, it was about softening the strict definition of what the user typed in order to get at the meaning.

What are like principles that you use to like design the systems, especially when you have, I mean in 2001 the internet is like doubling tripling every year in size.

It's not like a, you know, and I think today you kind of see that with LLMs too, or like every year the jumps in size and like capabilities are just something.

Are there just any, you know, principles that you use to like think about this?

Yeah, I mean, I think, you know, first whenever you're designing a system, you want to understand what of the sort of design parameters that are going to be most important in designing that, you know, how many queries per second do you need to handle, how big is the index you need to handle, how much data do you need to keep for every document of the index?

How are you going to look at it when you retrieve things?

What happens if traffic were to double or triple, you know, well, that system work well.

And I think a good design principle is you're going to want to design a system so that the most important characteristics could scale by like factors of 5 or 10, but probably not beyond that because often what happens is if you design a system for X, and something suddenly becomes a hundred X, that would enable a very different point of the design space that would not make sense at X, but all of a sudden a hundred X makes total sense.

So like going from a disk space index to a in memory index makes a lot of sense once you have enough traffic because now you have enough replicas of the sort of state on disk that those machines now actually can hold, you know, a full copy of the memory index and memory.

And that all of a sudden enables a completely different design that wouldn't have been practical before.

So I'm a big fan of thinking through designs in your head, just kind of playing with the design space a little before you actually do a lot of writing of code.

But, you know, as you said in the early days of Google, we were growing the index quite extensively.

We were growing the update rate of the index, so the update rate actually is the parameter that changed the most surprisingly.

But it used to be once a month.

Yeah.

And then we went to a system that could update any particular page in like sub one minute.

Okay.

Because this is a competitive advantage, right?

Right.

Because all of a sudden, you know, if you've got last month's news index, it's not actually that useful for new top or special B's.

Was there any, like, you could have split it on to separate system.

Wow.

We did.

We launched a global news project, but you also want news related queries that people type into the main index to also be sort of updated.

Yeah.

Yeah.

It's interesting.

And then you have to like classify whether the page is, you have to decide which pages should be updated.

And what?

Oh, yeah.

There's a whole, like, system behind the scenes that's trying to decide update rates and importance of the pages.

So even if the update rate seems low, you might still want to recall important pages quite often because the likelihood they change might be low, but the value of the app.

The update rate is high.

Yeah.

Yeah.

Yeah.

You know, this, you know, mentioned of latency and, and same thing that this reminds me of one of your classics, which I have to bring up, which is latency numbers every program you should know.

Uh-huh.

Yeah.

Was there, is there just a general story behind that?

It's really long.

Um.

I mean, this has, like, sort of eight or ten different kinds of metrics that are, like, how long does a cash mistake?

Yeah.

How long does Branchness predict day?

How long does a reference to main memory day?

Yeah.

How long does it take to send, you know, a packet from the U.S. to the Netherlands or something?

Um, I mean, the Netherlands by the way.

Or is it, is that because of Chrome?

Uh, we have a day of center in the Netherlands.

Yeah.

Um, so, I mean, I think this gets to the point of being able to do the back of the envelope calculations.

So these are sort of the raw ingredients of those.

And you can use them to say, okay, well, if I need to design a system to do image search and thumbnailing or something of the result page, you know, how, what I do that.

I could pre-compute the image thumbnails.

I could, like, try to thumbnail them on the fly from the larger images.

What would that do?

How much just bandwidth and I need, how many just seeks would I do?

Um, and you can sort of actually do thought experiments in, you know, 30 seconds or a minute with the sort of, uh, basic, uh, basic numbers that your fingertips.

And then as you sort of build software using higher level libraries, you kind of want to develop the same intuitions for how long does it take to, you know, look up something in this particular kind of hash table I use or, you know, how long will it take me to sort a million numbers or something?

Yeah.

So the reason I bring it up actually is actually for, I think, like, two years now I've been trying to make numbers every AI program I should know.

Okay.

Yeah.

Uh, I don't have a great one.

Uh, because it's, it's not, it's not physical constants like you have physical constants in here.

You know, it's, uh, and, uh, I do think, like, uh, so a simple one would be a number of parameters to, um, uh, disk size if you, if you need to convert that, uh, which is simple by conversion.

That's not, that's nothing interesting.

I wonder if you have any, if you want, if you want, if you want to update your, I mean, I think, uh, it's really good to think about, uh, calculations you're doing in a model either for training or inference.

Often a good way to view that is how much, uh, state will you need to bring in from memory either, like, on chip SRAM or HBM from the accelerator attached, uh, memory or DRAM or over the network.

Um, and then how expensive is that data motion relative to, uh, the cost of, say, an actual multiply in the matrix multiply unit.

And that cost is actually really, really low, right?

Because it's, you know, order, you know, uh, depending on your precision, I think it's, like, sub pico, one pico dual.

Oh, okay.

You measure the bandity.

Yeah.

Yeah.

I mean, it's all going to be about energy and how do you make the most energy of vision system.

Um, and then moving data from the SRAM on the other side of the chip, not even off the off chip, but on the other side of the same chip can be, you know, 1,000 pico duals.

Oh.

Yeah.

And so all of a sudden, this is why your accelerators require batching, because if you move, like, say, the parameter of a model from SRAM on, on the chip into the multiplier unit, that's going to cost you 1,000 pico duals.

So you better make use of that, that thing that you moved many, many times, which, so that's where the batch dimension comes in, because all of a sudden, you know, if you have a batch of 256 or something, that's not so bad.

But if you have a batch of one, that's really not good.

Yeah.

Right.

Because then you paid 1,000 pico duals in order to do your 1 pico dual multiple.

I have never heard an energy based analysis of batching.

Yeah.

I mean, that's why people batch.

Yeah.

Ideally, you'd like to use that for like one, because the latency would be great, but the energy cost and the compute cost inefficiency that you get, is quite large.

So, yeah.

Is there so much trick like, like, like you did with, you know, putting everything in memory, like, you know, I think obviously Nvidia has caused a lot of ways with, betting very hard on SRAM with grok.

I wonder if like, that's something that you already saw with the TPU, right, like that, that you had to, to serve at your scale, you probably saw that coming.

Like, what, what hardware innovations or insights were formed because of what you're seeing there.

Yeah.

I mean, I think, you know, TPUs have this nice sort of regular structure of 2D or 3D meshes with a bunch of chips connected.

Yeah.

And each one of those has HBM attached.

I think for serving some kinds of models, you know, you, you pay a lot higher cost and time, latency, bringing things in from HBM.

And you do bring them in from SRAM on the chip.

So, if you have a small amount of model, you can actually do model parallelism spread it out over lots of chips.

And you actually get quite good throughput improvements and latency improvements from doing that.

And so, you're now sort of striping your smaller scale model over, say, 16 or 64 chips.

But if you do that and it all fits in SRAM, that can be a big win.

So, yeah, that's not a surprise, but it is a good technique.

Yeah.

But what about the TPU design?

Like, how much do you decide where the improvements have to go?

So, like, this is like a good example.

Like, is there a way to bring the 1000 pixel joules down to 50?

Like, is it worth designing a new chip to do that?

The extremist, like, when people say, oh, you should burn the model on the A-sick and that's kind of like the most extreme thing.

How much of it is it we're doing in hardware when things change so quickly?

Like, what's the internal discussion?

Yeah, I mean, we have a lot of interaction between, say, the TPU chip design, architecture team, and the sort of higher level modeling experts.

Because we really want to take advantage of being able to co-design what should future TPUs look like based on where we think the sort of ML research puck is going.

In some sense, because, you know, as a hardware designer for ML, in particular, you're trying to design a chip starting today and that design might take two years before it even lands in a data center and then it has to sort of be a reasonable lifetime of the chip to take you three, four, or five years.

So, you're trying to predict two to six years out where what ML computations will people want to run two to six years out in a very fast changing field.

And so, having people with interesting ML research ideas of things we think will start to work in that time frame or will be more important in that time frame really enables us to then get, you know, interesting hardware features put into, you know, TPU and plus two, where TPU and is what we have today or the cycle time is plus two.

Roughly, wow.

Because, I mean, sometimes you can squeeze some changes into n plus one, but, you know, bigger changes are going to require the chip design be earlier in its lifetime design process.

So, whenever we can do that, it's generally good.

And sometimes you can put in speculative features that maybe won't cost you much chip area, but if it works out, it would make something, you know, ten times as fast.

And if it doesn't work out, well, you burned a little bit of tiny amount of your chip area on that thing, but it's not that big of deal.

Sometimes it's a very big change and we want to be pretty sure this is going to work out.

So, we'll do, like, lots of careful ML experimentation to show us this is actually the way we want to go.

Yeah.

Is there a reverse of, like, we already committed to this chip design so we can not take the model architecture that way, because it doesn't quite fit.

Yeah.

I mean, you definitely have things where you're going to adapt what the model architecture looks like, so that they're efficient on the chips that you're going to have for both training and inference of that, of that generation of model.

So, I think it kind of goes both ways.

You know, sometimes you can take advantage of, you know, lower precision things that are coming in future generations, but you can might train it at that lower precision, even if the current generation doesn't quite do that.

Yeah.

I'll look and we go in precision.

Because people are saying, like, Turnery is, like, yeah, I mean, I'm a big fan of very low precision, because I think that saves you a tremendous amount of energy, right?

Because it's pickled jewels per bit that you're transferring, and reducing the number of bits is a really good way to reduce that.

You know, I think people have gotten a lot of, a lot of myelage out of having very low bit precision things, but then having scaling factors that apply to a whole bunch of those weights.

It's killing, it's okay.

Interesting.

So low, low precision, but scale that weights.

Yeah.

Yeah.

They were considered that.

Interesting.

While we're on this topic, you know, I think there's a lot of, this is the concept of precision at all, is weird when we're sampling.

You know, like, we just, at the end of this, we're going to have all these chips that I'll do, like, very good math, and then we're just going to throw a random number generated at the start.

So, I mean, there's a movement towards energy-based models and plus processors.

Yeah.

I'm just curious if you, obviously, you've thought about it, but like, what's your commentary?

Yeah.

I mean, I think there's a bunch of interesting trends, so energy-based models, there's one, you know, diffusion-based models, which don't sort of sequentially decode tokens, there's another, you know, speculative decoding is a way that you can get sort of an equivalent, very small draft batch factor for, like you predict date tokens out, and that enables you to sort of increase the effective batch size of what you're doing by a vector of eight, even, and then you maybe accept five or six of those tokens, so you get five X improvement in the amortization of moving weights into the multipliers to do the prediction for the tokens.

So, these are all really good techniques, and I think it's really good to look at them from the lens of energy, real energy, not energy-based models, and also latency and throughput.

Right?

If you look at things from that lens, that sort of guides you to solutions that are going to be, you know, better from, you know, being able to serve larger models, or, you know, equivalent size models more cheaply, and with our latency.

Yeah.

Well, I think it's appealing intellectually, haven't seen it, like, really hit the mainstream, but I do think that there's some poetry in the sense that, you know, we don't have to do a lot of shenanigans if, like, we fundamentally design it into the hardware.

Yeah.

I mean, I think there's still, like, there's also sort of the more exotic things, like analog-based computing substrates, as opposed to digital ones.

You know, I think those are super interesting because they can be potentially low-power, but I think you often end up wanting to interface that with digital systems, and you end up losing a lot of the power advantages in the digital to analog and analog digital conversions you end up doing at the sort of boundaries and periphery of that system.

I still think there's a tremendous distance we can go from where we are today in terms of energy efficiency.

We have sort of much better and specialized hardware for the models we care about.

Yeah.

Any other interesting research ideas that you've seen or, like, maybe things that you cannot pursue a Google that you would be interested in seeing researchers.

Take a step at.

I guess you have a lot of researchers.

I guess you have a lot of life.

Our research portfolio is pretty broad, I would say.

I mean, I think in terms of research directions, there's a whole bunch of, you know, open problems and how do you make these models reliable and able to do much longer, kind of, more complex tasks that have lots of sub tasks, how do you orchestrate, you know, or maybe one model that's using other models as tools in order to sort of build things that can accomplish, you know, much more significant pieces of work collectively than you would ask a single model to do.

So that's super interesting.

How do you get more verifiable, you know, how do you get our L to work for non-verifiable domains?

I think it's a pretty interesting open problem because I think that would broaden out the capabilities of the models, the improvements that you're seeing in both math and coding, if we can apply those to other less verifiable domains because we've come up with our L techniques that actually enable us to do that effectively.

That would really make the models improve quite a lot of things.

I'm curious, like when we had no one Brown on the podcast he said, they already proved you can do it with the research.

You kind of have it with AI mode in a way.

It's not verifiable.

I'm curious if there's any thread that you think is interesting there.

Like, both are like information retrieval of Jason.

So I wonder if it's like the retrieval is like the verifiable part that you can score or what are like, yeah, how would you model that problem?

Yeah, I mean, I think there are ways of having other models that can evaluate the results of what a first model did.

Maybe I'm retrieving.

Can you have another model that says is this things are these things you retrieved relevant or can you rate these two thousand things you retrieved to assess which ones are the 50 most relevant or something?

I think those kinds of techniques are actually quite effective.

Sometimes I can even be the same model just prompted differently to be a critic as opposed to a actual retrieval system.

Yeah.

I do think there is that weird cliffware.

It feels like we've done the easy stuff.

But it always feels like that.

Every year it's like, oh, like, we know, and the next part is super hard and nobody's figured it out.

Like the way exactly with this ROVR thing, where like everyone's talking about, well, how do we do the next stage of the non-verifiable stuff?

It sounds like, I don't know, you know, that little judge.

I feel like the nice thing about this field is there's lots and lots of smart people thinking about creative solutions to some of the problems that we all see.

Because I think everyone sort of sees that the models are great at somethings and they fall down around the edges of those things and are not as capable as we'd like in those areas.

And then coming up with a good techniques and trying those and seeing which ones actually make a difference is sort of what the whole research aspect of this field is pushing forward.

And I think that's why it's super interesting.

If you think it back two years ago, we were struggling with GSMA K-Problems, right?

Like Fred has two rabbits.

He gets three more rabbits, how many rabbits do they have?

That's a pretty far cry from the kinds of mathematics that the models can annihilate.

I'm old.

I'm old.

I'm old.

You're language.

Yeah.

Pure language.

So that is a really, really amazing jump in capabilities in, you know, one year and a half or something.

And I think for other areas, it'd be great if we could make that kind of leap.

And, you know, we don't exactly see how to do it for some areas, but we do see it for some other areas and we're going to work hard on making that better.

Yeah.

Yeah.

Like YouTube thumbnail generation.

That would be really helpful.

We need that.

That would be H-I.

We need a part of that.

As far as content.

I guess I'm not a YouTube creator.

So I don't care that much about that problem.

But I guess many people do.

Yeah.

It doesn't matter.

People do judge books by their covers.

It turns out.

Just draw a bit on the I'm old gold.

I'm still not over the fact that a year ago, we had Alpha Proof and Alpha Geometry and all those things.

And then this year we were like, school that we're just chucking into the Gemini.

Yeah.

What's your reflection?

I think this question about the merger of symbolic systems and LMS was a very much core belief.

And then somewhere along the line, people would just say, nope, we'll just all do it in the LMS.

Yeah.

I mean, I think it makes a lot of sense to me, because, you know, humans manipulate symbols, but we probably don't have like a symbolic representation in our heads.

We have some distributed representation that is neural net, like in some way, of lots of different neurons, and activation patterns firing when we see certain things.

And that enables us to reason in plan and, you know, do chains of thought and, you know, roll them back, know that approach for solving the problem.

Doesn't seem like it's going to work.

I'm going to try this one.

And, you know, in a lot of ways we're emulating what we intuitively think is happening inside real brains in neural net based models.

So it never made sense to me to have like completely separate, discrete symbolic things, and then a completely different way of thinking about those things.

Interesting.

Yeah.

I mean, it's, maybe seems obvious to you, but it wasn't obvious to me that year ago.

Yeah, I mean, I do think like that.

IMO with, you know, translating the lean and using lean, and then the next year, and also a specialized geometry model, and then this year switching to a single unified model that is, roughly the production model with a little bit more inference budget, is actually, you know, quite good, because it shows you that the capabilities of that general model, yeah, have improved dramatically, and now you don't need the specialized model.

This is actually sort of very similar to the 2013 to 16 era of machine learning, right, like it used to be people with trained separate models for lots of different, each different problem.

Right, I have, I want to recognize street signs and something, so I train a street sign, recognition model, or I want to decode speech recognition.

I have a speech model, right?

I think now the, her of unified models, the do everything is really upon us, and the question is, how well do the models generalize to new things they've never been asked to do, and they're getting better and better.

You don't need domain experts, like one might, so I interviewed ET, who was on that team, and he was like, yeah, I don't know how they work, I don't know where the IMO competition was held, I don't know the rules of it, I just train the models with a training model, so yeah.

Yeah, and it's kind of interesting that like, people with these, this like universal school set of just machine learning, you just give them data and give them, enough computing and they can kind of tackle any task, which is, yeah, right.

The video lesson, I guess, I don't know.

Yeah, I mean, I think general models, will we now offer specialized ones in most cases?

Yeah, so I want to push there a bit, I think there's one hole here, which is like, there's this concept of like maybe capacity of a model, like abstractly a model can only contain the number of bits that it has, and so it, you know, God knows like Gemma Pro is like one to 10 trillion parameters, we don't know, but the Gemma models, for example, right?

People want the open source local models that are like that, and they have some knowledge, which is not necessary, right?

They can't know everything.

Like you have the luxury of you have the big model, and big model should be able to capable of everything.

But like when you're distilling and you're going down to the small models, you know, you're actually memorizing things that are not useful.

Yeah, and so like, how do we, I guess, do we want to extract that?

Can we, can we divorce knowledge from reasoning?

Yeah, I mean, I think you do want the model to be most effective at reasoning if it can retrieve things, right?

Because having the model devote precious parameter space to remembering obscure facts that could be looked up is actually not the best use of that parameter space, right?

Like you might prefer something that is more generally useful in more settings than this obscure fact that it has.

So I think that's always attention.

At the same time, you also don't want your model to be kind of completely detached from, you know, knowing stuff about the world, right?

Like it's probably useful to know how long the Golden Gate Bridges just as a general sense of like how long or bridges, right?

And it should have that kind of knowledge.

It maybe doesn't need to know how long some teeny little bridge in some other more obscure part of the world is.

But it does help it to have a fair bit of world knowledge and the bigger your model is, the more you can have.

But I do think combining retrieval with sort of reasoning and making the model really good at doing multiple stages of retrieval and reasoning through the intermediate retrieval results is going to be a pretty effective way of making the model seem much more capable.

Because if you think about, say, a personal Gemini, right, like we're not going to train Gemini on my email, probably we'd rather have a single model that we can then use and use being able to retrieve from that email as a tool and have the model reason about it and retrieve from my photos or whatever.

And then make use of that and have multiple stages of interaction.

Do you think the vertical models are like interesting pursuit like when people are like, oh, we're building the best health care, we're building the best law, LLM, are those kind of like short-term stop gaps or?

No, I mean, I think vertical models are interesting.

Like you want them to start from a pretty good base model, but then you can sort of, I sort of viewing them as enriching the data distribution for that particular vertical domain for health care, say, we're probably not going to train or for, say, robotics.

We're probably not going to train Gemini on all possible robotics data.

You could train it on because we wanted to have a balance set of capabilities.

So we'll expose it to some robotics data.

But if you're trying to build a really, really good robotics model, you're going to want to start with that and then train it on more robotics data.

And then maybe that would hurt its multi-lingual translation capability, but improve its robotics capabilities.

And we're always making these kind of trade-offs in the data mix that we train the base Gemini models on.

You know, we'd love to include data from 200 more languages and as much data as we have for those languages.

But that's going to displace some other capabilities of the model.

It won't be as good at, you know, pearl programming.

You know, it'll still be good at Python programming, because we'll include enough of that, but there's other long-tail computer languages or coding capabilities that it may suffer on, or multi-multi-modal reasoning capabilities may suffer because we didn't get to expose it to as much data there, but it's really good at multi-lingual things.

So I think some combination of specialized models may be more modular models.

So it'd be nice to have the capability to have those 200 languages, plus this awesome robotics model, plus this awesome healthcare module, that all can be knitted together to work in concert and call the pun in different circumstances, right?

Like if I have a health-related thing, then it should enable using this health module in conjunction with the main base model to be even better at those kinds of things.

Yeah.

It's installable and knowledge.

Yeah.

It's download.

And some of that installable stuff can come from retrieval, but some of it probably should come from training on, you know, 100 billion tokens or trillion tokens of health data.

Yeah.

And for listeners, I think I would have like the Gemma 3N paper, where there's a little bit of that.

Yeah.

Yeah, I guess the question is, how many billions of tokens do you need to outpace the front-tier model improvements?

You know, it's like if I have to make this model better at healthcare and the main Gemma I model is still improving, do I need 50 billion tokens?

Can I do it with Andre?

If I need a trillion healthcare tokens, they're probably not out there that you don't have.

You know, I think that's really like the...

Well, I mean, I think healthcare is a particularly challenging domain.

Right.

So there's a lot of healthcare data that, you know, we don't have access to it appropriately, but there's a lot of, you know, healthcare organizations that want to train models on their own data that is not public healthcare data.

Not public health, but public healthcare data.

So I think there are opportunities there to say partner with a large healthcare organization and train models for their use that are going to be, you know, more bespoke, but probably might be better than a general model train on say public data.

Yeah, I believe, but anyway, this is like someone related to the language conversation.

I think one of your favorite examples was you can put a low resource language in the context and it just learns in context.

Oh yeah.

I think the example we used was Kalamong, which is truly low resource because it's only spoken by, I think, 120 people in the world and there's no written text.

Yeah.

Yeah.

So you can just do it that way just to get in the context.

Yeah.

Yeah.

But I think you'll hold data set in the context.

If you take a language like, you know, Somali or something.

There is a fair bit of Somali text in the world that, or if you open it and park or something, you know, we probably are not putting all the data from those languages into the Gemini-based training.

We put some of it.

But if you put more of it, you'll improve the capabilities of those models.

Yeah.

Or of those languages.

Yeah.

Cool.

It's a, I have a side interest in linguistics.

I did a few classes in back in college and I, part of me, like, if I was a linguist and I could have access to all these models.

I would just be asking really fundamental questions about language itself.

Like, one is, there's one very obvious one which is superior war.

Like, how much does the language that you speak of actually thinking.

But then also, there's some languages where there's just concepts that are not represented in other languages.

But so, others, many others that are just duplicates, right, where there's also another paper that people love called the platonic representation, where, you know, like, the, an image of a cup is, if you learn a model on that and you, you, you have a lot of text with the word cup.

It eventually maps to, like, roughly the same place of lean space.

And so, like, that should apply to languages, except where it doesn't.

And that's actually, like, very interesting differences in what humanity has discovered as concepts, that maybe English doesn't have.

I don't know.

It's just, like, my rant on languages.

Yeah, I, I did some work on a early model that fused together a language-based model, with you have, you know, nice word-based representations.

And then an image model where you have trained it on image-net-like things.

Yes.

And then you fused together the top layers of the go.

No, this is devised device.

The, you do a little bit more training to fused together those representations.

What you found was that if you give a novel image that is not in any of the categories in the image model that was trained on, the model can often assigns kind of the right, the right label to that image.

So, for example, I think telescope and binoculars were both in the training categories for the image model, but microscope is not.

And so, if you give an image of microscope, it actually can come up with something that's got the word microscope as a label that are designed.

Even though it's never actually seen an image labeled that.

Oh, that's nice.

That's kind of cool.

Yeah.

So, yeah.

useful.

Cool.

I think there's more general, like, broad questions.

But, like, I guess what, what do you wish you were asked more in general?

Like, you know, you, you have such broad scope.

We've covered the hard way.

We've covered the models research.

Yeah.

I mean, I think, one thing that's kind of interesting is, you know, I did a undergrad thesis on neural network training, a parallel neural network training back in 1990 when I got exposed to neural nets.

And I always felt kind of they were the right abstraction, but we just needed way more compute than we had then.

So, like, the 32 processors in the department parallel computer, you know, could get you a little bit more interesting model, but not enough to solve real problems.

And so, starting in 2008 or nine, you know, the world started to have enough computing power through Moore's Law and, you know, larger, interesting datasets to train on to actually, you know, start training neural nets that could tackle real problems that people cared about, speech recognition, vision, and eventually, language.

And so, when I started working on neural nets at Google in late 2011, you know, I really just felt like we should scale up the size of neural networks we can train using, you know, large amounts of parallel computation.

And so, I actually revived some ideas from my undergrad thesis where I'd done both model parallel and data parallel training and it compared them.

I called them something different.

There was like pattern partitioned and, you know, model partitioned or something.

We'll have to get it.

Is it public?

Yeah, it's on the web.

Okay.

But, you know, I think combining a lot of those techniques and really just trying to push on scaling things up over the last, you know, 15 years has been, you know, really important.

And that means, you know, improvements in the hardware.

So, you know, pushing on building specialized hardware like GPUs.

It also means, you know, pushing on software abstraction layers to let people express ML ideas effectively.

And then also working on things like, say, sparse models.

I've felt for a long time that sort of sparsely activated models are a really important thing because you want the models to have a lot of capacity to our earlier discussion about remembering a lot of stuff.

Yeah.

But you also want to be super efficient in how you activate your model.

So, like, you know, trailing on the parameters, but activate only, you know, 1% or 5% or 10% of that.

And that, you know, we did early paper on this where we really scaled up, you know, outrageously large, you know, let works.

That was the title.

Yeah.

I think that's known as wording in this title into the good catchy title.

I mean, in 2017, he was out there talking about winter the parameter model.

Yes.

Yeah.

So, that is really good because that gave you, like, a 10x improvement in, you know, time to quality or compute cost to quality level relative to non-spars models.

Transformers similarly gave you a 10x to 100x improvement in, you know, compute cost to a given quality level versus, say, all the stems at the time.

And all of those things multiply together.

So, I think all those things really are important to work on.

You know, the hardware, the systems infrastructure, the, you know, algorithmic aspects of model architecture, improving the data, you know, improving the RL recipes, all these things are what are stacking together and multiplying together to give this models of 2020-26 are much more better than models of 25 and are awesome, we better than 24 and 23 and 22.

And the huge, honestly, like, organizational challenge.

Like, it's like a thousand people or maybe more.

I know when the first Japanese people came out, it was like a thousand of co-authors.

Yeah.

We have 10 pages of co-authors in here.

I'm a techer part.

Well, it was nice.

I mean, you know, people want to be acknowledged.

Yeah.

Yeah.

I mean, I think it's perfectly good to have actually a lot of co-authors.

And I do think organizing that number of people so that they're effectively pushing in common directions at all.

All their work actually sort of multiplies together in the ultimate output, which is, you know, the next generation of model is actually pretty tricky.

And we have awesome people throughout the German I team to help orchestrate this.

So, you know, myself, nom, and RL are sort of helping steer this.

And then we have people thinking about, you know, what is the pre-training set-up look like?

What is the infrastructure look like?

What is the post-training recipe look like?

And what is the data preparation of owls?

And, you know, multi-modal capabilities and ITN capabilities.

You know, there's a lot of different kinds of areas.

Coding capabilities, all these areas are, are super important.

And it's really good to have people paying close attention to those things.

And then also paying close attention to all the other things.

Yeah.

I'm told Sergey is very actively back in very, very much involved in coding stuff.

Yep.

Yeah.

Yeah.

We all use the same micro kitchen.

Yeah.

Oh, okay.

There's so many of them jump off.

So, by the way, I found out from the recent, I mean, you've probably told this story a few times, but apparently Google Brain was also started in a micro kitchen.

Yeah.

Yeah.

There's like your micro kitchen's very important.

Yeah.

I don't know if people, like, understand.

Yeah.

Yeah.

I actually bumped into Andrew Eng, who's a Stanford faculty member.

And I knew him from, I'd given talks at Stanford a couple years before.

So I sort of knew him and I'm like, oh, what are you doing here?

He's like, oh, I'm not sure yet.

I just started a couple weeks ago.

I'm going to spend one day a week here consulting.

I'm not sure what I'm working on, but my students at Stanford are starting to get good results on using neural nets for speech recognition.

I'm like, oh, neural nets, I like neural nets.

Like, I remember back to my 90 night before these was, yeah.

I'm like, oh, if that sounds interesting we should train really, really big neural nets, so that was we should, you say that.

It's a very interesting first instinct which is not we should go to set up a lot.

Yeah.

Well, I mean, I felt like Google has had lots of computational capability, and so if they were seeing good results on, what were effectively effectively single GPU or models, you know, if we were, we actually didn't have GPUs in our data centers, then we didn't have any accelerators, we had lots of CPUs, but, you know, we could build a software system that would enable you to distribute with both model parallelism and data parallelism across lots of computers, and we ended up training a pretty big model of 50x bigger than any previous neural net, as far as we could tell.

So it's two billion parameters, vision model, trained on 16,000 CPU cores for like multiple weeks, and that's what gave us really good, it would give us a 70% relative error improvement in image net, 22k, which is the 22,000 category thing, and that's how we really saw, okay, scaling this up, actually matters, we didn't write a, you know, sophisticated scaling analysis, but we had a, a saying, bigger model, more data better results, and that was our, just our mantra for like six or seven years of scaling, and every time we did that, we saw better results in speech and language and vision.

Speaking of bets, and this might, in this, you know, our preference with like this might be a little bit more sensitive topic, but you have, obviously, a lot of opinions about this.

We had a previous guest David Luan, who used to work for you, and he kind of like blames almost, the brain marketplace, as like the reason that Google didn't invest enough in language models, and I wonder if that's something you would agree with at the time or is there like a different sort of post-mortem?

The brain marketplace for, for two quarters, compute quarters, where basically he was like, okay, David worked at OpenAI, it's VP Engine, then he worked at Google.

He was like, fundamentally, OpenAI was willing to go all in, like, that's the farm on one thing, whereas Google was more democratic, like, everyone had a, had a quota, and I was like, okay, like, if you believe in scaling as an important thing, that's an important, organizational, wide decision to do.

Yeah, yeah, I mean, I think, I would somewhat agree with that.

I mean, I think I actually wrote a one-page memo saying we were being stupid by fragmenting our resources.

So in particular, at the time we had, you know, efforts within Google Research on, and in the brain team, in particular, on large language models, we also had efforts on multimodal models in other parts of brain and Google Research, and then legacy DeepMind had efforts, like, Ginchilla models and flamingo models.

And so really, we were fragmenting not only our compute across those separate efforts, but also our best people and our best ideas, right?

And so I said, this is just stupid, why don't we combine things and have one effort to train?

This is the merge.

Yeah, to train an awesome single unified model that is multimodal from the start.

That's good at everything.

And that was the origin of the Gemini effort.

And my one-page memo worked, which is good.

Did you have the name?

Because I also, for those who don't know, you named Gemini.

I did.

There was another name proposed, and I said, you know, it's sort of like these two organizations really are like twins in some sense, coming together.

So I kind of like that.

And then there's also the NASA interpretation of, you know, the early Gemini project, being an important thing on your way to, you know, the Apollo project.

So it seemed like a good name.

Twins coming together.

Right.

Yeah, nice.

I don't, we're ready running out of time, but I'm curious how you use here today to code.

So I mean, you're probably one of the most prolific engineers in the history of computer science.

I was really on through the article about UN Sungeise friendship and how you work together.

And you have one quote about, you need to find someone that you're going to pair program with who's compatible with your way of thinking so that the two of you together are a complementary force.

And I was thinking about how you think about coding agents in this, like how do you coding agents to be compatible with your way of thinking?

Like how would you rate the tools today like where should things go?

Yeah.

I mean, first, I think the coding tools are, you know, getting vastly better compared to where they were two or two years ago.

So now you can actually rely on them to do more complex things that you as a, as a software engineer, want to accomplish, and you can sort of delegate, you know, pretty complex things to these tools.

And I think one really nice aspect about the interaction between a human software engineer and a coding model that they're working with is your way of talking to that coding model actually sort of dictates how it interacts with you, right?

Like you could ask it, please write a bunch of good tests for this.

You could ask it, please help me brainstorm performance ideas, and your way of doing that is going to shape how the model responds, what kinds of problems it tackles, you know, how much do you want the model to go off and do things that are larger and more independent versus interact with it more to make sure that you're shaping the right kinds of things.

And I think it's not the case that any one style is the right thing for everything, right?

Like some kinds of problems you actually want maybe a more frequent interactions style with a model.

And other ones, you're just like, yeah, please just go right this because I know I need this thing.

I can specify it well enough and go off and do it and come back when you're done.

And so I do think there's going to be more of a style of having lots of independent software agents off doing things on your behalf and figuring out the right sort of human computer interaction model in UI and so on for when should it interrupt you and say, hey, I need a little more guidance here, or I've done this thing.

Now what should I do?

I think we're not at the end all answer to that question and that's the models get better that set of decisions you put into how the interaction should happen, make, make change, right?

Like if you, if you have a team of 50 interns, how would you manage that if they were people?

And I think it's not.

Do you want 50 interns?

You might if they're really good, right?

It's a lot of management, but it's a lot of yeah, I mean, I think that is probably within the realm of possibilities that lots of people could have 50 interns.

And so how would you actually deal with that as a person, right?

Thank you, probably want them to form small sub teams so you don't have to interact with 50 of them, you can interact with five of those teams and they're all doing things on your behalf.

But I don't know exactly what the how this is going to unfold.

How do you think about bringing people like the pair programming is always helpful to like get net new ideas in the distribution, so to speak.

It feels as we have more of these coding engines, right?

The code, it's hard to bring other people into the problem.

Say you go to like, you know, you have 50 interns, right?

And then you want to go to Nomshizir, you know, I'm like, I want to like pair on this thing.

But now there's like this huge amount of work that has been done in parallel that you need to catch him up on.

Right.

And I'm curious like if people are going to be in a way more isolated and their teams, where it's like okay, there's so much context in these 50 interns that it's just hard for me to like relay everything back to you.

Maybe, I mean, on the other hand, like imagine a classical software organization without any AI assisted tools, right?

You would have, you know, 50 people doing stuff and their interaction style is going to be naturally very hierarchical because, you know, these 50 people are going to be working.

This part of the system and not interact that much with these other people over here.

But if you have, you know, five people each managing 50 virtual agents, you know, they might be able to actually have much higher bandwidth communication among the five people.

And then you would have among five people who were also trying to coordinate, you know, 50 persons off-working each.

So I'm curious how you change your just working rhythm, you know, like you spend more time ahead with people going through his packs and design goals.

Like, um, I mean, I do think it's interesting that, you know, whenever people were taught how to write software, they were taught that it's really important to write specifications super clearly.

But no one really believed that.

Like, it was like, yeah, whatever.

I don't need to do that.

I'm gonna really, I don't know.

I mean, writing the English language specification was never kind of an artifact that was really paid a lot of attention to.

I mean, it was important.

But it wasn't sort of the thing that drove the actual creative process quite as much as if you specify what software you want the agent to write for you.

You'd better be pretty darn careful of in how you specify that because that's going to dictate the quality of the output, right?

Like, if you don't cover that it needs to handle this kind of thing or that this is a super important corner case or that, you know, you really care about the performance of this part of it, you know, it may not do what you want.

And the better you get at interacting with these models, and I think one of the ways people will get better is that they will get really good at crispy, specifying things rather than leaving things to ambiguity.

And that is actually probably not a bad thing.

It's not a bad skill to have regardless of whether you're a software engineer or a, you know, trying to do some other kind of task, you know, being able to crisp please specify what it is you want.

It's going to be really important.

Yeah, my joke is, you know, good prompting is indistinguishable from sufficiently advanced executive communication, like it's like writing an internal memo, like, yeah, yeah, way your words very carefully.

And also I think very important to be multi-model, right?

I think one thing that Antigravity from Google also did was like just come out the gate to very, very strong multimodal including videos.

And that's the highest bandwidth communication prompt that you can give the model, which is fantastic.

How do you collect things that you often, you will have in your mind?

So you have those amazing, like, performance sense, thing that you've heard about, how to look for performance improvements, and is there a lot more value and, like, people writing these, like, generic things down so that they can then put them back as, like, potential retrieval artifacts for the model.

Like, or do I have, like, the edge cases, it's like a good example, right?

It's like, if you're building systems, you're already having your mind specific edge cases depending on it.

But now you have to, like, every time repeat it.

Like, are you having people spend a lot more time writing out more generic things to bring back?

I mean, I do think well written guides of how to do good software engineering are going to be useful because they can be used as input to models or, you know, read by other developers so that their prompts are, you know, more clear about what the underlying software system should be doing.

You know, I think it may not be that you need to create a custom one for every situation.

If you have general guides and put those into, you know, the context of a coding agent that can be helpful, like, and you can imagine one for distributed systems.

You could say, okay, think about failures of these kinds of things and these are some techniques you can deal failures.

You know, you can have, you know, packs of like replication or, you know, you can send the request to two places and tolerate failure because you only need one of them to come back.

You know, a little description of 20 techniques like that in building distributed systems, probably we go a long way to having a coding agent be able to sort of cobble up more reliable and robust distributed systems.

Yeah, I wonder when Jim and I will be able to build Spanner.

Right.

Probably already has the code inside and I don't know.

Yeah, that, I mean, that's a good example, right when you have like, you know, the cap theorem and it's like, well, this is like, truth.

And you cannot break that and then you build something that broke it.

Like, I'm curious, like, models in OER, like, would he say he broke it?

Did you do this at your broke cap theorem?

Really?

Yeah, okay.

All right.

I mean, under local assumptions.

Yeah, under some of the something they're like, you know, well, but it's like sometimes you don't have to, like, always follow what is known to be through.

And I think models in a way, like, if you tell them something that like really buy into that, you know?

Yeah.

So yeah, just more thinking than any answer on how to fix it.

Yeah.

My, you know, it's just on this, like, big prompting and iteration, you know, I think that coming back to your latency point, I always try to, one, one AB test or experiment or benchmark or research, I would like, is what is the performance difference between, let's say, three dumb, fast model calls with human alignment, because the human will correct human alignment between human, human looks at the first one.

Exactly.

Human is a new prompt for the second one.

Correct.

Okay.

As opposed to, like, you spec it up, you know, it's been a long time writing is a big, big, big that prompt, and then you have a very smart model do it.

Right.

Right.

Right.

You know, because really is, is our lacks in performance, an issue of, like, well, you just haven't specified well enough.

There's no universe in which I can produce what you want, because you just haven't told me it's under specified, so I could produce ten different things and only one of them is the thing you wanted.

Yeah.

And the multi-turn taking the flash model is enough.

Yeah.

Yeah.

I'm, I'm a big believer in pushing on latency, because I think being able to have really low latency interactions with a system you're using is just much more delightful than something that is, you know, 10 times a slow or 20 times a slow.

And I think, you know, in the future, we'll see models that are and underlying software and hardware systems that are 20x lower latency than what we have today, 50x lower latency.

And that's going to be really, really important for systems that need to do a lot of stuff between your interaction.

Yeah.

Yeah.

Yeah.

This two extremes, right.

And then meanwhile, you also have B-think, which is on all the way on the other side.

Right.

But you would use deep-think all the time if it weren't for cost latency.

Right.

If, if you could have that capability in a model, because the latency improvement was 20x in the underlying hardware and system and costs, you know, there's no reason you wouldn't want that.

Yeah.

But at the same time, then you'd probably have a model that is even better that would take you 20 times longer, even on that new hardware.

Yeah.

You know, that there's the freedom curve keeps climbing.

Yeah.

Onward and outward.

Onward and outward.

Yeah.

So we ask him for predictions to go.

I don't know if you have any predictions that you like to keep.

You know, like, one way to do this is you have your tests whenever a new model comes out that run.

What's something that you're not quite happy with yet that you think will get done soon.

Um, let me make two predictions that are not quite in that vein.

Yeah.

So I think a personalized model that knows you and knows all your state and is able to retrieve over all state you have access to that you opt into is going to be incredibly useful compared to a more generic model that doesn't have access to that.

So like, can something attend to everything I've ever seen every email, every photo, every video I've watched, that's going to be really useful.

I think more and more specialized hardware is going to enable much lower latency models and much more capable models for affordable prices than say the current current status quo.

That's going to be also quite important.

Yeah.

When you say much lower latency, people usually talk in tokens per second.

Is that a term that is okay.

Okay.

You know, we're at, let's say a hundred now.

We can go to the thousands.

Is it meaningful to go 10,000?

Yes.

Really.

Okay.

Absolutely.

Right.

Yeah.

Because of chain of thought and chain of thought reasoning.

I mean, you could think, you know, many more tokens.

You could do many more parallel rollouts.

You could generate way more code and check that the code is cracked with chain of thought reasoning.

So I think, you know, being able to do that at 10,000 token per second would be awesome.

Yeah.

At 10,000 tokens per second, you are no longer reading code.

Yeah.

Like, you will just generate it.

You'll, there's not a whole member of right now.

You may not end up with 10,000 tokens of code.

Yeah.

It may be a thousand tokens of code that with nine thousand tokens of reasoning behind it.

Yeah.

Which would actually be probably much better code to read.

Yeah.

Yeah.

If I have more time, I wouldn't break it.

I'm sure later.

Yeah.

Yeah.

Awesome Jeff.

This was amazing.

Thanks a lot.

Yeah.

Thank you.

Such an honor.

It's been fun.

Thanks for having me.