Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI

0:00In hardware, again, as you know, there is this opportunity where the more you specialize to a particular workload, the less flexible it is, the faster, the more power efficient the hardware is going to be. So, it is this art, and it's this projection of what are you designing to, and how persistent is that workload. In other words, if it's going to go away after a month or 2 months or 3 months, even if it's big for those 3 months, you got a really narrow window to intercept it. So, it has to be

0:28somewhat durable. Uh and you have to be able to project [music] exa- exactly what win you can get for specializing to it.

0:40[music]

0:52Thrilled to welcome Amin Vedat to the show. Amin, thank you for joining us for today. It's really exciting to be here. I'm really looking forward to it. I am very excited for today's topic because we are in the middle of the biggest capex build out in human history. You are in the middle of it. Google alone is expected to spend more than $200 billion on capex this year, most of which is going into building data centers. Uh you're at the center of it all. You were named the head of Google's uh AI infra at the end of last year. Um so, you are the man spearheading the efforts uh of one of

1:25the most capital intensive build outs in in human history. And so, I am really excited to get into it with you today. It's a huge year uh for sure, of course, across the industry, including at Google. Uh really have I don't think we've ever seen anything like this, honestly. Certainly not at Google, but as you said, uh I think in the history of humanity in terms of the build out and the pace of transformation, really

1:46unbelievable. Before we get into it, maybe just just crash course for the audience, what is an AI data center, and how how how is it different from a non-AI data center? It's a very good question uh in that uh AI data center and a non-AI data center have do have a lot of similarities actually and they're they're not radically different. I mean it consists of concrete, right? An enclosure. It consists of electrical yards, mechanical yards, cooling. You have row

2:12after row of power being distributed. There's a huge amount of network infrastructure there. In other words, we connect large amounts of computes to one another. A fair amount of storage infrastructure goes in there. I think that the big difference that we're seeing with AI infrastructure is specialization. In the past when we're building a data center,

2:33it really is a 20 25 30-year building. Investments and we're thinking about how it's going to be evolving over that 20 25 30-year period. You might have servers going to it. You might have networking, storage. You might have some accelerators, GPUs, TPUs, whatever they might be going into it. But it's a 25 30-year planning horizon. So we have lifetime of the hardware might be 6 years. So many generations that we have

3:01to plan for. An AI data center often times is going to be more purpose-built. So in other words, we are often times co-designing the building with the hardware that might go into it. We might be saying, you know what actually, we're not going to put a lot of storage into this building. Why? Because a storage rack might have

3:2310 20 30 40 kilowatts of power. You put that next to a TPU rack or a GPU rack that easily is hitting hundreds of kilowatts today. Might hit megawatts. People are talking about that in the next few years. Designing a building that might take 30 storage racks in a row versus one or two AI racks in that same row, very very different design. Just think of it in terms of the size. Think of it in terms of the power and how that would be

3:53distributed across uh the building, etc. Networking would be the same. The amount of networking that you would need for a storage rack, tiny. I mean, if especially if it's hard drives, compared to an AI rack. So, if you're trying to make it fully fungible, you'll probably make it too big and too overbuilt. Fungible over a certainly a a

4:1230-year period. An AI data center likely is going to be much more purpose-built, co-designed with the hardware, even to the point cooling and power distribution, etc. So, a lot more co-optimization. You all delivered a big Vera Rubin cluster to one of my portfolio companies, Ineffable Intelligence, and I saw the photographs of it as it went

4:35out. That was a thing of beauty. It is. It is. It's It's I mean, this is this is one of those things where, you know, similar to looking at the biggest construction projects in human history, you look at that data center and it's like, "Wow, that is a moni- monument to what what mankind can do." No, we got a a nice picture of it and it and this is just you know, a a couple of racks, you know, the the cabling, the fiber distribution for it is is really beau- I mean, you got beauty's in the eye of the beholder, but for folks like me and probably yourself and others in

5:02the audience as well, it is a thing of beauty. We put this picture up on social media and people love the fact that Ineffable, by the huge fan of what what they're doing, fantastic team. That got a lot of attention. Okay, great rack for Ineffable, but actually people just loved seeing the the pictures of the fiber and the sort of the fractal nature of it. One of the most popular posts that we've ever had actually was around that. So, so yeah, absolutely. We're really really excited

5:28about that. Yeah, I had goosebumps seeing the picture. Mhm. How do you measure and hold yourselves accountable in this in the middle of this big buildout? And we were talking right before the show about how FLOPS is a vanity metric and you prefer an alternate metric. Can you can you say more? Yeah, so I think one thing to note is that, you know, whether it's flops or pick your other favorite chip centric uh metric,

5:52these are in theory. In other words, under some conditions for whatever chip you have, this is the maximum amount of flops that you can deliver. What we really care about in the end is what's the performance delivered by workload. Like that's that's what we're looking at. So then rarely it it happens, but actually relatively rarely, is that

6:11performance determined by a single chip. It's flops, it's HBM, it's SRAM uh capacity, etc. Those are all super important, but it might be how 2 4 8 16 1,000 10,000 more of these chips composed together with not just the accelerators again, whether TPUs or GPUs, but then the CPUs that might feed them the data, the network that connects them all together. So, what is the workload that you're running and what is the

6:41performance that workload? One measure that is interesting is what's your flops utilization? So for example, for a particular workload, if you have in theory a teraflop or a petaflop capable for your workload, which fraction of that are you delivering? Now, that's a measure of good put. What what is good put? So you can think of throughput, which is

7:02a well-known term. Yeah. That's the throughput that is possible, but now let's consider some uh other considerations. One is what is the slowdown of the workload again, just inherent to the workload, but other aspects of it that really hits are reliability. So in terms of how we hold ourselves accountable, if we have a chip failing for a synchronous workload, and many of these workloads, whether training or serving or agentic workloads, they're synchronous. There's many, many components that are working together

7:32simultaneously. Now, if you have let's say 1,000 10,000 100,000 of these components working together simultaneously and they're really needing to coordinate at microsecond or millisecond granularity. One of them fails, it might actually bring the whole thing to a stop. Right? Because everyone is counting on everyone else to do their part of the job in order to come up with the answer to a really tough question. One of them stops, okay, now we have to figure out what happened, which one stopped, what's the checkpoint that we have of the computation at some previous state in

