Utilizing Tech - Season 7: AI Data Infrastructure Presented by Solidigm - 2x17: How AI Drives the Need for Next-Generation Infrastructure Architectures with Liqid

Episode Date: April 27, 2021

We are on the cusp of a totally new architecture for enterprise IT, and this change toward composability is being driven by applications like AI. Instead of designing around fixed-configuration servers, disaggregation allows the use of pools of resources, and composability allows dynamic allocation of these resources as needed for different applications. When it comes to AI workloads, organizations can deploy a set of expensive GPUs and then allocate these as needed to various tasks, and redeploy these when that task (ML training, for example) is done. That’s what Liqid is delivering for their customers, and why we invited CEO and Co-Founder Sumit Puri and Chief AI Architect Josiah Clark to join Stephen Foskett and Chris Grundemann for this episode of Utilizing AI. Three Questions Are there any jobs that will be completely eliminated by AI in the next five years? Can you think of any fields that have not yet been touched by AI? How small can ML get? Will we have ML-powered household appliances? Toys? Disposable devices? Guests and Hosts Sumit Puri, CEO and Co-Founder at Liqid. Connect with Sumit on LinkedIn or on Twitter at @WeAreLiqid. Josiah Clark, Chief AI Architect at Liqid. Connect with Josiah on LinkedIn. Chris Grundemann, Gigaom Analyst and Managing Director at Grundemann Technology Solutions. Connect with Chris on ChrisGrundemann.com on Twitter at @ChrisGrundemann. Stephen Foskett, Publisher of Gestalt IT and Organizer of Tech Field Day. Find Stephen’s writing at GestaltIT.com and on Twitter at @SFoskett. Date: 4/27/2021 Tags: @SFoskett, @ChrisGrundemann, @WeAreLiqid

Welcome to Utilizing AI, the podcast about enterprise applications for machine learning, deep learning, and other artificial intelligence topics. Each episode brings experts in enterprise infrastructure together to discuss AI in today's data center. Today, we're discussing how AI is driving the need for a next generation IT infrastructure stack. First, let's meet our guests. Sumit Puri is co-founder and CEO of Liquid. Good afternoon, everyone. Nice to meet you. CEO and co-founder, Sumit Puri of Liquid.

Excited to share with you guys what we are doing for AI infrastructure here at Liquid. We've also got Josiah Clark, AI architect for Liquid. Hey, how you doing guys? Josiah Clark, I'm the chief AI architect at Liquid. Basically, I design the AI solutions around the Liquid technology. And of course, we've got Chris Grundemann. Yeah, hi, I'm your co-host today, Chris Grundemann. I'm a consultant, content creator, coach, and mentor. You can find more on chrisgunderman.com. And of course, I'm Stephen Foskett, organizer of Tech Field Day and publisher of Gestalt IT. You can find me on Twitter and most social media networks as S. Foskett. Those of us who have been in the enterprise IT space are quite aware of the fact that enterprise infrastructure is changing. In fact, we're on the cusp of a very, very dramatic change as more and more infrastructure that's like light lash to it, and that's that, into a more flexible, composable, disaggregated infrastructure architecture. And frankly, that's

what Liquid has been working on, and that's what Liquid has been delivering. And it's exciting to look at this stuff because it really is, to me, sort of a look down the road at where enterprise infrastructure is going next. Of course, AI also demands changes to the infrastructure model, and that's something we've talked about here on utilizing AI quite a lot. Sumit, I wonder if you can sort of kick us off by just giving us a little bit of background. What exactly is disaggregated architecture, and what is liquid? That's a great question, Stephen. Thank you for the opportunity to share here. So we look at disaggregation and composable as the next generation data center infrastructure architecture. Think about legacy infrastructure as us configuring our servers by taking devices and plugging them directly into the motherboard. With disaggregation,

what we're doing is we are taking pools of resources, pools of storage, pools of compute. These days, a lot of pools of GPUs or AI accelerators, and rather than plugging those directly into the server, we connect them into a fabric layer, and then we come in with sophisticated software, and then we compose our server for the stage of AI that we're at. For the inference process, let's grab this compute, those inference resources, these

