Skip to content

compose up: --backend flag is accepted but never applied #1036

Description

@VedantMadane

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:

  1. Plumb --backend into the configure/install path so non-default backends work under compose, or
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions