The AI Frontier: from Gemini 3 Deep Think distilling to Flash — Jeff Dean

Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, founder of Kernel Labs, and I'm joined by swyx, editor of Latent Space.

swyx

Hello, hello. We're here in the studio with Jeff Dean, chief AI scientist at Google. Welcome.

Thanks for having me.

swyx

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 legendary. The first thing that must be said is congratulations on owning the Pareto frontier.

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

swyx

I think it's a combination of both. You have to own the Pareto frontier, so you have to have frontier capability, but also efficiency, and then offer that range of models that people like to use. Some part of this was started because of your hardware work, some part of it is your model work, and I'm sure there's lots of secret sauce that you guys have worked on cumulatively. It's really impressive to see it all come together in this steadily advancing frontier.

Yeah. I think, as you say, it's not just one thing. It's 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.

swyx

How much pressure do you have on the lower end of the Pareto frontier, too? The new labs are always trying to push the top performance frontier because they need to raise more money and all of that. You guys have billions of users, and I think initially, when you worked on the CPU, you were thinking about what would happen if everybody who used Google used the voice model for 3 minutes a day. You needed to double your CPU count. What's that discussion like today at Google? How do you prioritize the frontier versus actually needing to deploy something if you build it?

I think we always want to have models that are at the frontier or pushing the frontier, because that's where you see what capabilities now exist that didn't exist in last year's version, or even the version from 6 months ago.

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 more expensive than people might like for a lot of other, broader use cases. So what we want to do is always have a highly capable, 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's really useful for deep reasoning and solving really complicated math problems.

It's not that one or the other is useful. They're both useful, so 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 distill it into your smaller model. It's not an either-or choice. You need the frontier model in order to actually get a highly capable, more modest-size model.

swyx

You and Geoffrey Hinton came out with this solution in 2014.

Don't forget Oriol Vinyals as well. It was a long time ago.

swyx

I'm curious how you think about the cycle of these ideas, even sparse models and so on. How do you reevaluate them? How do you think about, in the next generational model, what is worth revisiting? You've worked on so many ideas that end up being influential, but in the moment, they might not feel that way necessarily.

I think distillation was originally motivated because we were seeing that we had a very large image dataset at the time—300 million images that we could train on, with, I forget, around 20,000 categories—so much bigger than ImageNet. We were seeing that if you created specialists for different subsets of those image categories—this one would be really good at mammals, and this one would be really good at indoor room scenes, or whatever—and you could cluster those categories and train on an enriched stream of data after pretraining on a much broader set of images, you got much better performance if you then treated that whole set of maybe 50 models as a large ensemble.

But that's not a very practical thing to serve, right? Distillation really came about from the idea of: What if we want to actually serve that? We could train all these independent expert models and then squish them into something that actually fits in a form factor that you can serve. That's not that different from what we're doing today.

swyx

Yeah, a part of me also wonders if distillation also has a story with the RL revolution. So let me maybe try to articulate what I mean: RL basically spikes models in a certain part of the distribution, and then you have to sort of—well, you can spike models, but sometimes it might be lossy in other areas and it's kind of an uneven technique. But you can probably distill it back, and I think the general dream is to be able to advance capabilities without regressing on anything else. I feel like that whole capability merging without loss should be a distillation process, but I can't quite articulate it. I haven't seen many papers about it.

Often today, 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. I tend to think of one of the key advantages of distillation as being that you can have a much smaller model and a very large training dataset, and get utility out of making many passes over that dataset because you're now getting the logits from the much larger model in order to coax the right behavior out of the smaller model that you wouldn't otherwise get with just the hard labels.

What we've observed is that you can get very close to your largest model's performance with distillation approaches. That seems to be a nice sweet spot for a lot of people because, for multiple Gemini generations now, we've been able to make the Flash version of the next generation as good as, or even substantially better than, the previous generation's Pro model. I think we're going to keep trying to do that because it seems like a good trend to follow.

swyx

Dare I ask: the original map was Flash, Pro, and Ultra. Is Ultra just sitting there, and are you distilling from that? Is that the mother lode?

We have a lot of different kinds of models. Some are internal models that aren't necessarily meant to be released or served. Some are our Pro-scale models, and we can distill from those into our Flash-scale models. It's an important set of capabilities to have, and inference-time scaling can also be useful for improving a model's capabilities.

swyx

Obviously, the economics of Flash are what led to its total dominance. I think the latest number is 50 trillion tokens—I don't know, obviously it's changing every day—but by market share—

Hopefully up.

swyx

No, I mean, just economics-wise, because Flash is so economical, you can use it for everything. It's in Gmail now, it's in YouTube, it's in everything.

We're using it more in our search products, in various AI Mode and AI Overviews.

swyx

Oh my God, Flash powers AI Mode. I didn't even think about that.

One of the things that's quite nice about the Flash model is that it's not only more affordable; it's also lower-latency. Latency is actually a pretty important characteristic for these models because we're going to want models to do much more complicated things that will involve generating many more tokens from when you ask the model to do something until it actually finishes what you asked it to do.

You're going to ask now not just, “Write me a for loop,” but, “Write me a whole software package to do X, Y, or Z.” Having low-latency systems that can do that seems really important, and Flash is one way of doing that.

swyx

Yeah.

Obviously, our hardware platforms enable a bunch of interesting aspects of our 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 in terms of how you make them servable at scale.

swyx