storage devices create us a server. But if we're going to do training, that actually requires a completely different hardware profile. So the old way of solving the AI problem where we have static servers for different stages of the AI workflow, what that gives way to is dynamic pools of infrastructure. So depending on what stage of the AI workflow that we are at, we can go grab the devices and hardware that's required to go service that workload environment. And so what Liquid is delivering here is that next generation dynamic platform that enables us to dynamically spin up the server

with the appropriate amount of resources for the AI workload that we're looking to deploy. And this is really a dramatic change from the conventional infrastructure, because I think most of us are used to thinking, well, I'm going to buy a server. And if it's a big workload, I'm going to buy a big one. And if it's a small workload, I'm going to buy a small one. But you're talking about something that's sort of like a virtual server, but it's not virtual. It's physical. You're building a server sort of on the fly in a flexible way to serve whatever workload needs to be served at that moment. Yeah. The way that we like to think about it is we are developing the physical layer hypervisor. We slice and dice

physical infrastructure at the physical layer the same way that a hypervisor slices and dices at the virtualized layer. So we are reconstructing servers at the physical layer with the appropriate amount of resources to best match the job that we are looking to do. So yeah, it is a new way of thinking about deploying resources inside the data center in a very fluid, dynamic manner, as opposed to delivering static boxes and hoping that your workload fits the static box that you deploy.

And this is especially relevant to AI because AI, as you mentioned, tends to use things like a lot of memory, fast networking, fast storage, and of course, GPUs. And GPUs, in most cases, are literally a physical card that's been plugged into a server. That is not flexible. That's not flexible at all. And it doesn't even give you any kind of growth potential. But with what you're talking about, you can really deploy maybe more resources or less, depending on the need of the workload. Yeah, if you think about about, you can really deploy maybe more resources or less depending on the

need of the workload. Yeah, if you think about it, you know, AI is not, you know, run on traditional processors from companies like Intel. AI is actually best run on accelerators and GPUs from companies like NVIDIA. And these devices are expensive. You know, it's not a single $5,000 processor. We're talking about multiple GPUs that can be $10,000 a piece. And sometimes you need four of them, eight of them, 16 of them to go solve the AI problem that you're looking to address. And legacy static infrastructure is a very inefficient way to go off and scale the problem, to go off and share these GPU devices, to go off and build very high performance systems. The best, most cost efficient way to go address that problem is to take these accelerators and dynamically configure them for whatever the workload is. If you need two for your job,

go off and compose two into the server. If your training job now needs 16, let's go give that server 16 of these devices. Giving 16 to every server in the data center is not a cost-efficient way of solving the problem. Interesting. I'm really trying to wrap my head around this because obviously, as you said, it is a new way of thinking about servers. And so I wonder, Josiah, maybe you can walk me through kind of the practical implications of this because as I'm thinking about it, right, my first gut instinct is simply that whether I'm allocating these things physically or virtually, I still need to have enough resources in my data center or in my co-location space or wherever I'm operating this. And so, you know, in a real world application of AI over the course of time, I'm guessing is where this really comes into play, because if it was a static workload, we wouldn't even be talking about this. So it's things are dynamically changing, I'm sure. But what are the advantages of being able to move GPUs between one server and another versus just having one big honking training server and then another server for

inference, et cetera? Right. Yeah, that's a great question. So fundamentally, AI is kind of a broad term that covers a variety of different types of algorithms. They're all pretty much based on deep learning today. And each one of, you might have a couple of gigabytes of data and you might benefit from 16 GPUs during that training process, let's say. So there's training and inferencing, like you mentioned. Both of those also have different computational shapes. So training is highly computationally and data intensive, whereas inferencing is usually somewhat latency sensitive, depending on the application. So if you're an organization looking to implement an AI, you're gonna have these different computational shapes that could benefit from a certain number of GPUs or a certain amount of storage

or a certain amount of network traffic. Preferably, you're gonna have kind of a dedicated infrastructure for training. And maybe that's, you have a cluster with approximately eight GPUs per server. Well that's your general setup but you might have you could also have algorithms within that stack that might benefit only from what using one GPU per server or the optimal way the most effective way to run them with you. You know, maybe there's another algorithm that has an optimal configuration of 16 GPUs. So in the static infrastructure world,

you're kind of forced to pick eight or, you know, I think eight's usually kind of the normal number that we see out there in the wild. And the reality is your algorithm might more efficiently, you know, run on the two GPUs or eight GPUs or 16 GPUs. And you really don't have that choice of the static server. You could, in theory, reduce the number of GPUs and not use other ones and save things like power and stuff like that.

