[fts-forge]

What

Replaces fleet.ai/ollaya with fleet.ai/laya (modules/ai/laya.nix): upstream laya-serve (NandhaKishorM/laya v0.4.21, its own NixOS module) on the same 127.0.0.1:11435 /v1/systemone, so the Paperclip router (STA-631) keeps working.

• Why laya-serve: it loads laya-train fine-tunes directly (settings.ai.laya.extraModels). Ollaya only runs ONNX graphs, and training on our own decisions is where Laya's accuracy comes from.
• GPU when there's room: a start wrapper reads free VRAM and starts on cuda with at least 4 GiB free, else cpu. A 2-minute timer restarts the service onto the other device when that changes: under 1 GiB free on the GPU moves it to the CPU, and 4 GiB free moves it back.
• fp32 on both devices, so a move never shifts the probabilities that thresholds get fitted on. Weights are pinned to laya's reviewed revision, and a checkpoint unloads after 10 idle minutes.

Verified

• nix build .#nixosConfigurations.THEBATTLESHIP.config.system.build.toplevel exits 0.
• A scratch instance of the same laya-serve, run as cody on port 11439: it started on cuda with 12.7 GiB free, answered HTTP 200 with a 2-question choice, and warm requests took 19–44 ms (Ollaya on the CPU takes about 93 ms). It used 2.0 GiB VRAM and 3.0 GB RSS.
• flake.lock: only the new laya input. systems_8 and systems_9 swapped numbering; no revision changed.

Notes

• The router config uses laya:en (Ollaya's name). laya-serve answers to laya/english, so the router should switch to laya.
• Not deployed. Switching THEBATTLESHIP stops ollaya.service and starts laya-serve. Its first start downloads about 800 MB of weights.
• Rollback: sudo nixos-rebuild switch --rollback.

[fts-forge]

Deployed to THEBATTLESHIP (generation 1078) and fixed what the first switch exposed:

• HTTP 500 on every request at first. On CUDA, ModernBERT's Triton kernels compile a C helper on first use. The sandboxed service had no writable cache, no cc and no libcuda path. Then the helper built but wouldn't load, because systemd mounts the DynamicUser state dir noexec. Fix: TRITON_CACHE_DIR=/tmp/triton (the private /tmp allows exec), stdenv.cc on the path, and TRITON_LIBCUDA_PATH.
• Live now: started on cuda (12.3 GiB free). HTTP 200, warm requests 11–13 ms, 2.0 GiB VRAM, 1.2 GB unit memory. laya:en is accepted too, so the STA-631 router works unchanged. laya-serve-rebalance runs cleanly, and systemctl --failed is empty.
• CPU fallback: the same package with LAYA_DEVICE=cpu gives HTTP 200 at about 250 ms warm, with the same choices and probabilities as the GPU (max difference 0 at the returned precision).