LoRA transport: upload / id / url / inline file (no shared filesystem)
Previously a per-request LoRA could only be a local path or HF id, which
assumed the client shared the server's filesystem. Add a content-addressed
store so remote clients can supply LoRAs by value or handle.
Request `loras` spec now accepts (resolved server-side, in priority):
id "name:<registered>" -> a LoRA trained on this server (path-independent)
id "sha256:<hex>" -> a previously uploaded blob
file/data (base64) -> inline weights, cached in the blob store
url -> server downloads (cached by content hash)
model/path -> legacy local path / HF id (unchanged)
- loras.py: blob store (save_lora_blob / lora_blob_exists / _lora_blob_path),
resolve_lora_ref(), resolve_request_loras() (in-place -> clean 400 on a
missing blob / unknown name). New POST /v1/loras/upload (multipart / JSON
base64 / raw, dedup) and GET /v1/loras/blob/{hash} existence check.
- LoraConfig / VideoLoraConfig: model now optional; add id/url/file/data/path.
- image + video handlers resolve_request_loras() before model work, so
signature dedup / VRAM reserve / load_lora_weights read lora.model as before.
- gen_township_fighters.py: reference trained LoRAs by id "name:<registered>"
(derived from the server path) with the raw path kept as a co-located
fallback, so the script works client/server-split.
Also harden video load: float(cfg.get('balanced_gpu_percent', 80)) crashed on
an explicit null (admin UI writes null for blank fields); use `or 80`.
Co-Authored-By:
Claude Opus 4.8 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment