Google DeepMind Pre-Training Lead: How To Land a Job at a Frontier Lab | Vlad Feinberg

0:00Every single time you go up for a pre-training run, you're about to put in more flops into this run than you've ever done before. This is Vlad Feinberg. He's Google DeepMind's pre-training area lead, and I asked him all about how to get a job at a frontier lab. That was a particular skill that I see voracious demand for across all the different labs. The research skill set is going to become increasingly important if you do the scaling book exercises and, you know, send me a video of yourself doing them. I would love to interview you. Here's the full episode.

0:37You wrote this post that was titled, How to Get a Job at a Frontier Lab. What are the skills that are kind of in demand in Frontier Labs? Maybe we can talk about the shape of the work. There's quite a range of different things that Frontier Labs require. At this point, LLMs are artifacts that are connected to research and product in ways that machine learning really hasn't been as connected to before. And so it really touches on so many different things. The goal of my post was to propose just a couple of tangible directions in which labs could require a certain set of skills not to be fully exhaustive.

1:24And really the ones that I dive into have to do with kernel development and low-level engineering to accelerate the runtime for these LLMs in practice. And so that was a particular skill that I see voracious demand for across all the different labs and among different projects within the labs. So that seemed like a very sharp one to call out as an overall need. And so specifically, whenever we're doing a research project that involves changing the architecture for the neural net in a particular way, or rethinking how we might do serving to do better KV caching or something like that, Again, across the stack, you just need to be able to implement these new techniques in efficient ways.

2:21And the inner loop of all of these different changes is creating software artifacts that can function at large scales with high throughput, low latency. And this is just fundamental work that's tied to classical backend engineering thinking. So yeah, it seemed like a very open thing for people to specialize in. My friends that work at OpenAI and Anthropic, there's this distinction of an applied org and the research org. And I was wondering if DeepMind has a similar distinction and if you could speak about what that difference is. So we have different focus areas. And like, you know, for instance, within GDM, there's a team that focuses on how we can use our Gemini LLMs to better inform search results.

3:20And so like that might be some, you know, you know, in some way, like an applied version of the LLMs. But I am hesitant to, you know, make a very sharp distinction here because there's so much actual like hard research that has to go into this kind of level of product integration. Like specifically for the one I mentioned, quite a lot of work goes into making sure that these LLMs are factual and can cite sources to have very precise grounded answers, assessing the quality of these sources to make sure that you're not referring to anything that's like sarcastic or a joke. This is, I guess, a good example of how even in like product specific, quote unquote, applied AI verticals, you're still doing research.

4:10Uh, that being said, there's definitely what I would say is like very classical LLM research teams, pre-training, post-training. These are things that are still standalone, uh, teams inside of GDM that are focused on what I would say is like, you know, creating soda models, you know, pure research. again the caveat is the the pure research that we do like the extent that it matters is the extent to which we can realize it and so you know we're just as responsible with uh delivering these models and making sure they train stably and actually being like the sres of sorts for the training run to make sure that the model training is going smoothly as we are for coming up with the recipes to make these LLMs and you can't separate those two roles.

5:01It's really crucial to kind of wear both of those hats. So yeah, I think you can, you can draw up a spectrum between research and applied. But no matter what in today's world, I think everyone needs to be fluid across that spectrum. I noticed there's also another spectrum of software engineer to pure AI researcher. And How do you think of that spectrum, like software engineering versus like AI researcher roles? So I guess in my case specifically, I think a lot of what we do and a lot of the new techniques that we develop, the groundwork is laid in infrastructure investment. So I can walk through what my team does a little bit more detail later, but one of the verticals is distillation.

5:59And in order to do distillation, it's some way of transferring the knowledge or some form of statistics about the underlying data set through a teacher model into the student model to make the student model better than if it hadn't ever seen these auxiliary statistics from the teacher. And when you're talking about statistics derived from a massive LLM applied to trillions and trillions of tokens, you're talking about a level of flops investment that is millions and millions of dollars. And that in turn means that you have to be able to think through how do you optimize the system to be as efficient as possible?

6:50Because every operation that we're performing is multiplied by such a large factor that every second counts, every byte of storage counts. And quite a bit of that work is, you know, good old fashioned software engineering. And so in particular, the infrastructure for distillation has evolved through maybe three to four generations at this point. And in each one, we've taken a step back, looked at what kind of research methods have we been applying for distillation holistically, thought about how do we broaden what the infrastructure is capable of. And there's definitely a couple of discrete points where rethinking the system design of how we perform distillation enables us to do research on distillation methods much more quickly.

7:48And so it's this kind of investment that like, okay, this like four month or whatever rewrite of our distillation infrastructure then results in a dramatically new understanding of distillation scaling laws that translates to really strong models. So it really requires just work across the stack. And I can't imagine that we would have gotten results like Flash 3.0 without having made those distillation infrastructure investments that are, at the end of the day, things that started with a good old-fashioned design doc and thinking about what the right abstractions are for generating these teacher statistics, coming up with the right storage system for them, thinking through what could support the reading and writing across multiple different data centers at this scale.

8:42Really classical distributed systems problems. Yeah, I mean, it sounds like there's a lot of software engineering, backend, infra type problems given just the scale of the compute at this point. It still feels like though, at some point in that spectrum, there's some crossover where there's these new skills, like somewhere where if you had, you took a arbitrary backend engineer and you placed them to, I don't know, adjust the model architecture or something like there, that is like a bit of a jump more than the infrowork. Um, like how do you see that distinction? Yeah. So I think there is a crossover point in terms of doing research where research is an endeavor where the payoffs become a lot higher risk, higher reward.

9:34And we have this notion of kind of research taste, which is, you know, some high level intuition about what path you should be proceeding through the DAG of the multiple different milestones that you need to accomplish in a particular project. In some sense, we can view software engineering projects through a similar DAG where, you know, you have all of these intermediate artifacts that you want to hit in a software program to get to the final results. But in the software engineering case, the DAG is more or less deterministic where you, you know, build one service, then a different service, then a third service.

10:13And, you know, you figure out your storage infrastructure layer first, that kind of thing. And you can just make monotone progress. But in the research case, you have to kind of explore this DAG, which is now stochastic because some of the nodes, which might be some research ideas or some aspect of getting to a final goal, may or may not work out. And I think that requires a bit of a mindset shift. And that kind of mindset shift takes a while to learn and it takes specialized skills to learn. This would be the kind of skills you pick up in a PhD, for instance, one succinct way I could put it, there's a really excellent post by this professor, Jacob Steinhardt.

10:58And I love to frame a lot of the research work that I do in this way. And it's research as an MDP. So MDP here, Markov decision process. It's, again, we have this high level idea of a stochastic dependency graph between different milestones in a research project where you might need to have a certain kind of result or prove a certain kind of theorem before you get to a certain kind of conclusion. Similarly for a machine learning research project, you might need to have this and that featurization working before you can get to this and that image net accuracy or something like that. And expanding those nodes in this graph, it's this stochastic endeavor where these approaches may or may not work out and whether or not one works out, opens up a set of new possibilities for you.

11:48And so the approach that you might have in the software engineering case where you could fully write out here are all the paths to the goal across walking this graph. What's the shortest path to your goal? That approach is not optimal in the research case because if all of a sudden the transitions between the edges in this graph become unreliable and some of the nodes you might not even be aware of, it might be a hidden MDP, then the way that you might approach this problem would really differ. And in particular, you have to factor in the success rate and the time investment that you're going to be putting into these different research ideas, as well as a priori estimating what those different rates are.

12:40And that's a very different exercise than writing up what the design for your software engineering project might be. And it's this skill set of building an intuition of how likely an approach is to work out without having yet done that approach that I think people often correlate with this research taste notion. But that's exactly the one that you need to build up in order to properly traverse this MDP. For the research projects and just like generally the nature of the research work, it sounds like you're saying that there's a lot more uncertainty here. I'm still trying to get a sense of the nature of the work.

13:23If you threw this backend engineer into a team that's doing research, what are those concrete examples where they fall short? like I think the the very first thing that comes to mind is having the right context for the research landscape in which you're operating so quite a bit of research work involves like almost uh this kind of um you have to take on this like very humble viewpoint of there's been quite a lot of investment in related work in the past. And until I know the sum total of humanity's bleeding edge in this topic, I'm definitely not going to be able to further that bleeding edge. So building up a solid understanding of past work in a particular area and doing that related literature review is maybe the first thing that I would imagine people might stumble on is having read and having the skills to effectively traverse, you know, historical citation tree for a particular topic.

14:39Because you don't have the time to read all of these different papers. You need to build up a sense of what are the high value papers and what are the ways in which I can assess if a paper is worth reading without fully reading it. That's like the first thing that comes to mind as the, you know, skill that people need to build up. Even to be able to read these research level papers, you have to have a background in machine learning, in some, you know, computer science. And, you know, depending on the paper and depending on the domain, there might be all sorts of prerequisites in terms of like the underlying math and coursework that you would want to have to properly understand.

15:21So that's quite important to be able to have a deep understanding of what methodology is available because you really won't have a lot of hope of improving upon the methodology if you don't understand what's there already. So I think I like mentioned earlier, one of the things that my team works on is distillation. And in order to advance our understanding in distillation for large language models, you have to have a good understanding of what we're trying to do with LLMs. And just to give a cursory overview here, the name of the game for LLM research is, especially in pre-training, is scaling laws.

16:09And so what are scaling laws? People focus a lot about this power law structure and the fact that you have this and that exponent. But what matters is less so the functional form. What matters is for a given recipe of scaling up your LLM. So as you invest more and more flops into the pre-training run of an LLM, you have to be able to predict what the final test loss of this LLM is going to be. And why do we care about this question? Why do we care about predicting what our generalization error is? In the classical machine learning world, like say we're trying to win ImageNet, we have our test loss, which is our classification error for 1 ,000 different classes.

16:59And you run your VGG or your ResNet proposal to get that classification error. That's an estimate of how well that model does at classifying amongst those 1 ,000 classes various different images. We can estimate how good our method is going to be by taking a validation set. And then whenever we have an architecture idea for a neural net, we just train it. And then we do a bunch of validation set runs and we get a cross validation error that is itself an estimator of our final test error. And so in this way, you can just iterate on different ideas through this process. But what's different in LLM world is every single time you go up for a pre-training run, you're about to put in more flops into this run than you've ever done before.

17:45So it's in some sense like a one-shot version of this ImageNet problem. You never get to see the full ImageNet training data set. You have to practice on MNIST and then CIFAR and then maybe based off of those, you try to come up with a method that just works right off the bat on ImageNet. and if you were to just do that by itself as I'm sure many people have tried I'd like certainly when I was learning how to do all of those different things you get something it works really great on MNIST it maybe even works on CIFAR and then all of a sudden it breaks on ImageNet you'll find out that like things don't just generalize easily across scale like this and so much of what we do for LLMs is coming up with recipes there a recipe is this function that goes from number of flops you'd like to train on to a training routine for this LLM.

18:34And if you can couple this recipe with a prediction rule that can predict accurately what your LLM accuracy is going to be, then you're able to make decisions about how to improve your recipe because you can use that prediction. That is all a ton of context on what LLM research looks like in general. But But that's like an understanding that we got to, that we even thought was feasible thanks to so much initial LLM scaling work that we've seen across the Kaplan paper, across Chinchilla. Since those two papers, there's been a lot more work in terms of like, what other factors are there beyond number of params and number of tokens that you train on that influence your prediction accuracy, like number of unique tokens, for instance.

19:27But I would say those two foundational papers for LLMs, those are informed by an even longer line of different scaling works going back to, say, the original GPTs. And then Google has had a ton of scaling work across its palm papers. This is just a set of works that have informed that viewpoint that I described earlier that you kind of just need to build up by having gone through that literature review yourself. If you were, for instance, if you were trying to pick someone that was going on your team and the way that you would judge their fitness to help you push the frontier, is their understanding of the frontier, including the existing literature, which requires all these prerequisite, I think you called it mathematical maturity in your post.

20:23Yeah. So I think it's easy to read and understand those papers once you have mathematical maturity. So I guess the ones I mentioned in particular, nowadays they're table stakes. So I would expect candidates to be familiar with them. Um, I think, um, the, the general skillset is being able to dive into, uh, a paper of that level and then understanding it, uh, you know, being able to take a research idea, uh, from a paper and implementing it yourself. Like that's, that's just a very important skill set to be able to have. Like we get, you know, all sorts of different ideas presented, you know, they might not all directly apply to our domain, but if you can deeply understand them, then you can iterate on them and you can improve them inside of, inside of our domain.

