Placement Deployment Guide | Kamiwaza Docs
Documentation for Kamiwaza 1.0.0
This is documentation for Kamiwaza 1.0.0, which is no longer actively maintained. For the current GA release, see 1.0.1.
Version: 1.0.0
Placement is automatic — deploying a model with placement is the same deploy flow you already use. This guide shows how to deploy multiple models onto shared GPUs, read where each deployment landed, and troubleshoot placement problems.
For background on how placement decides, read the Model Placement Overview and Fractional GPU Serving.
Before you start
- A model downloaded and ready to deploy. See Downloading Models.
- A rough sense of the model's memory footprint versus your hardware. The UI shows VRAM guidance per variant; the SDK exposes
estimate_model_vram. - On a managed cluster: the NVIDIA or AMD GPU Operator installed by your cluster admin. If no sharing strategy is configured, deployments still work but density is limited to one model per GPU.
Deploy a model in the UI
- Navigate to the Models page and select the model.
- Click Deploy. In Novice Mode, Kamiwaza picks a platform-appropriate variant with sensible defaults; in Advanced Mode you can select the engine and parameters yourself. See the GUI Walkthrough.
- Kamiwaza estimates the model's footprint, picks a GPU (or memory pool) with enough free budget, and starts the deployment. No placement input is required.
- Watch the status move through
DEPLOYINGandINITIALIZINGtoDEPLOYED. The statuses are described in Model Deployment.
To run a second model on the same hardware, just deploy it the same way. If the combined budgets fit, both models run side by side; if not, the second deployment fails fast with a NoFit error.
Deploy a model with the SDK
from kamiwaza_sdk import KamiwazaClient
client = KamiwazaClient(base_url="https://<your-host>/api")
deployment_id = client.serving.deploy_model(model_id=model_id)
deployment_id = client.serving.deploy_model(
repo_id="Qwen/Qwen3-8B",
m_config_id=config_id,
)
status = client.serving.get_deployment_status(deployment_id)
The deploy API is asynchronous: the server accepts the request and returns the deployment ID immediately. By default the SDK blocks client-side (wait=True), polling until the deployment reaches DEPLOYED.
Monitor placement
Open a deployment's details to see where it landed:
| Field | Meaning |
|---|---|
topology |
managed_cluster or standalone_cluster |
node_name |
The node the model was placed on |
gpu_index, gpu_vendor |
Which GPU on the node, and its vendor |
hardware_class |
hardware_isolated, software_shared, or unified_memory |
sharing_class |
Sharing method of the device |
allocated_capacity_gb |
Reserved memory budget for this deployment, in GB |
Verify
- Confirm each deployment shows
DEPLOYEDin the UI. - Send a short test prompt to each deployment's endpoint.
- If you deployed multiple models to one GPU, confirm both respond — they are serving concurrently from the same card.
Troubleshooting
The deployment fails immediately with a placement (NoFit) error
This indicates that the model does not fit anywhere, and the deployment shows FAILED with last_error_code set to NoFitError. Common causes include insufficient capacity among others.
A SharingNotConfigured notice appears
On a managed cluster where the GPU Operator is installed but no sharing strategy is configured, deployments succeed as whole-GPU but are limited to one model per GPU.
The deployment reaches ERROR or FAILED after placement
If the deployment record shows an error code, it usually contains helpful information for troubleshooting.
The deployment sits in INITIALIZING
This could be normal, but if it persists, check the last error code for potential issues.
Checking capacity on a standalone cluster
kubectl get node <node-name> -o jsonpath='{.metadata.labels}' | tr ',' '\n' | grep gpu
kubectl get node <node-name> -o jsonpath='{.status.allocatable}' | tr ',' '\n' | grep vram-gb-gpu
If a node shows no kamiwaza.ai/gpu-* labels, hardware detection may not have labeled it.