Owning the AI Pareto Frontier — Jeff Dean

Thank you. Thank you. Pareto frontiers are good, and it's good to be out there.

Yeah. 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 stack And all of those really combine to help make us able to make highly capable large models, as well as software techniques to get those large model capabilities into much smaller, lighter weight models that are much more cost effective and lower latency, but still quite capable for their size.

today at Google? How do you prioritize frontier versus we actually need to deploy it if we build it? Yeah, I think we always want to have models that are at the frontier or 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 or last six months ago version.

At the same time, 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 lower latency use cases. People can use them for agentic coding much more readily.

And then have the high end frontier model that is really useful for deep reasoning, 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 like to do both. Also, through distillation, which is a key technique for making the smaller models more capable, 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 sized model. Yeah. And you and Jeffrey and Tim came out with this solution in 2014.

Forgot. L'Oreal Vineyards as well.

image data set at the time, 300,000,000 images that we could train on with, I forget, like 20,000 categories or something, so much bigger than ImageNet. And we were seeing that if you create specialists for different subsets of those 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 room scenes or whatever. And you can cluster those categories and train on an enriched stream of data.

After you do pre training on a much broader set of images, you get much better performance if you then treat that whole set of maybe 50 models you've trained as a large ensemble. But that's not a very practical thing to serve. So distillation really came about from the idea of, Okay, what if we want to actually serve that and train all these independent expert models and then squish it into something that actually fits in a form factor that you can actually serve?

And that's not that different from what we're doing today. Often today, 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.

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 training data set and you can get utility out of making many passes over that data set because you're now getting the logits from a much larger model in order to of coax the right behavior out of the smaller model that you wouldn't otherwise get with just the hard labels.

And so I think that's what we've observed is you can get very close to your largest model performance with distillation approaches. And that seems to be 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 flash version of the next generation as good or even substantially better than the previous generation's Pro. And I think we're going to keep trying to do that because that seems like a good trend to follow.

Mean, 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 pro scale model, and we can distill from that as well into our flash scale model.

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

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, seems really important.

And flash is one direction, one way of doing that. Yeah. 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 high performance and quite amenable to, for example, long context attention operations, having sparse models with lots of experts. These kinds of things really matter a lot in terms of how do you make them servable at scale.

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 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 you to do much more complicated things. And I think that's true not just for coding but of now, can you analyze all the renewable energy deployments in the world and give me a report on solar panel deployment or whatever.

That's a very complicated, more complicated task than people would have asked a year ago. And so you are going to want more capable models to push the frontier in the absence of what people ask the models to do. And that also then gives us insight into, Okay, where do things break down?

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. I like to think of the best kinds of benchmarks are 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 is trying to assess and get it up to like 80%, 90%, whatever.

I think once it hits 95% or something, you get very diminishing returns from really focusing on that benchmark because 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 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 assessing 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 a bunch of architectural improvements or some sort of model capability improvements? What would help make that better?

I mean, I think some of the long context capabilities of the Gemini models that came, I guess, first in 1.

Yeah. Yeah. Yeah.

I mean, I think and once you're set I mean, as you say, that needed single needle in a haystack benchmark is really saturated for at least context lengths up to one twenty eight k or something. I think most people don't actually have, you know, much larger than one twenty eight k these days or two fifty six or something. We're trying to push the frontier of 1,000,000 or 2,000,000 context language.

I think Google's still the leader, 2,000,000. Yeah, which is good because I think there are a lot of use cases where putting a thousand pages of text or putting multiple hour long videos in the context and then actually being able to make use of that is useful. But the single needle in a haystack benchmark is sort of saturated.

So you really want more complicated, 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.

I mean, like to sort of not focus on exactly what solution one should drive, but what capability would you want. And I think we're very convinced that long context is useful, but it's way too short today. I think what you would really want is, can I attend to the internet while 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, let alone 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'd be find all kinds of uses for 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, 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.

By the way, I think I did some math.

Right. But if you then say, Okay, I want to be able to understand everything can talk people.

else is extremely information dense. Yeah. I mean, 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 video 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. So like LIDAR sensor data from Waymo vehicles or like robots or various kinds of health modalities, X rays and MRIs and imaging and genomics information.

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 LiDAR data or MRI data, you could have because maybe that doesn't make sense in terms of trade offs of what you include in your main pre training data mix, at least including a little bit of it, is actually quite useful because it sort of tempts the model that this is a thing. Yeah, yeah.

vision and motion are quite important things. As opposed to static 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 paying attention to, and then help us in using that information to do things.

So I use it for YouTube all the time. Nice. Yeah.

Yeah. I mean, it's actually I think people kind of are not necessarily aware of what the Gemini models can actually do with video. Have an example I've used in one of my talks.

Was like a YouTube highlight video of 18 memorable sports moments across the last twenty years or something. So it has Michael Jordan hitting some jump shot at the end of the finals and some soccer goals and things of that. 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, the date is when they happened, and a short description of the event.

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

pre language model based works, our 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.

Now you're down to like 30,000 documents or something. And then you gradually refine that to apply more and more sophisticated algorithms and more and more sophisticated signals of various kinds in order to get down to ultimately what you show, which is the final 10 results or 10 results plus other kinds of information. And I think an 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 what are the 30,000 ish documents with the maybe 30,000,000 interesting tokens? And then how do you go from that into what are the 117 documents I really should be paying attention to in order to carry out the tasks that the user has asked me to do? And I think you can imagine systems where you have 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 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 the 117 things that might be your most capable model. So I think it's going to be some system like that that really enables you to give the illusion of attending to trillions of tokens.

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

Google. Yeah.

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.

I guess, Web Search and Data Mining Conference in 2009, where we never actually published any papers about the origins of Google Search. But we went through four or five generations, four or five or six generations of redesigning of the search and retrieval system from about 1999 through 2004 or 02/05. 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. 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 gonna not do well.

And then we also needed to scale our capacity because our traffic was growing quite extensively. And so we had a sharded system where you have more and more shards as the index grows. You have 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 respond for any particular user query. And then as traffic grows, you add more and more replicas to each of those. And so we eventually did the math that realized that in a data center where we had, say, 60 shards and 20 copies of each shard, we now had 1,200 machines with disks.

And we did the math and we're like, hey, one copy of that index would actually fit in memory across 1,200 machines. So in 2001, 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 how many different terms you looked at for a query, because every one of them would involve a disk 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 really getting at the meaning of the word as opposed to the exact semantic form the user typed in. And that was 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.

first, whenever you're designing a system, want to understand what are the design parameters that are going to be most important in designing that. So 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 in the index? How are you going to look at it when you retrieve things? What happens if traffic were to double or triple?

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

So going from a disk based index to an in memory index makes a lot of sense once you have enough traffic, because now you have enough replicas of the state on disk that those machines now actually can hold a full copy of the index in 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 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.

So it used to be once a month. And then we went to a system that could update any particular page in sub one minute. Okay.

Because this is a competitive advantage.

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 recrawl important pages quite often because the likelihood they change might be low, the value of having them updated is high. Yeah.

mean, this has sort of eight or 10 different kinds of metrics that are like, how long does a cache miss take? How long does branch miss predict take? How long does reference domain memory take?

How long does a distin take? How long does it take to send a packet from The US to The Netherlands or something?

We had a data center in there. 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, how would I do that?

I could pre compute the image thumbnails. I could try to thumbnail them on the fly from the larger images. What would that do?

How much disk bandwidth would I need? How many disseqs would I do? And you can sort of actually do thought experiments in thirty seconds or a minute with the sort of basic numbers at your fingertips.

it's really good to think about calculations you're doing in a model, either for training or inference. Often a good way to view that is how much state will you need to bring in from memory, either on chip SRAM or HBM from the accelerator attached memory or DRAM or over the network? And then how expensive is that data motion relative to the cost of, say, an actual multiply in the matrix multiply unit?

And that cost is actually really, really low, right? Because it's order, depending on your precision, think it's like sub one picajoule. Oh, Okay.

You measure it by energy. Yeah. I mean, it's all going to be about energy and how do you make the most energy efficient system.

And then moving data from the SRAM on the other side of the chip, not even off chip, but on the other side of the same chip can be, you know, a thousand picajoules. 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 the chip into the multiplier unit, that's going to cost you a thousand Picotools. So you better make use of that thing that you moved many, many times.

So that's where the batch dimension comes in because all of a sudden, if you have a batch of two fifty six 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 a thousand picotoules in order to do your one picajoule multiply. I have never heard an energy based analysis of batching. Yeah, I mean, that's why people batch, right?

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

Yeah. I mean, I think, you know, TPUs have this nice sort of regular structure of two d or three d meshes with a bunch of chips connected. And each one of those has HBM attached.

I think for serving some kinds of models, pay a lot higher cost and time latency bringing things in from HBM than you do bringing them in from SRAM on the So if you have a small enough 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 striping your smallish 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 that's not a surprise, but it is a good technique.

much of it is worth doing in hardware when things change so quickly? What's the internal discussion? Yeah, I mean, we have a lot of interaction between, say, the TPU chip design architecture team and the 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 ML research puck is going in some sense.

Because 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 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 interesting hardware features put into TPU n plus two, where TPU n is what we have today. Oh, the cycle time is plus two.

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

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 10 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 a deal.

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

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 generation of model. So I think it kind of goes both ways.

Sometimes you can take advantage of lower precision things that are coming in a future generation. So you might train it at that lower precision, even if the current generation doesn't quite do that. 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 picajoules per bit that you're transferring and reducing the number of bits is a really good way to reduce that. I think people have gotten a lot of luck, mileage out of having very low bit precision things, but then having scaling factors that apply to a whole bunch of those weights.

Yeah, I mean, I think there's a bunch of interesting trends. So energy based models is one. Diffusion based models, which don't sort of sequentially decode tokens, is another.

Speculative decoding is a way that you can get sort of an equivalent, very small batch factor for like you predict eight tokens out, and that enables you to sort of increase the effective batch size of what you're doing by a factor of eight. And then you maybe accept five or six of those tokens, so you get a 5x improvement in the amortization of moving weights into the multipliers to do the prediction for the token. 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 better from being able to serve larger models or equivalent sized models more cheaply and with lower latency.

Yeah. I I think there's also sort of the more exotic things like analog based computing substrates as opposed to digital ones. 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 to 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 with much better and specialized hardware for the models we care about.

I guess you have a lot of- Our research portfolio is pretty broad, would say. I mean, I think in terms of research direction, there's a whole bunch of open problems and how do you make these models reliable and able to do much longer, more complex tasks that have lots of subtasks? How do you orchestrate maybe one model that's using other models as tools in order to build things that can accomplish 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 verifiable how do you get RL to work for non verifiable domains? 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 could apply those to other less verifiable domains because we've come up with RL techniques that actually enable us to do that effectively, that would really make the models improve quite a lot, I think.

Yeah. I mean, I think there are ways of having other models that can evaluate the results of what a first model did. Maybe in retrieving, can you have another model that says, are these things you retrieved relevant?

Or can you rate these 2,000 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 that can even be the same model just prompted differently to be a critic as opposed to a actual retrieval system.

Yeah.

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 some things and they fall down around the edges of those things and are not as capable as we'd like in those areas. Then coming up with 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 back two years ago, we were struggling with GSM eight ks problems, right? Like Fred has two rabbits, he gets three more rabbits.

How many rabbits does he have? That's a pretty far cry from the kinds of mathematics that the models can And now you're doing IMO, Erdos problem Pure language. Pure language.

So that is a really, really amazing jump in capabilities in a 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 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.

guess I'm not a YouTube creator, so I don't care that much about that problem, but I guess many people do.

Yeah. I mean, I think it makes a lot of sense to me because humans manipulate symbols, but we probably don't have 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 and plan and do chains of thought and roll them back. Now that approach for solving the problem doesn't seem like it's going to work. I'm going try this one.

