[bong-water-water-bong]

The Laya GGUFs (mys/laya-GGUF, laya-multilingual-GGUF, laya-typed-decisions-GGUF) are compiled by ggmlc for its own laya runtime on GGML. They aren't llama.cpp GGUFs. This PR makes the typed-decisions one the router's scorer.

• third_party/ggmlc is pinned at 1519ea42. -DONEBIT_LAYA_GGML=ON builds its laya with GGML Vulkan (cmake/laya-ggml.cmake).
• config/laya.json pins mys/laya-typed-decisions-GGUF@1e9e8ba1, file laya_typed_decisions_q8_0.gguf. scripts/fetch-laya.sh fetches it into <laya dir>/gguf/ and checks its sha256. Verified on strixhalo: 20 checkpoint files plus the GGUF.
• serve --laya runs laya daemon <gguf> --family typed-decisions --device vulkan and talks to it over pipes. It doesn't use laya serve, which binds INADDR_ANY with auth off. It asks the same question and applies the same long_doc size gate, and it falls back to the C++ scorer when the binary or GGUF is missing. --laya-model FILE.gguf, ONEBIT_LAYA_GGML and ONEBIT_LAYA_DEVICE override the defaults.
• tests/laya_gguf_route.sh (ctest, CI) runs 8 checks with a fake daemon.

Measured through 1bit serve --laya on Strix Halo, using tests/laya_route_cases.json (200 cases; 150 are asked of the model):

Scorer	Accuracy	Decision p50
C++ scorer, safetensors, CPU	95.5%	538 ms
ggmlc laya, typed-decisions Q8_0, Vulkan	95.5%	24 ms

Asked directly: typed-decisions F16 scores 95.5% at 36 ms, the English Q8_0 93.0% at 22 ms, and the English F16 91.5%. Also verified: a build with -DONEBIT_LAYA_GGML=ON runs the compiled-in binary with no environment overrides.

Licence note: ggmlc declares MIT in its pyproject.toml and README, but the repo has no LICENSE file (GitHub shows no license). NOTICE says so. Its vendored ggml carries MIT.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit e909f0f

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Potential Resource Leak in LayaDaemon The LayaDaemon class manages file descriptors for pipes (to_ and from_) and a child process (pid_). While the destructor attempts to close the file descriptors and terminate the child process, there's a potential issue if ::close() or ::kill() fails. Specifically, if ::close() fails, the file descriptor may remain open, leading to a resource leak. Similarly, if ::kill() fails to terminate the child process, it could remain as a zombie process. These scenarios could lead to resource exhaustion or unexpected behavior, especially in long-running server processes. ~LayaDaemon() { if (to_ >= 0) ::close(to_); if (from_ >= 0) ::close(from_); if (pid_ > 0) { ::kill(pid_, SIGTERM); ::waitpid(pid_, nullptr, 0); } } Possible SIGPIPE Handling Issue The code sets std::signal(SIGPIPE, SIG_IGN) to ignore SIGPIPE signals. While this prevents the server from crashing when a pipe write fails, it can mask underlying issues. If the daemon dies unexpectedly, writes to its stdin may fail silently, and the server might not detect that the daemon is no longer functional. This could lead to silent failures or incorrect routing decisions. std::signal(SIGPIPE, SIG_IGN); // a daemon that died fails a write, not the server Insecure Temporary File Usage The script uses mktemp -d to create a temporary directory for testing, but it doesn't explicitly set permissions or ensure the directory is secure. While mktemp generally creates secure directories, the script should explicitly set permissions to ensure that only the owner can access the temporary files, preventing potential security issues.