Native audio.cpp home workers

Native audio.cpp home workers

These profiles run the home push daemon (brioso-worker serve) with
BRIOSO_WORKER_MODEL=audiocpp. The M5 uses one resident audio.cpp server for
the beta and production worker processes. The NVIDIA profile remains a
single worker with the native CLI.

Use the exact profile templates as the starting point:

• NVIDIA RTX 4070 / CUDA: apps/worker/.env.audiocpp-nvidia.example
• Apple Silicon / Metal: apps/worker/.env.audiocpp-apple-silicon.example

Copy one to the machine’s untracked apps/worker/.env, then set the shared
secret, worker id, telemetry endpoint, and absolute binary/model paths. Do not
set AUDIOCPP_BACKEND alone: BRIOSO_WORKER_MODEL=audiocpp is the model
selector; AUDIOCPP_BACKEND=cuda|metal only selects its accelerator.

Install and model preparation

Pin audio.cpp to v0.7.3. On Linux/CUDA, build that tagged source with CUDA
enabled and set AUDIOCPP_BIN to the audiocpp_cli path. On Apple Silicon,
use the v0.7.3 Metal audiocpp_server binary.

For the NVIDIA profile, download the F16 Medium GGUF to a normal local file
and record its path in AUDIOCPP_MODEL_PATH:

uv tool run --from huggingface_hub hf download \
  audio-cpp/audio.cpp-gguf \
  Stable-Audio-3-Medium-GGUF/stable-audio-3-medium-f16.gguf \
  --local-dir /srv/brioso/models

The M5 server uses the q8_0 Medium variant
(stable-audio-3-medium-q8_0.gguf, ~3.4 GB) at the path in its PM2 JSON
config. Download the q8_0 sibling with the same command and copy it there.
NVIDIA can also use Q8 by updating AUDIOCPP_MODEL_PATH.

audio.cpp v0.7.3 uses a file extension to determine tensor format, so an HF
cache symlink resolves to a blob without .gguf and fails. The copied file
above is therefore a deployment requirement, not just a cache optimization.

NVIDIA RTX 4070 (CUDA)

1. Copy the NVIDIA template to apps/worker/.env; keep
   BRIOSO_WORKER_MODEL=audiocpp and AUDIOCPP_BACKEND=cuda.
2. Build audio.cpp at v0.7.3 with CUDA, set an absolute AUDIOCPP_BIN, and
   pre-download the F16 Medium GGUF to the absolute AUDIOCPP_MODEL_PATH.
3. Run brioso doctor; it must pass the binary, model, CUDA, credentials, and
   backend checks.
4. Generate one F16 Medium WAV directly, then run brioso start, pm2 save,
   and pm2 startup.
5. Complete an existing API-backed runner="home" job and verify it reaches
   paid after upload.

Apple Silicon (Metal)

1. Install the Metal v0.7.3 audiocpp_server and copy the Medium Q8 GGUF to
   the path in deploy/pm2/m5-audiocpp-server.json.
2. Create separate private env files at ~/.config/brioso/m5/beta.env and
   production.env. Give each its own backend URL, worker secret, and
   HOME_WAKE_TOKEN. Set BRIOSO_WAKE_REQUIRE_TOKEN=1 in both files. The
   addon examples use push.tokenEnv: WORKER_SHARED_SECRET, which is already
   available to the backend. Set each daemon’s HOME_WAKE_TOKEN to its existing
   environment specific WORKER_SHARED_SECRET; never commit either value.
   AUDIOCPP_SERVER_URL explicitly selects the resident transport. Without it,
   the worker uses the existing CLI. Use apps/worker/.env.audiocpp-m5.example
   for the shared model URL and admission lock settings.
3. Start deploy/pm2/ecosystem.m5-home.config.cjs. Its model server listens
   on 127.0.0.1:7309; the workers listen on 127.0.0.1:7312 and :7311.
   The supervised SSH reverse tunnel exposes them to the VPS on its own
   loopback ports 17312 and 17311. Retain this SSH transport.
   The workers share one file lock and reject extra work before acknowledging
   it.
4. From the VPS, check http://127.0.0.1:17312/health for beta and
   http://127.0.0.1:17311/health for production. Confirm the runtime IDs.
   Missing, wrong, and opposite environment bearers must receive 401.
   Correctly authenticated empty JSON POSTs to /jobs must return 422
   without starting inference. Use push.tokenEnv: WORKER_SHARED_SECRET for
   the addon examples.
5. Confirm /v1/models says stable-audio-3-medium is loaded and both
   workers are idle before restarting the beta worker for a revision test.
   Leave the production worker, model, tunnel, and Tailscale policies unchanged.
6. The default gateway files preserve existing routing. Separate
   config/gpu-gateway.m5-beta.example.yaml and
   config/gpu-gateway.m5-prod.example.yaml files describe optional activation.
   Review and apply individual runtime and chain changes only when activating
   the addon. Do not import over the live registry.
7. Generate one beta song through brioso_generate_song, poll
   brioso_get_generation, and check the download. Production’s /mcp
   remains disabled; worker health alone does not prove production inference.

Checks and recovery

For migration from SSH to the dedicated Mac Cloudflare Tunnel, follow the
tunnel rollout and rollback. Retain SSH until
production completes its own HTTPS acceptance checks.

brioso engine prints audio.cpp/cuda or audio.cpp/metal; brioso config
shows the selected BRIOSO_WORKER_MODEL and backend. brioso doctor requires
absolute, existing binary and model paths for audio.cpp profiles.

Deploy through the existing guarded workflow when separately authorized.
Capture the active release and runtime configuration before activation.

On failure, restore the captured beta artifact and worker configuration.
Keep strict bearer authentication, the SSH tunnel, and fallback chains.
A completed song on Modal is a failed M5 verification. Correlate the job slug,
call ID, home-m5-beta runner, worker completion, terminal paid record,
and decoded application download. Revoke any temporary MCP credential.

For a bad rollout, run brioso stop, correct the profile or restore
BRIOSO_WORKER_MODEL=sa3, run brioso doctor, then brioso start. Inspect
brioso logs --lines 100 before rejoining the pool. Do not delete a claimed
job or alter its runner while diagnosing; normal lease expiry/fallback remains
the recovery mechanism.