Your idea, and it removes the last dead end. vLLM and llama.cpp pods
could not be given a local model or adapter: no endpoint to upload to,
and their server needs the file at launch. But a pod CAN fetch it before
the server runs — put the weights on any HTTP host it can reach and stage
them at boot.

The obstacle was that those images run their server as the ENTRYPOINT, so
everything we passed became an argument to the server. RunPod's REST pod
API accepts dockerEntrypoint/dockerStartCmd (GraphQL does not), so
runpod_client now creates a pod through REST when an override is needed
and stays on GraphQL otherwise.

The staged start command fetches with curl, wget or python — whichever
the image actually has rather than whichever we assumed — extracts a tar
for a multi-file model, and then execs the server pointed at what it
staged. One definition of the staged path (staged_model_dest) is used by
both the download and the server args: computing it twice is exactly how
a pod downloads to one path and serves another, which the first cut did,
along with emitting two --model flags.

Adapters given as a URL ride the same path: --lora-modules for vLLM,
--lora/--lora-scaled for llama.cpp. So a local adapter reaches a vLLM pod
after all — publish it to a URL instead of uploading it.

`source: upload` against a vLLM pod now says what to do instead, rather
than only that it cannot.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY