Model Deployment | Kamiwaza Docs

Kamiwaza 0.9.3 Documentation

This is documentation for Kamiwaza 0.9.3, which is no longer actively maintained. For the current GA release, see 1.0.1.

Model Deployment Process

The model deployment process in Kamiwaza is designed to be simple and robust.

  1. Initiate Deployment: When you request to deploy a model, Kamiwaza's Models Service takes over.
  2. Engine Selection: The platform automatically determines the best engine based on your hardware, operating system, and the model's file format. For example, on a Mac with an M2 chip, a .gguf file will be deployed with llama.cpp, while .safetensors will use MLX. You can also override this and specify an engine manually.
  3. Resource Allocation: The system allocates a network port and configures the load balancer (Traefik) to route requests to the new model endpoint.
  4. Launch: The selected engine is started. For vLLM on Linux, this is a Docker container. For MLX on macOS, it's a native process.
  5. Health Check: Kamiwaza monitors the model until it is healthy and ready to serve traffic.

Once deployed, your model is available via a standard API endpoint.

Deployment Lifecycle Statuses

Below are the deployment and instance statuses you may see, with what they mean and what (if anything) you should do.

Instance-Level Statuses (for replicas)

Error Codes and What to Do

If a deployment shows ERROR or FAILED, the UI may show a short error code and message. Common codes:

Viewing Logs and Diagnostics

Tips for Novice Mode

When to Retry vs. Change Configuration

How Routing Works

Kamiwaza wires the public port to Ray Serve for model traffic. Routes can be created immediately after launch; Ray Serve handles readiness internally. This is why you may see INITIALIZING briefly before DEPLOYED.