And 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 completely separate discrete symbolic things and then a completely different way of thinking about those things.

IMO with translating to 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 quite good because it shows you that the capabilities of that general model have improved dramatically, and now you don't need these specialized models. This is actually sort of very similar to the twenty thirteen to 'sixteen era of machine learning.

It used to be people would train separate models for lots of each different problem. 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.

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

And you don't need domain experts.

I mean, think you do want the model to be most effective at reasoning if it can retrieve things. 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 knowing stuff about the world. Like, it's probably useful to know how long the Golden Gate Bridge is, just as a general sense of like how long are 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, 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 my 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.

No. I think vertical models are interesting. You want them to start from a pretty good base model, then you can sort of view them as enriching the data distribution for that particular vertical domain, for health care, 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 want it to have a balanced 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 multilingual 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. 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 Perl programming. 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 multimodal reasoning capabilities may suffer because we didn't get to expose it to as much data there, but it's really good at multilingual things. So I think some combination of specialized models, maybe 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 health care module that all can be knitted together to work in concert and called upon in different circumstances.

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. Installable knowledge. Yeah.

Just download as a package.

but there's a lot of health care organizations that want to train models on their own data that is not public health care data. Not public health, but public health care data. So I think there are opportunities there to, say, partner with a large health care organization and train models for their use that are going to be more bespoke, but probably might be better than a general model trained on, say, public data.

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.

Somali or something, there is a fair bit of Somali text in the world Ethiopian Amharic or something. 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 or of those languages.

I did some work on an early model that fused together a language based model where you have nice word based representations and then an image model where you have trained it on ImageNet like things. And then you fuse together the top layers of No, this is devise. You do a little bit more training to fuse together those representations.

And 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 assign the label to that image. So for example, I think telescope and binoculars were both in the training categories for the image model, but microscope was not. And so if you're given an image of a microscope, it actually can come up with something that's got the word microscope as the label that it designs, even though it's never actually seen an image labeled that.

Yeah. I think one thing that's kind of interesting is I did a undergrad thesis on neural network training, parallel neural network training back in 1990 when I got exposed to neural nets. 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 could get you a little bit more interesting model, but not enough to solve real problems. And so starting in 2008 or 'nine, the world started to have enough computing power through Moore's Law and large interesting data sets to train on to actually 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 twenty eleven, I really just felt like we should scale up the size of neural networks we can train using 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 I compared them. I called them something different. There was like pattern partitioned and model partitioned or something.

Is it public? Can we go to Yeah, it's on the web. Okay, that's nice.

But I think combining a lot of those techniques and really just trying to push on scaling things up over the last fifteen years has been really important. And that means improvements in the hardware, so pushing on building specialized hardware like GPUs. It also means 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 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. But you also want to be super efficient in how you activate your model.

So you'd like trillions of parameters, but activate only 1% or 5% or 10% of that. And we did an early paper on this where we really scaled up outrageously large neural networks.

Yeah, so that is really good because that gave you a 10x improvement in time to quality or compute cost given the quality level relative to non sparse models. Transformers similarly gave you a 10x to 100x improvement in compute cost to a given quality level versus, say, LSTMs at the time. And all of those things multiply together.

So I think all those things really are important to work on. The hardware, the systems infrastructure, the algorithmic aspects of model architecture, improving the data, improving the RL recipes, all these things are what are stacking together and multiplying together to give us models of 2026 are much better than models of 2025 and are awesomely better than 2024 and 2023 and 2022.

tech report.

probably a historical paper. Yeah. I mean, I think it's perfectly good to have actually a lot of coauthors.

And I do think organizing that number of people so that they're effectively pushing in common directions, that all their work actually sort of multiplies together in the ultimate output, which is the next generation of model, is actually pretty tricky. And we have awesome people throughout the Gemini team to help orchestrate this. Myself, Noam, and Oriel are helping steer this.

And then we have people thinking about what does the pre training setup look like? What does the infrastructure look like? What does the post training recipe look like?

And what does the data preparation and evals and multimodal capabilities and I18N capabilities? You know, there's a lot of different kinds of areas, coding capabilities, all these areas super important.