But that's inefficient because you have these other GPUs that maybe somebody else could use that are just kind of running, being run idle or they're just idle. So with the composable solution, you can assign the number of GPUs to the job that, you know, assign the right number of GPUs to match the computation that you need to run.

And then also there's always like the scaling up thing. So a lot of nodes you can only, you know, install a GPUs in, you might actually get a performance benefit by using 16 for some. That's kind of what we found in our testing, or 20, depending on your time constraints and stuff like that. So being able to dynamically dial in the number of coprocessors, your storage, or network interconnects based on the model,

the type of model that you're trying to train, just allows you to more efficiently utilize all the resources. You know, it's actually interesting because fundamentally it's more of a resource utilization play. So like with processors, you know, we went to virtualization because we knew that one application on a server

may not be using all of the DRAM and CPU cycles, right? So we started stacking OSs on top of hypervisors so we could fully utilize the CPU and memory. And back in those days, we didn't really care too much about the PCIe devices. They're like network devices and stuff like that. We're using hard drives. They were very slow. You really couldn't pack very many of them in there. But now we've got today, due to the limitations of the lithography of the CPUs,

those have kind of bottomed out performance-wise, and everything's kind of moving down into GPUs, coprocessors, and high-performance networks, you know, 100 gig, 200 gig, 400 gigs right around the corner. So you have all these high I.O., you know, high compute capabilities on the device side now and high I.O. devices on the storage and network side. And at the moment, if you're not using it, you're just kind of wasting it. So we enable you to more efficiently utilize those devices for whatever your workload is, whether it's AI or something else, you know, cloud workload or something like that, so that the device resources are utilized more efficiently.

So that's kind of the value. Yeah, that makes a lot of sense. And I think that's one of the pieces that maybe I was missing too when I was thinking about this is from a virtualization standpoint, there are those resources, right? Typically PCIe connected devices that you can't virtualize, right? You really need to dedicate those to a workload in a fairly physical way and not share them, right? I mean, even I know I've had some issues on a gaming PC that I use here, right? And I can't run a Windows VM to use the full GPU.

I have to actually switch over and do a boot, you know? Right. Yep. Same thing in my house, man. Yeah. So is there, you know, I mean, I guess my other question though, is how often are folks actually changing the workloads on these, on these different data envelopes, these different data profiles? I mean, is that really something that's really dynamic inside most organizations? Events on the size. So, I mean, if, so, so a large organization usually is using some sort of a containerized

or, you know, a scheduler or something like Slurm to manage the jobs that are being run on the cluster. So, and then with, so Slurm allows you and Kubernetes allow you to like chop up jobs and distribute them across different machines. So that fundamentally is another efficiency thing. You're trying to use your resources as efficiently as possible. But they change relatively frequently, especially on like an enterprise grade training system. And that's what you would want.

You want the training system to be utilized as much as possible. And depending, it's you'll want to try a bunch of different models initially, kind of go through this experimentation phase where you're trying models of different sizes and shapes and, you know, different techniques. And you're kind of looking for one that like starts to fit well with your, the data that you have and the problem that you're trying to solve. And once you're going to find a good one, then you like scale that out across the cluster and you try to train it as fast as possible. So there's, there's a really like dynamic piece of the, the training process. And the key is really, you want to be using that infrastructure as efficiently as possible so that

you're, you know, getting your money out of it. And it's also, you know, you know, being utilized to train your models. So that's kind of, it's very dynamic. Well, it should be dynamic, I would say. Sometimes it's not always super dynamic. But yeah, it's a relatively dynamic workflow. Yeah, and I'll add a little color if I could there, right? So I think it's easy to understand the benefits of dynamically moving GPUs around and the cost efficiencies associated with that.

But we're winning business a lot of times, not necessarily because of the dynamic capability that composability brings, but a lot of the other benefits that are associated with disaggregation. Number one is scale out. There is no better way to scale out your data center environment than to disaggregate. Add trays of just storage, add trays of just compute, add trays of just GPUs, don't pay for all of that other stuff, right? We build what we call the impossible configuration, right? Give me a server with 16 Mellanox devices, 16 GPU devices, and 16 SSD devices all in a single server, right? Because that's what my workload requires. Well, nobody actually bends sheet metal like that. But in a disaggregated

