/v1/loras/upload put the bytes somewhere; nothing made them answerable. The
last step was editing models.json by hand, which is not a step a team
retraining adapters can automate — so the answer to "how do we send you a
QLoRA?" was "send it to us and we will register it", with a human in it.

POST /v1/loras/register {name, base, adapter} closes that. It joins the BASE'S
POOL by default, which is the entire economy of the thing: the base weights are
already loaded on a rented card, an adapter is tens of megabytes of deltas, and
vLLM applies them per request. It inherits the base's placement, card choice
and budgets, and deliberately does NOT inherit min_pods or keep_warm — an
adapter rides the base's pod, it does not ask for one of its own.

Re-registering a name with a new blob is how a retrain ships. A name that
already belongs to a real model is a 409 rather than a replacement, and an
adapter whose bytes we do not hold is a 404 that names the upload endpoint:
a pod sent a content id nobody holds serves the BASE instead, silently, which
is the failure this whole area has been about.

Identity is (weights, name) here too. An adapter and its base share a `path` by
definition, so the lookup is by id-or-alias and never by path.

/v1/loras is also pinned local in the gateway. An upload must land in THIS blob
store — it is where a pod is sent its adapters from, and the content id this
install hands out has to resolve here. It carries no `model` field, so it
happened to stay local by accident; that is luck, not design, and the same
shape of accident as /v1/runpod, which did not stay local and rented a pod to
deliver a teardown.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HXRMe9ZPUQCCCtBai9uqt3