seattleite849
seattleite849 OP t1_j736n71 wrote
Reply to comment by swappybizz in [p] I built an open source platform to deploy computationally intensive Python functions as serverless jobs, with no timeouts by seattleite849
We are spinning up the serverless gpu hosting the model using banana.dev btw (which I’ve really liked so far). Cakework spins up CPU-only microVMs for now, since the Firecracker virtual machine monitor runs only on CPUs.
seattleite849 OP t1_j734kwb wrote
Reply to comment by swappybizz in [p] I built an open source platform to deploy computationally intensive Python functions as serverless jobs, with no timeouts by seattleite849
Yup, that’s one of our examples! You can run this project to run a stable diffusion model on a serverless GPU: https://github.com/usecakework/cakework/tree/main/examples/image_generation
seattleite849 OP t1_j732oth wrote
Reply to comment by Noddybear in [p] I built an open source platform to deploy computationally intensive Python functions as serverless jobs, with no timeouts by seattleite849
🙌 heck yeah!
seattleite849 OP t1_j6yt8w2 wrote
Reply to comment by BasilLimade in [p] I built an open source platform to deploy computationally intensive Python functions as serverless jobs, with no timeouts by seattleite849
How are you wanting to trigger your function?
Also, here are some examples you can peek at: https://docs.cakework.com/examples
Under the hood, both Lambda and cakework are deploying Docker containers as microVMs running on bare metal instances. A few key differences:
- Lambda is a building block vs cakework is a custom, point solution for running async tasks. Meaning with Lambda, you will want to wire together other cloud resources to make it an application you can hit. This mix of code and infrastructure makes iterating quickly on your actual logic slow, in my experience, since you need to:
- Trigger the function (either exposing it via API Gateway if you'd like to invoke it using a REST call), or by hooking it up to an event (S3 PutObject, database update event).
- To hook up your function to other functions (for example, if you want to upload the final artifact to S3), you'll set up SQS queues. If you want to chain functions together, you'll set up Step Functions
- To track failures, store input/output params and results, and easily view logs, you would set up a database and write some scripts to trace the request via Cloudwatch logs.
- With Lambda, you manage creating and building the container yourself, as well as updating the Lambda function code. There are tools out there such as sst or serverless.com which help streamline this.
- With Cakework, you write your Python functions as plain code, then run a single command via the Cakework CLI to run `cakework deploy` which deploys your functions, exposes a public endpoint you can hit (either via REST calls, a Python SDK, or Javascript/Typescript SDK). The nice thing is you can directly test invoking your function as if it were code running on your local machine.
- No limits on the docker image size and no limit on how long your job can run for (vs 10 GB and 15 minute timeout for Lambda)
- You also specify CPU and memory parameters per request! So that you don't need to spin up a bigger instance than you actually need and pay that extra cost. Or provision not enough CPU or memory and 1) deal with failures, then 2) re-deploy your lambda with more compute.
seattleite849 OP t1_j737hp8 wrote
Reply to comment by swappybizz in [p] I built an open source platform to deploy computationally intensive Python functions as serverless jobs, with no timeouts by seattleite849
I got a bunch of credits from cloud hosting providers haha. Also since this is a beta I wanted a generous free tier. To connect with banana.dev, you would need to sign up for your own account and pass in your API key to the Python function that’s getting run on cakework. Thin