Does it feel like there's some breaking point for the Pro-to-Flash distillation that's one generation delayed? I almost think about it as a capability asymptote in certain tasks. The Pro model today has saturated on some sort of task.

Mhm.

swyx

So the next generation of 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 in 2 generations will be able to do basically everything. How do you make it economical to 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 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? I think this happens in my own usage. I used to try our models a year ago for some sort of coding task, and they were okay at some simpler things but wouldn't do the work very well for more complicated things. Since then, we've improved dramatically on the more complicated coding tasks, and now I'll ask it to do much more complicated things.

I think that's true not just of coding but of, you know, now being able to ask, "Can you analyze all the renewable energy deployments in the world and give me a report on solar panel deployment?" That's a much 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 some sense of what people ask the models to do. That also gives us insight into where things break down and how we can improve the model in these particular areas in order to make the next generation even better.

swyx

Yeah. Are there any benchmarks or test sets that you use internally? It's almost like the same benchmarks get reported every time, and it's like, all right, it's 99 instead of 97. How do you keep pushing the team internally, too? Is this what we're building toward?

Yeah. I think benchmarks, particularly external ones that are publicly available, have their utility, but they often have a lifespan of utility. They're introduced and maybe they're quite hard for current models. I like to think of the best kinds of benchmarks as ones where the initial scores are around 10%, 20%, or 30%, but not higher. Then you can work on improving that capability for whatever it is the benchmark is trying to assess and get it up to 80% or 90%, whatever.

I think once it hits around 95% or something, you get very diminishing returns from really focusing on that benchmark. 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 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 they weren'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 we make the model better at these kinds of things. Do we need different kinds 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?

swyx

Is there such an example where a benchmark inspired an architectural improvement? I'm just jumping on that because you just—

I mean, I think some of the long-context capabilities of the Gemini models that came, I guess, first in 1.5 really were about looking at what we wanted to have.

swyx

Immediately, everyone jumped to completely green charts. Everyone had them. I was like, how did everyone crack this at the same time?

Right, yeah. I think, as you say, that single-needle-in-a-haystack benchmark is really saturated for at least context lengths up to 128,000 or something. I think most people don't actually have much larger than 128,000 these days—maybe 256,000 or something. We're trying to push the frontier of 1 million or 2 million context lengths.

swyx

I think Google's still the leader at 2 million.

Yep, which is good, because I think there are a lot of use cases where putting 1,000 pages of text or 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 saturated. You really want more complicated, multi-needle, or more realistic tasks: take all this content and produce this kind of answer from a long context. That better assesses what people really want to do with long context, which is not just, "Can you tell me the product number for this particular thing?"

swyx

Yeah, it's retrieval. It's retrieval within machine learning. The more meta-level lesson I'm trying to operate at here is that you have a benchmark and you're like, okay, I see the architectural thing I need to do in order to go fix that. But should you do it? Because sometimes that's an inductive bias—basically, the kind of thing Jason, who used to work at Google, would say: you're going to win in the short term, but longer term, I don't know if that's going to scale. You might have to undo that.

I mean, I like to not focus on exactly what solution one should drive, but on what capability you would want. I think we're very convinced that long context is useful, but it's way too short today. 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. A million tokens kind of pushes what you can do. You're not going to do that to 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 find all kinds of uses for that. You could attend to the internet. You could attend to the pixels of YouTube and the deeper representations that we can form for a single video, but across many videos. On a personal Gemini level, you could attend to all of your personal state, with your permission—your emails, your photos, your docs, your plane tickets.

I think that would be really useful. 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?

swyx

Yeah. By the way, I did some math, and if you spoke all day, every day, for 8 hours a day, you would only generate a maximum of around 100,000 tokens, which very comfortably fits, right? But if you then say, okay, I want to be able to understand everything people are putting on video—

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

swyx

Yeah.

Yeah. I mean, I think one of the things about Gemini's multimodal aspects is that we've always wanted it to be multimodal from the start. Sometimes that means text, images, and video—human language and audio modalities. But I think it's also really useful to have Gemini know about nonhuman modalities, like LiDAR sensor data from, say, Waymo vehicles, or robots, or various kinds of health modalities—X-rays, MRIs and imaging, and genomics information.

I think there are 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. Even if you haven't trained on all the LiDAR data or MRI data, because maybe that doesn't make sense in terms of the trade-offs of what you include in your main pretraining data mix, at least including a little bit of it is actually quite useful. It sort of teaches the model that this is a thing.

swyx

Yeah. Since we're on this topic, I get to ask you all the questions I always wanted to ask, which is fantastic. Do you believe there are some king modalities—modalities that supersede all the other modalities? A simple example was vision. It can, on a pixel level, encode text, and DeepMind had this paper that did that.

Vision has also been shown to maybe incorporate audio, because you can do audio spectrograms, and that's also a vision-capable thing. So maybe vision is just the king modality.

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

swyx

Motion—video as opposed to static images?

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

Yeah, I think motion—I still want to shout out that I think Gemini is still the only native video-understanding model that's out there. I use it for YouTube all the time.

I mean, it's actually something people are not necessarily aware of: what the Gemini models can actually do with video. I have an example I've used in one of my talks. It was a YouTube highlight video of 18 memorable sports moments across the last 20 years or something. It had Michael Jordan hitting a jump shot at the end of the finals, some soccer goals, and things like that.

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 the date is when they happened, and a short description of the event?” So now you get an 18-row table of that information extracted from the video, which is not something most people think of as turning a video into a SQL-like table.