21:21And so when we assess for people who can work with the mathematical concepts in these machine learning papers, that's, that's, I guess the, the key skill there that would be evidence that you can go pick up this arbitrary paper and see to what extent these ideas carry over in the Google setting. This probably won't be exhaustive, but I'd be curious to hear other domains that maybe people could dig into to see what kind of matters in frontier AI research. So you'd mentioned distillation. You also mentioned kernels. It sounds like kernels are helpful everywhere. But are there other areas that come to mind if you were just raffle off areas that are not necessarily exhaustive?

22:04One thing that I think is quite powerful is actually programming language research. So by looking into how we can create abstractions at the programming language level, we could facilitate kernel development. I think Thunder Kittens is a really good example of this, like coming up with an abstraction that allows you to write kernels through four functions instead of arbitrary globs of C++ code allows you to move really quickly in developing algorithms that fully utilize hardware. So at that point, it's not about the PL research itself. It's about having a passion for these kind of programming language abstractions and working with low-level hardware, people who are interested in and will try to work with like QtDSL, this kind of thing where there's a lot of hardware-specific, domain-specific languages.

23:08One other thing that comes to mind besides PL and scaling law literature would be reinforcement learning literature. So in particular, ever since our LHF, I think we've seen that deep RL algorithms like PPO do have a place in production systems. And, you know, there was a time where that was in question, but now it's, you know, pretty unanimous that we see these kind of algorithms applied to real production systems. And the theory behind that, you kind of have to start with the basics for reinforcement learning and work your way up to the myriad value-based methods and policy gradient methods that we have today.

24:00That's another domain that I think is just like a very rich literature tree to crawl. And then for more of the backend engineer folks, just beyond just the kernels themselves, there's, I think, a pretty fun overlap between distributed systems and optimization work where figuring out how to design neural net training algorithms that allow for training across many GPUs. there's all sorts of fun challenges between asynchronicity, how up-to-date your gradients are, how pipelining affects the staleness. All of these system choices that you could make in your training algorithm design will impact convergence and the final quality of your neural net.

24:51And those are things that can be analyzed independently of the LLM setting and have been for a while. So, you know, especially if you're kind of more infra inclined, then having a good understanding of like how those different algorithms work is a really good place to start. Do you see any difference between the demands of the different frontier labs? So, for instance, if someone wants to work at DeepMind, is there like a particular area that you see DeepMind cares about more than Anthropic, for instance? I think in terms of the skill set, it's probably pretty similar. Yeah, I think there's maybe differences in business strategy and the set of offerings that's a function of the specialties of the labs and the kind of different customers that the labs could have.

25:49but I would say that there's quite a lot of overlap between the labs in terms of what people look for and like yeah like when I posted my post you would see like you know people from both OpenAI and Thropic saying like yeah like we agree with this advice and so you know I think that's just a little bit of evidence towards that. I think one reason for the huge demand for wanting to go closer to AI research is because people are thinking, oh, software engineering is not going to be as important in the future. Is there a similar thought in when it comes to research where LMS is also going to handle a lot of that work as well?

26:28So there's no reason to favor AI research versus software engineering. So I think the research skill set is going to become increasingly important. So I would say being able to handle stochastic components in the planning of your work is just going to be a larger and larger part of how we approach our jobs. Figuring out how to leverage AI in whatever thing you work on, which doesn't even have to be software related is just an important muscle to start building right away because these components aren't deterministic and thinking about how do I construct systems around these LLMs to do my job more effectively, that's going to be the thing that sets you apart in the future.

27:18And I think that's true no matter what you're going to be doing. Look, I think there's FUD everywhere, especially with some of the approach to marketing that some people have in terms of AI. It's FUD that is being intentionally leveraged. And so I feel like people should really just focus on themselves and trying to be more productive themselves. I don't think that AI is going to replace all of our roles. And so the reason for that is that one of the important aspects of what we do as humans in an organization, which is really this web of trust from this organization that is this pool of resources and this pool of people that manages these resources.