world, I can go create that server for the job, right? You know, brownfield is a big deal, right? A lot of our customers have invested in servers already, and now they want to go do AI. Now, rather than going out and buying new servers to do AI, let's just go buy trays of GPUs, which is what AI runs on, and then attach them to the existing infrastructure that we already own so I can enable my brownfield infrastructure to now go do this new AI thing, right? So I think there's a lot of benefits of dynamically moving hardware around, and the theory of hot plugging a GPU into a running server blows people's minds sometimes, right? They're like, what do you mean you're going to hot plug a GPU into a running server? Watch, right? Watch the app, watch Windows, you know, scan in GPUs into a running environment, right? So that's the

easy one to understand the dynamic capability, but there's all these secondary benefits around going disaggregated and in the AI workflow, right? So Sumit, one of the things that a lot of companies are talking about is sort of moving to disaggregated servers. And of course, disaggregated and composable are not the same thing. Now, I think that maybe one is a predecessor to the other, but essentially we're hearing a lot about, for example, CXL and PCIe 5 and how that's going to lead to a totally new server architecture.

How do you respond when people get confused about sort of general next generation architecture versus the stuff that you guys are actually delivering? Yeah, that's a great question, Stephen. So the first thing is, at the end of the day, Liquid at its heart is a software company. And one of our hallmarks that we do is we are multifabric. Whether you want to compose on PCIe, whether you want to compose on Ethernet, whether you want to compose on InfiniBand, soon we'll have CXL, potentially Gen Z. Believe it or not, we're talking to a company that wants to compose over 5G, a wireless network. So to us, that's physical layer stuff, right? So all physical layer should be able to be controlled by the liquid software.

And many times we do multifabric, right? Hey, go grab my GPUs over PCIe, but go grab my storage over Ethernet. And at some point, we're going to grab our memory over CXL. So one of the things that we are is we're multifabric. And in order to be a true composable platform, you have to support all fabric types, right? So that's number one. Second thing is you have to support all device types, whether it's NVMe storage, GPUs, FPGAs, Optane memory, NICs, a DPU, it doesn't matter. We have to compose all the device types, right? And so those are two things that we focus on is let's support all the fabrics.

Let's support all the device types because it's different tools for different jobs, right? And so it just so happens in AI land, PCIe is a very good fabric to compose against, but we still do a lot of multi-fabric. So that's the way that we'll think about it is I hope new interfaces are invented that bring us lower latency so we can disaggregate memory because the best form of composability is done on disaggregated pools of hardware. So they are not the same, but they work very well together. Well, you mentioned NVIDIA a couple of times, and I know that you guys were part of the recent GTC conference that a lot of our viewers were

attending and paying attention to as well. And NVIDIA makes a big deal about NVLink, and they talked about these grace servers and all that. I mean, how do you guys fit into that world? Yeah. So I think the first thing that we'll say is we are number one heterogeneous compute. So whether you're using an Intel processor, AMD processor, a power nine processor, or an arm processor, we support all processor types. So as, as arm finds its way into the data center, great. We will compose devices to ARM. We think there's tremendous value in composing even to the ARM-based processors, right? So that's one way that we think about it. And NVLink is great.

We are actually composing to NVLink, right? We take DGX systems and we're able to compose additional storage capability, compose additional networking capability to those devices. Now, NVLink is a great platform, but it's not for everyone. Sometimes the right answer is an NVLink-based system. Sometimes the right answer is a PCIe-based GPU, liquid supports both, right? We try to avoid the arguments around religion that say, no, this piece of hardware is better than that piece of hardware. No, no, we are hardware agnostic. And regardless which piece of hardware you want to use, we're going to find a way to add value by composing to it. So I always try to sneak in at least one stupid question as my brain wanders around these topics but you know one of the things we've talked about a lot on this podcast is the idea of ai at the edge and i think the reason that comes up a lot is because it's it's a less solved problem right i

mean for for an oversimplified view in a data center i can throw gpus at something and i can do some ai workloads i can make it work. Whereas at the edge, I'm usually power constrained, space constrained, maybe temperature constrained. And so I just wonder, is composability an answer at the edge as well? Or is this more in a place where I have a lot of resources, I'm in a data center and I can just scale out as you talked about earlier? No, it's a great question. And in our opinion, the next kind of growth segment is really going to be around the edge. The next big data centers are not going to be, the next data centers are not going to be big boxes in Arizona and we send data back to core. That's a long distance phone call. The next data centers are going to be built close to the point of data ingest, you know, under an antenna or servicing a handful of antennas.