8:03time. How do we restore that checkpoint? How do we restart? Worst case, we have to restart from the beginning. That would be really bad, but that that can happen in certain cases, especially on more on the inference side. The point here is that if you now then have to go back and redo a bunch of computation, if you then have to pause and wait for to figure out what happened with the failure, all that work is work. It's not actually

8:26helping you get the answer. Right? The in terms of let's say that you're working out a problem on paper. Step one, step two, step three, step four. If you have to go back to step one because you you made a mistake, yes, you're still doing work. That's throughput. You're doing work, but what is the good put in delivering your answer? It's basically the total amount of time it took you to solve the

8:48problem. That's That's what matters. And if you have failures, if you have failure recovery, if you have whatever it is that's interrupting your work, that's that's part of the issue. So, now how do we hold ourselves accountable? It's delivered good put, not theoretical benchmark throughput or goodness in theory, but actually for a workload, for real failure what's happening. And the unfortunate reality is that at a 100,000 accelerator scale, I was going to say at that scale

9:17something's failing all the time, right? the time. And And these each one of these, as you're aware, each one of these chips is a wonder of nature. I mean, they're at the very bleeding edge of what's possible to manufacture. Right? And so, again, to to me it's a stunning. And now actually these chips aren't just one chip, they're packages made up of in many cases two, four, eight, maybe more chiplets, right, that are composing together. And then of course HBM off to the side, network connectivity, maybe things like co-packaged optics. No criticism, lots of things can fail. And now if you got 100,000 of them, something is going to

9:54fail. You have to be prepared for that, detect that in near real time, recover from that in near real time. Doing all that is it's really like finding the the telemetry problem is massive. It's like finding a needle in the haystack continuously across certainly seconds and minutes, but for some of these jobs, hours and days and

10:13even weeks. Like just a continuous and online. How we hold ourselves accountable is what's the good put that we deliver for the workloads that actually matter in the data center. Is good put a Google term or is it an industry term? It's a Google term, but I think more and more people across industry are starting

10:30to pick it up. And then just to calibrate me, 100,000 accelerator scale, are we talking it's going to fail once a minute, once a once a day? Like how how often 100,000 accelerators, so let me see. I think that it is definitely going to be at the scale multiple times a day and perhaps depending on the exact configuration, multiple times an hour,

10:51something is going to fail. And what are the most common failure reasons? This is the problem. Actually, it's a very good question. If there were a common failure reason, we'd be we'd have figured it out and and fixed it. It is a long tail of constant discovery. You know, whenever we have a new product that's being introduced, there's going to be something that hits

11:10us. In many cases, frankly, because again it's at the very bleeding edge, it might be network related. It might be how we connect these things together at super high speed. It might be something to do with the hardware. Those things we work through. But then a lot of the issues could be software. So this is the other aspect of how we hold ourselves accountable. Again, the chip might be capable of a certain level

11:32of flops. But if you have a compiler bug, a runtime bug, a model issue, something else, operating system issue, it doesn't matter. That that's going to impact the end-to-end system performance. So, you might have perfect hardware, fully reliable, but then you might have software issues uh that hurt you. Mhm. Is there a standard reference stack from the accelerator companies from Nvidia or from the TPU team of, you know, here is the optimal system to build around our accelerators? And as long as you build to that system, you're you're good or how much of your own kind of data center design do you have to do above and

12:08beyond what the what the semiconductor companies give you? Uh right. So, there's a there's a reference stack. And I mean, I would say that's uh Nvidia is a uh incredible uh whole systems uh company. I I I mean, they're obviously semiconductor company, but they're not just a semiconductor company. They give you a really really strong reference stack. But I would say that um many and we find that uh the way I'd put it is most of our customers leverage that reference stack,

12:35but many also specialize. So, in other words, they might find that as as natural for their particular use case, they have an optimization opportunity or something different that they need to do. And they're going to do that. Similarly for the TPU side, we have a reference stack. But then and most people will leverage that, many

12:52will specialize it as well though. Got it. And then I guess in terms of overall capacity, you've told your teams that Google has to roughly double the serving capacity every 6 months or so, is that right? Well, so and to be clear, uh this is in terms of effective available capacity from the way in the end that we look at it is from a serving perspective, it's token

13:16generation capability. So, capacity and this is where I would say it's a combination of software and hardware. The hardware might have some {quote} inherent level of flops. What I'm saying here is not necessarily you have to double the number of flops every 6 months. That's one one path. You have to double the capability of that hardware to generate tokens every 6

13:37months. And as much or more of that is going to come from software as it is from uh hardware. So, in other words, it could be a model optimization that delivers that. It could be some runtime optimization that uh delivers that. It's really probably going to be dozens or hundreds of individual optimizations that are just landing again and again and again to make it all possible. But yes, the rate the rate of capacity improvement is

14:02incredible. I mean, I I guess we've had a few years of data center build-out now and a few years of model progress and software progress. What has been the empirical breakdown of how much um capacity maybe as measured by intelligence per watt, how much capacity increase has come from the silicon itself uh versus the models uh versus soft- other software and and

14:25any other kind of big components? Yeah, so it's a really good question. Um I don't have the exact breakdown, but I would say that uh in our experience most of the benefits come from model side improvements in terms of intelligence per watt. And by the way, the intelligence per watt is a fantastic metric. Uh you're really focusing. We we also for us it's um good put per watt, and we can come back to why the watts need to be the denominator. Good put could well be a measure of the intelligence delivered per watt. In other words, good put is a workload-specific metric. But I would say most uh of the gains often come uh

14:57come from the model side. Software system um quite a bit. Why? Because they're able to actually make sure that the hardware that you have is being used effectively. And then the hardware it it is pretty stunning. In other words, we're living in a world right now where 2x or more year-over-year performance improvements is absolutely possible. And so, the hardware does does support it, and it it is a If you want, it's a free multiplier, not free. Not But everyone else above it can count on it in terms of that being a multiplier that lifts everyone else up

15:31year over year. I'd love to talk a bit about the TPU program and and code design. So Google started building custom silicon more than a decade ago. It was contrarian call at the time. How is the TPU program evolved? Quite a lot. I mean when the program started 2013, it was really a contrarian call. And I mean I think that at the time it's hard to put yourself back into the moment 2013, conventional wisdom, you know, all the smartest, wisest people would say you don't build a custom built accelerator for a a single

