Latest / The Information Bottleneck / How to Turn Research Into Billion-Dollar Companies, with Ion Stoica

Transcript

How to Turn Research Into Billion-Dollar Companies, with Ion Stoica · The Information Bottleneck

• Ravid Shwartz-Ziv: Hi everyone and welcome back to the information bottleneck. and today we have a great guest, Ion Stoika. so Ion he's working he's a professor at Berkeley and he co-founded many companies, many startups, Databricks, right, Arena and Arena. and more. He is the guy that his lab invented VLM, Ray, Edgilang and many other and many other tools and and software that all of us are using today. So Ayan, thank you for joining us. Ion: Thanks for having me, really appreciate it and appreciate the nice introduction. The only caveat there I would say that actually the students invented all of this stuff so I think they should take the credit here. Ravid Shwartz-Ziv: Okay, great. Yeah, so I think we can start with I don't know, maybe the the the first question that I had in mind is how you actually like you're doing it, right? Like how you're taking like so many research ideas and research projects and transfer them to such successful startups. Ion: So I think, you know, the first observation I have is that things in academia from some, there are differences but also similarities between academia and industry. So one of the similarities that in both cases, what you want to do is like solve particular problems, right? You know, maybe... Sometimes, very rarely, problems which haven't solved before, but in most cases, you want to solve existing problems which are kind of important, better. So then, some of the projects in academia inherently are going to solve some of the problems, solve a bunch of problems, and some of these problems are going to be more relevant. for industries and others. And if you are lucky to solve a problem which is relevant for industry and you have reasonable artifacts like a system to do so, then it's going to get some adoptions because people are going to use it to solve that particular problem, maybe in a better way. And if that system or artifact gets more and more popular, then you are presented with several options and the options come in the form of of, you know, are you going to... Because people, they use these systems and they are serious of betting of the systems to be part of their infrastructure or things like that, the one question they are going to have is like, okay, so what will happen with this system after the students graduate and so forth, right? It's like, can I bet on it? It's going to be still there a few years from now. Who is going to maintain it? Who is going to add new features, evolve it and so forth? So that's kind of the question. then you are, know, people who were involved in the project, started the project, there are a few options. So one option is about, You you decide that, okay, it's not worth it, so you are going to drop the back project. Whatever it happens, it happens. The other option is that maybe you are going to donate the project to another company to continue to develop it, or the last one is to start a company, right? So in many of these cases, you know, the projects like to companies, that kind of has a process, right? Started to work on a project. The project was fortunately sold. a problem people care about. The system we build or the artifact we build to solve the problem, know, got traction, was good enough for people to use it and becomes more and more popular and now you are confronted with these kind of questions about what to do. And in quite a few of these cases, decision was to start a company, which was a lot of times the decision was driven by the students themselves. And I did help with that. But that's kind of in short. The one thing I want to make sure and I want to be very clear about all of this. project all these systems, we build our open source, right? We are coming from Berkeley and as you know that Berkeley had this long time tradition in developing and pushing open source all the way from... Unix, FreeBSD, Unix before Linux, from networking stack for the internet, like TCP IP, the first database, relational database, Ingress, and many more. Allen Roush: So actually that that leads me to my first question, around, you know, the nature of of continued open source commitments. and I I ask this because we do have a decent amount of like investment type folks for who watch our our podcast. And I've been fascinated by you know the value that VLLM and S G Lang have had as unifying frameworks in allowing any model, any reasonable LLM to run on on a wide variety of hardware. Right, like you know, AMD, NVIDIA, et cetera. and I w I'm c you know, I don't know that much yet about Infraact or Ratex arc, but I worry that these companies, you know, have a sort of vested interest in potentially taking away some of the juiciest parts of the the f you know, next innovations that would otherwise be merged into those projects. And and, you know, do they try to compete kind of like t with Together and Fireworks AI, or how do you see them and can you com you know, can you Say for sure that VLLM and S G Lang will will stay open source. Ion: I think that's hard. So first of all, this both Infra-Act and Radix-Hack are early on. So there are still a lot of things to figure out about the business. So that's number one. In terms of your question, it's about remaining open source. I do think that... they are going, and I do hope they are going to remain open source for the foreseeable future. And I think one of the reasons for that is that it's a competitive market and environment. And so I think that alone should encourage the open source motion. And it's it's even, it's like VLLM, it's HLANG, it's TensorFlow, you know, NVIDIAs. offering as well TensorRT LNM. yeah, so I think that's all. It's enough to drive the open source for quite a bit. Ravid Shwartz-Ziv: So I I want to ask about so your recent like talks frame you know an AI stack, right? that like you from scaling workloads down to inference with like now V L and S G Lang. both kind of like maturing w what do you think is the real remaining bottleneck? is it memory, communication, scheduling and or Maybe something else less obvious. Ion: Yeah, that's a good question. So one thing, yeah, we actually, when we look at some of these problems and when we started some of these projects, one of the things we did consider about the trends to see whether the trends are going to be very important. the relevance of the problems you are going to solve, right? It's like if, say, you focus on solving a particular bottleneck, if that bottleneck disappears because of the trends, then your solution always will be no longer relevant. So I think that's kind of important aspect. So now, think that taking a stab back, I think that the biggest challenge I can see is that the sheer complexity of the stack has grown in order of magnitude. compared with what was 15, 20 years ago. Just to be very, you know, just to... And again, instead of... describing the problem here, again, solving the problem may require many things. But when this spark, it was, you know, started in 2009, so I don't know, like 2010, so it was 16, 17 years ago. When we did that, it was still complex because you are talking about distributed systems. Distributed systems are more complex than single node or single systems fundamentally because you need to deal with failures, communication, and many other things. But still, if you are talking about the environment, the clusters you're deploying the systems on. We are talking here about Hadoop, Spark. They're homogeneous clusters. So more or less the same nodes. then... Each node has Intel CPU or maybe AMD. That was the biggest Intel time back then. And maybe you have hard drives and they are connected by the ethernet, right? That's kind of what you have. then, so then on top of that, you are going to have this kind of Hadoop and Spark, which are also pretty, so to speak, they are distributed, they are pretty regular, parallelism, right? This is data parallelism. And you have these kind of stages, each stage consists of tasks, which each task is basically doing the same kind of work for different data partitions. You partition the data, and then you shuffle between the stages. And now fast forward today, and it's so much more complexity at all levels. you think about the clusters. Clusters are not only distributed, you know, you have a huge heterogeneity, right? You don't have only CPU GPUs, but if you look at the GPUs, accelerators and so forth. Like the last time when I checked, like for BLLM was supporting hundreds of different types of GPUs and accelerators, right? Then it's not only that, it's also the networking. The networking is far more complex. You have RDMAs and quiz topos, InfiniBand and things like that. And then the hierarchy, the topology of the... The cluster, the network topology is very important, right? Because now you are going to have not only kind of server, you connect servers, can track rack level servers like NN and NVL and 72. You can have then ports, right? This kind of a lot of racks which is tightly connected together. And then you look at the applications. The applications are, workloads are so much more complex, right? is not some kind of regular parallelism. But you have nested parallelism, you have so many things which, because they are driven not only about training or you have post-training and inference, if I look at the inference how complex it became, right? You have different kind of parallelism, seven different kind of parallelism, like... data parallelism, sensor parallelism, context parallelism, sequence parallelism, expert parallelism, and so forth. So you have this whole this complexity and then things are moving so fast, right? Because every year you have a new... model GPOs from every major provider, Like look at Nvidia, right? And these are pretty different. They introduce new instructions, right? It's a button exchange. And finally, because you ask about this, it's not the challenge. It's not only one particular gap. It's that... people try to optimize the entire stack, right? It's like useful. Usually, when you build a complex system, what do you do? You divide it into kind of some components, modules, have clear interfaces between them. And this allows you to conquer complexity because now you can... worry about developing these components more or less independently as long as you provide the same, maintain the same interface between them. But now that typically when you do this modularity it comes with overhead. You pay the overhead, some overhead, right? And... people are not willing to pay that overhead because you you train a model it can cost billions of dollars so then what before was okay if you few percent you pay for overhead to have this kind of nice modular system which kind of is more revolvable it's easier to reason about it Right now, know, 1 % if it costs you $1 billion to train is 10 million, right? So then they break the layering, you know, the solutions, cross-layer optimization. So it's so much more complex. So I think that conquering that complexity, I think that's kind of is the key. And even in the case of one workload like inference, that alone is so complex. Ravid Shwartz-Ziv: And And do you think like what will be the direction? Like do you think that like the algorithms will try to follow the infrastructure and like what efficient like how to design like efficient algorithms for this infrastructure or the other way around? Like we'll try to to go and to build infrastructure for algorithms that we that we think are promising? Ion: I think... One, of course, one answer is going to be like, hopefully, know, things will stabilize and then we are going to have more time to think about what are the right abstractions, what are the right components. The other answer is about... You know, you need to figure out maybe other ways to develop this kind of software to develop the stack, right? So that's why you are talking about, and we've been looking at using AI to optimize and even synthesize some of these components in the stack. Hopefully that will be much faster, right? Because even if developers cannot keep up with it, with all this kind of... complexity and the speed of evolution of the ecosystem, then hopefully AI can help you to, like, that's the promise, right? It improves productivity of the engineers so you can do things much faster. So maybe you can keep up. So I think these are the two approaches. You need to think at all, post, know, and evaluate. different approaches in order to solve the problem in this case. Allen Roush: And do you think that know, there's these AI code generation agent tools now, Claude Code, Codecs, Open Code, which I'm sure VLLM is actually powering a lot of models running it. Do you you know, I've seen a lot of papers that show that the some of the hardest code for any code generation tool to write is anything that's asynchronous or distributed, and et cetera, which includes, you know, the fanciest like GPU attention kernels, like flash attention and et cetera. So do you think Ion: Yeah, yeah, yeah, yeah. Yeah. Allen Roush: that this this kind of domain of like inference optimization at the level that V LLM and SG Lang and maybe even at what Ray was doing, is this the kind of thing that you anticipate LLMs and it code generation tools will continue to struggle with over time, like relative even to humans? Ion: I think, obviously, on one hand, they are going to become better and better, right? We know that. On the other hand, relatively, in relative terms, I do expect they are going to struggle more than maybe, say, application level code. And there are several reasons for that. One, There are fewer examples. Think about how many distributed systems are out there versus applications like web applications or things like that. It's a lot more. The second thing is the code, the logic is much more complex if you talk about the infra. Because again, you need to deal with faults. right, to tolerate failures, recover from failures. have, if you are talking about the data, you talk about consistency, different consistency levels. And so, and the searching is just much harder, you know, takes much harder to test. And because eventually you generate code, you need to evaluate, you need to test it, right? And there are two reasons it's harder to test. One, it's because the sheer space for testing is much larger, right? Because again, you have different dimensions. I just mentioned a few of them, data consistency. reliability, actually number of nodes as well. You have, you know, and each of these new dimensions, we should not have necessary, like for instance, failures. if for, you know, the application we are using now, it's not a big complicated, you know, to handle it, right? Because it's this kind of, it's called this fake sharing. It fails, it fails for all of us. And basically we restart it, right? But in this system, this is much more subtle. again, so this means that the number of cases you need to test for is exponentially bigger. And the other one, it also takes more time, right? You need to set up the system. need to start the nodes, you know, start. So all of this takes more time. So I think for that reasons, I do expect... in relative terms, this model to struggle more with this infrastructure applications than user facing applications. And, but the other thing is about for any kind of applications, you still need to make sure and I alluded to this, it's about how do you make sure that the generated code is going to align with your intent? It's going to do what it's supposed to do. And I think this is going to be for a while, one of the biggest challenges. Right? Because you see, you know, it's like, in some sense, if you look about how you do create, how do you solve, how do you, when you are talking about a problem, when you're going to talk about an artifact, typically what you have, there are three phases. One, you come up with the idea about what you want to do, or you formulate, or you maybe, or you pick the problem you want to solve, right? Then you come up with the solutions. You write the code, or... Ravid Shwartz-Ziv: And how Ion: If it's a math problem, you come with a proof. then you can, or the idea for the proof, and then you check that what your solution really solves the problem. And what these models do, they commoditize the middle part, coming up with a solution, generating a solution, generating code. But then you are going to be left still. who is trying to figure out, and of course you can use LLMs to try to help you to figure out whether the code is correct. But at the end of the day, it's like, I think it's very hard to out-sort the entire verification to LLMs, right? Because if you write a piece of code, it's not the LLM lab that are going to be liable if it's a problem. It's you are going to be liable. Ravid Shwartz-Ziv: So how do you see like the future or like the solution? Because like there are lot of ideas around like hygenic frameworks, right? Like with verifiers for different parts of it and like do we need harnesses or not? They can like actually write them by the ride it by themselves or like so how do you see this pipeline? Do you think like we'll have the model itself that will write its own verifiers, its own harnesses, its own infrastructure? There is I think like for example I think it was Karpaty that that mentioned it like yeah maybe we don't need any like external packages anymore, right? The the the model can write its own packages or like something like that. How how do you see it? Ion: Yeah, I think, again, they are going to become better and better. But for some application, here it's a little bit like kicking the can down the road. What I mean by that is that, OK, you are going to have verifiers verifying that the solution which you generated is correct. But how do you know that verifiers are going to handle all the corner cases? Okay? Maybe you can have a verifier for that verifier. But you see, it's no longer... And then if you start... It's like actually also, you know, Andrej Karpathy, I think he said, you can outsource your thinking but not understanding, right? So if you don't, you end up with a... by a code which kind of is going to pass your tests, right? And then you are going to deploy it. And then it's going to fail. What are you going to do, right? It's like, I am going to add this as a test and so forth. But you know, it's like you need to have at least for a while, I don't know what will happen in one, two years, three years, but. You need to, I think that for the applications infrastructure you care about, you need to understand them, right? No matter how many verifiers you have and so forth. Because the way, here is another way to think about it. It's like at least how I think about it. You obviously need to be worried about this reward hacking, right? What reward hacking means is it means that in our case, it's like the code or the application is not going to behave in our case like you'd expect, right? And let me, this is maybe too abstract, but let me give you some examples. And sometimes this kind of your hacks. you cannot even think about them. So if you cannot think about them, it's very hard to also figure out, or even for other verifiers to think about it, because the verifiers are also trained on the data produced by humans, mostly. Also now you have a lot of more synthetic data. Say, and we've seen a lot of these reward hacks in our research, say you want to build load balancers, right? The simplest one. So you get a bunch of requests and you have a bunch of servers and you want to redirect the request to different servers so that you know, you... each server is going to loaded more or less the same. So then you can serve as many requests as possible. So if you serve as many requests as possible, if you can distribute them evenly across the servers. Because if you have a server which is overloaded, then you are going to have the latency and the service for the request you send to that server. OK, and in one case, the solution, and one of the metrics here, you want to maximize the number of requests you can handle. So for instance, one solution in one particular case, it was for. the solution to maximize the number of requests it can handle by dropping them. Okay? So now I'm giving these examples because it's one thing you don't think about because if I'm asking someone to design a good load balancer to maximize the load it can handle, Ravid Shwartz-Ziv: Mm-hmm. Ion: I wouldn't probably even think about, you shouldn't drop the request, right? Because it's obviously that's wrong way of thing to do. And there are many, many, examples like this. So that's what I'm trying to say is that you don't know what you don't know, right? It's like that's kind of the thing. Allen Roush: Do you d do you think that the the distributed inference projects that you've worked on, and even you know going back to things like like Spark, do you think that that's still the right paradigm today for b most efficient utilization? of GPUs. I ask because there's so many different models for how an enterprise can consume them, right? They can directly rent per GPU hour. They can go to per token inference services where they you know often pay a premium but don't have to worry about idling and then there's, you know, Spark and cluster based jobs and scheduling and it I'm just curious what your opinions are on that for for any enterprise just trying to get their toes into AI. Ion: Yeah, I think there are at least three things. So one, it's about how you consume this kind of hardware resources. And you can have reservations. You can have on demand and so forth. The reservation is cheaper to reserve this GPU. But if you need to, then on demand. But you need to keep them utilized, right? So I think, and then the second thing is about what the framework you are going to use to support the workload on this hardware, right? And obviously, if you want to handle on demand, then you have a more dynamic framework. And if you can acquire logs, acquire new nodes. You can do fundamentally auto-scaling, right? But the first thing I want to make sure, as I was about to say, irrespective. If you think about it, and you try to oversimplify it. If you want people, if you want to reduce the costs, if you want to even improve your availability, I think the name of the game, you want to maximize the utilization of your most expensive, most scarce resources. In this case of the GPUs, period. Right? And if you do that, in order to, sorry, again, you do that, you reduce the cost, right? Because you can do more with less. Also increase availability, right? Because maybe what before I had to do is 10 GPUs, now I use only four GPUs. So six GPUs I can use for something else. But what this means, you need frameworks and you need systems. which can handle heterogeneous hardware. Right? Like for instance, if I have things like batch inference, right? You you do some data pre-processing, some data post-processing. So, and when you do that, those things you can do on CPUs. So basically in that particular case I should have a framework in which I can auto-scale whatever the number of CPUs so that I feed enough data to the GPUs to saturate them. Right? and also to get quickly data out of the GPUs, right, to not waste the resources, the time on GPUs, compute on the GPUs, right? So I think that's one of very important aspects to handle heterogeneous compute. And this is going even more like even for inference, right? It's like you can have for multimodal, you can have, or even pre-filled disaggregation, you can have different characteristics for kind of GPUs for pre-fill and than, you know, token generation, output generation. You can have even different GPUs, like for instance if you have video, right? Because you can do decoding and coding can happen on cheaper GPUs, while if you have in the middle some transformer doing inference. then you want to deploy it on a much more powerful GPU. So I think that's kind of the name of the game. At the high level, the name of the game, you want to maximize the utilization of your most powerful resources and typically means, especially for more complex workloads, that you need to support... heterogeneous compute because this will help you to use cheaper compute, cheaper instances to saturate your most expensive instances. Ravid Shwartz-Ziv: Do you think so like there is now a huge debate about compute, right? It's like no one had enough compute, everyone are running to find to find GPUs. do you think this is something that will change in the future in terms like whether you'll see like more more efficient models or like Maybe somehow like find ways to to have the same models but like in to train them or like serve them the inference in more efficient way. Ion: Yeah, that's a very hard question. So, yeah. Well, it's... I think... Ravid Shwartz-Ziv: This is why we are here. Ion: You know. I don't think that this will continue at the same level of scarcity, but there can be ups and downs. I think if you remember actually at the end or the end of the last year, it wasn't such a high scarcity. Actually the price of the GPUs and so forth are going a little bit down. I think what happened, it was... In February, with the releasing of Opus and Codex, I don't know, like the coding agents and the agentic workloads, then this dramatically increased the load, right, increased the amount, and there are also very successful applications. And then everyone is racing. to build better models for coding, right? And I think that's kind of this transition, which was very fast. Then... immediately overnight increase the load in terms of the length of the contacts you have to train on and things like that and the model size increases as well which creates this scarcity over the past several months which was never like almost like before. But you do expect that eventually this, you know, not continue at the same level. But then maybe you are going to have a newer cloud which are going to be a, you know, another big bump in kind of the load and then create another kind of scarcity. So I think it's going to be a little bit up and down. I think in terms of... Ravid Shwartz-Ziv: Yeah. Ion: Models, yeah, I mean, as long as people believe that better models are going to power, you know, like obviously as a scaling law continue at some level. And then more data, bigger models, and so forth, more compute is going to lead to better models. You are still going to see that kind of race. It's natural. Of course, for different application domains, you are going to have better, even fine-tuned models or... Post-trained models are going to do very well and to be much cheaper as a force if you are an enterprise and you are going to use your data to fine-tune these models I Think that's also you are going to see quite a bit But I don't think that the top models are going to just suddenly stop increasing in size or stop right it's But people, they do optimize them, as you know. By the way, all this optimization, going back to what I mentioned earlier on about complexity just lead to much more complexity. Right? Because if you look at these models, you know, like what they try, first of all, was this kind of transition to mixture of experts, which are much more complex, obviously, because they're dense models. And now you have this so much work on attention. Right? It used to be all the layers have the same attention mechanism. Now you have different layers, different attentions. Within the same layer, now you have different attention mechanisms. Maybe you going to have this kind of attention, protocol basis. So this complexity is going through the roof again. But people try to do it. But it's one of these things, right? Because there is no question the models are becoming more efficient. The system are becoming more efficient. For the same model, for the same power, for the same accuracy, the cost of serving per token is going to drop dramatically like a rock. But at the same time, people... Ravid Shwartz-Ziv: Yeah. Ion: This is not enough to compensate for the desire of the people. They can't take these gains. And the way they take it, I'm going to try even bigger models, or even more data, because now I can also generate a lot of data using the harnessing and using all of these agentic loops. Yeah. Ravid Shwartz-Ziv: but do you see that like a future in let's say near future that it will end, you know, that the complexity will be too too big and will not support this like increasing intelligence? Ion: It's a concern, but people, think that what... people will do, will focus more and more kind of like specializing the stack for a single model or things like that. I think you'll see and what would happen, right? You know, even, but like for instance, if you think about transformers, everything right now it's optimized for transformers, right? Software, libraries, everything. recipe we know they are optimized for that. Hardware is optimized for that, right? So, but this hyper optimization, the biggest problem is that it's very hard right now. It's make it harder. It's not very impossible right now. Nothing is almost nothing is impossible unless you prove mathematically, but It's much harder to come up with new models, new ideas, new, right? Or you can come up, but to make them successful, right? Because you need to be 100 times better, right? Everything else is kind of you get this optimization for at all levels for the existing technologies. That's what I think is the concern, right? And you are going to do certain types of attention mechanism. The next generation of hardware is going to optimize for that. So now even in all the paper, you have a better attention mechanism because the hardware is not optimized for that. You may have problems for that one to be successful, right? So that's kind of the thing. this will happen, and it's already happening, you are going to really optimize for different accelerators, for different architectures for the entire stack. Allen Roush: Do you think that the model inference engines will well first of all, do you think that that enterprises in general will want to focus more on the very top of the line foundation models, which are often, you know, close source, open AI anthropic, or is there gonna be a push more towards open AI model or sorry, open open source models? And d where do you think the trajectory is on them ever catching up or even exceeding close perceived Ion: Yes, look, look, look, if you, we don't know because, know, but if you are an enterprise, if you are any company at the application level, what do you want is to own as much of the stack? You do not want to be just a wrapper, right? Or even you need to be very careful about how much of the value you can capture, right? Even Cursor, which was a very successful application, right, in the most successful market for AI application coding, it was very hard to stay independent, right? So, and they try to get out of it, but by training their own model. I think that probably, maybe they should have trained, started that two years ago or something like that. But I think that what I'm trying to get to is like every company is going to be hard incentivized to own as much of the stack. given the choice, absolutely they would like to have an open model. train with their data because now own that kind of stack instead of sending their data to open AI and so forth, right? So, because like let's take again as to this kind of like exercise, know, like thinking about. even cursor, right? It's like if you were to start two years ago to train your models, then you have the advantage of the data which you use. You are going to have most users, you are going to have the most data, so hopefully this will give you some advantage, right? If you delay that, you lose the advantage of the data, right? Because the other competitors will have as much data and they'll have more money, right? So... So now, of course, with that being said... More important than that is for a company enterprise to create an application which is successful, which they can sell, they can, you know, or features, right, which makes, more users using that features or application and so forth. They generate more revenue or maybe reduce the cost. But make no mistake that, and then this can force you, okay, I'm going to use the best models out there. But everyone will think about, okay, I'm starting a lot of companies, not everyone are thinking I'm starting on this, you know, open AI or anthropic models or, and then eventually I'm going to migrate maybe to some open models. which are fine-tuned on my data. And then I own more of the stack, and it's going to be cheaper. I'm not going to spend as much. So that's kind of incentive. It's always there. The question then are there going to be good enough open source models to continue to be to... to allow you to do that. I hope that will do. Ravid Shwartz-Ziv: And what what do you think? Do you think the gap between open source and closed source will will be bigger? Ion: I think right now it's probably six months or so, something like that. Ravid Shwartz-Ziv: And do you think in the future? Ion: I think in the future need to figure out. you know, better way to... create these open source models. Because right now, training the generation of models. frontier models, it's more and more expensive. Each generation, from what I understand, is going to be between 2 and 5x more expensive than the current one. So, which makes this also raise a barrier for the open source models, right, because they need bigger and bigger pockets. So, I think... We have to maybe come up with more creative ways to train such models. Ravid Shwartz-Ziv: But what do you think is the button? Like is it the data, the compute, like the expertise? Ion: All of the above, I think that it's basically what you need. We need at least three things. We need data, we need to compute, and we need people. Right? I think data, if you want to train on the public data, only public data, it's a bottleneck, clearly. But otherwise, you spend money and you buy data like everyone else. Then obviously the compute, which is more and more expensive. And then people, right? And you know, there are, then it's an incentive for the company, right? For instance, maybe this is what probably you want to look at. I guess for someone like Nvidia will have incentives to have very powerful open source models, And they have also the money. So that's kind of one natural promoter. And they do have right now, Nemotron and so forth, which is pretty good. But I think that's kind of unique to think is like that's kind of make it challenging, right? But I do think that again, it's like if you have, of course, if you have enough money as a company is incentivized, can do it, right? It's clear that, and you can see it's what one think what is clear is that it's very hard. There is. There is very hard to get significant differentiation between the models over more than a few months, right? Because, know, everyone's, know, I mean, Anthropic has a great model now and has been ahead, you know, ahead for a while, for at least from... since February, but you know, at the end of the last year Gemini was considered a very, very strong model. Of course, before that it's open. Now people also codex 5.5.5 is very good. So Gemini is going to plant right later this month, the new version of Gemini. You expect to be very good. So. The reason I'm saying that, I think that if you have money, the expertise is not like a secret about how you do it, right? People still move from the lab, you just need like meta, right? Meta has tried to do it. So at the end of the day, if you have enough money, you can be in the game. Ravid Shwartz-Ziv: And what about Mythos? What do you think? Do you think this is a a step function or this is something? Ion: So yeah, Steph function, you know, there are many models. like Kimi, obviously. Quen used to be, you know, it's like Minimax are also good, good models. GLM, very good models also for coding. So you have a bunch of very performant models. The question is that these companies who create these models are going to continue to do so. because some of them started to restrict the license, like MiniMax and things like that. So, we'll see. The point is that, my hope is that there are a lot of constituents in the ecosystem, the economy in general, which are incentivized to have good models. Hardware... providers, right? It's like NVIDIA and others, right? They need open source models because they want to understand the architecture of these models. It's like requirements for the next generation of chips, right? Of hardware, right? Enterprises, sure, for sure, want open source models, right? For as you mentioned. Any kind of AI application vendors who like to do that. They don't want necessarily to depend. only on this open AI and anthropic and so forth. Different governments in different countries, right, they want that. So I hope that somehow it's going possible to assemble this kind of more coalitions to build very good open source models. Continue to do that. Ravid Shwartz-Ziv: And what about regulation? Do you think we should have we should regulate regulation. we should like regulate models and I dunno the use cases Ion: What? Yeah, regular. you should regulate the use cases. I wrote something recently and I think that... You can do a little bit of everything, but the one thing to think, you have to, I am a strong believer, you need to regulate by outcome, not by capabilities, right? We cannot, like humans, right? We don't regulate you because you are smart, how smart you are, right? We regulate you, you know, it's like the laws and so forth, but you've done, right? It's not what you could do, what you've done, right? It's end. You have to apply something similar to these models because it's very hard to know because of generality what they can do. How do you know, right? It's not like as the calculus are continuously growing. So it's not like my computer. My computer is pretty clear what it can do or it cannot do, right? With the model, it is much harder. So I think outcomes makes a lot of sense to me, right? Right? Because, you know, it's like if I cannot even anticipate what the model can do. then how I can regulate, right, by capabilities, right? Or, you know, it was this thing, you know, or this kind of executive orders in the past or even the Californias 1047, right? It's like, you know, trying at some points to regulate by capabilities, right, about how many flops to train and so forth. But the main point is that it's again, it's like, if you think about... It's like... doesn't make a lot of sense because the use case and how you are going to apply that is going to be so far more important than capabilities. If the chips in a bomb or missile have much lower power than what you have in your iPhone. So that's my position. Ravid Shwartz-Ziv: And do you think like it should be like I don't know self-regulation, something like what Entropic has done with a metal that like they release to some like to a small number of companies? Ion: No, I think that it's concentration of power and it's very bad from my perspective. think that you should, I think that's one of the things about the open models. Actually, ideally, it's 360 open models. You can inspect and you can audit them, right? And they are open. Everyone can do that, right? You can have, you know... Ravid Shwartz-Ziv: Yeah. I agree. Ion: You know. people and researchers and so forth focusing on that, right? And then, you know, once you audit... Ravid Shwartz-Ziv: Okay. So Iun. So Ion, thank you so much for for this great conversation and thank you so much for joining us. It was really a pleasure. Allen Roush: Yeah. Yeah, tot total pleasure. Ravid Shwartz-Ziv: Thank you so much.