swyx

Has there been any discussion inside Google of, as you mentioned, attending to the whole internet? Google is almost built around the fact that a human cannot attend to the whole internet, and you need some sort of ranking to find what you need.

Yep.

swyx

That ranking is much different for an LLM because you can expect a person to look at maybe the first 5 or 6 links in a Google search, versus for an LLM, should you expect to have 20 links that are highly relevant? How do you internally figure out how to build the AI Mode that is maybe much broader in search and span versus the more human one?

I think even pre-language-model-based work, 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 that is relevant with very lightweight kinds of methods. Now you're down to 30,000 documents or something, and then you gradually refine that by applying more and more sophisticated algorithms and more and more sophisticated signals of various kinds, in order to get down to what you ultimately show, which is the final 10 results, or 10 results plus other kinds of information.

I think an LLM-based system is not going to be that dissimilar. You're attending to trillions of tokens, but you want to identify the 30,000-ish documents with maybe 30 million interesting tokens, and then figure out how to go from that to the 117 documents you really should be paying attention to in order to carry out the task that the user has asked you to do.

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 helps you narrow down from 30,000 to 117 with maybe a little bit more sophisticated model or set of models. Then maybe the final model is the thing that looks at 117 things. That might be your most capable model.

I think it has 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 you—not the illusion, but you are searching the internet.

swyx

But you're finding a very small subset of things that are relevant. I often tell a lot of people who are not steeped in Google Search history that BERT was used basically immediately inside Google Search, and that improved results a lot. I don't have any numbers off the top of my head, but I'm sure those are obviously the most important numbers to Google.

I don't think people understand how much LLMs have taken over all these very high-traffic systems. It's Google. It's YouTube. YouTube has this semantic ID thing where every token—or every item in the vocabulary—is a YouTube video or something that predicts the video using a codebook, which is absurd to me for YouTube's size. And most recently, Grok for xAI.

I'll call out that 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.

swyx

Do you have a history of how that evolved?

I actually gave a talk at the 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 4, 5, or 6 generations of redesigning the search and retrieval system from about 1999 through 2004 or 2005. That talk is really about that evolution.

One of the things that really happened in 2001 was that we were working to scale the system in multiple dimensions. One was that 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 not going to do well. We also needed to scale our capacity because our traffic was growing quite extensively.

We had a sharded system where you have more and more shards as the index grows. You have 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. As traffic grows, you add more and more replicas of each of those.

We eventually did the math and 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. We did the math and thought, “Hey, one copy of that index would actually fit in memory across 1,200 machines.”

swyx

Mhm.

So in 2001, we put our entire index in memory. 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. 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 that you throw into the query from the user's original 3- or 4-word query, because now you can add synonyms like “restaurant” and “restaurants” and “cafe” and “bistro” and all these things. You can suddenly start really getting at the meaning of the word as opposed to the exact surface form the user typed in.

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

swyx

What are the principles that you use to design these systems, especially when you have—I mean, in 2001, the internet was doubling or tripling every year in size. It's not like a... And I think today you kind of see that with LLMs too, where every year the jumps in size and capabilities are just so big. Are there any principles that you use to think about this?

Whenever you're designing a system, you want to understand what the design parameters are that are going to be most important in deciding that. 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?

I think a good design principle is that you want to design a system so that the most important characteristics can scale by factors of 5 or 10, but probably not beyond that. 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.

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 sort of state on disk that those machines can actually hold a full copy of the index in memory.

swyx

Yeah.

That all of a sudden enables a completely different design that wouldn't have been practical before. I'm a big fan of thinking through designs in your head, just playing with the design space a little before you actually do a lot of writing of code.

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. The update rate was actually the parameter that changed the most, surprisingly. It used to be once a month.

And then we went to a system that could update any particular page in under 1 minute.

swyx

Because this is a competitive advantage, right?

All of a sudden, news-related queries—if you've got last month's news index, it's not actually that useful.

swyx

News is a special beast. Was there any way you could have split it onto a separate system?

Well, we did. We launched a Google News product, but you also want news-related queries that people type into the main index to also be sort of updated.

Yeah. It’s interesting. Then you have to classify the pages—you have to decide which pages should be updated at what frequency.

Oh, yeah. There’s a whole system behind the scenes that’s trying to decide update rates and the 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 that they change might be low, but the value of having them updated is high.

Yeah. This mention of latency and saving things to disk reminds me of one of your classics, which I have to bring up: “Latency Numbers Every Programmer Should Know.” Was there just a general story behind that? Did you just write it down?

I mean, this has 8 or 10 different kinds of metrics: How long does a cache miss take? How long does a branch mispredict take? How long does a reference to main memory take? How long does a disk seek take? How long does it take to send a packet from the US to the Netherlands or something?

Why the Netherlands, by the way? Is that because of Chrome?

We had a data center in the Netherlands.

I think this gets to the point of being able to do these back-of-the-envelope calculations. These are the raw ingredients of those calculations, and you can use them to say, “Okay, well, if I need to design a system to do image search and thumbnailing or something for the results page, how might I do that?” I could precompute the image thumbnails, or 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 disk seeks would I do?

You can actually do thought experiments in 30 seconds or a minute with the basic numbers at your fingertips. Then, as you build software using higher-level libraries, you want to develop the same intuitions for how long it takes to look up something in a particular kind of hash table, or how long it will take to sort a million numbers or something.

