Okay, great. Thank you, everybody. Hi, I am Amy Sutter, and I am sitting in for Rob Sanders, our European Semi & hardware Analyst who unfortunately was not able to be here today. He covers Qualcomm. I will be running the fireside chat. I want to introduce Durga Malladi, who is the EVP of Tech Planning, Edge Data Center, who is here from Qualcomm. Maybe just to get started, I know you said you have been at Qualcomm since 1998. Can you give us a little bit of your background, kind of what different roles you have had? Sure. Yeah. I joined Qualcomm in 1998, so it is my 29th year over there. Inside Qualcomm, we have gone through at least two different DNA mutations over the last two and a half decades or so. This is the third one. I ran our research and R&D organization for the longest period of time till about 10 years back or so. That is when Cristiano, who is our CEO now, my boss now, he said, "I want you to come over on this side and help on the business." For the last few years, it has been more than a few years now, eight or nine years, I have been running the product planning. At this point in time, I run all of our technology roadmap across all the businesses, ranging from this lowest end IoT all the way up to data center. Last year, when we restarted our data center business, I ran the business for one year just to kind of make sure that we are in the right direction, and now we have a full-fledged business unit that is running by itself. That is my role. Awesome. Great. I think, since the Analyst Day, the most common questions I think that we have been hearing from investors is how are you going to differentiate in the data center with your newly announced High Bandwidth Compute technology? Can you maybe help us understand the genesis of HBC and kind of where it fits into your total strategy? Yeah. It started off, first of all, when we unveiled our HBC product portfolio and the multiple generations that we are working on, it is important to understand that it is not something that we just did in one year or so. It was something that has been in the works for the longest period of time. It was last year that I felt like we have reached a point in our R&D where now it is time to commercialize this. Working backwards from there, what is the problem that it is solving? That is something that became quite clear to us by 2021 timeframe. When we were observing how the compute, in each of these data center racks, and in fact, it also holds true for some of the other places, it is growing quite a bit exponentially, generation over generation, while the memory bandwidth was kind of stagnant or maybe growing more modestly. It is more of a linear growth. It eventually will lead to a memory wall, wherein you can throw as much compute as possible, but it is going to do absolutely nothing when it comes to inference decode portion of it, unless you solve the memory bandwidth as well. We invested quite heavily in our R&D, and when we reached a point where last year where it is becoming like, yeah, now it is feasible. We have cracked a lot of the solutions over there. Keep in mind that we called it as High Bandwidth Compute because it is not really a pure memory technology. It is actually about a combination of how do you have the compute right next to memory, how do you design it, co-design it in the right way, and then make sure that it interfaces with the rest of the AI accelerator. It was a direct take on an alternative way of doing things as opposed to HBM. We feel very confident and comfortable with where things are right now, and that is why we unveiled our multi-generation solutions, with the first generation coming out next year and the second generation after that. That is a very unique proposition, and now it is fully endorsed by a large number of the memory vendors as well, who have been our partners for a while, but now they are equally out in the open and talking about something like that. Yeah. Great. Yeah. I would not have thought of Qualcomm as being in the memory game, but talking about it as a compute technology is very helpful. Maybe just to dig a little deeper, when you talked about Gen 1 and Gen 2, and I think at the Analyst Day, you showcased the bandwidth per watt relative to HBM, and then you also have some very high numbers relative to SRAM. Can you talk about the unique selling points, versus HBM and SRAM that you are talking to customers about, in terms of solving the issue with the memory wall? Okay. Two things over there. First is, some of the numbers and the second part is on proof points, and maybe I will shed a little bit of light in terms of how the discussions are coming up with hyperscalers. In terms of numbers, we always talk about tokens per watt because the power consumption is something that is very important, and today with HBM, the power consumption is very high. By the way, a funny anecdote on that because we talked about 6x improvement compared to HBM in terms of tokens per second per watt. The second part is HBM today is about give or take 21 TB- 22 TB per second. We are, like, in hundreds of terabytes per second. When we compared it against SRAM has got its own restrictions. It is the fastest interface, but it consumes more area. You will need a larger number of racks to do the same thing, so there is a TCO argument to be made against SRAM. These are the three things that we talked about at Investor Day. The important point is, okay, these are numbers. What are the proof points? The nice thing is that, yes, we taped out the silicon. The silicon is back in the lab. It is coming along very well. Stay tuned on that front as we start unveiling this a little bit more on what the numbers are beginning to look like, but we are pretty confident in terms of the first generation of the products. A bit of an anecdote on this. Right after Investor Day, we spoke about this. We said, "Hey, here is HBM." There were these two nice animations, one which talked about, okay, this is no good with HBM. On the other hand, with HBC, this is great. Right after that, I was in Korea with two memory vendors, and I fully anticipated them to say, "What are you talking about? We have this awesome roadmap with HBM that is really great. It is going to be much better than HBC." That is not the feedback that we received. Instead, what we got is, "Hey, how can we work with you much closer on this?" In fact, we have been working with them because we need to make sure that we have the right supply as we do the commercialization. In addition to that, there has been a lot of interest coming in directly from the memory community itself, which has been a very positive and pleasant experience, and that is actually great. It also kind of validates some of the points that we made that we need a different kind of a solution as we move forwards in these data center racks. The second generation of the product, so the first generation is slated to be commercial and shipping in 2027. We are already working on the second generation, which is going to be in 2028, and those numbers are even higher. One of the reasons for that, as in terms of the relative comparisons against what we anticipate with HBM4E, the reason for that is as we look ahead to 2028, a lot of things are evolving in itself. On one hand, AI models themselves are evolving, which means the compute that we end up doing in the compute die or the logic die, which is underneath the DRAM stack, we actually are anticipating what we need to do, and we are throwing in even more arithmetic. It is harder to scale that with HBM, so the relative gain looks even better with that. That is where we are. Great. Okay. One of the criticisms of it is with the multiple layers of LPDDR on top of with high-performance logic that there is thermal issues. Maybe can we talk about how you are getting around these with, I guess, your packaging technology? Then you mentioned Gen 1 and Gen 2. Just maybe some milestones for us as investors to think about and for us to look for in terms of this. Then I know you were talking about talking with the Korean memory players, but also, are you engaging with hyperscalers today? I do not know if that is something you have shared yet. Okay. Short answer is yes to all of them, but I will start with proof points. As I said, silicon is back in the lab, looking good. It is coming along very nicely. I do not believe we have explicitly put down dates as to when this is going to be unveiled, but in the next quarter, just stay tuned on that front. I think some of it is also within our marketing domain in terms of how we want to expose it, but we will have numbers. We will actually have the silicon validation coming in, and we are on track to ship both from the samples, the engineering and the commercial samples, and the technology validation in itself. I think it is looking good. We do not anticipate any issues for the first generation. What's happened is that as we brought this up and we started talking to every single hyperscaler, every hyperscaler, they have a lot of their own in-house solutions. Most of them, some of them are like, "I have my CPU." Some of them are like, "I have my CPU, and I have my AI accelerator." But very few of them always relied upon HBM as a, okay, it's one of those memory bandwidth things. I will acquire that IP, and then I'll build my rack on top of it. It's always been really good when we sat down with all the hyperscalers, and they took a look at this like, "This is awesome. How do I actually bring this in?" At Investor Day, we specifically talked about these are three different tracks, independent tracks. For example, some hyperscaler might come in and say, "I have my CPU and my AI accelerator. I need your HBC to be a standalone product that works with this." We have a solution for that. There might be someone else who will say, "You know what? I have my AI accelerator. That's good. I like your HBC, and you know what? Your CPU is looking pretty good too. Maybe I can take both of them. How does that work with me?" We have the answer for that as well. It kind of is now at a point where with hyperscalers, we're not coming in with some sort of a it's all or nothing. No. You can take individual components if you want, or you can take all of the above, and then we take it from there. Got it. One of the things when I think HBC, the concern is maybe when you look at prefill versus decode, and I know memory is more focused on the decode side, that's where the bottleneck is. But can you maybe talk about how HBC does there? Yeah. If you are looking at inference in data center, typically we split that problem into, there's the prefill stage and the decode stage. The prefill stage is fully compute dominated. The more compute you throw at it, the better it is. And of late, we are seeing something like a 2.5x- 3x increase in compute generation over generation. You can always solve that problem with throwing more compute at it. HBC will not do much about that one at all. On the other hand, decode is completely memory bandwidth dominated. You can throw as much compute as you want, it doesn't matter. Unless you have a solution like this, it's not going to work. And that perhaps is the place where in all these discussions, not just with hyperscalers, with a lot of the others as well, we see this, "Hey, I have my compute solution. I can use it for prefill." Perhaps for decode, as you're doing HBC, there's additional logic that goes into the bottom die. You can bring in that logic over there, so there's even more of a mix and match that's occurring in that space. That's how we anticipate, at least in the short term, things to evolve. In addition to all three of these, CPU, our AI accelerator, and HBC, at Investor Day, we also talked about our custom silicon business. If you think about everything that I said, you're almost getting to the point of, is it like a custom silicon for something that's going into a hyperscaler? I think there is a very thin academic line between these two arguments because once you start putting it together, it does go in that direction. But there's a heavy dosage of our IP that goes in along with mix and match with their IP as well. Got it. I think SK hynix and SanDisk are also talking about High Bandwidth Flash. Though it seems like it's a little ways out, at least that's my take. But could hyperscalers take a pool of HBM and HBF and run their models more cheaply? How does your HBC defend against that kind of TCO narrative, if that's something that becomes a way that we're trying to attack the memory wall? When we talk to memory vendors, and we have gone into this in depth with them in terms of HBC versus HBM and what is coming with the High Bandwidth Flash, this is my opinion over here at this point in time, HB Flash is trying to solve a slightly different problem. It is not quite exactly the same problem. Because one of the things that is the argument over there is, let us also use Flash in addition to DRAM to actually do something else over here. That is not the same thing as increasing the memory bandwidth to the point that the decode performance becomes really good. But it has its own use case. There is still more work to be done. That is just the perspective that we have right now. But it is one of those stacks which is kind of independent of this. Meanwhile, with comparison against HBM, the same vendors who have been working on HBM for a while, they are like, "I need to open a parallel track in addition to this, because it is not obvious to me that in the near future, at least for the foreseeable future, not just near future, there is anything like HBC that I can offer through my HBM." Now time will tell. Maybe five years down the stream, it is going to be a different story. But as of today, that is the only solution that actually gets us to this level of performance gains compared to what we have. What I think has been very interesting for me, coming from Hot Chips earlier this week, is just the diversity of solutions that are coming out today in compute, GPUs, CPUs, and in memory, and how every hyperscaler and customer model company is attacking it differently. When I think about HBC, can it be relevant for other end markets outside of data center, maybe auto? It is a very good question, and when we talked about HBC at Investor Day, and of course, at Investor Day, we were talking a lot more in terms of our investments into beyond what we typically have done in edge devices, and that is why we talked a lot about data center. But truth be told, HBC is a generic technology. It goes all the way down into devices. Let me explain why that is the case. Believe it or not, we are working on HBC on devices that are around us today. We are actually working in terms of what is the technology that makes sense for that. Here is the reason why. In data center, the comparison is against HBM, and we are talking of what is the best way to solve the decode problem and the memory wall problem over there. There is no equivalent problem in devices. Let's take a smartphone or an agentic AI device, but there's a different problem over there, especially with agentic AI devices. These are devices that are being built as we speak with those who've been in the business of thinking AI first, and I need to build a solution around it. It's all about ambient AI. It's constantly running. That's why we call it agentic AI. It's always running in the background and just waiting for you to say something, and then it picks it up from there. But if you're always on ambient AI, always on, that means you're always burning power. Now, HBC is compute is right next to memory. So there's something else that you get. We've completely collapsed that transport latency between memory and the compute. Not just that, the power consumption has come down dramatically. It's perfectly suited for ambient AI in all sorts of agentic AI devices that come in now. So the usage of HBC in devices is in the context of ambient AI, whereas in data center, it's about the memory bandwidth that it provides and the decode performance. When you say edge cases, are we thinking about something like robotics, where we're thinking about AI there? Or could you think of it being used in a car or a phone or. Going all the way down to smartphones, tablets, PCs, XR devices, and yes, into automotive as well. It comes down all the way to those. When do you think that happens? Discussions are going on as we speak. Typically, we have a lead time on this. If you have a commercial product in one year, then usually it's three years before that is when the commercial discussions begin. That's a question for once it shows up, you will realize it, but suffice it to say that we're not that far from the first generation of the commercial products coming in. Got it. I guess then maybe closing out on HBC a little bit. Do you think it's with Gen 2 or Gen 1 where you see customers really clamoring for it? Does it become a technology that you might offer to license to third parties to help them scale, or do you look at this as some kind of proprietary moat that Qualcomm can offer? There's two questions over there. The first one, in terms of going beyond Gen 1 and as we're going into Gen 2, where exactly is the action over there? Gen 1 is next year. That's literally next year. There would be a few customers who'll go in that direction. But then as we talk to a lot of the hyperscalers and so on, there will be some separation between where the volume is going to be between Gen 1 and Gen 2. We will certainly see traction on Gen 1. I hope we see a lot more, because more and more customers are lining up. The earliest adopters are the ones who are going to go with G 1. But now we have so much of incoming interest coming in. I do anticipate more coming up with Gen 2 as well. That's the way that we see it. The second part is in terms of how we see this technology. Just keep in mind that there's actually three different components to it. We're not a memory vendor, so someone is still doing the DRAM stacking. We're not doing the DRAM stacking ourselves. What we prescribe is this is how things should be done. These are the TSVs that need to occur. This is the design for it. The compute die, of course, comes from us. We do all the logic inside that. We still have to work with the likes of TSMC to tape it all together. I think we are all in our swim lanes in our own way, but we are kind of like the overall system integrator and putting it together in the right way. In that sense, this is our current model. We haven't said anything about how it's expected to evolve, but that's where we are now. If I'm a hyperscaler customer, would I be the one who's focusing on the memory? Because memory is a big bottleneck today. You don't have to worry about that, the hyperscaler worries about that, and you just help get the solution integrated together and in. When a hyperscaler is interested in our HBC product, they will have certain volume commitment, some sort of a demand signal that we get. They talk to us, and they will cross-check and make sure that, "Hey, you're all from a supply perspective, that's great." They talk to us, and we are like the front end for all of that conversation. Of course, they will be talking to the memory vendors to make sure, and to the likes of TSMC, to make sure everything else is in the right order. This is a product that comes from us to them. They are our customers. That is how it starts. Okay. Great. Switching over a little bit, let us talk about the Dragonfly C1000 server CPU. You have some very high claims in terms of performance per watt relative to peers, but it is a second half 2028, if I am correct, right? That is correct. You are kind of giving away some stuff now. How do you think about what the competition is doing, and does the baseline shift from the other big CPU competitors? Could it be challenged at arrival? Last year, I remember when we decided to restart this, and I was thinking about, okay, what are the differentiations that we have over there? The first one, I was like, okay, we got to go into the memory architecture and memory wall solve the problem. Our R&D project is good to go. That's good to go. Then I was looking at, okay, where are we with our existing CPU solutions, and what is the right way to scale that? We had something in planning already at that point, because over the last three or four years, we have been investing quite heavily in our custom CPU solutions, our Oryon family of CPUs. And I was paying very close attention to exactly where each of the data center class CPUs are. You can start from Neoverse V2 and take a look at the generation over generation. What I was looking at is, we are not competing against anyone else out there today. I want to compete against where they are going to be in 2028, and that was the mindset with which we went in, and we need to beat it by a certain generation for it to be compelling. If it is 2% better, then nobody is going to take it compared to their own in-house solution or something else that you get. It has to be really compelling. That is the bar that we set for ourselves. And over time, as we built this up and we did all the benchmarking, typically this is done with SPECint2000 and so on, and we have our projections. One of the hyperscalers, the response from them was, "Your numbers are too good to be true." I was like, "Okay, what I am hearing is, if you do actually show up at that, you will like them." He was like, "Oh, yeah, absolutely." Now we have made our claims. You are absolutely right. We feel very confident about those claims. We have absolutely no second guessing on that at all. Now it is execution and crunch time. We announced Meta as our first customer for C1000. They believed our claims. Qualcomm is a company where if we say this is what is going to happen, never have we actually fallen short of it. We have always been on par or better. So they went with our reputation and said we are good to go. There are others who were like, "Let us see your silicon, and then we will be there." I am really looking forward to that, but I feel extremely confident about it. The next milestone will be launch with your first customer or investor? Launch with the first customer, but even before that, the commercial launch is in 2028, but with silicon back in the lab, all the proof points and so on, hopefully we will be able to share a few more things in our view. Great. Okay. I also think, too, that CPU, the offerings we see in the market today, some of them are more focused on more cores, some of them are more focused on single core, like hyper-threading, or if I get it right. I am still kind of curious from your perspective when you look at CPUs in the data center, what you think is the right solution, or maybe there is not, again, because workloads are going to vary so much. I would love to get your opinion on that. Till about two years back, I would say that, by the way, the CPU landscape is evolving as we speak, and it is becoming like for the longest period of time, including inside Qualcomm, by the way, it is like our XPU team or the GPU and the NPU teams are like, "Okay, we are in the AI business, and the CPU team is not quite there. It is a little bit out there," but it is not quite like that anymore. All three processes are important, but in a different way. What has happened in the last two years is it used to be that you had two different kinds of workloads in data center. General purpose compute, that means you just run, you light up all the cores. At Investor Day, we said that our racks have 250+ cores and so on. So, okay, so let's say that you have 256 cores or so, then you light up all of them. It's general purpose. It's like a workhorse. Then there is a different configuration, which is an AI head node, where actually most of the AI workload is being done by some XPU that is sitting out there. The CPU's job is to do some management and kind of get out of the action and let the GPU or the NPU perform whatever it is that's needed. All the AI inference occurs over there. But that led to an asymmetry in terms of number of CPUs to XPU. It was like 4:1, it used to be 8:1, became 4:1. But with agentic AI, that's changing quite a bit. In fact, nowadays we are more in the 2:1 configuration. For every CPU, there's 2 XPUs, maybe there's not four. And I wouldn't be surprised if it actually becomes even less than that, it becomes more and more symmetric. As these conversations evolve, we initially started, "Hey, your cores look really great. Excellent for general purpose compute. I think I got it for AI head node. I probably don't need you, but general purpose compute is great." But over time, now we are getting, let's actually talk about not just general purpose compute, but also agentic AI, because I would like to use those CPUs over there as well. So that's the evolving landscape with CPUs. And the workloads themselves are shifting. They're becoming a mix and match of general purpose compute and agentic AI. Not just AI head node, but agentic AI workloads which look very different. Right. Okay. And then also talking a little bit about your roadmap overall. You're also using your RISC-V cores, so you have two roadmaps here with Arm and RISC-V. Maybe you could talk about why do that. What challenges does that create or what opportunities does that create? So, couple of data points on that. The RISC-V conversation is an important one because it's usually, I would argue that whenever one talks about RISC-V, for the longest period of time, it was seen as something which was academic, which was a little bit out there. It's a good science experiment. If you're a grad student in a university, it's an excellent project that you should be working on, but not really for commercialization. That used to be the narrative till about one and a half years back. Not anymore. At this point in time, there's a lot of, not just interest, but pre-commercial engagements that are occurring in terms of where do we take RISC-V cores. But I'll get to that, because the first question to ask is why? What's causing this? What exactly is the issue with this? Historically, what has happened is that if you are in the custom Arm CPU business, then you inherit a certain architecture and your innovation is within the microarchitecture domain. That is where you tend to innovate and you try to differentiate. But you inherit a certain architecture and that is all there is to it, which means your scope of innovation is only below a certain threshold, but not everywhere else. RISC-V, on the other hand, is completely open. If you have some ideas, you actually go to the standards process and you say, "This is what I would like to see," and that gets done. It is an open standard, so there is more innovation coming over there. It is a clean start. Every three decades or so, there is a new ISA that comes in, an instruction set architecture, and we see a lot of potential in RISC-V as well. That is where, as Qualcomm, we started investing quite heavily. First making sure that the standards organization is a professional organization that is run with commercial milestones in mind and not just for research purposes. Qualcomm has a lot of leadership positions in the RISC-V forums. In addition to that, we work with our hyperscaler partners and say, "Hey, it cannot be just us. There has got to be an entire software ecosystem that needs to come in." They started participating quite heavily, and we have very good partners over there. A few hyperscalers, both in U.S. and in China, which brings me to the other point, because the other narrative that comes up is RISC-V is it is something that is going to be done in China, but I do not know about the rest of the world. Not true. In fact, we will start seeing that in the U.S. as well because there is a lot of incoming interest. As a part of this, we have started investing quite a bit in our RISC-V portfolio, even towards data center, especially towards data center. Last year we made an acquisition of Ventana Microsystems, and that team is now fully integrated and we are on our way. What is the advantage of RISC-V then? A couple of things come in. First of all, it is going to be a parallel track, which is occurring at the same time. We see the demand is going to be like a mix and match of both over time. We expect to see that just because of the features that are coming in on the RISC-V roadmap as we look ahead. It is to be seen as to where does this end? Are we going to have two tracks? We had x86 and Arm for the longest period of time. One shouldn't be surprised to see even these parallel tracks come in. It is not A or B, it is A and B, depending upon their own customer needs and choices. Why did China? It seems like China has been the early adopter. Is there a reason for that? That is a good question for China. All right. I'll ask them. Maybe to move on a little bit on the software side of things, obviously, as we all know, NVIDIA dominates with CUDA. Changing those programs to be able to adapt to non-NVIDIA chips, it's hard. Modular, that software, how does it make it possible if I'm an NVIDIA to maybe use, for example, maybe your CPU or what have you? So how does that happen? How do you reassure developers over time that these compilers will be open and available so that they don't get locked in on Modular? Absolutely, yeah. By the way, there's two or three questions over there, but I'm going to actually start back with It's okay. It's a very big investment that we've made, and it's an important concept. So I'll start with, at Investor Day, we talked about our acquisition of Modular. We hadn't closed yet at that point in time, Chris talked about Chris Lattner, he actually talked about, okay, where this comes in. There was this one flagship slide for those of you who might have either attended or seen it on video, and if not, I'll just explain, where we put together, I remember with Chris and Tim, we were literally on the floor and saying, "Okay, we should put it like this." Literally put them right next to each other. So there's Mojo, then we put in CUDA on one side, that's from NVIDIA. Then we said MAX, that's for the compiler layer. They said, this is Triton, that's for the compiler layer over there, and Modular Cloud, and that's Dynamo on top of it. So it's like this is the CUDA stack, if you will, and this is the Modular stack. Underneath that, from a hardware perspective, it's NVIDIA hardware only. Here, anyone. It can be any third-party hardware and any third-party processor. It's a bold claim. Then right below that, we put in a footnote. We said, when you take Modular stack and you take your existing rack, as an example, and you have your native stack, then you say, okay, instead of that, you use Modular stack, the performance is going to be on par or better. When we said better, we said up to 50% better. That was the fine print over there. It took some time to actually write that down. I remember telling, "Okay, Chris, okay, now that we've thrown this gauntlet, we're going to get a lot of questions in, and it's going to be fun." It is. In fact, one of the first things that we did, the moment we did that, we got some really good feedback from a lot of the others saying, "This is awesome. I would really like to actually try this out and take a look at it." Because others have tried. Others have tried exactly the same thing, and it's not quite panned out that way. It seems too good to be true. You have true disaggregation of third-party software that can run on any third-party hardware. As Qualcomm, we are saying, "Here's a software product. Try it out, and it can run on your hardware as well." Second, it's going to be open. There's quite a few new things from Qualcomm's perspective. That's why I said it's our third mutation over here. Last week at ModCon, we went one step further. We said it's going to be open source for Mojo. On MAX, by and large, it's open source. It's on Apache 2.0 license. Anyone can take it. They will have full source access of this. There's some portion of it that's going to be licensed, and we go from there onwards. We showed even more numbers. The best part, we had a person from AMD who showed up on stage and saying, "This is awesome. I'm going to try this out." That is a game changer. It seems, yeah, that's okay, but actually, at least for us, we were like, it's quite something to have a third party come on stage and say, "I'm going to actually start taking your software, and I'm going to try this out." So everyone is interested in now kicking the tires and taking a look at what the performance is going to be. We really want third parties to reach that conclusion themselves. What we don't want is, yeah, we are doing our own analysis. We have our benchmark, but if I were to show up over here and say, "This is how much better it is, but it's all done by Qualcomm," no. I want AMD to do it, want someone else to do it. I want third-party artificial analysis and someone else to do it and reach the same conclusions. That is what is happening as we speak. It's interesting you say AMD. Does it compete with ROCm? That's something that they are. That's a question for them, by the way. Yeah. But it was nice to actually have them say, "This is something we want to try out. Yeah. Where that takes them, that's a different story. Yeah. We'll take it from there. The final part that I wanted to mention, which was a humorous anecdote because the Modular, as I was talking to Chris, they had brought up Modular software on everyone else's hardware except Qualcomm, which is so odd. Last week, for the first time, we also unveiled it running on our platforms, including one of the older generation AI 100. That's on the data center side. We even showed it on one of the laptops, an X Elite platform. So it's the beginning of that. We said any hardware, it of course must include Qualcomm as well. So we are beginning to do that. Got it. Can you talk about the partnership you have with Hugging Face? Yes. That was the second part of that presentation at Investor Day. Hugging Face, 15 million developers flock to that website on a daily basis, largest repo of AI models, open weight models out there, 3+ million models. On the other hand, we have some data that indicates that the most popular ones are probably far more concentrated. Not all 3 million are the same, and some of them are derivatives. But clearly, it's the place to go if you're a developer, you're in the business of building apps or writing agents or building agents, first you go to shop. That's the place that you land up at and say, "What do I have to work with?" All the things that are available out there. In our partnership with Hugging Face, we want, first of all, agentic onboarding of any of those models. Any of those models, agentic onboarding of those models onto our platforms. What does it mean? Today, I go to Hugging Face, I'm going to click, I have to manually click on something, and then it gets downloaded. Then I have to write something with that, and then I have to write some specific commands, and then I can start building the applications. I don't want to do that. I have one small thing. They actually have something called HuggingChat. I would like to pick some model that does object detection and classification or a text-to-video generation model, pick one of the good ones, and make sure that it runs on this platform from Qualcomm. That's your prompt. Everything else happens behind the scenes. You can actually see the code being written down out there, and it gets done, and it comes onto your platform. That makes it extremely easy for developers to start adopting our platforms over there. Second piece of the puzzle, we threw in Modular as a part of that as well. That means if I'm a developer, I would say, instead of in PyTorch, maybe I want to actually use Modular. A developer might say, "Do I have to now learn another language?" Mojo just happens to be very similar to Python. But these days, increasingly, developers themselves are not necessarily writing all the code. They're using coding agents. I'd rather say, using Mojo, I would like to see an application being done. That's actually written because it does all the tool calling, looks at all the documentation, getting done. This is where Hugging Face has emerged as a really good partner for us to do a direct engagement with developers, while at the same time, those developers get exposed a lot more with the Modular stack. Got it. Sounds like a great partnership. Yeah. It is. Yeah, for sure. You touched on this when you were talking about running Modular on some of your older technologies, Qualcomm technology that you just announced. Can you talk about how it might then support your cloud-to-edge strategy? Can it be like a universal layer to write an enterprise agent, AI agent all at once and trust that it can run on these different devices, whether it be a laptop or data center CPU? So, that's, I think, the final piece of the puzzle. We talked about it even in our Hugging Face engagement. If you take these emerging agentic AI devices that we are talking of, a good fraction of them actually, the user interface is directly to an agent. You ask something, you want a specific task to be done, the agent then decides what needs to be done. Do I run some inference on the device? First, I need to shop around inside the device and see what models do I have to work with. Is this good enough for what I need, or do I need something better? If it's good enough, I use that. But you might still need something else that's running in the cloud. So you go there, and you do a second inference instance that's running there. That's two parallel inference instances running concurrently. It's not one or the other, but it's both. Meanwhile, there might be some sort of a tool calling with a web call in which you're extracting information from somewhere else. That's the third part. When you put it all together, we have reached the conclusion that it's never going to be one or the other. It's going to be all of the above, and the agent is running several inference instances. So hypothetically, if you were to picture a world in which you have Mojo and MAX, the Modular stack, actually running on the device, and it happens to be running on the cloud instances where the inference is running, does it make it more efficient? The answer is yes. By the way, it could be any rack. It could be an AMD rack, it could be a Qualcomm rack, it could be someone else's rack. It doesn't matter. But does that make it more efficient? We do believe the answer is yes, but that's what we are working on. Maybe this is a basic question, but how did Modular, what was the secret sauce? Because you said so many people have tried this. Why were they able to do this when no one else could? Because I think a lot of people would like to break the CUDA mode. It is a combination of things, in my opinion, but one of them happens to be that if you think about the existing stacks that are there, including CUDA, for example, CUDA itself is about 15 years old now. What it was initially written for graphics and specifically focused, it evolved over time to this. There is a lot of legacy as well. One thing that is certainly been done is when it comes to the development of Mojo and MAX, it is kind of a fresh look at it, and it is done in a fundamentally different way, which makes it cleaner, simpler, and for lack of a better phrase, more modular. Got it. Literally, it is modular, the adjective. The second part of it is that as you go through the compilers, this goes one level below into the technology in itself, compilers themselves have been gradually evolving. There is notion of using AI within compilers itself, and that is emerging as well. A lot of these things have been built into it. We believe that is the real differentiation. There is certainly far more to it, but I would actually reserve that for a tech deep dive. Got it. Maybe just to talk a little bit about prefill and decode in terms of Modular's tool stack, how does that software handle that? Can it do it dynamically? Just in terms of the Modular stack, the way that it is currently envisioned and constructed, it kind of sits on top of. I would say prefill and decode are system-level concepts sitting upon certain hardware, but the software layer itself is kind of independent of each other. Everything that I said earlier about Modular equally applies to both stages. Got it. Okay. Also when you think about the memory wall that we have been, and also the power wall, does Modular also kind of attack some of this in terms of harnessing idle devices, et cetera, that might be able to help improve the efficiency or performance? I think it's a little too early to have come to that stage. We are still doing a lot of our analysis in terms of what else we can do in this space. But at this stage, I think it's a little too early. Got it. When investors are thinking about Modular, what kind of milestones and proof points should we look for? Are you talking about number of developers using or. We have a lot of things actually planned out over the next quarter or two as we start bringing in speeds and feeds and data points in terms of, okay, here's an existing rack, here's with the native stack, this is the performance based upon all these workloads, and you compare and contrast with what happens when you have Mojo and MAX running on top of it. That's the first set of tons and tons of data coming up on that one. The second proof point of that is how well does it actually scale into all the other platforms beyond data center? Keep in mind that as Qualcomm, from a device perspective as well, we are in the business of any framework, any runtime, any operating system, and we provide all the debuggers, the compilers, the tools, and whatnot that actually go along with it. There is a very rich set of runtimes that already exist. You have ExecuTorch/PyTorch from Meta, we have LiteRT from Google, we have Windows ML coming in from Microsoft. They are all great partners of ours. We will continue to support them, while at the same time also bringing in our stack as well. The next step would be to how does it work on a given platform when you already have support for one and where does Modular come in? That is the other part that you will see over the next couple of quarters. Got it. We have touched on a lot of different things. HBC, CPU, and Modular. A lot of exciting new opportunities for Qualcomm, I guess. Do you think there is something we did not cover right now that you would want to point out to investors? I know you just had your analyst day, but I thought we might wrap with that in the last. Yeah. I think the one part that I would like to say is that there was a fourth piece of this. We talked about GPU and XPU and HBC, but custom silicon I think is going to be very important for us. Post our acquisition of Alphawave, we have retained the custom silicon business. Increasingly, all of our discussions with hyperscalers involve some level of customization. It is a mix and match of everything that we bring to the table along with their IP. Keep in mind that we are in the networking business now, so we have SerDes. This is what we acquired from Alphawave. That will continue to evolve, and that is the one place where I would like everyone to be reminded of the fact that prior to acquisition, Alphawave already had these hyperscaler customers, so we will continue to go in that direction. Great. Well, thank you so much. I appreciate it. All right. Thank you.