Bug
docker model compose up defines a --backend flag (default llama.cpp) but never uses the value when calling ConfigureBackend.
Evidence (main)
In cmd/cli/commands/compose.go (newUpCommand):
var backend string
// ...
c.Flags().StringVar(&backend, "backend", llamacpp.Name, "inference backend to use")
The only write is the flag binding. backend is never read. Configure is built as:
desktopClient.ConfigureBackend(scheduling.ConfigureRequest{
Model: model,
BackendConfiguration: backendConfig,
RawRuntimeFlags: rawRuntimeFlags,
})
There is no backend name field set from the flag. scheduling.ConfigureRequest also has no top-level backend selector (only model + BackendConfiguration + runtime flags). So even if the flag were plumbed, the request shape would need a place to put it (for example how ModelConfigEntry.Backend is stored elsewhere).
Meanwhile compose metadata advertises --backend via commandParameters(upCmd), so Compose/UI consumers may show a backend selector that does nothing.
Expected
Either:
- Plumb
--backend into the configure/install path so non-default backends work under compose, or
- Remove the flag from
up and from metadata until the API can honor it (so metadata matches behaviour).
Impact
Users (or Compose integrations) that pass --backend vllm (or anything other than the default) get silent no-ops: the flag is accepted, metadata lists it, but configuration always follows the runner default.
Related
I can send a PR either wiring backend selection or dropping the dead flag after maintainers pick a direction.
Bug
docker model compose updefines a--backendflag (defaultllama.cpp) but never uses the value when callingConfigureBackend.Evidence (main)
In
cmd/cli/commands/compose.go(newUpCommand):The only write is the flag binding.
backendis never read. Configure is built as:There is no backend name field set from the flag.
scheduling.ConfigureRequestalso has no top-level backend selector (only model +BackendConfiguration+ runtime flags). So even if the flag were plumbed, the request shape would need a place to put it (for example howModelConfigEntry.Backendis stored elsewhere).Meanwhile
compose metadataadvertises--backendviacommandParameters(upCmd), so Compose/UI consumers may show a backend selector that does nothing.Expected
Either:
--backendinto the configure/install path so non-default backends work under compose, orupand from metadata until the API can honor it (so metadata matches behaviour).Impact
Users (or Compose integrations) that pass
--backend vllm(or anything other than the default) get silent no-ops: the flag is accepted, metadata lists it, but configuration always follows the runner default.Related
I can send a PR either wiring backend selection or dropping the dead flag after maintainers pick a direction.