28:08One of the important things that we do is we allocate those resources towards certain goals. And even when we can accelerate our execution, there's an element of making decisions around how we allocate these resources that will always be something that needs to be attributable to a human making that decision. And that's simply because you can't hand off blame to AI. So we at this point have LLMs that really deeply understand law and they could review your contract for you or something like that. But they can't represent you in court because they can't be disbarred. And so that's, I think, a really sharp way that I might describe like, okay, this is why the legal profession will go on, even though LLMs are really good at recalling precedent, is you want to have someone who is responsible, who can validate the output of AI to perform legal work more effectively for you rather than hand off your legal defense to an LLM.

29:25Yeah, I think the FUD, that was actually the original motivation for your post. Yeah, I mean, I really think that the mindset that people should have is a constructive one. And so there was a tweet that I saw, I think by Didi, that was like, some long form, you know, fear mongering about, you know, uh, uh, AI permanent underclass or something like that. And, uh, it's easy to get stuck in that loop, but I think the important thing to think about is like, we all have agency over our future and we can start investing in, skills that matter for tomorrow, today. And that's really the only thing you should be doing, right?

30:15Like, you know, worrying about it is not going to help you. And so part of why I wanted to write this post is in response to that, because it was something that I could see echoed. You know, I gave a lecture at Princeton a while back and, you know, a big question that came up is like, you know, how do I work at DeepMind? And it's something that like, yeah, just when people find out what I do, that's the top question people ask. So I figured it would be helpful to add a little bit more constructive, you know, direction to the discourse here. One last thing on the post, because, you know, if you think about getting a role, there's obviously the skills.

30:56And we talked a lot about the skills and your fitness for the role, but there's also kind of the signaling for that role and like what is kind of valued if you were to be saying marketing yourself to one of these frontier labs what signals matter most actual evidence that you've created something of uh of use to other people along the line of kernels right like you can take any of the many open source llms that we have and optimize them you don't have to make them better in every case You could show that, oh, I have an improvement for this in that setting. It doesn't even have to be something that speeds up the model on GPU.

31:38There's all sorts of open source stacks like VLLM. There's a lot of other things that you can do besides accelerating the LLM inference on device. The serving stack that surrounds LLMs is a very sophisticated distributed system that has to maintain this KV cache memory and deal with all sorts of like load balancing and request queuing and very common problems for backend servers. And these projects are always looking for help. So, you know, contributions to VLLM or SGLang or demonstrations with TensorRT. They have, I think, a distributed system called Dynamo that allows for disaggregated serving where you could show that you made a project using these components.

32:31You improve these components like that would be an extremely positive signal for any candidate that I'm looking at. and a very welcome contribution to open source. I think also a lot of what we said is kind of assuming the path of external hire into Frontier Lab. But a lot of these Frontier Labs have large organizations that aren't necessarily doing the cutting edge frontier work. So let's say, yeah, for instance, I mean, you know, Google DeepMind versus let's say there's some infrastructure eng that's working on search and they have the backend skillset maybe not as much domain context and they try to internal transfer to google deep mind does any of your advice differ in that kind of case for like an internal transfer versus uh someone who's coming from external there's someone who i worked with closely on the search side who actually did transfer to my team uh nate lids and he's amazing and now he owns so much of uh like what we do on my team in terms of inference co-design for uh like flash and flashlight and i would say like he's a really great example of this where his approach was you know how do i help my pa my product area adopt this technology as effectively as possible so i think there's you know definitely if you're in a organization that isn't directly generating these models, but in some way trying to leverage them, there's a very big gap in terms of applying these LLMs effectively, serving them effectively within your organization.

34:24And becoming someone who does that really effectively not only creates a ton of value in terms of like the, you know, specific business need for your org, which will definitely elevate you in your org, but it'll also be the case that you're going to just naturally become the partner that we work with on the research side to make sure that our models are effective within your org. And so at that point, you know, you may or may not want to transfer. Definitely if you transfer, we'd, you know, be happy to work with you. But like at that point, I think you're, you're, you're already doing something that is cutting edge, which is integrating this new technology into, you know, a real product that people use.