Yeah. The reason I bring it up, actually, is that for 2 years now I’ve been trying to make “Numbers Every AI Programmer Should Know.”

I don’t have a great one, because it’s not physical constants like you have. You have physical constants in here, you know. But I do think a simple one would be the number of parameters to disk size, if you need to convert that. That’s a simple byte conversion; that’s nothing interesting. I wonder if you were to update your list—

I mean, I think 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, HBM from the accelerator-attached memory, 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? Depending on your precision, I think it’s on the order of sub-picojoule—1 picojoule.

Oh, okay. You measure it by energy.

Yeah, yeah. It’s all going to be about energy and how to make things as energy-efficient as possible. 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 around 1,000 picojoules.

Oh.

And so, all of a sudden, this is why your accelerators require batching. If you move, say, a parameter of a model from SRAM on the chip into the multiplier unit, that’s going to cost you 1,000 picojoules. So you’d better make use of that thing you moved many, many times. That’s where the batch dimension comes in, because if you have a batch of 256 or something, that’s not so bad. But if you have a batch of 1, that’s really not good.

I have never heard an energy-based analysis of batching.

Yeah. That’s why people batch, right? Ideally, you’d like to use batch size 1 because the latency would be great, but the energy cost and the compute-cost inefficiency you get is quite large.

Is there a similar trick, like you did with putting everything in memory? Obviously, Groq has caused a lot of waves by betting very hard on SRAM. I wonder if that’s something you already saw with the TPUs, something you had to serve at your scale. You probably saw that coming. What hardware innovations or insights were formed because of what you were seeing there?

Yeah. I think TPUs have this nice, regular structure of 2D or 3D meshes, with a bunch of chips connected, and each one of those has HBM attached.

For serving some kinds of models, you pay a much higher cost and latency bringing things in from HBM than you do bringing them in from SRAM on the chip. So if you have a small enough model, you can actually do model parallelism, spread it out over lots of chips, and get quite good throughput and latency improvements from doing that.

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, yeah, that’s not a surprise, but it is a good technique.

What about the TPU design? How much do you decide where the improvements have to go? This is a good example: Is there a way to bring the 1,000 picojoules down to 50, and is it worth designing a new chip to do that? The extreme is when people say, “You should burn the model into the ASIC,” which is kind of the most extreme thing.

How much is it worth doing in hardware when things change so quickly? What’s the internal discussion?

Yeah, we have a lot of interaction between the TPU chip design and architecture team and the higher-level modeling experts, because we really want to take advantage of being able to co-design what future TPUs should look like based on where we think the ML research puck is going.

As a hardware designer for ML in particular, you’re trying to design a chip starting today, and that design might take 2 years before it even lands in a data center. Then it has to have a reasonable lifetime as a chip, say 3, 4, or 5 years. So you’re trying to predict 2 to 6 years out what ML computations people will want to run in a very fast-changing field.

Having people with interesting ML research ideas—things we think will start to work in that time frame or will be more important in that time frame—really enables us to get interesting hardware features put into TPU N+2, where TPU N is what we have today.

Oh, the cycle time is N+2?

Roughly. I mean—

Because—

Sometimes you can squeeze some changes into N+1, but bigger changes are going to require the chip design to be earlier in its design process. Whenever we can do that, it’s generally good.

Sometimes you can put in speculative features that maybe won’t cost you much chip area, but if they work out, they would make something 10 times as fast. If they don’t work out, you’ve burned a 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 it’s going to work out. So we’ll do lots of careful ML experimentation to show us that this is actually the way we want to go.

Is there a reverse of that? We’ve already committed to this chip design, so we cannot take the model architecture in that direction because it doesn’t quite fit?

Yeah, you definitely have things where you’re going to adapt what the model architecture looks like so that it’s efficient on the chips you’re going to have for both training and inference of that generation of the model. So I think it goes both ways.

Sometimes you can take advantage of lower-precision things that are coming in a future generation. You might train it at that lower precision even if the current generation doesn’t quite support it.

How low can we go in precision?

I mean, I’m a big fan of very low precision, because I think that saves you a tremendous amount of energy. It’s picojoules per bit that you’re transferring, and reducing the number of bits is a really good way to reduce that.

People have gotten a lot of mileage out of having very low-bit-precision things, but then having scaling vectors that apply to a whole bunch of those weights.

Scaling. Okay, interesting. So, low precision but scaled-up weights.

Yeah.

Huh. Yeah, I never considered that. Interesting. While we’re on this topic, the concept of precision at all is weird when we’re sampling. At the end of this, we’re going to have all these chips that do very good math, and then we’re just going to throw a random-number generator at the start.

I mean, there’s a movement toward energy-based models and processors.

swyx

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

Yeah, I mean, I think there are a bunch of interesting trends. Energy-based models are one. Diffusion-based models, which don't sequentially decode tokens, are another.

swyx

Yes.

Speculative decoding is a way that you can get an equivalent, very small—

swyx

Draft.

Batch factor. You predict 8 tokens out, and that enables you to increase the effective batch size of what you’re doing by a factor of 8. Then you maybe accept 5 or 6 of those tokens, so you get a 5x improvement in the amortization of moving weights into the multipliers to do the prediction for the tokens.

