Now. Hello, everyone. Good afternoon.
I'm super excited to moderate this conversation between two leaders who are really shaping the future of AI. First is, Doctor Andrew Ng, my former PhD advisor at Stanford. You've been democratizing AI education for over a decade.
Over two decades, I believe. And Doctor Lisa Su, AMD CEO, You've been leading the charge in making AI hardware available to a broader market of builders and more open so more developers can contribute to the important software for AI compute. So let's start with something that's core to both of your missions AI accessibility.
Andrew, you've taught millions of people about AI through your courses. And, Lisa, you've built compute that served millions of people as leaders and making AI more widely available to developers, What do you view as key levers of making this happen and ultimately accelerating AI progress effectively and safely? Well, first of all, it's the first time I'm sitting with this audience.
So I have to say “Are you guys having a good day? ” It is super important to me that you have a good day, because you really are the center of, you know, our world in terms of this whole concept of democratizing. AI, you know, our goal in life is to make sure that there's an incredibly strong compute roadmap.
But more than that, it's a compute roadmap that everyone can have access to. And, you know, what does that mean? Okay.
That means, lots and lots of places where you can get compute, but it also means, a very strong ecosystem. And, you know, the developer community is really at the center of that. So, you know, that's very high on our priority list.
That was a very important key thing that we wanted to do today was to make sure that there was, number one, Anush, that developer cloud better be working well No pressure. But that's what I said to a new I said, look, I love the fact that we're going to announce a developer cloud. I want to make sure that when all of you access it, that it does.
In fact, do what you say, but we want to give you lots and lots of compute. That's our goal in life. And, you know, it's really a really a pleasure to be here on stage with Andrew, who has done so much for AI.
So I'll turn it over to you now. Thank you. Yeah.
Let me share something about that. So this is what I think of as an AI stack, right? Low level semiconductor, AMD and Nvidia, and others, hyperscalers or the large clouds build on top of that.
Then the AI foundation model companies like OpenAI and Shopee, Gemini and many others. And then I think the majority of people in this room, really the majority of people in the world will be in the application layer. Will we take advantage of the wonderful tools and the technology layers, semiconductor, cloud hyperscaler or foundation model to build wonderful applications.
And in fact, I spend a lot of my time with the application layer. And almost by definition, even though all the you know, PR and hype is at the technology layer, the application layer has got to be even more valuable because frankly we need the applications to generate more revenue you know so that they can afford to pay the technology layers. And frankly, one of the reasons I really appreciate Lisa and Vamsi and AMD teams, work is this approach to openness.
And maybe to make an analogy, if we look at the mobile ecosystem, frankly, is like kind of, it's just not that interesting. Right. And one of the reasons is because, by the way, Andrew said that I didn't say that.
my bad, my bad. And one of the reasons is that two gatekeepers, Android and iOS, and unless they let you do certain things, a certain innovations, they're just not allowed to have or monetization innovation and so on. One of the fears in AI has been the rise of gatekeepers at some layer of the stack that ends up, you know, capturing unfair amounts of rent, and also, frankly, stifling innovation.
So at the foundation model layer, I think supporting open weight models have been absolutely critical there. Definitely. I foundation all the companies that did intense lobbying to try to wipe out open source, you know, because it would've been great if some of them could be the gatekeeper.
I think that that threat one so there is diffuse and for all of us, the application layer, we want that layer to be open. If, look, the other layers of the stack, I think the semiconductor layer is one where there is clear potential for there to be gatekeepers. And I think in contrast, the very open ROCm ecosystem, and making sure that developers have choice in, you know, semiconductor, that's what prevents gatekeepers from arising.
That would then force application developers to have to get permission from someone else or to be allowed to innovate and whether we want to. So I think, because of that, I actually really appreciate a lot of work that Lisa, Vamsi, and ROCm team. And really the broader AMD team is doing.
Thank thank you, Andrew. Can you touch on an example of an application that would be affected by that type of openness? And then, I don't know, Lisa, you could touch on, how the infrastructure underneath could support that if it were open.
I think right now, maybe it's actually so clear in mobile. It turns out that, you can't, you know, launch a new keyboard. It's very difficult to launch a new map out there.
You can't launch a new voice assistant in the United States. Because of the gatekeepers on mobile. It's very difficult to do some of those things.
I think that the GenAI world is still, you know, younger and earlier. And so I think where gatekeepers who choose to stifle innovation is because the gatekeepers have not had the power to stifle innovation. I think that's been a good thing.
I think, for example, if, none of us are allowed to fine tune models, you know, because they were gatekeepers, they chose. So that is only part of their model. So I had to find, you know, the I think the open innovation ecosystem Is really powerful or, I was actually really interested to see, within a few days of the latest DeepSeek model being released, it was already distilled on top of Qwen.
I think that the DeepSeek team did it, but that's two open models, DeepSeek and Qwen being distilled together to form a new model. And I think, there are so many innovations. And I don't know when Llama was released, some people thought the context length was too short and then some folks rejiggered the new version of a longer context window.
So there's so many things that is very difficult to sit down in advance or change the data to take a text only model and have it also input images. So there's so many things that openness has already enabled the the foundation model layer. And then also having the semiconductor interop and the kernel support and so on to support that next layer of innovations.
I feel like it feels really important to me. Yeah. Actually, Andrew, I, I completely agree with you.
I mean, I think we were really actually impressed with just how fast innovation was happening, you know, around, you know, SeepSeek and around Llama. I mean, the fact is, zero models, they work on, you know, a whole bunch of infrastructure. It was very easy for our team to optimize, actually very easy to optimize.
And and then frankly, people were moving things over and, you know, whether you use the model itself or you just took pieces of it, you were able to, really improve the infrastructure. I think from our standpoint, from an infrastructure standpoint, I have to say that sometimes, you know, it is actually scary for us to open source stuff and Vamsi and Anush can vouch for that because it's not perfect. And the idea is when it's not perfect, you guys will all see it and you'll say, well, you know, this is not right and this is not right.
And and frankly, I think the, the whole model of open source and an open ecosystem is for us to trust that. Yeah, it may not be perfect, but by the fact that we're willing to open it means that it will get much better much faster with, you know, different ways of doing things and different capabilities. So, certainly the silicon layer, we have to innovate, you know, as fast as possible.
It's very, very complex. But in terms of ensuring that the amount of work you have to do at the upper layers is as minimal as possible, and it just ports right over. I mean, that's the whole idea.
So that you have choice in what you do. And we're very committed to that. We're continuing to build out that ecosystem.
It is not perfect, but it's getting a lot, lot better. And with the power of the the open ecosystem, I think, you know, just some of the great results, that we've seen so far, like, MI350 is relatively, if I can tell you just how many systems, you know, we have internally, we've, delivered some to some of the keyopen ecosystem partners> The fact that it's actually come up so well, in terms of performance, I think has a lot to do with the fact that the ecosystem is open and is able to do that. So, yes, it's a very important part of our infrastructure, and we'll continue to build that out.
Awesome. And I just say, but AMD isn't paying me right little more for me, but I think I found that some of my workflows written in PyTorch ported over to AMD not all I wish I could say everything I ever did ported seamlessly over the AMD, but a large fraction when we try ran with basically no code changes. When implementing PyTorch doesn't work all the time.
But I think if you have access to dev cloud and AMD GPUs, you know, might be aware of try running them on the AMD. Maybe it won't work, but I think there's a decent chance that well, if you implement the PyTorch layer and then do your TCO back to the arm for low price performance calculation, and then decide what you may or may not want to do. We're definitely not paying you, but we are super happy.
Maybe you should, Hey, negotiating on. Yeah, yeah, yeah. But, we're super happy that you're here because you.
you have so much credibility with how it should work. It should work. That's that's the bottom line.
It absolutely, should be a very easy, you know, port. How should, developers in the audience get more involved as we open more and more parts of the stack? Andrew, you mentioned, you mentioned that people are very involved in increasing the context window of Lama, for example, or at that model layer, but wondering at the lower layers, how should people get more involved?
Yeah. So I think many of us operate in many layers of the stack. I feel like for, you know, the people here, which I think that's you going to be in the minority, operating close to GPU at the kernel layer.
I think it's worth to really take a look right at open ROCm ecosystem and seeing as a way to support more open things. I think that for teams working higher up at the stack, frankly, most of us would rather just, you know, frankly, not have to care, and do a price performance calculation and then hopefully to access whatever a compute service gives us a best price performance. And I think that just a touch on a higher level of the stack, I think the opportunities that the application layer are just amazing.
So I think of them two things that have happened in the past as having happened in the last couple of years. One is the rise of AI building blocks. So the tools for, you know, prompting evals, RAGs, and vector databases, guardrails, agency workflows, these building blocks are amazing so that it's now possible to take these building blocks and combine them really quickly to build applications that they just were not possible 2 or 3 years ago.
So I think for those of you offering the application layer, you know, go learn about all these wonderful building blocks built on top of whatever is a compute provider. And then the other exciting thing is, AI assistant coding, right? Like, like many of you, I probably can't imagine myself ever wanting to code again without AI assistant.
And the evolution of the tools and AI coding assistance is one of the I know we're supposed to say everything and I go so fast, but frankly, I think the pace of innovation and AI coding assistant is one of the fastest in a sector that is already very fast. So two, three years ago was the 2002 GitHub copilot to the great job pioneering autocomplete. And then they came the curse of windsurf generation, which was much more sophisticated to write code to agentic workflows.
Their kind of work sometimes introduce one the bug, but, you know and then there's a new generation of even much more agentic AI coding assistance. So Claude form was released like two and a half years ago, and I found myself in the last two and a half weeks using quite a lot. So my team members also playing around with Codex.
And I think these highly agentic AI workflows are gonna be a huge boost to developer productivity and part of me is also it is going to help with kind of CUDA ROCm and code translation or things as well as GPU portability. But I feel like, as developers sitting on top of these trends, I think this is already helping, right to maintain legacy software. But where I spend a lot of my time is, frankly, building quick and dirty prototypes.
So my team, I find we built, you know, many startups. And I find that, when you as a developer have an idea, there's so many things that, you know, I or my team will implement in an afternoon that a few years ago would have been like six engineers and three months or something. So now I find that when does an idea I get excited about it.
It frankly, it takes me longer to explain it to someone else and get them to try to implement it. than just build it myself. And it's been interesting to see the incredible fast pace of iteration where, we build a prototype in a day, get user feedback late that evening and the next morning or after the next iteration.
So I think that, one thing I see is, previously people used to have access to a lot of proof of concept still make to the production because they felt they wasted effort, but it doesn't actually bother me. I feel like the thing I focus more on is driving down the cost of doing a proof of concept so low that if you can build 20 prototypes and 18 die a quick, quiet death and asset price of finding the two, they're really valuable. If you want to take to production and take the scale, that's an excellent trade off.
So I find that the innovation process at both startups and large corporates as changing to take advantage of this capability of insanely fast prototype as a mechanism for inventing and figuring out what will actually work. So I think all that is super exciting at the application layer. And again, comes back to to ensure this excitement continues.
And then we're all allowed to continue to innovate with no gatekeepers. Making sure the tech layer is the open will be an important part of continue to support this application innovation. I really like that concept, Andrew.
I think this idea of rapid prototyping, so we fail fast, but we learn a lot and that speed is is very much what we're trying to do. I mean, you know, certainly if you look at our evolution of ROcm, I think it's fair to say that even a year ago, we probably were much, much more focused on sort of the hyperscale environments. You know, they buy lots of GPUs.
You know, these are large labs. And we learned a lot through our partners there. You know, we very much appreciate, our partnerships, with, you know, Microsoft and meta and, and OpenAI and these folks, but we also realized that the rate and pace of innovation that's happening in the startup community is, like, unbelievable.
I mean, the kind of this idea of lots of people, great ideas, fast learning. And so, we've really shifted our developer efforts to something that is, you know, much more. Let's get stuff out there quick.
You know, you know, a new, you know, runs this program for us. You know, every two weeks we have a new training Docker, new inference Docker that goes out. We do a good amount of test on it, but obviously we we don't get everything right.
We get quick feedback. We make sure that we get that feedback and have it go into the next release. And frankly, the speed of that helps us learn much, much faster.
And so back to, you know, your question sharing about how to get involved. I actually think this, this notion of sort of the two pieces that Andrew said is exactly right, like for the vast majority of you. Like, I never want you to think about it like, think about this stuff should just work out of the box.
You know, if you're running on PyTorch or you're, using any of these, you know, let's call it, higher level frameworks and you just run on AMD, there are times when you need to do performance optimization or we need new kernels or some kind of kernel optimization. We're actually starting to you know, training AI to write kernels. for us, so that we can get that done faster.
Actually, that's one of the things young lady is going to do here. As Sharon and her team join AMD. But for those of you who are innovating and you have good ideas, I mean, we'll take that code and directly put it into our inference and training Dockers as well.
That's kind of the very positive cycle we can get with a lot of people who are doing different use cases on our hardware. I think almost a testament to, you know, it being so easy to use. Seeing AI researchers creating the new architecture on AMD GPUs and running with that, or, developers creating the new agent interface on top of AMD GPUs and scaling that out.
I want to shift the conversation a bit to something that we were chatting about backstage, around jobs and I. Andrew, I think you mentioned that I think people think about like, okay, this is automating a lot of the code I'm writing. And I spent a lot of my time writing code.
So where does that go? But also what opportunities does that open up? So, as early as I know, early this year.
And so the last year, there are a few people advising others to stop learning to write code because AI will automate it. I think we'll look back on that as some of the worst career advice ever given. Because there's something becomes easier.
As something becomes easier, more people should do it. Not fewer. So, I think when you know, the world move from, punch cards to keyboards, right?
Became easier to code. More people did it when they weren't moved from assembly language to COBOL. There are actually articles saying, well, we now have COBOL programing is so easier.
It looks like we don't need programmers anymore. But the opposite happened, right? And I think as we now have AI assisted coding, a lot more people should be coding.
And I think the demand for software is custom software is has no practical ceiling. So the cost of software engine comes down, which it is. We just get more and more great software out in the world.
But software engineering is shifting. So there is a stereotype of, you know, the fresh college grad. There's a Gemini native that is outperforming the much more experienced engineers.
So I should just be really straight and tell you what I see. It is true that a fresh college grad is really on top of AI, will outperform a full stack engineer with ten years of experience that is still doing things they were back in 2002. Sorry to 2022, right?
Three years before GenAI. I but the other piece that is less well appreciated is the best engineers I know are not fresh college grads. No offense to fresh college grads.
They're actually very experienced engineers that deeply understand architecture and a conceptual framework of how to think about computers and additionally are on top of AI and AI skills. I know that, one source of angst has been the uptake in, you know, difficulty of finding jobs. The fresh CS grads.
And I think one really unfortunate thing is many businesses just can't find enough skills. Gen AI applications developers, people that know how to use their coding assistants, how to use them, the building blocks at least alluded to to build really valuable applications really quickly. We just can't find enough of those people.
But a lot of the educational systems, especially, you know, university curricula tend to get updates too slowly. Are still not yet training people for these jobs that are very much in demand and that, companies can't get enough of. So I think in the future, we will need a lot more software written.
But there is a big upskilling challenge to teach developers as well as, frankly, non developers to use these tools which make them much more productive. Yeah, I mean, I can tell you from our perspective at AMD, we are hiring a ton of people. So there is and we are using AI everywhere.
We're using AI everywhere in our workflow. You know, throughout our hardware work, throughout our software work, you know, throughout our sales, marketing, HR, all of these places. But the fact of the matter is we still need more.
So the idea that somehow AI is going to replace all of these jobs, I think it is just simply not true. You know, for us, the real quotient is how do we get more products to market faster? You know, frankly, that's the goal.
If I could do, you know, a three year project and do it in six months, that that has incredible value. Now, you know, we can't necessarily do all of that. But we can certainly, broaden the pipeline and do a lot more.
So, I think that says that there is a back to this comment of the more I you use, the more capable and productive you are, and the more we're going to be able to get from a engineering standpoint is certainly, certainly my philosophy. And, this idea of sort of continuing education. I mean, you know, Andrew, I really appreciate much of what you do in terms of just, this whole notion of you don't just go to school and stop learning.
You actually learn every single day, and you learn in different ways, right? You learn on the job. You learn through, you know, courses, like much of what you're doing on Coursera and frankly, we learn by forums like this.
I think that's the key. I mean, the key thing is, you have to keep this pace of learning up. And that's what I actually helps you do, is to learn much faster.
Yeah. So you both shared some really great perspectives, really strong perspectives. What should the audience take away?
Wrapping up a bit, what should the audience take away as a developer? From the session, what's your call to action to each and every one of them? To me, one of the most important life lessons is, you're allowed to just do stuff, right?
You know, don't harm anyone. Don't do damage. But so long as you're not doing damage to people and things, you're like, just do stuff.
And I think in today's world, with AI assisted coding tools and really amazing AI building blocks, the number of things that individuals can do and can implement has exploded. So I think this is just a wonderful time to go and build stuff and, you know, so long as you're not harming anyone, you don't need anyone else information. You don't need anyone else to think your idea is a good one.
Just go and build stuff. And then if what you build sucks, build it anyway. You learn the lesson you think you've learned in a subset that don't require dev, and then go build something else.
And I find that, a lot of my best, you know, projects, including, you know, frankly, Coursera sort of as a side project and actually felt like, boy, I'm a Stanford, back then, I'm a Stanford professor. Should I be am I allowed to be spending time doing this with online educational stuff that no one cared about? But I thought, hey, I want to build it at home.
And I think a lot of the best projects I've seen across Silicon Valley were these weird things where someone without asking for permission but still being responsible, right? Just went and built something. And a lot of times it does require dev, but even when it does, you still learn.
And then sometimes you could be the one to build something really amazing. So I would say, is easier than ever before to build amazing things. Just go ahead.
You know, build, build, build. That's great. And I'm going to be really simple.
Take what Andrew said build, build, build, and build on AMD who Just give us a shot and look I want to really say that when we say developers are really the center of what we're trying to do with ROCm, we really mean that. And it is a, you know, AMD is very much a learning culture. We understand like we're I'd like to say we're at the very early innings of AI.
As much has happened over the last couple of years. Just imagine what the next five years or the next ten years are going to be like. Like we're just at the very beginning and we're in this ecosystem.
We have a chance to kind of write the page on what's going to happen in the future. That's a great place to be. So we want to be your partner in that.
We want to be an enabler of that. And, we want to learn from you and, you know, really help you learn as well. So, again, thanks for spending some time with us today.
Thank you, Sharon, for moderating. Thank you Andrew for for participating. And, I think we have a lot of great things we can do together.
Yeah. All right. Thank you both.
Please join me with warm applause. Decision. Thank you.
Thank you. Thank you.