• Stefy Lanza (nextime / spora )'s avatar
    runpod: place any model individually, keep orchestration local, ship LoRAs · 533f29f0
    Stefy Lanza (nextime / spora ) authored
    PER-MODEL PLACEMENT FOR ANY KIND. Sending a model to RunPod used to work
    only for text: resolve_pod_engine looked at whether the path ended in
    .gguf, and RunpodBackend implements chat only. A diffusion model pinned
    to runpod would have been handed to vLLM, which cannot serve it. Now the
    model's OWN KIND picks the pod: an image/video/TTS/STT/embedding model
    gets that capability's published coderai image, a GGUF gets llama.cpp, an
    HF repo gets vLLM. The gateway routes by model BEFORE capability, so two
    models of the same kind can differ — one video model pinned local with
    `placement: "local"` while another runs on its own pod with its own
    budget, which capability-level routing could never express.
    
    A pod rented for one model starts with an EMPTY catalogue and would
    refuse every request for it, so pod_plan seeds CODERAI_SEED_MODELS with
    that model's entry and the pod registers it at startup (in memory only —
    a pod is disposable, and writing it would surprise anyone setting the
    variable on a real install). Only fields that describe the model travel:
    never local paths, which mean nothing there, and never this deployment's
    placement settings, which would have the pod renting pods of its own.
    
    ORCHESTRATION STAYS LOCAL. /v1/pipelines, /v1/characters and
    /v1/environments are no longer gatewayable capabilities. They are a
    sequence of calls to other endpoints, and they already dispatch each step
    through the front as its own /v1 request — so every step is placed by its
    own model's config, and a chain can mix local and remote freely.
    Forwarding the chain would have moved the logic to a pod and placed every
    step by that pod's catalogue instead.
    
    LORAS FOLLOW THE REQUEST. A LoRA is a file on this machine; a pod has
    never seen it. The blob store is content-addressed, so each adapter is
    hashed, checked against the remote's /v1/loras/blob/<hash>, uploaded only
    when missing, and the reference rewritten to that id — repeat requests
    upload nothing. QLoRA needs nothing extra: the quantisation is in how the
    base model loads, the adapter is the same safetensors file. An HF id or
    URL is left alone for the remote to fetch.
    
    Also: a vLLM pod now refuses a local model path up front, with the same
    reasoning as the GGUF guard — otherwise it boots for minutes and dies —
    and passes `quantization` through, since a local load_in_4bit does not
    carry over to vLLM.
    Co-Authored-By: 's avatarClaude Opus 5 (1M context) <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY
    533f29f0
Name
Last commit
Last update
..
test_admin_auth.py Loading commit data...
test_admin_remote_ui.py Loading commit data...
test_audio_ml_backends.py Loading commit data...
test_audio_ml_endpoints.py Loading commit data...
test_broker_config.py Loading commit data...
test_broker_dispatch.py Loading commit data...
test_broker_protocol.py Loading commit data...
test_broker_streaming.py Loading commit data...
test_burst_placement.py Loading commit data...
test_manual_multimodal_test_client.py Loading commit data...
test_remote_execution.py Loading commit data...
test_studio_composed_surfaces.py Loading commit data...
test_whisper_server_local_models.py Loading commit data...