Configuration

Worker configuration comes from three sources, merged in order (later wins):

1. Built-in defaults compiled into the daemon.
2. Config file at ~/.pendra/config.yaml (Unix) or %ProgramData%\Pendra\config.yaml (Windows).
3. Environment variables.

pendra setup writes the config file interactively; pendra config set <key> <value> mutates it directly. Env vars are re-read on every CLI invocation and at daemon startup.

Example config file

# ~/.pendra/config.yaml
app_server_ws_url: wss://api.pendra.ai
gpu_worker_private_key: <base64-ed25519-private-key>
worker_id: wrk-a1b2c3d4
worker_name: gpu-01
models_dir: ~/.pendra/models
# optional — private inference (set by 'pendra keygen --save'):
workload_private_key_file: ~/.pendra/workload_key

The file holds the Ed25519 private key in plaintext, so the daemon enforces mode 0600 on Unix and warns at startup if it's wider. On Windows the config directory and key file are restricted to SYSTEM, Administrators, and the account Pendra runs as, so other local accounts can't read the key.

Settings reference

Naming a worker

Installing a worker never asks you for a name. It starts out named after the machine it's running on — its hostname — so a fresh worker shows up in the console already recognisable.

To change it, open Workers → your worker in the console and click the pencil next to the name. Type the new name and save. The worker has to be connected: the console sends the new name to it, and it takes effect within a couple of seconds — no restart, and the name sticks across restarts. You need to be an owner or operator, and names are up to 64 characters.

If you'd rather set the name where you deploy the worker — a Docker -e WORKER_NAME=gpu-01, a Kubernetes manifest, a systemd unit — you still can, and it's the better fit for containers, whose hostname is an unhelpful random string. Just note that the WORKER_NAME environment variable wins every time the worker restarts, so a rename you make in the console will be replaced by it on the next restart. Pick one place to name a given worker and stay there.

The worker_name key in config.yaml works the other way round: a rename you make in the console takes precedence over it. To set the name on the machine instead, run pendra config set worker_name gpu-01 — that clears the console name for you — then restart the worker.

Per-worker settings in the console

A few worker-wide tuning options live in the console rather than in config.yaml or an env var. Open Workers → your worker → Settings (you must be an owner or operator) — changes apply to the running worker within a few seconds, no restart needed.

Accepted, running, waiting

These three settings are easier to reason about as one pipeline. A request Pendra sends here is accepted; a request the GPU is currently generating is running; anything in between is waiting on this worker for a free slot.

Generating a reply means running the model once per token. A single pass that produces one token for one request costs almost the same as a pass that produces one token for eight, because the GPU spends most of it waiting on memory rather than calculating. That is why Run requests together is worth turning on: eight requests served together finish in barely more time than one served alone, where eight served one after another take roughly eight times as long.

With Run requests together off, this worker generates one reply at a time no matter how many it accepts — the rest simply queue here. So raising Requests accepted at once on its own does not add speed; it only decides where requests go.

Splitting the two matters most when you run a single worker. Say sixteen requests arrive at once on one GPU:

• Accept 8, run 8 — the ninth request has nowhere to go and is rejected.
• Accept 16, run 16 — nobody is rejected, but one GPU's output is split sixteen ways, so every reply is slow.
• Accept 16, run 8 — nobody is rejected, eight stream at full speed, and the rest start the moment a slot frees.

Going from one to around eight running at once costs each individual reply very little. Pushing it much higher keeps raising total throughput, but every reply gets noticeably slower — so a bulk or batch job wants it as high as it goes, while anything a person is waiting on wants it moderate. It is not a memory setting: lowering it does not free GPU memory, which is reserved from the model's context window instead.

A few model families always generate one reply at a time regardless of these settings, because of how they store conversation state. The console says so on the model itself.

CLI commands

Related

• Install — get the worker running.
• System requirements — OS support, hardware.
• Choosing a context size — how the context window is sized.