These are all really good techniques, and I think it's really good to look at them from the lens of real energy—not energy-based models—and also latency and throughput. If you look at things from that lens, that guides you to solutions that are going to be better for serving larger models, or equivalent-size models, more cheaply and with lower latency.

swyx

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

Yeah. Yeah. I mean, I think there are also more exotic things, like analog-based computing substrates as opposed to digital ones. I think those are super interesting because they can potentially be low-power.

swyx

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.

swyx

Yeah. Any other interesting research ideas that you've seen, or maybe things that you cannot pursue at Google that you would be interested in seeing researchers take a stab at? I guess you have a lot of researchers.

Yeah, we have a lot. Our research portfolio is pretty broad. I would say, in terms of research directions, there are a whole bunch of open problems. 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 more verifiable? How do you get RL to work for non-verifiable domains? I think it's a pretty interesting open problem because I think that would broaden 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.

swyx

I'm curious: when we had Noam Brown on the podcast, he said they already proved you can do it with Deep Research.

Mhm.

swyx

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. What is it? Both are information retrieval of JSON, so I wonder if the retrieval is the verifiable part that you can score. How would you model that problem?

Yeah, I mean, I think there are ways of having other models evaluate the results of what a first model did. In retrieval, can you have another model say, “Are these things you retrieved relevant?” Or can you rate the 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: a critic as opposed to an actual retrieval system.

swyx

Yeah. I do think there is that weird cliff where it feels like we've done the easy stuff, and now it's—but it always feels like that. Every year it's like, “Oh, we know,” and the next part is super hard and nobody's figured it out. Exactly with this RLVR thing, everyone's talking about, “Well, okay, how do we do the next stage of the non-verifiable stuff?” And everyone's like, “I don't know. Judge.” [laughter]

I mean, I feel like the nice thing about this field is that there are lots and lots of smart people thinking about creative solutions to some of the problems that we all see. Everyone sort of sees that the models are great at some things, but they fall down around the edges of those things and are not as capable as we'd like in those areas.

Coming up with good techniques, trying those, and seeing which ones actually make a difference is what the whole research aspect of this field is pushing forward. I think that's why it's super interesting. If you think back 2 years ago, we were struggling with GSM8K problems, right? Fred has 2 rabbits, he gets 3 more rabbits—how many rabbits does he have?

swyx

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

And now you're doing it in language. Yeah.

swyx

Yeah. Pure language.

So that is a really amazing jump in capabilities in a year and a half or something. I think for other areas, it would be great if we could make that kind of leap. 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.

swyx

Yeah. Like YouTube thumbnail generation—that would be very helpful.

We need that. That would be AGI. We need it as far as content creators go.

swyx

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

It doesn't matter. People do judge books by their covers, as it turns out.

swyx

Just to draw a bit on the IMO gold, I'm still not over the fact that a year ago we had AlphaProof and AlphaGeometry and all those things, and then this year we were like, “Screw that, we'll just chuck it into Gemini.” What's your reflection? This question about the merger of symbolic systems and LLMs was very much a core belief, and then somewhere along the line people just said, “Nope, we'll just all do it in an LLM.”

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, right? We have some distributed representation that's neural-net-like in some way, with lots of different neurons and activation patterns firing when we see certain things. That enables us to reason and plan and do chains of thought, and roll them back: “That approach for solving the problem doesn't seem like it's going to work. I'm going to try this one.”

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.

swyx

Interesting. Yeah. I mean, it may seem obvious to you, but it wasn't obvious to me a year ago. [laughter]

Yeah. I do think that IMO, with translating to Lean and using Lean, and then the next year also a specialized geometry model, and 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. 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 very similar to the 2013–2016 era of machine learning, right? It used to be that people would train separate models for each different problem. If I want to recognize street signs, I train a street-sign-recognition model. If I want to do speech recognition, I have a speech model.

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

swyx

And you don't need domain experts. One of my—so I interviewed Eli, 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. I'm good at training models.” [laughter]

It's kind of interesting that people with this universal skill set of just machine learning—you give them data and enough compute, and they can kind of tackle any task.

Yeah, right. [laughter]

swyx

A bitter lesson, I guess. I don't know.

Yeah, yeah. I mean, I think general models will win out over specialized ones in most cases.

swyx

So I want to push there a bit. I think there's one hole here, which is this concept of the capacity of a model. Abstractly, a model can only contain the number of bits that it has. God knows, Gemini Pro is 1 to 10 trillion parameters—we don't know—but the Gemma models, for example, are what a lot of people want: open-source, local models that are like that.

They have some knowledge which is not necessary, right? They can't know everything. You have the luxury of having a big model, and a big model should be capable of everything. But when you're distilling and going down to the small models, you're actually memorizing things that are not useful. So how do we, I guess, extract that? Can we divorce knowledge from reasoning?

Yeah.

I think you do want the model to be most effective at reasoning if it can retrieve things, right? 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. You might prefer something that is more generally useful in more settings than an obscure fact that it has. So I think that's always a tension.

At the same time, you also don't want your model to be completely detached from knowing stuff about the world, right? It's probably useful to know how long the Golden Gate Bridge is, just as a general sense of how long bridges are. 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. The bigger your model is, the more you can have.

But I do think combining retrieval with 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 models seem much more capable. If you think about, say, a personal Gemini—

swyx

Yeah. Right? We're not going to train Gemini on my email. Probably we'd rather have a single model that we can then use, with the ability to retrieve from my email as a tool, and have the model reason about it and retrieve from my photos or whatever, then make use of that and have multiple stages of interaction.

