# Ship & Monitor: From Weeks to Minutes

Deploying a model is where most platforms stop. k3ld Model carries a trained model through deployment to a live, monitored, self-correcting endpoint — the part the status quo gets stuck on longest.

## Ship — deploying a trained model

**Status quo — 1–2 weeks per deployment**

- Write the Dockerfile, slim the 8GB image down to 6GB; `docker build` → push 6GB to ECR (~20 min)
- Hand-write SageMaker config via boto3: create model → endpoint config → endpoint
- Test → `MissingAuthenticationTokenException` → fix IAM → retry
- Write autoscaling alarms by hand (CloudWatch metric math)
- Document the endpoint URL in Confluence. "How do I update the model?" — that's another week

**k3ld Model — 2 minutes**

- One click from a completed training run: real-time endpoint, batch, or serverless
- Platform packages model + tokenizer + inference script into the container
- Autoscaling policy created automatically
- Endpoint goes live with an API key and a ready-to-call URL
- Cost & capacity planner estimates instances and monthly spend before you deploy
- Canary traffic split, adapter attach, and rollback built in
- GPU auto-sleep: endpoints pause when idle (billing stops) and wake on the first request

## Monitor

**Status quo — ongoing 0.75 FTE**

CloudWatch dashboards, hand-written drift cron, "is it still good?" Slack pings, no one knows when to retrain.

**k3ld Model — built-in, live**

- Latency, drift, and usage dashboards out of the box
- Drift scans on a schedule with alerting
- Retraining one click away from the same dataset
- Data capture on every prediction so you can audit what the model actually did
- Production is where models decay — monitoring and retraining are part of the platform, not a side project

## Real example

A deployed **Ministral-3-3B + LoRA** support assistant (from the 3-day walkthrough) runs as a real-time endpoint with autoscaling, data capture, and idle-sleep. Same model that cost the status-quo pipeline 6–10 weeks shipped in a day.