Deploy your model
To deploy your model: Runbaseten model push --output json. The JSON output returns the model and deployment IDs needed in later steps.
Validate your model
To validate the deployed model: Target the returned model and deployment IDs, and use representative input for your model. Save the model-defined response body for inspection and print the HTTP status.response.json and confirm that the output matches your expectations. For more information, see Call your model.
For a Model API, promote the exact deployment that you validated to production before you create the endpoint.
To promote the validated Model API deployment to production:
Set --model-id to the model ID returned by baseten model push, abc123, and set --deployment-id to the validated deployment ID, def456. The command promotes to production by default.
Publish your model
Publish a Dedicated model
Create a private, closed-source listing, publish the validated model version, and then make that version live for adoption. To create a private, closed-source listing: Setdisplay_name to the customer-facing name, user_defined_id to a stable listing ID, is_public to false so the Dedicated listing is not publicly accessible, and closed_source to true to protect the Truss and weights. closed_source controls artifact access, not customer availability.
oracle_version_id to the deployed model version, version_tag to the identifier for the published version, and allow_truss_download to false to prevent downloads. allow_truss_download controls artifact access, not customer availability.
version_tag in the path to select the published version, then set is_live to true to make it live for customer adoption.
Publish a Model API
The Distribution Platform uses the Gateway endpoint management resource to configure the model target for a Model API. This shared control-plane resource doesn’t make customer inference a Frontier Gateway call. Customers call the Model API with workspace API keys and Model API inference semantics, not Frontier Gateway federated keys. Create an endpoint that maps the Model API slug to your validated model in production. The response structure follows Create an endpoint. This example uses a generic slug and model ID, and the response omitsenvironment_name because production targets don’t echo it.
To create the Model API endpoint:
Set slug to the endpoint’s routing identifier. In the OpenAI-compatible
example below, customers send this value in the model field. Add one targets
entry with provider set to BASETEN, the deployed model_id, and
environment_name set to production to route requests to that deployment.
Complete the Baseten-assisted setup
After you create the listing or endpoint, Baseten enables your organization for distribution, configures the billing setup and customer pricing, attaches the license and supplemental terms, and configures Model API availability. A lab can start a Model API with an allowlist of selected customer workspaces, then make it available to all eligible Baseten customers after validation. Baseten configures both the allowlist and broader availability during assisted setup. Send your Baseten contact the listing ID or endpoint ID, distribution channel, price and unit, terms, and intended customer availability. If you don’t have a Baseten contact, talk to us. Baseten confirms when setup is complete and, for a Model API, provides the customer activation URL. After Baseten completes setup, give one test customer access. Customer access is outside the five lifecycle stages.Test your published model
After Baseten completes setup and the test customer activates the Model API, give this request to a developer in that customer’s workspace. They must setBASETEN_API_KEY to an API key from that workspace. This is an OpenAI-compatible example. Custom Model APIs use the request and response schema that the lab defines.
To test an OpenAI-compatible Model API end to end:
Set model to the published slug and put the chat input in messages so the shared endpoint routes the request to your model.
Update your published model
Update a Dedicated model
To publish a new Dedicated version: First, publish the new deployed model version to the listing with a new version tag. Replaceacme-text-model with your listing ID, pqr678 with the deployed model version ID, and 2.0.0 with the new version tag.
2.0.0 live for adoption. This demotes the previous live version.
Replace acme-text-model with your listing ID and 2.0.0 with the version tag to make live.
Update a Model API
When you deploy a new version of the same Baseten model, validate the new deployment and promote it to production. The endpoint continues to target the same model ID and production environment, so you don’t need to update it. To update the deployment for the same Baseten model: Set--model-id to the existing Baseten model ID, abc123, and set --deployment-id to its new validated deployment ID, mno345. The command promotes to production by default.
--model-id to the new Baseten model ID, ghi789, and set --deployment-id to its validated deployment ID, jkl012. The command promotes to production by default.
abc123hash to your endpoint ID and ghi789 to the new model ID that you promoted.
Retire your model
Retire a Dedicated model
To delete a Dedicated listing: Replaceacme-text-model with the listing ID to delete.
Deleting the listing stops new adoption and removes its catalog resources. It
does not terminate customer deployments already created from an adopted
version. Those deployments continue until each customer replaces or retires
them.
Retire a Model API
To delete a Model API endpoint: Replaceabc123hash with the endpoint ID to delete.
Next steps
- Give customers access: Understand customer activation and limits.
- Insights: Track customers, models, and proceeds.