And the edge is inherently limited by power, by floor space, by cooling, by human access. And that's the exact problem that composability solves. We take a rack of infrastructure that's 20% utilized because it's statically configured. We reconfigure it dynamically. We squeeze 40, 50, 60% utilization out of that same hardware. And if that is true, we are going to shrink the footprint at the edge because we can do with one rack of infrastructure what in theory used to take two racks of infrastructure to do. So we're definitely winning at the edge. And oh, by the way, sending a human to the edge is no fun. And so by being able to software define the edge, it's kind of a big deal. And AI at the edge is happening.

There's a lot of examples of workloads at the edge that are relevant to these AI kind of use cases. I'll give you two of them. One of them is autonomous checkout at the edge. You know, I'm going to go into the store. The cameras at the store are going to be watching me. I'm going to grab whatever I want. I'm going to walk out the store and I'm going to be given a bill on my cell phone for everything that, you know, I purchased. And all of that is going to be driven by cameras and AI inference. And all of that is going to be driven by cameras and AI inference, and all of that is going to be done at the edge, right? And then you can think about things like the autonomous forklift, right? Moving around the warehouse, picking up and moving stuff around.

If that fetch has to go back to the core data center, that might be too long and we might run over a human, right? So that doesn't work any longer. So therefore, again, the speed of light is real. And so we have to push infrastructure closer to the data, right? Yeah. There's also kind of two other interesting things about the edge with AI right now, kind of how we can help. So one is the, in addition to the products that I mentioned. One is the bolt-on solution. Hey, you have your Walmart. You've purchased 50,000 servers to monitor your shelves. And you now realize that the new algorithm you have can't run fast enough on the GPU you have installed there. Maybe you need additional GPUs. What do you do?

Do you replace 50,000 servers? How do you get another two GPUs in there or however many you need, or maybe you need some extra storage or something like that. So that's the bolt on approach. Well, Hey, leverage our technology. Now that server, those 50,000 servers just turned into, you know, went from two GPU servers or one GPU servers to however many GPUs you need. So there's, there's the augmentation case. And then the other use case is something that's called federated learning. I'm not sure. Have you guys heard about that at all?

So it's basically federated learning as it's the concept of so traditionally when we train models, we move all the data back to a central location, and we train them like on a supercomputer type setup. But let's say it's sensitive medical data, or it's sensitive data that can't leave the facility that you'd like to train the model on, but it can't actually go back to your data center. So with the concept of federated learning, you basically need to kind of build these like little micro pods at the edge that train on their individual data set. And they share like numerical values that don't have any attributable information about the people or it's not for it. It's not HIPAA, you know, that has requirements and all that type of stuff. So yet again, you kind of run into that same problem where you're like, okay, I need to

augment the system that I have in place that is currently using this, but I want to actually train on this system at the edge. So again, it's kind of an augmentation use case, but that of the other one of the newer things that's kind of coming along uh that people are starting to look at how do we actually do this across diverse areas where we can't share everything back to a central location and actually start doing training on the edge as well whereas historically it's mostly been in fernstein so there's a topic i've seen um i think you guys talk about maybe some others um but I think it'd be worth kind of diving into and understanding exactly what the data flywheel is as it relates to AI and then how that moves towards composable infrastructure. I'll let Josiah add color here, but let me address that in, I guess, two parts, right? So number one, we say that data has gravity.

It's very difficult to move data around. It's much easier to move the compute resources to the data. So I think that's one way that we think about it. The other way that we think about it is AI is not an event. AI is a workflow. There are different phases of the AI process that we do. And the first step usually starts with data ingest. Well, guess what? That's a networking intensive thing. And then we go to the data, the tagging, the cleaning, the scrubbing of that data.

And that's actually a compute thing. And then we move on to data training, which is, you know, the big GPUs, four, eight, 16 of them. And then we move on to data inference, which is like a single, you know, different type of hardware. And then normally there is this massive set of data at the center of the universe, right? And many times we are shuffling data around four different physical systems to get our job done. And so we like to think about the concept of data gravity and don't move the data between the different servers bring the networking to the data when you need to ingest it bring the compute resources to the data when you got to do your data scrubbing and tagging and cleaning bring the the the big gpus to the data when you got to go do your training and make the data the center of the

