00:34:43 · Finn Meeks
[00:34:43] S1: Coming back to what you said earlier is you you kinda do these deployments. You learn from what your customers are doing, you feed that kind of back into research. And it goes back to something we were talking about a few weeks ago that stuck with me which is that you just said product and research are becoming inherently more coupled. I'm curious what that looks like at Luma day to day, you know, as you kind of feed this back into your product learnings, kind of back into research. How you do that maybe just in practice day to day and then what that kind of enables? I think one thing that has really impressed me about Luma is that you you actually ship and you ship with a very high velocity. And I'm just curious, can you talk us a little bit more about just kind of those learning feedback loops and kind of how you see these being coupled?
00:35:23 · Amit Jain
[00:35:23] S0: In a foundation lab, there is no product or research. Research produces a product and product works in research, it's all in the same thing. And Foundation Labs are probably the blueprint of companies of the future because of the way our economics are structured. We literally target every product that we can make. It costs us barely 1% of our balance sheet to make a whole new product in a whole new domain because our economics are not dictated by the products we make, by the software we make, but by the compute and by the research we do. At the end of the day, product and research are really the same thing. Practically, does it mean we have a product team that is different from research team? Yes. But that's like having the same thing as like in a product organization, have a growth team and you have a product growth team or growth engineering team, sorry, and you have a design team and those kind of things. There's just part of the same ecosystem and the same team. How we think about the product is deeply tied to our models capabilities. We can wish for making a product, but if the models don't deliver on it, then it's too bad. A lot of people then try to build like harnesses and complex systems and things like that, and they will spend six months optimizing that system. We don't do that. If it doesn't do that today, too bad. Next iteration of the model will do it. It is just data for us in what the next iteration of the model should be able to do. A lot of people we have seen who might have spent six months, eight months trying to optimize this one problem to solve one vertical thing. For us, that is basically a two week, three week long data collection job, where we're like, oh, all right, it doesn't do that today. Let's gather the data and we'll put this in the next, like,. X training run or we'll put it in the next pre training run if it really requires that level of training or requires that level of compute, sorry. So tasks, the way we think about them. So first of all, we don't think about verticals. We think about professions, right? Which professions we can help or which kind of people we can help? Second, we don't think about in terms of like, Okay, what kind of spaghetti we can put together to make a product, but rather what is the base model capability and how can we make the thinnest possible product?
00:37:34 · Amit Jain
And of course, it never ends up being so thin. It ends up being a little bit fat. And then the next model's job is to reduce the fatness to make it really, really thin, and the product model just handles it. And then we build a little bit more thickness on top of it to solve a little bit more problems on the it's this iterative loop of products and model and product and model and product and model. This also really works really, really well for customers because see, what customers are looking for is end to end solutions to their problem, not promises of solutions to their problem. They don't want a narrow solution that like, okay, well, it does this. Fine, some people might buy it. But at the end of the day, they're looking for, how do I do this fund production? How do I do this marketing? How do I do this, this kind of thing? So when they're doing that, they want generalist systems because let's think about marketing. You guys might not think about marketing a lot. I didn't used to either, I'm a physicist by education. But like everything that humans are deeply involved in end up becoming an AGI problem. Because think about it, what does it take to do marketing? And why is it so damn hard? If you're founders and if you're here and you don't have the gene of marketing, I don't. Then like, it's a really, really, really hard problem, right? You need to understand the environment you're in. You need to understand what will resonate. You need to under... It's not the final asset you produce. No, it's a problem of communicating with the world, right? It's a problem of like what would the world respond to? It's a really hard problem. And when you're trying to solve that problem, right, the models cannot just be, hey, I'm a good image model. So you need these generalist systems. So if any build products that are like just like thin stacks on top of like some of the somebody else's models, they really fall apart very quickly as you're seeing now, oh, well, the attrition of the the velocity of model improvements is increasing because again, the infrastructure is getting better and better and better. Every new model, we build better infrastructure and so on and so forth. So product and research in Foundation Labs are not two different things.
00:39:40 · Amit Jain, Finn Meeks
They are jointly optimized and the secret to building a great company in this space is to just treat them as one and and, you know, unified system. [00:39:48] S1: Amazing. Well, Amit, congratulations on all the success of Luma. It's been an amazing journey so far and and you're working on some really exciting new stuff, which I'm sure we'll all see here in the coming months and years. Thank you for coming back to SPC and appreciate you doing this. Let's give you a round of applause. [00:40:05] S0: Awesome. Thank you for everything.