llm: make every text model remotizable, GGUF included
Two additions, one goal: no text model is stuck on this box.
1. codai/backends/remote_openai.py — set `service_url` on a model entry
and coderai proxies that model to any OpenAI-compatible endpoint
(another coderai, llama-server, vLLM, SGLang, a rented pod) instead of
loading it. `served_model` renames it for the remote, `api_key` adds a
bearer token. It reuses RunPod's request/SSE machinery and only
replaces endpoint resolution, so streaming and usage accounting are
the same code path.
This is what makes the GGUF/llama.cpp catalogue remotizable: those
models load in-process through llama-cpp-python, so there is no
service to redirect — pointing the *model* at a URL is the only
redirect available. The manager checks it first, ahead of every engine
route, and `_model_is_runpod` grew into `_model_is_remote` so such
models are never downloaded, cached, or charged local VRAM (old name
kept as an alias).
2. RunPod pods pick their server per model. A GGUF cannot simply go to
vLLM: its GGUF loader is experimental — single file only, a limited
architecture list, and it still wants the original repo's tokenizer.
So `engine: auto` sends an HF repo to vLLM and a GGUF to llama.cpp's
own server image (ghcr.io/ggml-org/llama.cpp:server-cuda), which
downloads the weights itself from `hf_gguf` ("user/repo:Q4_K_M") —
a local /AI/….gguf path means nothing on a rented machine, and we
don't upload multi-GB weights. `engine: vllm|llamacpp` overrides.
Both servers answer /v1/models, so the readiness probe is unchanged.
Tested against fake servers: routing, /v1 normalisation, auth header,
chat, SSE streaming, usage, and each engine-selection branch.
Co-Authored-By:
Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY
Showing
Please
register
or
sign in
to comment