runpod: let a client lease warm pods up to max_pods (v0.2.93)
The autoscaler reacts to load — a pod is added once the least-loaded one
already has scale_up_inflight_per_pod requests in flight. That is right for
traffic nobody predicted and wrong for a client that KNOWS what is coming: a
batch of a thousand documents otherwise discovers the pool one cold start at a
time.
So a client may now say so: POST /v1/runpod/scale {model, pods}. It is a lease,
bounded three ways, because a client that can raise the floor can raise the
bill:
* allow_client_scale, off by default, so no model is client-scalable unless
someone said so;
* clamped to max_pods — asking for more returns the ceiling with
"clamped": true rather than an error, since the client asked for "as many
as you can" and refusing would leave it with none;
* client_scale_ttl_s (default 30 min), because the failure that matters is
not a wrong number, it is a client that asks for four A40s and then dies.
A lease that never expired would be a bill that never stopped, so a 0 in
the config falls back to the default instead of meaning "forever".
The lease and a warm-pod schedule are MAXED, never summed: both mean "hold this
many ready", so a client cannot lower a configured floor and a closed window
cannot cancel a lease. /v1/runpod/status reports the live lease per model, so an
unexpected bill has a visible cause.
Not admin-scoped, unlike /v1/runpod/spend: the gate is the per-model flag, not
the key, and the account's $/hr and spend caps still refuse to provision.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
This diff is collapsed.
Please
register
or
sign in
to comment