That makes sense. Do you think the vertical models are an interesting pursuit? When people are like, “Oh, we're building the best healthcare LLM. We're building the best law LLM,” are those short-term stopgaps, or—

No, I think vertical models are interesting. You want them to start from a pretty good base model, but then you can view them as enriching the data distribution for that particular vertical domain.

For healthcare, say—or for robotics—we're probably not going to train Gemini on all the possible robotics data we could train it on, because we want it to have a balanced set of capabilities. 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. Maybe that would hurt its multilingual translation capability but improve its robotics capabilities.

And we're always making these kinds 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.

Yeah.

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 are other long-tail computer languages or coding capabilities that it may suffer on. Multimodal reasoning capabilities may suffer because we didn't get to expose it to as much data there, but it will be really good at multilingual things.

So I think some combination of specialized models, maybe more modular models. It'd be nice to have the capability to have those 200 languages, plus this awesome robotics model, plus this awesome healthcare module, all knitted together to work in concert and called upon in different circumstances. 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.

swyx

Yeah. Installable knowledge. Yeah, right? Just download as a—

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

swyx

Yeah. And for listeners, I think I will highlight the Gemma 3 paper, where there was a little bit of that, I think.

Yeah.

swyx

Yeah. I guess the question is: how many billions of tokens do you need to outpace the frontier model improvements? If I have to make this model better at healthcare and the main Gemini model is still improving, do I need 50 billion tokens? Can I do it with 100? If I need a trillion healthcare tokens, they're probably not out there, or you don't have them. I think that's really the challenge.

I think healthcare is a particularly challenging domain. There's a lot of healthcare data that we don't have appropriate access to, but there are a lot of healthcare organizations that want to train models on their own data that is not 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 more bespoke but probably might be better than a general model trained on, say, public data.

Yeah.

swyx

Yeah. I believe, by the way, Alessio, this is somewhat related to the language conversation. I think one of your favorite examples was that 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 Kalamang, which is truly low-resource because it's only spoken by, I think, 120 people in the world, and there's no written text.

swyx

So—

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

swyx

Yeah.

Yeah. But I put your whole data set in context, right?

If you take a language like Somali, there is a fair bit of Somali text in the world that we probably are not putting all of into the Gemini base training. We put some of it in, but if you put more of it in, you'll improve the capabilities of those models.

Yeah.

Or of those languages.

swyx

Yeah, cool. I have a side interest in linguistics. I did a few classes back in college, and part of me thinks that if I were a linguist and could have access to all these models, I would just be asking really fundamental questions about language itself.

One very obvious one is the Sapir-Whorf hypothesis: how much does the language that you speak affect your thinking? But there are also some languages where concepts are not represented in other languages, while many others are just duplicates. There's also another paper that people love called “The Platonic Representation Hypothesis,” where an image of a cup, if you train a model on that and have a lot of text with the word “cup,” eventually maps to roughly the same place in latent space.

That should apply to languages, except where it doesn't, and that's actually very interesting: the differences in the concepts humanity has discovered that maybe English doesn't have.

I don't know. That's just my rant on languages.

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

What you found was that if you give it a novel image that is not in any of the categories in the image model it was trained on, the model can often assign the right label to that image. For example, telescope and binoculars were both in the training categories for the image model, but microscope was not. If you give it an image of a microscope, it can actually come up with something that has the word “microscope” as the label, even though it's never actually seen an image labeled that.

swyx

Oh, that's nice.

Yeah.

swyx

Useful. Cool. I think there are more general, broad questions, but what do you wish you were asked more in general? You have such a broad scope. We've covered the hardware, the models, and the research.

I did an undergraduate thesis on neural network training—parallel neural network training—back in 1990, when I got exposed to neural nets. I always felt they were the right abstraction, but we just needed way more compute than we had then. The 32 processors in the department's parallel computer could get you a little bit more interesting model, but not enough to solve real problems that people cared about.

Starting in 2008 or 2009, the world started to have enough computing power through Moore's law, and larger, 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.

When I started working on neural nets at Google in late 2011, I really just felt like we should scale up the size of neural networks we could train using large amounts of parallel computation. I actually revived some ideas from my undergraduate thesis, where I'd done both model-parallel and data-parallel training, and I compared them.

I called them something different. It was like pattern-partitioned and model-partitioned or something.

swyx

We’ll have to— is it public? Can we go dig?

Yeah, it’s on the web.

swyx

Okay.

I think combining a lot of those techniques and really just trying to push on scaling things up over the last 15 years has been really important. That means improvements in the hardware, so pushing on building specialized hardware like TPUs. It also means pushing on software abstraction layers to let people express ML ideas effectively. And then also working on things like sparse models.

swyx

Yeah.

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, as we discussed earlier, to remember a lot of stuff. But you also want to be super efficient in how you activate your models. You’d like trillions of parameters but activate only 1%, 5%, or 10% of them.

We did an early MoE paper on this—“Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer”—where we really scaled up outrageously large neural networks. The title, I think, was Noam’s wording, which is a good, catchy title.

swyx

I mean, in 2017, he was out there talking about 1-trillion-parameter models.

Yeah. That is really good because it gave you a 10x improvement in time to quality, or compute cost to quality at a given quality level, relative to nonsparse models. Transformers similarly gave you a 10x to 100x improvement in compute cost to a given quality level versus, say, LSTMs at the time. All of those things multiply together.