16:02workload. Why because Moore's law is there, doubling of performance every whatever it is 18 or 24 months is there. You get to leverage standard programming models, all your C++ code, etc. Java, Python, whatever it might be is bitter lesson of chips. Yes, exactly. It's like the bitter lesson of chips is that's specialization never wins. But in in this particular case, it was we have this one application or or few, a small number of them that would benefit tremendously and that would require an unimaginable amount of general purpose CPU to

16:34support. So really in 2013, it it was a bet and there were quite a few people even within the company, I would say, who were not sure that it would work out. So it was a bet, it turned out to be a massively successful bet. So the first chip was all all about inference. The second chip was hey, actually we can take the same idea and build a training

16:59chip. From from there it got picked up for more and more use cases. Around the time the second chip came out, transformers were invented. And this this was a major major moment and that actually completely shifted the TPU program. We of course learned that recommender systems could run really really well on the TPUs and so add some related use cases came along. So, I would say the change and evolution has been one of expansion in scope and impact. In other words, start with a really impactful use case of a couple of applications for inference serving. This was language translation primarily

17:39and voice recognition. To then training to then transformers, recommender systems and containing to generalize as I guess the GenAI moment took a hold to ever larger, ever more scalable systems as well. You mentioned the moment the transformer came through being a a major moment and I'm curious to explore the TPU was like a specific architecture but it wasn't, you know, specific to the transformer specific. How do you kind of straddle the fine line of you know, how specific you want your

18:12chip to be for the workload? This is a great question and I think that it really comes down to the applicability. I mean, I think that um uh of the of the chip to particular workload. So, in other words, in the end, we've been thinking about this for every generation. Would we further specialize? The question that we were facing, let's say um 2 years ago or a little bit more was in 2026, should we have two chips or one? We could have one chip that could do inference and training simultaneously and do both quite well or we could have two chips. One that was further specialized for inference and

18:48the second one that was further specialized for training. This analysis and this work led to the release of two chips this year. 8I for inference, 8T for training and in the end, what we realized is that it wasn't the case necessarily a couple years ago but by '26, we we saw inference and serving

19:06really taking off. And so, having a chip that would be significantly faster for serving that we thought might be 30, 40, 50, 60% of the market in its lifetime, started making a lot of sense for us. Relative to if if inference if we projected inference to be 2% or 5% of the market, even if that specialized chip is, let's say, 2x faster,

19:32it might not make sense. Right? Because you'd actually go for the one general purpose chip that's not fully optimized, but that that's okay because you now have the uniformity, etc. So, really uh it does come down to a calculus question of, "Okay, would you further specialize? How big is that workload? How big is that workload projected to be in a couple of 3, 4 years? Is this a um sustained growth for a particular

19:57workload? In hardware, again, as you know, there is this opportunity where the more you specialize to a particular workload, the less flexible it is, the faster, the more power efficient the hardware's going to be. So, it is this art and it's this projection of what are you designing to and how persistent is that workload. In other words, if it's going to go away after a month or 2 months or 3 months, even if it's big for those 3 months, you got a really narrow window to intercept

20:25it. So, it has to be somewhat durable. Uh and you have to be able to project ex- exactly what win you can get for specializing to it. So, the rough trade-off is there's a thick a large fixed cost to support a new program. Yes. And you basically have to think that there's going to be enough demand for that specific program to justify the

20:46cost. Exactly. And uh to some to some extent, you know, for example, for our 8i and 8t chips, both chips can do the other workload. This is also key. If 8i could only do inference and it couldn't do training at all. Like in other words, it had zero performance for training. And then vice versa, if 8t was amazing at training and had zero performance for inference, that would

21:07have also been a key limitation. Why? Because we would have to predict ahead of time over 6-year period, lifetime of the hardware, exactly how much we need of each. In this case, it was nice because both chips are better at what they're specialized for. But if you needed to, if you had leftover capacity in one place or the other, both can actually do the other other's job. Depending on the specialization you do, you might get so specialized that you actually limit

21:31yourself from being flexible, fungible. And if the rough trade-off then is kind of size of program on the other end, like it seems to me that so much of the modern AI market is transformer based. And so maybe just ask a provocative question, why not just burn the transformer architecture into the chip? Yeah, so I think that's it's transformer based, but then the next level of question would be transformers in the end are about the

21:57vector and matrix multiply operations. And you know, a soft max, so there's a range of essentially linear algebra We have those and others do as well, roughly baked into the hardware. It's all transformer based, but then it's your model architecture is, okay, how many layers do you have? How do you go through the layers? How do you go across the layers? How for each dimension, what exact shape of matrices and vectors are you applying? You you could go further and specialize to not just the transformer, but your model. That's the next level of specialization. I think there are a number of companies out there that are I think about that. I

22:35think it's a very very interesting direction as well. Okay, so at this point in time, do your customers view TPU and GPU as roughly fungible equivalents or is there is there a certain set of problems that is better suited for one or the other? There's for sure better set of problems that are better suited for one or the other. I mean, GPUs are more general purpose than TPUs for for one. That that is clear. I mean, there are incredible products at Google and

23:01Google Cloud. We we sell a lot of GPUs. We use GPUs internally, but I think it really then comes down to the specifics of your problem. I So, I think that our customers there there is overlap between the two, but our customers then evaluate their workload and evaluate their options. What we like to do at Google is give our customers choice. In other words, we want to have the right solution for their needs and of course provide the solution that that

23:27best meets their needs for them. What is the case for co-design from the chips to the network to the software? And then what is the case against co-design? Yeah. So, there's huge optimization opportunities with co-design. And so, what you can imagine is that if you have a N-layer stack and you want to be able to pick and choose whatever component you want. Let's Let's say you're running across many clouds or you're running across many pieces of

23:56hardware, many pieces of software. You could design abstraction That would basically say, "I can run on any hardware. I can run on any software. I can run on any network topology, any amount of network that you give me. No problem. And my system is going to be fully adaptive." Very likely, so now you have a great capability. You can move anywhere. Like new capacity becomes available, overnight you're up and running because you've designed your system that way to actually be able to take advantage of anything. You have not hard-coded or specialized at all to anyone's