universe rather than you know making the compute the center of the universe rather than, you know, making the compute the center of the universe. So that's kind of one way that we think about the AI workflow. The data is the most important part of it. Let's keep the data kind of the center of everything and move all the devices around the data. I'll let Josiah maybe add, sorry, if there's a question there, great. Go ahead. Well, I was just going to say, you know, I think the illustration there is interesting, right? I think, you know, thinking of data as the center of the universe, I think of the galaxy spinning around and all the stars in the center and things. But I do, it's a, there's a, basically your algorithm has to involve statistical learning of some type learns off of data. build an application that does something. So like Google did search and as better it becomes, more people use it. And if you're smart, you'll collect more data as people are using it, which will give you more data to train your algorithm on. And then that algorithm will be better. So more people will use it. So you'll get more data and you'll kind of revolve around

the data pilot. Right. So fundamentally the,ally, there's two important things. One, you want to be collecting more data. Two, you want to be improving your model. These are all speed-based things. Like Sumit mentioned, you could collect the data, move it into an ETL system, you know, wait for it to get processed, move the data over into your parallel file system, you know, start messing around on it, testing it, move it over to like the actual giant cluster that you're going to train on once you've like figured out your models. So there's all these data movements that have to occur.

Whereas with composability, you know, you're like, all right, move it to a storage device ETL. Give it, you know, compose a bunch of memory to that system. So you load it all in memory, do all your ETLs, write it back to the same storage device. Now recompose that storage device to your GPU cluster that's going to do the training on it. You just move, you know, you're bypassing all these copies. You know, you might not even have to leave the same server. And all of that can just be automated. So kind of from the data flywheel perspective, what we do is we accelerate it from like a, we reduce the amount of data movements.

But, you know, kind of the real, really important thing about the data flywheel is, in theory, so like AI is one of those winner-take-all markets, fundamentally. It follows that market trend. So like if you do a task well, you get it out to your market and you leverage the data file concept, in theory, that means as long as your product isn't bad and it solves a real problem, you'll collect more data, you'll get more data to train your model, you'll have more money to train your model, and your system just keeps getting better and better. And what we do is we accelerate, take that kind of one step further by accelerating the speed at which you can revolve around that by reducing the amount of times you actually have to physically move the data from like one machine to the next well i really appreciate this conversation but

we actually are running up here against the end of our allotted time uh before we go though we do have a utilizing ai season two tradition of asking three fun questions, open-ended questions, to see a little bit of what you think is coming in the future of artificial intelligence. So since we have two guests here, I'm going to kind of throw this out there. Either one of you can answer. And maybe, you know, if you both want to jump in, that's fine, too. But let's kick off this lightning round portion with some with a couple of interesting, fun questions. So question number one, are there any jobs like people jobs that will be completely eliminated by AI in the next five years? So jobs that nobody will do anymore. I'll take the first pass at this and I'll let Josiah go next, right? And so it's kind of funny, right? The number one job in America is what, right? Is a driver, right? I drive a truck, I drive something, I get behind a car, right? So it's no doubt in our mind, autonomous vehicles are coming, how quickly they

replace everything is to be determined. The other interesting part, the number two job in America is I stand behind a box and I transact, right? I, you know, take your money for a good or a service, right? And we think both of those markets, the two biggest markets in America will be highly disrupted by artificial intelligence. I think fundamentally this has the ability to disrupt every market. I don't think there's going to be a scenario where it necessarily replaces humans across the board in every segment, but it will augment humans in a lot of different areas. And in certain cases, yes, it will replace the humans. but I'll let, I'll let Josiah take a, take a pass at his opinion here.

Yeah. Yeah. No, I agree with Samit. I mean, uh, uh, the, the drivers are definitely, you know, we're kind of seeing that now. Um, that's one of the more advanced, but still risky, you know, if a, if a car, like if a machine doesn't take your, uh, money at a checkout, you know, nobody dies. Um, so, um, I, I do believe that technology is kind of reaching a level of maturity where, you know, you know, five years is not unrealistic on the driving side. Um, and then, uh, I would say, you know, factory type jobs, um, and a lot of that, uh, actually quality control. It's kind of an interesting one.