I think all those things are really 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 stacking together and multiplying together.

swyx

To give us models of 2026 that are much better than models of 2025, and awesomely better than 2024 and 2023. And a huge, honestly, organizational challenge: there are like 1,000 people, or maybe more. I know when the first Gemini paper came out, it had like 1,000 coauthors.

Yeah. We have 10 pages of coauthors in the technical report.

swyx

But it was nice. People want to be acknowledged on probably a historical paper.

Yeah. I think it’s perfectly good to have a lot of coauthors, and I do think—

swyx

Organizing that number of people so that they’re effectively pushing in common directions, and so that all their work actually sort of multiplies together in the ultimate output, which is the next generation of the model, is actually pretty tricky.

And we have awesome people throughout the Gemini team to help orchestrate this. Myself, Noam, and Oriol are sort of helping steer this. Then we have people thinking about what the pretraining setup looks like, what the infrastructure looks like, what the post-training recipe looks like, and what the data preparation and eval look like.

We have people focused on multimodal capabilities, reasoning capabilities, coding capabilities—all these areas are super important. It’s really good to have people paying close attention to those things and also paying close attention to all the other things.

swyx

Yeah. I’m told Sergey is very actively back and very much involved in coding stuff.

Yep. Yeah. We all use the same microkitchen.

swyx

Yeah. Uh-oh. There are so many jumping-off points. 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 microkitchen.

Yeah.

swyx

Just like your microkitchens are very important.

Yeah. I don’t know if people understand.

swyx

Yeah.

I actually bumped into Andrew Ng, who’s a Stanford faculty member. I knew him because I’d given talks at Stanford a couple of years before, so I sort of knew him. I said, “Oh, what are you doing here?” He said, “I’m not sure yet. I just started a couple of weeks ago. I’m going to spend 1 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 using neural nets for speech recognition.”

I said, “Oh, neural nets. I like neural nets.” I remembered my 1990 thesis. I thought, “Oh, that sounds interesting. We should train really, really big neural nets.”

swyx

Which, when you say that, is a very interesting first instinct: that we should scale this up a lot.

Yeah. Well, I felt like Google has lots of computational capability, so if they were seeing good results on what were effectively single-GPU models, we could build a software system that would enable us to distribute with both model parallelism and data parallelism across lots of computers.

We ended up training a pretty big model. It was 50x bigger than any previous neural net, as far as we could tell. It was a 2-billion-parameter vision model trained on 16,000 CPU cores for multiple weeks.

That gave us really good results. It gave us a 70% relative error improvement on ImageNet-22K, which is the 22,000-category version. That’s how we really saw that scaling this up actually matters. We didn’t write a sophisticated scaling analysis, but we had a saying: “Bigger model, more data, better results.”

swyx

That was our mantra for 6 or 7 years of scaling. Every time we did that, we saw better results in speech, in language, and in vision. Speaking of bets, this might be a little bit more sensitive of a topic, but you obviously have a lot of opinions about this.

We had a previous guest, David Luan, who used to work for you, and he kind of blames the Brain marketplace as the reason Google didn’t invest enough in language models. I wonder if that’s something you would agree with at the time, or if there’s a different sort of postmortem.

The Brain marketplace for computers—

swyx

Compute quotas. Basically, he was like, “Okay, OpenAI was willing to go all in, bet the farm on one thing, whereas Google was more democratic. Everyone had a quota.” If you believe in scaling as an important thing, that’s an important organization-wide decision to make.

Yeah. I would somewhat agree with that. I actually wrote a 1-page memo saying we were being stupid by fragmenting our resources.

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. Legacy DeepMind had efforts like Chinchilla models and Flamingo models.

We were fragmenting not only our compute across those separate efforts but also our best people and our best ideas. I said, “This is just stupid. Why don’t we combine things and have 1 effort?”

swyx

And this is the merge.

To train an awesome, single, unified model that’s multimodal from the start, that’s good at everything. That was the origin of the Gemini effort, and my 1-page memo worked, which is good.

swyx

Did you have the name? Because, for those who don’t know, you named Gemini.

I did. There was another name proposed, and I said, “It’s sort of like these 2 organizations really are like twins in some sense coming together.” I kind of liked that. Then there’s also the NASA interpretation of the early Gemini project being an important thing on your way to the Apollo project. It seemed like a good name: twins coming together.

swyx

Right. Nice. I know we’re already running out of time, but I’m curious how you use AI today to code. You’re probably one of the most prolific engineers in the history of computer science. I was reading through the article about you and Sanjay’s friendship and how you work together.

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

I was thinking about how you think about coding agents in this. How do you shape a coding agent to be compatible with your way of thinking? How would you rate the tools today? Where should things go?

First, I think the coding tools are getting vastly better compared to where they were 1 or 2 years ago. Now you can actually rely on them to do more complex things that you, as a software engineer, want to accomplish, and you can delegate pretty complex things to these tools.

One really nice aspect about the interaction between a human software engineer and a coding model they’re working with is that 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.” Your way of doing that is going to shape how the model responds, what kinds of problems it tackles, and how much you want the model to go off and do things that are larger and more independent versus interacting with it more to make sure that you're shaping the right kinds of things.