24:29particular infrastructure. Downside is you probably leave a lot of performance on the table. If you become fully fungible, if you become fully flexible to anybody's hardware, software, network, storage, computes, that's etcs stack. So, the case for co-designing is between each one of those layers um there's a big impedance mismatch if you try to get full generality. And so, there might be 10% 20% 2x across each of these layers, you start multiplying those optimization opportunities through, and all of a sudden you're left with a big end-to-end opportunity in terms of whatever you want to say, intelligence per watt or throughput per watt, that you can leverage even again all the way down to

25:14power delivery and power availability, software optimizations, etc., etc. So, pros are um you can run anywhere, anytime. You have no lock-in. Cons are you're leaving um significant and in all likelihood significant amounts of performance on the table. Hm. So, my understanding is that if you take Open AI and Anthropic, um Open AI was kind of primarily building on a uh homogeneous compute stack, and then Anthropic was building a roughly more heterogeneous compute stack. Do you think that's part of the reason that co-design is part of the reason why they converged on what is rumored to be very different architectures for their

25:54models? Um I can't I can't speculate. I can't I don't want to speculate in terms of what Open AI and Anthropic are doing. It's just one one possibility, uh but I think that uh without knowing the details of what they're doing, I would imagine that there could be many reasons for why they wind up with different architectures. Well, what about for Google then? I'm curious what the working relationship looks like between your team and DeepMind? Kind of who's in the room at what stage of model development? And how are you making decisions together on

26:23co-design? It's one of the most fun and frankly gratifying parts of being at Google is the opportunity to work really shoulder to shoulder with DeepMind team in terms of co-design of our hardware and models. There's a third element to it in in terms of that we also get to extend that with the consumer services and cloud. I'll put that aside for a moment. I can come back to that. But with respect to DeepMind, it it really is a deep partnership. So, let me I mean, from the past I can give you examples where uh they have come up with

26:55model optimizations. Um let's say two transformers or to particular math that they might want to do and we might have a chip in progress not quite done. But then they say, "Oh my gosh, if we had hardware support for this our end-to-end training or serving might get significantly faster, more efficient. What would it take to actually now change our hardware definition? Now we might be in execution on to

27:22accommodate." And this then leads to our engineers from and researchers to getting together intensely in the same room for a few days, a week, two weeks saying "Okay, yes, we can do this. More likely we couldn't quite do what you wanted. But we can do this other thing. And then maybe you can change your model architecture in this other direction that gives you 98% that gives us 90% of what we were

27:51looking for. And yes, we can then go back and intercept the hardware. And or we can say, "You know what? We're going to delay the tape out by a week or two weeks because wow, for this level of benefit, it's it's totally worth it." Yeah, similarly when we're um projecting our road map out and it's time for you know, we we we have many generations of chips that are essentially in progress at any one point in time. We have the chips that are in production, that's one. We have the chips that we're working on getting into production, they're already back from the manufacturer and we're debugging

28:23them, making them work. We have the chips that are in implementation that are about to tape out and go to the manufacturer. We have the chips that are in design phase. And then we have the chips that are in concept phase. So it's really this five, six stage, many, many year pipeline from in production to in your mind, etc. The collaboration with DeepMind for in

28:47production of significance. Because we get to work together in maximizing delivered intelligence or delivered good foot per watt. And we know exactly what's happening in the model, and we know exactly what's happening in the hardware, and everything in between. We also get to collaborate deeply on though the chips that are actually just about to tape out.

29:05Why? Because we can intercept. And we can make changes to the chip literally the chip architecture in flight, which would be somewhere between hard and impossible if we were working across company boundaries. Not not impossible, but it would be much harder, right? For us to say, "Oh my gosh, we're a few weeks or a few months away from getting this chip done, and now let's get in the same room shoulder to shoulder and figure out if we should disrupt the program." It's possible, but

29:32but harder is what I would say. And then of course for the chips that are in design, we have many architectures we can evaluate together. We can then ask our colleagues in DeepMind, "Where do you see model architectures going? In 2 or 3 years' time? Here's the Pareto of things that we can do. Here's the Pareto of where model

29:52architecture's going. We have uh actually deep and significant simulation infrastructures that can predict how the workloads are going to map to uh different hardware architectures. Deep deep and fast iteration. It really isn't the teams are working separately. It's in in uh same building, same rooms many times. Deep daily interaction. I talk to whether it's Koray or Demis multiple times a week uh etc. So, it it really is a a super fun aspect of the

30:23work. That's awesome. And eventually their models will help with with chip design. We're using Gemini to design uh hardware for future Geminis as well. That's really cool. I want to come back to that a little bit later. On the collaboration itself, I guess is there an impedance mismatch still of just I figure the cycle times are probably just slower when you're when you're dealing with hardware than than than than your DeepMind folks get to deal with on the software side. And I figure your planning cycles are much

30:49further ahead. For sure. Um and so how much room do you actually have to adjust? Yeah, it's it's a really good question. I mean, we are planning hardware two, three, four, five years in advance. No no question. In other words, we talked about TPU 8, I and 8T uh just now that we uh announced, but you can imagine that uh 9, 10, and maybe some others are are in in uh concept to execution to

31:11something else. And so they and they might be um years out. If you're working with model architecture, by default, you're not going to be thinking years out. Yeah. But I think this is also the great thing about how the company has grown up together. And you know, in other words, Google Research and DeepMind and Transformers being invented, all of this was happening in in these overlapping rooms as well. So in other words, there's a whole generation of researchers who've grown accustomed to being able to influence

31:39the hardware. And knowing that the hardware is operating on multi-year cycles. And they also know that look, if they have a small tweak that's going to deliver like 1% or 0.5% or something like that for a chip that's about to tape out, they're probably not going to come to us. Because then they they know enough to know that actually it's not like software where you can just do a change list and it's going to ship to production in 2 weeks' time. Like it actually stopping a tape out is a

32:03big deal. But they also know if they've got a big like a a really good opportunity, the yes, we're absolutely going to work together to figure out if we can get it in there. So um as I said, it's multiplicative in terms of where the benefits come from. The hardware does lift all all the tides, right? And so significant portions of the DeepMind team, as we're so grateful for it. It's an amazing team. But significant portions of it are thinking about how do I influence the road map? Because it's actually a pipeline. Like the idea I had 2 years

32:35ago, like it's in production now. And it's helping all the workloads at Google go faster. Like, that's a good feeling. Totally. It seems like an impossible task though to predict in 5 years what workloads will be most common and what algorithmic breakthroughs will have occurred. Uh doesn't it seem like an impossible task? I hear you that it would seem like an impossible task, but here's the awesome thing. And actually we're working on writing this in great great detail and it's a lot of fun to do it. The stunning thing is that um the TPU architecture at a medium level of detail, not at a super high level of detail, at a medium level

33:12of detail hasn't really changed since TPU V1. Like, one way to look at it is the instruction set architecture for a CPU. Like, you've got loads and you've got stores and you've got adds and you've got subtracts and branches and like and yet what has the software on top of it done like over over that period of time? Same thing with TPUs. We have some fundamental instructions and some fundamental primitives. Of course, we've extended it. It's not like the instruction set hasn't gotten changed at all. But, the primitives there in terms of specializing the numerics to very big very large matrix multiply units, um a sparse core that manages

33:52vector operations and scatter gather operations, etc. There's five or six things that really define a load remote load store. That's another one. Actually, we can read and write remote memory through our ICI network. The fundamentals have been there and they've extended this to many generations of models, many generations of even deep neural network

34:14algorithms and model structures. Okay, speaking of shifting workloads, it seems like one of the biggest changes in workloads over the last year or so, I think it really started at the beginning of this year this calendar year was kind of the rise of the long horizon agents. Yes. And I would guess that's a a different shape of workload than kind of the quick turn LLM conversations of of years past. Um what does that mean in terms of data

34:37center needs? Yeah, so I think the one uh there's two huge aspects to this. One is it's no longer human to um whatever you want to say accelerator interaction. In other words, when you are typing at uh prompt on a on a web browser or on your phone or whatever, uh of course in response to your prompt there's going to be a bunch of work that happens. But then when the response

34:58comes back, you've got to read it. You've got to think about it and then maybe you have a follow-up. That's going to be multiple seconds of interaction time. Now on deep horizon agents, it's not there's no human loop that is going to naturally rate limits how quickly requests are going to go to the model, right? So this will what went from, you know, seconds, maybe tens of seconds in terms of inter- interaction time is now

35:20going into perhaps milliseconds, right? As soon as I get a uh response back, I can parse it, I can reason about it perhaps a bit, and then I can figure out what my next request is going to be. So that's big change one. Big change two is all that reasoning and all that parsing is going to probably

35:37happen on a CPU. And that CPU is then going to have to probably think about, okay, what other state do I need to go gather before making my next prompt back into the model. Like in other words, I've I've learned something from this response. I'm going to take another step, but I actually need to go grab some context, maybe from uh DRAM local to me, maybe from someone else's DRAM on another CPU, maybe on SSD or maybe on HDD somewhere else. So now uh huge amount of

36:05orchestration has to take place as well. So the design actually is changing pretty significantly where the demand for accelerator computer is going up, but the demand for CPU and networking and storage, the you know, traditional data center CPU etc. is also going through the through the roof. So does that mean you're putting more

36:25CPUs alongside your your GPU racks then? So this is yeah, GPU TPU racks. This is the key question is going back to this question of optimization and specialization. If we start putting lots of CPU racks and it is a question next to the GPUs and TPUs, that means that actually we can't fully specialize to the density and network requirements, let's say, of a TPU rack relative to a

36:51CPU rack. TPU rack is going to be more dense than a CPU rack. It's probably going to need more networking than a CPU rack. So in other words, now our building design is going to change. Another option is maintain your uniformity, put your TPUs or your GPUs all in one building and the building next door but maybe

37:11put your CPUs. And your maybe your and maybe by the way the hard drives have to be in another building on the other side because they have yet another set of requirements. Now you need networking between these buildings at a pretty significant level. So once you leave a building, networking complexity goes up significantly from a reliability perspective, from a cost perspective, latency goes up probably acceptably, but still now you might go to hundreds of microseconds, potentially more with queuing between the components. So the considerations do

37:45change in pretty interesting ways. Mhm. Your job is hard. It's fun. It's fun. Yeah. Um what's happening on the networking side and I've heard that Google's always been the at the forefront of the newest in networking including optical. Can you say a word on what is like the the state of of optical networking? You know, we at Google, this was probably 15, 16 years ago were among the first to bring essentially what's called wave division multiplexing where you could put multiple signals on

38:18a single fiber within the data center. And we actually leverage that for all of our uh communication between racks. At the same time, we introduced the technology uh along with the wave division multiplexing uh called optical circuit switching. And essentially what optical circuit switching does is in contrast with traditional electrical packet switching, what it does is it transmits and moves data entirely in the optical domain. The great thing about that is and so let me describe the technology that underpins it. In a in a packet switch, you would take a packet, it has a header, you would look at it um in the electrical domain, figure out where the

38:58packet is headed. In its header, it might have an IP address that says, "Okay, where do I head it?" You look up, "Okay, for that destination, you look up in a table, what port do I forward it along?" So, basically, billions billions and billions, perhaps trillions of packets coming through at super high speed per second, you're forwarding them along. Optical circuit switching says, "I'm not touching these bits in the

39:21electrical domain. What I'm going to do is I'm going to figure out for an input port, which output port to send the light to." Okay? And now I have uh there's multiple ways to do this. The one that we started with is called uh MEMS uh switches, micro electrical motors that basically control mirrors in 3D. So, we can now programmatically take a box that might have, you pick, 128 ports, 256 ports, some number like that, and we can configure every input port for fiber that comes into it, map it to an output port, and then change the rotation of mirrors where the light literally shines down on

39:58these mirrors and gets reflected to the right output port. Initially, the reason we did this, twofold, was to create locality between groups of racks. Let's say I had a compute cluster and a storage cluster, and both of them were in support of, again, making it up, search. We knew that these two clusters would talk to each other a lot, so we would configure the mirrors to create shortcuts, purely optically,

40:26between those two clusters. Clusters of racks. That was reason number one. Reason number two was we wanted to be able to expand the network and contract the network without actually moving any fiber. And without working into the details, I could draw this on a board, the optical circuit switch would allow you to actually reconfigure the spine of the network to expand it or to shrink it without a human being having to do anything other than be a literally a controller

