runpod: a preferred GPU, not the only GPU (v0.3.1)
`gpu_type` was a filter: "NVIDIA A40" meant an A40 or nothing, so when RunPod
had no A40 free the request failed rather than taking a card that would have
served it. Now `gpu_types` is an ordered PREFERENCE and `allow_other_gpus` lets
the search fall through to anything else that still satisfies min_vram_gb and
max_hourly_usd.
A preferred card ranks ahead of every fallback whatever selection_criteria
says — otherwise "cheaper" would put the fallback first and naming a card would
mean nothing. Each ranked option carries `preferred`, and provisioning a card
nobody asked for prints "[FALLBACK — no preferred card available]": correct
behaviour, but never silent.
Off by default. A pinned card is sometimes pinned for a reason, and an install
that quietly started renting something else would be a surprise on the invoice.
Name matching is exact on the id or display name, case-insensitive, tolerating
a missing "NVIDIA " prefix, and deliberately NOT a substring: "A40" would
otherwise match "NVIDIA RTX A4000" — 16 GB for a job that asked for 48. GPU
names split on commas only, because "NVIDIA RTX A6000" has spaces in it.
Also: the admin handler rebuilds the runpod block from a whitelist, so all six
keys added today (global_volume_id, data_centers, gpu_types, allow_other_gpus,
allow_client_scale, client_scale_ttl_s) were being dropped the next time anyone
saved a model from the GUI — taking the warm schedule and the volume with them.
They are in the whitelist now, with the two ordered lists kept in order.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
This diff is collapsed.
Please
register
or
sign in
to comment