fix(vllm): pin the model so the app id cannot lie - #60
Conversation
There was a problem hiding this comment.
Pull request overview
This PR removes configuration drift in the vllm example by pinning the served model in compose.yml so the statically advertised app id in runners.json can’t become inaccurate via an environment override. It also updates vllm/README.md to explain the static-runner “contract” (config must remain truthful) and points readers to realtime-transcription for the dynamic alternative.
Changes:
- Pin the vLLM model in
vllm/compose.ymlinstead of allowing an override viaVLLM_MODEL. - Remove
VLLM_MODELfromvllm/.env.exampleto avoid implying the model is an operator “knob”. - Update
vllm/README.mdto document why the model is pinned for static registration and how to change it safely.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| vllm/README.md | Documents static vs dynamic runner registration and clarifies that the vLLM model is intentionally pinned to keep the advertised app id truthful. |
| vllm/compose.yml | Pins --model to Qwen/Qwen2.5-0.5B-Instruct and updates comments explaining why this must not be an env override. |
| vllm/.env.example | Removes VLLM_MODEL to prevent accidental app-id/model drift through environment configuration. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
runners.json advertises `vllm/qwen2.5-0.5b-instruct` by name while VLLM_MODEL let an operator serve something else. .env.example presented it as an ordinary knob, so turning it silently made the app id false, and discovery republished that to the network at whatever price was set. A static runner has no code to recompute its id: the container is the stock vllm image with zero Livepeer code, which is the point of the example. So the fix is to remove the drift rather than derive the name. Serving another model now means editing the compose command and runners.json together, which is the static registration bargain: the operator owns the contract, and the orchestrator health-polls the runner without ever checking it serves what the config claims. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
d394b0c to
553526f
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Suppressed comments (1)
vllm/compose.yml:33
- The comment says
runners.json“advertises this model by name”, butvllm/runners.jsononly contains the app id (vllm/qwen2.5-0.5b-instruct), not the Hugging Face model string. Rewording avoids suggesting the exact model name lives inrunners.json.
# Pinned, not a knob: runners.json advertises this model by name, so change both
# together. --gpu-memory-utilization caps VRAM (0.9 default can exceed free).
runners.jsonadvertisesvllm/qwen2.5-0.5b-instructby name, butcompose.ymlread${VLLM_MODEL:-Qwen/Qwen2.5-0.5B-Instruct}and.env.examplepresented it as an ordinary knob. Turn it and the app id becomes false: discovery republishes it unchanged at whatever price the operator set, and a caller filtering for Qwen gets Llama with no way to tell.The fix pins the model as a literal in
compose.ymland dropsVLLM_MODELfrom.env.example. Serving a different model now means editing the compose command andrunners.jsontogether.Deriving the id from the loaded model (what
realtime-transcriptiondoes) is not available here: vllm is a static runner whose container is the stockvllm/vllm-openaiimage with zero Livepeer code, which is what the example exists to show. So the README states the asymmetry instead. A dynamic app advertises what it loaded and cannot drift; a static one stays true only if the operator keeps it so, and the orchestrator health-polls the runner without ever checking it serves whatrunners.jsonclaims.Verified: stack up with the literal, vLLM served, runner registered as
vllm/qwen2.5-0.5b-instruct.