Um, you know, so, so like with all this stuff, you have to look at like, you know, can a machine do it better than a human today? And is there, um, you know, a, does it kind of make the world better for everybody? Does, does the, the, you know, the jet engine not explode because the machine has 99.999% error rate, you know, you know, correct, correct. It's right. 99.99% of the time, whereas a human's only right. 98% of the time. Like, what, what would you, what would you want as like a, as somebody that flies, would you want the machine that's like, right. More to check to make sure the engine's not going to like blow up when you're playing, or do you want the human that we know as like roughly,

you know, an expert's about 98 point something percent accurate. So I think those are kind of what we'll see first, because those are things that we want, you know, medical, medical stuff, radiologists, pretty much anything that has to do with classifying, you know, a tumor and an image or something like that, you know, most people I think will want that. They'll want, you know, a machine that's more efficient at telling you if you have a disease or something like that, or maybe there's not enough doctors who have that specialty. And do you want to wait six months for a pathologist to look at a slide or do you want to have a machine answer it or do a full report on you and you know uh you know have a second so i think those those kind of uh will be the first and the easiest ones and then i think the um you know the thing the the tasks that

involve in the event the machine failed it would be you know very dangerous um or you know cause you know harm to human life or something those will take a little bit longer to shake out, even though the technology is getting pretty close to being able to outperform the machine. Okay. Let's talk about the flip side of that then. Can you think of any fields that have not yet been touched at all

by artificial intelligence? That's a tough one. I am at a loss right now. I'm running the gamut in my head right now. Fun. Yeah, we've talked about some crazy use cases on the show, even like creative writing and things like that have been touched by AI. So reading, writing, cutting code, cooking, babysitting, dog walking, you name it, right?

It's being impacted. All right. Well, then there we go. That's the answer. And then finally, an all new question that I just added. How small can machine learning get? Will we have machine learning household appliances, toasters? How about toys?

How about disposable devices? Will we have disposable ML? I don't see why not, right? So at the end of the day, this is an algorithm, right? And how small you can shrink an algorithm and have the sensors feed that algorithm, there really should be no limit on how small we can make this stuff, right?

So absolutely, appliances embedded with AI, I think that's already there, right? I think we're already seeing that. Toys embedded with AI, absolutely, right? We're already starting to see that. I don't think there is a limit on how small this can get because the size that we can make memory and CPU and sensors, which are the kind of the key requirements for doing anything artificial intelligence, that can operate already, you know, almost on a nanoscale, right?

So these things are going to be able to get really, really small. Now, how useful will something like that be? You know, it'll be interesting. Maybe, you know, many of them together will solve an interesting problem, but I don't think there's really a limit on how small we can make these things. Well, thank you very much for joining us today. Where can people connect with you and follow your thoughts on enterprise AI and other topics. Let's start with Josiah. Yeah, you can find me on LinkedIn, josiah.clark at liquid.com. Also on the Liquid blog, I'm throwing stuff out there. And then just, you know, same email on archive for anything I

publish, when it gets out there. Great. How about Smith? Hey guys, easy to reach. Submit, S-U-M-I-T at liquid.com. Shoot me an email. Happy to share my thoughts with anyone. You can also find me on LinkedIn. I'm pretty active. And please go to our website, www.liquid.com and reach out with questions if you have them.

We'd love to talk to you. And Chris, what have you been up to lately? Yeah, lots of things. Most of it's documented either on LinkedIn or on Twitter, at Chris Grundemann. Also, for all things Chris, chrisgrundemann.com. Thanks. And I've been busy with a little thing

called the Utilizing AI podcast. But of course, I'm also busy planning Tech Field Day events, including our forthcoming AI Field Day event. If you'd like to learn more about getting involved in that one, please just go over to techfielday.com and click on sponsors to learn how to present or delegates to learn how to become one of the folks

asking these questions at AI Field Day. Thank you very much for joining us for the Utilizing AI podcast. If you enjoyed this discussion, remember to subscribe, rate, and review the show in iTunes, since that does help our visibility. And please do share this show with your friends and on social media channels. This podcast is brought to you by gestaltit.com, your home for IT coverage from across the enterprise.

For show notes and more episodes, go to utilizing-ai.com or find us on Twitter at utilizing underscore AI. We'll see you next time.