Have you been considering launching a product or even a business based on Python's AI ML stack?
We have a great guest on this episode, Dylan Fox, who is the founder of Assembly AI and has been
building his startup successfully over the past few years. He has interesting stories of hundreds
of GPUs in the cloud, evolving ML models, and much more that I know you're going to enjoy hearing.
This is Talk Python to Me, episode 356, recorded February 17th, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes
at talkpython.fm and follow the show on Twitter via at Talk Python. We've started streaming most of our
episodes live on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube to get
notified about upcoming shows and be part of that episode. This episode is brought to you by the
Stack Overflow podcast. Join them to hear about programming stories and about how software is made
in century. Find out about errors as soon as they happen. Transcripts for this and all of our episodes
are brought to you by Assembly AI. Do you need a great automatic speech to text API? Get human level
accuracy in just a few lines of code. Visit talkpython.fm/assembly AI. Dylan, welcome to Talk Python to
me. Yes. Thank you. I am a fan. I've listened to a lot of episodes and big podcast fan. So I'm happy
to be on here. Thanks. Yeah, I'm sure you are. Your specialty is in the realm of turning voice into
words. Yeah, that's right. I bet you do a lot of studying of media like podcasts or videos and so on,
right? Yeah, it's actually funny. So I started the company. I started Assembly like four years ago. And
there was this one audio file that I always used to test our speech recognition models on. It was this
Al Gore TED Talk from like 2007, I think. And I've almost memorized like parts of that TED Talk because
I've just tested it so many times. It's actually still part of our end-to-end test suite. It's in
there. It's like a legacy kind of founder thing that's like in the current still. Yeah, how cool.
Yeah, it is kind of funny, especially now that we're like 30 people at the company and I'll see
some of the newer engineers writing tests around like that Al Gore file still. And it makes me laugh
because there's no real reason I picked that. It was just something easy that came to me.
Yeah. Yeah. You can start. I just got to grab
some audio. Here's something, right? Yeah, exactly. Exactly. So yeah, definitely. I've also listened to
like a ton of podcasts and I was with, we just started like releasing models for different
languages. And I was with someone from our team last week and I heard this like phone call and it's
like, it's like foreign language. People like screaming on this. I was like, what are you listening
to? And, it is, but it is an audio company. You get sometimes data from customers and it's like,
you have to like listen to it. Yeah. I bet there's some interesting stories in there.
Yeah. For sure. Yeah. Well, we're very privacy conscious. So not too, not too many, but yeah.
Yeah. There was just, on the verge, there was just a article about a different speech to text
company. I don't know. Have you seen this, that there was some suspicious stuff going on? Let me see
if I can find it. I think, what was it called? It was Otter. Interesting.
Otter.ai. I'm not asking you to speak on them, but this, a journalist, Otter.ai scares a reminder
that cloud transcription isn't completely private. Basically there was a conversation about Uyghurs
in China or something like that. Yeah. And then they unprompted reached out to the person who was
in the conversation and said, could you tell us the nature of why you had to speak about this?
No way. They're like, what?
That is crazy. That is crazy.
Yeah. They're like, we're a little concerned about why, you know, it's, it's kind of like
interested in the content of our conversation.
Yeah. There's a lot of that like suspicion around, you know, there's some like, like conspiracy
theories right around like, oh, does your phone like listen to you while you're around and does
it evidently listen to you and then use that data to remarket to you? And I was talking to someone
about this recently. I did nothing about the location-based advertising world, but sometimes I'll
be talking about something and then I'll see ads for it on my phone or if I'm on Instagram or something.
And someone told me it's probably more based on like the location that you're in and the other data
that they have about you.
Yeah. You were at your friend's house. Your friend just searched for that, then told you about it.
Yeah, exactly.
I think the reality of that is that it's actually more terrifying than if they were just listening to you.
Yeah, it is.
That they can piece together this shadow reality of you that matches reality so well.
Yeah. Like your friend just bought this thing and you went over and then, so maybe you're
interested in this thing because you're probably-
Yeah, they probably told you about it or something, right?
Yeah. It is really crazy. It is really crazy. I haven't paid too much attention to all the
changes that are happening around like, I listened to some podcast, I think on the Wall Street Journal
about like the big change that Google's making around that tracking and how a lot of people are up
in arms about that. And it's, it was saying something how like they're going to have,
and sorry if I'm derailing whatever plan we had for a conversation here.
You're derailing in a way that I'm like super passionate about because it's so crazy,
but yeah.
Yeah, yeah.
We'll go too deep, but yeah, it's so interesting.
They said that there's, I'm probably butchering this, but something how like for each user,
they're just going to have like six like categories about you. And then one of them is going to be
randomly inserted as to somehow anonymize your profile. And I just thought, yeah, it was super weird
to hear about how they're doing it.
Yeah.
And like what the meeting was internally that came up with that idea, you know? So I'm like,
well, let's just throw a random category on there. I don't know.
My thoughts are we're faced or we're presented with a false dichotomy. Either you can have horrible,
creepy, tracking, advertising, shadow things like we talked about. Or you can let the creators and
the sites that make the services you love die. There are more choices than two in this world,
right?
For example, you could have some kind of ad that is related to what is on the page rather than who
is coming to the page, right? You don't necessarily have to retarget me. Like for example, right here
on this podcast, I'm going to tell people about, I'm not sure without looking at the schedule, what the
advertisers are for this episode, but I am going to tell people about that. And it is exactly related
to the content of the show. It's not that I found out that, you know, Sarah from Illinois did this Google
search and visit this page. So now we're going to show it like, no, it's, there's so many sites like this,
this one here on the verge, you could have ads for assembly AI and it'll be, maybe you don't actually want
on this one, but you know, like things like this, it would be totally reasonable to put an ad for speech
to text companies on there that requires no targeting and no evil shadow companies. And there's,
you know, like we go on and on, but there are many ways like that, right? That don't require this false
dichotomy that is being presented to us. So hopefully we don't end up with either of those. Cause I don't
think those are the best options or the only options. Yeah. It's weird how that's kind of how
things developed, you know, to where we are now. Yeah. But I agree with you. There's probably a lot we
can everyone's looking for like, okay, well, if we do retargeting, we can get 2% better returns.
And like, you know, the, no one's worried about, well, what happens to society?
Yeah. That's actually what I was going to say. It's all about the kind of high growth,
like society that we have where we need to maximize growth and maximize returns. And I mean,
I understand this acutely. Like I'm, you know, the CEO of a startup, so I get it. But yeah,
it's when it's like growth over everything, you end up with things like what you said,
like, Oh, it proves it to our returns 2%. So let's do this. But you don't think about what
the trade-offs will be. Yeah, absolutely. All right. Well, thanks for that diversion.
That was great. Yeah. But let's, before we get beyond it, let me just, get your background
real quick. How do you get into programming? And I'm going to mix it up a little and machine
learning. Yeah. Yeah, definitely. Do you want the long, the long story or the short story?
How many minutes do I have? Intermediate. Intermediate.
So the intermediate story is that I started a company when I was in college, just like a
college startup thing. And at the time was very limited in my programming knowledge. I had done
some basic like HTML when I was a kid, I was really into like, like Counter-Strike and Call of Duty and,
Oh yeah. Yeah. I would like sell up like private servers. I don't, I don't know how I got into this,
but would, would, I like rented these servers and I would like windowed remote windows desktop into
them and set up like private Counter-Strike servers and then sell those and set up like a basic website
for it with HTML and CSS. And, and my brother was super into computers. So it was always kind of
into computers. And then in college, got into startups. And I think like programming and startups are like
really connected. So through that, learned how to code, learned how to program, started attending
Python meetups in Washington, DC, where I went to school. And that's how I met Matt Mackay, who we,
it was a mutual, mutual connection. Yeah.
So attended a bunch of meetups, learned how to program and then got really into it. But I think
what I found myself more interested in was the like more like meaty programming problems, more like,
I guess like algorithm type problems. And that kind of naturally led me to like machine learning and NLP.
And then kind of just like took off from there. Cause I found that I was really interested in,
in machine learning and, and like different NLP problems.
Those are obviously the really hard ones that, you know, it's, yeah.
Especially probably when was this that you were doing it or the,
this is maybe like 2013, 2014.
Yeah. So, so kind of the early days of when that,
that was becoming real. Right. I remember feeling like all this AI and text to speech
or speech to text rather type of stuff was very much like fusion, like 30 years out, always 30.
Like it's, it's going to come eventually, but you know, people are doing weird stuff in Lisp
and it doesn't seem to be doing much of anything at all.
Like some like Pearl script seat out. Yeah. Yeah.
And then all of a sudden we end up with like amazing speech attacks. We ended up with
self-driving cars, like something clicked and it all came, came to life.
Yeah. It's kind of crazy, especially over the last couple of years.
I think what's really interesting is that a lot of the advances in like self-driving cars and NLP
and speech to text, they're all based on similar machine learning algorithms. So,
you know, like the transformer, right. Which is like really popular type of neural network
that came out was initially applied towards like just NLP, like text language modeling related tasks.
Now that's shown to be super powerful for speech as well. Whereas classical machine learning,
there were still these underlying algorithms like support vector machines or, you know, other,
other types of underlying algorithms, but a lot of the work was around like the data.
And so how can you extract better features for this type of data? And you had to be like,
I remember when I was getting into speech recognition, I bought this speech recognition,
like textbook. And this is, yeah, a while ago. And it was around like really understanding like
phonemes and how different things are spoken and how the human speech is spoken. And now you don't
need to know about that. You just get a bunch of audio data and you train these like big neural
networks. They figure that out. Right. You wanted to understand British accents and American
accents. You just give it a bunch of more data. Yeah, yeah, exactly. So, but it is,
it is crazy to see where things have gotten over the last couple of years in particular. Yeah. So
when I was starting out, neural networks were there, but they're a lot more basic and you didn't have,
like, there's a lot more compute resources down, more mature libraries like TensorFlow and
PyTorch. I think I went to like one of the first TensorFlow meetups that they had,
or not meetups, like developer days or whatever down at the Google conference. So it's,
it's like so new still. Yeah. It's so new. Yeah. It's easy to forget. It is a while ago.
It is. Yeah. That all the stuff didn't even exist, right? Yeah, absolutely.
So you mentioned assembly, assembly AI. Yes. That's what you're doing these days, right?
Yeah. So I am the founder of a company called assembly AI. We create APIs that can automatically
transcribe and understand audio data. So we had APIs for automatic speech to text of audio files,
live audio streams, live audio streams, and then APIs that can also summarize audio content,
do content moderation on top of audio content, detect topics, what we call like audio intelligence
APIs. And so we have a lot of startups and enterprises using our APIs to build the way we call it like
applications on top of audio data, whether it's like content moderation of a social platform or
speeding up workflows like I'm sure you have where you take a podcast recording and transcribe it so
you can make it more shareable or extract pieces of it to make it more shareable. Yeah, exactly. Yeah.
Basically for me, it's a CLI command that runs Python against your API, against a remote MP3 file. And then,
you know, magic. That's the great thing about podcast hosts that are also programmers. Like I've talked
to a few and they're all like, there's a bunch that are non-programmers and they use these different
services. But every podcast host that I've talked to that's a programmer, they have their own like
CLIs and Python scripts that they're running. Yeah.
Yeah. Yeah. Yeah. There's a whole series of just, you know, CLIs and other commands to do the workflow.
Yeah. I do want to just give a quick statement, disclaimer. Yes. So if you go over to the transcripts
or possibly, I suspect if you've listened to the beginning of this episode, it'll say that it's
sponsored by Assembly AI. This episode is not part of that sponsorship. This is just, you and I got to
know each other. You're doing interesting stuff. You've been on some other shows that I've heard that
the conversation was interesting. So invited you on. Thank you for sponsoring the show. But just to
point out, this is not actually part of that. But with the transcripts that we do have on the show,
the last year or so are basically generated from you guys, which is pretty cool.
Yep. Yep. And we don't even need to talk about Assembly that much on this podcast. We can talk
about other things. Yeah. So one of the things I want to talk about, and maybe what's on the screen
here gives a little bit of a hint of being TensorFlow, is why do you think Python is popular
for machine learning startups in general? I feel that I'm not as deep in that space as you, but
looking in from the outside, I guess I would say it feels very much like Python is the primary way
which a lot of this machine learning stuff is done.
Yeah. Yeah. That's a good point. So why that is, outside of machine learning even, I think Python's
just such a popular language because it's so easy to build with compared to PHP or C# and even
JavaScript. When I learned to code, I started with Python because the syntax was easy to understand.
There were a lot of good resources. And then there's this snowball effect where more people know Python,
so there's more tutorials about Python. There's more libraries about Python. And
it's just more popular of a language. Yeah. This insights to be pulling this up.
Yeah. If people have talked about this a lot, right? But if you pull up the Stack Overflow
trends for the most popular programming languages, there's only one that is going dramatically up out
of 10 languages or something. It's just so much more popular. Yeah.
It is. It's so interesting how it's really sort of taken off. And it wasn't back in when you got
started and when I got started back in this general area in 2012. Interesting. What was the number one
language then? The number one then was, what is that? C#.
C#. But you got to keep in mind, this is a little bit of a historical bias of Stack Overflow.
Stack Overflow was started by Jeff Atwood and Joel Spolsky, who came out of the .NET space.
So when they created it, its initial traction was in C# and VB. But over time, clearly,
it's become where programmers go, obviously. So take that a bit with a grain of salt. But that was the
number one back in the early days. Another founder legacy decision.
Yeah. Exactly. Yeah. Yeah. So I agree that it's absolutely generally popular. And I think there's
some interesting reasons for that. Yeah. It's just so approachable, but it's not a toy, right? A lot
of approachable languages are toy languages and a lot of non-toy languages are hard to approach.
So I'll see you next time.
For a dozen years, the Stack Overflow podcast has been exploring what it means to be a developer
and how the art and practice of software programming is changing our world. Are you wondering which skills
you need to break into the world of technology or level up as a developer? Curious how the tools
and frameworks you use every day were created? The Stack Overflow podcast is your resource for tough
coding questions and your home for candid conversations with guests from leading tech companies about the
art and practice of programming. From Rails to React, from Java to Python, the Stack Overflow podcast will
help you understand how technology is made and where it's headed.
Hosted by Ben Popper, Cassidy Williams, Matt Kierninder, and Sierra Ford, the Stack Overflow
podcast is your home for all things code. You'll find new episodes twice a week, wherever you get
your podcasts. Just visit talkpython.fm/stackoverflow and click your podcast player icon to subscribe.
And one more thing. I know you're a podcast veteran and you could just open up your favorite podcast app
and search for the Stack Overflow podcast and subscribe there. But our sponsors continue to support us when
they see results and they'll only know you're interested from Talk Python if you use our link.
So if you plan on listening, do use our link, talkpython.fm/stackoverflow to get started.
Thank you to Stack Overflow for sponsoring the show.
Yeah, like for me, it was very easy to get started with Python. And I actually had,
so I taught myself how to program. I went to college, I studied economics. So I did not study
programming in college computer science. And the first language I started to try to learn was PHP.
And I bought this huge PHP textbook and made it halfway through. And I was like, what is going on?
I gave up and then tried again with Python later and it was so much easier.
And then I also wonder how much of this is for the machine learning libraries in specific.
Like you have these macro trends where a lot of the data science boot camps that have been so popular.
There's Scikit-learn. I know we have a tab up there. There's NumPy and I dream of what NLTK is one of the
popular NLP libraries. So there are a lot of libraries in Python in the early, like when I was getting into NLP,
I worked a lot with NLTK and like SciPy and Scikit-learn and NumPy. And I think a lot of
work was done around there. And so people that were doing data science or doing some type of machine
learning were already in Python. And then now you have like PyTorch and TensorFlow and it's just like
kind of cemented, like, okay, the machine learning libraries today, the popular ones that you work
with them in Python.
Yeah. You want to give us your thoughts on those? We've got TensorFlow and PyTorch and
you know, probably Scikit-learn as well. Those are the traditional ones. We've got some newer ones like
Hugging Face.
Yeah. Yeah. They're a cool company.
Yeah. Maybe give us a survey of how you see the...
The different libraries.
The libraries that people might choose from.
So when we started the company, everything was in TensorFlow.
When was that?
Back in like late 2017.
Okay.
Yeah. Late 2017. Everything was in TensorFlow. And actually, I don't know what year
PyTorch came out. I don't even know if it was out back then. Or maybe it was like just internally at Facebook.
Yeah. It's pretty new. Yeah.
Yeah. So TensorFlow was definitely, they got started early. I think their docs and
the framework just got complicated over the years. And then they sort of rebooted with like TensorFlow 2.0.
And then there was like Keras that was popular. It kind of got pulled in. Now, I think,
so we switched everything over to PyTorch in the last year or two. A big reason for that was that,
and we actually put out this article on our blog comparing like PyTorch and TensorFlow. And we have
this chart where we show like the percentage of papers that are released where the code for the
paper is in PyTorch versus TensorFlow. And it's a huge, huge difference. Like most of the latest
research gets implemented. Yeah, here it is. If you go down to one of, so this is, yeah,
hugging face. Can you go keep going? Yeah, research papers. Yeah. Go up to that one. Yeah. Okay.
So it shows like the fraction of papers. And so what we're showing here for the people that are
listening is like a graph that shows the percentage of papers that are used, built using PyTorch
versus TensorFlow over time. Yeah. When you started, it was, what is this? Six, seven percent?
Yeah, probably 10 percent. And the balance being TensorFlow,
Right. When you started your company. Right.
And now it's 75 percent PyTorch. That's a huge, very large change.
It's a dramatic change. You know, if PyTorch was a company, it'd be like
probably raising a lot of money. I think one of the reasons we picked PyTorch is because a lot of the
newer research was being implemented in PyTorch first. There were examples in PyTorch. And so it's
easier to get, they have it on their, it's their tagline, but to quote them, like from research to
production, right? Like it was easier to get more exotic, advanced neural networks into production and
like actually start training models with those different types of layers or operations or loss
functions that were released in these different papers. So we started using PyTorch and we kind of
haven't looked back. Yeah.
Well, if you're tracking all the research and trying to build a cutting edge startup around ML,
you don't want to wait for this to make its way to other frameworks. You want to just grab it and go.
So that's where the research is being done. That helps a lot, right?
Right. Exactly. Yeah. You can get, just get up and running a lot faster with the newer research. And so
most companies that I talk to now, they're all using PyTorch. I think PyTorch is definitely like
the more popular framework. There's some new ones coming out that have people excited, but still,
like from what I can sense, PyTorch is, if someone was going to get started today, I would tell them
to start with PyTorch. Yeah.
And I think TensorFlow is also- Who runs PyTorch? I think it's-
Sorry, who runs PyTorch? It's released by Facebook, right?
Yeah. And then TensorFlow, that's Google, right?
Google, yeah. Yeah. And I think Google's tried to tie TensorFlow into their cloud ML products,
so train your models on Google Cloud and use their TPUs in the cloud. And there's probably some business
in this cases behind that, but I feel like it may have made the developer experience worse because
it's trying to get back to Google. Whereas PyTorch isn't trying to get you to train your models on
Facebook Cloud or something. Yeah. What's the story with hugging face?
This is how- People probably wouldn't use Facebook Cloud if that existed nowadays.
Yeah. I don't know if you'd want to host your data interface. Meta Cloud. I mean, Meta Cloud now.
Yeah. Meta Cloud. You can only do it in VR. Yeah.
What's the story with Hugging Face? So Hugging Face is a cool- So this is a company, actually.
And they have, it's kind of hard to even explain. It's like, you can basically get access to a bunch
of different pre-trained models really quickly through Hugging Face. And so if you want to,
a lot of work around NLP now is like how familiar you are with like self-supervised learning or
base models for NLP. I'm familiar with that. Somewhat. So the idea is to have a,
like a general model and then apply some sort of transfer learning to build up a more specialized
one without training from scratch. Is that- Exactly. Yeah. And then that general model is,
is really just trained to like learn representations of the data. It's not even really trained like with us,
our particular like NLP task. It's just like trained to learn representations of data. And then
with those representations that it learns, you can then say like, okay,
you know, I'm going to train you towards this specific task with some labeled data in a
supervised manner. And so there are some really popular open source, like base models, foundation
models, like BERT is one, there's a bunch of others, but you can easily get like, like load up BERT basically,
and fine tune it on your data with Hugging Face. So if you're trying to get a model, the model up and
running quickly in like the NLP, like the text domain, you can do that pretty easily with Hugging
Face. And- Okay.
Yeah. So it's less like, if you want to like build your own neural network from scratch,
like inputs to outputs, implement your own loss function, all that, you would do that in PyTorch.
If you want to try to just like quickly fine tune BERT for a specific task that you're trying to solve,
you could still go like the PyTorch out, but it would just be faster to go with Hugging Face. So they've seen a lot of adoption there. And then scikit-learn is kind of like the old school library that's been around forever with like-
The OG, yeah.
The OG, yeah. Like if you want to do stuff with like support vector machines or random forest or like KDR's neighbors, you know, this scikit-learn is probably still really popular in that for those different use cases.
I do think that I hear scikit-learn being used quite a bit still.
Yeah.
Maybe in the research, the academic, if you go take a course on it, you know, probably there's a lot of stuff on this, I would guess.
Yeah. Like there's a lot of times where, I mean, you don't really need to build a neural network. I mean, there's parts of our stack that are really important.
Like basic machine learning, like statistical models. And if you can get away with it, it's a lot easier to train and you don't need as much data and it's easier to deploy. So like a lot of like recommendation type models or, and sometimes SVMs are just like good enough. SVMs, support vector machines are just good enough for, for a task that you might want to have.
So for a lightweight Netflix recommendation or YouTube recommendation, not like the high end stuff that I'm sure they're actually doing.
Yeah.
Something like that.
Yeah. Yeah, exactly.
That kind of recommendation engine. Yeah.
Something, yeah. Something basic. Yeah. Although I actually am kind of underwhelmed with like the Netflix and YouTube recommendations are very good.
Netflix recommendations and like prime recommendations are kind of underwhelmed by. You would think that you watch.
I agree.
Yeah. Yeah. It's still so hard to find things to watch sometimes on those platforms.
It is. And YouTube interestingly seems to have an end. So if you scroll down through YouTube, like 10 pages, it'll start showing you like, well, it seems like we're out of options. Here, we'll show you 10 from this one channel. And then we'll just kind of stop.
I know you got a lot of videos. You could just keep recommending stuff. I'm pretty sure if you would keep recommending it. There's stuff down here. But yeah, I agree. It's interesting.
I feel like it's gotten better too. Like my YouTube consumption has really picked up over the last year, I would say. The recommendation algorithms, and I don't know if it's just more content being created or maybe it's just like a personal thing for me. And there was some thing on Hacker News too about like YouTube comments that like one of the founders of Stripe posted are like generally very positive. And like there's really good comments on YouTube too. So they've definitely also come up with ways to classify comments as being high value or not.
And then put those up top. And nowadays, those models are definitely used with something like for some big neural networks and transformer.
Yeah.
Because those neural networks, they're so much better at understanding context. And like SVMs, you have to still, for a lot of these classical machine learning approaches, like feed it, hand-labeled data. But the neural networks, yeah, they're really good for those language tasks now.
Yeah, absolutely. Christopher out in the audience has a question. That's kind of interesting. Does it make sense to start with scikit-learn if, for example, you're trying to predict when a production machine is not out of tolerance yet is trending to be?
Is that like, God...
Like if you were like monitoring like a data center for maybe VMs, I'm guessing.
Like your RAM or like memory is going high or some statistic is like predictive that this VM will probably go down.
Failure is coming.
Failure is coming. Yeah.
And the question was, is it SBM or scikit-learn good to start with? Yeah, I would actually probably say that's where you want to go with something like scikit-learn.
Because there's probably very clear-cut patterns.
I would say if you're unsure of what the pattern is, then a neural network is good because a neural network can, in theory, like you're feeding it raw data and it's learning the pattern.
But if you know what the pattern is, like, okay, like there's probably like these signals that if a human was just sitting there looking at it all day, would be able to tell this system is probably going to go down.
Then you just can train an SVM or some type of classical machine learning model with scikit-learn to be able to do those predictions with pretty high accuracy.
And then you've got a super lightweight model.
You don't need much training data to train it because you're not trying to build something that's like super generalizable to like all systems or like all AWS instances.
It's probably something unique to your system.
But I would say that's kind of where the difference is.
And then it's a lot easier too because if you're trying to build like a neural net, it's like, well, what type, how many layers, what, you know, kind of like optimization schedule, like learning rate.
There's all these hyper parameters and things you have to figure out.
You still have to do that too for classical machine learning to a degree.
But if your problem is not that difficult, it's not as, you know, like fancy nowadays, but it gets the job done.
Yeah.
I suspect you could come up with some predictors and then like monitor them for in this model, whereas opposed to here's an image that is a breast scan.
Does it have cancer or not?
Right.
Like exactly.
We don't even really know what we're looking for, but there probably is a pattern that could be pulled out by a neural network.
Exactly.
Yeah.
That's a great point.
And, you know, like we're trying to build some predictive scaling for our API right now, because, you know, one of the problems with the challenges of a startup that's doing machine learning in production is, you know, we deploy like hundreds of GPUs and thousands of CPU cores into production every day at peak load.
And then there's just huge costs that come from a scale.
And then there's huge costs that come with that.
And so we've done a ton of work around like auto scaling and trying to optimize models and production and things like that.
And now we're trying to do some predictive scaling.
And for that, for example, we'd probably do something super simple with like scikit-learn.
We wouldn't do a neural net for that.
Yeah.
The scaling sounds like solving a basically a similar issue.
Yeah.
As understanding failure, right?
Yeah, exactly.
Exactly.
The lack of scaling sometimes is kind of the result is failure.
So yeah, they're somewhat related together.
Yeah.
You talked about like running stuff in production.
And there's obviously two aspects for machine learning companies and startups and teams and products that are very different than say the kind of stuff I do, right?
Like I've got APIs that are running.
We've got mobile apps.
We've got people taking the courses.
But all of that stuff, there is like one.
It's always the same, right?
We put stuff up and people will use it and consume it and so on.
But for you all, you've got the training and almost the R&D side of things that you've got to worry about working on and scaling.
Right.
And then you've got the productionizing.
So maybe tell us a little bit about how you, what do you guys use for-
For both parts.
For training.
Yeah.
Maybe start with the training side.
Yeah, the training side, it's basically like impossible to use the big clouds for that because it would just be prohibitively expensive, at least for what we do.
So we train like these huge neural nets for speech recognition and different NLP tasks.
And, you know, we're training them across like 48, 64 GPUs, like really powerful GPUs.
I've got the GeForce 3090, which is a beast up here.
Do you know what kind you're using?
Yeah, so we use a lot of V100s, like A100s.
And we rent, basically what we do is we rent dedicated machines from provider.
And each machine, we're able to like pick the specs that we want.
Like how many GPUs, what cards, how much RAM, what kind of CPU we want on there.
So we're able to pick the specs that we want.
And we found that that's been the best way to do it because the big clouds, yeah, if you're running like a dozen, dozens of GPU, like of the most expensive types of GPUs for like weeks on end, you could do that if you had like one training run you wanted to do.
But a lot of times you have to train a model halfway through.
It doesn't work well.
You have to restart or finish this training and the results are not that good.
And you learn something.
So you have to go back and start over.
And now what we're doing is buying a bunch of our own compute.
Like my dream is to have some closet somewhere with just like, you know, tons of GPUs and like our own like mini data center for the R&D.
Because if things go down, you know, like when you're training a model, you checkpoint it as you go.
So if your program crashes or your server crashes, like you can resume training.
Whereas like for production workloads, we use AWS for that because things can't go down.
And I don't think we'd want to take on our own competency of like hosting our own production infrastructure.
But for the R&D stuff, you know, we are looking into just buying a ton versus renting because it'd be a lot more cost efficient.
And you can, instead of basically like paying each year for the same compute, you just like buy it once.
And then you just pay for the electricity and server hosting costs and maintenance costs that come with that.
Yeah.
Maybe find a big office building and offer to heat it for free in the winter by just running on the inside.
There's this like, you know, you can run like NVIDIA SMI.
I don't even play around with GPUs at all.
But like, you can see what the temperature is of the GPU.
And like sometimes, you know, if I'm, I remember a while ago when I was training some of these models, I would just like look at what the temperature is during training.
And yeah, they get so hot.
And these data centers have to have all this, all these special cooling infrastructure to keep the machines down.
It's pretty environmentally unfriendly.
Yeah.
To the extent that some of them, yeah, to the extent that people are creating underwater data center, like nodes and putting them down there and just letting the ocean be the heat sink.
Yeah.
That's crazy.
You can buy some land and like, you know, in Arctica and put our stuff there.
That's where like the GitHub, like the Arctic code thing.
I forget what it's called.
Yeah.
The Arctic code vault.
Yeah.
Yes.
Yeah.
So we could do something like that for our GPUs.
When we get bigger, that's, that's the dream.
That's where it might nerd out.
There you go.
So, yeah, so we train, I think we have like, I think somewhere like maybe like 200 like GPUs that we use just for R&D and training.
And we're getting a lot more because you don't want to be, a lot of times there's like scheduling bottlenecks.
So two researchers want to run a model and need a bunch of compute to be able to do that.
And they're both good ideas.
You don't want to have to like wait four weeks for someone to run their, their model because compute is taken.
So we're trying to unblock those scheduling conflicts by just getting more compute.
Yeah.
And for the production side, yeah, we deploy everything in AWS right now and onto like smaller GPUs.
Because a lot of our models do inference on GPU still.
Some of our models do inference on CPU.
Oh, interesting.
Yeah.
To, to evaluate the stuff, it still uses GPUs.
Yeah.
Correct.
Even after the models are created.
Correct.
Yeah.
I mean, there's, we could run it on CPU, but it's just not as parallelizable as running
it on GPUs.
There's a lot of work that we could probably do to get it really efficient so that, you know,
we're running it on like as few CPU cores as possible.
But one of the problems is like almost like every like three to four months, we're like throwing
out the current neural network architecture and using a different one that is giving us better
results.
Like sometimes we'll make the model bigger or there'll be a small tweak in the model
architecture that yields better results.
But a lot of times it's like, okay, we've kind of iterated within this architecture as
much as we can.
And now to get the next accuracy bump, we have to go to a new architecture.
We're undergoing that right now.
We've released our, one of our like newer speech recognition models we released, I think
like three months ago and the results are really good, but now we have one that is looking
a lot better and it'd be like a completely different architecture.
And so it's just that trade off of, do you spend a bunch of time optimizing the current
model that you have and trying to like prune the neural network and do all these optimizations
to get it really small?
Or do you just spend that research effort and that energy focused on finding the next accuracy
game?
And because we're trying to win customers and grow our revenue, it's just, all right, let's
just focus on the next model.
And when we have a big enough team or when we can focus on it, we'll work on making the
models smaller and more compute efficient and less costly to run.
But right now, yeah.
Like our speech recognition model that does inference on a GPU.
There's a couple of our like NLP related models, like our content moderation model that does
inference on a GPU.
And then there's like our automatic punctuation and casing restoration model.
Like that runs on a CPU because that's not as compute intense.
And so it really varies.
Yeah.
As you say, it's pretty interesting to think about how you're optimizing the software
stack and the algorithms and the libraries and whatnot.
You know, when you're not doing something that's changing so quickly, you know, if it's working,
you can kind of just leave it alone.
Right.
Like, right.
I've got some APIs, I think they're built either in Pyramid or Flask.
Sure.
It'd be nicer to rebuild them in FastAPI, but they're working fine.
I'm just like, I have no reason to touch them.
Right.
So there's not a, like a huge step jump I'm going to take.
They're not under extreme load or anything.
Right.
This portion of Talk Python to me is brought to you by Sentry.
How would you like to remove a little stress from your life?
Do you worry that users may be encountering errors, slowdowns, or crashes with your app right
now?
Would you even know it until they sent you that support email?
How much better would it be to have the error or performance details immediately sent to you,
including the call stack and values of local variables and the active user recorded in the
report?
With Sentry, this is not only possible, it's simple.
In fact, we use Sentry on all the Talk Python web properties.
We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we
got the support email.
That was a great email to write back.
Hey, we already saw your error and have already rolled out the fix.
Imagine their surprise.
Surprise and delight your users.
Create your Sentry account at talkpython.fm/sentry.
And if you sign up with the code talkpython, all one word, it's good for two free months of
Sentry's business plan, which will give you up to 20 times as many monthly events as well
as other features.
Create better software, delight your users, and support the podcast.
Visit talkpython.fm/sentry and use the coupon code talkpython.
But in your world, there's so much innovation happening around the models that you do have
to think about that.
So how do you work that tradeoff?
How do you like, well, could we get more out of what we've got or should we abandon it and
start over?
Right?
Because it is nice to have a very polished and well-known thing as well.
Definitely.
And every time you throw out our architecture to implement a new architecture, you've now
got to figure out how to run that architecture at scale.
And you don't want to have any hiccups for your current customers or users of your API, which
sometimes happens because these models are so big that you can't just write this model
that service that sits on a GPU and does everything.
You have to break it up into a bunch of component parts so that you can run it efficiently at
scale.
So there's like eight, nine microservices for a single model because you break out all
these different parts and try to get it running really efficiently in parallel.
But it does beg the question of how do you build good CICD workflows and good DevOps workflows
to get models into production quickly?
And this is something that we're working on right now and trying to solve.
Because a lot of times we have better models and we sit on them for like two, three weeks
because to get them into staging, we have to do low testing, see does anything with scaling
have to change because the model profile is different?
Are there any weird edge cases that we didn't check or see during testing?
So it slows down the rate of development because you have, it's hard to do CICD.
It's not like you just, okay, run these tests, the code works, go.
There's like compute profile changes that happen.
So maybe you need a different instance type or you need to...
Right.
Uses less CPU, but way more RAM.
So if you actually deploy, it's going to crash or something.
Okay.
Exactly.
And then doing that at scale, you have to profile out and do low testing.
And so really, we're trying to figure out how to get these models into production faster.
And I think the whole ML ops world is so in its infancy around things like that.
And it's a lot of work.
Yeah.
It's a lot of work.
So for us, the trade-off though is always like, you know, our customers and developers,
they just want better results and always more accurate results.
And so we just always are working on pushing our models, making them more accurate.
If we can iterate within a current architecture, great.
Like sometimes you can just make the model bigger or make a small change and then you get
a lot of accuracy improvements.
And it's just like what we call it a drop-in update where no code changes.
It's just literally like the model that you're loading is just different.
And then it's just more accurate.
Right.
That's easy.
Yeah.
That's the dream.
You know, it's just a drop-in, but that's maybe like 30% of updates.
Like the other 70% are, okay, you've got a new architecture or it's got a pretty different
compute profile.
So it uses a lot more RAM or it's a lot slower to load in the beginning.
So we need to scale earlier because instances come online later and become healthy later.
So there's all these like things you have to think about.
Yeah.
The whole DevOps side of this sounds way more interesting and involved than I first thought.
Yeah.
It's painful too.
I mean, we're like, I can't explain how many like graphs we have in Datadog, just like monitoring
things all day.
Luckily, I don't have to work on that anymore.
That was very stressful.
And I was like owning the infrastructure.
Now we have people that are better at it than me.
We had like two DevOps people start on Monday, but yeah, like DevOps is a huge, huge piece
of this.
Yeah.
That's quite interesting.
Yeah.
I do want to just circle back to one real quick thing.
You talked about buying your own GPUs for training and people might out there be thinking
like, who would want to go and get their own hardware in the day of AWS, Node, whatever,
right?
Like it just seems crazy.
But there's certainly circumstances.
Like here's an example that I recently thought about.
So there's a place called Mac Stadium where you can get Macs in the cloud.
Hey, how cool, right?
So maybe you want to have like something you could do with extra things.
And well, what does it cost?
Well, for a Mac mini M1, it's $132 a month.
You think that's, is that high or low?
Well, the whole device, if you were to buy it costs $700.
Yeah.
You know, that's, and I suspect that even though the GPUs are expensive, there's probably something
where like, if you really utilize it extensively, it actually makes.
To buy it.
It stops making sense in ways that people might not expect.
Yeah.
That it's a buy it, you mean, right?
Like it stops making sense to rent it.
Yeah.
That's what we're facing.
It stops making sense to rent it in the cloud.
Yeah.
I mean, we spent a crazy amount of money renting GPUs in the cloud and it's like, okay, you
know, if we had a bunch of money to make a, you know, CapEx purchase, right?
Like just shell out a bunch of money to buy a bunch of hardware up front, it'd be so much
better in the long run.
Cause it is similar to the example you made about like, if you don't have a lot of cash, then you're
only going to use a Mac for a couple months.
Right.
You need it for two weeks.
Then it doesn't make sense to buy it.
Great.
You just, you pay the a hundred dollars and you're good.
Right.
Or if you don't have like 2k and you know, then, then you just rent in and it's like,
you know, if you don't have the money to buy a house, you rent an apartment, right?
Like things like that.
So there are definitely benefits.
And I think for a lot of, I think for most models, you don't need crazy compute.
Like you could get away with, like, you could buy a desktop device that has like two GPUs
or you could rent a dedicated machine or still do it on AWS if you're using like one or two
GPUs.
And it wouldn't be insane.
So if you're just starting out, all those options are fine.
But if you're trying to do like big models and, or train a bunch of parallel, you need
more compute.
And definitely doesn't make sense to use the big clouds for that.
There's a bunch of dedicated providers that you can rent, like dedicated machines from
and just pay a monthly fee regardless of how much you use it.
And, it's a lot more, it's a lot more efficient for like companies to do that.
Give me your thoughts on sort of CapEx versus OpEx for ML startups rather than, I don't know,
it's some other SaaS service that doesn't have such computational stuff, you know, being
CapEx being, you got to buy a whole bunch of machines and GPUs and stuff versus OpEx.
Like, well, it's going to cost this much to rent in the cloud.
Like I feel like things are more possible because you can get the stuff in the cloud,
prove an idea and then get investors without going, well, you know, let's go to friends
and family and get 250,000 for GPUs.
And if it doesn't work, we'll just do Bitcoin.
Yeah.
Yeah, yeah, yeah.
Definitely.
I mean, we started in the cloud, right?
So like first models we trained were K80s on K80s and AWS took like a month to train.
Wow.
Yeah, it was terrible.
So we started in the cloud and then now that we're fortunate to have like more investment
in the company, we can make these CapEx purchases.
But yeah, I mean, the operating expenses of running an ML startup are also like crazy, like
payroll and GP and payroll and like AWS are our biggest expenses because you run so much
compute and it's super expensive.
And what I talk about and what we talk about is like, there's nothing fundamental about what
we're doing that makes that the case.
It's just goes back to that point of like, do you spend a couple months optimizing your models,
bringing compute costs down?
Or do you just focus on the new architecture and kind of pay your way to get to the future?
Like this growth versus, yeah.
And then we're like a venture-backed company.
So like there's expectations around our growth and, you know, all that.
So we just focus on like, okay, let's just get to the next milestone and not focus too much
on like bringing those costs down because there's the opportunity cost of doing that.
But eventually we'll have to.
Yeah.
It's a little bit of the ML equivalent of sort of the growth.
You can lose money to just gather users.
Yeah.
But this is the sort of gain capabilities, right?
It is.
Yeah, it is 100%.
And then you'll figure out how to do it efficiently once you kind of find your way.
Okay.
And I'll give you like a tangible example.
I mean, like we've been adding a lot of customers and developers on the API and there's always like
new scaling problems that come up.
And sometimes we're just like, look, let's just scale the whole system up.
It's going to be inefficient.
There's going to be waste, but like let's scale it up and then we'll like fine tune the auto
scaling to bring it down over time versus like having to step into like a more perfect auto
scaling scenario that wouldn't cost as much, but there'd be bumps along the way.
And so we just like scaled everything up recently to buy us time to go work on figuring out how
to improve some of these like auto scaling.
Yeah.
You could spend two weeks trying to figure out the right way to go to production or you
could spend just more money.
Exactly.
And then, cause you, you might not be sure with the, like the multiple month life cycle,
some of these things.
Right.
Is this actually going to be the way we want to stick with?
So let's not spend two weeks optimizing it first.
Right.
Very interesting.
And I mean, like, look, not every company can make that decision.
Like if you are bootstrapped or you're trying to get off the ground, which like a lot of companies
are, you do have to make those, you can't just pay your way to the future.
Yeah.
And I'm a big fan of bootstrapped companies and finding your way.
I don't think that necessarily just, you know, set a ton of money on fire.
Right.
It's the only way forward.
But if you have backers already, then they would prefer you to move faster.
I suspect.
Correct.
Yeah.
Correct.
Like I always was self-conscious about our, you know, operating costs as an ML company,
cause they're high compared to other SaaS companies where you don't have heavy compute,
but you know, the investors we work with, they get that like, okay, this isn't, there's
nothing like that fundamental about this that requires those costs to be high.
You just have to spend time on bringing them down and it's, there's like a clear path.
It's not like Uber where it's like the path to bring costs down or like self-driving cars
because it's expensive to employ humans.
That's like, you know, so far down the road.
Yeah.
But for us, it's like, okay, we need to just spend three months making these models more
efficient and they'll run a lot cheaper, but it's that trade-off.
But I love bootstrap companies too.
I mean, it's just a different way to do it.
Something special about like, you're actually making a profit and you're actually, you have
customers and people paying for stuff.
Yeah.
And the, and the freedom for sure.
Yeah.
So you probably saw me messing around with the screen here to pull up this Raspberry Pi
thing.
There's a question out in the audience says, could you do this kind of stuff on a Raspberry
Pi?
And like a standard Raspberry Pi, I suspect absolutely no.
Yeah.
Have you ever seen that there are water-cooled Raspberry Pi clusters?
Whoa.
I have not seen that.
That is crazy.
Is that insane?
That's insane.
So what kind of computer are they getting on that?
It's pretty comparable to a MacBook Pro on this.
That's crazy.
They've got what, eight water-cooled Raspberry Pis in a cluster.
And it's really an amazing device.
But if you look back at a, you know, you sort of consider it like a single PC with a, you
know, a basic Nvidia card or a MacBook Pro or something like that.
Like that's still pretty far from what you guys need.
Like how many GPUs did you say you were using to train your models?
It's like 64 for the bigger ones.
Yeah.
In parallel.
Yeah.
These are not small GPUs.
So I suspect I'm going to maybe throw it out there for you and say probably no, maybe
for the scikit learn type stuff, but not for what you're doing.
Not the TensorFlow PyTorch.
Yeah.
Not for, not for training, but you could do inference on a Raspberry Pi.
Like you could squeeze a model down super tiny, like what they do to get some models
onto your phones.
And you're on that on a Raspberry Pi.
You get the models small enough.
The accuracy might not be great, but like you could do it.
Yeah.
Oh, there's a lot of stuff happening around the edge.
Like I think a lot of that Siri.
Yeah.
The edge compute, the sort of ML on device type stuff.
Like a lot of the speech recognition on your phone now happens on device.
Yeah.
And not in the cloud.
Yeah.
Sort of related to this, like the new M1 chips and even the chips in the Apple phones before
then come with like neural engines built in, like multi-core neural engines.
Right.
Interesting for edge stuff again, but not really going to, not really going to let you do like
the training and stuff like that.
Right.
I haven't done much iOS development, but I know there's like SDKs now to kind of like get your
neural networks like on device and make use of these, like the hardware on the phone.
And definitely if you're trying to deploy your stuff on the edge, there's a lot more
resources available to you.
Yeah.
And it's a really good experience because having, you know, you speak to your assistant
or you do something and it says thinking, thinking like, okay, well that I don't want
that.
Like, I'll just go do it if I got to wait 10 seconds.
Right.
Yeah.
But it happens immediately.
And there's the privacy aspect too.
Yeah, absolutely.
The privacy is great.
Yeah.
Like the wake word on the, like, I don't know if you know this, but like the wake
words, like on the Alexa device, like they happen local, that runs locally.
Although I've heard, I've heard that when you say Alexa, they verify it in the cloud
with a more powerful model.
Interesting.
Because sometimes it'll trigger and then shut off.
I don't know if you've ever seen that happen.
Yeah.
It's, it'll spin around and go, ah, no, that wasn't right.
Yeah, exactly.
I think what's happening is that they're sending what they're sending like the wake
word to the cloud to verify.
Like, did you actually say Alexa?
Probably the local models below some certain confidence level, it sends it up to the cloud and then
the cloud verifies like, yeah, start, start processing.
But it is much faster from a latency perspective.
Although with, with 5G, I don't know, like mobile internet is so much, it's faster now.
It's getting pretty crazy.
Yeah.
Yeah, absolutely.
Yeah.
Sometimes I'll be somewhere my wifi is slow and I'll just tether my phone and it's like
faster.
Yeah.
If I'm not at my house, I usually do that.
If I go to a coffee shop or an airport, I'm like, there's a very low chance that the wifi
here is better than my 5G tethered.
Yeah.
Exactly.
Jack Woody out in the audience has a real interesting question.
I think that you can speak to because you're in this space right now, living it.
What do investors look at when considering an AI startup or maybe AI startup, not just specifically
speech to text?
Yeah.
It's a good question.
I think it really depends on like, are you building like a vertical application that makes
use of the AI?
So you're building some like call center optimization software where there's like AI under the hood,
but you're, you're using it to power this like business use case versus are you building
some like, like infrastructure AI company?
Like we're us, like we're building APIs for speech to text, or if you're building a company
that's exposing like APIs for NLP or different types of tasks, I think it varies what they
look at.
I am not an expert in like fundraising or AI startups.
I want to make that very clear.
Like, so, so maybe don't take my advice too, too seriously.
Yeah, but you've done it successfully, which is, I mean, there are people who claim to
be experts, but are not currently running, you know, a successful backed company.
So I wouldn't put too much of a caveat there.
Yeah.
I think we just got lucky with, you know, meeting some of the right people that have helped us.
But I think it's like, yeah, you know, are you, are you doing something innovative on the
model side?
Do you have some innovation on the architecture side?
I actually don't really think the whole like data vote is that strong of an argument personally,
because there's just so much data on the internet now.
And did a moat being like, we run Gmail so we can scan everybody's email.
That gives us a competitive advantage.
Yeah.
Something like that.
Exactly.
Yeah.
I don't know.
Like you might get like a slight advantage, but there's so much data on the internet and
there's so many, there's so many innovations happening around.
Like, look at, look at GPT-3 that OpenAI put out, right?
That was just trained on like crazy amount, a huge model trained on crazy amounts of public
domain data on the internet.
That works so well across so many different tasks.
So even if you had a data mode for a specific task, like it's arguable that GPT-3 could beat
you at that task.
So I think it depends what you're doing, but I don't personally buy into the whole data mode
thing that much.
You know, cause like even for us, we're able to build some of the best speech to text models
in the world.
And we don't have this like secret source of data.
You know, we, we just have a lot of innovation on the model side and there's tons of domain
data in a public domain that you can access now.
So I think it's really about like, are you building some type of application that is making
the lives of like a customer developer, some startup, like easier leveraging AI?
Right.
Are you solving a problem that people will pay money to solve?
Yeah.
Yeah, exactly.
Exactly.
Cause I actually think it's more about like the distribution of the tech you're building
versus the tech itself.
So like, are you packaging it up in an easy to use API or is like the, imagine you're
selling something to like podcast hosts that uses AI.
I mean, AI could be amazing, but if like the user interface sucks, you know, like you're,
you're not going to use it.
Here's what you do.
You're going to make a post request over to this and you put this header in and like, it's
going to like, here's how you do paging and you're like, no, no, here's the library
in your language.
You call the one function, things happen, right?
Like how presentable or straightforward do you make it right?
Right.
Cause I actually think that's a huge piece of it.
Are you, are you making it easier?
Are you making, is the distribution around the technology you're creating like really powerful
and, and like, do you have good ideas around that?
So I think it's a combination of those things, but to be honest, I think really depends on
what you're building and what the product is or what you're doing.
Cause it varies, like really it varies a lot.
Yeah.
There's also the part that we as developers don't love to think about, but the marketing
and awareness and growth and traction, right?
Yeah.
It's, you could say, look, here's the most amazing model we have.
Well, we haven't actually got any users yet, but that is a really hard sell for investors
unless they absolutely see, you know, this has huge potential.
Right.
But if you're like, look, we've got this much monthly number of users and here's the
way we're going to start to up, you know, create a premium offering.
And yeah.
Yeah.
Right.
That that's something we're not particularly skilled at as developers, but that's a non-trivial
part of any tech startup.
Right.
Oh yeah.
And I think as a developer too, you kind of like shy away from wanting to work on that
because it's so much easier to just write code or build a new feature versus like go solve
this hard marketing problem or go like.
Marketing sales.
Like you gotta have them, even if you're bad at them and you don't like it.
Yeah.
And we're fortunate that we get to market it to developers.
So like I enjoy it, you know, and cause you get like to talk to developers all the time,
but yeah, that's a huge piece of it too.
Definitely.
It's, it's kind of all come together.
Yeah.
This up a little bit, we're getting sort of near the end, but let's talk about,
you've got this idea of you've got your models, you've got your libraries, you've trained them
up using your GPUs.
Now you want to offer it as an API.
Like how do you go to production with a machine learning model and do something interesting?
You want to talk about how that's where I know you talked a little bit about running
the cloud and whatnot, but yeah.
You know, do you offer as an API over Flask or run it in a cloud?
Like what are you doing there?
Are they Lambda functions?
Yeah, that's a good, that's a good question.
What's your world look like?
So we have asynchronous APIs where you send in an audio file and then we send you a
webhook when it's done processing.
And then we have real-time APIs over WebSocket where you're streaming audio and you're getting
stuff back over a WebSocket in real time.
The real-time stuff's a lot more challenging to build.
I'm sure it is.
Yeah.
The async stuff.
Really what happens is we have like, so one of our main APIs was built in Tornado.
I don't know if you, yeah.
Legacy.
The early, early async enabled Python web framework before asyncio was officially a thing.
Yep.
So I built the first version of the API in Tornado.
So it's kind of like still in Tornado for that reason.
A lot of the newer things or newer microservices are built by FastAPI or Flask.
And so for the asynchronous API, what happens is like you're making a post request.
The API is really just like a CRUD app.
It's storing a record of the request that you made with all the parameters that you turned
on or turn off.
And then that goes into a database.
Some worker that's like the orchestrator is constantly looking at that database and it's
like, okay, there's some new work to be done.
And then kicks off all these different jobs to all these different microservices, some over
queues, some over HTTP, collects everything back, orchestrates like what could be done in
parallel, what depends on what to be done first.
When that's all done, all the kind of asynchronous like background jobs, the orchestrator pushes
the final result back into our primary database.
And then that triggers you getting a webhook with the final result.
So that's like in a nutshell, kind of what the architecture looks like for the asynchronous
workloads.
There's like tons of different microservices, all with different instance types.
different like compute requirements, some GPU, some CPU, some, you know, like all different
scaling policies.
And that's really where the hard part is.
That's kind of like the basic overview of how the asynchronous stuff works in production.
Yeah.
Very cool.
Yeah.
Are you seeing Postgres or MySQL or something like that?
Postgres for the primary DB.
Because we're on AWS, we use DynamoDB for a couple of things like ephemeral records we need
to keep around for when you send something in, it goes to DynamoDB.
And that's where we like keep track of basically like your request and what parameters you add
on and off.
And that kicks off a bunch of things.
But the primary DB is Postgres.
Yeah.
I think there's like, at this point, like it's getting pretty large.
There's like a few billion records in there.
Because we process like a couple million audio files a day with the API.
Sometimes I'll read on Hacker News like these, I think like GitHub went down at one point
because they couldn't increment the primary key values any higher.
It's, int 64 is overflowing.
We're done.
Yeah, yeah.
Something like that.
Yeah.
I mean, in the back of my mind, like I hope we're thinking about something like that because
that would be really bad if we came up against something like that.
Do you store the audio content in the database or are they going like some kind of bucket,
some object storage thing?
So we're unique in that we don't store a copy of your audio data.
Okay.
For privacy reasons for you.
So you send something in, it's stored ephemerally like in the memory of the machine that's processing
your file.
And then what's stored is the transcription text encrypted at rest because you need to be able
to make a GET request for the API to fetch it.
But then you can follow up with a delete request to permanently delete the transcription text from
our database.
So we try to like keep no record of the data that you're processing because like we want
to be really privacy focused and sensitive.
You can, like some customers will toggle on that.
We keep some of their data to continuously improve the models, but by default, we don't store anything.
Yeah, that's really cool.
Yeah.
That's good for privacy.
It's also good for you all because there's just less stuff that you have to be nervous about
when you're trying to fall asleep.
You're like, what if somebody broke in and got all the audio?
Oh wait, we don't have the audio.
Okay.
So that's not a thing they could get.
Yeah.
Like things like that, right?
Yeah.
It's definitely, definitely.
I hadn't thought about that before, but I'm imagining now what that would be like.
Well, now I'm making, now you're going to be nervous because there's probably other stuff,
but that's all right.
Yeah.
Now you got me thinking about in that space.
Like what are those things we need to lock up?
No, we have like, we're mostly a team of engineers.
So I think of the 30 people, like 70% are engineers with a lot more experience than me.
So we're doing everything like by the book, especially with the business that we're in.
Yeah.
Of course.
Yeah.
All right, Dylan, I think we're out of time, if not out of topic.
So let's maybe wrap this up a little bit with the final two questions and some packages and
stuff.
So if you're going to work on some Python code, what editor are you using these days?
I'm still using Sublime.
Right on.
What do you use?
The OG easy ones.
I'm mostly PyCharm.
If I want to just open a single file and look at it, I'll probably use VS Code for that.
That's probably just, you know, I want to open that thing.
Not have all the project ideas around it, but I'm doing proper work.
Probably PyCharm these days.
Yeah.
That makes sense.
Yeah.
And then a notable PyPI project, some library out there.
I mean, you've already talked about it, like TensorFlow and some others, but anything out
there you're like, oh, we should, you should definitely check this out.
I would check out Hugging Face if you haven't yet.
It's a pretty cool library.
Yeah.
A pretty cool library.
Yeah.
Hugging Face seems like a really interesting idea.
Yeah.
I want to give a quick shout out to one as well that I don't know if you've seen this.
Have you seen TLS, please, as an LS replacement?
No.
Chris May told me about this yesterday.
Told me and Brian for Python Bytes.
Check this out.
So it's a new LS that has like icons and it's all developer focused.
So like if you've got a virtual environment, it'll show that separately.
If you've got a Python file, it has a Python icon.
The things that appear in the list are controlled somewhat by the git ignore file and other things
like that.
And you can even do like a more detailed listing where it'll show like the git status of the
various files.
Isn't that crazy?
That's really cool.
Yeah.
That's really cool.
That's a Python library, PLS.
PLS.
That's awesome.
I'll check that one out.
Yeah.
People can check that out.
Yeah.
All right.
Dylan, thank you so much for being on the show.
It's really cool to get this look into running ML stuff.
Yeah.
And production and whatnot.
Thanks for having me on.
Yeah.
You bet.
You want to give us a final call to action?
People interested in sort of maybe doing an ML startup or even if they want to do things
with Assembly AI?
If you want to check out our APIs for automatic speech and text, you can go to our website,
assemblyai.com.
Get a free API token.
You don't have to talk to anyone.
You can start playing around.
There's a lot of Python code samples that you can grab to get up and running pretty quickly.
And then, yeah, if you're interested in ML startups, I think that one of the things that
I always recommend is if you want to go the funding route, definitely check out Y Combinator
as a place to apply because that really helped us get off the ground.
They help you out with a lot of credits around GPUs and resources.
And it helps a lot.
That helped us a lot.
Were you in the 2017 cohort?
Yeah.
Something like that.
Yeah.
2017.
So it was super helpful.
And I would highly recommend that.
There's also just a big community of other ML people that you can get access to through
that.
So that really helped.
And I would recommend people check that out.
How about if I don't want to go PC funded?
Yeah.
Go ahead.
Yeah.
So one more is there's also an online accelerator called Pioneer.
I don't know if you've heard of this, but that's also a good one to check out too.
If you don't want to go the accelerator route, then I would say like, yeah, really it's just
about getting a model working good enough to like close your first customer and then just
like keep iterating, you know?
So like don't get caught up in like reaching state of the art or yeah.
Like in the research, just like kind of think of like the MVP model that you need to build.
They go win your first customer and they kind of keep going from there.
Yeah.
Awesome.
All right.
Well, thanks for sharing all your experience and for being here.
Yeah.
Thanks for having me on.
This was fun.
Yeah, you bet it was.
All right.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
For over a dozen years, the Stack Overflow podcast has been exploring what it means to
be a developer and how the art and practice of software programming is changing the world.
Join them on that adventure at talkpython.fm/stack overflow.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with
Sentry.
Just visit talkpython.fm/sentry and get started for free.
And be sure to use the promo code talkpython, all one word.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Thank you.