Hello,
Following up on the question of why the LLM stack is built as
translators, here is the honest accounting of what the
architecture buys, compared with a classical LLM stack (a
monolithic API, a GPU in a datacenter, and a black box). Each
point below comes from the actual roadmap of the components, not
from aspiration.
1. Composability through the filesystem. Every interaction between
components is a POSIX write/read: no socket, no linked library,
no proprietary API. The contracts between translators are
frozen JSON files, versioned like code.
2. Replaceability. PostgreSQL can change host or version without
recompiling anything upstream — only /db and its conninfo
move. Any component can be swapped at runtime with settrans,
while the rest of the stack keeps running.
3. Inspectability. cat /db/status, cat /inference/request,
/web/<url>/status: the whole state of the stack is readable
with cat. No intermediate state is hidden inside a process.
4. Explainability and audit. The interface narrates each action,
and the frozen JSON trio request/status/result is a complete
trail of every run. Compare with an opaque response and no
audit of the reasoning.
5. Errors are data, not failures. A non-200 HTTP status is an
exploitable datum, not a POSIX error; an SQL duplicate is a
readable "duplicate" status, not a fatal error; the translator
retries the connection and stays alive. In a classical stack,
one transport error kills the whole request.
6. Fault isolation. The supervisor persists every incident and
restarts the failed instance; one crash invalidates nothing
else. A classical stack is a single point of failure with
manual restarts.
7. Reliability through comparison. N networks with different
topologies run on /llm1 ... /llmN; their outputs are evaluated
and merged (majority vote / weighted average). A classical
LLM gives you blind trust in one output.
8. Replayability. Everything is persisted from the first run:
the run can be replayed later, identically, with the network
unplugged. With a remote LLM, nothing is replayable outside
the provider.
9. Sovereignty and security. The remote mode delegates all
encryption and authentication to OpenSSH, with nominative,
revocable public keys held in a registry; private keys never
enter the stack. In a classical stack, prompts and data leave
the machine toward a third party.
10. Resource efficiency. The compute unit is float32, one arena
allocation, zero allocation in the hot paths: it runs on a
local CPU. A classical LLM needs a datacenter of GPUs, with
the matching cost and footprint.
11. Native multi-task and multi-user. Each translator is a POSIX
node serving several users simultaneously, with per-reader
cursors and explicit locking. This is now a written
requirement in all five repositories.
12. Testability. The tests are deterministic POSIX operations,
environment-agnostic, with a home-grown harness and make
check everywhere; a file that behaves like /llm<N> is enough
to test the orchestrator. A classical stack needs real
network calls, pays per test, and fights non-determinism.
And the limit, stated openly because the roadmaps do not hide
it: translators provide the architecture — coordination,
persistence, traceability, composition. The neuron-translator
itself remains a feedforward sigmoid network, not a pretrained
transformer. The value over a classical LLM stack is structural:
open it, audit it, compose it, replay it. It is not a claim
about the language quality of the underlying model.
Best regards,
Claire Ivanenka
[email protected]
GNU AI — https://gnu-ai.org
