[model-config] feat: add environment variables support for backends

[Nold360]

Description

Simple change to be able to specify env variables for backend processes in model config. This way the user is able to further customizes processes. Like in my case i want to be able to set CUDA_VISIBLE_DEVICES to control which model gets loaded onto which of my GPUs. it also slightly reduces VRAM usage on unused GPUs when using tensor_split.

• Add field to model configuration to pass environment variables to backend processes
• Update backend options and model configuration handling
• Add documentation for environment variables configuration

Assisted-by: qwen-agentworld-35b-a3b

Notes for Reviewers

Signed commits

• [x ] Yes, I signed my commits.

[mudler]

Looking good!

[mudler]

seems we don't pass the env vars here in distributed mode?

[Nold360]

ah, i didn't really know about distributed.. seems like we need to pass it through installbackend, too for that. i'll look into it.

[Nold360]

seems like we need to pass the env variables through InstallBackend for that, too.

if you are fine with more params on those, i'll try to get it done

[mudler]

yes that sounds right, we can probably take the occasion (if it's bloating the function arguments) to pass a struct option too

[Copilot]

Pull request overview

Adds support for specifying per-model environment variables in model.yaml, threading them through model config → backend options → backend process spawn so operators can control backend runtime behavior (e.g., CUDA_VISIBLE_DEVICES).

Changes:

• Add env to model configuration schema and UI metadata registry.
• Plumb env vars into model loader options and backend process spawning.
• Extend gRPC ModelOptions proto and document the new YAML field.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/model/process.go	Extends backend process spawn to accept model-specific env vars.
pkg/model/loader_options.go	Adds loader option storage + setter for env vars.
pkg/model/initializers.go	Passes env vars through when spawning the gRPC backend.
core/services/worker/supervisor.go	Updates StartProcess callsite for new signature.
core/config/model_config.go	Adds env field to the model config schema.
core/config/model_config_test.go	Adds a test section intended to cover env var config.
core/config/meta/registry.go	Registers env for UI/config metadata (map editor).
core/backend/options.go	Threads config env vars into model options and gRPC options.
backend/backend.proto	Adds EnvVars to ModelOptions proto.
docs/content/advanced/model-configuration.md	Documents env: usage in model configuration YAML.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[localai-bot]

Thanks @Nold360, this is a genuinely useful knob (per-model CUDA_VISIBLE_DEVICES in particular is a common ask). The functional path is correct: ModelOptions() -> WithEnvVars(c.Environment) -> startProcess appends the vars to the backend process environment. That part works.

Two things to address before this can go green, one blocking:

1. Build break (blocking): the proto field is not backed by generated code.
The PR adds map<string, string> EnvVars = 75; to backend/backend.proto and then sets opts.EnvVars in grpcModelOpts (core/backend/options.go), but the generated pkg/grpc/proto/backend.pb.go was not regenerated. On master that file has no EnvVars field, so opts.EnvVars = ... will not compile once the build matrix runs (right now only DCO has executed because fork CI needs maintainer approval). You would need make protogen-go and to commit the regenerated backend.pb.go/backend_grpc.pb.go.

2. But the proto path is actually dead code, so the cleaner fix is to drop it entirely.
Nothing consumes ModelOptions.EnvVars: I grepped the whole repo and there is no reader, and your own core/services/worker/supervisor.go change passes nil for the env map. The env vars only ever take effect through the local startProcess -> os/exec environment (path #1), not through the gRPC ModelOptions message. So the backend.proto field, the grpcModelOpts block, and the regen are all unnecessary. Dropping them makes this a tighter change and sidesteps the build break.

Concretely, I would suggest:

• remove the EnvVars = 75 field from backend.proto
• remove the opts.EnvVars = ... block in grpcModelOpts
• keep everything else (the Environment config field, WithEnvVars, the startProcess injection, the docs, the test)

Minor: if c.Environment != nil && len(c.Environment) > 0 can just be if len(c.Environment) > 0 (len(nil) == 0), same in both call sites.

Worth a doc note: because the injection happens in startProcess, this applies to locally spawned backends. In distributed mode the remote worker supervisor spawns the process (and passes nil), so env: will not reach a remote worker as written. Fine as a first cut, just worth calling out so users are not surprised.

Once the proto path is dropped (or the pb.go regenerated) and CI is green, happy to take another look.