40:50that would manage that. Now, fast forward to TPUs. A TPU uh has a torus topology that connects all the TPUs to one another directly. Well, I I talked about throughput and goodput earlier. One of the things that we can do is if we have a TPU rack that fails, we can replace it with another TPU rack

41:13without moving any fiber. Again, I'd have to wave my hands or draw on a whiteboard, but essentially, we can say we have a spare rack available at all times. And when a rack fails, we redirect the light to that new rack. And that can be done in milliseconds. Why do you have the fiber at all then? As opposed to fully free space. Yeah, it's a very good question. Um attenuation loss and the

41:38bandwidth would drop dramatically. Furthermore, across the range of a very large building, aiming everything without fiber without the benefit of fiber to connect it all together in 3D would be would be challenging to possibly impossible. Um we've talked about it. We've talked about it, actually, and and there've been some really interesting discussions. Uh but but yes, it's mostly in fiber, but then when they hit the optical circuit switch, essentially, the light then literally shines down on these tiny chips. So, um that's one big direction of uh There's but there's there's a lot. I mean, I would say networking is uh exploding in in terms of its uh

42:18uh capabilities and need, frankly, in the data center. So cool. We could have an entire conversation on that. Yes, it is very very cool. Even like that going back to the picture from Menethil, it was all the the cables that that kind of amazed my eyes. Yeah, and those cables eventually some of them wind up at optical circuits

42:33which in our data centers. Makes sense. Okay, I want to flip to talking about power. You've been talking about good put per watt and other units per watt. Makes me think per watt means power is kind of the the binding constraints or the scarce constraints or the expensive constraints in some way. You know, so I I uh I get asked this question, what is the biggest constraint that we face? And um the reality is there is no single biggest constraint

42:54that we face. They're all constraints. They're all super hard. It could be uh and and they shift uh continuously. But if I had to answer fundamentally, uh I would say that power is the single most fundamental constraint that we face. Like everything else seems uh like we know how to solve them and it's a question of um solving them over some period of time. Power Yeah, I think

43:16the way that you put it is really nice. It's a it's a binding long-term issue that we do not have a I mean, there you know, nuclear. And you know, perhaps nuclear is going to abundant clean energy uh which would solve a lot of problems uh for for sure. When that happens and it at when it happens at scale, uh still

43:36still unknown. And so, how does it work in practice? You you know, you're standing up a new data center. It needs a gigawatt of power. I imagine you can't just call PG&E and say, "Hey, please send the gigawatt of lot of power." So, how what does provisioning power actually look like? And are you having to actually vertically integrate all the way down to like, you know, doing your own turbines? Or how do you solve the

43:57power bottleneck? Yeah, it's again uh it's a it's a big question and important question. We do uh our our preferred model at Google is always to be uh utility connected, to be good connected. So, it's the equivalent of calling your uh Oh, so you can't just call PG&E. Exactly. You you call uh very politely your favorite utility wherever it is that your uh data center is. And of course, you give them many many years of notice. So, in other words, if we're talking about a gigawatt scale, it's not something that you can say, "Hey, I need a gigawatt tomorrow. When when can you start billing me?" Uh it's something

44:29that we co-plan plan together. You know, for for us, it's something that we also take very seriously from the perspective of ensuring that when we work with these utilities, the the costs of putting that infrastructure in place the we could get into long conversations long conversation just on this topic as well, that we cover those costs because with the way that billing works, it actually could be that by the act of the utility building up capacity for us, let's say, other people's rates could go up in theory. What we ensure is that actually, let's say the transmission lines that have to be built, upgraded, uh additional utility base stations,

45:03etc., that we pay for those as well. But so, it is a long planning process. Uh it's uh can absolutely be the case that in let's say that we need a gigawatt in I'll make up a date, uh 2028. Uh and the utility can get us a gigawatt in 2029. They can get us, let's say, 700 MW in

45:232028. So, now we might be left with the question of how do we cover those 300 MW? Well, one answer is just wait. Another answer is to say, "Okay, well, would we figure out how we generate some subset of that power ourselves?" And maybe that would be with solar cells. Or with uh with batteries as a backup, etc. Or it be for other sources. So, then we again work with the utility. So, it might also be a uh combination where we might maintain some power uh generation local and have the capability even when the utility uh comes online uh fully at let's say the gigawatt scale,

45:59where we could actually provide power back to the grid. So, having that in when they need it as well, right? So, in other words, there might be the One way to look at it is there might be the 2 weeks of the year, maybe it's the hottest 2 weeks of the year where there's huge amount of

46:13residential demand. If we have some local generation, we can then provide that back to the uh grid as well. So, it really is working over multiple years with the utilities uh for us. Why is your preference to do that versus to kind of go like to work with the utilities as opposed to to kind of

46:30vertically integrate yourselves? Yeah, so um the main main reason is flexibility and uplift on both sides. So, one one way to look at it is um statistical multiplexing or if you want the law of uh large numbers. If we need to have a gigawatt of uh power, let's say we wanted to have that with 99.99%

46:51plus reliability. Probably means we have to build 2 gigawatts of power. Right? We've at that level of 99.99 or 99.999, you have to have 1 + 1 redundancy. That that gets expensive. And then making sure that that's going to be ideally uh clean energy source, probably right next to our data center, that can also be challenging. Now, if we partner with the data center, again, maybe we have some some amount of that that we can bring ourselves that we can give to the grid when they need it less, that we can take their power. So, in other words, by leveraging that statistical multiplexing over a much

47:23larger base, actually everybody wins. We win, the the grid wins, uh residences uh win, etc. We prefer that. And then in rare rare cases, we we will uh do it uh let's say behind the meter, but even then, we're doing it under the assumption that we're going to work with the utility where it might be a year later.

47:44We we want to be connected to the grid. That's uh again, it's an uplift for us, it's an uplift for the grid. Makes sense. How did you decide how big to make a data center? Yeah, that's that's an art and it's a uh source of significant debate. You know, at some point, you know, we had a debate, even 10 plus years ago, 15 years ago, big debate at Google. Should we just put everything into one data center? Like back then it was going to

48:05be a gigawatt. [laughter] Which was Simpler times. Yeah, different times. Like 10, 15 years ago, we were going to have a gigawatt data center. So one obvious concern there is single point of failure. Right, if you're looking at things from a 30-year perspective, that's a huge concern. You know, on the other hand, if you're talking about training workloads today,

48:26bigger is better. I mean, that was having more because from a networking perspective, actually, you want to have things concentrated in as small a distance as possible. But then again, two issues, single point of failure, but then also now power availability. I mean, while a gigawatt was huge 10 or 15 years ago, but imaginable, there's no way anywhere in the country or the world we're going to get the total requirements of Google built in in one place. It's just just not going to be possible. So now what's the optimum size? Again, we have models for this, simulators, etc. But this it also depends on Look, in some places we're

49:03going to be at the edge of the network or we're going to be in country. That might be tens of megawatts. We actually partner with ISPs. That might be Iraq. Like literally, it could be Iraq. This is a training cluster. Okay, maybe that's going to be closer to a gigawatt. Some other sites might be hundreds of

49:21megawatts, etc. Interesting. I love to understand how you think about the portfolio life cycle management. So I guess my guess would be that, you know, the biggest newest clusters are used for training the latest frontier model. And then you kind of recycle the other stuff and run inference on it. Is that Is that like a fair framework? Are you Are you also standing up inference specific

49:44clusters? How does that all work? Very reasonable framework that you're thinking about that and I think makes a lot of sense, but I would say that the demand for inferences such that we can't just rely on um whatever older training clusters that are no longer being fully used that just for training as the basis for inference. And also, if you think about it, we might centralize again uh in a particular year into a small number

50:07of large sites our training clusters. And there is benefits to keeping the network distance between them uh small. So, now let's wherever they're located in the world is they're probably going to be let's say on the same continent or they might be even in the same portion of a continent in a particular year. So, now you might be left with um not enough serving capacity on the other continents. Etcetera. So, then okay, actually we then have to go build the specialized

50:34inference uh elsewhere across the world. So, uh I think your intuition is uh spot-on, but not wholly. In other words, it it really does have to be okay, here are the training clusters. Yes, probably they're going to be used for serving in some number of years. Uh but then we're also having to build

50:48the serving clusters as well. And your serving clusters, are they different than the training clusters? Like are they smaller? Is there are they are they cheaper per per per megawatt? Uh not necessarily cheaper, actually, because uh for serving there is more need to colocate uh uh compute, networking, and storage. And so, that then we get to the inability to specialize. So, for training, you actually have this big density, uniform

51:14deployment, etc. Uh whereas for serving, you're going to have to have the mix of storage, compute, and accelerators. Furthermore, for um it's a very interesting aspect of this that we could go into more detail on as well, but for serving, you actually don't want to have too much in one place. You want to be serving your workloads from uh all over the the planet. But, now uh we wind up having um individual model endpoints, and there

51:41actually can be variations of models. So, now we have to spread these models out across the world, also accounting for locality. So, they will be smaller. They'll actually be less vertically integrated, probably, in the inference side. Super interesting. So, if you made a data data center 5 years ago, you know, state of the art accelerator that 5 years ago was very

52:02different. Mhm. Vastly less efficient than the ones that are being made today. Yes. Do you actually go back and like swap out the the chips in those in those old data centers? And I know this kind of relates to there's been an ongoing debate, I think, of like what is the actual useful life of a chip? Yeah. Yeah, so, you know, I've been on on record of saying this in one one of my more I was surprised by how much pick up this I had, but but you know, I said that our 7-year-old TPUs are still at 100%

52:28utilization. Wow. Uh and and I saw this. I didn't know this was meaningful. yeah, I I didn't mean for it to be a [laughter] a meaningful statement, but it was a meaningful statement, apparently. Yeah, so, our older TPUs GPUs, but our older TPUs are seeing significant utilization. We do uh replace them. In the end, there's a question of, okay, have they depreciation lifetime is approximately 6 years. Uh so, once they're fully depreciated, uh and given the power efficiency of newer generations, etc., it does make sense to um replace them and upgrade them. It's not that we were I mean, we do replace the chips, but it's really the the the systems. So, in

53:05other words, we think in terms of pods. So, a TPU, let's say um 8T pod might be 9,600 chips. And it might be uh 100 uh 40 something 152 racks, etc. So, then we would say, okay, we're going to pull out that pod, and we're going to replace it with a whatever it is, TPU 12 or 13 or

53:2414 pod. It might not be a perfect fit. Uh which then we have to In other words, the new pod's footprint might not be a perfect fit for the old pod's vacancy. We we then just have to account for that. We have to figure out how we would retrofit. We can't plan that because we don't know what that many generations of

53:41TPUs are going to be. Uh so then it's uh again a bit of an art to figure out how we would and it's actually hard work figure out how we would decom and then replace as quickly as possible with the with new TPUs. You've written publicly about open standards. Um can you say a word on

53:57that? Yeah, so I think that's uh the we we talked about this um interoperability question. And so for us, while we support vertical integration and we make it possible to you know extract just as much performance as you want, for us it's really important to um not force lock-in and not force a sort of walled garden in terms of how the system works and and so you know for I mean I'll give one example. At uh Google we developed a um

54:26model development framework called JAX. Uh we like it a lot. We think it's really really good and we use it extensively internally. Many of our customers like PyTorch. Right? And so one one thing we could say is, "Hey, if you want to run on TPUs, um you got to use JAX. It's the best. I'm I'm being a This is just a little bit but may maybe it is, maybe it isn't. We think it's the best and that's your only choice

54:52because it's it's so great." Or we could say, "Look, if you like JAX, we like JAX. If you like JAX, you can use it. But if you like PyTorch, we have torch TPU where your unmodified models etc. can can run." With and we you know what, we've seen this throughout history actually with many many examples. I've used the

55:11example of IP. Why did the internet protocol win? There were actually many competing protocols to IP. This is ancient history in the '70s and early '80s. Why did IP win? It's because it was a open standard and it was this narrow waist to the hourglass where anything could run on top in terms of software and anything could run on underneath it

55:33in terms of hardware. So open standard, interoperable, anyone who brought IP could plug into a router port and become part of the internet. Like that was it was beautiful. And that's what allowed the internet to explode in its growth and reach across the world. So, we really do believe in those open standards in terms of plug-in points. Now, if you want to plug in something highly specialized,

55:56you can. Right? If you if you think that you've got a better thing to plug into our our framework, you absolutely can. But, we want to really support open standards, ideally open source surrounded as well. It's too big and too important of a build-out to be, you know, any one vendor's closed proprietary standard.

56:14Yeah, we really we really believe that. And it's got to be one of choice. And that's also why, for example, we fully support and have TPUs, GPUs, other accelerators, etc. Yeah. How has day-to-day life for for your team changed with AI? Where is it changing your your function the most? So, I think the the whatever you want to say, the easiest answer is on the software engineering side, where I mean, it's been documented externally quite a bit. So, I think that we are at Google and my team using it to great effect in in terms of our software development capabilities, but also frankly test, rollouts, even helping with

56:56design, etc. But, there have been on the hardware side, which is maybe gotten less external coverage, also significant change. In other words, my hardware engineers I I was just looking at the numbers earlier at today, in fact, are using AI, using whatever the token counts, if if you want to not the best metric, but it's still a metric. Our hardware engineers are using AI as much as the software engineers are. And productivity has gone up, time to you know, time from design kickoff to

57:25tape-out is shrinking. Time for bring-up is shrinking. So, in other words, productivity is going up significantly. But, then other maybe less expected changes, how we do data center design has changed significantly. In other words, how we and how we evaluate you mentioned, "Hey, do we do a gigawatt building or 100 MW campus or 200 MW

57:50campus?" In the past, this would be very detailed, very sort of spreadsheet driven, human driven processes. And it still is to some extent, but there's a lot of AI now involved that really streamlines the process in terms of planning and development as well. Interesting. So, is it like reasoning models or I wouldn't say quite yet reasoning models. It's not It's not replacing human judgment, but it's making it much easier to bring the necessary information together like in in in one place and basically put the right information in front of

58:27the humans making the decisions. Okay, I'm going to bring us home with two kind of out there, kind of fun questions. Yeah. Um question number one, uh orbital data centers. Um I've seen that, you know, Google's thinking about this quite seriously and you don't need to comment on that, but I mean, does the fact that people are seriously running the numbers on orbital computes mean that there are kind of serious binding constraints on the earth? And And what do you think of

58:52of orbital data centers? Yeah, it's it's an exciting direction. We are actually pursuing it and we've uh referred to it more than no tongue in cheek as a as an moon shot as one of our big big efforts that we're excited about investing in. It goes back to the earlier part of the conversation where you raised I think correctly that in terms of fundamental constraints, energy and energy production is a key key challenge. And so, really bottom line is from a fundamentals perspective, um in space, um you have something like 40% more power available because of lack of attenuation in the atmosphere, etc. In other words, there's just more solar

59:30capacity, what 1.4x. So, that's one part of it. But but in a sun-synchronous orbit, you have 98 to 100% coverage of sunlight on your solar cells relative to 28 30, maybe 35% um on land. All right. So, in other words, just this enormous amount of power, obviously the sun. You You take the 1.4x and you take the 3 to 4x

1:00:00in terms of number of hours per day. You remove batteries more or less from the equation. And now you have the potential for something that can really And And of course, carbon free. Lots of benefits. Lots of challenges. Yep. Right. Lots and lots of challenges. So, in other words, okay, now what about cooling? You know, naively you might think cooling in space is easier. It's

1:00:22actually harder. Uh reliability. We talked about how these things fail sometimes. So, repairs uh becomes harder. Not not impossible, but becomes harder in space. Networking. up with the with the cluster? And exactly. So, perhaps they'll be this model is a is a promising direction. Uh redundancy will probably be your friend. Uh your uh person's question on free space

1:00:43optics is now going to become reality. We're probably not going to be stringing fiber between these components. So, it will actually be free space. And we're going to have the lasers pointing at the receivers and calibrating in in real time. These are There are no showstoppers here. No fundamental showstoppers. Uh last question. I've had this image of the ineffable big supercomputer that you built them um in my head this whole time. And so,

1:01:10here's the question. 10 years from now, what will the most frontier supercomputer look like? Oh my gosh. Yes, so 10 years is right at that edge where it's um uh I would say in all sincerity probably some people are thinking about what the 2036 computer looks like. We might have a few thinking that far

1:01:32ahead. But uh wow, I um the cone of uncertainty there is is uh way way too wide. Like in other words, if you look at the trends um the level of integration is going to be tremendous. So, you know, we saw the beautiful fiber and the um VR200 uh racks that we put together for

1:01:51Ineffable. My my guess is it's going to be more integrated. Less fiber to I won't say no fiber in 2036, but I think that probably from a rack perspective um the rack will look uh much more tightly integrated and the amount of fiber that there'll be maybe a small fiber bundle coming out of the rack. And then uh so in other words, one one view you might have from a modular manufacturing perspective is these racks likely in 2036 are going to be

1:02:17manufactured centrally. And so whether they have 72 or 144 or 288 or probably more, but you know, if it's 576 or 1152, pick your favorite multiple of GPUs since we've talked about the uh in Ineffable case, but then be the same for the TPUs. Deeply integrated into a rack. Would a rack be multiple megawatts? You know, we don't know exactly how, but

1:02:412036 we get to we get to imagine things. Could be multiple megawatts in a single rack. And now you bring water and you bring power and you bring fiber. Right? You you you wheel that rack in, you plug those three things in and you're off uh off to the off to the races uh as well. Okay, so it's not going to be like a big

1:03:00alien orb then. Uh up [laughter] in space. By 2036, I wouldn't say that it's not possible uh for 2036 for it to be a uh then directly launched into space uh and then maybe um taken by a robotic arm at some space station and then plugged into the right uh module. Maybe that's for 2036.

1:03:19Fun. Fun fun to think about. Um I really enjoyed this conversation. We were This is the most intense, biggest capex buildout in history, but I also think it's it's a technology revolution. revolution that is a thing of beauty. And I think you have such a grasp over, you know, the beauty of the technology and and the binding constraints and and how to balance this this all. Uh Google

1:03:44is in good hands. Appreciate it. Thank you for taking the time to share what you're doing. It's a ton of fun. We get to live We get to live through this so we get to define it. So so thank you very much. It's a great conversation. Thank you. Yep, thanks. [music]

1:04:13[music]

1:04:19[music]