I don't think it's the case that any one style is the right thing for everything. Some kinds of problems actually call for more frequent interaction with the model, while others are more like, “Yeah, please just go write this, because I know I need this thing and I can specify it well enough. Go off and do it, and come back when you're done.”

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 for when they should 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, the set of decisions you put into how the interaction should happen may change. If you have a team of 50 interns, how would you manage that if they were people?

swyx

Do you want 50 interns?

You might if they're really good, right?

swyx

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. How would you actually deal with that as a person? You would probably want them to form small subteams so you don't have to interact with 50 of them. You could interact with 5 of those teams, and they're off doing things on your behalf. But I don't know exactly how this is going to unfold.

swyx

Yeah. How do you think about bringing people in? Pair programming is always helpful to get net-new ideas in the distribution, so to speak. As we have more of these coding agents writing the code, it feels hard to bring other people into the problem.

Say you have 50 interns, and then you want to go to Noam Shazeer and say, “Hey, I want to pair on this thing,” but now there's this huge amount of work that has been done in parallel that you need to catch him up on, right? I'm curious whether people are going to be, in a way, more isolated in their teams, where there's so much context in these 50 interns that it's hard for me to relay everything back to you.

Maybe. 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 5 people each managing 50 virtual agents, they might be able to have much higher-bandwidth communication among the 5 people than you would have among 5 people who are also trying to coordinate a 50-person software team each.

swyx

Yeah. How do you change your working rhythm? Do you spend more time ahead with people going through specs and design goals?

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.”

Writing the English-language specification was never an artifact that was really paid a lot of attention to. It was important, but it wasn't the thing that drove the actual creative process quite as much as it does when 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. 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.

The better you get at interacting with these models—and I think one of the ways people will get better is by getting really good at crisply specifying things rather than leaving things to ambiguity—that is actually probably 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.

swyx

Yeah. My joke is that good prompting is indistinguishable from sufficiently advanced executive communication. It's like writing an internal memo.

Yeah. Yeah.

swyx

Weigh your words very carefully. Also, I think it's very important to be multimodal, right? One thing that Google Antigravity did was come out of the gate very, very strong multimodally, including videos, and that's the highest-bandwidth communication prompt that you can give the model, which is fantastic.

Yeah. How do you collect things that you often would have in your mind? You have this amazing performance-hints thing that you wrote about how to look for performance improvements. Is there a lot more value in people writing these generic things down so that they can then put them back as potential retrieval artifacts for the model?

The edge cases are a good example, right? If you're building systems, you already have specific edge cases in your mind depending on the system, but now you have to repeat them every time. Are you having people spend a lot more time writing out generic things to bring back?

I do think well-written guides on 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 clearer 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 use to deal with failures.”

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

swyx

Yeah. Yeah. I wonder when Gemini will be able to build Spanner.

Probably already has the code inside.

swyx

Yeah, I mean, that's a good example, right? When you have the CAP theorem and it's like, “Well, this is truth and you cannot break that,” and then you build something that broke it. I'm curious—models, in a way, are like—what did he say? He broke it? Would you say you broke the CAP theorem?

Really? Yeah. Okay. All right.

swyx

I mean—

Under local assumptions, yeah. And some of them are, you know, good clocks.

swyx

Yeah. Sometimes you don't have to always follow what is known to be true. I think models, in a way, if you tell them something, they really buy into that.

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

swyx

Yeah. My big thing on prompting and iteration is that, coming back to your latency point, one A/B test, experiment, benchmark, or research project I would like is: What is the performance difference between, let's say, 3 dumb, fast model calls with human alignment—where the human looks at the first one and produces a new prompt for the second one—as opposed to specifying it out, spending a long time writing a big, fat prompt, and then having a very smart model do it?

Is a lack of performance really an issue of, “Well, you just haven't specified it well enough”? There's no universe in which I can produce what you want because you just haven't told me. It's underspecified, so I could produce 10 different things and only 1 of them is the thing you wanted.

Yeah. The multi-turn interaction with a Gemini Flash model is enough.

swyx

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

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

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

swyx

Yeah. Yeah. There are two extremes, right? And then meanwhile, you also have Deep Think, which is all the way on the other side.

Right? But you would use Deep Think all the time if it weren't for cost and latency, right? If you could have that capability in a model because the latency improvement was 20× in the underlying hardware and system, and costs were lower, 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.

swyx

Yeah. You know, the Pareto curve keeps climbing.

Yeah.

swyx

Onward and outward, in a way. [laughter]

Yeah. Should we ask him for predictions to go? I don't know if you have any.

swyx

Predictions that you like to keep? One way to do this is, you have your tests whenever a new model comes out that you run. What's something that you're not quite happy with yet that you think will get done soon?

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 the 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.

swyx

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, 100 now. Yeah, we can go to the thousands. Is it meaningful to go 10,000?

Yes.

swyx

Really? Okay.

Absolutely. Right.

swyx

Yeah. Because of chain of thought and all—

Chain-of-thought reasoning. You could think 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.

swyx

Yeah. At 10,000 tokens per second, you are no longer reading code. You'll just generate it. You won't remember it. It may not—

End up with 10,000 tokens of code—a thousand tokens of code with 9,000 tokens of reasoning behind it.

swyx

Yeah. Yeah.

Which would actually be probably much better code to read.

swyx

Yeah. Yeah.

Yeah. If I had more time, I would have written a shorter letter.

swyx

Yeah. Yeah. Awesome, Jeff. This was amazing. Thanks for making the time.

Thank you. It's been fun. Thanks for having me.