Autoscaling Is a Control Loop, Not a Button
Autoscaling trades responsiveness, stability, and cost: this explainer shows how signal choice, scaling direction, and capacity limits shape the right control loop for a workload.
DatabricksAnshul GuptaProblem & solution
Databricks Custom Model Serving addresses the operational burden of serving custom models, whose resource profiles, traffic patterns, and latency requirements vary widely from small CPU classifiers to large GPU-backed language models. Its fully managed platform packages MLflow models and uses isolated Kubernetes deployments, model-appropriate runtimes, and a short request path to limit interference and per-request overhead. At the center, the AutoPilot Pod Autoscaler combines active concurrency and queue signals for horizontal scaling with CPU, GPU, and memory measurements for model-aware target-concurrency adjustment, allowing one controller to adapt across workloads. Warm pools, provisioned concurrency, and zero-downtime updates address startup and deployment concerns, while reported production results include 90%+ cost savings for some customers, up to 2x improvement in p99 and p50 latency, 100K+ QPS, and 99.99% availability.
Custom models have widely different resource profiles, traffic patterns, and latency budgets, while traffic can spike, burst, or drop to zero. Traditional serving platforms require customers to configure replica counts, concurrency, and autoscaling thresholds, creating ongoing re-profiling work and tension between low latency, high scale, and cost efficiency.
Custom Model Serving uses isolated Kubernetes deployments, model-specific inference runtimes, and a short request path. Its AutoPilot Pod Autoscaler combines request-based horizontal scaling with model-aware vertical scaling that adjusts target concurrency using CPU, GPU, memory, queue, and concurrency signals. Warm pools, provisioned concurrency, and zero-downtime updates address cold starts and releases.
The AutoPilot Pod Autoscaler learns how much load each model replica can handle and adjusts target_concurrency without changing the underlying hardware.
Horizontal scaling responds to active concurrent requests, while model-aware vertical scaling uses resource and load measurements to account for differences between workloads such as CPU classifiers and GPU-heavy LLMs.
Reported production results include 90%+ cost savings for some customers, up to 2x improvements in p99 and p50 latency, 100K+ QPS, and 99.99% availability.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Autoscaling trades responsiveness, stability, and cost: this explainer shows how signal choice, scaling direction, and capacity limits shape the right control loop for a workload.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.