Model Changes
Let's get to it 🙌 One detail to get out of the way is that you don't need to per se migrate your current model. Instead we recommend creating a new model, that's a V2 version of your V1 model. So the migration workflow will be something like:
Create new GitHub repo => from this create a new model => migrate that model => redirect traffic from V1 model to V2 => confirm that everything works => delete old model
This way you'll never have any downtime and you can revert to the V1 model if needed 👍
Potassium
Potassium is our server framework that you'll use to deploy your models to V2 with. This is probably the biggest change for you when migrating so let's go through things thoroughly. We'll use the BERT serverless template as an example model from V1 and migrate it.
Let's migrate the BERT serverless template
The easiest way to get a Potassium app scaffolded is using the Banana CLI. Get it on your machine by running:
You don't need the CLI, but it's a nice convenience. Once you got it you can initialise a Potassium app by running:
If you get an error such as "command not found: banana "
, you probably haven't added the Python package bin location to your PATH variable.
If that's the case, on Mac try something like:
export PATH="/Users/<me>/Library/Python/3.9/bin:$PATH"
Once you cd into the directory you'll have the scaffold for Potassium read to go 🔥 If you're doing this manually, you'll need an app.py
and a Dockerfile
as a minimum requirement. But we highly recommend to use the download.py
utility, requirements.txt
and .gitignore
as well.
Now, activate your virtual environment, e.g.
And run your Potassium app locally:
To make sure that it works you can simply call your server from another terminal by running:
Now you're running a Potassium app locally, awesome 💪
What's in the app.py
Okay so this is maybe a bit cheating. The default scaffold is a BERT model after all. So what to you need to change in your app to use to the Potassium framework? Let's look at the app.py
to understand what's going on.
The default app.py
looks like this:
If you're familiar with the Serverless Template, this should look familiar to you. To refresh your memory, this is the app.py in the Serverless Template:
Key takeaways:
init()
in both cases runs when the server starts. But in Potassium we don't need to make the model a global object. We can pass it to the context which is accessible in every handlerinference()
-->@app.handler()
. Instead of an inference function you can put the decorator over your function which makes it an http-endpoint.This also gives you access to the context, Request & Response objects.
Pro tip when developing a Potassium app: If it runs locally -- it should run remotely
Alright, now we have a Potassium app, let's deploy it! 🚀
The final step, deploy
Now for the simple stuff. To deploy the model you'll need to:
Create a model/repo on GitHub (this should be familiar from before)
Push local changes to the main branch on GitHub
Go to the model settings (image below) --> change to V2
This will trigger a rebuild, let's wait for 5-15 minutes while it rebuilds. Grab some coffee ☕
Build is done 🚀
Now let's move to the next section on how to call the model -->
Last updated