stuff. Yep. Yeah.

We all use the same micro kitchen.

Yeah, I actually bumped into Andrew Ng, who's a Stanford faculty member. And I knew him from, I'd given talks at Stanford a couple of 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 of 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.

Google has lots of computational capability. And so if they were seeing good results on what were effectively single GPU or models, if we actually didn't have GPUs in our data centers then, we didn't have any accelerators, we had lots of CPUs. But 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.

Was 50x bigger than any previous neural net, as far as we could tell. So it's 2,000,000,000 parameters vision model trained on 16,000 CPU cores for multiple weeks. That's what gave us really good it gave us a 70% relative error improvement in ImageNet 22 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 sophisticated scaling analysis, but we had a saying, bigger model, more data, better results. And that was our mantra for like six or seven years of scaling.

Every time we did that, we saw better results in speech, in language, in vision.

Yeah. I mean, I think I would somewhat agree with that. I mean, 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 efforts within Google Research 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 Chinchilla 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.

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 the early Gemini project being an important thing on your way to the Apollo project.

So it seemed like a good name.

How would you rate the tools today? Where should things go? Yeah.

I mean, first, I think the coding tools are getting vastly better compared to where they were a year or two years ago. So now you can actually rely on them to do more complex things that you as a software engineer want to accomplish. And you can sort of delegate 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 dictates how it interacts with you. 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, 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. Some kinds of problems you actually want maybe a more frequent interaction style with the model.

And other ones you're just like, yeah, please just go write 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 and 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 as the models get better, that set of decisions you put into how the interaction should happen may change. Like if you have a team of 50 interns, how would you manage that if they were people?

I think it's not Do you want 50 interns? You might if they're really good, right? That'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?

I think you would 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 off doing things on your behalf. But I don't know exactly how this is going to unfold.

Maybe. I mean, on the other hand, imagine a classical software organization without any AI assisted tools. You would have 50 people doing stuff, and their interaction style is going to be naturally very hierarchical because these 50 people are going to be working on this part of the system and not interact that much with these other people over here.

But if you have five people each managing 50 virtual agents, they might be able to actually have much higher bandwidth communication among the five people than you would have among five people who were also trying to coordinate a 50 person software team each.

I mean, I do think it's interesting that 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. It was like, yeah, whatever. I don't need to do that.

Really? I don't know. Mean, the was English language 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 in how you specify that, because that's going to dictate the quality of the output. 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 really care about the performance of this part of it, 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 they will get really good at crisply 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 trying to do some other kind of task. Being able to crisply specify what it is you want is going to be really important.

Yeah.

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 read by other developers so that their prompts are more clear about what the underlying software system should be doing. 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 the context of a coding agent, that can be helpful.

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 with failures.

You can have Paxos like replication, or you can send the request to two places and tolerate failure because you only need one of them to come back. A little description of 20 techniques like that in building distributed systems probably would go a long way to having a coding agent be able to cobble up more reliable and robust distributed systems. Yeah.

Yeah, 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 10 times as slow or 20 times as slow. And I think 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 interactions.

would use DeepThink all the time if it weren't for cost and latency, right? You could have that capability in a model because the latency improvement was 20x in the underlying hardware and system and costs, 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.

Onward and outward. Onward and outward.

Let me make two predictions that are not quite in So that I think a personalized model that knows you and knows all your state and is able to retrieve overall 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 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 status quo. That's going to be also quite important. Yeah.

many more tokens, you could do many more parallel rollouts, you could generate way more code and check that the code is correct with chain of thought reasoning. So I think being able to do that at 10,000 tokens per second would be awesome. Yeah.

At 10,000 tokens per second, you are no longer reading code. You will just generate it. I'm not reading It right may not end up with 10,000 tokens of code.

Reasoning It may be for 1,000 tokens of code with 9,000 tokens of reasoning behind it, which should actually be probably much better code to read. Yeah.

Awesome, Jeff. This was amazing. Cool.

Thanks for taking the time. You. It's been fun.

Thanks for having me.