Jerod: Welcome to Practical AI, the podcast that makes artificial intelligence practical, productive, and accessible to all. If you like this show, you will love the changelog. It's news on Mondays, deep technical interviews on Wednesdays, and on Fridays, an awesome talk show for your weekend enjoyment. Find us by searching for the changelog wherever you get your podcasts. Thanks to our partners at fly.io.
Launch your AI apps in five minutes or less. Learn how fly.io.
Daniel: Welcome to another episode of the Practical AI Podcast. This is Daniel Witenack. I am CEO at Prediction Guard, and I'm joined as always by my cohost, Chris Benson, who is a principal AI research engineer at Lockheed Martin. How are you doing, Chris?
Chris: Doing great today, Daniel. It's a beautiful spring day here in Atlanta, Georgia, and I gotta say the the flowers are coming out. It's a Yes. Nice day to talk.
Daniel: They're probably distributed all over the various lawns across Everywhere. Federated even. Yes. Yes. Well, Chris, this reminds me, week we had a kind of part one intro to federated learning and some details about that with Patrick from Intel.
He mentioned recently that he was at the Flower Labs conference and the Flower Framework around federated learning, he mentioned quite a few times. Well, we're privileged to carry on the conversation around federated learning into a part two on the subject because we've got Chong Shen with us who is a research engineer at Flowr Labs. Welcome, Chong. How are doing?
Chong Shen: Hi. I'm doing very well. Thanks for having me.
Daniel: Yeah. Actually, we were talking before the show. This is the second time that we've got to chat about flower on the podcast back in 2021, so even before AI was invented with Chad GPT, apparently we were having conversations about AI and one of those was with Daniel from Flowr. That's episode 160 titled Friendly Federated Learning. It took me a second to say that one.
But I'm sure a lot has changed and updated and advanced in that time, of course. Maybe just to start things out, Chong, could you give us a little bit of a context of your background and how you got introduced to this idea of federated learning and eventually ended up working with Flowr?
Chong Shen: Yeah, absolutely. Thanks again for having me. My background is in computational physics, so I spent many years working, doing research in the computer physics field, both my PhD and a postdoc. So I worked a lot on parallel computing, on supercomputer classes. I was also very interested in machine learning and deep learning in general.
So when I pivoted away from academia to go into what I call industry, there was this space where you have distributed learning. So that was in 2021. So when I started my career back then, it started as a data science consulting business, but specializing in federated learning. And I saw lots of projects that were very interested to adopt federated learning or this distributed learning approach to solve some specific problems that they have. But I also came across the Flower framework.
And open source development is a big passion of mine. So being able to develop a framework that is used effectively with a very permissible license, I think it's a pretty cool thing to do. So that's why I decided to join Flowr Labs and become a core contributor to the framework itself.
Daniel: Yeah. Yeah. And feel already connected with you because my background is in physics as well. It's always good to have other physicists on the show that have somehow migrated into the AI world. I'm wondering in that transition, you mentioned this transition kind of academic to industry.
You were getting into even consulting around federated learning. Was that idea of federation or distributed computing or however you thought about that, was that a key piece of what you were doing in academia, which led you into that interest? Was it something else that sparked the desire to really dig in there as you were kind of going into quote industry as you mentioned?
Chong Shen: Yeah, wasn't something I came across in academia surprisingly. But somehow when I stepped into the data science world, I came across people who are looking into it, and that became an approach that back then we adopted to try and solve some problems. So we saw that Federated Learning could be a way to solve it, and then it's very coincidental. Okay, it's distributed learning, it's a distributed computing. So it resonated with me quite strongly.
Daniel: Yeah. And was that related to working with sensitive data or in regulated industries or something like in those consulting projects or just interested in that progression?
Chong Shen: Yeah, actually there are, I would say, two broad categories. One where the data is incredibly sensitive and we usually refer to them as really siloed data, data that should not absolutely leave the boundaries of where it was generated. And then the second group or second cluster is the problems where the data sources are so massive. The point at which the data is generated generates so much data every second of the day that they just can't do any useful or meaningful analysis on this kind of raw data and you have to build off downsampling. So try to look into pushing competition to the edge and try to see if they could apply some sort of machine learning approach or deep learning approaches on this sort of massively generated data without needing to downsample them.
Daniel: That makes sense. And yeah, I guess I should explicitly mention as well that in the part one of this two parter with Patrick, Patrick did provide a detailed introduction to the idea of federated learning, and we discussed that at length. If people want to go back to the previous episode and listen through that, that may provide some context. But it probably would be worthwhile just to give your thirty second or couple minute view on federated learning and how you would describe it at a high level, and then maybe we can jump into some other things.
Chong Shen: Sure, absolutely. The easiest way to think about it is looking at your classical machine learning approach. Classically, you need to bring all the data into a single location. Think of a database or on disk, and then you train your model on that data. But sometimes, it's not so easy to actually bring all the data into one location just because of the privacy reasons about moving your data, some geopolitical considerations surrounding it, and also the data volume that's been generated.
So instead of bringing out a data to one spot and training a machine learning model on that, what you do is you move the machine learning models to the point at which the data is generated, and then you train these local machine learning models at these sources. Then instead of moving the data across, you move the model weights to a central server, which is much, much smaller. You can then aggregate the model weights to learn from these various data sources. Then over time, as you repeat many, many rounds of this, you end up with a globally aggregated model that has learned from this variety of data sources without needing to move data sources across. That's the essence of federated learning.
Chris: I'm curious as as you guys have worked on the framework and and, you know, you have new users coming into it, what what usually prompts typical user from your perspective to move into federated learning? Like, what like, you know, before they're really, like, fully into it, and they understand the benefits and and they're sold on it, if you will. What's usually in your experience, the impetus that kind of gets them into that mindset or and and kind of drives them in that direction initially? What causes the change in the way they're thinking so they go, I definitely need to get into federated learning and go use flower specifically?
Chong Shen: Yeah, absolutely. I think from my experience, the biggest driver is when they realize they can't move their data. Right? But when they speak to all the parties involved, they say that, Oh, I have this dataset. Oh, you have this dataset, but I don't really want to share them.
And then, Okay, this is where, you know, federated learning or FL comes to the picture and decided, Okay, we really need to do this. This is one aspect of it. And the other aspect is when there's this big company who has, let's just say, many data sources. They say, okay, it's super difficult to coordinate all our databases together so that we can have a cohesive way to train the machine in the model. This is also when try to look for all distributed machine learning systems, then they realize, oh, they come across various learning.
There's these two vectors that drive the typical use cases.
Chris: Curious if I can follow-up on that, because I have a a personal curiosity. I happen to work for one of these big companies that has data in lots of different places. And and in addition to that and we kind of in the preview in last week when we were talking, we talked a little bit about some of the privacy issues as well. I'm curious what you think about this. Like, in our case, and and we're not the only one, lots of that data is store at different levels of security and and privacy.
There are different enclaves, if you will Mhmm. Where you're trying to do that. And how does that ramp up the challenge of federated learning when you have different, you know, different security concerns around the different data enclaves that you're trying to bring together through federated learning? How do how does one go like, instead of saying all different locations for distributed data are equal, when you're dealing with different security concerns, do you have any any ways of starting to think about that? Because as as I come into it as a newbie on this, that seems like quite a challenge for me.
Do you have any advice or guidance on how to think about it?
Chong Shen: Yeah. Yeah. I think this is, from my experience is that the complexity of the solution skills with a number of data stakeholders involved. And when you mentioned about different levels of the enclaves, that to me signals that there are many data owners who manage their data a bit differently. So the the key to solving that is to harmonise the data standards first, to be able to get on to a federation.
And then from then onward, the implementation becomes much, much easier. Maybe it's one of the key things that I've seen.
Daniel: And we've kind of talked about your background, the introduction to federated learning, some of those motivations. Maybe before we get into flower specifically and some of the more production use, From your perspective as being a central place within the ecosystem of federated learning, I guess, Just very honestly, because we had that last episode in 2021. '20 '20 '1 till now, how is the state of adoption of federated learning in industry different maybe now than before? How has that grown or how has that matured as a kind of ecosystem, I guess?
Chong Shen: Yeah. It's a very good question. If I were to put a number to it, and this is really arbitrary, I think there's 100x difference from 2021 when the Flowr framework existed and now. And one of the key changes in the usage of heritage learning is the ability to train foundational models and large language models. And this has been a significant change and driving force.
Previously, when we talked about using the Flowr framework, you may be confined to models that are not super large, small by today's standards of the order of millions of model parameters. But these days, when we are talking about making use of text data, image data for these foundational models, you are thinking about models at the order of billions of parameters. And there is a fundamental change in also how we have structured the architecture of our framework, and also to increase the ability to stream large model weights. So all of these things are happening right now as we speak, and there's some exciting new progress. Hopefully, we release a new version in a couple of weeks.
For the users, the usage is identical. Nothing has changed. But what has been unlocked is the ability to then train very large models. So all of these really increases the appeal of using federated learning or the Flowr framework for a larger variety of use cases.
Sponsor: You know what's beautiful about good code? It just works. No fuss, no five hour debugging sessions at 2AM. That's exactly what NordLayer brings to business security. While you're busy shipping features and fixing bugs, NordLayer handles your network security in the background.
It's like having a senior DevOps engineer who never sleeps, never takes vacation, and never accidentally deletes the production database. Zero trust architecture? Check. VPN that doesn't make your team want to work from the coffee shop instead? Double check, deploy in under ten minutes with no hardware to rack and stack, triple check, built on the same foundation as NordVPN, but designed for teams who need granular access control and compliance reporting because apparently it works on my machine is not sufficient for the auditors.
The good news is our friends get up to 22% off plans plus an additional 10% with the code practically 10. That's practically dash 10. That's less than your monthly GitHub Copilot subscription, but infinitely more useful when the security team comes knocking. Check it out at nordlayer.com/practicalai. Again, nordlayer.com/practicalai.
Chris: Well, Chung, we as we've kind of dived into the show and we've we've already started making reference to flower quite a bit, but we haven't actually really described specifically what flower is in detail as a framework and what it brings and such as that. Could you could you take a moment and and we probably should have done this before, maybe kind of kind of express, you know, exactly what flower is, what the components are, and and how it kind of helps the user begin to federate their data in terms of their know, what their workflow is. Could you talk a little about the kind of the basics of it?
Chong Shen: Yeah, absolutely. So the Flowr framework is our flagship open source code that's built on the Apache two point zero license. And this framework allows users, any data practitioners, to build a federated learning solution. So with the framework, what this means is they are able to, I guess in code terms, install a basic Python distribution of Flowr, and to build the different apps that allows you to construct the fundamental fairytale architecture. So what this means is to be able to spin up your server, which aggregates the model parameters, and to write the code to also do your training on the clients.
The structure that we provide within the framework allows users to follow the same reproducible way to perform their accredited learning. So I think at the essence, this is what it is. What I also wanted to say that, and one of the appeals of Flowr for me personally, is that we really emphasise the user experience. And this is why we always say Flowr is the friendly federated learning framework. We prioritize the experience of all our users.
We support them on Slack. We also have a Discourse channel called Flower Discuss, where we actively answer any of the questions from users. And we also have a fantastic community that has contributed a lot of, code improvements to the call framework as well. So we are completely open. We're built transparently and really accountable for every single line of code that we commit to the highest standards.
Daniel: Yeah, and I can testify personally. At Prediction Guard, we work with a number of students over time at Purdue University. They have capstone projects. We're in the same town, so it's natural that we would work with some of those students. We've done that a couple times now.
One of those student groups that we had, I believe it was last year, actually did this sort of capstone project related to federated learning and training language models, translation models, trying various things. They evaluated a bunch of different things, but I think ended up using Flowr for the reasons that you mentioned. They were newbies into into this world of federated learning. Obviously, smart, students. No no doubt there.
But they but they definitely gravitated to the user experience with Flowr because they had programmed in Python and it just came naturally to them. So yeah, I'm sure that's a common experience that maybe you all hear from others, that sort of natural Pythonic way to kind of approach these topics.
Chong Shen: Yeah, yeah, we do, absolutely. I'm very happy that you shared that experience. It's good to always hear feedback from your community. But yes, Python being the really driving language behind machine learning models and deep learning models right now. So it's a really natural way to provide a Python SDK.
We support it from day one and we will continue to support it for a long time.
Chris: I'm curious the kind of extending that just a little bit. Beyond being in the language, I like the notion of the friendly language. The word friendly appeals to me in terms of that user experience. Could you talk a little bit more about kind of why you're branding around friendly and what that means from a user experience standpoint? You know, what other aspects of it make it friendly.
There there are so many things out there that are not friendly that, that definitely that definitely grabs my attention.
Chong Shen: Yeah. Absolutely. I can, I think what what would be nice to explain is, for the past 10 releases, we have dramatically improved the friendliness of our framework, hopefully? I hope that's the experience that people will get out of this. The main point is to reduce the cognitive load of any developers who want to use our framework.
So I'll give one concrete example. We introduced the Flowr CLIs a couple of releases ago, I think probably late last year. And what this does is with a simple FLWR space new command NEW, a user is able to navigate options through the command line and immediately have a templated project to work with for federated learning. And it runs out of the box. After Flower New, the user goes through this, just follows the steps, and then you do flwr run, and it runs out of box.
And we have the core templates that is necessary for users to build on. We have the PyTorch, TensorFlow, the typical ones, and the more exotic ones, have Jax. And those who want it, they can use NumPy as well. All these provide the boiler code for users to get started with, and it reduces so much startup time. Then with that, once a user has built all their applications, the user can also really monitor their runs.
We also introduced commands like fwlr ls. It's really like ls in your terminal to just see what runs, what Webflow runs are running at the moment. And also others like FWR log to see the logs of your code. So all of these really simple CLI tools really help a user navigate and work with running code much more easily. Previously, I would say 2021, '20 '20 '2, early '20 '20 '2, the Flower framework was in a different place.
How it worked back then was was still friendly, but the way that a user would need to start the federation would be to start three Python scripts. And this is not as intuitive or natural if you want to scale up or put into production. So with the introduction of the Flowr CLI and a different way of deploying the architecture which drives the federation, it really makes it so much easier for users to start building and then deploy the, deploy the code.
Daniel: Well, you you were kind of leading into maybe what was going to be my next question. You mentioned kind of taking things into production. So some people might hear kind of friendly framework, which is a good thing as Chris mentioned, but they might associate that with, you know, prototyping and learning and that sort of thing, not necessarily production usage. So I'd love if you could kind of help us understand what does a if I'm implementing a federated learning system with Flowr, what does a production federated learning system look like? I'm sure there's different sorts of ways that that could manifest, but certainly you've seen a lot of use cases.
Maybe you could just highlight some examples for us. What does that production federated learning system look like? And what are some of the considerations that you have to think about going from a toy prototype of this might work to a full scale production rollout?
Chong Shen: Yeah, absolutely. I think it is a nice segue between the fairness aspect and moving to production, because what I also want to mention here is that I walk through a very simplified workflow of how a user would build out an FL solution. With the Flowr framework, you could build and write the apps that you need for your your server aggregation, and also for the clients, which actually train the models at the data sources. In the first iteration, a user might actually run it in what we call the simulation runtime. So without worrying about the actual data sources or to work out the data engineering aspect of it, you could test the implementation of the basic architecture in the simulation runtime using data sets that are obtained from Hugging Face, for example, or from data sets that you could just create artificially just for testing purposes.
With the same code that you use to train the models and the clients and to aggregate, you can then point the code to a different runtime and then execute it in what we call the deployment runtime. And this brings us one step closer to production. So once you have this mode of execution, the clients would then be tapped in to the data sources, and you can then start training your actual federated model. So what does it take to deploy a production system? Firstly, there is a nice acronym that I like to use from the TinyML community.
It's Blurb. I'm not sure if you've come across that before. Have you come across that before? Just out of curiosity.
Daniel: But go ahead and explain.
Chong Shen: Yeah. Yeah. So the TinyML community talks about bandwidth, latency, efficiency, reliability, and privacy, if I'm not mistaken. I could be wrong with the last one. But in a production grid system, what you really want is the reliability of the deployed solution to do the full computation.
It doesn't have to be federated learning, but systems in general. So with the conversion of the file framework, we have separated what we call the application layer, where users will build in apps, and these are the ones that users will modify. And then we also have the infrastructure layer, which underpins this system. This infrastructure layer is responsible for receiving the flower commands from a user, and then to distribute all the necessary code the clients for the clients to actually perform the training. So in parallel terms, you come across it, but we call this the superlink to actually host the server.
And the supernodes supernodes are the long running services which basically orchestrate the clients. So these two components are long running. With these two components, because they are long running, the users can then execute multiple federations across all the systems without worrying about any of these components failing. So this is where the reliability comes into the picture. Because the connections are also established, we also handle the bandwidth and the connection, so we try to reduce the latencies between the supernodes and the superlink as well.
So the infrastructure is something that is being deployed once and that will persist for the lifetime of the project. And this makes it much easier for the users to continue to work with the production grid system. So it's always there waiting for you. Every time a user wants to go in and execute a run and look at the results, it's always there without worrying about any component failing and stopping the run.
Daniel: Chris and I are so happy that you are joining us each week to hear from amazing guests and listen to some of our own thoughts about what's happening in the AI world. But the things are just moving so quickly, and we recognize and want to see you all participate in the conversation around these topics. That's why I'm really happy to share that we're gonna start posting some webinar events on our website where you can join virtually and actually participate, ask questions, get involved in the discussion, and really deep dive into various topics related to either various verticals or technologies or tools or models. The first or next of these that's coming up is June 11 at 11AM eastern time. It's gonna happen virtually via Zoom, and you can find out information about that at practicalai.fm/webinars.
This is gonna be a a discussion around on prem and air gapped AI, in particular as how that relates to manufacturing and advanced logistics. I've seen personally as we work with customers in this area just the transformative power of this technology there from monitoring machine generated events to providing supply chain advice and so much more. But there's a lot of struggle in terms of deployment of this technology in those air gapped or in those on prem environments. So that's what we're gonna talk through on June 11. I really hope to see you all there.
For this discussion, again, June 11, '11 AM eastern time. It's gonna be virtual via Zoom, and you can find out more information at practicalai.fm/webinars. Chong, I love this idea of the sort of super notes and super links. And my thought is, I'm trying to work out in my head kind of if I was Let's say I'm working in the healthcare space and my nodes are maybe different hospitals or different facilities in a network or something like that, and I have a central place where I have my super link and I'm doing the aggregation. Just from a practical standpoint, as I think Chris mentioned before, you have these different facilities, you have different maybe stakeholders with different data.
What do I need to do as let's say I'm the person that's in charge of running the experiment, training the model. What do I need to do on the setup side to sort of connect in these super nodes or wherever the clients are? What needs to exist there? How do I register them in that setup process to really get going before I'm able to go in, like you say, and from a user perspective, run experiments or perform training runs and that sort of thing?
Chong Shen: There are many ways to go about it, but I think the cleanest way is to think about two groups of roles. One is the administrator role, and they are responsible for deploying the supernodes in each of these, let's say, health care facilities, health care centres. They are responsible for making sure the correct user is registered onto the Superlink or the Federation, and also to coordinate any monitor, basically monitor the usage of the Superlink itself. So that's the administrative role. And then there is the user role, or the data practitioners, data scientists would then write their apps, their server apps and their client apps, and then run these apps on the super link, on the federation that the administrator has deployed.
So I think this clear distinction would be an easy way to think about it. So as a start, an administrator would say there are five hospitals who want to form a federation. An administrator or administrators can go in and deploy the supernodes with the template. For example, if you using Kubernetes or Docker containers, you can have Helm charts that can deploy the supernodes in each of these five hospitals. The superlink can be hosted by a trusted third party server, or it can also be hosted by Flower Labs, for example, who can host a Superlink for you because it's just a simple service.
And then the users would register or be authenticated on the Superlink. So they need to be, both authenticated and have the authorization to run the Flowr commands on the Superlink. And that way, you can get a compression system up and running, in a cross silo setting.
Chris: I'm curious as we're kind of talking through it, and I'm learning a lot from you as as we're as you're describing it. And you've kind of made reference to admin roles and client server apps and, you know, super links and super nodes and stuff, which which, you know, kind of in the context of federated, there's networking and stuff like that. So I guess I have a generalized question around that. And and that is, is there any set of knowledge or skills that a user can kind of ramp up into or needs to know to use flower effectively, like like like particular, for instance, you know, that maybe they're coming from more of a kind of a the data science or kind of, you know, deep learning role. And and maybe they haven't done a lot of networking and stuff like that.
Do they need are there skills that they need to be able to ramp up into to be most effective at using Flower that you would recommend? Or, you know, what what would the expectation on the user be in that capacity?
Chong Shen: Yeah. That's a good question, actually. It's a fair question as well. In my opinion, what we're trying to convey is that we users do not need to think about the communication aspect of it at all, that everything is handled by the infrastructure. Of course, if a user starts to be more run into when the Shared Data Learning solution becomes a bit more complicated and run through very special cases, this is where some understanding of the communication protocols and how these are set up.
This could help as well. And I think for users who are stepping more into sort of administrative role and want to deploy the supernodes or work with the infrastructures, basically the superlinking supernodes, there are questions of infrastructuredev ops. You have to have some familiarity with deploying this in containers or working with pods, things like that. But fundamentally, when you first start to work with the framework, you can get started with a vanilla production system without worrying too much about the communication or needing to know too much about it. And then as you get your feet wetter, then you can learn more along the way.
Daniel: Well, yeah, that line of thought, along with something that you earlier said about how large language models generative have pushed the boundaries of how you do communicate data, weights back and forth, how you can handle larger models with the more recent versions of Flowr, and you're releasing the new version in a couple weeks, even with more. I'm wondering generally how certainly that's one aspect of how this sort of boom and generative AI has probably influenced your roadmap and how you're thinking about things, what people are wanting to do with Flowr. I imagine there may be a variety of ways that that's impacting Flowr. I was even thinking while you were talking about that, was like, Wow, it would be cool if there was a MCP server or something or helpers on top of flower that I could just type in natural language. That would be a friendly interface to set up my experiments and that sort of thing.
Yeah. As one of the core folks working on the framework, how have you seen this boom in interest around generative AI influence the roadmap and what you're thinking about at Flowr, what you maybe envision for the future of the framework, that sort of thing?
Chong Shen: Well, when you brought up the model context protocols, had a small interface, but there's definitely been some interesting conversations recently as well. We and the team are looking to that. Yeah. About the impact of generative models or large language models slash multimodal models, there's been a It's one of the driving forces for the Flowr framework as well. We really believe that this state of the art LMs as we speak, they're running out of data to train.
Back in December, Julia, the co founder of OpenAI, you were saying that data is running up, or data has run up to train these LMs. And yes, that's exactly the sentiment that we feel as well. It's the tip of the iceberg. There are tonnes of data locked in silos that could benefit from having large language models, either pre trained or fine tuned on in order to be useful, to be made useful. And the way to achieve it is through federated learning.
I think this is one of the key technologies that is driving the framework.
Chris: I'm curious kind of to extend that notion a little bit. As we're we we've been so into kind of the generative AI hype cycle for the last couple of years and stuff. And and now we're that that's kind of moving into combining models in different ways and and agentic, you know, focus and and ultimately, physical, you know, models going out there in terms of of interaction. And so and I I know I'm what I'm seeing out there involves instead of just having one model, you know, people are now putting lots of different combinations of models together to get jobs done. Does that in any way change kind of how you should think about about using federated learning?
Is is, like, every model that you might have in a solution just its own one off Flower implementation, or is there any ways that you guys are thinking about combining models together if they're all using data from, you know, different resources and stuff like that? Like, how as we're moving into my solution has many models in it, does that change in any way how users should think about using Flowr or architecting a Flowr based solution?
Chong Shen: It's a very deep question. I feel that there are a couple of possible futures here. There is a future where these agentic workflows, where you have models that are chained together to achieve a certain task, could also be used eventually in concert with federated learning. So I see a future where there is a possibility about that as well. But there needs to be some intermediary steps there.
And the reason is because these models, when you use them for agentic workflows, they need to be really optimised for the agentic workflows. They need to be trained on a certain type of structure and also be optimised for it. There needs to be some proper evaluations for that. So sort of the missing I see the future where if these two sort of pathways of agentic workflows and federated learning come together, it would be that people should think about having strong evals for this kind of workflows, and then knowing that there is a limit to them once you're able to quantify them, then to look for ways you can improve it through distributed learning, such as federated learning. And this is how you rationalize an improvement over, agentic workflows.
Daniel: Well, Chong, it's been fascinating to hear some of your your perspective on, especially production use of federated learning and flower. As we kind of draw to a close here, I imagine we'll have flower back on the podcast here in another couple of years or before. Hopefully this does be a recurring one. But as you look to this next season of either what you're working on or just the ecosystem more
Chong Shen: broadly,
Daniel: what's exciting for you, interesting for you that is always top of mind or is most there when 're going back from work in the evening? What's on your mind as you look forward?
Chong Shen: Yeah, absolutely. I think I'm very keen to think about this Foundation LLM that is purely trained on FL, on federated learning, and has been shown to be both privacy preserving and also state of the art. I think if the viewers and also yourselves, if you check out, we are collaborating with Vana as well in The US. They are looking into data DAOs, and we are very much working on that. So I'm really looking forward to seeing the first LLM in the world that is trained in FLA with, soda standards.
Daniel: Awesome. Well, yeah, we look forward to to that as well. Certainly come on the show and and give us your comments on it when it when it happens. But, thank you so much for taking time, Chong, to to talk with us. Really appreciate your perspectives.
And, please pass along our our thanks to the Flowr team and their continued work, you know, as a team, on a great addition to the to the ecosystem.
Chong Shen: I will. Thank you, Daniel and Chris. Thanks for having me having you on the podcast.
Jerod: All right. That is our show for this week. If you haven't checked out our Changelog newsletter, head to changelog.com/news. There you'll find 29 reasons. Yes.
29 reasons why you should subscribe. I'll tell you reason number 17. You might actually start looking forward to Mondays.
Sponsor: Sounds like somebody's got a case of the Mondays.
Jerod: 28 more reasons are waiting for you at changelog.com/news. Thanks again to our partners at Fly.io, to Brakemaster Cylinder for the Beats, and to you for listening. That is all for now. We'll talk to you again next time.